Локальный inference в 2026: четыре слоя между Cursor и datacenter

Соло-разработчик на Cursor, который гоняет агентные циклы через локальный API вместо облачного биллинга, рискует не на промпте, а на выборе слоя inference: Ollama как drop-in под api.openai.com — разумный старт, но тот же стек на десятке одновременных пользователей или в плотном RAG-контуре может рассыпаться. В свежем разборе Sreeraj Sreenivasan собирает карту open-source рантаймов на июль 2026 и предлагает выбирать не «лучший инструмент», а workload — для агентов и IDE это принципиально.
Почему спор «Ollama или vLLM» ставит вопрос не туда
В лиде поста — «nine tools, three layers, one decision framework», но внутри автор раскладывает стек уже на четыре уровня. Слой Developer UX — Ollama, LM Studio, Jan, GPT4All, Open WebUI. Слой Inference Engines — llama.cpp, Apple MLX, ExLlamaV3, MLC-LLM: «всё остальное строится на них». Production Serving — vLLM, SGLang, LMDeploy, Aphrodite. Datacenter — TensorRT-LLM с Triton, только NVIDIA.
Смысл для разработчика с ИИ-инструментами простой: сравнивать молоток и дрель бессмысленно, если одна задача — прототип агента в IDE, а другая — пятьдесят параллельных сессий. Поставить vLLM на MacBook ради «максимального throughput» — та же категория ошибки, что и тащить Ollama в прод с пиковой concurrency: архитектура ломается раньше, чем вы допишете system prompt.
Ollama как дефолтный бэкенд для Cursor и агентного зоопарка
Для соло и прототипирования Ollama — первая ветка decision framework: «fastest start, widest framework support». Обёртка вокруг llama.cpp или, на Apple Silicon с версии 0.19+ (март 2026), MLX — ollama run, OpenAI-compatible API на localhost:11434/v1.
Здесь же ключевая связка с vibe coding: «весь agentic tooling ecosystem — Cursor, Continue, Aider, Open WebUI, LangChain, LlamaIndex — по умолчанию бьёт в API Ollama». Для ру-соло без отдельного MLOps это практичный путь: агент в IDE ходит на локальный endpoint, промпты и tool calls не уезжают в облако, подписка на inference API не обязательна.
Цена удобства измерима: на одинаковом железе llama.cpp даёт на 10–25% больше скорости, Ollama проигрывает raw-движку на 10–20% из-за обёртки. На одном пользователе разница с vLLM «near-zero»; при пиковой нагрузке vLLM уходит в 16–20× по concurrent throughput — но это уже другой слой стека, не замена утреннего ollama pull.
Jan, MCP и SGLang — когда агентный контур тяжелее чата
Не каждый локальный сценарий укладывается в «запустил модель и подключил Cursor». Jan — open-source GUI на Tauri, zero telemetry, Apache 2.0, API на localhost:1337; полностью аудируемая альтернатива проприетарному LM Studio. Для agentic frameworks отдельно отмечена поддержка MCP (Model Context Protocol) — нативное подключение Jan к агентным фреймворкам без обходных мостов.
Ветка «RAG pipeline or agentic workflows» в decision framework ведёт к SGLang. RadixAttention, prefix cache, structured output и function calling «first-class» — под agent loops с повторяющимися tool descriptions и JSON-схемами. Заявлено до 20–30% снижения стоимости RAG «in practice» и до 6× в RAG-сценариях относительно vLLM на H100; в среднем — +29% throughput против vLLM. Цифры — claims одного гайда, без независимой проверки редакцией, но логика выбора ясна: если агент крутит один и тот же контекст снова и снова, слой serving должен это понимать.
Несколько моделей в одном процессе — SGLang или LMDeploy; vLLM в этой ветке не рассматривается. Разные форматы квантизации (EXL2, ExLlamaV3, GGUF, AWQ) — Aphrodite Engine, лицензия AGPL-3.0, что для части соло-проектов может стать отдельным фильтром.
Production, CPU-only и яблочное железо — три ловушки выбора
CPU-only / без GPU — llama.cpp или GPT4All; последний ещё и desktop-RAG через LocalDocs для менее технической аудитории. Apple Silicon, max performance — mlx-lm или Ollama 0.19+ с MLX backend; в примере автора Qwen3-235B MoE даёт 5.5+ tok/s на M4 Max 128GB.
10+ concurrent users — vLLM: PagedAttention, continuous batching, safetensors, CUDA-first. Практический минимум VRAM — 16GB+, плюс 20–30% на paging buffers. Cold start — минутами, не секундами: цена за multi-user batching.
TGI с 21 марта 2026 в maintenance mode; новых пользователей перенаправляют на vLLM, SGLang, llama.cpp, MLX. Если вы строите агентный сервис, а не эксперимент за обед, закладка на устаревающий serving — лишний риск в цепочке.
Datacenter-ветка — TensorRT-LLM + Triton: компиляция модели 15–30 минут (в тексте встречается и 28 min) one-time на версию, зато максимальный NVIDIA throughput. Для соло-разработчика это четвёртый слой «на будущее», не стартовая точка.
Decision framework: чеклист под ваш workload
Выбор сводится к дереву по задаче, а не к рейтингу GitHub stars (в гайде они есть — llama.cpp 85k+, Ollama 130k+, — но как контекст зрелости, не как метрика тренда):
| Ситуация | Куда смотреть |
|---|---|
| Соло, прототип, IDE-агенты | Ollama |
| GUI, open source, MCP | Jan |
| GUI, проприетарный комфорт | LM Studio |
| CPU-only | llama.cpp / GPT4All |
| Apple Silicon | mlx-lm / Ollama 0.19+ |
| 10+ одновременных пользователей | vLLM |
| RAG / agentic workflows | SGLang |
| Несколько моделей в одном процессе | SGLang / LMDeploy |
| Экзотическая квантизация | Aphrodite |
| NVIDIA datacenter | TensorRT-LLM + Triton |
| Полностью аудируемый open source | Jan (GUI) или llama.cpp (engine) |
Практическое правило по квантизации из того же материала: GGUF Q4_K_M держит 95–98% качества full precision «на большинстве бенчмарков» — компромисс для локального агента, когда VRAM упирается в потолок.
Версии и бенчмарки в гайде помечены как «verified as of July 2026» — перед продакшен-решением имеет смысл прогнать свой workload на своём железе. Но рамка остаётся: промпты и агенты живут на слое, который вы выбрали осознанно. Для Cursor-соло это чаще Ollama; для agentic RAG в проде — разговор про SGLang; для пятидесяти параллельных сессий — vLLM, а не спор в комментариях «что моднее».
Источники
- Sreeraj Sreenivasan — The Complete Guide to Local LLM Inference Tools in July 2026: llama.cpp, Ollama, vLLM, SGLang, and Beyond (Dev.to, опубликовано 19 июля 2026; дата доступа: 2026-07-19 UTC)