Lokální LLM.
Vhodně dimenzované.
Od vhodného modelu po spravovanou AI službu: DAXS plánuje lokální infrastrukturu LLM, prověřuje hardware při skutečné zátěži a integruje řešení do vašeho stávajícího IT.
AI server začíná profilem zátěže.
Lokální jazykový model může zpracovávat interní texty, pomáhat s návrhy kódu nebo být součástí vyhledávání znalostí. Pro použitelné řešení musí odpovídat kvalita modelu, povolené datové cesty a očekávané využití. DAXS tyto požadavky zmapuje, naplánuje infrastrukturu a zajistí instalaci, integraci i dohodnutý provoz – společně s vaším IT nebo jako vymezenou součást služeb.
Úkol a kvalita
Jaké otázky, jazyky, dokumenty nebo programovací úkoly má řešení zvládat? Krátký chat a analýza dlouhých podkladů vyžadují odlišné modely a kontexty.
Využití a čekání
Kolik požadavků přichází současně? Jak rychle musí začít první reakce a jak dlouho smí trvat celá odpověď? Příležitostné jednotlivé dotazy a trvale používaná týmová služba potřebují odlišné rezervy.
Data a provoz
Které zdroje a funkce jsou schválené? Kde smějí být model, vyhledávací index, protokoly a zálohy? Kdo řeší aktualizace a chyby a jaká cesta zpět je potřeba?
Řádně propojit aplikaci, inferenci a provoz.
Uživatelské rozhraní je jen částí celku. Před ním stojí kontroly identit a přístupu; za ním pracují inferenční služba, úložiště modelů a případně vyhledávání znalostí nebo firemní rozhraní. Dohled, aktualizace a obnova patří do stejného plánu.
Schéma ukazuje možnou architekturu, nikoli skutečnou zákaznickou síť. Reverzní proxy může zajistit TLS a vstup. Aplikace přesto musí vynucovat uživatelská oprávnění. API modelů se omezují na potřebné sítě a funkce; dostupný inferenční port ještě není hotovou firemní službou.
Více než velikost souboru modelu.
Při výběru posuzujeme váhy, nároky za běhu, kontext, souběh a celou datovou cestu. GPU může mít dostatek paměti, a přesto nemusí vyhovovat požadované době odezvy. Naopak menší, dobře vybraný model může úkol řešit ekonomičtěji.
| Součást | Co prověřujeme | Proč je to důležité |
|---|---|---|
| GPU a VRAM | Architekturu, ovladače, inferenční backend, podporované výpočetní formáty, velikost paměti a propustnost. | Váhy a KV cache potřebují místo. Výpočetní výkon a přenosy paměti ovlivňují různé pracovní fáze; samotná propagovaná hodnota TOPS aplikaci nepopisuje. |
| Jedna nebo více GPU | Rozdělení modelu, propojení GPU, připojení PCIe, energii a chlazení. | VRAM se automaticky neslučuje do volně použitelné společné paměti. Rozdělení a synchronizaci musí podporovat vybraný softwarový stack; další GPU mohou vytvořit nová úzká místa. |
| CPU a systémová RAM | Běhové prostředí, tokenizaci, přípravu dat, paralelní procesy a případně inferenci na CPU nebo přesouvání části výpočtů. | Přesunutí části modelu může umožnit jeho spuštění, ale mění výkonový profil. Přenosy mezi RAM a GPU mohou odpověď zpomalit. Také GPU server potřebuje odpovídající rezervy CPU a RAM. |
| NVMe a úložiště | Verze modelů, dobu načítání, vyhledávací index, importovaná data, protokoly, volnou kapacitu a zálohy. | Rychlé NVMe SSD pomáhají při načítání modelů a některých datových operacích. Generování tokenů modelem zcela uloženým v paměti GPU určují především výpočetní, paměťové a běhové faktory. |
| Síť a napájení | Připojení, povolené datové cesty, prostor, příkon, odpadní teplo a přístup pro údržbu. | Nejlepší jednotlivá výpočetní komponenta příliš nepomůže, pokud službu při skutečné zátěži omezují teploty, organizace nebo přístup k datům. |
Výpočetní pomůcka – nikoli doporučení k nákupu.
Samotnou dolní hranici pro váhy lze zhruba odhadnout jako počet parametrů × počet bitů na váhu ÷ 8 Hypotetický model s osmi miliardami parametrů a čtyřmi bity na váhu má výpočtem čtyři gigabajty, tedy přibližně 3,73 GiB.
K tomu přibývají metadata kvantizace, případně části modelu s vyšší přesností, KV cache, pracovní oblasti a běhové prostředí. Tato hodnota proto výslovně neříká, jaká kapacita VRAM stačí pro vaši aplikaci. U modelů s architekturou expertů je navíc nutné odlišovat aktivně počítané části od všech vah, které musejí být k dispozici.
Krátká odpověď je jiný test než týmová služba.
Kontextové okno zahrnuje informace, které může model zohlednit pro jeden požadavek. Podle aplikace sem patří instrukce, historie rozhovoru, načtené části dokumentů a plánovaný výstup. Nominálně velké kontextové okno nezaručuje vhodný hardware ani spolehlivé využití informací.
KV cache
Key-value cache uchovává mezistavy mechanismu pozornosti. Její nároky závisejí mimo jiné na architektuře modelu, datovém typu, skutečně obsazeném kontextu a současně aktivních sekvencích. Více kontextu a vyšší souběh často výrazně zvyšují spotřebu paměti.
Prefill a decode
Při prefill model zpracovává vstupní kontext; při decode vznikají další tokeny. Obě fáze zatěžují hardware odlišně. Dlouhé dokumenty mohou prodloužit dobu do prvního tokenu, i když následný výstup působí plynule.
Dávkové zpracování a fronta
Společné zpracování může zvýšit celkovou propustnost. Jednotliví uživatelé však mohou čekat déle. Do návrhu proto patří rezervovaná kapacita, fronty, limity a vhodné plánování souběhu.
Měříme skutečný případ použití.
Pilot zahrnuje typické krátké i dlouhé požadavky a souběžné přístupy. Sledujeme přitom Time to First Token, celkovou dobu odpovědi, rychlost výstupu, frontu, chybovost a obsazení paměti. Tokeny za sekundu lze smysluplně porovnávat jen spolu s verzí modelu, kvantizací, kontextem, zátěží a podmínkami měření.
Stack odpovídá modelu a využití.
Ollama, llama.cpp a vLLM jsou možnými součástmi. Výběr a konfigurace se řídí podporou modelu, hardwarem, požadovaným souběhem, provozem a integrací. Prověřujeme konkrétní verzi místo toho, abychom obecný instalační příkaz vydávali za produkční architekturu.
Ollama
Možný vstup do správy modelů a místního poskytování služby. Úložiště modelů, schválené modely, kontext, souběh a zabezpečení služby musejí odpovídat prostředí.
llama.cpp
Flexibilní součást pro vhodné modely na různých CPU/GPU backendech s kvantizovanými formáty a serverovým provozem. Podpora hardwaru, rozdělení a skutečně potřebné funkce API se prověřují prakticky.
vLLM
Možnost pro vhodné serverové inferenční a zátěžové profily. Plánování, KV cache, dávkové zpracování a případně více GPU se ladí společně. Vyšší celková propustnost neznamená kratší čekání každého jednotlivého požadavku.
Kontejner, virtuální stroj, nebo vlastní hostitel?
Kontejnery mohou reprodukovatelně sdružovat softwarové verze. Virtuální stroj může prostředí navíc organizačně a technicky oddělit. Vhodná cesta závisí na přímém předání zařízení, ovladačích, údržbě a stávajících provozních postupech. Kompatibilní API usnadňuje připojení, nenahrazuje však funkční test s vaší aplikací.
Kdy je vhodný Proxmox s GPU passthrough?
GPU passthrough přiřazuje vhodnou fyzickou GPU virtuálnímu stroji. Odpovídat musejí mimo jiné platforma a firmware, skupiny IOMMU, ovladače hostitele a hosta i chování při resetování zařízení. Konkrétní kombinaci prověříme před závazným příslibem.
Přiřazená GPU není automaticky flexibilně sdílitelná mezi několika virtuálními stroji. vGPU a přímé předání jsou odlišné koncepce s vlastními předpoklady a případně licenčními podmínkami. Také údržba, zálohování a případná změna hostitele vyžadují vhodný postup; paušální příslib živé migrace by nebyl přiměřený.
Vhodný model musí obstát v úkolu.
Modely porovnáváme pomocí schválených příkladů z budoucího použití: například německých odborných otázek, výňatků z dokumentů, vícejazyčných požadavků nebo konkrétního skriptovacího úkolu. Model pro programování a embeddingový model plní odlišné úkoly. Při vyhledávání znalostí musejí odpovídat vyhledávání, embeddingy a model odpovědí.
Kvantizace často snižuje nároky na paměť. Dopad na kvalitu odpovědí, volání nástrojů a rychlost se prověřuje u vybraného formátu. Větší model není automaticky lepší nebo ekonomičtější volbou. Stejně tak dlouhý maximální kontext nedokládá, že model spolehlivě využije všechny informace v něm.
- Licence: konkrétně prověřit vybrané váhy modelu, komerční využití, další šíření a povinné informace; samotné stažení toto prověření nenahrazuje.
- Verze: dohledatelně zaznamenat model, kvantizaci, tokenizer a běhové prostředí.
- Přejímka: opakovatelnou sadou otázek prověřit odbornou vhodnost, nepřípustné odpovědi, jazykovou kvalitu a chybové případy.
- Změny: nejprve otestovat nové verze modelu, zachovat použitelnou cestu zpět a při změně embeddingů odpovídajícím způsobem znovu vytvořit vyhledávací indexy.
Místně, externě nebo ve vhodné kombinaci.
Vlastní hardware může dávat smysl při vhodném vytížení, jasných požadavcích na data a dostupném provozním rámci. Externí služba může být vhodnější při kolísavém využití, zvláštních schopnostech modelu nebo malé vlastní provozní kapacitě. Hybrid cíleně propojuje vymezené úkoly a datové cesty.
Porovnání zahrnuje pořízení nebo využívání, energii a chlazení, licence, integraci, aktualizace, správu, rezervu a následky výpadku. Místní zpracování automaticky nezaručuje bezpečnost ani soulad s GDPR: také modely, embeddingy, telemetrie, aktualizace, externí nástroje a protokoly musejí odpovídat dohodnuté datové koncepci.
Nejprve plánujeme zvládnutelný pilot s měřitelnými požadavky. Z jeho výsledku vychází rozhodnutí o rozšíření, úpravě nebo jednodušší alternativě. Další základy najdete v části Cloud a SaaS.
Spravovaná služba potřebuje přehledné odpovědnosti.
DAXS může naplánovat a nainstalovat hardware a software, připojit je ke stávajícím identitám a aplikacím a zajistit dohodnutý průběžný provoz. Patří sem sledování dostupnosti a prostředků, správa verzí, řešení chyb a dokumentace. Potřebná dostupnost a způsoby reakce se konkrétně sjednávají.
Stanovíme, které konfigurace, aplikační komponenty, indexová data a případně upravené modely se zálohují. Znovu získatelné váhy modelů a chráněná provozní data mají odlišné požadavky na zálohování. Test obnovy patří do vhodné provozní koncepce.
Zmapování požadavků, návrh architektury, test modelu a zátěže, zdokumentované datové cesty a srozumitelné doporučení hardwaru, způsobu provozu a dalších integračních kroků.
To vyjasníme při rozhovoru.
Kolik VRAM potřebuje lokální LLM?
Záleží na modelu a kvantizaci, běhovém prostředí, kontextu i souběžných požadavcích. Samotný soubor modelu jako podklad nestačí. Než doporučíme konkrétní vybavení, otestujeme požadovaný úkol včetně dlouhých požadavků a špiček zátěže.
Je druhá GPU automaticky rychlejší?
Ne. Vybraný stack musí podporovat rozdělení. Výsledek ovlivňují spojení mezi GPU, synchronizace a architektura modelu. Více paměti může umožnit spuštění, aniž by zrychlilo každou jednotlivou odpověď.
Lze použít stávající server Proxmox?
Může to být vhodné, pokud odpovídají hardware, skupiny IOMMU, ovladače a přímé předání GPU. Navíc musejí být dostatečné rezervy pro ostatní služby a vhodné postupy údržby, zálohování a obnovy. Stávající platformu konkrétně prověříme.
Trénují se interní dokumenty do modelu?
Pro vyhledávání znalostí to často není nutné. RAG vyhledá vhodné povolené části dokumentů a předá je modelu jako kontext. Úprava vah modelu je jiné opatření a odůvodňuje se samostatně.
Kdy je externí služba ekonomičtější?
Při malém nebo výrazně kolísavém využití, zvláštních požadavcích na model nebo nedostatečné provozní kapacitě může být externí služba vhodnější. Porovnáváme náklady, datové cesty, kvalitu a provoz za plánovanou dobu využívání.
Společně sledovat modely, zátěž a náklady.
Vedle vytížení GPU a doby odezvy sledujeme náklady na použitelný úkol. Aktualizace modelu se před nasazením porovná se schválenou testovací sadou. Chybovost, fronty, limity paměti a výpadky potřebují určené odpovědné osoby a cestu zpět. Externí náhradní služba připadá v úvahu jen tehdy, když to dovoluje třída dat a schválení.
Proberme váš případ použití.
Co se má zjednodušit, která data se zapojují a jaké systémy už máte? Z toho vytvoříme smysluplný začátek a zvládnutelný další krok.