Решения

llama.cpp: INT4/INT8 и компактный сервинг LLM

Задача страницы. Показать, как запускать модели в формате GGUF через llama.cpp на тонких инстансах: квантизация INT4/INT8, гибридный режим CPU↔GPU, настройка контекста, стриминг и базовые профили производительности/стоимости.

TL;DR

  • GGUF + INT4/INT8 сильно сокращают память модели и стоимость запуска; хороший выбор для edge/тонких серверов и внутренних инструментов.
  • Гибридный режим: часть слоёв на GPU (-ngl), остальное на CPU — компромисс между p95‑латентностью и ценой.
  • Для чатов включайте стриминг и ограничивайте длину ответа/контекста; для массовых задач — используйте оффлайн‑скрипты main, для API — server.

Когда выбирать llama.cpp

  • Нужен лёгкий сервинг на недорогих инстансах (CPU‑only или 1 тонкий GPU).
  • Требуется максимальная экономия памяти за счёт INT4/INT8 и сжатых форматов весов (GGUF).
  • Важны простота деплоя (один бинарник) и низкие зависимые расходы (без тяжёлых фреймворков).

Альтернативы:
 — максимум TPS при больших очередях → /solutions/llm-inference/vllm/
 — минимальная p95‑латентность на H100 → /solutions/llm-inference/tensorrt-llm/
 — универсальный REST‑сервинг с пулами моделей → /solutions/llm-inference/tgi/

Подготовка весов: HF → GGUF → квантизация

A) Конвертация HF‑весов в GGUF

				
					# Пример: путь к HF-весам в ./hf_model, выходной GGUF в f16
python3 convert-hf-to-gguf.py ./hf_model --outfile ./llama3-8b-f16.gguf

B) Квантизация GGUF

				
					# Сбалансированный профиль качества/памяти (Q4_K_M)
./quantize ./llama3-8b-f16.gguf ./llama3-8b-q4_k_m.gguf Q4_K_M

# Более высокое качество (Q5_K_M), ценой памяти/скорости
./quantize ./llama3-8b-f16.gguf ./llama3-8b-q5_k_m.gguf Q5_K_M

# Минимальный размер (например, Q2_K) — для самых тонких машин
./quantize ./llama3-8b-f16.gguf ./llama3-8b-q2_k.gguf     Q2_K

Практический ориентир по объёму (порядок величин):
 • 7–8B в Q4_K_M ≈ 4–5 ГБ; Q5_K_M ≈ 6–7 ГБ.
 • 13B в Q4_K_M ≈ 8–10 ГБ. Точные значения зависят от модели/словаря.

Запуск сервера (HTTP, стриминг)

Старт сервера 

				
					./server \
  -m ./llama3-8b-q4_k_m.gguf \
  -c 4096 \
  -t 12 \
  -ngl 20 \
  --host 0.0.0.0 \
  --port 8081 \
  --timeout 120
# Опции по ситуации: --no-mmap, --mlock
  • -c — длина контекста (вход + выход);
  • -t — число потоков CPU;
  • -ngl — сколько слоёв выгрузить на GPU (0 = чистый CPU); повышайте до упора по VRAM;
  • —timeout — общий тайм‑аут запроса.

Пример запроса (OpenAI‑совместимый, стриминг SSE) 

				
					curl -N http://localhost:8081/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3-8b-q4_k_m",
    "messages": [
      {"role":"system","content":"You are concise."},
      {"role":"user","content":"Объясни внимание в трансформерах за 3 пункта."}
    ],
    "stream": true,
    "max_tokens": 200,
    "temperature": 0.2
  }'

Профили эксплуатации (выберите под SLA/бюджет)

A) CPU‑only (минимальная стоимость)

  • Квантизация: Q4_K_M или Q2_K для совсем ограниченной памяти.
  • Команда: -ngl 0, -t = ядра CPU (подбирайте эмпирически).
  • Сценарии: оффлайн‑генерации, внутренние инструменты, RAG‑ретривер с небольшими ответами.

B) Гибрид CPU↔GPU (тонкий GPU)

  • Цель: снизить p95 за счёт переноса части слоёв на GPU.
  • Команда: -ngl 10–32 (в зависимости от VRAM), оставить разумное -t для CPU.
  • Сценарии: чат‑сервисы/ассистенты с умеренной нагрузкой.

C) GPU‑перевес (минимум CPU‑offload)

  • -ngl максимально возможный (влезает в VRAM); уменьшите -t до уровня токенизации/оркестрации.
  • Сценарии: строгие задержки при умеренном QPS на одном узле.

Контекст, KV‑кэш и лимиты

Память под KV‑кэш растёт ~линейно с длиной контекста и числом одновременных запросов. Практика:

  • Держите умеренный -c (например, 2–4 K), ограничивайте max_tokens на запрос.
  • Разделяйте трафик на короткие и длинные запросы (две реплики/пула).
  • Для чат‑сценариев используйте стриминг — пользователь видит ответ раньше даже при ограниченном TPS.

Подробнее про стриминг/пулы:
 /solutions/llm-inference/streaming/, /solutions/llm-inference/multi-model/

Качество vs скорость: какие кванты выбрать

  • Q4_K_M — «золотая середина» для RU/EN‑чатов и многих задач.
  • Q5_K_M / Q6_K — лучше качество, выше задержки и память.
  • Q2_K / Q3_K — самый низкий след памяти для edge/CPU‑only, может страдать точность на сложных задачах.
  • INT8 (Q8_0) — близко к FP16 по качеству, но требует больше памяти; разумно для небольших моделей на мощных CPU/GPU.

Стоимость и планирование

Обозначим: TPS_decode — токены/с на декоде, T — латентность одного запроса, B — «эффективный» батч (обычно 1 для серверов на CPU).

Оценки:

				
					QPS ≈ B / T
Tokens_per_hour ≈ TPS_decode × 3600
Cost_per_1M_tokens ≈ (GPU_or_CPU_hour_price × Num_nodes) / (Tokens_per_hour / 1e6)

Снижаем цену за 1М токенов: квантизация «ниже», ограничение max_tokens, гибридный режим -ngl, стриминг, несколько лёгких реплик вместо одной «тяжёлой».

Дополнительно: /solutions/llm-inference/costs/, /solutions/cost-planner/

Наблюдаемость и эксплуатация

Минимальный набор метрик:

  • Latency p50/p95/p99, tokens/sec, доля timeouts.
  • CPU/GPU: загрузка, частота, температура, использование HBM/DRAM.
  • Кэш/контекст: текущий -c, одновременность, «хвосты» по длинным запросам.
  • Система: дисковые I/O (логи/веса), сеть (стрим).

Смотрите: /solutions/monitoring-logging/, /solutions/llm-inference/observability/

Траблшутинг

  • Высокая p95 на CPU‑only. Уменьшите -c и max_tokens, переходите на Q4_K_M (если было Q5/FP16), поднимите -ngl на тонком GPU.
  • GPU‑OOM при -ngl. Понизьте число слоёв на GPU, выберите более «лёгкий» квант (Q4_K_M → Q4_K_S), сократите контекст.
  • Низкий TPS. Проверьте конкуренцию CPU‑потоков, уменьшите температуру/стохастику для детерминированных задач, используйте несколько реплик за балансировщиком.
  • Нестабильный запуск/краши. Отключите —mlock/—no-mmap, проверьте права и лимиты ОС, храните GGUF на локальном NVMe.
  • Качество «плывёт» после квантизации. Поднимите уровень кванта (Q4→Q5/Q6) или ограничьте длины/сложность задач, держите промпт‑шаблоны стабильными.

Как запускать это в cloudcompute.ru

  • Шаблон “llama.cpp‑Serve” в /solutions/templates/:
     – профили cpu‑only / hybrid / gpu‑first;
     – готовые скрипты конвертации в GGUF и квантизации;
     – сервис server с healthcheck и логами запросов.
  • Для сценариев с несколькими моделями или пиками трафика — смотрите /solutions/llm-inference/multi-model/.
  • Для расчёта стоимости и SLA — /solutions/llm-inference/costs/, /solutions/cost-planner/.

Чек‑лист перед продом

  • Весы в GGUF, протестированы уровни квантизации (качество/латентность).
  • Выбран профиль: cpu‑only / hybrid / gpu‑first, настроены -t, -ngl, -c.
  • В API ограничены max_tokens, включён стриминг.
  • Настроены метрики/логи/алерты; проверены «хвосты» p95/p99.
  • Продуман фоллбек: вторая реплика/модель, снижение контекста/кванта при перегрузе.

Навигация по разделу «Инференс LLM»

Обзор: /solutions/llm-inference/

Альтернативные стеки: /solutions/llm-inference/vllm/, /solutions/llm-inference/tgi/, /solutions/llm-inference/tensorrt-llm/

Производительность и стоимость: /solutions/llm-inference/quantization/, /solutions/llm-inference/costs/, /solutions/llm-inference/streaming/

Эксплуатация: /solutions/llm-inference/observability/, /solutions/monitoring-logging/