Zahteve za lokalno LLM sklepanje: Opredelite delovno obremenitev pred nakupom GPU

Podjetniška lokalna LLM inferenca je problem sočasnosti in SLO inženiringa, ne nakupa GPU-jev. Vsak dokument z zahtevami, ki se začne z ‘kateri GPU poganja 70B model’, je že propadel — to vprašanje odgovarja na demo za enega uporabnika in prezre sedem spremenljivk, ki dejansko odločajo, ali sistem preživi produkcijo: žetoni na dan, sočasni uporabniki, cilj časa do prvega žetona, dolžina konteksta, razred modela, razred skladnosti in nivo dostopnosti.

VRAM tabele za FP16 uteži ne povedo ničesar o pritisku KV predpomnilnika pri 200 sočasnih sejah. Benchmarki žetonov na sekundo za en tok ne povedo ničesar o P99 latenci med ponedeljskim jutranskim skokom. Ta objava predstavlja zaporedje dimenzioniranja, ki ga uporabljamo pred katerim koli pogovorom o strojni opremi — tisto, ki omogoča podjetjem, da dostavljajo v tednih, namesto da bi leto dni odkrivala, kaj bi morala specificirati prvi dan.

Seznam za nakup GPU-jev je napačen artefakt

Privzeto podjetniško vprašanje — ‘katero strojno opremo potrebujemo za pogon Llama 70B?’ — proizvede seznam delov, ki preživi natanko eno fazo projekta: prototip. Referenčne številke so privlačne, ker so konkretne. Llama 3.1 70B potrebuje približno 140 GB VRAM pri FP16, okoli 35 GB pri INT4 in okrog 38–42 GB v praksi, ko upoštevamo metadata, KV predpomnilnik in režijske stroške ogrodja ^[1]. 24B model pristane pri 48 GB pri FP16 in 12 GB pri INT4; 7–8B model se umesti v 16 GB pri FP16 ali 4 GB pri INT4 ^[6]. Te številke so pravilne. So pa tudi neuporabne kot artefakt zahtev, ker opisujejo en sam prehod za enega uporabnika.

Pravi začetni artefakt je profil delovne obremenitve, ne seznam delov. Preden kdorkoli navede GPU, mora dokument z zahtevami vsebovati sedem številk: največje število žetonov na dan, največje število sočasnih uporabnikov, ciljni P50 in P99 TTFT, povprečno in največjo dolžino konteksta, razred modela (klepet, RAG, koda, multimodalno), klasifikacijo podatkov (javni, interni, regulirani, zračno ločeni) in nivo dostopnosti (99%, 99,9%, 99,99%). Vsaka nadaljnja odločitev — kvantizacija, inferenčni motor, število GPU-jev, omrežje, kadrovske potrebe — izhaja iz teh sedmih vhodov. Nobena od njih ne izhaja iz VRAM tabele.

VRAM je omejitveni faktor za to, kateri modeli sploh tečejo na GPU; pasovna širina pomnilnika je omejitev za CPU inferenco ^[8]. To je strojna resnica, ne metodologija dimenzioniranja. Obravnavati jo kot metodologijo je način, kako organizacije končajo z lepo specificirano škatlo, ki se ustavi pri 40 sočasnih uporabnikih.

Matematika sočasnosti je zahteva, ki jo konkurenti preskočijo

Dejanska zmogljivost je žetoni na sekundo na uporabnika, pomnoženo s sočasnimi uporabniki, plus odtis KV predpomnilnika na aktivno sejo, plus režijski stroški ogrodja. Velikost FP16 uteži je spodnja meja vašega VRAM proračuna, ne zgornja. Vsaka aktivna seja nosi svoj KV predpomnilnik, ki se skalira z dolžino konteksta, in ta predpomnilnik živi v istem VRAM-u kot uteži. 70B model, ki ‘se umesti’ v 140 GB pri FP16 ^[1], ne prenese 100 sočasnih uporabnikov z 8K kontekstom — ne ker so uteži zrasle, temveč ker je predpomnilnik na sejo.

24B INT8 model z 24 GB ^[6] izgleda udobno na enem 48 GB GPU, dokler ne dodate 80 sočasnih RAG sej s 16K kontekstnimi okni, pri čemer pritisk KV predpomnilnika prisili bodisi izključevanje, uvrščanje v čakalno vrsto ali drugi GPU. Počasno sklepanje, visoka poraba virov in nizka sočasnost so prevladujoči podjetniški ozki grli, odzivi preko petih sekund pa uničijo primere uporabe v realnem času ^[4]. Dinamično grupiranje in upravljanje pomnilnika v slogu PagedAttention obstajata prav zato, ker naivno serviranje propade pod sočasnostjo.

Zaporedje dimenzioniranja je: ocenite največje število sočasnih aktivnih sej, pomnožite s povprečno dolžino konteksta, izpeljite proračun KV predpomnilnika, dodajte odtis uteži, dodajte 2–4 GB režijskih stroškov ogrodja, nato dodajte rezervo za P99 skok. Šele tedaj veste, koliko GPU-jev delovna obremenitev potrebuje. Ta številka skoraj nikoli ni številka, ki jo dobite z deljenjem velikosti modela z GPU VRAM.

TTFT in dostopnost sta vhoda, ne rezultata

Če poslovni primer zahteva sub-50ms TTFT pri P99 in 99,9% dostopnost, so to omejitve dimenzioniranja — ne aspiracijske metrike za merjenje po namestitvi. Ustrezno dimenzionirano lokalno sklepanje dostavi približno 15–30 ms P50 TTFT, medtem ko oblačni API-ji običajno pristanejo pri 100–300 ms P50 in skočijo na 1–2 sekundi pri P99 med preobremenitvijo ponudnika ^[1]. Lokalna prednost je resnična, vendar le če je grozd opremljen z rezervo za držanje P99 pod obremenitvijo: redundantni inferenčni vozlišča, konservativni politiki grupiranja in zmogljivost rezervirana za failover.

Nivo dostopnosti spremeni topologijo grozda, preden spremeni karkoli drugega. 99,9% dovoljuje približno 8,7 ure izpadov na leto, kar prisili N+1 inferenčne vozle, poteke dela za rollback modela, poti canary namestitve in načrt za okrevanje po nesreči, ki preživi odpoved enega rack-a. Ničesar od tega se ne pojavi na VRAM tabeli. Infrastrukturno dno — redundantno napajanje in hlajenje, 10 Gbps interno omrežje, minimalno 64–128 GB RAM, interna MLOps zmogljivost ^[7] — je potrebno, vendar ni zadostno. Dejanska številka vozlišč je funkcija vašega SLO, ne velikosti modela.

Če ne morete navesti svojih TTFT in ciljev dostopnosti, ne morete dimenzionirati grozda. Nakup GPU-ja najprej in odkrivanje SLO pozneje je najdražje zaporedje v tej celotni kategoriji.

Izbira inferenčnega motorja je odločitev delovne obremenitve, ne preference

Ollama, vLLM in SGLang niso zamenljivi runtime-i s kozmetičnimi razlikami. To so različni motorji za različne profile delovnih obremenitev, napačna izbira pa je način, kako prototipi ne uspejo diplomirati. Podjetniško preslikavanje: Ollama za hitro lokalno namestitev in interno testiranje, vLLM za visoko zmogljive API storitve z obsežnimi zahtevami in visoko sočasnostjo ter SGLang za kompleksne multimodalne naloge, kot so image-text in OCR poteki ^[4].

Način odpovedi je predvidljiv. Ekipa naredi prototip na Ollama, ker je brez trenja, ga uspešno predstavi vodstvu, nato pa ga poskuša postaviti za podjetniški API gateway s 500 sočasnimi uporabniki in gleda, kako se pretočnost podre. Motor ni bil napačen za prototip; bil je napačen za produkcijski profil delovne obremenitve. Dinamično grupiranje in paged attention vLLM obstajata, ker je visokosočasno API serviranje temeljno drugačen inženirski problem kot sklepanje za enega uporabnika. Migracija med motorji sredi projekta je draga — dotakne se strategije grupiranja, opazljivosti, avtentikacije in instrumentacije SLA.

Izbira motorja sodi v dokument z zahtevami poleg profila delovne obremenitve, ne v poznejšo fazo ‘implementacijske podrobnosti’. Profil delovne obremenitve narekuje motor. Motor narekuje politiko grupiranja. Politika grupiranja narekuje število GPU-jev. Obrnite to zaporedje in projekt dostavlja pozno.

TCO, ki se ustavi pri ceni GPU, je fikcija

Argument prelomnice proti oblačnim API-jem je resničen. Organizacije, ki vzdržujejo več kot približno 10 milijonov žetonov na dan, lahko vidijo, da se lokalna namestitev povrne v 12–18 mesecih: 10M žetonov/dan stane 6.000–9.000 $ mesečno preko oblačnega API proti 3.500–6.000 $ lokalno, 100M žetonov/dan pa stane 60.000–90.000 $ v oblaku proti 8.000–15.000 $ lokalno ^[1]. Te številke so verodostojne. So pa tudi nepopolne.

TCO model, ki se ustavi pri strošku nakupa GPU, je fikcija. Postavke, ki spremenijo 18-mesečno povračilo v 30-mesečno, so tiste, ki jih konkurenti izpustijo: poraba energije pri rack gostoti, ki zahteva nestandardno PDU oskrbo, hlajenje, ki lahko prisili tekoče zanke ali zadrževanje hodnika, kolokacijske pristojbine, če ne posedujete podatkovnega centra, 10 Gbps+ interno omrežje ^[7], infrastruktura opazljivosti in beleženja, MLOps in platform engineering kadrovske potrebe, osvežitev strojne opreme na 3–5 letnem ciklu ter tveganje izkoriščenosti, če promet ne zraste v grozd, ki ste ga dimenzionirali za vrh.

Lokalna rešitev zmaga pri TCO nad pragom žetonov in pod pragom tveganja izkoriščenosti, le če je operativni model kadrovsko pokrit. En-vendor sklad, ki združuje strojno opremo, runtime, modele, aplikacije in podporo, stisne postavke, ki uničijo naivne TCO modele — zato nabavno vprašanje ni le ‘koliko stane GPU’, temveč ‘kdo ima v lasti sklad na dan 400’.

Razred skladnosti spremeni celoten sklad, ne le omrežni diagram

Zračno ločene in z GDPR vezane delovne obremenitve ne dodajo preprosto firewall pravila k sicer standardni namestitvi. Spremenijo runtime, potek dela za posodabljanje, revizijsko površino in model odzivanja na incidente. Zračno ločen grozd potrebuje offline pipeline artefaktov modela, podpisane pakete posodobitev, reproducibilne namestitve in pot rollback, ki ne predpostavlja dostopa do interneta. Z GDPR usklajen grozd potrebuje politike hranjenja pozivov in dopolnitev, redakcijo ob vnosu, nadzor dostopa, vezan na obstoječe identitetne sisteme, ter revizijske sledi, ki zadostijo regulatorju, ne le interni SRE.

RAG delovne obremenitve dodajo svojo plast skladnosti: sledenje citatov nazaj do izvornih dokumentov, številke strani in revizije dokumentov, tako da se vsak odgovor lahko sledi do artefakta, ki ga je proizvedel. Ta zahteva je trivialna za prilepiti na prototip in boleča za retrofit na sklad, izbran zgolj zaradi pretočnosti. Isto velja za upravljanje artefaktov modela — vedeti, katera verzija modela je proizvedla kateri odgovor na kateri datum, s katerim iskanjem indeksa — kar je prva razredna runtime skrb, ne dodatna misel.

Razred skladnosti sodi v profil delovne obremenitve poleg žetonov na dan, ker določa, kateri inferenčni motorji, orkestracijskie plasti in arhitekture shranjevanja so sploh kandidati. Sklad, izbran za surove žetone na sekundo in nato zaprošen za proizvodnjo GDPR revizijske sledi dva četrtletja pozneje, je prepis, ne sprememba konfiguracije.

Nabava in operativni model sta del zahteve

Dobavni roki GPU-jev, vendor lock-in in odločitev graditi-proti-kolokaciji-proti-en-vendor-skladu sodijo v dokument z zahtevami, ne v ločeno nabavno pot, ki se začne po podpisu arhitekture. 30-dnevna pot do produkcije in 12-mesečna pot do produkcije sta različni zahtevi z različnimi dizajni grozdov, različnimi predpostavkami kadrovskih potreb in različnimi profili tveganja. Le ena od njih preživi pregled odbora, kjer ima AI iniciativa četrtletni mejnik.

Pot gradnje zahteva interno MLOps zmogljivost, odnose z dobavitelji strojne opreme in potrpežljivost za integracijo runtime-a, modelov, aplikacij in opazljivosti sami ^[7]. Pot kolokacije menja capex za opex in doda vendor površino k vašemu odzivu na incidente. Pot en-vendor sklada — strojna oprema, runtime, odprto-težinski modeli, aplikacije, namestitev in podpora od enega ponudnika — stisne čas do produkcije na račun fleksibilnosti sklada. Nobena od teh ni univerzalno prava. Vse tri so legitimni odgovori na različne profile delovnih obremenitev in različne organizacijske realnosti. Napačen odgovor je pustiti izbiro nedoločeno, dokler ne prispejo GPU-ji.

Podjetja, ki dimenzionirajo delovno obremenitev najprej, dostavljajo v tednih s predvidljivimi SLO. Podjetja, ki kupijo GPU najprej, preživijo naslednje leto s odkrivanjem, kaj bi morala specificirati prvi dan. Sedem številk — žetoni na dan, sočasni uporabniki, TTFT, kontekst, razred modela, razred skladnosti, dostopnost — ni kontrolni seznam. To je dokument z zahtevami. Vse drugo je implementacija.

Pošljite nam svoj profil delovne obremenitve in dimenzionirali bomo grozd — https://wavenetic.com