Рушії інференсу LLM: vLLM, llama.cpp, LiteRT-LM та інші — швидкість, залізо, масштабування

Привіт!

Мовну модель мало завантажити: потрібна програма, яка її запустить. Вона завантажує ваги в пам'ять, перетворює текст на токени, проганяє їх через нейромережу, вибирає наступний токен і стежить, щоб пам'яті вистачило всім користувачам. Таку програму називають рушієм інференсу. Інференс (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. Чип 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.

Мапа рушіїв

У таблиці — рушії, про які йтиметься, і їхні версії на початок листопада. Масштабування в цій таблиці — це скільки заліза рушій уміє задіяти під одну модель.

Програми й шар для кластерів рушіями не є: вони використовують рушії всередині.

З огляду випали рушії, які закрилися або завмерли:

• TGI (Text Generation Inference) від Hugging Face. З 11 грудня 2025 року він у режимі підтримки, а тепер його репозиторій в архіві. 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 — спосіб зберігати KV-кеш сторінками, про нього нижче. Уже тоді автори показали до 24 разів більшу пропускну здатність, ніж у бібліотеки Hugging Face Transformers, і до 3,5 раза — ніж у TGI.

З травня 2025 року vLLM — проєкт PyTorch Foundation при Linux Foundation. У січні 2026 року його автори заснували компанію Inferact і залучили 150 млн доларів за оцінки у 800 млн; раунд очолили Andreessen Horowitz і Lightspeed. Сам рушій лишається відкритим, під ліцензією Apache 2.0.

Масштаб проєкту: понад 2000 авторів коду і близько 97 тисяч зірок на GitHub. Тільки за червень 2026 року в основну гілку влили 1918 комітів — по 64 на день. Реліз виходить раз на два тижні, і кожен кандидат проходить повний набір тестів, нічні заміри продуктивності й перевірку точності моделей. Остання версія на момент написання — 0.33.0 від 2 листопада: 927 комітів від 389 авторів за два тижні.

Як він улаштований

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

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

Процеси обмінюються повідомленнями через ZeroMQ. Звідси практичний наслідок, про який попереджає документація: кожному процесу потрібне своє фізичне ядро процесора. На сервері з чотирма відеокартами це щонайменше шість ядер. Якщо ядер менше, відеокарти простоюють в очікуванні планувальника, особливо у віртуальних машинах.

Планувальник не ділить роботу на фази 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, який відтворює реальні сесії агентів для програмування, теоретично можна перевикористати понад 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 — нова реалізація тієї частини, яка готує входи й запускає модель на відеокарті. Підготовку входів перенесено на 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 року.

Документація чесно попереджає: виграш великий за малого навантаження і менший за великого. Коли відеокарта й так зайнята великим батчем, перевірка чужих здогадок перестає бути безкоштовною. Тому з'явилися адаптивні режими, які самі вирішують, скільки токенів угадувати. Наскільки великий виграш, видно на 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 від тих самих розробників.

Окремо квантується 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 — у документації є інструкція, як під'єднати до нього 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 наголошує: це спосіб керувати затримками, особливо найдовшими, а не підняти пропускну здатність, і функцію досі позначено як експериментальну. З кінця 2025 року так само відокремлюють кодувальники зображень у мультимодальних моделей, а 2026-го з'явився плагін, який відокремлює навіть шари уваги від шарів експертів.

Багаторівневий KV-кеш. KV-кеш, який не вміщується у відеокарту, можна вивантажувати в оперативну пам'ять, на диск і в об'єктне сховище, а потім підвантажувати замість того, щоб рахувати заново. Для агентів із довгою історією це пряма економія на prefill.

Еластичний експертний паралелізм — відеокарти можна додавати в MoE-розгортання і прибирати з нього без перезапуску сервера.

Наскільки це все швидко, видно з чисел розробників — це їхні власні заміри, а не незалежні:

• DeepSeek на H200. Із wide-EP і розділенням prefill і decode — 2200 токенів за секунду на відеокарту в багатовузловому розгортанні, грудень 2025 року.
• Kimi K3 на AMD проти NVIDIA. На восьми AMD MI355X — 7567 токенів за секунду на відеокарту проти 6083 на восьми NVIDIA B300 за однакової швидкості 50 токенів за секунду для кожного користувача. Пост написали AMD і Embedded LLM; числа взято з бенчмарку InferenceX.
• DeepSeek-V4.1-Flash. На GB200 швидкість decode — у межах 6% від власного рушія DeepSeek, DeepInfer, жовтень 2026 року.

Як роздавати запити між десятками екземплярів vLLM, розказано в розділі про шар над рушіями для кластерів.

Залізо

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

Windows vLLM не підтримує — тільки через 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 потрібен, якщо відеокарту займають і інші програми; на виділеному сервері його можна прибрати:

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 передають одне одному дані через спільну пам'ять:

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:

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__" наприкінці: без неї скрипт падає під час старту рушія.

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 — головний суперник vLLM і за задачами, і за можливостями. Його робить LMSYS — некомерційна організація дослідників, відома рейтингом Chatbot Arena. 2026 року навколо проєкту з'явилася компанія RadixArk, за повідомленнями TechCrunch — з оцінкою в 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 тисяч вихідних токенів за секунду на відеокарту для 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 на 512 відеокартах AMD MI355X саме на SGLang. Перед вибором варто прогнати обидва на своєму навантаженні.

TensorRT-LLM

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 — про нього в розділі про шар над рушіями.

Інші серверні рушії

• LMDeploy із Шанхайської лабораторії ШІ (автори моделей InternLM). Два рушії — TurboMind на C++ і CUDA та рушій на PyTorch; працює на NVIDIA і Huawei Ascend. Версія 0.18.0 від вересня.
• 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 (раніше називався 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. Так я і зробив.

Замір на ноутбуці: 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:

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

Результати — сумарна швидкість генерації, медіанний час до першого токена і медіанна пауза між токенами:

Що з цього випливає:

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 — рушій на 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 і продовжує працювати над проєктом; сам проєкт лишається відкритим і громадським. Фіксованих релізів немає: кожен влитий pull request стає новою збіркою, і на день їх виходить понад десяток. Станом на 9 листопада актуальна збірка b12233.

Залізо

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

Готові збірки викладаються разом із кожною версією: для 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 у різних форматах, за таблицею з репозиторію:

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-кеш, якщо новий запит починається так само, як попередній, і зберігає завершені діалоги в оперативній пам'яті. Під навантаженням від різних користувачів останнє заважає — це видно в замірі вище.
• Спекулятивне декодування. Чорнова модель, EAGLE-3, MTP із травня 2026 року, DFlash, DSpark і пошук продовження у вже написаному тексті (n-gram).
• Зображення, звук і відео на вході, якщо в моделі є мультимодальний проєктор.
• Інструменти. Виклики функцій через шаблони чату, вбудований клієнт MCP, керування міркуваннями: увімкнути, вимкнути, обмежити бюджет.
• Кілька моделей. У режимі маршрутизатора сервер сам завантажує модель із теки під час першого звернення до неї і вивантажує зайві, коли пам'ять закінчується.

Завантажити модель із Hugging Face і запустити сервер — одна команда; суфікс після двокрапки вибирає варіант квантування:

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):

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 шарів:

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

Швидкість за різних способів розкласти модель, за замірами llama-bench:

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

Кілька відеокарт і кілька машин

На кількох відеокартах одного комп'ютера llama.cpp за замовчуванням роздає їм шари по черзі. Це дає змогу запустити велику модель, але не пришвидшує її: карти працюють по черзі. У квітні 2026 року з'явився експериментальний тензорний паралелізм (-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 — бібліотека машинного навчання від Apple для власних чипів, а mlx-lm — запуск мовних моделей на ній, із сервером, сумісним з OpenAI. Її головна перевага — спільна пам'ять: в Apple Silicon процесор і відеокарта працюють з однією й тією самою оперативною пам'яттю, і MLX не копіює дані між ними. Mac із 128 або 512 ГБ спільної пам'яті запускає моделі, для яких на ПК знадобилося б кілька відеокарт.

Кілька Mac можна об'єднати: MLX роздає модель по машинах, з'єднаних кабелями Thunderbolt 5, а починаючи з macOS 26.2 передає дані між ними через RDMA, оминаючи процесор. У замірах Apple від жовтня 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 ставить планувальник і сторінковий KV-кеш vLLM поверх MLX. Він потрібен, якщо Mac обслуговує кількох користувачів: на пачці з восьми запитів він упорався швидше, ніж mlx-lm і llama.cpp.

Інші локальні рушії

• ExLlamaV3 із сервером TabbyAPI — власний формат квантування EXL3 і тензорний паралелізм для домашніх відеокарт; тільки NVIDIA.
• ik_llama.cpp — відгалуження llama.cpp від автора багатьох його форматів квантування: власні формати й оптимізації для процесора і CUDA.
• mistral.rs — рушій на Rust із безперервним батчингом і сторінковим KV-кешем; CUDA, Metal і процесор.
• OpenVINO GenAI від Intel — для процесорів, відеокарт і NPU Intel, зокрема в ноутбуках.

LiteRT-LM

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. Новий проєкт на ньому починати не варто.

Платформи й залізо

На процесорі 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 на 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 для Gemma 4 E2B (файл 2,58 ГБ) — це числа виробника, довжину промпту в них не вказано:

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

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

З телефонами є два застереження, про які не пишуть у таблицях. Перше — нагрівання: під час довгої генерації телефон знижує частоти, і швидкість падає за хвилини, на iPhone — майже вдвічі вже після кількох прогонів. Друге — пам'ять: системи вбивають застосунки, які займають забагато оперативної пам'яті, тому на телефонах працюють моделі на 1–4 млрд параметрів у 4-бітному квантуванні.

Як спробувати

Найшвидше — утилітою командного рядка. Вона завантажує модель із Hugging Face і працює на Windows, macOS, Linux і Raspberry Pi:

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."

Замір швидкості на власному залізі — тією самою утилітою:

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 .:

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.

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 — рушій 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 — цикл генерації від 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 — вбудована в систему копія ONNX Runtime, яка сама завантажує провайдер під залізо користувача: NVIDIA, Intel, AMD, зокрема NPU AMD через VitisAI, і Snapdragon. Старий DirectML у ній позначено як застарілий. Якщо ваш застосунок для Windows має працювати на будь-якому ноутбуці — з NVIDIA, Intel, AMD чи Snapdragon, — це найпряміший шлях.

Apple

• Foundation Models — 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 компілює модель через Apache TVM під конкретне залізо: Vulkan, Metal, OpenCL, CUDA, WebGPU. Проєкт живий, але виходить лише нічними збірками, без релізів.
• 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, хоча текст на тій самій сторінці ще описує пробний доступ, — перевірте перед використанням. Вимоги: Windows 10 або 11, macOS 13 і новіші, Linux або Chromebook Plus; 22 ГБ вільного місця; відеокарта з понад 4 ГБ пам'яті або 16 ГБ оперативної пам'яті й 4 ядра. На Android та iOS не працює.
• transformers.js від Hugging Face — бібліотека, яка запускає моделі у форматі ONNX просто в браузері через WebGPU; рахує в ній ONNX Runtime. З версії 4 від березня 2026 року в нього власний виконавець WebGPU на основі ONNX Runtime, який працює і в Node.js, Bun і Deno.
• WebLLM — браузерна версія MLC LLM з API, сумісним з OpenAI.
• LiteRT-LM для JavaScript — у ранньому доступі, теж через WebGPU.

Зведена таблиця: хто де працює

Програми на основі рушіїв

Ці програми самі нічого не рахують. Вони беруть готовий рушій — найчастіше llama.cpp або MLX — і додають те, що потрібно людині: каталог і завантаження моделей, вікно чату, локальний сервер з API, керування пам'яттю. Швидкість у них визначає рушій усередині, а обирають їх за зручність.

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 від травня 2026 року Ollama знову використовує llama.cpp: до цього команда писала власний рушій поверх ggml, але повернулася до llama.cpp заради сумісності й швидкості. Ще є хмарні моделі: ті, що не вміщуються локально, запускаються на серверах Ollama.

Для багатьох користувачів Ollama не призначений: за замовчуванням кожна модель обробляє один запит за раз (OLLAMA_NUM_PARALLEL=1), решта чекають у черзі.

LM Studio

LM Studio — десктопний застосунок зі зручним інтерфейсом: каталог моделей із Hugging Face, чат, локальний сервер з API OpenAI. Усередині три рушії на вибір: llama.cpp, MLX і, на Apple Silicon, Splash. З версії 0.4.0 від січня 2026 року він обробляє кілька запитів паралельно (за замовчуванням чотири слоти) і працює без інтерфейсу як фонова служба llmster з утилітою командного рядка lms. Застосунок закритий; умови використання дозволяють особисте та внутрішнє робоче використання. Версія 0.4.28.

Інші програми

• Lemonade — локальний сервер за підтримки AMD: на відеокарті він запускає llama.cpp, а на NPU процесорів Ryzen AI — рушій FastFlowLM.
• Foundry Local від Microsoft — локальний запуск на ONNX Runtime з автоматичним вибором NPU, відеокарти або процесора.
• Jan, LocalAI, llamafile — застосунки й сервери поверх llama.cpp.

Шар над рушіями для кластерів

Рушій — це один сервер, хай і на багато відеокарт. Щоб розподіляти запити між десятками його екземплярів, потрібен шар вище, і цей шар уже не рушій: рахують, як і раніше, vLLM, SGLang або TensorRT-LLM. Головне завдання цього шару — маршрутизація. Звичайний балансувальник роздає запити по колу. Тоді запит із довгою історією потрапляє на екземпляр, де цієї історії немає в кеші, і рахується заново. Розумний маршрутизатор знає, де лежить який префікс і яка черга в кожного екземпляра.

NVIDIA Dynamo

NVIDIA 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 — розподілений інференс на 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 — керувальний шар для 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 для одного пристрою.