Головна / Статті / LLMOps для невеликих мовних моделей: фреймворки обслуговування та посібники з експлуатації в промислових умовах

LLMOps для невеликих мовних моделей: фреймворки обслуговування та посібники з експлуатації в промислових умовах

Чому моделі SLM мають перевагу за ціною та приватністю, як порівнюються vLLM, SGLang, TGI, llama.cpp, Ollama, WebLLM, ONNX та TensorRT-LLM, і як квантувати, оцінювати та використовувати їх у продакшені.

4127 слів

Практичний підхід до LLMOps для компактних мовних моделей: коли локальна або пристрійна обробка даних краща за сучасні API, які стеки обслуговування підходять до певних обмежень апаратного забезпечення та як підтримувати їхню працездатність після першого успішного запиту.

Вступ

Між підходом «налаштовувати найбільшу модель для всього» та «запускати модель з кількістю параметрів менше мільярда на телефоні» змінилися пріоритети у виробництві. Багато завдань — класифікація намірів, направлення запитів до інструментів, структуроване вилучення даних, переранжування інформації за принципом RAG — не вимагають моделей найвищого рівня, якщо є надійна модель SLM, яку можна ефективно квантувати та використовувати.

Проблема полягає у тому, що модель SLM без стратегії обслуговування є лише контрольним пунктом на диску. Її запуск у виробничому середовищі створює проблеми з пам’яттю GPU, групуванням запитів, точністю квантування, можливістю скасування змін та оцінкою ефективності, які майже не розглядаються у класичних посібниках з MLOps.

Модель, яку неможливо розгорнути, контролювати чи скасувати, не є продуктивним активом — це тягар із привабливими показниками бенчмарку.

У цьому посібнику розглядаються проблема, сучасні підходи та інструкції для експлуатації в умовах продакшну — у такій послідовності. Процес є безперервним: контрольна точка стає функціональною лише після проходження перевірок на придатність, оцінки та операційних критеріїв.

Проблема: чому «більша модель» більше не є стандартним рішенням

1. Витрати та затримки зростають у масштабі

Надсилання простого запиту на класифікацію тикетів до моделі об’ємом 70 мільярдів параметрів є марною тратою ресурсів. Додаткові параметри забезпечують функціонал, який може знадобитися, але водночас збільшують кількість GPU-секунд та затримки під час одночасної роботи. У масштабах продукту саме ці витрати стають домінуючими.

2. Вплив даних та приватність спонукають до обробки інформації безпосередньо на краю мережі

У сферах охорони здоров’я, фінансів та додатків для споживачів, які працюють безпосередньо на пристроях, часто неможливо надсилати необроблений текст до API сторонньої організації. Модель SLM, яка поміщається у кілька гігабайт оперативної пам’яті, може знаходитися поруч із даними — на локальних GPU, ноутбуках чи телефонах — відповідаючи вимогам щодо розташування даних, яких не може задовольнити модель, що працює в хмарі.

3. Інфраструктура обслуговування має власні способи збою

Обслуговування моделей зазнає збоїв не так, як звичайні помилки додатків: фрагментація пам’яті GPU через недбале розподілення кешу KV, проблеми з планувальником через раптові сплески трафіку, неузгодженості під час квантовання, які тихо погіршують якість, а також проблеми з початковим запуском моделі, які порушують встановлені показники продуктивності після зменшення масштабу до нуля.

4. LLMOps — це окрема галузь порівняно з MLOps

Класичні підходи MLOps передбачають відносно стабільну форму та детерміновані результати. LLMOps додає недетерміновані версії тексту, запитів та інструментів, механізми керування токенами та фільтри безпеки. Регресія більше не означає лише „точність знизилась на 2%“ — це також може бути „недотримання схеми JSON“ або „зниження кількості токенів/секунду після оновлення драйвера“.

Що таке LLMOps та чим він відрізняється від MLOps?

LLMOps охоплює процеси розгортання, хостингу, контролю та вдосконалення мовних моделей у реальних системах із такою ж рівнем серйозності, як і для будь-якої іншої критично важливої послуги.

Якщо MLOps перевіряє, чи не відбулась регресія точності, то LLMOps також перевіряє:

Чи ефективно двигун обробки використовує пам’ять GPU за умов конкурентності?
Чи залишається квантований результат достатньо точним для виконання завдання?
Чи зафіксовані версії запитів/інструментів та чи можливе їх скасування?

Чи може трафік переміщуватися між моделями без переписування клієнта?

Чи відображають логи витрати токенів та затримку для кожного маршруту?

Решта цього посібника відповідає на ці запитання саме щодо SLM.

Пейзаж фреймворків для розгортання SLM

Щодо первинної пропускної здатності GPU, vLLM є поширеним вибором для високої кількості запитів із API, сумісним з OpenAI, на GPU NVIDIA чи AMD. SGLang конкурує там, де важливе повторне використання префіксів та структуроване генерування. Hugging Face TGI підходить командам, які вже стандартизувалися на Hub та Helm charts.

Щодо портативних рішень, llama.cpp / GGUF працює на CPU, Apple Silicon та багатьох графічних процесорах для споживачів. Ollama об’єднує ці інструменти для двокомандної роботи безпосередньо на пристрої. LM Studio додає графічний інтерфейс для оцінки якості. MLC-LLM / WebLLM призначені для роботи в браузерах та на мобільних пристроях. ONNX Runtime GenAI підтримує Windows/NPU та корпоративні стандарти ONNX. TensorRT-LLM + Triton забезпечують максимальну продуктивність на архітектурі NVIDIA після попередньої компіляції.

Кожен з цих інструментів перетворює дані з точки контролю на відповіді; вони відрізняються за припущеннями щодо обладнання, вагою операцій та конструкцією паралельної обробки.

Детальний огляд фреймворків

vLLM

vLLM популяризував технологію PagedAttention, яка керує кешем KV схоже на віртуальну пам’ять, завдяки чому паралельні послідовності витрачають менше оперативної пам’яті GPU. Постійне групування даних підтримує високий рівень використання пристрою.

# Install vLLM
pip install vllm

# Serve using VLLM
vllm serve Qwen/Qwen2.5–1.5B-Instruct - port 8000 # fully OpenAI-compatible endpoint


# Make Request
curl http://localhost:8000/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
  "model": "Qwen/Qwen2.5–1.5B-Instruct",
  "messages": [{"role": "user", "content": "Write a haiku about model quantization"}]
}'

# Python Script for vllm

from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")
resp = client.chat.completions.create(
    model="Qwen/Qwen2.5–1.5B-Instruct",
    messages=[{"role": "user", "content": "Summarize LLMOps in one sentence."}],
)
print(resp.choices[0].message.content)

Найкраще підходить для: бекендів із високою кількістю запитів на секунду та сервісів RAG, яким потрібні кінцеві точки, сумісні з OpenAI. Переваги: пропускна здатність, охоплення моделей, формати квантації (AWQ/GPTQ/FP8). Недоліки: орієнтація на GPU; все ще потребує оркестрації для забезпечення високої доступності.

SGLang

SGLang базується на RadixAttention для спільного використання кешів префіксів у між запитами — що корисно для циклів агентів із повторюваними системними запитами — та містить DSL sgl.function для структурованої генерації.

# Installation
pip install "sglang[all]"

# SGLang launch server
python -m sglang.launch_server \
 - model-path Qwen/Qwen2.5–1.5B-Instruct \
 - port 30000


# CURL Request
curl http://localhost:30000/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
  "model": "Qwen/Qwen2.5–1.5B-Instruct",
  "messages": [{"role": "user", "content": "Write a haiku about model quantization"}]
}'

import sglang as sgl

@sgl.function
def classify(s, ticket):
  s += sgl.user(f"Classify this support ticket as billing/technical/other: {ticket}")
  s += sgl.assistant(sgl.gen("label", max_tokens=8))

sgl.set_default_backend(sgl.RuntimeEndpoint("http://localhost:30000"))
state = classify.run(ticket="My invoice charged me twice this month")
print(state["label"])

Найкраще підходить для: конвеєрів агентів та обмежених форматів вихідних даних у форматі JSON. Переваги: повторне використання префіксів, структурований вихід. Недоліки: менша екосистема, ніж у vLLM; працює лише з GPU.

Hugging Face Text Generation Inference (TGI)

TGI інтегрується в екосистему Hub завдяки пакетації, сумісній з Docker/Kubernetes.

docker run - gpus all -p 8080:80 \
-v $PWD/data:/data \
ghcr.io/huggingface/text-generation-inference:latest \
 - model-id microsoft/Phi-3.5-mini-instruct \
 - quantize bitsandbytes-nf4

from huggingface_hub import InferenceClient
client = InferenceClient("http://localhost:8080")
print(client.text_generation("Explain quantization in one line.", max_new_tokens=64))

Найкраще підходить для: команд, орієнтованих на Hub, та систем з регулюванням, які потребують підтримуваного шляху обслуговування. Переваги: інтеграція з Hub, опції квантування, підтримка Helm. Недоліки: деякі завдання все ще віддають перевагу vLLM за рахунок більшої пропускної здатності; необхідно стежити за умовами ліцензії з часом.

llama.cpp / GGUF

Створений для роботи з LLaMA на CPU MacBook, llama.cpp є основою багатьох локальних/периферійних рішень SLM завдяки квантуванню у форматі GGUF.

# macOS: brew install llama.cpp   |   or build from source:
# git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp && cmake -B build && cmake --build build

# Pull a quantized SLM straight from Hugging Face and serve an OpenAI-compatible endpoint
llama-server -hf Qwen/Qwen2.5-0.5B-Instruct-GGUF:Q4_K_M \
    --port 8090 -c 4096 -ngl 999   # -ngl offloads layers to GPU if available (Metal/CUDA)

curl http://localhost:8090/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"messages":[{"role":"user","content":"What is GGUF?"}]}'

Найкраще підходить для: серверів на CPU, Apple Silicon, пристроїв Pi/edge без CUDA. Переваги: портативність, розвинена система квантування, ліцензія MIT. Недоліки: пропускна здатність при одночасній роботі поступається стекам, оптимізованим під GPU.

Ollama

Ollama перетворює llama.cpp на інструмент для розробників з можливістю швидкого завантаження та виконання за допомогою локального HTTP API.

ollama pull qwen2.5:1.5b
ollama run qwen2.5:1.5b "Write a haiku about model quantization"

import requests
r = requests.post("http://localhost:11434/api/chat", json={
  "model": "qwen2.5:1.5b",
  "messages": [{"role": "user", "content": "Give me 3 LLMOps metrics to track"}],
  "stream": False,
})
print(r.json()["message"]["content"])

Найкраще підходить для: локальної розробки, створення прототипів та самостійного розміщення на сервері в малих командах. Переваги: зручність використання та налаштування за замовчуванням. Недоліки: не призначений для високонавантажених продакшн-середовищ.

LM Studio

Графічний інтерфейс для роботи на ПК, який дозволяє переглядати, завантажувати та спілкуватися за допомогою подібних локальних двигунів; крім того, є сервер, сумісний з OpenAI, який можна активувати одним кліком для демонстрацій. Ідеальний для оцінки перед створенням налаштувань розгортання; це не компонент інфраструктури, який можна використовувати у масштабних системах.

MLC-LLM / WebLLM

Створені на основі Apache TVM: MLC компілює моделі для різних бекендів; WebLLM працює повністю у браузері.

pip install mlc-llm

mlc_llm chat HF://mlc-ai/Qwen2.5-1.5B-Instruct-q4f16_1-MLC

// WebLLM: fully in-browser inference, no backend server
import * as webllm from "@mlc-ai/web-llm";

const engine = await webllm.CreateMLCEngine("Qwen2.5-1.5B-Instruct-q4f16_1-MLC");
const reply = await engine.chat.completions.create({
  messages: [{ role: "user", content: "Explain WebGPU inference simply." }],
});
console.log(reply.choices[0].message.content);

Найкраще підходить для: мобільних додатків, обробки даних на клієнтському боці зі збереженням приватності, функцій офлайн-роботи. Переваги: можливість компіляції для різних цільових систем; відсутність сервера для WebLLM. Недоліки: складність компіляції; обмеження пристроїв у браузерах.

ONNX Runtime GenAI

API GenAI від Microsoft розширює можливості ONNX Runtime для авторегресивної генерації з управлінням кешем KV через Windows DirectML та NPUs.

pip install onnxruntime-genai

python -c "
import onnxruntime_genai as og
model = og.Model('phi-3.5-mini-onnx-directml')
tokenizer = og.Tokenizer(model)
tokens = tokenizer.encode('Explain ONNX Runtime GenAI briefly.')
params = og.GeneratorParams(model)
params.set_search_options(max_length=200)
generator = og.Generator(model, params)
generator.append_tokens(tokens)
while not generator.is_done():
    generator.generate_next_token()
print(tokenizer.decode(generator.get_sequence(0)))
"

Найкраще підходить для: додатків, створених спеціально для Windows, та підприємств, що використовують стандарт ONNX. Переваги: можливість перенесення додатку після експорту. Недоліки: труднощі під час конвертації; менша кількість користувачів порівняно з двигунами, створеними на основі PyTorch.

NVIDIA TensorRT-LLM + Triton Inference Server

TensorRT-LLM здійснює попередню компіляцію двигунів із об’єднаними ядрами; Triton дозволяє керувати багатьма моделями одночасно.

# Build a TensorRT-LLM engine for a small model (simplified)
trtllm-build --checkpoint_dir ./qwen2.5-1.5b-checkpoint \
    --output_dir ./qwen2.5-1.5b-engine \
    --gemm_plugin float16

# Serve via Triton
tritonserver --model-repository=/models

Найкраще підходить для: максимальної продуктивності флоту NVIDIA та сценаріїв, де критично важлива затримка. Переваги: максимальна продуктивність після компіляції. Недоліки: двигуни є специфічними для конкретних SKU та форматів; їх необхідно перекомпілювати після змін апаратного забезпечення чи профілів обробки.

Вибір фреймворку: посібник з прийняття рішень

Ментальна модель: три запитання, а не список функцій

Запитання 1: Де саме має працювати модель? Браузер чи телефон без мережевого з’єднання → WebLLM/MLC. CPU/Apple/edge без CUDA → llama.cpp/Ollama. Лише після цього варто розглядати двигуни на GPU у дата-центрах.

Запитання 2: Це для продакшн-використання чи досліджень? Дослідження → LM Studio чи Ollama. Продакшн-API → vLLM/SGLang/TGI/TensorRT залежно від наступного запитання.

Запитання 3 (лише виробництво GPU): Яка форма трафіку, і який обсяг бюджету на інженерію є? Незалежні одноразові виконання → vLLM за замовчуванням. Високо повторювані префікси агентів/структуровані результати → SGLang. Максимальна оптимізація від NVIDIA з інвестиціями в платформу → TensorRT-LLM + Triton. Зручність використання Hub/Helm → TGI.

Компресовані джерела інформації:

Максимальна пропускна здатність API GPU → vLLM (або SGLang у разі повторюваних операцій)
Абсолютний максимум продуктивності від NVIDIA з бюджетом на компіляцію → TensorRT-LLM + Triton
CPU/Apple/edge → llama.cpp; обгортка DX → Ollama
Браузер/офлайн-клієнт → WebLLM/MLC
Стандарт Windows/NPU/ONNX → ONNX Runtime GenAI
Оцінка за кліком → LM Studio

Корпоративні агентські системи проти всього іншого

Single-turn request/response traffic loves continuous batching on vLLM. Enterprise agents may call the model tens of times per task—planning, tool choice, observation, replan—so prefix caching and structured outputs dominate. Those deployments often land on SGLang or TensorRT-LLM + Triton on self-hosted GPUs, with TGI as an alternative when Hub integration outweighs peak throughput.

Multi-tenant agent platforms also need per-principal quotas, trace baggage across tool calls, and clear rollback of prompt+model pairs together—LLMOps concerns that sit above any one engine.

Production Deployment Guide

Getting something running is roughly a fifth of the work. The rest is keeping it correct, cheap, and safe.

Treat quantization, registry, evaluation, canaries, and routing as one loop every model version travels:

1. Стратегія квантування. У багатьох продакшн-сценаріях SLM за замовчуванням використовується AWQ-4bit або GGUF Q4_K_M — при ретельній оцінці це зазвичай дає результати, що відрізняються на кілька відсотків від показників FP16, — і необхідно переконатися, що обраний двигун підтримує цей формат. Квантування — це не одноразова конвертація; воно завершується на етапі оцінки, а не після виконання команди конвертації.

2. Версіонування моделей та реєстр. Тонкі налаштування та квантовані версії моделей слід розглядати як незмінні об’єкти з версіями — їх ніколи не слід перезаписувати на місці. MLFlow, репозиторії Hugging Face Hub із дайджестами чи внутрішній реєстр OCI для зберігання об’єктів — усе це підходить, якщо дайджести вказані у маніфестах розгортання.

3. Етапи оцінки. Для кожного завдання необхідно визначити ключові показники: значення F1 для класифікації, точність вилучення даних, частка коректних схем, правильність відхилення некоректних запитів та ліміти затримки. Не дозволяйте переходу до продакшн-режиму, якщо ці показники не відповідають нормам, навіть якщо демонстраційні версії виглядають краще.

4. Топологія обробки. У разі потреби розділяйте процеси токенізації/попередньої обробки на CPU від робочих процесів на GPU; автоскейлуйте систему залежно від глибини черги та використання GPU, а не лише кількості запитів на секунду. Зберігайте резервний пул процесорів, якщо початок роботи системи з нуля порушує встановлені показники якості.

5. Наглядовість. Експортуйте дані про затримку обробки запитів, кількість токенів вхідних/вихідних, частку успішних запитів до кешу, розмір пакетів даних та кількість випадків нестачі пам’яті чи повторних спроб. Ретельно обирайте зразки запитів відповідно до правил конфіденційності.

6. Відкати. Використовуйте підхід blue/green або canary, орієнтуючись на сукупність параметрів моделі та версії запиту. Миттєво відкладіть обидві версії у разі різкого погіршення якості.

7. Тестування типу A/B та маршрутизація за моделями

Маршрутизуйте запити відповідно до завдань: використовуйте моделі SLM для класифікації та вилучення інформації; більші моделі — для створення тексту з відкритою структурою. Перед повною заміною тестуйте роботу потенційних моделей на паралельних потоках. Відстежуйте витрати на кожне успішно виконане завдання, а не лише кількість токенів, щоб дешевша модель, яка потребує двох спроб, не отримувала хибного „перемоги“.

Флаги функцій мають пов’язувати клієнтські маршрути з іменованими кінцевими точками моделей, розташованими за гейтвеєм, щоб заміна моделей не вимагала випуску нової версії додатку.

Сценарії використання

Додатки для споживачів/мобільні додатки

Віддавайте перевагу SLM, які працюють безпосередньо на пристрої або поблизу нього, за допомогою MLC/WebLLM чи GGUF у середовищах виконання на пристрої. Ретельно керуйте обсягом пам’яті; використовуйте стрімінг токенів для покращення користувацького досвіду; зберігайте можливість роботи в хмарі для складних запитів за чіткого згоди користувача.

Інші сфери застосування (асистенти-копілоти, внутрішні системи RAG, краєві гейтвеї) слідують тому ж шаблону: спочатку визначайте можливості обладнання, потім вибирайте двигун обробки даних, а нарешті — механізм квантування та оцінки.

Антипатерни

Використання формату FP16 «через кращу якість», не перевіривши базовий рівень продуктивності у квантованому варіанті на реальних завданнях
Застосування топологій Ollama/LM Studio у продакшні з високою частотою запитів без двигуна обробки, створеного для паралельної роботи
Перезапис модельних файлів на місці, через що відкати стають неможливими

Оцінка відбувається лише за показниками атмосфери, а не за якістю результатів.

Ігнорування кешу KV та метрик пакетних обчислень до моменту виникнення проблем з пам’яттю GPU у продакшені.

Розгляд змін запитів як безкоштовних, при цьому фіксуючи версії моделей — або навпаки.

Основні висновки

SLM ефективні, коли завдання є вузькоспрямованими, дані не можуть покидати систему чи коли бюджети на витрати та затримки не дозволяють використовувати передові моделі.
LLMOps розширює MLOps завдяки ефективності обслуговування, точності квантування, версіонуванню запитів/інструментів та економіці токенів.
Вибирайте двигуни відповідно до місця розміщення (пристрій/CPU/GPU), етапу роботи (дослідження чи обслуговування) та характеру трафіку (одноразове використання чи автономна робота).
Успіх у продакшені — це цикл: квантування → реєстрація → оцінка → тестування → спостереження → скасування змін.
Поєднуйте стабільні агрегати моделей із механізмом маршрутизації типу „дзвінок у двері“, щоб клієнти залишалися стабільними під час еволюції бекенду.

Джерела

Для отримання інформації про прапорці встановлення та фіксацію версій перегляньте офіційну документацію кожного проекту: vLLM, SGLang, Hugging Face TGI, llama.cpp, Ollama, LM Studio, MLC-LLM/WebLLM, ONNX Runtime GenAI та NVIDIA TensorRT-LLM/Triton. Керівництва з апаратного забезпечення від NVIDIA та документація Apple Metal доповнюють README-файли двигунів під час налаштування розмірів пакетів та процесу квантації.

Тримайте внутрішню інструкцію, у якій буде записано, які інструменти обробки працювали з якими наборами даних на конкретних моделях GPU — саме цей документ перетворює цей посібник у функціональну платформу.

Додаток: Керування SLM протягом другого тижня до двадцятого тижня

Після першої успішної спроби зв’язку через curl із локальним сервером виникають складні запитання: хто несе відповідальність у разі аварії, як планувати оновлення драйверів CUDA та що робити, якщо маркетингова кампанія втричі збільшує кількість запитів на секунду протягом ночі. Відповідайте на них у письмовій формі ще до початку перших тестів.

Планування пропускної здатності для SLMs все ще потребує запасу місця для зростання KV-кешу у залежності від довжини контексту. Модель об’ємом 1,5 млрд параметрів, яка здається дуже маленькою при 2 кб контексту, може створити тиск на пам’ять, коли клієнти відкривають вікна об’ємом 32 кб. Слід відстежувати кількість токенів контексту на рівні p95 окремо від частоти запитів.

Перевірки безпеки мають охоплювати ланцюжок постачання моделей: перевірку чексумів під час завантаження, те, хто може опублікувати їх у реєстрі, та чи потрапляють системні запити з конфіденційною інформацією до пакетів клієнтів. Моделі, які працюють безпосередньо на пристрої, потребують каналів оновлень настільки ж ретельних, як і випуски мобільних додатків.

При аналізі витрат слід порівнювати загальну суму власності: вартість оренди GPU, час інженерів на перебудову моделей у формат TensorRT та кількість проблем з якістю, спричинених агресивною квантацією. Іноді трохи більша модель SLM у форматі 8 біт коштує дешевше, ніж дуже мала модель, яка змушує вдаватися до ручного втручання.

Навчання команди має велике значення. Надайте інженерам з розробки додатків готову основу: чарт Helm або файл Compose, стандартну URL-адресу, сумісну з OpenAI, та вже налаштовані панелі керування. Надайте інженерам з машинного навчання можливість публікувати результати обробки даних, які проходять всі перевірки. Більшість проблем виникає під час передачі роботи між цими групами.

Нарешті, щокварталу переглядайте питання використання „більших моделей“ на основі даних. Якщо показник ефективності SLM залишається на одному рівні, тоді як завдання користувачів стають складнішими, необхідно впроваджувати зміни вибірково — залежно від ситуації, а не замінювати всю систему миттєво. LLMOps для SLM так само передбачає стриманість, як і прискорення розвитку.

Примітка щодо експлуатації: фіксуйте точні версії компонентів для CUDA у файлах lockfile та записуйте версію драйвера поруч із кожним успішним варіантом програми, щоб під час інцидентів можна було визначити джерело проблем у різних шарах програмного та апаратного забезпечення.

Примітка щодо експлуатації: фіксуйте точні версії компонентів CUDA у файлах блокування, а також записуйте версію драйвера поруч із кожним успішним варіантом тестування, щоб під час інцидентів можна було розділити проблеми на частини між програмним та апаратним рівнями.

Усі статті Надіслати бриф