Strona główna / Artykuły / LLMOps dla małych modeli językowych: frameworki serwisowe i przewodniki produkcyjne

LLMOps dla małych modeli językowych: frameworki serwisowe i przewodniki produkcyjne

Dlaczego modele SLM przewyższają inne pod względem kosztów i prywatności, jak porównują się vLLM, SGLang, TGI, llama.cpp, Ollama, WebLLM, ONNX oraz TensorRT-LLM, oraz jak kwantyzować je, oceniać i wykorzystywać w produkcji.

4127 słów

Praktyczne podejście do LLMOps dla małych modeli językowych: kiedy inferencja lokalna lub w urządzeniu przewyższa zaawansowane API, jakie stacki serwisowe pasują do określonych ograniczeń sprzętowych i jak utrzymać je w dobrym stanie po pierwszym udanym wywołaniu.

Wprowadzenie

Pomiędzy podejściem „dostosowywania największych modeli do wszystkiego” a „uruchamianiem modeli z mniej niż miliardem parametrów w telefonie” zmieniły się priorytety w produkcji. Wiele zadań – takich jak klasyfikacja intencji, kierowanie do odpowiednich narzędzi, wydobywanie danych w formie uporządkowanej czy ponowna sortowanie informacji z RAG – nie wymaga modeli o najwyższej wydajności, gdy solidny model SLM zostanie skwantyzowany i dobrze obsłużony.

Prymatem jest jednak to, że model SLM bez strategii serwisowania jest jedynie plikiem z danymi na dysku. Jego uruchomienie w produkcji rodzi problemy z pamięcią GPU, grupowaniem zapytań, dokładnością skwantyzacji, możliwościami cofania zmian oraz kwestiami oceny, których prawie w ogóle nie poruszają tradycyjne procedury MLOps.

Model, którego nie można wdrożyć, monitorować ani cofnąć, nie jest zasobem produkcyjnym – to obciążenie o atrakcyjnych wynikach w testach porównawczych.

To przewodnik omawia problem, dostępne frameworki oraz procedury operacyjne w takiej kolejności. Proces jest ciągły: punkt kontrolny staje się funkcjonalnością dopiero po przejściu testów dostępności, oceny oraz sprawdzania aspektów operacyjnych.

Problem: Dlaczego „większy model” przestał być standardowym rozwiązaniem

1. Koszty i opóźnienia rosną wraz ze skalą

Wysyłanie prostej zapytania do modelu o wielkości 70 miliardów parametrów to marnotrawstwo zasobów. Dodatkowe parametry zapewniają funkcjonalności, których być może nie potrzebujesz, jednocześnie zwiększając czas pracy GPU i opóźnienia przy dużej liczbie równoczesnych zapytań. Na poziomie produktu te koszty stają się dominujące.

2. Siła przyciągania danych i kwestie prywatności skłaniają do wykonywania obliczeń na periferii

Zakresy zastosowań w sektorze opieki zdrowotnej, finansów oraz urządzeń konsumenckich często nie mogą przesyłać surowego tekstu do API dostawcy zewnętrznego. SLM, który mieści się w kilku gigabajtach pamięci RAM, może funkcjonować obok danych – na lokalnych kartach graficznych, laptopach lub telefonach – spełniając wymogi związane z lokalizacją danych, których nie może spełnić model chmurowy.

3. Infrastruktura serwowania ma własne sposoby awarii

Serwowanie modeli zawodzi w inny sposób niż zwykłe błędy aplikacji: fragmentacja pamięci GPU spowodowana nierozważnym alokowaniem bufora KV, problemy z planerem pod wpływem nagłego wzrostu ruchu, niezgodności w kwantyzacji prowadzące do cichego pogorszenia jakości, oraz problemy z uruchamianiem modeli po zmniejszeniu skali do zera.

4. LLMOps to odrębna dziedzina w porównaniu z MLOps

Klasyczne MLOps zakłada stosunkowo stabilne struktury i deterministyczne wyniki. LLMOps wprowadza elementy niedeterministyczne, takie jak różne wersje tekstu, promptów i narzędzi, mechanizmy gospodarki tokenami oraz filtry bezpieczeństwa. Regresja nie polega już tylko na „spadku dokładności o 2%” – może też objawiać się „spadkiem zgodności ze schematem JSON” lub „gwałtownym spadkiem liczby tokenów na sekundę po aktualizacji sterownika”.

Czym jest LLMOps i w czym różni się od MLOps?

LLMOps obejmuje sposoby dostarczania, hostowania, zarządzania oraz ulepszania modeli językowych w systemach działających w czasie rzeczywistym – z taką samą powagą operacyjną, jaką przywiązuje się do każdej innej krytycznej usługi.

Podczas gdy MLOps sprawdza, czy dokładność spadła, LLMOps pyta również o:

Czy silnik obsługi efektywnie wykorzystuje pamięć GPU przy jednoczesnym działaniu wielu procesów?
Czy zquantyzowany wynik pozostaje wystarczająco wierny oryginałowi do realizacji danej zadania?
Czy wersje promptów i narzędzi są zdefiniowane jasno i możliwe do cofnięcia?

Czy ruch może być przekierowywany między modelami bez konieczności przerabiania kodu przez klienta?

Czy ślady działania ujawniają koszt tokenów i opóźnienie na każdej trasie?

Pozostała część tego przewodnika odpowiada na te pytania specyficznie w kontekście SLM.

Obszar frameworków do implementacji SLM

Dla maksymalnej wydajności GPU, vLLM jest popularnym wyborem o wysokim wskaźniku zapytań na sekundę, oferującym API kompatybilne z OpenAI na kartach NVIDIA lub AMD. SGLang konkuruje w sytuacjach, gdy ważne jest ponowne użycie prefiksów oraz strukturyzowana generacja. Hugging Face TGI nadaje się dla zespołów, które już używają standardów Hub i Helm.

Jeśli chodzi o rozwiązania przenośne, llama.cpp / GGUF działa na procesorach CPU, Apple Silicon oraz wielu kartach graficznych przeznaczonych do użytku konsumenckiego. Ollama opakowuje ten zestaw narzędzi, umożliwiając korzystanie z nich za pomocą dwóch poleceń. LM Studio dodaje interfejs graficzny do pracy na komputerze stacjonarnym w celu oceny wydajności. MLC-LLM / WebLLM są kompilowane pod przeglądarki i urządzenia mobilne. ONNX Runtime GenAI jest przeznaczony dla systemu Windows/NPU oraz standardów ONNX używanych w środowiskach korporacyjnych. TensorRT-LLM + Triton zapewniają maksymalną wydajność kart NVIDIA po uprzedniej kompilacji.

Każde z tych rozwiązań przekształca pliki checkpoint w odpowiedzi; różnią się one pod względem założeń dotyczących sprzętu, wagi operacji oraz projektu związанego z równoczesnością obliczeń.

Szczegółowe omówienia frameworków

vLLM

vLLM upowszechnił technologię PagedAttention, która zarządza pamięcią KV w sposób podobny do pamięci wirtualnej, dzięki czemu sekwencje przetwarzane równocześnie zużywają mniej pamięci RAM karty graficznej. Ciągłe grupowanie zadań utrzymuje wysoki poziom wykorzystania sprzętu.

# 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)

Najlepsze do: backendów o wysokiej wydajności QPS oraz usług RAG wymagających punktów końcowych kompatybilnych z OpenAI. Zalety: duża przepustowość, szeroki zakres modeli, formaty kwantyzacji (AWQ/GPTQ/FP8). Wady: skupienie na GPU; nadal wymaga orkiestracji dla wysokiej dostępności.

SGLang

SGLang opiera się na RadixAttention do współdzielenia pamięci cache z prefiksami w powiązanych żądaniach – doskonały do pętli agentów z powtarzającymi się promptami systemowymi – i zawiera DSL sgl.function do strukturyzowanej generacji.

# 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"])

Najlepsze do: pipeline’ów agentów oraz ograniczonych wyjść w formacie JSON. Zalety: ponowne użycie prefiksów, strukturyzowane wyjścia. Wady: mniejszy ekosystem niż vLLM; dostępny tylko na GPU.

Hugging Face Text Generation Inference (TGI)

TGI łączy się z ekosystemem Hub dzięki opakowaniu przyjaznemu Dockerowi/Kubernetesowi.

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))

Najlepsze do: zespołów skupionych wokół Hub oraz środowisk regulowanych, które potrzebują wspieranej drogi dostarczania usług. Zalety: integracja z Hub, opcje kwantyzacji, wsparcie Helm. Wady: niektóre obciążenia wciąż preferują vLLM ze względu na wydajność; należy śledzić warunki licencji z biegiem czasu.

llama.cpp / GGUF

Stworzony do uruchamiania LLaMA na procesorze MacBooka, llama.cpp stanowi podstawę większości lokalnych i brzegowych rozwiązań SLM dzięki kwantyzacji 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?"}]}'

Najlepsze do: serwerów z procesorem CPU, Apple Silicon, urządzeń typu Pi/edge bez CUDA. Zalety: przenośność, rozwinięta skala kwantyzacji, licencja MIT. Wady: wydajność przy jednoczesnym przetwarzaniu jest gorsza niż w rozwiązaniach natywnych dla GPU.

Ollama

Ollama umożliwia korzystanie z llama.cpp poprzez prosty interfejs typu „pobierz i uruchom” z lokalną API HTTP.

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"])

Najlepsze do: pracy lokalnej, tworzenia prototypów oraz samodzielnego hostowania w małych zespołach. Zalety: wygodny interfejs i domyślne ustawienia. Wady: nie nadaje się do zadań produkcyjnych wymagających wysokiej konkurencji.

LM Studio

Interfejs graficzny do pracy na komputerze, który umożliwia przeglądanie, pobieranie i rozmawianie za pomocą podobnych silników lokalnych — plus serwer kompatybilny z OpenAI dostępny jednym kliknięciem do demonstracji. Idealny do oceny przed napisaniem plików konfiguracyjnych; nie jest komponentem infrastruktury do wdrażania na dużą skalę.

MLC-LLM / WebLLM

Bazujące na Apache TVM, MLC kompiluje modele dla różnych backendów; WebLLM działa w pełni w przeglądarce.

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);

Najlepsze do: aplikacji mobilnych, inferyencji klienta chroniącej prywatność, funkcji offline. Zalety: możliwość kompilacji na różne cele; brak serwera wymaganego dla WebLLM. Wady: złożoność kompilacji; ograniczenia urządzeń w przeglądarkach.

ONNX Runtime GenAI

API GenAI firmy Microsoft rozszerza ONNX Runtime o funkcje generowania autoregresywnego wraz z zarządzaniem pamięcią KV-cache na platformach Windows DirectML i 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)))
"

Najlepsze do: aplikacji typu Windows oraz przedsiębiorstw stosujących standard ONNX. Zalety: możliwość przenoszenia aplikacji po eksporcie. Wady: trudności przy konwersji; mniejsza społeczność w porównaniu z silnikami opartymi na PyTorch.

NVIDIA TensorRT-LLM + Triton Inference Server

TensorRT-LLM umożliwia kompilację silników z góry przy użyciu połączonych jąder; Triton obsługuje zespoły wielu modeli.

# 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

Najlepsze do: maksymalnej wydajności floty urządzeń NVIDIA oraz ścieżek, gdzie krytyczna jest opóźnienie. Zalety: maksymalna wydajność po skompilowaniu. Wady: silniki są specyficzne dla konkretnych modeli i formatów; ich ponowna kompilacja jest konieczna po zmianach w sprzęcie lub profilach przetwarzania.

Wybór frameworku: Przewodnik decyzyjny

Model myślowy: trzy pytania, a nie lista funkcji

Pytanie 1: Gdzie musi fizycznie działać model? Przeglądarka lub telefon bez połączenia sieciowego → WebLLM/MLC. CPU/Apple/edge bez CUDA → llama.cpp/Ollama. Dopiero wtedy rozważyć silniki GPU w centrach obliczeniowych.

Pytanie 2: Czy chodzi o obsługę w produkcji, czy o eksplorację? Eksploracja → LM Studio lub Ollama. API do produkcji → vLLM/SGLang/TGI/TensorRT w zależności od następnego pytania.

Pytanie 3 (tylko produkcja GPU): Jaki jest kształt ruchu i jaki jest budżet inżynieryjny? Niezależne, jednorazowe zadania → vLLM jako standard. Bardzo powtarzalne prefiksy agentów / ustrukturyzowane wyniki → SGLang. Optymalizacja na poziomie NVIDIA z inwestycją w platformę → TensorRT-LLM + Triton. Wygoda korzystania z Hub/Helm → TGI.

Skrócone informacje:

Maksymalna przepustowość API GPU → vLLM (lub SGLang w przypadku zadań agentowych/powtarzalnych)
Maksymalna wydajność NVIDIA z budżetem na kompilację → TensorRT-LLM + Triton
CPU/Apple/edge → llama.cpp; otoczka DX → Ollama
Brauzer/klient offline → WebLLM/MLC
Windows/NPU/ONNX standard → ONNX Runtime GenAI
Ocena po kliknięciu → LM Studio

Systemy agentowe dla przedsiębiorstw kontra wszystko inne

Ruch zapytań/odpowiedzi jednoetapowych preferuje ciągłe grupowanie zadań w vLLM. Agenci korporacyjni mogą wywoływać model dziesiątki razy na zadanie – planowanie, wybór narzędzia, obserwacja, ponowne planowanie – dlatego kluczowe stają się cacheowanie prefiksów oraz strukturyzowane wyniki. Takie rozwiązania często wykorzystują SGLang lub TensorRT-LLM + Triton na samodzielnie zarządzanych kartach graficznych, przy czym TGI stanowi alternatywę, gdy integracja z Hubem ma większe znaczenie niż maksymalna przepustowość.

Platformy agentów wielu użytkowników wymagają również kwot dostępnych dla każdego użytkownika, śledzenia działań podczas wywołań narzędzi oraz możliwości cofnięcia całych par prompt+model – to kwestie związane z LLMOps, które dotyczą wszystkich rozwiązań.

Przewodnik po wdrożeniu produkcyjnym

Rozruch systemu to zaledwie około jedna piąta całej pracy. Reszta polega na utrzymaniu jego poprawności, niskich kosztów i bezpieczeństwa.

Traktuj kwantyzację, rejestr, ocenę, mechanizmy testowe oraz routowanie jako jeden cykl, który przechodzi każda wersja modelu:

1. Strategia kwantyzacji. W wielu ścieżkach produkcyjnych SLM domyślnie stosuje się AWQ-4bit lub GGUF Q4_K_M – zazwyczaj o kilka procent lepsze wyniki w porównaniu z FP16 po dokładnej ocenie – i należy upewnić się, że wybrany silnik obsługuje ten format. Kwantyzacja to proces nie jednorazowy; kończy się przy bramce oceny, a nie po wydaniu polecenia konwersji.

2. Wersjonowanie modeli i rejestr. Dostosowania oraz kwantyzowane wersje modeli należy traktować jako niezmienne, wersjonowane obiekty – nigdy nie należy ich nadpisywać na miejscu. MLFlow, repozytoria Hugging Face Hub z digestami lub wewnętrzny rejestr OCI dla artefaktów sprawdzą się, jeśli digesty są określone w manifestach implementacji.

3. Bramki oceny. Należy utrzymywać standardowy zestaw wskaźników dla danej zadania: F1 w klasyfikacji, dokładność wyodrębniania danych, wskaźnik poprawności schematu, prawidłowość odrzuceń oraz limity opóźnienia. Blokować przenoszenie modeli do środowiska produkcyjnego w przypadku nieprzejścia bramek oceny, nawet jeśli demonstracje wyglądają lepiej.

4. Topologia obsługi. Rozdzielaj tokenizery/preprocesory CPU od pracowników GPU, gdy jest to korzystne; skaluj automatycznie w zależności od głębokości kolejki i wykorzystania GPU, a nie tylko RPS. Zachowaj zasób gotowy do użycia, jeśli starty z zimnego stanu naruszają SLO.

5. Obserwowalność. Eksportuj opóźnienia żądań, liczbę tokenów wprowadzanych/wyjściowych, wskaźniki trafień w pamięci cache, rozmiar partii oraz liczbę przypadków braku pamięci/retry. Dobieraj próbki zapytań ostrożnie, przestrzegając polityki prywatności.

6. Odwracanie zmian. Wykorzystuj podejście blue/green lub canary dla całości, czyli modelu oraz wersji zapytania. Natychmiast przywróć obie wersje, gdy jakość spadnie gwałtownie.

7. Testy A/B i routowanie między modelami

Routuj zapytania według zadania: modele SLM do klasyfikacji i wydobywania informacji; większe modele do generowania tekstów otwartych. Przeprowadź testy z ruchem skierowanym do kandydatów przed pełną migracją. Śledź koszt za udane zadanie, a nie tylko liczbę tokenów, aby tańszy model, który wymaga dwóch prób, nie wygrał fałszywie.

Znaki funkcjonalne powinny łączyć trasy klienta z nazwanymi punktami końcowymi modelu znajdującymi się za bramką, aby zmiany nie wymagały wydawania nowych wersji aplikacji.

Plan działania dla poszczególnych domen

Aplikacje konsumenckie / mobilne

Należy preferować rozwiązania SLM działające na urządzeniu lub w jego bliskiej okolicy, wykorzystujące MLC/WebLLM lub GGUF w środowiskach uruchomieniowych na urządzeniu. Należy starannie planować zużycie pamięci; przesyłać tokeny w formie strumieniowej dla lepszej jakości użytkownika; zachować opcję awaryjną w chmurze dla złożonych zapytań przy wyraźnej zgodzie użytkownika.

Inne domeny (asystenci wspomagający, wewnętrzne systemy RAG, bramki krawędziowe) stosują ten sam schemat: najpierw określa się możliwości sprzętowe, potem silnik obliczeniowy, a na końcu pętlę kwantyzacji i oceny.

Nieprawidłowe praktyki

Wprowadzanie wersji FP16 „ze względu na jakość” bez pomiaru wydajności wersji skwantyzowanej przy rzeczywistych zadaniami
Używanie topologii Ollama/LM Studio w środowiskach produkcyjnych o wysokiej przepustowości bez silnika serwowania zaprojektowanego do obsługi wielu zadań jednocześnie
Mazanie plików modeli bezpośrednio na miejscu, co sprawia, że procedury odwracania zmian stają się bezużyteczne

Ocena opiera się wyłącznie na sprawdzaniu atmosfery, a nie na kompletnych zestawach danych.
Ignowowanie cache’u KV oraz metryk zbiorczych, dopóki w środowisku produkcyjnym nie wystąpi brak pamięci GPU.

Główne wnioski

SLM-y przeważają, gdy zadania są ograniczone, dane nie mogą opuścić danego środowiska lub budżety kosztów i opóźnień uniemożliwiają użycie zaawansowanych modeli.
LLMOps rozszerza MLOps o efektywność dostarczania usług, dokładność kwantyzacji, wersjonowanie promptów i narzędzi oraz aspekty ekonomiczne związane z tokenami.
Należy wybierać odpowiednie silniki w zależności od miejsca uruchomienia (urządzenie/CPU/GPU), etapu pracy (eksploracja vs dostarczanie usług) oraz charakteru ruchu (jednorazowy vs agenty).
Sukces w środowisku produkcyjnym to cykl: kwantyzacja → rejestracja → ocena → testy pilotażowe → obserwacja → cofnięcie zmian.
Należy łączyć trwałe reprezentacje modeli z systemem routingu typu „doorbell”, aby klienci pozostawali stabilni mimo ewolucji backendów.

Źródła

Zobacz oficjalną dokumentację każdego projektu w celu pozyskania informacji na temat flag instalacyjnych oraz wersji narzędzi: vLLM, SGLang, Hugging Face TGI, llama.cpp, Ollama, LM Studio, MLC-LLM/WebLLM, ONNX Runtime GenAI oraz NVIDIA TensorRT-LLM/Triton. Przewodniki dotyczące sprzętu od NVIDIA oraz dokumentacja Apple Metal uzupełniają pliki README silników podczas dostosowywania rozmiarów partii oraz metod kwantyzacji.

Miej dostępny wewnętrzny podręcznik, który odnotowuje, które narzędzia przetwarzające zostały użyte z jakimi zestawami danych na konkretnych modelach GPU – to właśnie ten dokument przekształca tę instrukcję obsługi w funkcjonalną platformę.

Dodatek: Obsługa SLM-ów od drugiego do dwudziestego tygodnia

Po pierwszym udanym połączeniu za pomocą curl z lokalnym serwerem pojawiają się trudne pytania: kto jest odpowiedzialny za dyżury, jak planowane są aktualizacje sterowników CUDA oraz co się dzieje, gdy kampania marketingowa trzykrotnie zwiększa liczbę zapytań na sekundę w ciągu nocy. Odpowiedz na nie pisemnie przed uruchomieniem pierwszego testowego wariantu.

Planowanie pojemności dla modeli SLM nadal wymaga zapasu mocy na wzrost pamięci cache KV w zależności od długości kontekstu. Model o pojemności 1,5 miliarda parametrów, który wydaje się niewielki przy kontekście 2k, może obciążać pamięć, gdy klienci otwierają okna o długości 32k. Należy śledzić liczbę tokenów kontekstu na poziomie p95 oddzielnie od szybkości wysyłania zapytań.

Przeglądy bezpieczeństwa powinny obejmować łańcuch dostaw modeli: weryfikację sum kontrolnych podczas pobierania, określenie, kto może publikować modele w rejestrze, oraz sprawdzenie, czy komendy systemowe zawierające poufne dane trafiają do plików klienckich. Modele działające lokalnie wymagają tak samo starannych kanałów aktualizacji jak aplikacje mobilne.

Przeglądy kosztów powinny porównywać całkowity koszt posiadania modeli: koszt wynajmu GPU, czas pracy inżynierów potrzebny do ponownej konfiguracji TensorRT oraz incydenty związane ze spadkiem jakości wynikające z agresywnej kwantyzacji. Czasami nieco większy model SLM w formacie 8-bit jest tańszy niż mały model, który zmusza do interwencji ludzi.

Szkolenie zespołu jest ważne. Daj inżynierom aplikacji gotową drogę do pracy: wykres Helm lub plik Compose, standardowy adres URL kompatybilny z OpenAI oraz już przygotowane panele kontrolne. Daj inżynierom ML gotową drogę do publikowania zestawień, które przechodzą wszystkie testy. Większość problemów pojawia się podczas przenoszenia obowiązków między tymi grupami.

Na koniec co kwartał sprawdzaj kuszenie „większym modelem” na podstawie danych. Jeśli wynik golden-set modelu SLM pozostaje bez zmian, podczas gdy zadania użytkowników stają się trudniejsze, dokonuj selektywnych zmian – zgodnie z ustalonym planem – a nie zastępuj całość systemu od razu. LLMOps dla modeli SLM polega zarówno na kontrolowaniu tempa rozwoju, jak i na przyspieszaniu procesów.

Uwaga operacyjna: zapisuj dokładne wersje komponentów CUDA w plikach lockfile oraz notuj wersję sterownika obok każdego udanego kanary, aby podczas incydentów można było precyzyjnie zlokalizować problemy na poziomie oprogramowania i sprzętowego firmware’u.

Uwaga operacyjna: zapisz dokładne wersje oprogramowania CUDA w plikach lockfile, a obok każdego udanego kanary zapisz wersję sterownika, aby podczas incydentów można było dokonać analizy regresji na poziomie oprogramowania i firmware’u.

Uwaga operacyjna: zapisz dokładne wersje oprogramowania CUDA w plikach lockfile, a obok każdego udanego kanary zaznacz wersję sterownika, aby podczas incydentów można było dokonać analizy regresji na poziomie oprogramowania i firmware’u.

Uwaga operacyjna: określ dokładne wersje oprogramowania CUDA w plikach lockfile i zapisz wersję sterownika obok każdego udanego kanary, aby podczas incydentów można było rozdzielić regresje na poziomie oprogramowania i firmware’u.

Literatura pokrewna

Dostarczanie Qwen3.8-27B na One RTX 3090 z poprawionym vLLM i DFlash2 — Jak wersja vLLM 0.28.0 z dodatkowymi modyfikacjami, wykorzystująca requantyzowane embeddingi oraz technologię DFlash2, umożliwia uruchomienie hybrydowego modelu o wielkości 27 miliardów parametrów na karcie pamięci o pojemności 24 GB, oraz dlaczego długi kontekst spowalnia jego działanie.
Małe, specjalistyczne modele cicho przewyższają gigantyczne LLM — Zobacz, jak model logiki o 3 miliardach parametrów pokonuje model o 120 miliardach parametrów w zadaniach wymagających formalnego rozumowania na zwykłym sprzęcie, oraz dlaczego dopasowanie modelu do konkretnego zadania jest ważniejsze niż sama jego wielkość.

Metryki inferencji vLLM: Od TTFT i TPOT do KV Cache i Goodput — Przewodnik praktyczny po metrykach vLLM w Prometheus: wskaźniki skuteczności, percentyle opóźnień, stosunek I/O tokenów, przerwy w działaniu, przedwczesne uzupełnianie danych, DPD oraz akceptacja dekodowania spekulatywnego.

Wszystkie artykuły Wyślij brief