Jak hostovat open-source LLM: od Ollamy po Kubernetes

Citlivá data, která nesmějí opustit firmu. Faktura za API, která roste rychleji než produkt. Nebo prostě chuť rozumět tomu, co se děje pod kapotou. Důvodů, proč si provozovat vlastní jazykový model, přibývá — a dobrá zpráva je, že dnes je to snazší než kdy dřív. V tomto průvodci projdeme celou cestu: výběr modelu, kvantizaci, nároky na hardware, tři nejpoužívanější inference enginy, pronájem GPU v cloudu i škálování na Kubernetes.

Kdy dává self-hosting smysl

• Soukromí a compliance — data neopouštějí vaši infrastrukturu. Pro zdravotnictví, finance nebo interní know-how často jediná schůdná cesta.
• Náklady při velkém objemu — API je levné na začátek, ale při milionech tokenů denně se vlastní GPU zaplatí. Počítejte ale poctivě: k ceně karty přičtěte elektřinu, správu a svůj čas.
• Kontrola a stabilita — model se vám pod rukama nezmění ani nezmizí, můžete ho fine-tunovat a ladit inferenci (viz mitigace U-křivky z minulého článku).
• Offline a edge scénáře — asistent běžící bez internetu, na notebooku nebo v uzavřené síti.

Naopak pokud potřebujete špičkovou kvalitu frontier modelů a objemy máte malé, zůstaňte u API — open-source modely jsou výborné, ale těm největším komerčním se vyrovnají jen v užších doménách.

Výběr modelu

Nabídka na Hugging Face se mění každý měsíc, rodiny ale zůstávají: Llama (Meta), Qwen (Alibaba), Mistral, Gemma (Google), DeepSeek nebo GPT-OSS (OpenAI). Při výběru řešte tři věci:

1. Velikost — udává se v miliardách parametrů (7B, 14B, 70B…). Větší = chytřejší, ale pomalejší a hladovější po paměti. Pozor na MoE (mixture-of-experts) modely: u nich se liší celkový počet parametrů a počet aktivních na token — do paměti musíte vejít s celkem, rychlostí odpovídají aktivním.
2. Varianta — chcete instruct verzi (dotrénovanou na konverzaci a instrukce), ne base. Pro agentní použití ověřte podporu tool callingu, pro RAG dostatečné kontextové okno.
3. Licence — Apache 2.0 a MIT jsou bez háčků; komunitní licence (např. Llama) mívají podmínky pro komerční nasazení. Vždy přečtěte.

Praktická rada: nezačínejte otázkou „jaký největší model rozjedu“, ale „jaký nejmenší model zvládne moji úlohu“. Na klasifikaci, extrakci nebo sumarizaci často stačí 4–8B model, který poběží rychle a levně; univerzálního asistenta z něj neuděláte. Rozhodne jedině vyhodnocení na vašich datech.

Kvantizace: klíč k rozumnému hardwaru

Model v plné přesnosti (FP16/BF16) potřebuje zhruba 2 bajty na parametr — 7B model tedy ~14 GB VRAM jen na váhy. Kvantizace váhy zaokrouhlí na méně bitů: u 4bitové kvantizace klesne spotřeba zhruba na čtvrtinu, s malou, pro většinu použití přijatelnou ztrátou kvality. Ztráta ale není nulová a roste s agresivitou kvantizace — pod 4 bity už bývá znát, u úloh citlivých na přesné uvažování (matematika, kód) i dřív.

• GGUF — formát ekosystému llama.cpp/Ollama, úrovně Q2 až Q8. Rozumný kompromis je Q4_K_M, vyšší kvalitu dá Q5_K_M či Q8_0. Umí běžet na CPU, GPU i hybridně.
• AWQ / GPTQ — 4bitové formáty optimalizované pro GPU inference, typicky pro vLLM. AWQ chrání „důležité“ váhy vyšší přesností, takže drží kvalitu o něco lépe.
• FP8 — na novějších kartách (Hopper, Ada a novější) zlatá střední cesta pro produkci: poloviční paměť oproti FP16 při prakticky neměřitelné ztrátě.

K vahám ale musíte přičíst KV cache — paměť, do které si model ukládá klíče a hodnoty attention pro už zpracované tokeny. Roste lineárně s délkou kontextu a s počtem souběžných požadavků; u serveru s dlouhými konverzacemi klidně spolkne víc než samotné váhy. Právě proto se produkční enginy tolik věnují její správě.

Berte to jako orientační tabulku — skutečná spotřeba závisí na délce kontextu a počtu souběžných požadavků. Modely, které se nevejdou na jednu kartu, lze rozložit na více GPU (tensor parallelism), za cenu nároků na propojení karet. A nezapomeňte, že díky llama.cpp lze menší modely rozběhnout i čistě na CPU, jen výrazně pomaleji.

Tři nástroje, tři scénáře

Ollama — nejrychlejší start

Ollama obaluje llama.cpp do nástroje ve stylu Dockeru: jedním příkazem model stáhne, kvantizovaný spustí a vystaví lokální API. Sám řeší správu paměti, automatický fallback na CPU i odkládání nepoužívaných modelů. Ideální pro vývoj, prototypy a osobní použití:

# instalace (Linux), pak staci:
ollama run qwen3:8b

# model bezi a zaroven je dostupny na http://localhost:11434

llama.cpp — maximální kontrola a nejširší hardware

llama.cpp je céčkový engine, na kterém Ollama stojí. Běží na CUDA, AMD, Apple Silicon i čistém CPU a dává vám plnou kontrolu nad kvantizací, offloadingem vrstev na GPU a dalšími parametry. Součástí je i server s OpenAI-kompatibilním API:

llama-server -m qwen3-8b-Q4_K_M.gguf --port 8080 -ngl 99
# -ngl 99 = vsechny vrstvy na GPU; snizte, kdyz se model do VRAM nevejde

vLLM — produkční serving pro více uživatelů

Jakmile má model obsluhovat tým nebo aplikaci s desítkami souběžných požadavků, přichází čas na vLLM. Jeho dvě klíčové technologie:

• PagedAttention — KV cache se spravuje po malých stránkách, podobně jako virtuální paměť v operačním systému. Odpadá fragmentace a do stejné VRAM se vejde výrazně víc souběžných požadavků.
• Continuous batching — nové požadavky naskakují do rozjeté dávky, jakmile se uvolní slot; GPU se nezastavuje čekáním na nejpomalejší request.

Výsledek: při souběžné zátěži řádově vyšší propustnost než Ollama nebo llama.cpp, za cenu složitějšího setupu a nároku na NVIDIA GPU. Pro jednoho uživatele je to zbytečně těžká infrastruktura; pro tým nebo produkční aplikaci naopak správný nástroj.

pip install vllm
vllm serve Qwen/Qwen3-8B-AWQ --max-model-len 16384

# pozor: vLLM si standardne zabere ~90 % VRAM pro KV cache;
# pokud kartu sdilite, pridejte --gpu-memory-utilization 0.5

Jedno API pro všechno

Všechny tři nástroje vystavují OpenAI-kompatibilní endpoint. To znamená, že aplikaci napíšete jednou a mezi lokálním modelem, vlastním serverem a komerčním API přepínáte jen změnou URL:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",   # Ollama; u vLLM napr. :8000/v1
    api_key="neni-potreba",
)

odpoved = client.chat.completions.create(
    model="qwen3:8b",
    messages=[{"role": "user", "content": "Vysvetli mi kvantizaci LLM."}],
)
print(odpoved.choices[0].message.content)

Nemáte GPU? Pronajměte si ho

Vlastní karta není podmínka — mezi „všechno doma“ a „komerční API“ existuje celé spektrum online platforem. Liší se hlavně tím, kolik správy nechávají na vás:

• GPU cloudy (IaaS) — pronajmete si holý stroj s GPU po hodinách a doinstalujete si vLLM či Ollamu sami. Typicky RunPod, Vast.ai (burza GPU s nejnižšími cenami), Lambda nebo evropský CoreWeave; GPU instance mají samozřejmě i AWS, Azure a Google Cloud, obvykle za vyšší ceny. Maximální kontrola, plná odpovědnost.
• Serverless GPU — nahrajete kontejner nebo funkci a platíte jen za vteřiny, kdy inference skutečně běží; škálování na nulu řeší platforma. Např. Modal, Replicate nebo RunPod Serverless. Skvělé pro nárazovou zátěž; daní je studený start (načtení vah do VRAM trvá desítky sekund).
• Managed inference open modelů — hotové API nad open-source modely, kde neřešíte vůbec nic: Together AI, Fireworks AI, Groq (extrémně rychlá inference na vlastních čipech) či Hugging Face Inference Endpoints. Technicky už to není self-hosting, ale zachováváte si volnost výběru modelu a únikovou cestu: díky OpenAI-kompatibilnímu API se později přesunete na vlastní železo změnou jedné URL.

Typický vývoj projektu: prototyp na notebooku s Ollamou, pilot na pronajatém RunPodu s vLLM, a teprve když je jasná trvalá zátěž, investice do vlastního hardwaru — nebo přechod na Kubernetes.

Větší škála: Kubernetes

Jeden server s vLLM obslouží překvapivě hodně. Ale jakmile potřebujete více replik kvůli dostupnosti, více modelů vedle sebe, autoscaling podle zátěže a bezvýpadkové nasazování nových verzí, dostanete se tam, kde se průmysl standardizoval na Kubernetes. LLM inference je z pohledu K8s „jen“ další workload — se třemi specifiky, která je potřeba vyřešit:

1. GPU jako plánovatelný zdroj — nody s kartami vyžadují NVIDIA GPU Operator (ovladače, device plugin, monitoring). Pod si pak GPU vyžádá v resources.limits jako nvidia.com/gpu: 1. Karty lze i dělit mezi menší workloady (MIG, time-slicing).
2. Pomalé starty — desítky GB vah se musí při startu podu dostat do VRAM. Řeší se cache modelů na perzistentním svazku či v registru, readiness probes (pod nedostane provoz, dokud model nenačte) a konzervativním scale-down, aby cluster repliky zbytečně nerecykloval.
3. Chytřejší load balancing — klasický round-robin je pro LLM nevhodný: požadavky se liší délkou o řády a vyplatí se směrovat je podle vytížení KV cache a prefix-cache hitů konkrétních replik.

Minimální nasazení vLLM na K8s se vejde do běžného Deploymentu:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-qwen3
spec:
  replicas: 2
  selector:
    matchLabels: { app: vllm-qwen3 }
  template:
    metadata:
      labels: { app: vllm-qwen3 }
    spec:
      containers:
        - name: vllm
          image: vllm/vllm-openai:latest
          args: ["--model", "Qwen/Qwen3-8B-AWQ",
                 "--max-model-len", "16384"]
          ports: [{ containerPort: 8000 }]
          resources:
            limits: { nvidia.com/gpu: 1 }
          readinessProbe:
            httpGet: { path: /health, port: 8000 }
            initialDelaySeconds: 60
          volumeMounts:
            - { name: model-cache, mountPath: /root/.cache/huggingface }
      volumes:
        - name: model-cache
          persistentVolumeClaim: { claimName: hf-cache }

Pro vyšší patra existují specializované nadstavby: KServe (standardizované InferenceService CRD, škálování na nulu), vLLM Production Stack (Helm chart s routerem, který směruje podle KV cache) nebo llm-d — Kubernetes-nativní distribuovaná inference, která odděluje prefill a decode fázi na různé pody. Autoscaling se pak neřídí CPU, ale LLM metrikami (hloubka fronty, vytížení KV cache) přes KEDA nebo HPA s vlastními metrikami.

Na co si dát pozor v produkci

• Zabezpečení endpointu — lokální API nemá autentizaci. Před vystavením do sítě patří za reverse proxy s API klíči a TLS; na K8s to řeší ingress a NetworkPolicy.
• Souběh a fronty — Ollama a llama.cpp nejsou stavěné na desítky paralelních uživatelů; na to je vLLM (případně SGLang či TGI).
• Monitoring — sledujte latenci prvního tokenu (TTFT), tokeny/s, hloubku fronty a vytížení VRAM; vLLM exportuje metriky pro Prometheus, ke GPU metrikám slouží DCGM exporter.
• Vyhodnocení kvality — kvantizovaný menší model nemusí stačit na vaši úlohu. Před nasazením porovnejte výstupy s referenčním API modelem na vlastních datech — a měření zopakujte při každé změně modelu či kvantizace.
• Náklady průběžně — hodinová sazba GPU je jen část účtu; nevyužitá rezervovaná karta je nejdražší karta. Autoscaling a scale-to-zero u nárazové zátěže šetří nejvíc.

← Zpět na blog