llama.cpp чи Ollama: що запускати у 2026 році?

Голий llama.cpp, якщо хочете максимум tokens/секунду і повний контроль; Ollama, якщо хочете встановлення однією командою і API-сервер, що працює з коробки. Ollama — не конкурентний двигун: це Go-сервіс, що упаковує llama.cpp як інференс-бекенд, додає керування моделями (ollama pull llama3.1) і роздає REST API на порту 11434. Тож справжнє питання не «який двигун швидший», а «скільки контролю ви хочете над ручками того двигуна». І оскільки Ollama постачається з консервативними дефолтами (квантування Q4_K_M, помірний контекст, без flash attention до недавна), той самий залізо може видати помітно різні числа. Нижче: що насправді відрізняється, звідки береться розрив у швидкості, та сама модель в обох, і таблиця рішень.

У чому різниця між llama.cpp та Ollama?

llama.cpp — це інференс-двигун: один C/C++-проєкт від автора GGUF Георгія Герганова, що гоняє квантовані моделі на CPU, GPU чи міксі обох. Він дає llama-cli для разових запитів і llama-server — HTTP-сервер, сумісний з OpenAI — плюс кожен прапорець тонкого налаштування, який підтримує двигун: знесення шарів на GPU, квантування KV-кеша, спекулятивне декодування, власні семплери.

Ollama — продукт, нашаруваний над тим двигуном. Вона форкає і вендорить llama.cpp, а потім загортає його в:

• реєстр моделей (ollama pull, ollama list) з автоматичним розрізанням ваг GGUF,
• систему Modelfile (специфікація на кшталт Dockerfile для шаблонів промптів і параметрів),
• фонового демона, що тримає моделі теплими у VRAM і роздає власний REST API,
• автоматичне виявлення заліза з безпечними дефолтами.

Практичний підсумок: з Ollama ви керуєте моделями; з llama.cpp — інференсом. Якщо ви колись хотіли змінити формат квантування, квантувати KV-кеш, підняти контекст понад дефолт або пришити конкретні шари до GPU — це територія llama.cpp. Ollama ховає більшість тих ручок — навмисно.

	llama.cpp	Ollama
Що це	Інференс-двигун (C/C++)	Сервіс, загорнутий навколо llama.cpp
Встановлення	Збірка з сирців чи пакет	Однорядківець-інсталятор, один бінарник
Запуск моделі	llama-cli -m model.gguf + прапорці	ollama run llama3.1
API	Сумісний з OpenAI (llama-server)	Власний REST + сумісний з OpenAI ендпоінт
Керування моделями	GGUF-файли тягнете самі	Реєстр: pull/list/rm
Дефолти	Обираєте все	Безпечні: Q4_K_M, помірний контекст
Оновлення двигуна	День-в-день (upstream)	Відстають від upstream-релізів
Глибина тюнінгу	Повна (KV-квант, spec decode, семплери)	Обмежений пролаз
Найкраще для	Робота над продуктивністю, сервери, edge	Початок, ноутбукові машини

Чи llama.cpp швидший за Ollama?

На одному GGUF-файлі, з одним квантуванням, контекстом і версією llama.cpp — ні, вони в межах шуму один від одного, бо Ollama є llama.cpp, що рахує. Кожен бенчмарк «Ollama повільніша на 30%» — це насправді порівняння дефолтів. Розрив народжується у трьох місцях:

1. Вибір квантування. Реєстр Ollama за замовчуванням бере Q4_K_M. Запустіть ту саму модель як Q5_K_M чи Q6_K у llama.cpp — і отримаєте кращу якість на токен за схожої швидкості, або беріть Q4_0/IQ4 заради голої швидкості.
2. Flash attention і квантування KV-кеша. --flash-attn плюс -ctk q8_0 -ctv q8_0 різко зменшує KV-кеш, що піднімає tokens/сек на довгому контексті і дозволяє втиснути більші контексти в ту саму VRAM. Ollama відкриває лише частину цього.
3. Відставання версії. Оптимізації ядер прибувають у llama.cpp щотижня; Ollama мержить upstream за власним графіком. Свіжа збірка llama.cpp може бути помірно швидшою за місячний бінарник Ollama на тому самому залізі — поки Ollama не наздожене.

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

./build/bin/llama-bench -m Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99 -fa 1

Запустіть її на файлі моделі самої Ollama (~/.ollama/models/blobs/..., перейменованого на .gguf) — і зазвичай точно збігаєтеся з цифрами Ollama, а тоді обганяєте їх, додавши -ctk q8_0 на контексті 16k.

Як запустити ту саму модель в обох?

Обидва їдять GGUF. Мінімум «від нуля до кінця» для кожного:

# --- шлях Ollama: встанови, підтягни, сервуй ---
curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.1:8b        # завантажує Q4_K_M, вантажить у VRAM, відкриває чат

# його API, у стилі, сумісному з OpenAI:
curl -s http://localhost:11434/v1/chat/completions -d '{
  "model": "llama3.1:8b",
  "messages": [{"role": "user", "content": "Say hi in 5 words"}]
}'

# --- шлях llama.cpp: зберіть, завантажте GGUF, сервуйте ---
git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build -DGGML_CUDA=ON    # чи -DGGML_VULKAN=ON / -DGGML_HIP=ON
cmake --build build --config Release -j

huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF 
  Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf --local-dir models

./build/bin/llama-server -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf 
  -ngl 99 --ctx-size 16384 --flash-attn -ctk q8_0 -ctv q8_0 --port 8080

llama-server відкриває схему OpenAI Chat Completions, тож той самий curl на http://localhost:8080/v1/chat/completions працює без змін. Будь-який інструмент, збудований на OpenAI API — скрипти, редактори, RAG-пайплайни — може вказувати на будь-кого з них. Справжню роботу роблять прапорці: -ngl 99 зносить усі шари на GPU, а --flash-attn плюс пара -ctk/-ctv тримає контекст 16k у карті 8 ГБ, від якої дефолти Ollama відмовилися б.

Про вибір самого GGUF-файлу і що означають квант-мітки — у як запустити GGUF-моделі локально.

Коли Ollama логічніша?

Більшості людей варто починати з Ollama, і це не втішний приз:

• Хочете, щоб працювало вже сьогодні ввечері. Одна команда, модель підтягнута, API живий. llama.cpp означає вибір бекенду (CUDA/Vulkan/HIP/Metal), збірку і ручне тяжіння ваг.
• Жонглюєте багатьма моделями. Реєстр, автоматичне вивантаження та Modelfiles б’ють ручне керування теками GGUF-файлів.
• Машина скромна. Дефолти Ollama консервативні не просто так — вони майже завжди вміщуються і працюють.
• Хочете стабільну поверхню API. Демон Ollama керує життєвим циклом моделей, щоб тривало живий сервіс не мусив.

Беріть голий llama.cpp, коли бенчмаркуєте, сервуєте на будь-якому масштабі, живете на телефоні чи Raspberry Pi, потребуєте довгого контексту на малій VRAM або фічі в день мержу в upstream. Досвідчені користувачі часто гонять обидва: Ollama для щоденних моделей і пришита збірка llama.cpp для єдиної роботи, якій потрібні останні 20%.

Якщо ж ваша порівняння — насправді між настільними GUI-застосунками, то це інша вісь — дивіться Ollama vs LM Studio — а для вибору двигуна під задачу, найкращі локальні LLM для кодування покриває модельний бік.

То що використовувати?

Вирішуйте за контролем, не за швидкістю. Двигуни однакові; дефолти — ні. Ставте Ollama, якщо ціль «працює і роздає API» — втратите кілька ручок, які все одно не крутили. Збирайте llama.cpp, якщо ціль — tokens/секунду, довжина контексту чи контроль квантування — отримаєте всі ручки, цінами самостійного керування моделями. В обох випадках ви ганяєте ті самі GGUF-файли, а перемикання потім коштує півдня, не переписування.