Self-hosted LLM: jak nasadit open-source model bezpečně

Proč (a kdy) jít do self-hosted LLM

Hlavní motivací pro self-hosting je kontrola: nad daty, náklady i chováním modelu. Pro organizace s citlivými informacemi, regulatorními omezeními nebo přísnými smluvními závazky je provoz ve vlastním perimetru často jediná přijatelná cesta. Další důvody:

• Ochrana soukromí a tajemství: data neopouštějí perimetr, minimalizace třetích stran, jasné řízení toho, co se loguje a jak dlouho.
• Předvídatelné náklady: náklad za požadavek lze stabilizovat pomocí kvantizace, batchingu a cache; odpadá část marže za managed služby.
• Flexibilita: možnost měnit prompty, plugovat vlastní nástroje (tool use) a kombinovat s interními zdroji přes RAG.
• Licenční suverenita: modely a knihovny pod vaší kontrolou, jasná evidence verzí a podmínek užití.

Zároveň si přiznejme, kdy se self-hosting nevyplatí: nemáte-li kapacitu na 24/7 provoz, nepotřebujete-li specifické úpravy a vystačíte si s kvalitou i SLA managed služby, může být ekonomicky i provozně racionálnější volba cloudové platformy. Rozhodnutí musí vycházet z reálných požadavků, ne z módy.

Hrozby a cíle bezpečnosti: co chránit a před čím

Self-hosted LLM rozšiřuje vaši útočnou plochu o model, inference server, datové konektory i uživatelské rozhraní. Bez explicitního threat modelu se snadno přehlédnou slabiny. Myslete v osách CIA a AAA:

• Důvěrnost (Confidentiality): ochrana PII, obchodních tajemství, smluv; minimalizace dat ve vstupech a logách; šifrování v klidu i přenosu.
• Integrita (Integrity): důvěryhodný původ modelových vah a kontejnerů; kontrola hashů a podpisů; ochrana před neoprávněnými změnami.
• Dostupnost (Availability): škálování, odolnost proti špičkám, rate limiting a ochrana proti DoS.
• Autentizace a autorizace (AAA): silná identita (SSO), minimální nutná práva, segmentace sítí a tenantů.

Konkrétní hrozby: prompt-injection a data-exfiltration přes citace, „supply-chain“ rizika (podvržené váhy či obraz), volání nástrojů bez sandboxu, nadměrné logování, průnik laterálním pohybem z inference vrstvy do datových úložišť. Opatření: guardraily, egress kontrola, sandbox pro tool use, PII redakce, mTLS a policy enforcement v service mesh.

Výběr open-source modelu: Llama, Mistral, Falcon

Model volte podle reálného use-case, jazyka, latence a nároků na hardware. Zapomeňte na „největší = nejlepší“. U interaktivních aplikací bývá menší, dobře kvantizovaný a optimalizovaný model lepší než obří síť s vysokou latencí. Důležité faktory:

• Schopnosti a jazyk: jak si vede v češtině a angličtině, v oboru (právo, finance, IT).
• Velikost a kontext: parametry a délka kontextu (požadavky na KV cache a paměť).
• Licence: povolené komerční použití, omezení redistribuce, povinnosti při publikaci derivátů.
• Ekosystém: dostupné inference servery, podpora kvantizace a adapterů (LoRA/QLoRA), komunita.

Než vyberete, připravte malý, ale reprezentativní eval: desítky až stovky dotazů, reálné dokumenty a požadovaný formát odpovědí. Otestujte 2–3 modely na stejné pipeline a srovnávejte přesnost, latenci i stabilitu formátu.

Licence a legální rámec: co smíte a za jakých podmínek

Open-source neznamená bez závazků. Zásady, které vám ušetří problémy:

• Čtěte konkrétní licenci modelu a vah (omezení komerce, povinnosti při distribuci, případné metriky „přípustného použití“).
• Dokumentujte původ: model registry musí obsahovat verzi, hash, zdroj stažení a podpis. Uchovávejte SBOM pro kontejner i inference server.
• Dodržujte práva k tréninkovým datům u vlastních adapterů; uchovávejte informaci o původu a podmínkách.
• Řešte export modelu za hranice (compliance, sankční režimy) a datovou rezidenci.

Referenční architektura: perimetr, inference, data, integrace

Silný základ je modulární a dobře izolovaný. Osvědčené vrstvy:

1. Perimetr a síť: privátní segment, WAF/Reverse proxy, egress kontrola, mTLS, service mesh s politikami, segmentace pro inference, vektorové DB a aplikační část.
2. Inference: vLLM, Text-Generation-Inference, TensorRT-LLM či llama.cpp podle hardwaru; podpora streamu, continuous batchingu, KV cache, priorit front.
3. Policy/guardrails: verifikační vrstva před i za modelem (validace JSON schématu, PII redakce, content policy, detekce prompt-injection, limity velikosti kontextu).
4. Datová vrstva: RAG indexy (vektorová DB + BM25), správa dokumentů a metadat, verze kolekcí, RBAC/ABAC nad chunkem.
5. Integrace: SSO (OIDC/SAML), API brána, SIEM, CMDB, KMS/Vault, governance evidence a model registry.
6. Aplikace: chat UI, copiloty v interních systémech, bezpečné konektory pro „tool use“ (čtení jen povolených systémů).

Kubernetes vs. virtuální stroje

Kubernetes přináší rychlé škálování, izolaci a observabilitu; pro menší instalace mohou stačit VM s kvalitní automatizací. Důležitá je správa GPU (operátor), pinning na nody, quotas a ochrana proti laterálnímu pohybu mezi jmény prostorů.

Příprava modelu: kvantizace, adaptéry, guardraily

Optimalizace často rozhodne o úspěchu. Klíčové techniky:

• Kvantizace: INT8/INT4 (weight-only či s omezenou dekvantizací aktivací) s kalibrací na vašich datech. Výrazně snižuje paměť i latenci, nutné změřit dopad na kvalitu.
• LoRA/QLoRA adaptéry: lehká doménová adaptace chování (styl, odmítání, formát). Udržujte odděleně základní váhy a adaptery pro snadný rollback.
• Speculative decoding: malý „draft“ model urychluje generování; zvažte tam, kde je důležitá TTFT.
• KV cache: pečlivé řízení velikosti a životnosti cache v decode fázi; dramaticky snižuje výpočty u delších konverzací.
• Prompt kontrakty: pevný formát výstupu (například JSON se sekcemi), jasné zásady citací a práce s nejistotou („nedostatek informací“).

Vše versionujte v model registry: základní váhy, adaptery, kvantizační profil, podpůrné knihovny a jejich hashe/podpisy. Bez reprodukovatelnosti nemáte audit.

RAG a datová vrstva: indexy, embeddings, citace

Pro podnikové použití je RAG prakticky nezbytnost: odděluje fakta (dokumenty) od chování (LLM). Co rozhoduje o kvalitě:

• Ingestion a extrakce: spolehlivé konektory, OCR pro skeny, zachování struktury (nadpisy, tabulky, stránky), deduplikace a odstranění boilerplate.
• Chunking: hierarchický postup (sekce → odstavce → délka) s překryvem; zvláštní zacházení pro tabulky. Každý chunk nese identitu (dokument#sekce#offset) a oprávnění.
• Embeddings: volba modelu pro češtinu/multi-lingva, L2 normalizace, strategie re-embed při změně modelu; „hot“ vs. „cold“ tier indexů.
• Hybridní retrieval: vektor + BM25, fúze pořadí, re-ranking cross-encoderem, MMR proti redundanci, filtry metadat a time-decay pro nové verze.
• Citace: přesné odkazy na stránky/sekce, viditelná verze dokumentu, možnost prokliku; roste důvěra a klesá riziko halucinací.

Identita a přístupy: SSO, RBAC/ABAC, segmentace

LLM je služba jako každá jiná — integrujte jej do IAM a bezpečnostních standardů:

• SSO přes OIDC/SAML, mapování skupin na role v API bráně i v RAG kolekcích; enforce minimální nutná práva.
• RBAC/ABAC na úrovni chunku a kolekcí, aby se do promptu nikdy nedostalo, co uživatel nemá vidět.
• Segmentace sítě a tenantů, mTLS mezi službami, oddělení vektorové DB od aplikačních vrstev, egress politika.
• Rate limiting a kvóty pro ochranu před zneužitím a předvídatelné náklady.

Observabilita: metriky, logy, tracing, alerting

Bez viditelnosti ztratíte kvalitu i nákladovou kontrolu. Co sbírat a hlídat:

• Latence: time-to-first-token a tokens/s zvlášť pro prefill a decode; p50/p95/p99, fronty a využití cache.
• Využití akcelerátoru: paměť, occupancy, OOM události, teplota, podíl INT8/INT4 cest, hit-rate KV cache.
• Kvalita RAG: Recall@k, MRR, nDCG, podíl odpovědí s citací, míra „no sufficient context“.
• Bezpečnost: neúspěšné autentizace, podezřelé patterny v promptu (injection), porušení politik a egress pokusy.

Tracing vám rozkreslí cestu dotazu: retrieval → re-ranking → konstrukce promptu → generace → post-processing. Snadno tak identifikujete úzká hrdla a latencí náročné kroky.

Evaluace kvality: off-line, on-line a bezpečnost

Evaluace rozdělte na retrieval a odpověď; držte „as-of“ snapshot dat, aby bylo možné výsledky reprodukovat. Metriky:

• Retrieval: Recall@k, MRR, nDCG, Coverage, chybové případy (dotazy bez relevantních pasáží).
• Odpověď: exact match/F1 pro faktografii, „faithfulness“ (věrnost citacím), míra halucinací, stabilita formátu.
• Bezpečnost: míra odmítnutí zakázaných požadavků, odolnost vůči jailbreakům, správná práce s nejistotou.

On-line doplňte A/B testy: čas do odpovědi, re-prompt rate, míra eskalací na člověka, spokojenost. Rozhodování o změně modelu či promptů dělejte na základě čísel, ne pocitů.

Výkon, latence a škálování: tokens/s, batching, cache

Pro interaktivní aplikace je rozhodující stabilní nízká latence. Osvědčené postupy:

• Continuous batching v inference serveru; správně nastavené limity drží TTFT nízko a zároveň zvyšují propustnost.
• KV cache sdílená mezi požadavky výrazně zrychluje decode; řízená velikost podle profilu konverzací.
• Kvantizace (INT8/INT4) a vhodná kompilace (TensorRT-LLM apod.) snižují latenci a nároky na paměť.
• Speculative decoding pro zrychlení generování; dále context budgeting (do promptu jen pasáže s přidanou hodnotou).
• Paralelismus pro větší modely: tensor-parallel a pipeline-parallel; počítejte s vyšší komplexitou orchestrací.

V RAG přímo šetří náklady i latenci redukce redundance (MMR) a „context compression“ — vložení zhuštěných pasáží místo celých stránek bez ztráty důležitých faktů.

Náklady a udržitelnost: TCO, energie, kapacitní plán

TCO zahrnuje compute (pronájem/odpisy), energii (včetně PUE datacentra), síť/úložiště, software, personál a rezervy. Jak na to prakticky:

1. Seberte profil volání: průměrné a p95 délky promptu/odpovědi, poměr RAG, průměrný počet citací.
2. Změřte tokens/s pro relevantní přesnosti (FP16/FP8/INT8/INT4) a dopočítejte počet replik pro SLA.
3. Vypočítejte cenu za 1000 požadavků pro různé varianty (větší model bez kvantizace vs. menší s kvantizací; GPU vs. kombinace s NPU offloadem).
4. Nasadťe response cache a embedding cache; invalidujte chytrými pravidly (změna relevantních kolekcí apod.).

Energeticky pomůže kvantizace, batching, kratší prompty a provoz v energeticky efektivních datacentrech. Pro dávkové úlohy zvažte plánování do časů s nižší uhlíkovou intenzitou sítě.

Governance a compliance: data residency, audit, PII

Bez governance riskujete reputaci i auditní problém. Minimální rámec:

• PII/PHI redakce už ve vstupu; do logů a embeddingů neposílejte víc, než je nutné.
• RBAC/ABAC na chunku a kolekcích; „row-level security“ v indexu.
• Lineage a evidence: dokument → verze → chunk → embedding_version → index_version; reprodukovatelnost odpovědí.
• Audit logy: kdo volal, jaký model, jaké citace; retenční a přístupové politiky.
• Data residency a šifrování; řízení životního cyklu logů a indexů dle práva a smluv.

Integrace do ekosystému: API brána, SIEM, CMDB

Self-hosted LLM musí zapadnout do vašich standardů IT:

• API brána: rate limiting, mTLS, validace schémat, transformace hlaviček, centralizace tajemství a klíčů.
• SIEM: centralizace auditů, korelace s dalšími událostmi, detekce anomálií.
• CMDB/asset management: model registry, verze kontejnerů, knihoven a konfigurací; vazba na změnové řízení.
• Secrets management: KMS/Vault, rotace klíčů, správa přístupů podle principu nejmenší nutnosti.

Spolehlivost a obnova: RPO/RTO, runbooky, testy

Odolnost chybám je stejně důležitá jako přesnost. Co nesmí chybět:

• Zálohy a replikace pro modelové váhy, registry, indexy a metriky; testované obnovy.
• RPO/RTO cíle a technická opatření (geo-repliky, snapshoty, hot/warm standby).
• Runbooky pro OOM incidenty, propady Recall@k, výpadky retrieveru či anomálie latence.
• Chaos a DR testy v bezpečných oknech; měřte, jak dlouho trvá návrat do SLA.

Vzorové scénáře nasazení

Právní a compliance RAG

Obsah tvoří šablony smluv, metodiky, citace zákonů. Nutné jsou přesné citace se stránkou a verzí dokumentu, striktní RBAC nad kolekcemi, hybridní retrieval a re-ranking. Odpověď musí bezpečně přiznat nedostatek informací a nabídnout eskalaci.

Interní copilot pro IT a analytiky

LLM navrhuje dotazy do datového skladu, generuje kostru kódu, pomáhá s readme. Důležitá je integrace do SSO, sandboxované „tool use“ (jen schválené repozitáře a databáze) a audit volání nástrojů.

Zákaznická podpora

RAG nad znalostní bází a ticketingem vrací odpovědi s citacemi, snižuje „time-to-first-answer“ a objem eskalací. Měřte recall a faithfulness, sledujte spokojenost a chybové dotazy pro zlepšování indexu.

Roadmapa adopce: pilot → hardening → škálování

1. Pilot: jeden use-case s jasným přínosem, dvě až tři modelové varianty, základní RAG a guardraily, měření Recall@k, TTFT, faithfulness a NPS.
2. Hardening: SSO, RBAC/ABAC, audit logy, SIEM, kvantizace, cache, policy enforcement, evidence pack pro bezpečnost a compliance.
3. Škálování: více kolekcí a jazyků, multi-tenant režim, automatizované re-embed/re-index, pravidelná regresní evaluace a drift monitoring, canary releasy.

Nejčastější chyby a jak se jim vyhnout

• Spoléhat na „větší model to vyřeší“ a ignorovat kvantizaci, batching, KV cache a RAG kvalitu.
• Žádná „as-of“ evaluace a slepé srovnávání cizích benchmarků; v produkci pak přichází zklamání.
• Chybějící governance: bez RBAC, lineage a auditů nelze prokázat, z čeho odpověď vznikla.
• Přetěžování promptu desítkami podobných pasáží; bez MMR a komprese roste cena i halucinace.
• Nedostatečná observabilita: bez metrik a tracingu nevíte, kde hoří latence a náklady.
• Nejasné licenční podmínky a původ vah; chybějící SBOM a podpisy v supply chain.

Závěr: bezpečný self-hosting jako výhoda

Self-hosted LLM není jen „model na vlastním serveru“. Je to produkt se vším všudy: bezpečnostní politika, observabilita, governance, disciplína v evaluaci a ekonomice. Zvolíte-li model pragmaticky (Llama, Mistral či Falcon dle cílů a licence), zřídíte pevný perimetr, nasadíte guardraily, kvalitní RAG a silné SSO/RBAC, získáte řešení, které je rychlé, přesné a auditovatelné — a které chrání vaše data i rozpočet. Tajemství úspěchu je v detailech: versioning všeho, metriky a tracing, pravidelné regresní testy, chytrá kvantizace, cache a kontextový rozpočet. S takovým základem se z open-source modelu stává spolehlivý firemní asistent, který roste s vaším byznysem a posiluje vaši technologickou suverenitu.