---
title: "Движки инференса LLM: vLLM, llama.cpp, LiteRT-LM и другие — скорость, железо, масштабирование"
url: "https://romankryvolapov.com/ru/llm-inference-engines/"
description: "Чем запускать языковые модели в конце 2026 года: движки vLLM, SGLang, TensorRT-LLM, llama.cpp, MLX, LiteRT-LM и ExecuTorch и программы на их основе вроде Ollama и LM Studio — за счёт чего движки быстрые, на каком железе работают и как масштабируются, с замерами на ноутбуке."
language: ru
published: 2026-11-05
updated: 2026-11-11
---
**Привет!**

Языковую модель мало скачать: нужна программа, которая её запустит. Она загружает веса в память, превращает текст в токены, прогоняет их через нейросеть, выбирает следующий токен и следит, чтобы памяти хватило всем пользователям. Такую программу называют движком инференса. Инференс (inference) — это работа уже обученной модели, в отличие от её обучения.

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

- **серверные** — vLLM, SGLang, TensorRT-LLM — обслуживают сотни и тысячи пользователей на видеокартах дата-центра;
- **локальные** — llama.cpp и MLX — запускают модель на своём компьютере;
- **встраиваемые** — LiteRT-LM, ExecuTorch, ONNX Runtime GenAI — работают внутри мобильного приложения, на ноутбуке или в браузере.

Движок не стоит путать с программами вокруг него. Ollama и LM Studio — не движки: они скачивают модели, показывают чат и отвечают по API, а считают внутри llama.cpp и MLX. NVIDIA Dynamo и llm-d — тоже не движки, а слой для кластера, который раздаёт запросы между копиями движка. И тем и другим в статье отведены отдельные разделы в конце.

В статье — что делает каждый, за счёт чего он быстрый, на каком железе работает и как масштабируется. Больше всего места отдано трём движкам, по одному на каждый класс: vLLM, llama.cpp и LiteRT-LM. Всё ниже — состояние на начало ноября 2026 года по документации, репозиториям и публичным бенчмаркам; даты без года относятся к 2026-му.

Команды из статьи проверены на моём ноутбуке: видеокарта RTX 5070 Ti Laptop с 12 ГБ памяти, процессор Ryzen 9 9955HX, 64 ГБ оперативной памяти, Windows 11. На нём же сделаны замеры: vLLM и llama.cpp под нагрузкой и LiteRT-LM на видеокарте и процессоре.

## Как работает инференс: пять понятий

Без этих понятий сравнение движков превращается в набор непонятных цифр. Если они вам знакомы, переходите сразу к [карте движков](#Карта-движков).

### Токены и веса

Модель работает не с буквами, а с токенами — кусочками текста длиной от одного символа до целого слова. Ответ она тоже выдаёт по одному токену.

Веса — это числа, полученные при обучении. Модель «на 1,7 млрд параметров» хранит 1,7 млрд таких чисел. В формате BF16 каждое число занимает 2 байта, то есть вся модель весит около 3,4 ГБ. При инференсе веса не меняются: движок только читает их и умножает на данные.

### Prefill и decode: две фазы с разными узкими местами

Ответ модели рождается в две фазы, и у каждой своё узкое место.

1. **Prefill** — модель читает запрос. Все токены промпта обрабатываются одновременно, одним большим умножением матриц. Видеокарта здесь загружена вычислениями полностью, и скорость упирается в её вычислительную мощность. От этой фазы зависит, как быстро появится первое слово ответа.
2. **Decode** — модель пишет ответ по одному токену. Для каждого следующего токена нужно прочитать из памяти все веса модели, а вычислений на один токен мало. Видеокарта больше ждёт данные, чем считает. Скорость здесь упирается в пропускную способность памяти — сколько гигабайт в секунду можно прочитать.

Отсюда простая прикидка: скорость генерации для одного пользователя ≈ пропускная способность памяти ÷ размер весов. Это видно на моём ноутбуке. Модель Qwen3-1.7B в формате BF16 (3,2 ГиБ) llama.cpp генерирует со скоростью 131 токен в секунду. Та же модель, сжатая до 4 бит (1,03 ГиБ), — 285 токенов в секунду: веса в три раза меньше, генерация в два с лишним раза быстрее. Чтение промпта при этом почти не изменилось: 13 000 и 15 700 токенов в секунду.

Тот же эффект хорошо виден в [замерах Apple](https://machinelearning.apple.com/research/exploring-llms-mlx-m5). Чип M5 обрабатывает промпт в 3,3–4,1 раза быстрее, чем M4: в его видеокарте появились нейроускорители для умножения матриц. А генерирует только на 19–27% быстрее, ровно настолько, насколько выросла пропускная способность памяти: 153 ГБ/с против 120.

### KV-кэш

Чтобы не пересчитывать весь текст заново на каждом шаге, модель сохраняет для каждого уже обработанного токена промежуточные результаты механизма внимания — ключи и значения (keys и values). Это и есть KV-кэш. Он растёт с каждым токеном, и для длинных диалогов он больше самой модели.

Посчитаем для той же Qwen3-1.7B. У неё 28 слоёв, в каждом 8 голов ключей и значений размером 128 чисел, каждое число занимает 2 байта. Один токен — это 28 × 8 × 128 × 2 (ключ и значение) × 2 байта = 112 КиБ. Диалог на 32 тысячи токенов занимает 3,5 ГиБ — больше, чем веса. Сто пользователей с такими диалогами — 350 ГиБ.

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

### Батчинг: почему сервер обслуживает многих почти по цене одного

На фазе decode видеокарта больше ждёт данные, чем считает. Если на каждом шаге генерировать токен не для одного пользователя, а для 16 сразу, веса читаются из памяти один раз на всех, а вычислений становится в 16 раз больше — и они наконец загружают видеокарту. Каждому пользователю ответ приходит чуть медленнее, а в сумме сервер выдаёт почти в 16 раз больше токенов. Это называется батчингом (batch — пачка).

Простой батчинг ждёт, пока соберётся пачка запросов, и держит её, пока не допишется самый длинный ответ. **Непрерывный батчинг** (continuous batching) добавляет и убирает запросы на каждом шаге генерации: один ответ закончился — на его место сразу встаёт следующий запрос из очереди. Сегодня так работают все движки, рассчитанные на много пользователей.

### Метрики: что значит «быстрый движок»

У скорости несколько измерений, и разные движки оптимизируют разные:

- **TTFT** (time to first token) — сколько ждать первого токена ответа. Важна в чатах и для агентов.
- **TPOT** (time per output token) — пауза между токенами одного ответа. 10 мс — это 100 токенов в секунду на пользователя. Величину, обратную TPOT, называют интерактивностью (interactivity): сколько токенов в секунду видит один пользователь.
- **Пропускная способность** (throughput) — сколько токенов в секунду сервер выдаёт в сумме по всем пользователям, обычно в пересчёте на одну видеокарту. От неё зависит цена миллиона токенов.
- **Goodput** — та же пропускная способность, но с учётом только тех запросов, которые уложились в обещанные задержки (SLA). Сервер, который выдаёт много токенов, но заставляет ждать первый токен по 10 секунд, никому не нужен.

Пропускная способность и интерактивность тянут в разные стороны: чем больше пользователей в одном батче, тем больше токенов в сумме и тем медленнее ответ каждому. Поэтому честный бенчмарк показывает не одну цифру, а кривую: сколько токенов в секунду на видеокарту даёт движок, если каждому пользователю обещано 30, 50 или 100 токенов в секунду.

### Квантование

Квантование хранит веса не в 16 битах, а в 8, 4 и даже меньше. Модель становится меньше, decode ускоряется, потому что читать нужно меньше, а качество немного падает. У каждого класса движков свои форматы:

- GGUF — у llama.cpp и всех, кто построен на нём;
- FP8, NVFP4, MXFP4, AWQ, GPTQ — у серверных движков;
- `.litertlm` — у LiteRT-LM.

FP8, NVFP4 и MXFP4 — форматы чисел с плавающей точкой на 8 и 4 бита, которые новые видеокарты считают аппаратно: FP8 — начиная с NVIDIA Ada и Hopper, FP4 — на NVIDIA Blackwell и AMD MI350.

## Карта движков

В таблице — движки, о которых пойдёт речь, и их версии на начало ноября. Масштабирование в этой таблице — это сколько железа движок умеет занять под одну модель.

| Движок | Для чего | Железо | Масштабирование | Лицензия | Версия |
|---|---|---|---|---|---|
| [vLLM](#vLLM) | сервер для многих пользователей, самый широкий охват моделей и железа | NVIDIA, AMD, Intel, Google TPU, AWS Trainium, Huawei Ascend, Apple Silicon, CPU | от одной видеокарты до стойки из 72 | Apache 2.0 | 0.33.0, 2 ноября |
| [SGLang](#SGLang) | то же; сильнее всего в повторном использовании общих префиксов | NVIDIA, AMD, Intel, Google TPU, Huawei Ascend, Apple Silicon | то же | Apache 2.0 | 0.5.23, 2 ноября |
| [TensorRT-LLM](#TensorRT-LLM) | максимум из видеокарт NVIDIA | только NVIDIA | то же | Apache 2.0 | 1.2.1, ветка 1.4 в предрелизах |
| [llama.cpp](#llamacpp) | одна машина: ПК, Mac, сервер, телефон | почти всё, вплоть до CPU без видеокарты | несколько видеокарт одной машины; несколько машин — экспериментально | MIT | b12233, 9 ноября |
| [MLX](#MLX) | Apple Silicon | Apple; есть бэкенд CUDA | несколько Mac через Thunderbolt 5 | MIT | mlx-lm 0.32.2 |
| [LiteRT-LM](#LiteRT-LM) | модель внутри приложения: Android, iOS, браузер, ПК, Raspberry Pi | CPU, GPU, NPU (Qualcomm, MediaTek) | одно устройство | Apache 2.0 | 0.19.1, 5 ноября |
| [ExecuTorch](#ExecuTorch) | то же, от Meta на основе PyTorch | CPU, GPU, NPU и DSP через десяток бэкендов | одно устройство | BSD | 1.5.1 |
| [ONNX Runtime GenAI](#ONNX-Runtime-GenAI-и-Windows-ML) | Windows-ПК и приложения Microsoft | CPU, NVIDIA, NPU и GPU через провайдеры Windows ML | одно устройство | MIT | 0.19.0 |
| [WebLLM](#В-браузере) | браузер | WebGPU | одно устройство | Apache 2.0 | 0.2.87 |

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

| Программа или слой | Что это | Какой движок внутри | Лицензия | Версия |
|---|---|---|---|---|
| [Ollama](#Ollama) | программа для запуска моделей на своём компьютере: каталог моделей, API | llama.cpp, на Mac — MLX | MIT | 0.40.15 |
| [LM Studio](#LM-Studio) | настольное приложение с чатом и локальным сервером | llama.cpp, MLX, Splash | закрытая, бесплатно для личного и внутреннего рабочего использования | 0.4.28 |
| [NVIDIA Dynamo](#NVIDIA-Dynamo) | слой для кластера: маршрутизация, KV-кэш, автомасштабирование | vLLM, SGLang или TensorRT-LLM | Apache 2.0 | 1.6.2 |
| [llm-d](#llm-d-и-другие) | слой для кластера на Kubernetes | vLLM или SGLang | Apache 2.0 | 1.0.0 |

Из обзора выпали движки, которые закрылись или замерли:

- **TGI** (Text Generation Inference) от Hugging Face. С 11 декабря 2025 года он в режиме поддержки, а теперь его [репозиторий](https://github.com/huggingface/text-generation-inference) в архиве. Hugging Face советует вместо него vLLM или SGLang, а для локального запуска — llama.cpp и MLX.
- **LoRAX** от Predibase и **IPEX-LLM** от Intel — репозитории в архиве.
- **DeepSpeed-MII** из проекта DeepSpeed — последний коммит в июне 2025 года.
- **MediaPipe LLM Inference API** от Google. Страница его документации теперь открывает документацию LiteRT-LM: Google переводит разработчиков туда.

### Как выбрать за минуту

- **Сервис для многих пользователей на своих видеокартах** → vLLM. SGLang — равноценная альтернатива, на конкретной модели и железе выигрывать может любой, поэтому проверьте оба. Только NVIDIA и нужен последний процент скорости → TensorRT-LLM, обычно вместе с Dynamo.
- **Десятки и сотни видеокарт в Kubernetes** → движок плюс слой для кластера: llm-d или NVIDIA Dynamo.
- **Модель на своём компьютере, для себя** → движок llama.cpp напрямую или программа поверх него — Ollama или LM Studio. На Mac — движок MLX, в том числе внутри LM Studio и Ollama.
- **Модель, которая не помещается в видеокарту** → llama.cpp: он держит часть модели в оперативной памяти. Для огромных моделей MoE вроде DeepSeek и Kimi — KTransformers.
- **Модель внутри приложения для Android или iOS** → LiteRT-LM. Если команда живёт в PyTorch — ExecuTorch. На iOS есть ещё системная модель Apple через Foundation Models.
- **Модель в браузере** → встроенный в Chrome Prompt API, WebLLM или transformers.js.

## vLLM

vLLM — сервер и библиотека на Python для инференса языковых моделей; всё, что требует скорости, написано на C++, CUDA и Triton. Он умеет больше всех: поддерживает больше двухсот архитектур моделей, работает на видеокартах трёх производителей и на десятке других ускорителей, масштабируется от одной видеокарты до стойки. Когда говорят «поднять модель на своих GPU», чаще всего имеют в виду именно его.

### Откуда он взялся и кто его делает

vLLM появился в 2023 году в лаборатории Sky Computing Калифорнийского университета в Беркли вместе со [статьёй о PagedAttention](https://arxiv.org/abs/2309.06180) — способе хранить KV-кэш страницами, о нём ниже. Уже тогда авторы показали [до 24 раз большую пропускную способность](https://vllm.ai/blog/2023-06-20-vllm), чем у библиотеки Hugging Face Transformers, и до 3,5 раза — чем у TGI.

С мая 2025 года vLLM — проект [PyTorch Foundation](https://pytorch.org/blog/pytorch-foundation-welcomes-vllm/) при Linux Foundation. В январе 2026 года его авторы основали компанию Inferact и [привлекли 150 млн долларов](https://techcrunch.com/2026/01/22/inference-startup-inferact-lands-150m-to-commercialize-vllm/) при оценке в 800 млн; раунд возглавили Andreessen Horowitz и Lightspeed. Сам движок остаётся открытым, под лицензией Apache 2.0.

Масштаб проекта: больше 2000 авторов кода и около 97 тысяч звёзд на GitHub. Только за июнь 2026 года в основную ветку влили [1918 коммитов](https://vllm.ai/blog/2026-07-16-keeping-vllm-production-quality) — по 64 в день. Релиз выходит раз в две недели, и каждый кандидат проходит полный набор тестов, ночные замеры производительности и проверку точности моделей. Последняя версия на момент написания — [0.33.0 от 2 ноября](https://github.com/vllm-project/vllm/releases): 927 коммитов от 389 авторов за две недели.

### Как он устроен

Команда `vllm serve` запускает не одну программу, а несколько процессов:

- **API-сервер** принимает HTTP-запросы, превращает текст в токены, применяет шаблон чата, загружает картинки и отправляет ответ клиенту по мере генерации.
- **Ядро движка** (engine core) — это планировщик и менеджер KV-кэша. Он крутится в бесконечном цикле и на каждом шаге решает, какие запросы и сколько их токенов пойдут в следующий прогон модели.
- **Рабочие процессы** — по одному на каждую видеокарту. Каждый держит свою часть весов и выполняет вычисления.

Процессы обмениваются сообщениями через ZeroMQ. Отсюда практическое следствие, о котором [предупреждает документация](https://docs.vllm.ai/en/latest/configuration/optimization/): каждому процессу нужно своё физическое ядро процессора. На сервере с четырьмя видеокартами это минимум шесть ядер. Если ядер меньше, видеокарты простаивают в ожидании планировщика, особенно в виртуальных машинах.

Планировщик не делит работу на фазы prefill и decode. У него есть бюджет токенов на один шаг (`max_num_batched_tokens`), и он заполняет его так:

1. Сначала берёт по одному токену у каждого запроса, который уже пишет ответ.
2. Оставшийся бюджет отдаёт промптам новых запросов. Длинный промпт режется на куски и обрабатывается за несколько шагов — это называется chunked prefill.

Так длинный промпт нового пользователя не останавливает генерацию у остальных. Бюджет по умолчанию зависит от видеокарты: для сервера на картах меньше 70 ГБ — 2048 токенов, на H100 и H200 — 8192, на B200 и B300 — 16 384. Меньший бюджет даёт более ровные паузы между токенами, больший — более быстрый первый токен.

Если KV-кэша на всех не хватает, планировщик вытесняет последний принятый запрос: освобождает его память, а когда место появится, считает его промпт заново.

### PagedAttention: KV-кэш страницами

До vLLM серверы выделяли каждому запросу непрерывный кусок памяти под KV-кэш на максимально возможную длину ответа. Запрос мог написать 50 токенов, а память была зарезервирована под 2000. Авторы vLLM измерили, что так впустую пропадало 60–80% памяти под KV-кэш.

PagedAttention решает это так же, как операционная система решает проблему с оперативной памятью, — страницами. Сравнение из статьи авторов: блоки — это страницы, токены — байты, запросы — процессы.

1. Память под KV-кэш заранее нарезана на блоки фиксированного размера, например по 16 токенов.
2. У каждого запроса есть таблица блоков — какие физические блоки хранят его токены и в каком порядке.
3. Блоки выдаются по мере того, как ответ растёт. Впустую пропадает не больше одного недозаполненного блока на запрос; по замерам авторов — меньше 4% памяти.

В ту же видеокарту помещается в несколько раз больше одновременных запросов, и пропускная способность растёт вместе с ними.

Второе следствие — общие блоки. Если два запроса начинаются одинаково — общий системный промпт, одна история диалога, несколько вариантов ответа на один вопрос, — их таблицы ссылаются на одни и те же физические блоки. KV-кэш для общего начала хранится и считается один раз.

Идея стала стандартом: страничный KV-кэш есть в SGLang, в TensorRT-LLM и даже в плагине vLLM для Mac. А собственное ядро PagedAttention, с которого vLLM начинался, в июле 2026 года из кода удалили (версия 0.25.0). Страничный кэш теперь читают общие ядра внимания — FlashAttention, FlashInfer, Triton и другие, — а от исходной реализации осталась схема разметки памяти.

### Кэш префиксов

vLLM считает хэш каждого заполненного блока вместе со всем, что было до него, и не выбрасывает готовые блоки после окончания запроса. Новый запрос с тем же началом получает их сразу и пропускает их prefill. Это называется автоматическим кэшированием префиксов (automatic prefix caching), и оно включено по умолчанию.

Для агентов это главный источник скорости. Агент на каждом шаге отправляет модели всю историю заново, и почти весь промпт совпадает с предыдущим. В бенчмарке AgentX, который воспроизводит реальные сессии агентов для программирования, [теоретически можно переиспользовать](https://vllm.ai/blog/2026-10-16-kimi-k3-mi355x) больше 96% промпта.

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

### CUDA-графы, torch.compile и Model Runner V2

Модели в vLLM описаны на PyTorch. При запуске vLLM готовит их к быстрой работе в два этапа:

1. **Компиляция через torch.compile.** Цепочки мелких операций сливаются в крупные ядра видеокарты, и данные реже ходят в память.
2. **Запись CUDA-графов.** CUDA-граф — это заранее записанная последовательность запусков ядер для типового размера батча. Видеокарта потом воспроизводит её целиком, без участия Python на каждом шаге. На маленьких батчах это даёт заметную часть скорости.

Плата за это — долгий старт: от десятков секунд до нескольких минут. Уровни оптимизации от `-O0` до `-O3` меняют баланс между временем старта и скоростью, а флаг `--enforce-eager` отключает и компиляцию, и графы — для быстрой отладки. Скомпилированное сохраняется на диск, в `~/.cache/vllm`, и повторные запуски идут быстрее.

На моём ноутбуке первый запуск модели на 1,7 млрд параметров занял три минуты: 13 секунд компиляции, 39 секунд записи графов, остальное — загрузка весов и подготовка. Повторный запуск — 79 секунд, из них компиляция заняла 0,16 секунды. Большую часть оставшегося времени съела загрузка весов: в Docker на Windows они читались с диска Windows 34–38 секунд, а из файловой системы WSL — за 0,4 секунды.

В 2026 году переписана сердцевина движка. [Model Runner V2](https://vllm.ai/blog/2026-03-24-mrv2) — новая реализация той части, которая готовит входы и запускает модель на видеокарте. Подготовка входов перенесена на GPU, планирование стало асинхронным: пока видеокарта считает один шаг, процессор уже планирует следующий. С версии 0.29.0 (сентябрь) Model Runner V2 работает по умолчанию для всех моделей. Параллельно идёт работа над API-сервером на Rust, который должен снять с Python приём и разбор запросов; пока он экспериментальный.

Для быстрых перезапусков появились демон `vllm preload`, который держит уже квантованные веса в памяти видеокарты, пока движок перезапускается, и снимки уже инициализированного движка — пока экспериментально.

### Спекулятивное декодирование

На фазе decode видеокарта недогружена: она ждёт память. Спекулятивное декодирование использует этот простой.

1. Маленький быстрый «черновик» угадывает несколько следующих токенов.
2. Большая модель проверяет все угаданные токены за один проход — так же, как читает промпт.
3. Совпавшие токены принимаются; на первом несовпавшем черновик отбрасывается, и вместо него берётся токен большой модели.

Ответ получается таким же, какой большая модель дала бы сама, а за один шаг выходит несколько токенов. Способы угадывать в vLLM такие:

- **EAGLE** (EAGLE-3, EAGLE 3.1, P-EAGLE) — маленькая надстройка, которая предсказывает токены по внутренним состояниям самой модели;
- **MTP** (multi-token prediction) — встроенные в модель головы, которые сразу предсказывают несколько токенов вперёд; они есть у DeepSeek, Qwen3.5, Gemma 4 и других;
- **черновая модель** — отдельная маленькая модель того же семейства;
- **n-gram и suffix decoding** — без дополнительной модели: продолжение ищется в самом промпте и в прошлых ответах. Хорошо работает, когда модель правит код или пересказывает документ;
- **DFlash и DSpark** — черновики на основе блочной диффузии, которые предлагают целый блок токенов за один проход. Появились в 2026 году.

[Документация](https://docs.vllm.ai/en/latest/features/speculative_decoding/) честно предупреждает: выигрыш велик при малой нагрузке и меньше при большой. Когда видеокарта и так занята большим батчем, проверка чужих догадок перестаёт быть бесплатной. Поэтому появились адаптивные режимы, которые сами решают, сколько токенов угадывать. Как велик выигрыш, видно на LiteRT-LM в моём замере ниже: MTP ускорил генерацию Gemma 4 E2B на видеокарте ноутбука в 1,7 раза.

### Квантование

vLLM понимает почти все серверные форматы: FP8, NVFP4, MXFP4 и MXFP8, INT8 и INT4, чекпойнты GPTQ и AWQ, форматы compressed-tensors, NVIDIA ModelOpt, AMD Quark и TorchAO. GGUF поддерживается экспериментально, а bitsandbytes с версии 0.28.0 вынесен в отдельный плагин. Свои модели под vLLM предлагается квантовать библиотекой [LLM Compressor](https://github.com/vllm-project/llm-compressor) от тех же разработчиков.

Отдельно квантуется KV-кэш. FP8 вдвое уменьшает его, а значит, вдвое увеличивает число одновременных диалогов. В 2026 году добавились 4-битные варианты: NVFP4 для NVIDIA и свои форматы для AMD. Что именно ускорится, зависит от поколения видеокарты: FP8 считается аппаратно начиная с NVIDIA Ada и Hopper, FP4 — на Blackwell и AMD MI350.

### API и возможности

Сервер vLLM повторяет API OpenAI: completions, chat completions, Responses API, эмбеддинги, распознавание и перевод речи. Кроме того, он понимает Anthropic Messages API — в документации есть [инструкция](https://docs.vllm.ai/en/latest/serving/integrations/claude_code/), как подключить к нему Claude Code, — и gRPC.

Возможности, которые нужны в продакшене:

- **структурированный вывод** — ответ строго по JSON-схеме или грамматике, через библиотеки xgrammar или guidance;
- **вызовы инструментов и рассуждения** — для десятков семейств моделей есть разборщики, которые превращают текст модели в вызовы функций и отделяют рассуждения от ответа;
- **много LoRA-адаптеров** поверх одной базовой модели в одном батче — так одна видеокарта обслуживает десятки дообученных вариантов;
- **мультимодальность** — картинки, видео и звук на входе;
- **эмбеддинги и переранжирование** — модели для поиска работают на том же сервере;
- **режим сна** — веса временно выгружаются из видеокарты, чтобы быстро переключиться на другую модель.

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

### Масштабирование: от одной видеокарты до стойки

Когда модель не помещается в одну видеокарту или одной карты не хватает по скорости, vLLM раскладывает работу на несколько. Способов пять, и их комбинируют.

- **Тензорный параллелизм** (tensor parallelism, TP) режет каждую матрицу весов на части. Каждая видеокарта считает свою часть каждого слоя, и после каждого слоя карты обмениваются результатами. Нужна очень быстрая связь между картами — NVLink внутри одного сервера. Это самый частый способ запустить модель на 70 млрд параметров на нескольких картах.
- **Конвейерный параллелизм** (pipeline parallelism, PP) раздаёт картам целые слои: первая считает слои с 1-го по 20-й, вторая — с 21-го по 40-й. Обмен идёт только на границах, поэтому так можно растянуть модель на несколько серверов с более медленной сетью. Цена — карты ждут друг друга.
- **Параллелизм данных** (data parallelism, DP) — несколько копий модели, каждая обслуживает свои запросы. Растёт пропускная способность, а не допустимый размер модели.
- **Экспертный параллелизм** (expert parallelism, EP) — для моделей Mixture of Experts (MoE). В каждом слое такой модели десятки или сотни «экспертов», и на каждый токен включаются немногие из них. Эксперты раскладываются по картам, а токены пересылаются к нужным. Сочетание DP для слоёв внимания и EP для экспертов на десятках карт называют wide-EP; на нём держатся рекорды для DeepSeek, Kimi и похожих моделей.
- **Контекстный параллелизм** (context parallelism, CP) режет между картами один очень длинный запрос на сотни тысяч токенов. Для prefill и decode он устроен по-разному.

Несколько серверов vLLM по умолчанию объединяет через Ray, но умеет и без него. KV-кэш между машинами передают подключаемые коннекторы: NIXL от NVIDIA, Mooncake, LMCache, MoRI-IO от AMD.

**Разделение prefill и decode** (disaggregated serving, P/D). Prefill нагружает вычисления, decode — память. Когда обе фазы идут на одних и тех же картах, длинный промпт нового пользователя на мгновение тормозит генерацию у всех остальных. Решение — разные экземпляры vLLM: одни только читают промпты, другие только генерируют ответы, а KV-кэш передаётся между ними по сети. Каждую группу можно настроить и масштабировать отдельно. [Документация vLLM](https://docs.vllm.ai/en/latest/features/disagg_prefill/) подчёркивает: это способ управлять задержками, особенно самыми долгими, а не поднять пропускную способность, и функция по-прежнему помечена как экспериментальная. С конца 2025 года так же отделяют кодировщики картинок у мультимодальных моделей, а в 2026-м появился плагин, который отделяет даже слои внимания от слоёв экспертов.

**Многоуровневый KV-кэш.** KV-кэш, который не помещается в видеокарту, можно выгружать в оперативную память, на диск и в объектное хранилище, а потом подгружать вместо того, чтобы считать заново. Для агентов с длинной историей это прямая экономия на prefill.

**Эластичный экспертный параллелизм** — видеокарты можно добавлять в MoE-развёртывание и убирать из него без перезапуска сервера.

Насколько это всё быстро, видно по цифрам разработчиков — это их собственные замеры, а не независимые:

- **DeepSeek на H200.** С wide-EP и разделением prefill и decode — [2200 токенов в секунду на видеокарту](https://vllm.ai/blog/2025-12-17-large-scale-serving) в многоузловом развёртывании, декабрь 2025 года.
- **Kimi K3 на AMD против NVIDIA.** На восьми AMD MI355X — [7567 токенов в секунду на видеокарту](https://vllm.ai/blog/2026-10-16-kimi-k3-mi355x) против 6083 на восьми NVIDIA B300 при одинаковой скорости 50 токенов в секунду для каждого пользователя. Пост написали AMD и Embedded LLM; цифры взяты из бенчмарка InferenceX.
- **DeepSeek-V4.1-Flash.** На GB200 скорость decode — [в пределах 6%](https://vllm.ai/blog/2026-10-23-deepseek-v41-flash-pd-wide-ep) от собственного движка DeepSeek, DeepInfer, октябрь 2026 года.

Как раздавать запросы между десятками экземпляров vLLM, рассказано в разделе о [слое над движками для кластеров](#Слой-над-движками-для-кластеров).

### Железо

| Платформа | Как поддерживается | Что важно знать |
|---|---|---|
| NVIDIA | в основном коде | видеокарты с compute capability 7.5 и выше, то есть от T4 и RTX 20xx; V100 больше не поддерживается. С версии 0.33.0 сборки только под CUDA 13.0 |
| AMD | в основном коде, через ROCm | Instinct MI200, MI300, MI350; Radeon RX 7900 и RX 9000; Ryzen AI MAX и AI 300. Образ по умолчанию собран на ROCm 10.0 |
| Intel | в основном коде | видеокарты Arc и Data Center GPU; ускорители Gaudi — через плагин vllm-gaudi |
| Google TPU | плагины tpu-inference и vllm-torchtpu | второй появился в октябре 2026 года; для него рекомендован TPU v7x Ironwood, а v5e, v5p и v6e поддерживаются экспериментально |
| AWS Trainium и Inferentia | плагин vllm-neuron | |
| Huawei Ascend | плагин vllm-ascend | |
| Apple Silicon | плагин [vllm-metal](https://vllm.ai/blog/2026-09-22-vllm-metal-v0-28-0) | работает поверх MLX, ставится через Homebrew |
| Процессоры | в основном коде | x86, ARM, PowerPC, IBM Z; для экспериментов и маленьких моделей |
| Другие ускорители | плагины | IBM Spyre, Rebellions, MetaX, Iluvatar, Cambricon, Baidu Kunlun, Tenstorrent |

Плагины живут в отдельных репозиториях и выходят по своему графику, обычно отставая от основного vLLM на несколько релизов.

Windows vLLM [не поддерживает](https://docs.vllm.ai/en/latest/getting_started/installation/gpu/) — только через WSL2 или Docker. Именно так он и запущен на моём ноутбуке.

### Слабые места

- **Только Linux.** На Windows — WSL2 или Docker. Образ с CUDA весит 35 ГБ.
- **Долгий старт.** Загрузка весов, компиляция, запись CUDA-графов — минуты, а не секунды.
- **Забирает видеопамять заранее.** По умолчанию vLLM занимает 92% памяти видеокарты, рассчитывая, что она принадлежит ему одному. На моём ноутбуке около гигабайта занимали браузер и рабочий стол, и vLLM просто отказался запускаться: свободной памяти оказалось меньше 92%. На общей видеокарте долю приходится задавать вручную флагом `--gpu-memory-utilization`.
- **Одному пользователю не быстрее.** На домашней видеокарте для одного потока llama.cpp так же быстр, а сжатые модели GGUF меньше и ещё быстрее.
- **Быстрые перемены.** Релиз каждые две недели меняет зависимости и убирает старое: в последнем релизе, например, исчезли сборки под CUDA 12.9 и два способа спекулятивного декодирования.
- **Большие развёртывания требуют инженерной работы.** Подобрать сочетание TP, DP и EP, бюджеты токенов, коннекторы KV-кэша — отдельная задача.

### Как запустить

На Linux с видеокартой NVIDIA и Python от 3.11 до 3.14 vLLM ставится одной командой. Вторая скачивает готовые ядра FlashInfer, чтобы движок не собирал их при первом запуске. Модель с Hugging Face скачивается при первом запуске сервера. Флаг `--gpu-memory-utilization 0.6` нужен, если видеокарту занимают и другие программы; на выделенном сервере его можно убрать:

```bash
uv pip install vllm
vllm download-kernels
vllm serve Qwen/Qwen3-1.7B --max-model-len 8192 --gpu-memory-utilization 0.6
```

То же самое в Docker. Флаг `--ipc=host` нужен потому, что процессы vLLM передают друг другу данные через общую память:

```bash
docker run --gpus all -p 8000:8000 --ipc=host \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:v0.33.0 Qwen/Qwen3-1.7B \
  --gpu-memory-utilization 0.6 --max-model-len 8192
```

Сервер отвечает по API OpenAI на порту 8000:

```bash
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "Qwen/Qwen3-1.7B", "messages": [{"role": "user", "content": "What is a KV cache? Answer in two sentences."}]}'
```

vLLM можно использовать и без сервера, прямо из Python. Это удобно для пакетной обработки: движок сам соберёт запросы в батчи и загрузит видеокарту целиком. Обратите внимание на проверку `if __name__ == "__main__"` в конце: без неё скрипт падает при старте движка.

```python
from vllm import LLM, SamplingParams


def main():
    # Модель скачивается с Hugging Face при первом запуске
    llm = LLM(model="Qwen/Qwen3-1.7B", max_model_len=4096, gpu_memory_utilization=0.6)
    params = SamplingParams(temperature=0.7, max_tokens=512)

    # Сто вопросов уйдут в модель общими батчами, а не по одному
    conversations = [
        [{"role": "user", "content": f"Give one fact about the number {n}."}]
        for n in range(100)
    ]
    # Qwen3 по умолчанию сначала рассуждает; здесь рассуждения выключены
    outputs = llm.chat(conversations, params, chat_template_kwargs={"enable_thinking": False})

    for output in outputs[:3]:
        print(output.outputs[0].text)


# vLLM запускает движок в отдельном процессе, и тот импортирует этот файл заново.
# Без проверки он снова дошёл бы до создания LLM и упал бы с ошибкой
if __name__ == "__main__":
    main()
```

На моём ноутбуке сто таких запросов обработались за 5 секунд — около 1950 токенов ответа в секунду. Один запрос за раз та же видеокарта генерирует со скоростью около 117 токенов в секунду: так выглядит батчинг в действии.

## SGLang

[SGLang](https://github.com/sgl-project/sglang) — главный соперник vLLM и по задачам, и по возможностям. Его делает LMSYS — некоммерческая организация исследователей, известная рейтингом Chatbot Arena. В 2026 году вокруг проекта появилась компания RadixArk, по сообщениям [TechCrunch](https://techcrunch.com/2026/01/21/sources-project-sglang-spins-out-as-radixark-with-400m-valuation-as-inference-market-explodes/) — с оценкой в 400 млн долларов. Лицензия Apache 2.0, версия 0.5.23 от 2 ноября, около 39 тысяч звёзд на GitHub.

Чем он отличается от vLLM:

- **RadixAttention.** Кэш префиксов хранится в radix-дереве — дереве, где каждая ветка соответствует общему началу нескольких запросов. Движок сам находит самое длинное совпадение среди всего, что лежит в кэше, и переиспользует его. В vLLM похожий результат даёт хэширование блоков. Авторы SGLang с самого начала делали упор на программы из многих вызовов модели с общими префиксами — агентов и ветвящиеся диалоги.
- **Планировщик без простоев.** Процессор готовит следующий шаг, пока видеокарта выполняет текущий, и видеокарта не ждёт Python. В vLLM то же делает асинхронное планирование.
- **Маршрутизатор с учётом кэша.** SGLang Model Gateway на Rust раскидывает запросы по экземплярам так, чтобы запрос попал туда, где его префикс уже посчитан.
- **Крупные MoE-развёртывания.** Команда SGLang публиковала подробные открытые рецепты для DeepSeek на десятках видеокарт: на 96 H100 с разделением prefill и decode и wide-EP, позже — на стойке GB200 NVL72. На GB200 они получили [26 тысяч входных и 13 тысяч выходных токенов в секунду на видеокарту](https://www.lmsys.org/blog/2025-09-25-gb200-part-2) для DeepSeek-R1. Это их собственные замеры 2025 года, более свежих я не нашёл.

Железо: NVIDIA от Ampere до Blackwell, включая RTX и Jetson; AMD MI300X–MI355X; Intel Arc и Xeon; Google TPU; Huawei Ascend; Apple Silicon; китайские Moore Threads. На практике SGLang и vLLM сейчас догоняют друг друга каждые две недели, и выбор между ними — вопрос конкретной модели и железа. Например, в MLPerf Inference 6.1 компания Crusoe [прогоняла DeepSeek-R1](https://www.crusoe.ai/resources/blog/serving-5-75-million-tokens-per-second-crusoes-mlperf-inference-v6-1-results-on-amd-mi355x) на 512 видеокартах AMD MI355X именно на SGLang. Перед выбором стоит прогнать оба на своей нагрузке.

## TensorRT-LLM

[TensorRT-LLM](https://github.com/NVIDIA/TensorRT-LLM) — движок самой NVIDIA, и работает он только на её видеокартах. Зато на них он часто быстрее всех: NVIDIA выпускает в нём ядра под новое железо раньше, чем они доходят до открытых движков, — FP4 на Blackwell, связь между 72 видеокартами стойки NVL72, разделение prefill и decode. Лицензия Apache 2.0. Стабильная версия — 1.2.1 от апреля, ветка 1.4 выходит предрелизами.

Раньше работа с ним начиналась с долгой «сборки движка»: модель заранее компилировалась под конкретную видеокарту и конкретные размеры батча. В версии 1.2 этот путь удалили, и теперь TensorRT-LLM работает поверх PyTorch, как vLLM и SGLang. Сервер запускается командой `trtllm-serve` и говорит по API OpenAI. Внутри — непрерывный батчинг, страничный KV-кэш, спекулятивное декодирование EAGLE-3 и MTP, wide-EP.

Минусы — только NVIDIA, частые ломающие изменения, меньше поддерживаемых моделей, чем у vLLM, и долгий первый запуск: например, ядра для DeepSeek-V4 на Blackwell компилируются 5–10 минут. Обычно TensorRT-LLM выбирают те, кто выжимает последний процент из большого парка NVIDIA и готов за это платить временем инженеров. Для кластеров NVIDIA выпускает к нему слой Dynamo — о нём в [разделе о слое над движками](#NVIDIA-Dynamo).

## Другие серверные движки

- **[LMDeploy](https://github.com/InternLM/lmdeploy)** из Шанхайской лаборатории ИИ (авторы моделей InternLM). Два движка — TurboMind на C++ и CUDA и движок на PyTorch; работает на NVIDIA и Huawei Ascend. Версия 0.18.0 от сентября.
- **[KTransformers](https://github.com/kvcache-ai/ktransformers)** — для огромных MoE-моделей на одном сервере с небольшим числом видеокарт. Слои внимания считаются на GPU, а эксперты — на процессоре с инструкциями Intel AMX и AVX-512, и модель на сотни миллиардов параметров помещается в оперативную память сервера. Интегрирован с SGLang. Версия 0.7.2.
- **OpenVINO Model Server** от Intel — сервер для процессоров, встроенных и дискретных видеокарт и NPU Intel.
- **xLLM** от JD и **MindIE** от Huawei — движки для китайских ускорителей, прежде всего Huawei Ascend. Возможности MindIE постепенно переезжают в плагин vllm-ascend.

## Бенчмарки: каким цифрам верить

Сравнить движки «вообще» нельзя: результат зависит от модели, железа, длины запросов, числа пользователей, обещанных задержек и того, сколько времени инженеры потратили на настройку. Есть два источника, которым можно доверять больше, чем остальным.

**[InferenceX](https://github.com/SemiAnalysisAI/InferenceX)** (раньше назывался InferenceMAX) от аналитической компании SemiAnalysis. Каждую ночь он прогоняет vLLM, SGLang и TensorRT-LLM (в том числе под Dynamo) на видеокартах NVIDIA от H100 до Vera Rubin NVL72, на AMD MI300X, MI325X и MI355X, на TPU v7x. Результаты — кривые «пропускная способность на видеокарту против скорости для каждого пользователя» и цена миллиона токенов. С августа добавлен тест AgentX — реальные сессии агентов для программирования, с длинными историями и общими префиксами.

Выводы февральского выпуска InferenceX v2 на DeepSeek-R1 такие. В конфигурациях с разделением prefill и decode, wide-EP и FP4 впереди NVIDIA с SGLang и TensorRT-LLM. AMD MI355X с SGLang не уступает NVIDIA на одном сервере в FP8. А на FP4 с разделением фаз AMD отстаёт: ядра и библиотеки связи для ROCm пока сырые. Сами авторы оговаривают ограничения: в v2 промпты состояли из случайных токенов, а кэш префиксов был выключен, то есть самая важная для агентов оптимизация в тесте не участвовала.

**MLPerf Inference** от консорциума MLCommons — раунды раз в полгода с проверкой результатов другими участниками. В раунде 6.0 в апреле NVIDIA подавала результаты на TensorRT-LLM и Dynamo; в раунде 6.1 в сентябре Crusoe прогнала DeepSeek-R1 на 512 видеокартах AMD MI355X на SGLang. MLPerf хорошо показывает потолок железа, но настраивают его команды производителей неделями, и ваша конфигурация так быстро работать не будет.

Остальные цифры стоит читать с тремя вопросами:

1. **Кто мерил?** Почти все публикации — от разработчиков движков или производителей железа. Даже честный замер производителя показывает конфигурацию, в которую вложено больше всего труда.
2. **Что считали?** Например, в одном из октябрьских постов vLLM пропускная способность на тесте AgentX — 954 тысячи токенов в секунду на видеокарту. Но в эту цифру входят и закэшированные входные токены, которые почти ничего не стоят, а агентские сессии почти целиком из них и состоят. Цифра верная, но сравнивать её с «токенами ответа в секунду» нельзя.
3. **Какая нагрузка?** Сравнения на одной H100 из блогов хостинг-компаний противоречат друг другу на десятки процентов, а местами повторяют одни и те же цифры.

Надёжнее всего замерить самому на своей модели и своём профиле запросов. Для этого есть `vllm bench serve` — он умеет нагружать любой сервер с API OpenAI, не только vLLM, — и [GuideLLM](https://github.com/vllm-project/guidellm). Так я и сделал.

## Замер на ноутбуке: vLLM и llama.cpp под нагрузкой

Вопрос, который задают чаще всего: если llama.cpp так же быстр, зачем нужен vLLM? Я прогнал оба на одной видеокарте с одной и той же моделью.

Условия замера:

- **Железо** — RTX 5070 Ti Laptop с 12 ГБ, Windows 11. Около гигабайта видеопамяти занято рабочим столом и браузером.
- **Модель** — Qwen3-1.7B в BF16, без квантования: в обоих движках одни и те же веса. Для llama.cpp — файл GGUF в BF16.
- **vLLM 0.33.0** — в Docker, потому что под Windows его нет. Память под KV-кэш — ровно 16 384 токена, до 16 запросов одновременно.
- **llama.cpp b12233** — обычная сборка для Windows с CUDA 13: `llama-server` с 16 слотами и общим KV-кэшем на те же 16 384 токена.
- **Нагрузка** — один и тот же клиент `vllm bench serve` для обоих: промпт из 512 случайных токенов, ответ ровно 256 токенов, от 1 до 16 одновременных запросов. Для каждого уровня — новые промпты, чтобы кэш префиксов не подыгрывал.

Вот команда, которой нагружался сервер; она работает с любым сервером, совместимым с API OpenAI:

```bash
vllm bench serve --backend openai --base-url http://localhost:8000 \
  --endpoint /v1/completions --model Qwen/Qwen3-1.7B \
  --dataset-name random --random-input-len 512 --random-output-len 256 \
  --num-prompts 96 --max-concurrency 16 --ignore-eos --seed 5016
```

Результаты — суммарная скорость генерации, медианное время до первого токена и медианная пауза между токенами:

| Одновременных запросов | vLLM, токенов/с | vLLM, TTFT | vLLM, TPOT | llama.cpp, токенов/с | llama.cpp, TTFT | llama.cpp, TPOT |
|---|---|---|---|---|---|---|
| 1 | 116 | 41 мс | 8,4 мс | 120 | 49 мс | 8,1 мс |
| 2 | 240 | 60 мс | 8,1 мс | 223 | 91 мс | 8,7 мс |
| 4 | 460 | 146 мс | 8,1 мс | 372 | 178 мс | 9,8 мс |
| 8 | 717 | 187 мс | 10,4 мс | 656 | 244 мс | 11,2 мс |
| 16 | 1167 | 321 мс | 12,5 мс | 824 | 317 мс | 17,6 мс |

Что из этого следует:

1. **Для одного пользователя разницы нет.** 116 и 120 токенов в секунду — это обе программы упираются в одну и ту же память видеокарты.
2. **С ростом нагрузки vLLM уходит вперёд.** На 16 одновременных запросах он выдаёт в 1,4 раза больше токенов, а пауза между токенами у каждого пользователя растёт медленнее: с 8,4 до 12,5 мс против 8,1 → 17,6 мс у llama.cpp. Шаг сразу для многих запросов — главный сценарий vLLM, и он на нём специализируется; для llama.cpp это сценарий второстепенный.
3. **Это не предел.** На моём ноутбуке память ограничила тест 16 запросами. На серверной видеокарте с 80 ГБ vLLM может держать сотни одновременных диалогов, и чем больше батч, тем важнее эффективность шага.

Две находки по ходу дела, о которых стоит знать.

**У llama-server есть настройка, которая мешает под нагрузкой.** В свежих версиях он по умолчанию сохраняет каждый закончившийся диалог в оперативную память (параметр `--cache-ram`, по умолчанию 8 ГиБ), чтобы мгновенно продолжить его, если пользователь вернётся. Сохранение происходит в тот момент, когда приходит новый запрос, — и новый запрос ждёт. В моём первом прогоне с настройками по умолчанию время до первого токена росло с числом пользователей до полусекунды, а в одном прогоне на 8 пользователях часть запросов прождала первый токен больше минуты. В Docker это было ещё заметнее — до 3,5 секунды. С флагом `-cram 0` всё стало ровно; таблица выше — с ним. Если у вас много разных пользователей, а не один, который возвращается к своему чату, этот кэш стоит выключить.

**Кэш префиксов искажает повторные замеры.** Мой первый прогон vLLM использовал одни и те же промпты на всех уровнях нагрузки, и время до первого токена при двух пользователях оказалось вдвое меньше, чем при одном: vLLM просто доставал из кэша то, что уже посчитал. При замерах меняйте `--seed` или перезапускайте сервер.

## llama.cpp

[llama.cpp](https://github.com/ggml-org/llama.cpp) — движок на C и C++, с которого в 2023 году начался запуск языковых моделей на обычных компьютерах. Георгий Герганов написал его, чтобы запустить LLaMA на MacBook, и с тех пор это самый портируемый движок: он работает на Windows, Linux, macOS, Android и iOS, на процессоре без видеокарты и почти на любой видеокарте. Под капотом — его же библиотека тензорных вычислений ggml. На llama.cpp построены Ollama, LM Studio, Jan, LocalAI, llamafile и десятки других программ.

Лицензия MIT, около 134 тысяч звёзд на GitHub. В феврале 2026 года команда ggml.ai [перешла в Hugging Face](https://huggingface.co/blog/ggml-joins-hf) и продолжает работать над проектом; сам проект остаётся открытым и общественным. Фиксированных релизов нет: каждый влитый pull request становится новой сборкой, и в день их выходит больше десятка. На 9 ноября актуальна сборка b12233.

### Железо

Главная сила llama.cpp — бэкенды. Одна и та же модель запускается на:

| Где | Бэкенд |
|---|---|
| процессоры x86 | AVX2, AVX-512, Intel AMX; для серверов AMD EPYC — ZenDNN |
| процессоры ARM | NEON, SVE, библиотека Arm KleidiAI; Apple Silicon |
| видеокарты NVIDIA | CUDA |
| видеокарты AMD | HIP (ROCm) или Vulkan |
| видеокарты Intel | SYCL или Vulkan; бэкенд OpenVINO в разработке |
| Apple Silicon | Metal |
| любая видеокарта с Vulkan | Vulkan — работает и на картах, которые не поддерживает больше ничего |
| телефоны и ноутбуки на Snapdragon | OpenCL для видеоядра Adreno и Hexagon для NPU |
| экзотика | Huawei Ascend (CANN), Moore Threads (MUSA), IBM Z (zDNN), браузер (WebGPU) |

Готовые сборки выкладываются вместе с каждой версией: для Windows — под процессор, CUDA 12 и 13, Vulkan, SYCL, ROCm, OpenVINO и Adreno; для Linux, macOS и Android — свои наборы. Есть образы Docker под CUDA, ROCm, Vulkan, Intel и другие бэкенды, а также пакеты: `winget install llama.cpp` на Windows и `brew install llama.cpp` на macOS.

Скорость на разном железе энтузиасты собирают в открытых обсуждениях на GitHub — по одной и той же модели Llama 2 7B в 4-битном формате Q4_0. Несколько цифр генерации из этих таблиц: RTX 5090 — 290 токенов в секунду, AMD MI300X — 233, Radeon RX 7900 XTX — 167, Apple M5 Max — 120. Цифры собраны на разных сборках llama.cpp, поэтому сравнивать их между собой можно только примерно.

### GGUF и квантование

Модели для llama.cpp хранятся в формате GGUF: в одном файле лежат веса, токенизатор, шаблон чата и описание архитектуры. Популярные открытые модели появляются на Hugging Face в GGUF обычно в первые дни после выхода, сразу в десятке вариантов квантования.

Варианты отличаются числом бит на вес. Вот сколько весит Llama 3.1 8B в разных форматах, по [таблице из репозитория](https://github.com/ggml-org/llama.cpp/tree/master/tools/quantize):

| Формат | Бит на вес | Размер |
|---|---|---|
| F16 (без квантования) | 16 | 15,0 ГиБ |
| Q8_0 | 8,5 | 7,95 ГиБ |
| Q6_K | 6,6 | 6,14 ГиБ |
| Q4_K_M | 4,9 | 4,58 ГиБ |
| IQ2_M | 2,9 | 2,74 ГиБ |

Q4_K_M — разумный выбор по умолчанию: модель в три раза меньше, а потеря качества обычно небольшая. Q8_0 почти неотличим от оригинала. Форматы IQ с двумя-тремя битами нужны, когда иначе модель вообще не помещается; качество на них падает уже заметно. Для самых аккуратных результатов квантуют с матрицей важности (imatrix): llama.cpp прогоняет через модель образец текста и бережнее сжимает веса, которые сильнее влияют на ответ. В 2026 году добавились 4-битные форматы с плавающей точкой: MXFP4, в котором выпущены модели gpt-oss, и NVFP4 — формат NVIDIA, который видеокарты Blackwell считают аппаратно.

### llama-server

`llama-server` — сервер, который превращает llama.cpp в замену облачному API. В свежих сборках к нему добавилась короткая форма: `llama serve`. Что он умеет:

- **API.** OpenAI — chat completions, completions, Responses API, эмбеддинги; Anthropic Messages API; переранжирование; потоковое распознавание речи через WebSocket. Встроен веб-интерфейс для чата.
- **Несколько пользователей.** Параметр `-np` задаёт число слотов — одновременных диалогов. Непрерывный батчинг включён по умолчанию. С флагом `-kvu` слоты делят общий пул KV-кэша; если число слотов не задано, он включён сам.
- **Кэш промптов.** Сервер переиспользует посчитанный KV-кэш, если новый запрос начинается так же, как предыдущий, и хранит закончившиеся диалоги в оперативной памяти. Под нагрузкой из разных пользователей последнее мешает — это видно в [замере выше](#Замер-на-ноутбуке-vLLM-и-llamacpp-под-нагрузкой).
- **Спекулятивное декодирование.** Черновая модель, EAGLE-3, MTP с мая 2026 года, DFlash, DSpark и поиск продолжения в уже написанном тексте (n-gram).
- **Картинки, звук и видео** на входе, если у модели есть мультимодальный проектор.
- **Инструменты.** Вызовы функций через шаблоны чата, встроенный клиент MCP, управление рассуждениями: включить, выключить, ограничить бюджет.
- **Несколько моделей.** В режиме маршрутизатора сервер сам загружает модель из папки при первом обращении к ней и выгружает лишние, когда память кончается.

Скачать модель с Hugging Face и запустить сервер — одна команда; суффикс после двоеточия выбирает вариант квантования:

```bash
llama-server -hf unsloth/Qwen3-1.7B-GGUF:Q4_K_M --port 8080
```

Для сервера на несколько пользователей нужно больше флагов. Вот конфигурация из моего замера: все слои в видеокарте (`-ngl all`), FlashAttention (`-fa on`), 16 слотов (`-np 16`) с общим пулом KV-кэша на 16 384 токена (`-c 16384 -kvu`) и без сохранения диалогов в оперативную память (`-cram 0`):

```bash
llama-server -m Qwen3-1.7B-BF16.gguf -ngl all -fa on -np 16 -c 16384 -kvu -cram 0
```

Без `-kvu` контекст делится между слотами поровну, и каждому достанется только 1024 токена.

### Модель больше видеопамяти

Здесь llama.cpp вне конкуренции. Параметр `-ngl` задаёт, сколько слоёв модели положить в видеокарту; остальные считает процессор из оперативной памяти. По умолчанию llama.cpp сам подбирает столько слоёв, сколько поместится. Модель, которая не влезает в видеокарту, запускается, просто медленнее.

Для моделей MoE есть приём получше. В таких моделях на каждый токен работает лишь небольшая часть экспертов, а слои внимания работают всегда. Если оставить в видеокарте внимание и общие части, а экспертов вынести в оперативную память, процессору достаётся немного работы на токен, и скорость падает не так сильно. За это отвечают флаги `--cpu-moe` (все эксперты в оперативную память) и `--n-cpu-moe N` (эксперты первых N слоёв).

Пример с моего ноутбука. Qwen3.6-35B-A3B — MoE-модель на 35 млрд параметров, из которых на каждый токен работают около 3 млрд. В квантовании Q4_K_M она весит 20,6 ГиБ — почти вдвое больше видеопамяти. Вот как её запустить, оставив в оперативной памяти экспертов 28 слоёв:

```bash
llama-server -m Qwen3.6-35B-A3B-UD-Q4_K_M.gguf --n-cpu-moe 28 -c 16384
```

Скорость при разных способах разложить модель, по замерам `llama-bench`:

| Где лежит модель | Генерация, токенов/с | Чтение промпта, токенов/с |
|---|---|---|
| вся в оперативной памяти (`-ngl 0`) | 13,5 | 367 |
| все эксперты в оперативной памяти, остальное в видеокарте (`--cpu-moe`) | 32,7 | 139 |
| эксперты 32 слоёв в оперативной памяти (`--n-cpu-moe 32`) | 42,5 | 183 |
| эксперты 28 слоёв в оперативной памяти (`--n-cpu-moe 28`) | 49,4 | 233 |

Генерация почти 50 токенов в секунду у модели на 35 млрд параметров на ноутбуке — это быстрее, чем человек читает. Слабое место — чтение промпта: 140–230 токенов в секунду, и документ на 10 тысяч токенов модель будет читать около минуты. Первый запрос к серверу тоже медленнее остальных — 31 токен в секунду против 44–49: веса подтягиваются с диска при первом обращении. Подбирать `--n-cpu-moe` приходится вручную: чем меньше число, тем больше экспертов в видеокарте и тем быстрее, пока хватает памяти.

### Несколько видеокарт и несколько машин

На нескольких видеокартах одного компьютера llama.cpp по умолчанию раздаёт им слои по очереди. Это позволяет запустить большую модель, но не ускоряет её: карты работают по очереди. В апреле 2026 года появился [экспериментальный тензорный параллелизм](https://github.com/ggml-org/llama.cpp/pull/19378) (`-sm tensor`), при котором карты считают каждый слой вместе. В замерах автора на двух RTX 4090 Gemma 4 31B стала генерировать 59 токенов в секунду вместо 44, а MoE-модель Gemma 4 26B, наоборот, замедлилась. Ускорение пока есть только на CUDA, и автор прямо пишет, что для продакшена функция не готова.

Несколько машин объединяются через бэкенд RPC: главный узел раздаёт другим части модели по сети. Кроме TCP, теперь поддерживается передача через RDMA. Документация называет RPC экспериментом и предупреждает, что запускать его в открытой сети небезопасно.

### Чего llama.cpp не умеет

- **Сотни пользователей на одной видеокарте.** Слоты и непрерывный батчинг есть, но под нагрузкой llama.cpp заметно уступает vLLM, а серверных механизмов вроде разделения prefill и decode, маршрутизации по кэшу между экземплярами и wide-EP в нём нет.
- **Масштабирование на кластер.** Тензорный параллелизм и RPC — эксперименты.
- **Модели в день выхода — не всегда.** Новую архитектуру нужно реализовать в ggml вручную, и иногда это занимает недели, особенно для мультимодальных и гибридных моделей.

Зато для одного пользователя на своём железе llama.cpp — самый простой и часто самый быстрый вариант: один файл модели, одна программа, запуск за секунды.

## MLX

[MLX](https://github.com/ml-explore/mlx) — библиотека машинного обучения от Apple для собственных чипов, а [mlx-lm](https://github.com/ml-explore/mlx-lm) — запуск языковых моделей на ней, с сервером, совместимым с OpenAI. Её главное преимущество — общая память: у Apple Silicon процессор и видеокарта работают с одной и той же оперативной памятью, и MLX не копирует данные между ними. Mac с 128 или 512 ГБ общей памяти запускает модели, для которых на ПК понадобилось бы несколько видеокарт.

Несколько Mac можно объединить: MLX раздаёт модель по машинам, соединённым кабелями Thunderbolt 5, а начиная с macOS 26.2 передаёт данные между ними через RDMA, минуя процессор. В [замерах Apple](https://machinelearning.apple.com/research/mlx-distributed-inference) от октября 2026 года четыре Mac Studio на M5 Ultra генерировали Qwen 3.8 27B в BF16 со скоростью 51 токен в секунду против 20 на одном. У MLX есть и бэкенд CUDA для Linux, но основная платформа — Mac.

Независимых сравнений MLX с llama.cpp на одном и том же Mac с одинаковой методикой я не нашёл: блоги дают разные результаты, обычно с перевесом MLX на генерации.

На Mac можно запустить и vLLM: плагин [vllm-metal](https://vllm.ai/blog/2026-09-22-vllm-metal-v0-28-0) ставит планировщик и страничный KV-кэш vLLM поверх MLX. Он нужен, если Mac обслуживает нескольких пользователей: на пачке из восьми запросов он справился быстрее, чем mlx-lm и llama.cpp.

## Другие локальные движки

- **[ExLlamaV3](https://github.com/turboderp-org/exllamav3)** с сервером TabbyAPI — свой формат квантования EXL3 и тензорный параллелизм для домашних видеокарт; только NVIDIA.
- **[ik_llama.cpp](https://github.com/ikawrakow/ik_llama.cpp)** — ответвление llama.cpp от автора многих его форматов квантования: собственные форматы и оптимизации для процессора и CUDA.
- **[mistral.rs](https://github.com/EricLBuehler/mistral.rs)** — движок на Rust с непрерывным батчингом и страничным KV-кэшем; CUDA, Metal и процессор.
- **[OpenVINO GenAI](https://github.com/openvinotoolkit/openvino.genai)** от Intel — для процессоров, видеокарт и NPU Intel, в том числе в ноутбуках.

## LiteRT-LM

[LiteRT-LM](https://github.com/google-ai-edge/LiteRT-LM) — движок Google для запуска языковых моделей прямо на устройстве пользователя: в телефоне, ноутбуке, браузере, на Raspberry Pi. Модель работает без сети, данные никуда не уходят, а платить за токены не нужно. Сам Google называет его готовым для продакшена слоем, который запускает LLM поверх LiteRT, и использует в своих продуктах: на нём работает встроенная в Chrome модель Gemini Nano, функции Chromebook Plus и Pixel Watch. Лицензия Apache 2.0, версия 0.19.1 от 5 ноября.

### Откуда он взялся

У Google три слоя с похожими названиями, и их легко перепутать:

1. **LiteRT** — бывший TensorFlow Lite, переименованный в 2024 году. Это общий движок нейросетей на устройстве: он выполняет граф модели на процессоре, видеокарте или NPU.
2. **LiteRT-LM** — надстройка над LiteRT специально для языковых моделей. Она добавляет то, чего нет в обычном движке нейросетей: токенизатор, KV-кэш, цикл генерации, сэмплирование, историю диалога, вызовы функций.
3. **MediaPipe LLM Inference API** — старый высокоуровневый API, через который в 2024–2025 годах запускали Gemma на Android, iOS и в браузере. Теперь Google переводит разработчиков с него на LiteRT-LM, и страница его документации открывает документацию LiteRT-LM. Новый проект на нём начинать не стоит.

### Платформы и железо

| Ускоритель | Android | iOS | macOS | Windows | Linux | Raspberry Pi и IoT |
|---|---|---|---|---|---|---|
| процессор | да | да | да | да | да | да |
| видеокарта | да | да | да | да | да | — |
| NPU | да | — | — | ранний доступ | — | — |

На процессоре LiteRT-LM считает через библиотеку XNNPACK. На видеокарте — через ML Drift, собственные ядра Google: OpenCL на Android, Metal на устройствах Apple, WebGPU в браузере. На Windows, судя по журналу моего запуска, видеокарта тоже используется через WebGPU, поэтому CUDA не нужна. На NPU работает с чипами Qualcomm и MediaTek на Android, а на Windows — с NPU Intel через OpenVINO, пока в раннем доступе. Модель под NPU обычно компилируют заранее под конкретный чип, поэтому на Hugging Face для одной модели лежат отдельные файлы под разные процессоры телефонов.

Языки и API:

- **стабильные** — Kotlin (Android и обычная JVM), Python, C++ и утилита командной строки;
- **в раннем доступе** — Swift для iOS и macOS и JavaScript для браузера;
- **от сообщества** — Flutter.

### Модели и формат

Модель для LiteRT-LM — один файл `.litertlm`, в котором лежат веса, токенизатор и метаданные. Готовые модели публикует [litert-community](https://huggingface.co/litert-community) на Hugging Face: Gemma 4 E2B и E4B (E — от effective: часть весов можно не держать в быстрой памяти, и по расходу памяти модель ведёт себя как модель на 2 или 4 млрд параметров, хотя параметров у неё больше) и Gemma 4 12B, Gemma 3n, Qwen3 и Qwen3.5, Phi-4-mini, FunctionGemma для вызова функций, EmbeddingGemma 2 для эмбеддингов, модели распознавания и синтеза речи. Свою модель с Hugging Face можно сконвертировать библиотекой litert-torch.

Возможности:

- **картинки и звук** на входе у мультимодальных моделей;
- **вызовы функций** и **ответ по JSON-схеме или грамматике**; с версии 0.19 ограничение ответа считается прямо на видеокарте;
- **спекулятивное декодирование через MTP** для Gemma 4 — Google обещает до 2,2 раза быстрее на видеокартах телефонов;
- **диалоговый API** — движок сам хранит историю диалога, а KV-кэш диалога можно сохранить и восстановить, чтобы не читать историю заново;
- **LoRA-адаптеры**, **эмбеддинги**, **сервер с API OpenAI** командой `litert-lm serve`.

### Скорость

[Замеры Google](https://developers.google.com/edge/litert-lm/overview) для Gemma 4 E2B (файл 2,58 ГБ) — это цифры производителя, длина промпта в них не указана:

| Устройство | Бэкенд | Чтение промпта, токенов/с | Генерация, токенов/с | Первый токен |
|---|---|---|---|---|
| Samsung S26 Ultra | процессор | 557 | 47 | 1,8 с |
| Samsung S26 Ultra | видеокарта | 3808 | 52 | 0,3 с |
| iPhone 17 Pro | процессор | 532 | 25 | 1,9 с |
| iPhone 17 Pro | видеокарта | 2878 | 56 | 0,3 с |
| MacBook Pro M4 Max | видеокарта | 7835 | 160 | 0,1 с |
| ноутбук на Intel Lunar Lake | видеокарта | 3751 | 48 | 0,3 с |
| Raspberry Pi 5 | процессор | 133 | 8 | 7,8 с |

На моём ноутбуке я прогнал ту же модель встроенным бенчмарком — 256 токенов промпта и 256 токенов ответа:

| Бэкенд | Чтение промпта, токенов/с | Генерация, токенов/с | Первый токен |
|---|---|---|---|
| процессор Ryzen 9 9955HX | 748 | 23 | 0,39 с |
| видеокарта RTX 5070 Ti Laptop | 7837 | 144 | 0,04 с |
| видеокарта и MTP | 7425 | 246 | 0,04 с |

На обеих таблицах видно то же, что и в начале статьи. Видеокарта в 5–10 раз быстрее читает промпт — это вычисления. А генерирует на Samsung почти так же, как процессор, 52 и 47 токенов в секунду: генерация упирается в память, а она у процессора и видеокарты телефона общая. На iPhone видеокарта и здесь быстрее вдвое. MTP на видеокарте ноутбука ускорил генерацию в 1,7 раза. Бенчмарк подаёт синтетический текст, а на настоящем тексте доля угаданных токенов и выигрыш могут быть другими.

С телефонами есть две оговорки, о которых не пишут в таблицах. Первая — нагрев: при долгой генерации телефон снижает частоты, и скорость [падает за минуты](https://arxiv.org/abs/2603.23640), на iPhone — почти вдвое уже через пару прогонов. Вторая — память: системы убивают приложения, которые занимают слишком много оперативной памяти, поэтому на телефонах работают модели на 1–4 млрд параметров в 4-битном квантовании.

### Как попробовать

Быстрее всего — утилитой командной строки. Она скачивает модель с Hugging Face и работает на Windows, macOS, Linux и Raspberry Pi:

```bash
uv tool install litert-lm
litert-lm run --from-huggingface-repo=litert-community/gemma-4-E2B-it-litert-lm \
  gemma-4-E2B-it.litertlm --backend=gpu \
  --prompt="What is a KV cache? Answer in two sentences."
```

Замер скорости на своём железе — той же утилитой:

```bash
litert-lm benchmark --from-huggingface-repo litert-community/gemma-4-E2B-it-litert-lm \
  gemma-4-E2B-it.litertlm --backend gpu --speculative-decoding on
```

Из Python — через пакет `litert-lm-api`. Модель здесь — тот же файл, скачанный командой `hf download litert-community/gemma-4-E2B-it-litert-lm gemma-4-E2B-it.litertlm --local-dir .`:

```python
import litert_lm

# Backend.CPU() работает везде, Backend.NPU() — на Android с поддерживаемым чипом
with litert_lm.Engine("gemma-4-E2B-it.litertlm", backend=litert_lm.Backend.GPU()) as engine:
    with engine.create_conversation() as conversation:
        # Ответ приходит кусочками; диалог сам хранит историю
        stream = conversation.send_message_async("What is a KV cache? Answer in two sentences.")
        for chunk in stream:
            for item in chunk.get("content", []):
                if item.get("type") == "text":
                    print(item["text"], end="", flush=True)
```

В приложении на Kotlin зависимость для Android — `com.google.ai.edge.litertlm:litertlm-android`, для обычной JVM — `litertlm-jvm`. Код одинаковый. Движок создаётся один раз на всё приложение: загрузка модели занимает секунды. Для видеокарты на Android в манифест нужно добавить библиотеки `libOpenCL.so` и `libvndksupport.so` с `android:required="false"`, а модель на 2–4 ГБ скачивать после установки приложения, а не класть внутрь APK.

```kotlin
import com.google.ai.edge.litertlm.Backend
import com.google.ai.edge.litertlm.Engine
import com.google.ai.edge.litertlm.EngineConfig
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.flow.Flow
import kotlinx.coroutines.flow.flow
import kotlinx.coroutines.flow.flowOn
import kotlinx.coroutines.withContext

class LocalModel(modelPath: String, cacheDir: String) : AutoCloseable {
    private val engine = Engine(
        EngineConfig(
            modelPath = modelPath,
            // Backend.CPU() работает везде, Backend.NPU(...) — только на Android
            backend = Backend.GPU(),
            // Сюда кладутся ядра, собранные под эту видеокарту: второй запуск быстрее
            cacheDir = cacheDir,
        )
    )

    // Загрузка весов и подготовка видеокарты занимают секунды: не на главном потоке
    suspend fun load() = withContext(Dispatchers.Default) { engine.initialize() }

    // Ответ приходит кусочками, как в чате; диалог хранит историю сам
    fun ask(question: String): Flow<String> = flow {
        engine.createConversation().use { conversation ->
            conversation.sendMessageAsync(question).collect { emit(it.toString()) }
        }
    }.flowOn(Dispatchers.Default)

    override fun close() = engine.close()
}
```

Этот класс я запустил на обычной JVM под Windows с Gemma 4 E2B на видеокарте: модель загрузилась за 5,9 секунды и ответила правильно. Одна ловушка: сборка `litertlm-jvm` для Windows работает с видеокартой через WebGPU, но не содержит компилятор шейдеров DirectX — файлы `dxcompiler.dll` и `dxil.dll`. Без них движок не создаётся с ошибкой «Device could not be created». Помогло положить обе библиотеки в одну папку с `litertlm_jni.dll` из того же jar-файла и указать эту папку в `-Djava.library.path`; сами библиотеки есть, например, в Python-пакете `litert-lm-api`. На Android этой проблемы нет.

## Другие движки для приложений и браузера

### ExecuTorch

[ExecuTorch](https://github.com/pytorch/executorch) — движок Meta для запуска моделей PyTorch на устройствах: от телефонов и очков до микроконтроллеров. Версия 1.0 вышла в октябре 2025 года, актуальна 1.5.1, лицензия BSD. Модель экспортируется из PyTorch в файл `.pte` под нужный бэкенд, а для языковых моделей есть готовый экспорт и цикл генерации.

Сила ExecuTorch — бэкенды. Через них движок использует почти любой ускоритель: XNNPACK на процессоре, Core ML, Metal и MLX на устройствах Apple, Vulkan на видеокартах, NPU Qualcomm, MediaTek и Samsung, Arm Ethos-U и Cortex-M в микроконтроллерах, OpenVINO на Intel. Meta использует его в Instagram, WhatsApp, Messenger и Facebook, в шлемах Quest и очках Ray-Ban Meta. ExecuTorch стоит выбрать, если модель обучаете вы сами на PyTorch или нужен ускоритель, которого нет в LiteRT-LM. Если же вы берёте готовую открытую модель для Android, LiteRT-LM проще.

### ONNX Runtime GenAI и Windows ML

[ONNX Runtime GenAI](https://github.com/microsoft/onnxruntime-genai) — цикл генерации от Microsoft поверх ONNX Runtime; версия 0.19.0, лицензия MIT. На нём работают Foundry Local, Windows ML и AI Toolkit для VS Code. Ускорители подключаются через провайдеры (execution providers): CUDA и TensorRT RTX для NVIDIA, OpenVINO для Intel, QNN для Snapdragon, DirectML и WebGPU.

В Windows 11 начиная с версии 24H2 есть [Windows ML](https://learn.microsoft.com/en-us/windows/ai/new-windows-ml/overview) — встроенная в систему копия ONNX Runtime, которая сама скачивает провайдер под железо пользователя: NVIDIA, Intel, AMD, в том числе NPU AMD через VitisAI, и Snapdragon. Старый DirectML в ней помечен как устаревший. Если ваше приложение для Windows должно работать на любом ноутбуке — с NVIDIA, Intel, AMD или Snapdragon, — это самый прямой путь.

### Apple

- **[Foundation Models](https://developer.apple.com/documentation/foundationmodels)** — Swift API к системной модели Apple Intelligence. Модель уже лежит в системе, скачивать её не нужно; в техническом отчёте Apple 2025 года это модель примерно на 3 млрд параметров. API умеет структурированный ответ в Swift-типы и вызовы инструментов. В iOS 27 к нему добавились подключение других моделей через общий протокол, модель на серверах Apple Private Cloud Compute и картинки на входе. Заменить или дообучить саму системную модель нельзя.
- **Core AI** — новый фреймворк iOS и macOS 27 для своих нейросетей на процессоре, видеокарте и Neural Engine.
- **MLX Swift** — та же MLX, что на Mac, но для приложений на Swift, в том числе на iPhone.

### Другие

- **[MLC LLM](https://github.com/mlc-ai/mlc-llm)** компилирует модель через Apache TVM под конкретное железо: Vulkan, Metal, OpenCL, CUDA, WebGPU. Проект жив, но выходит только ночными сборками, без релизов.
- **[MNN](https://github.com/alibaba/MNN)** от Alibaba — движок для телефонов с поддержкой NPU Snapdragon и спекулятивным декодированием; на нём работает приложение MNN Chat.
- **Qualcomm GenieX** — открытая версия движка Qualcomm для NPU Snapdragon на Android, Windows on ARM и Linux; пока предварительная.

### В браузере

- **Встроенный ИИ Chrome.** Это не движок, а API браузера: Chrome сам скачивает модель Gemini Nano и даёт к ней Prompt API из JavaScript, а считает, по словам Google, LiteRT-LM. Для расширений Chrome API стабилен с версии 138; для обычных страниц таблица статусов указывает стабильность с версии 148, хотя текст на той же странице ещё описывает пробный доступ, — проверьте перед использованием. [Требования](https://developer.chrome.com/docs/ai/get-started): Windows 10 или 11, macOS 13 и новее, Linux или Chromebook Plus; 22 ГБ свободного места; видеокарта больше чем с 4 ГБ памяти или 16 ГБ оперативной памяти и 4 ядра. На Android и iOS не работает.
- **[transformers.js](https://github.com/huggingface/transformers.js)** от Hugging Face — библиотека, которая запускает модели в формате ONNX прямо в браузере через WebGPU; считает в ней ONNX Runtime. С версии 4 от марта 2026 года у него собственный исполнитель WebGPU на основе ONNX Runtime, который работает и в Node.js, Bun и Deno.
- **[WebLLM](https://github.com/mlc-ai/web-llm)** — браузерная версия MLC LLM с API, совместимым с OpenAI.
- **LiteRT-LM для JavaScript** — в раннем доступе, тоже через WebGPU.

## Сводная таблица: кто где работает

| Движок | NVIDIA | AMD | Intel | Apple Silicon | Google TPU | Другие ускорители | Процессор | Телефон |
|---|---|---|---|---|---|---|---|---|
| vLLM | да | да | да, Gaudi — плагином | плагином | плагином | Trainium, Ascend и др. — плагинами | да | — |
| SGLang | да | да | да | да | да | Ascend | да | — |
| TensorRT-LLM | да | — | — | — | — | — | — | — |
| llama.cpp | да | да | да | да | — | Ascend, Adreno, Hexagon | да | да |
| MLX | есть бэкенд CUDA | — | — | да | — | — | да | iPhone — через MLX Swift |
| LiteRT-LM | видеокарта ПК | не заявлено | видеокарта ПК, NPU в раннем доступе | да | — | NPU Qualcomm и MediaTek | да | Android и iOS |
| ExecuTorch | да | экспериментально | через OpenVINO | да | — | NPU Qualcomm, MediaTek, Samsung | да | Android и iOS |
| ONNX Runtime GenAI | да | через провайдеры Windows ML | да | процессор | — | Snapdragon через QNN | да | Android |

## Программы на основе движков

Эти программы сами ничего не считают. Они берут готовый движок — чаще всего llama.cpp или MLX — и добавляют то, что нужно человеку: каталог и загрузку моделей, окно чата, локальный сервер с API, управление памятью. Скорость у них определяет движок внутри, а выбирают их за удобство.

### Ollama

[Ollama](https://github.com/ollama/ollama) — самый простой способ запустить модель локально: `ollama run` и имя модели из её каталога. Это обёртка с собственным реестром моделей, менеджером загрузки и API, совместимым с OpenAI и, частично, с Anthropic. Работает на Windows, macOS и Linux, на видеокартах NVIDIA, AMD через ROCm или Vulkan и Apple. Лицензия MIT, версия 0.40.15.

Движков внутри два. На Mac с Apple Silicon — MLX от Apple. Для моделей GGUF с [версии 0.30](https://github.com/ollama/ollama/releases/tag/v0.30.0) от мая 2026 года Ollama снова использует llama.cpp: до этого команда писала свой движок поверх ggml, но вернулась к llama.cpp ради совместимости и скорости. Ещё есть облачные модели: те, что не помещаются локально, запускаются на серверах Ollama.

Для многих пользователей Ollama не предназначен: по умолчанию каждая модель обрабатывает [один запрос за раз](https://docs.ollama.com/faq) (`OLLAMA_NUM_PARALLEL=1`), остальные ждут в очереди.

### LM Studio

[LM Studio](https://lmstudio.ai) — настольное приложение с удобным интерфейсом: каталог моделей с Hugging Face, чат, локальный сервер с API OpenAI. Внутри три движка на выбор: llama.cpp, MLX и, на Apple Silicon, Splash. С версии 0.4.0 от января 2026 года он обрабатывает несколько запросов параллельно (по умолчанию четыре слота) и работает без интерфейса как фоновая служба `llmster` с утилитой командной строки `lms`. Приложение закрытое; [условия использования](https://lmstudio.ai/app-terms) разрешают личное и внутреннее рабочее использование. Версия 0.4.28.

### Другие программы

- **[Lemonade](https://github.com/lemonade-sdk/lemonade)** — локальный сервер при поддержке AMD: на видеокарте он запускает llama.cpp, а на NPU процессоров Ryzen AI — движок FastFlowLM.
- **[Foundry Local](https://github.com/microsoft/Foundry-Local)** от Microsoft — локальный запуск на ONNX Runtime с автоматическим выбором NPU, видеокарты или процессора.
- **Jan, LocalAI, llamafile** — приложения и серверы поверх llama.cpp.

## Слой над движками для кластеров

Движок — это один сервер, пусть и на много видеокарт. Чтобы распределять запросы между десятками его экземпляров, нужен слой выше, и этот слой уже не движок: считают по-прежнему vLLM, SGLang или TensorRT-LLM. Главная задача этого слоя — маршрутизация. Обычный балансировщик раздаёт запросы по кругу. Тогда запрос с длинной историей попадает на экземпляр, где этой истории нет в кэше, и считается заново. Умный маршрутизатор знает, где лежит какой префикс и какая очередь у каждого экземпляра.

### NVIDIA Dynamo

[NVIDIA Dynamo](https://github.com/ai-dynamo/dynamo) — не движок, а слой над движками для кластера. Версия 1.0 вышла в марте на конференции GTC, сейчас актуальна 1.6.2. Внизу работает на выбор vLLM, SGLang или TensorRT-LLM, а Dynamo добавляет:

- маршрутизатор, который знает, на каком экземпляре лежит KV-кэш нужного префикса;
- менеджер KV-кэша, который выгружает его в оперативную память, на SSD и в сетевое хранилище;
- NIXL — библиотеку для быстрой передачи KV-кэша между видеокартами и машинами; её используют и vLLM, и SGLang;
- планировщик, который добавляет и убирает экземпляры, чтобы уложиться в обещанные задержки;
- оператор для Kubernetes, который учитывает топологию стойки NVL72.

Знакомый многим Triton Inference Server в 2025 году переименован в Dynamo-Triton и формально продолжает жить, но всё новое для языковых моделей NVIDIA делает в Dynamo.

### llm-d и другие

- **[llm-d](https://github.com/llm-d/llm-d)** — распределённый инференс на Kubernetes поверх vLLM (и SGLang). Маршрутизирует запросы с учётом кэша префиксов через расширение Gateway API Inference Extension, разделяет prefill и decode, поддерживает wide-EP, многоуровневый KV-кэш и автомасштабирование по задержкам. Его основали Red Hat, Google Cloud, IBM Research, CoreWeave и NVIDIA, с марта 2026 года он в песочнице CNCF, версия 1.0 вышла 20 октября. На нём же построен ресурс для языковых моделей в KServe.
- **[AIBrix](https://github.com/vllm-project/aibrix)** — управляющий слой для Kubernetes из той же организации vllm-project: маршрутизация, автомасштабирование, упаковка LoRA-адаптеров. Версия 0.8.0 вышла в октябре.
- **production-stack** — эталонный Helm-чарт для vLLM от его разработчиков; по возможностям он скромнее llm-d.
- **vLLM Router** — балансировщик на Rust с учётом кэша и разделения prefill/decode, и **Kinference** от Buoyant, представленный 4 ноября, — управляющий слой с политиками маршрутизации и учётом расходов по клиентам.

## Итоги

- **vLLM** — выбор по умолчанию для сервера: самые широкие поддержка моделей и железа, масштабирование от одной видеокарты до стойки, экосистема вокруг (llm-d, Dynamo, AIBrix). Его цена — Linux, долгий старт и время на настройку больших развёртываний. **SGLang** — равный ему соперник, **TensorRT-LLM** — для тех, у кого только NVIDIA и кому важен каждый процент.
- **llama.cpp** — выбор для одной машины: запускается везде, работает с моделями больше видеопамяти, для одного пользователя не уступает серверным движкам. Под нагрузкой из многих пользователей он отстаёт: в моём замере на 16 одновременных запросах vLLM выдал в 1,4 раза больше токенов.
- **LiteRT-LM** — выбор для приложения на устройстве пользователя, особенно на Android: Google обкатывает его в собственных продуктах, а видеокарты и NPU телефонов работают через него без отдельного кода под каждый чип.
- **Ollama и LM Studio** — не движки, а удобные программы поверх llama.cpp и MLX: для одного человека на своём компьютере это самый простой путь. **Dynamo и llm-d** — слой для кластера, он нужен, когда экземпляров движка становится много.

Все три движка выпускают новые версии каждые несколько дней или недель, и многое из описанного здесь появилось или изменилось за 2026 год. Поэтому перед выбором стоит проверить свежие релизы и прогнать свою модель на своей нагрузке — `vllm bench serve` для серверов и `llama-bench` или `litert-lm benchmark` для одного устройства.