Главная / Статьи / LLMOps для небольших языковых моделей: фреймворки обслуживания и руководства по внедрению в производство

LLMOps для небольших языковых моделей: фреймворки обслуживания и руководства по внедрению в производство

Почему SLMs превосходят по стоимости и уровню конфиденциальности, как сравниваются 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» или «снижение количества токенов в секунду до уровня p95 после обновления драйвера».

Что такое LLMOps и чем он отличается от MLOps?

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

Если MLOps проверяет, произошла ли регрессия точности, то LLMOps также учитывает:

Эффективно ли движок обслуживания использует память GPU при одновременной работе?
Остается ли квантизированный результат достаточно точным для выполнения задачи?
Закреплены ли версии промптов и инструментов, и возможно ли их возврат к предыдущей версии?

Может ли трафик перенаправляться между моделями без изменения кода клиента?

Показывают ли логи стоимость токенов и задержку для каждого маршрута?

В остальной части этого руководства даются ответы на эти вопросы именно для SLM.

Панорама фреймворков развертывания SLM

Что касается чистой пропускной способности GPU, vLLM является популярным выбором для высокой нагрузки благодаря API, совместимому с OpenAI, на GPU NVIDIA или AMD. SGLang конкурирует в тех случаях, когда важно повторное использование префиксов и структурированная генерация. Hugging Face TGI подходит командам, уже использующим стандартизированные инструменты Hub и Helm.

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

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

Подробный обзор фреймворков

vLLM

vLLM сделал популярной технологию PagedAttention, которая управляет кэшем KV подобно виртуальной памяти, тем самым сокращая расход GPU RAM при обработке параллельных последовательностей. Постоянная группировка запросов помогает поддерживать высокую степень использования ресурсов.

# 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 и периферийных устройств без 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 и сценариев, критичных к задержкам. Преимущества: максимальная производительность после компиляции. Недостатки: движки специфичны для конкретных моделей и форматов; перекомпиляция требуется при изменениях аппаратного обеспечения или настроек пакетов.

Выбор фреймворка: руководство по принятию решений

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

Вопрос 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/устройства периферии → llama.cpp; обёртка DX → Ollama
Браузер/офлайн-клиент → WebLLM/MLC
Windows/NPU/стандарт ONNX → ONNX Runtime GenAI
Оценка по нажатию → LM Studio

Корпоративные системы с агентами против всего остального

Трафик запросов/ответов с однократным обменом данными отлично подходит для непрерывной группировки операций в vLLM. Корпоративные агенты могут вызывать модель десятки раз в процессе выполнения задач — планирование, выбор инструментов, сбор данных, перепланирование — поэтому критически важны кэширование префиксов и структурированный вывод информации. Такие решения часто реализуются с использованием SGLang или TensorRT-LLM + Triton на самостоятельно размещенных GPU, причем TGI служит альтернативой в тех случаях, когда интеграция с Hub имеет большее значение, чем максимальная пропускная способность.

Платформы агентов с несколькими тенантами также требуют настройки квот для каждого пользователя, отслеживания действий в ходе вызовов инструментов и возможности одновременного отката пар запроса+модели — это вопросы, связанные с LLMOps и актуальные для любого инструментария.

Руководство по развертыванию в производстве

Запуск системы составляет примерно пятую часть всей работы. Остальное — это поддержание ее корректности, экономичности и безопасности.

Считайте квантизацию, реестр моделей, оценку их качества, использование канарейских версий и маршрутизацию частью единого цикла, через который проходит каждая версия модели:

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.
Использование изменений в промптах как бесплатных ресурсов при фиксации версий моделей — или наоборот.

Основные выводы

СЛМ-модели эффективны, когда задачи ограничены, данные не могут покидать определенную среду, или бюджеты на затраты и задержки не позволяют использовать передовые модели.
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 и что происходит, когда маркетинговая кампания за одну ночь увеличивает количество запросов в три раза. Ответьте на них письменно до начала тестирования с использованием канарейских версий.

Планирование мощностей для SLM всё ещё требует запаса пропускной способности для роста KV-кэша с учётом длины контекста. Модель объёмом 1,5 млрд параметров, кажущаяся незначительной при длине контекста 2 килобайта, может создать нагрузку на память, когда клиенты открывают окна длиной 32 килобайта. Необходимо отслеживать количество токенов контекста на уровне p95 отдельно от частоты запросов.

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

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

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

Наконец, ежеквартально анализируйте ситуацию с использованием «более крупных моделей» на основе данных. Если показатель качества работы SLM остается на прежнем уровне, в то время как сложность задач пользователей растет, следует проводить выборочную замену моделей — поэтапно, а не заменять всю систему сразу. Управление моделями типа LLMOps для SLM предполагает как ускорение работы, так и соблюдение ограничений.

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

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

Все статьи Прислать бриф