Модель запустилась. Это еще не значит, что ей можно пользоваться

В социальных сетях регулярно появляются сообщения: большая модель запущена на ноутбуке, мини-ПК или рабочей станции с ограниченной памятью. Технически это может быть правдой. Веса загрузились, программа не завершилась с ошибкой, модель сгенерировала ответ.

Но для бизнеса важен не факт запуска. Важен ответ на другой вопрос: может ли система выполнять нужную работу с приемлемой задержкой, под реальной нагрузкой и без деградации качества?

Если автор демонстрации не указал длину входа, время до первого токена, скорость генерации, число одновременных запросов, формат квантования и долю вычислений на CPU, фраза "модель работает" почти ничего не сообщает.

Инструменты вроде llama.cpp действительно позволяют запускать квантованные модели на широком спектре оборудования и использовать гибридный CPU+GPU inference. Это полезно для экспериментов и персональных сценариев. Но сама возможность выгрузить часть вычислений в системную память не превращает такую конфигурацию в производительный многопользовательский сервис.

Конкретный эксперимент, а не цифра из воздуха

11 сентября 2026 года автор FP4 Brain (@thefp4brain) опубликовал в X запуск DeepSeek V4.1 Flash на Mac mini M1 с 16 ГБ объединенной памяти и SSD на 1 ТБ. В эксперименте использовались исходные FP4/FP8-веса, SSD-streaming и самописный MLX-runner. Сам автор указал 108 секунд до первого токена и около 23 секунд на каждый следующий токен, отдельно предупредив, что это секунды на токен, а не токены в секунду. Видео было показано с ускорением 12x.

В продолжении ветки автор выложил код, рецепт запуска и журналы. Веса оставались на SSD, нужные эксперты и lookup-строки загружались по запросу, а для плотных весов использовался cache на 4 ГиБ. Дополнительными оптимизациями скорость удалось улучшить примерно с 31 до 23 секунд на токен.

Дополнительный завершенный прогон той же конфигурации, приведенный в разборе KOCPC, занял 16 минут 21 секунду: TTFT составил 127,9 секунды, средняя скорость - 30,7 секунды на токен, а итоговый ответ содержал 28 токенов.

Запрос к языковой модели проходит две основные фазы.

Prefill: обработка входа

Сначала движок обрабатывает системный промпт, историю диалога, найденные RAG-фрагменты и другие входные токены. На этом этапе строится KV-cache. Чем больше документов и инструкций передано модели, тем заметнее задержка до первого ответа.

Decode: генерация ответа

После prefill модель генерирует выход последовательно. Именно здесь обычно измеряют токены в секунду для одного потока. Но эта цифра без контекста тоже обманчива: нужно знать число параллельных запросов и распределение задержки, а не только лучший одиночный результат.

Официальная документация vLLM отдельно учитывает время до первого токена, межтокенную задержку, полную задержку запроса, время в очереди, длительность prefill и decode, а также загрузку KV-cache. Это и есть язык производственного inference.

Prefill и decode по-разному используют ускоритель. NVIDIA в разборе chunked prefill показывает, почему настройка планировщика всегда является компромиссом между временем до первого токена, скоростью текущей генерации и общей пропускной способностью.

Обычно используются один или несколько приемов: сильное квантование весов, CPU-offload, memory mapping, сокращенный контекст, маленький KV-cache, последовательное выполнение и единственный запрос без фоновой нагрузки. Каждый прием расширяет список оборудования, на котором модель можно запустить, но может снижать скорость, качество или доступную параллельность.

Особенно легко ошибиться с MoE-моделями. У них для одного токена активируется лишь часть экспертов, однако хранить и перемещать часто приходится значительно больший checkpoint. Например, карточка GLM-5.3-Flash указывает 320 млрд параметров всего и 18 млрд активных. У Kimi K2.7 Code заявлены 1 трлн параметров всего и 32 млрд активных. Активные параметры помогают понять объем вычислений на токен, но не равны памяти, необходимой для всех весов и рабочего состояния сервера.

Показателен и DeepSeek-V4-Flash-0731: официальный пример производительного запуска vLLM приведен для узла с четырьмя GB300 и специализированными настройками MoE, KV-cache и speculative decoding. Это не означает, что экспериментальные локальные варианты бесполезны. Это означает, что демонстрацию на доступном устройстве нельзя автоматически переносить на производственный SLA.

Заказчик может увидеть впечатляющий запуск модели на сотни миллиардов параметров и удивиться, почему для его задачи мы предлагаем, например, Qwen3.8-27B. Причина проста: мы выбираем не самый большой checkpoint, который теоретически стартует, а систему, которая укладывается в ограничения процесса.

Допустим, корпоративным ассистентом одновременно пользуются пять сотрудников. Они отправляют длинные документы, ожидают быстрый первый ответ и читают поток без пауз. Здесь нужно заранее определить:

• целевую скорость на один активный запрос, а не только суммарные токены сервера;
• p95 времени до первого токена для реальной длины входа;
• скорость prefill на документах из рабочего профиля;
• поведение при пяти одновременных запросах;
• допустимую глубину очереди;
• запас KV-cache и качество выбранной квантизации.

Для нашего интерактивного сценария 50-60 токенов/с на один активный поток - это нижняя допустимая граница. Комфортный рабочий диапазон начинается примерно с 80-100 токенов/с, а около 120 токенов/с дает желательный запас для более требовательного интерфейса. Важно не подменять эту цифру суммарным throughput сервера: пять одновременно работающих пользователей должны получать приемлемую скорость каждый.

Для тяжелого RAG отдельно измеряется prefill. Около 700-800 токенов/с можно считать минимально приемлемым уровнем для рассматриваемого профиля, но предпочтительный ориентир - примерно 1000 токенов/с и выше. Это не универсальный стандарт: целевые значения зависят от длины документов, SLA и структуры приложения.

В одном проектном сценарии с Qwen3.8-27B и пятью параллельными пользователями расчет может привести к двум RTX 5090 с tensor parallel в vLLM. Не потому, что модель вообще не запускается на меньшей конфигурации, а потому, что нужны скорость, KV-cache, параллельность и эксплуатационный запас. Точный результат подтверждается нагрузочным тестом выбранной версии модели, runtime, квантизации и контекста.

Сообщение "модель запущена" полезно как технический эксперимент. Оно показывает, что сообщество расширяет границы локального inference и находит новые способы использовать доступное оборудование.

Проблема начинается, когда результат эксперимента продают как доказательство готовности к бизнесу. Один сгенерированный ответ не подтверждает скорость, параллельность, стабильность, качество и экономику.

Поэтому при выборе частной LLM мы начинаем не с вопроса "какую самую большую модель можно загрузить?", а с процесса: какие данные она будет читать, сколько людей обратятся одновременно, сколько секунд они готовы ждать, какое качество нужно сохранить и сколько стоит один завершенный сценарий. После этого выбираются модель, runtime и GPU-конфигурация.

Рабочая локальная LLM - это не checkpoint в памяти. Это измеренная система с понятным SLA.