Двигатели за инференс на 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 ГБ обща памет стартира модели, за които на PC биха били нужни няколко видеокарти.

Няколко 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 за едно устройство.