Галоўная / Артыкулы / 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, якая помешчаецца ў кальколях гігабайтаў памяці RAM, можа знаходзіцца пры самых данных — на локальных 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 больш саадповедна віртуальнай памяці, таму секвэнцыяў, якія працуюць адночасна, выкарыстоўваюць менша колькасць 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 і сцэнарыяў, дзе важны час адпаведзі. Працоўныя прынтакі: максимальная выдатнасць пасля компілявання. Мінусы: двойкі прызначаны конкрэтна для певных 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.

Скомпрэсаваныя варыянты:

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

Корпаратыўныя агентскія системы проты всіх іншых

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

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

Адказвальныя вядомасцы па рэалізацыі

Запуск чаго-небудзь — гэта прыбліжна пята частка работы. Раштата — гэта падтрымкі таго, каб усё працавало правільна, дышча і безпечна.

Складзіце квантызацыю, рэжыстр, адлік эфектыўнасці, тэстовыя версіі і маршрутызацыю ў адну петлю, якая праходзіць за кожной версіей модэлю:

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

2. Версіяванне модэля і реестр. Фін-тюнінгі і квантызаваныя версіі модэля трэба спрыяваць як незменныя, версіяваныя об’екты — ніколі не перазапісваць іх на месца. MLFlow, рэпозітарыі Hugging Face Hub з дайджестамі або внутршній реестр OCI для такіх об’ектаў будуць эфектывныя, якщо дайджесты будуць уключаныя ў маніфесты развёртвання.

3. Этапы ацэнкі. Неабходна зберагаць «золаты» набор метрык для задання: показнік F1 для класыфікацыі, точнасць выкарыстоўвання поль, ступень правамернасці схемы, правільнасць адмов і ліміты затрымкі. Заблакаваць пераход на стадію продакшна, калі метрыкі не парадныя, нават якшо дэманстрацыі выглядаюць краща.

4. Топалогія адміністрацыі. Калі гэта дапаможна, выдзеляйце токенайзеры/прадаўальнікі CPU ад працоўнікаў GPU; автаскейліруйце ў залежнасці ад глыбі каня і выкарыстоўвання GPU, а не толькі RPS. Зберагайце пул працоўнікаў у “гарячым” стане, якщо пачатак роботы з нуля нарабляе адхыленнія ад SLO-ў.

5. Возможнасць абзору. Экспортуйце даны пра затрымку запитоў, колькість токенаў увайшлых/выйшлых, шчыльнасць кэша, размер пакетаў, а таксама колькість випадкаў OOM і перапрыбутакоў. Аккуратна берыце праекты запитоў са адлікам на правіла прыватнасці.

6. Атрыбуцыя да пачатковага стану. Выкорыстоўвайце методы blue/green або canary для ўсьго комплексу — модэля і версіі праекта запита. Негайна атрыбуцыя да пачатковага стану, калі якосьць роботы расте.

7. А/B тэставанне і мнагамодельная рутацыя

Рутавайце запиты па задачах: SLM-і для класыфікацыі і выдлучэння інформацыі; большыя модэлі — для генеравання адкрытых тэкстаў. Перад перайшчым на новую систему прабавайце трафік з новымі модэлямі. Следзіце за вартасцю кожнай успешной задачы, а не толькі за колькасцю токенаў, ўпэўніваючыся, што дешавейшы модэль, які трэба перапрыбутваць два разы, не будзе “выграў” неправедна.

Флагі функцыяў должны прыяўляць маршруты кліента да названых канцэнтраў моделей, якія знаходзяцца за гэйтвейем, так што для змены ўстановленых параметраў не патрабуецца выпуск новай версіі прыёмніка.

Планы дзеяння для разных сфер

Прыёмнікі для спожычальнікаў / мобільныя прыёмнікі

Вядомае прываліканне да SLM-аў, якія работаюць на самым прыёмніку або поблізу яго, за дапамогою MLC/WebLLM чы GGUF у рэжыме ўрабаткі прыёмніка. Аккуратна керуйце бюджетам памяці; вядомае адправляйце токены для паспрабоўкі корыстніка; зберагучы альтэрнатыўную версію ў хмаре для складных запытанняў, калі ёсць чыстае сагласнае корыстніка.

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

Анті-патэрны

Выпуск версій у формате FP16 «з-за вышэйшай якосці», не пераканалівшыся ў квантаванай версіі на рэальных задачах
Іспользованне топалагій Ollama/LM Studio для высокачастотных сервісаў без двігуна, створанага для паралельнай адрабаткі запытанняў
Замена файлаў моделей на месцы, чыяму адворачэнне да поперадней версіі стае немагчымым

Ацэнка ведзецца толькі на пераканаўчых праметах, а не на высокаякоснастных наборах дадзэнняў.

Ігнараванне KV-cache і паметрык батчаў пакуль у працоўнай сітцы не выйдзе з-пад контролю 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, і што будзе, калі маркетынгавая кампанія за ноч адразу збільшыць колькасць запытанняў у секунду у тры разы. Неабходна даць на яны письмовыя адказы ўжо до першага тэставання.

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

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

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

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

На заканчыце, кожны квартал пераглядзіце праблему выбору “большога модэлю” на аднойчынку з дадзеннямі. Якщо рэйтынг SLM у стане “золатая сэтка” застаёцца на месцы, пакалі заданні корыстувача становяцца сложнейшымі, прыемлівайце рашэння выборча — па шляху — а не заменяючы весь комплекс за ноч. LLMOps для SLM-аў значыць таксама і стрымленне, як і прышвартаванне.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Усе артыкулы Даслаць брыф