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 і в документації самих проєктів.

Часті запитання

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 на конкретній архітектурі моделі. Розумна тактика: зафіксувати робочу збірку, оновлюватися свідомо і після оновлення повторювати свій замір на своїй моделі.