Ollama, LM Studio и llama.cpp на одной модели: от 0,3% разницы до трёх раз

Коротко (TL;DR)

• Когда модель, квант и настройки действительно одинаковы, разрыв между тремя программами маленький: на RTX 5060 Ti LM Studio отстал от прямого llama.cpp на 0,3%, Ollama — на 10%; на Radeon 8060S разрыв Ollama и llama.cpp составил около 3%.
• Разрывы «в полтора-три раза», которыми пестрят обзоры, почти всегда не про обёртку. В них либо разные кванты одной модели, либо разная стратегия выгрузки слоёв на GPU у MoE-моделей. Это настройка, а не архитектура.
• Посылка «под всеми тремя один движок» устарела. Ollama ушла с llama.cpp на библиотеку GGML напрямую ещё 15 мая 2025 года, а LM Studio на Apple Silicon умеет считать через MLX вместо llama.cpp.
• Версия сборки способна перевесить выбор программы. В самом llama.cpp зафиксирован случай: та же карта, та же модель, те же флаги — сборка от 6 июля 2026 обрабатывает промпт со скоростью 17 t/s, а сборка b10107 — 799 t/s.
• Дефолты трёх инструментов различаются сильнее, чем их скорость. llama-server берёт полный контекст модели, Ollama — 4096 токенов и молча обрезает лишнее; модель между запросами Ollama держит 5 минут, LM Studio — 60.
• Мы не гоняли эти карты сами. Все цифры ниже — чужие замеры с указанием, чьи они и на чём сняты; замеры без методики в таблицу не попали, и таких мы отбраковали шесть.

llama.cpp, Ollama и LM Studio: где движок, а где оболочка

Три названия из заголовка — сущности разного уровня, и путаница начинается именно здесь.

llama.cpp — это движок. Проект описывает себя одной строкой: «LLM inference in C/C++», лицензия MIT. Он умеет считать на CUDA, Metal, Vulkan, HIP (AMD), SYCL (Intel), а также на голом процессоре. В комплекте идут три инструмента: llama-cli для консоли, llama-bench для замеров и llama-server — HTTP-сервер с OpenAI-совместимым API и встроенным веб-интерфейсом, включённым по умолчанию. То есть «llama.cpp — это только командная строка» — миф: интерфейс там есть, просто он в браузере.

Ollama — демон с реестром моделей. Вы пишете ollama run gemma4, и программа сама скачивает веса, подбирает шаблон промпта и поднимает сервис на порту 11434 с нативными эндпоинтами /api/generate, /api/chat и OpenAI-совместимым слоем. Лицензия — MIT. Модели хранятся не файлами, а блобами с манифестами, по образцу контейнерных образов: удобно для дедупликации, неудобно для переиспользования весов в других программах.

LM Studio — графическая оболочка с каталогом. Внутри приложения вы ищете модель на Hugging Face, видите подсказку по кванту под ваш объём памяти и запускаете чат. С июля 2025 года приложение бесплатно и для рабочего использования. Отдельно есть демон llmster и CLI lms — то есть сервером без графики LM Studio тоже работает.

Отсюда следует главное для сравнения: низкоуровневая математика у всех троих родом из одной тензорной библиотеки GGML — на ней построены и llama.cpp, и новый движок Ollama, и рантайм LM Studio. Значит, разница в скорости — это стоимость слоя сверху, а не другой алгоритм умножения матриц. Вопрос статьи звучит так: сколько процентов скорости и памяти забирает удобство и за что именно вы платите этот процент. Выбор самой модели — отдельный разговор, он у нас разобран в гиде по локальным LLM.

GLM-5.3 нашла 1097 критических багов — Z.ai придержала веса на две недели

Квантование локальных LLM: Q8 даёт запас, а обрыв качества начинается ниже Q4

Видеопамять под LLM: 10 моделей, 5 квантов и формула для KV-кэша

DGX Spark, Mac Studio и Strix Halo: 120B держат все три, 70B буксует у двух

RTX 5090, 4090 и 3090 в локальных LLM: чужие замеры в одной таблице

Ollama ушла с llama.cpp на GGML: движок под тремя уже не общий

Почти все сравнения в выдаче начинаются с фразы «все три — обёртки над llama.cpp». В 2026 году это верно наполовину.

15 мая 2025 года Ollama опубликовала запись о новом движке. Формулировка прямая: «Ollama has so far relied on the ggml-org/llama.cpp project for model support» — то есть полагалась в прошедшем времени, — и дальше: «We set out to support a new engine». Новый движок построен напрямую на тензорной библиотеке GGML, без llama.cpp как обёртки. Под него завели поддержку Meta Llama 4, Google Gemma 3, Qwen 2.5 VL и Mistral Small 3.1, а внимание стали настраивать не общей группой, а под каждую модель: скользящее окно у Gemma 3, чанковое внимание у Llama 4.

Забавная деталь: README самого репозитория Ollama на 15 августа 2026 года по-прежнему называет движком проекта llama.cpp. То есть даже внутри одного проекта два документа говорят разное, а статья MachineLearningMastery от 29 июля 2026 года всё ещё утверждает, что «все три работают на одном ядре».

LM Studio ломает ту же посылку с другой стороны. Документация говорит: на Mac, Windows и Linux приложение считает через llama.cpp, а на Apple Silicon дополнительно умеет MLX — фреймворк Apple. Это не тонкая настройка, а другой движок с другим форматом весов. В замере на M4 Max путь MLX дал 126–132 tok/s против 70–72 у llama.cpp — разрыв в полтора-два раза, то есть больше, чем разница между самими программами.

Практический вывод: прежде чем верить любому сравнению «трёх бекендов», нужно спросить, на каком движке считал каждый из них в момент замера. Ни один из разобранных нами материалов топ-10 на этот вопрос не отвечает.

Что обязано быть в чужом замере, иначе его нельзя брать в таблицу

Своих карт у редакции нет, поэтому единственный честный путь — брать чужие цифры и проверять их методику. Планку задаёт не наш вкус, а шапка официального треда замеров llama.cpp: она требует указывать git-коммит сборки и строку устройства, иначе результат в таблицу не принимают.

Мы использовали чек-лист из семи пунктов. Замер попадает в нашу таблицу, если в нём названы:

1. Железо — конкретная карта или чип, объём памяти, шина.
2. Модель — точное имя и число параметров, включая пометку MoE (у моделей вида 35B-A3B активна лишь часть весов).
3. Квант — не «4 бита», а именно Q4_K_M, Q8_0, UD-Q4_K_XL: между ними разница и в весе, и в скорости.
4. Версии всех участников — сборка llama.cpp, версия Ollama, версия LM Studio с указанием рантайма.
5. Длина контекста — от неё напрямую зависит расход памяти и скорость на длинном входе.
6. Что именно измерено — обработка промпта или генерация, и как считали: по часам клиента или по счётчику движка.
7. Число прогонов и разброс — один прогон измеряет погоду в комнате, а не программу.

По этому чек-листу мы отбраковали шесть источников из числа тех, что стоят в топе выдачи по запросам вида «ollama vs llama cpp benchmark». Типичная причина — цифры есть, условий нет. У XDA-Developers разрыв между LM Studio и llama.cpp оценён «на 5–20%» без единого параметра стенда, там же приведена чужая реплика про 280 tok/s против 90 на RTX 5090 — без модели, кванта и версий. Ещё в нескольких материалах разброс подаётся диапазоном вида «быстрее на 13–80%», который сам по себе означает, что складывали несравнимые прогоны. Такие утверждения нельзя ни проверить, ни повторить, поэтому они остались за бортом.

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

Одна модель на трёх бекендах: что показывают сведённые замеры

Ниже — все найденные замеры, прошедшие чек-лист хотя бы частично, с честной пометкой, чего в них не хватает. Цифры относятся к генерации токенов (не к обработке промпта), если не сказано иное.

Что из этой таблицы следует.

Первое: усреднять её нельзя. Ollama в разных строках выдаёт 16, около 31, около 45, 46, 60 и 69 tok/s — это не разброс инструмента, это шесть разных экспериментов.

Второе: разрыв растёт на моделях с разреженной архитектурой. На плотной Qwen2.5-Coder-7B отставание Ollama составило 10,3% на NVIDIA и 13,6% на Apple. На MoE-моделях, где активна лишь часть весов, отставание в разы больше: у Qwen3.5-35B-A3B в issue самой Ollama — 33–40%, у Qwen3.6-35B-A3B в разборе на Habr — 2,8–3,2 раза. HTTP-слой во всех случаях один и тот же, значит, дело не в нём. Оговорка: в issue #14861 у второй модели, gpt-oss:20b, отставание меньше (13–21%), но она тоже MoE — 21 миллиард параметров при 3,6 миллиарда активных — и снята в другом кванте (MXFP4 против Q8_0), так что эти две строки друг с другом напрямую не сравнимы.

Третье: самый аккуратный по протоколу замер оказался самым некорректным по сути. Ante Kapetanovic сделал всё правильно с точки зрения статистики — прогрев, десять повторов на конфигурацию, 160 замеров, отдельно скорость по счётчику движка и по часам клиента. Но кванты у него разные: Ollama получила Q4_K_M, llama.cpp — Unsloth Dynamic Q4_K_XL (слои внимания подняты до 8–16 бит), MLX — своё групповое 4-битное квантование. Это уже не «одна модель, три бекенда», и разрыв 70–72 против 42–48 tok/s измеряет сумму трёх разных вещей.

Четвёртое, и самое полезное: стоимость слоя-обёртки один раз измерили внутри одного движка. В том же материале MLX сравнили сам с собой: через Python API и через HTTP-сервер. Разница — около 20%. Это верхняя граница того, во что вообще может обойтись сервер поверх движка, снятая без смены модели, кванта и железа.

Обработка промпта и генерация — две разные скорости, а не одна

Почти все обзоры дают одну цифру tok/s. Официальный инструмент замеров llama.cpp даёт две, и они отличаются не на проценты.

llama-bench меряет pp512 — скорость обработки промпта на 512 токенах — и tg128 — скорость генерации 128 токенов. Первая величина показывает, как быстро модель «прочитает» ваш длинный запрос, вторая — как быстро она будет печатать ответ. Вот выдержка из официального треда замеров на CUDA (модель Llama 2 7B, квант Q4_0, все слои на GPU):

На Apple Silicon расклад принципиально другой. В соседнем треде, где вся таблица снята на одной зафиксированной сборке 8e672ef, M4 Max с 40 GPU-ядрами даёт 885,7 t/s на обработке промпта и 83,1 t/s на генерации — отношение около 11×, а не 64×. M2 Ultra с 76 ядрами: 1238,5 и 94,3 t/s.

Практический смысл различия простой. Если вы гоняете короткие чаты, вас интересует только генерация. Если вы кормите модель кодовой базой или документом на 30 тысяч токенов, львиная доля ожидания приходится на обработку промпта — и здесь NVIDIA отрывается от Apple в разы, хотя по «скорости печати» разрыв невелик. Обзор, смешавший обе величины в одну цифру, отвечает не на тот вопрос, который вы задали. Подробнее о том, как это влияет на выбор конфигурации, — в нашем гиде по железу для локального ИИ.

Память: кто держит модель в VRAM и что режется при нехватке

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

Две строки этой таблицы объясняют большинство жалоб на «Ollama жрёт память».

Первая — авто-выгрузка. Ollama по умолчанию держит модель загруженной пять минут после последнего запроса, LM Studio — час. Если вы поработали с моделью и переключились на другую задачу, оба продолжают занимать видеопамять; llama-server не выгружает её вообще, пока вы не остановите процесс.

Вторая — число одновременно загруженных моделей. По документации Ollama переменная OLLAMA_MAX_LOADED_MODELS по умолчанию равна трём на каждый GPU. То есть «лишняя» занятая память часто уходит не на накладные расходы обёртки, а на вторую и третью модель, которые вы уже забыли.

При нехватке памяти поведение тоже разное. Ollama, по её собственной документации, сначала пытается уместить модель целиком на одну карту, а если не выходит — размазывает по всем доступным и по процессору; команда ollama ps показывает результат вида «48%/52% CPU/GPU». Именно так возникают внезапные 11 tok/s вместо 40: часть слоёв уехала на процессор.

Наш расчёт: сколько VRAM съедает контекст на Llama 3.1 8B

Ни один из разобранных материалов не приводит расчёта памяти под контекст, хотя именно он чаще всего решает, влезет модель или нет. Считаем сами.

KV-кеш — это сохранённые ключи и значения внимания для каждого уже обработанного токена. Формула:

размер = 2 (ключи и значения) × число слоёв × число KV-голов × размер головы × длина контекста × байт на число

Для Llama 3.1 8B: 32 слоя, 8 KV-голов благодаря групповому вниманию, размер головы 128, тип f16 (2 байта). Получаем на один токен:

2 × 32 × 8 × 128 × 2 = 131 072 байта, то есть ровно 128 КиБ на токен.

Дальше умножаем на длину контекста:

Проверка расчёта по двум независимым источникам. Официальный разбор Llama 3.1 в блоге Hugging Face даёт для 8B в FP16 таблицу: 0,125 ГБ на 1000 токенов и 15,62 ГБ на 128 тысяч — это ровно те же 128 КиБ на токен, что вышли у нас, просто записанные в десятичных гигабайтах. Автор функции квантования KV-кеша в Ollama приводит для модели на 8 миллиардов параметров с контекстом 32K около 6 ГБ при f16 и около 3 ГБ при q8_0 — его оценка выше наших 4,0 ГиБ, потому что включает служебные буферы, а пропорция «q8_0 вдвое меньше» совпадает.

Отсюда видно, во что упирается 16-гигабайтная карта: веса Llama 3.1 8B в библиотеке Ollama весят 4,9 ГБ, и на полный контекст 128K нужно ещё 16 ГиБ — то есть полный контекст на такой карте не помещается в принципе, а на 32K останется запас. Именно поэтому llama-server с его дефолтом «взять контекст из модели» на слабой карте падает по памяти там, где Ollama со своими 4096 токенами спокойно запускается — и наоборот, режет длинный документ. Как это соотносится с выбором конкретной сборки, разобрано в материале про компьютер под локальный ИИ.

Настройки дороже выбора инструмента: контекст, слои, KV-кеш, батч

Это главный вывод статьи, и он подкреплён числами.

Контекст. У llama-server параметр -c по умолчанию равен нулю, а ноль означает «взять из модели» — то есть полный обученный контекст. У Ollama дефолт другой, и здесь начинается неприятное: FAQ говорит «4096 токенов», справочник Modelfile — что num_ctx по умолчанию 2048, а страница о длине контекста утверждает, что значение подбирается по объёму видеопамяти (4k при VRAM меньше 24 ГиБ, 32k при 24–48 ГиБ, 256k при 48 ГиБ и выше). Три страницы официальной документации — три разных ответа, проверено 15 августа 2026 года. Хуже того, при переполнении окна вход обрезается молча: модель отвечает, ответ читается нормально, просто написан он по хвосту вашего запроса.

Выгрузка слоёв. Здесь живёт та самая разница «в три раза». Разбор на Habr показывает механизм на RTX 4060 16 ГБ и модели Qwen3.6-35B-A3B. Ollama работает в режиме целых слоёв (-ngl) и укладывает на карту 26 из 41 — видеопамять при этом занята, но полезная загрузка GPU, по формулировке автора разбора, около 30%: отсюда 16 tok/s при контексте 4k. llama.cpp для MoE-моделей умеет режим -n-cpu-moe, где выгрузка идёт не слоями целиком, а отдельными тензорами: на GPU уезжают все тензоры внимания и несколько слоёв, и загрузка GPU доходит до 100% — 45 tok/s. Это не «Go-сервер тормозит», это разная гранулярность размещения: память занята в обоих случаях, а работает она по-разному.

KV-кеш. Переключение с f16 на q8_0 освобождает примерно половину памяти под контекст, на q4_0 — три четверти. Цена: по замеру автора реализации, q8_0 добавляет 0,002–0,05 перплексии (в его таблице для Qwen 2.5 Coder 7B — 8,3891 против 8,3934), а q4_0 уже 0,206–0,25, и это заметно. Важная оговорка: квантование KV требует включённого Flash Attention, иначе Ollama молча возвращается к f16 — экономия, которую вы ждёте, просто не случится.

Батч. В RDNA4-треде llama.cpp зафиксирован эффект одного флага: -ub 2048 (размер микробатча) дал +21% к скорости обработки промпта на модели 35B-A3B. Прирост от одной настройки сопоставим со всем разрывом между Ollama и llama.cpp в контролируемом замере.

Версия сборки. И финальный аргумент. В том же треде: «та же карта, та же модель, те же флаги — сборка от 6 июля 2026 обрабатывает промпт со скоростью 17 t/s, а сборка b10107 — 799 t/s». Речь о гибридной схеме внимания у Qwen3.6-27B, дефект позже починили, но вывод автора треда стоит держать в голове: проверяйте сборку, прежде чем публиковать числа. Со стороны вендора есть зеркальный пример: NVIDIA заявляет прирост 27% на DeepSeek-R1-Distill-Llama-8B на RTX 5080 благодаря своим правкам в llama.cpp (условия названы: Q4_K_M, batch 1, вход 4000 токенов, выход 200, Flash Attention включён). Это заявление вендора, а не независимый тест, но порядок величины тот же: обновление движка меняет результат сильнее, чем смена программы.

Что умеет каждый: форматы, API, сеть, мультимодальность, лицензия

Пара пояснений к таблице. Переход ggml.ai в Hugging Face 20 февраля 2026 года не поменял ни лицензию, ни управление проектом: в анонсе прямо сказано, что команда продолжает поддерживать ggml и llama.cpp на полной занятости, а сообщество принимает технические решения как раньше. Для читателя это ответ на вопрос «а не заброшено ли», который у инфраструктурного проекта возникает первым.

Второе: хранение моделей. llama.cpp и LM Studio работают с файлами GGUF напрямую, поэтому одну скачанную модель можно скормить обоим. Ollama держит веса по хешу в своём хранилище, и переиспользовать их в других программах трудно. На практике это означает, что одна и та же модель на диске лежит дважды. При весе современных сборок в 20–40 ГБ это ощутимо. Плюс сама программа: по замеру It’s FOSS на октябрь 2025 llama.cpp на Windows занимает меньше 90 МБ, установщик LM Studio — 528 МБ, а Ollama — около 4,6 ГБ за счёт вшитых библиотек ROCm и CUDA.

Кому что брать: разработчику, экспериментатору и серверу в сети

Победителя здесь нет, есть три разных ответа на три разных вопроса.

Берите Ollama, если вам нужен локальный эндпоинт за две минуты и вы пишете код вокруг API. Отставание в 10–14% на плотной модели вы не заметите, а сэкономленный вечер настройки — заметите. Обязательно проверьте две вещи: реальную длину контекста на своём сервере (не верьте документации, спросите сам сервер) и OLLAMA_MAX_LOADED_MODELS, если память кончается неожиданно. На MoE-моделях вроде Qwen3 стоит сравнить результат с прямым запуском — там разрыв может оказаться кратным.

Берите LM Studio, если вы подбираете модель, а не строите систему. Каталог с подсказкой по кванту под ваш объём памяти экономит больше времени, чем стоят проценты скорости, а на NVIDIA отставание от прямого llama.cpp измеряется долями процента. На Mac обязательно проверьте, какой рантайм выбран: MLX даёт заметно больше, чем путь через llama.cpp. Для быстрого знакомства с небольшими моделями вроде Phi-4 это самый короткий путь.

Берите llama.cpp напрямую, если вам нужен контроль: точная длина контекста, тип KV-кеша, режим выгрузки слоёв под конкретную MoE-модель, размер микробатча. Плюс новые модели появляются здесь первыми — остальные ждут цикла обновления. Цена — время на сборку и на изучение флагов, а также ответственность за версию: обновление способно как ускорить, так и сломать вашу конфигурацию.

Отдельный случай — сервер на несколько человек. Все три инструмента рассчитаны на одного-двух пользователей. У Ollama OLLAMA_NUM_PARALLEL по умолчанию равен единице, у llama-server параллельные слоты делят общий контекст. Если пользователей больше пяти, задача решается не выбором из этой тройки.

Риски чужих цифр: где сравнение трёх бекендов некорректно

Раздел обязательный, потому что без него таблица выше выглядит точнее, чем она есть.

Мы не гоняли ни одну из этих конфигураций. Ни RTX 5060 Ti, ни M4 Max, ни Radeon 8060S у редакции нет. Каждая цифра в статье — чужой замер с указанием автора, даты и условий. Там, где условий не хватает, это написано прямо в таблице.

Ни в одном найденном замере не названы версии всех трёх инструментов одновременно. Самое близкое — материал по Strix Halo, где перечислены сборки llama.cpp (b9049…b10107) и версии Ollama (0.31.1–0.32.5), но LM Studio там не участвует. С учётом зафиксированной разницы между сборками в 47 раз это принципиальный пробел, а не придирка.

Два самых подробных замера сравнивают разные кванты. У Kapetanovic llama.cpp получил UD-Q4_K_XL против Q4_K_M у Ollama; на Habr — та же картина. Разрыв в 1,6–3 раза оттуда нельзя приписывать обёртке.

Замеры LM Studio на Mac не указывают рантайм. Если внутри работал MLX, сравнение идёт вообще не с llama.cpp. Если GGUF-путь — тогда результат 38,2 tok/s против 46,2 у Ollama выглядит странно и требует перепроверки.

Украиноязычной выдачи по теме практически нет. Запросы на украинском отдают англо- и русскоязычные страницы; проверено 15 августа 2026 года.

Что устареет первым. Быстрее всего — строки таблицы с абсолютными tok/s: они привязаны к сборкам, которые обновляются несколько раз в неделю. Дальше — дефолты Ollama по длине контекста, они уже менялись как минимум дважды. Медленнее всего — лицензии и разделение «движок против оболочки». Проверять свежее состояние стоит там же, где смотрели мы: в тредах замеров llama.cpp на GitHub и в документации самих проектов.

FAQ

Ollama и llama.cpp дадут разный ответ на один и тот же промпт?

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

Можно ли использовать одну скачанную модель во всех трёх программах?

Между llama.cpp и LM Studio — да, оба читают файлы GGUF с диска, достаточно указать путь. С Ollama сложнее: она хранит веса блобами по хешу в своём каталоге, поэтому проще импортировать готовый GGUF внутрь Ollama через Modelfile, чем достать оттуда. На практике одна модель обычно лежит на диске дважды.

Почему на Mac LM Studio иногда быстрее Ollama, а иногда медленнее?

Потому что на Apple Silicon LM Studio считает либо через llama.cpp, либо через MLX, и это два разных движка. Путь MLX на M-чипах существенно быстрее: в замере на M4 Max он дал 126–132 tok/s против 70–72 у llama.cpp. Если рантайм в замере не назван, сравнивать такую цифру не с чем.

Сколько видеопамяти нужно, чтобы контекст на 32 тысячи токенов влез целиком?

Для Llama 3.1 8B по нашему расчёту KV-кеш при f16 займёт 4,0 ГиБ, при квантовании до q8_0 — 2,0 ГиБ. Прибавьте вес самой модели: в библиотеке Ollama сборка на 8 миллиардов параметров занимает 4,9 ГБ. Итого около 9 ГБ плюс служебные буферы, то есть карта на 12 ГБ справится, на 8 ГБ — уже нет.

Что выбрать, если сервер должен обслуживать несколько человек одновременно?

Ни один из трёх не проектировался под многопользовательскую нагрузку: у Ollama число параллельных запросов по умолчанию равно единице, у llama-server параллельные слоты делят общий контекст между собой. До двух-трёх человек это работает, дальше нужен движок с постраничным управлением памятью, рассчитанный на пакетную обработку запросов.

Обязательно ли обновлять llama.cpp, если всё и так работает?

Не обязательно, и иногда вредно. Между сборками случаются как ускорения (заявленные NVIDIA 27% на RTX 5080), так и регрессии — вплоть до падения обработки промпта с 799 до 17 t/s на конкретной архитектуре модели. Разумная тактика: зафиксировать рабочую сборку, обновляться осознанно и после обновления повторять свой замер на своей модели.