Kapacitetsplanering för on-premises LLM-driftsättningar: att dimensionera modeller efter hårdvara

Varför kapacitetsplanering för LLM är annorlunda

Klassisk kapacitetsplanering i stora organisationer börjar med CPU, minne och IOPS. LLM-servering börjar med GPU-minne, tokenkapacitet och svanslatens, och relationen mellan dem är betydligt mindre intuitiv. Ett kluster som presterar imponerande på batch-arbetsflöden kan kollapsa vid tjugo samtidiga chattsessioner, och en blygsam modell med god batching kan överträffa en mycket större modell på dåligt konfigurerad hårdvara. Kapacitetsplanering för on-premises-LLM är inte en kalkylövning utan en liten ingenjörsundersökning.

Målet med den här guiden är en praktisk ordning: beskriv arbetslasten, härled minnes- och kapacitetsbudgetar, dimensionera samtidighet och planera för tillväxt. Inget kräver exotiska verktyg. Det som krävs är disciplin att mäta den arbetslast du faktiskt har, inte den som modellens produktkort marknadsför.

Börja med arbetslastens form, inte modellstorleken

Innan du väljer GPU, beskriv arbetslasten. De variabler som spelar störst roll är:

• Förfrågningsmix: interaktiv chatt, batch-behandling av dokument, agent-baserade verktygsloopar och RAG-svarsgenerering beter sig väldigt olika. Ett enda kluster som servar allt är möjligt men kräver explicit prioritering.

• Tokenfördelningar för in- och ut-data: medel och p95 för promptlängd och svarslängd. RAG-arbetslaster har ofta långa indata och korta utdata; agent-arbetslaster ofta tvärtom.

• Samtidighetsprofil: topp av samtidigt aktiva sessioner, ankomstmönster och huruvida förfrågningar är interaktiva (latenskänsliga) eller asynkrona (kapacitetskänsliga).

• Kvalitetsgolv: den minsta godtagbara modellen per arbetsflöde. Alla uppgifter kräver inte en 70B-klassad modell; många dokumentuppgifter sköts väl av 7B-14B-modeller med domänmedvetna prompter.

Att omvandla dessa till siffror — även grova siffror från en tvåveckors loggningsövning — förändrar alla efterföljande beslut. Leverantörer dimensionerar efter sina benchmarks; din egen arbetslastform är det som faktiskt driver fakturan.

GPU-minne: modellvikter är bara en del av budgeten

Ett vanligt dimensioneringsfel är att bara räkna modellvikter. Enhetsminnet måste rymma:

• Modellvikter i vald precision (FP16, BF16, FP8 eller kvantiserad INT8/INT4).

• KV-cache, som växer linjärt med sekvenslängd och samtidighet och ofta dominerar minnet för långkontext-arbetslaster.

• Aktiveringsminne vid inferens, mindre per förfrågan men betydande vid breda batcher.

• Runtime-overhead från själva serveringsramverket — vLLM, TGI, SGLang och TensorRT-LLM bär var sin bokföring.

Räkna med att KV-cachen blir den bindande begränsningen för chatt- och agent-arbetslaster. Att aktivera paged KV cache (som vLLM gör), kvantisera KV-cachen och sätta maxkontextlängd per arbetsflöde är de spakar du har. Välj precision medvetet: FP8 eller välkalibrerad INT8 bevarar ofta kvaliteten samtidigt som det ungefär halverar minnestrycket jämfört med FP16.

Lämna alltid arbetsmarginal. En GPU på 95 procents minne har ingen plats för en ovanligt lång prompt eller en spekulativ avkodnings-draftmodell. Planera för 70-80 procents stadig minnesanvändning så att normal varians inte väcker dig klockan två.

Kapacitet, latens och svansens tyranni

Rubriksiffror för kapacitet (tokens per sekund vid batch 64) matchar sällan produktion (tokens per sekund vid batch 3 med burstig ankomst). För interaktiva arbetslaster styr tid-till-första-token och latens mellan tokens upplevd kvalitet; för batch-arbetslaster är aggregerad tokens per sekund det som räknas.

Två konfigurationsval har överdimensionerad påverkan:

• Kontinuerlig batching: moderna serveringsmotorer batch:ar dynamiskt på tokennivå. Rätt konfigurerat mångdubblar detta den användbara kapaciteten jämfört med statisk batching, utan att skada interaktiv latens.

• Spekulativ avkodning: en liten draftmodell föreslår tokens som huvudmodellen verifierar parallellt. När det är tillämpligt minskar detta latens märkbart och är särskilt hjälpsamt för kort-utdata interaktiv trafik.

Mät både medel och p95 latens under realistisk samtidighet. En uppsättning med stark medelprestanda men ful svans kommer generera supportärenden från precis de användare vars transkriptioner blir fallstudier. Kapacitetsplanering måste dimensioneras för svansen, inte medelvärdet.

Samtidighet, isolering och flottans form

När per-GPU-budget är klar följer klusterformen ur samtidighetsmål. Några praktiska heuristiker:

• Föredra fler mindre noder framför färre mycket stora för interaktiv trafik. Fellägen blir mindre och rullande uppgraderingar svartlägger inte oproportionerligt mycket kapacitet.

• För mycket stora modeller som överstiger enskild GPU-minne är tensor- eller pipeline-parallellism oundviklig. Välj den minsta parallelliseringsgrad som ryms bekvämt; varje extra shard lägger till nätverksberoende och felyta.

• Isolera batch- och interaktiva arbetslaster på schemaläggarnivå. Ett stort batch-jobb som anländer klockan 10 ska inte fördröja första token i en chefs chattförfrågan.

• Håll en liten, dedikerad pool för utvärdering, canary och red team-trafik. Att återanvända produktions-GPU:er för dessa syften ger både brusig benchmark och olyckliga användare.

Tänk i termer av servicenivåer som backas av olika köer och olika kvantiseringar eller modellval, snarare än ett enda monolitkluster där varje arbetsflöde konkurrerar på lika villkor.

Planering för tillväxt och okända

On-premises-inköp löper på kvartal; LLM-adoption löper på veckor. Designa plattformen så att tidiga efterfrågetoppar inte kräver panikköp. Nyttiga spakar:

• Kvantiseringsskikt: förmågan att servera samma modell i FP16 eller INT8 på olika servicenivåer, vilket låter dig återta kapacitet under tryck utan inköpscykel.

• Modellkaskader: dirigera rutinarbete till mindre modeller och eskalera till större modeller bara vid behov. Kaskader förbättrar den effektiva kapaciteten dramatiskt när de flesta förfrågningar är rutinmässiga, vilket är typiskt för företagsarbetslaster.

• Hybridöversvämning: en förgodkänd, dataklassificerad väg för icke-känslig trafik att skala över till en betrodd extern leverantör när intern kapacitet är mättad. Flaskhalsen är vanligen styrning, inte teknik.

• Reservation och chargeback: gör kapaciteten synlig för affärsägare så att tillväxtsamtal sker före incidenter. Koppla till befintliga GPU-kvot- och chargeback-mönster för delade plattformar.

Se över planen kvartalsvis. Nya modeller, nya serveringsfunktioner och nya arbetslaster kommer snabbare än årliga cykler antar; team som räknar om kapaciteten varje kvartal undviker både överprovisionering och nödlägen.

Att knyta ihop det

Sund kapacitetsplanering för on-premises-LLM börjar med arbetslastform, inte hårdvaruspecifikationer. Därifrån budgeteras GPU-minne över vikter, KV-cache, aktiveringar och runtime-overhead med medveten marginal. Kapacitet och latens mäts under realistisk samtidighet, med kontinuerlig batching och spekulativ avkodning behandlade som förstaklassiga verktyg. Samtidighetsmål styr flottans form, isolering och servicenivåer. Slutligen skyddar kvantiseringsskikt, kaskader, hybridöversvämning och synlig chargeback plattformen mot det okända. Team som gör detta bra diskuterar sällan kapacitet offentligt; de som inte gör det diskuterar det vanligen i sina post-incident-granskningar.

Utvald bild av Dimitris Chapsoulas på Unsplash.