Argumentet lyder overbevisende: Lej eller køb acceleratorer, kør en model med åbne vægte, og erstat en variabel API-regning. Men modeller er ikke automatisk ligeværdige, GPU’er forbliver ikke fuldt udnyttede, og du overtager ansvaret for hele inferensstakkens sikkerhed og driftsstabilitet.
Denne artikel er en vejledning i omkostningsmodellering, ikke et benchmark. Gennemgå den aktuelle vLLM-dokumentation, vLLMs sikkerhedsvejledning, SGLang-dokumentation og Hugging Face TGI-dokumentation, før du vælger en server. Benchmark understøttede versioner på den målhardware, du bruger.
Virkeligheden er mere kompleks. Selvhosting vinder reelt ved visse skalaer. Ved andre vokser driftsomkostningerne, til de overstiger besparelserne på inferens. Nulpunktet varierer efter arbejdsbelastning, modelstørrelse, krav til latenstid og teamkapacitet.
Denne artikel går i dybden med beregningerne, de praktiske driftsforhold og de mønstre, der adskiller teams, der bør selvhoste, fra dem, der ikke bør. Vi antager, at du overvejer dette seriøst og ønsker konkrete tal.
Hvornår giver selvhosting mening
Nogle kendetegn, der taler for selvhosting:
Skala og udnyttelse. Vedvarende, forudsigelig efterspørgsel kan amortisere reserveret kapacitet. Brug den målte belastningsfordeling time for time; månedlige API-omkostninger alene udgør ikke en nulpunktsanalyse.
Forudsigelig arbejdsbelastning. Stabil, forudsigelig brug. Selvhosting kræver kapacitetsplanlægning; spidsbelastninger fører enten til spildt kapacitet (underudnyttelse) eller svigt (overbelastning).
Krav til databeskyttelse og regeloverholdelse. Data, der ikke må sendes til cloudleverandører (regulerede brancher, visse offentlige kontrakter eller data, der kun må bruges internt).
Tilpassede modeller. Finjusterede modeller, egenudviklede arkitekturer eller specialiserede varianter, som administrerede tjenester ikke tilbyder.
Kontrol over latenstiden. At hoste tættere på brugerne og kontrollere batchbehandlingen kan forbedre latenstiden, men netværk, kødannelse, modelstørrelse, promptlængde og belastning dominerer stadig. Benchmark den målpercentil, du har brug for.
Omkostninger pr. kald under nulpunktet. Når du laver regnskabet, og selvhosting reelt vinder.
Når de fleste af disse forhold er sande, er selvhosting værd at overveje seriøst.
Hvornår giver selvhosting ikke mening
Den anden side. Kendetegn, der taler for administrerede API’er:
Lav eller varierende skala. Ubrugt kapacitet og dimensionering efter spidsbelastning kan udslette de tilsyneladende besparelser på tokenprisen. Administreret inferens kan passe bedre, men beregn begge scenarier.
Store belastningsudsving. Store forskelle mellem spids- og lavperioder kan efterlade reserveret kapacitet ubrugt eller kræve dyr dimensionering efter spidsbelastningen.
Behov for en funktion fra en lukket model. Nogle aktuelle modeller, modaliteter, sikkerhedssystemer eller administrerede værktøjer er kun tilgængelige gennem en leverandørtjeneste. Hvis evalueringen af arbejdsbelastningen kræver én af dem, skal leverandørløsningen og dens kontraktmæssige begrænsninger indgå i sammenligningen. Erstat den ikke med en model med åbne vægte, som ikke er blevet evalueret.
Lille team. Selvhostet inferens kræver driftsmæssig ekspertise. Uden afsat kapacitet går tingene i stykker.
Hurtige iterationer. Hvis I afprøver mange forskellige modeller, konfigurationer og leverandører, gør API’er arbejdet lettere; ved selvhosting bliver hver ændring til en udrulning.
Flere regioner og globale brugere. Selvhosting kan kræve regional kapacitet, routing, dataoverførsel og genoprettelsesarbejde. Administrerede API’er kan reducere ansvaret for infrastrukturen nogle steder, men regional tilgængelighed, dataplacering, failover og netværksforsinkelse skal stadig verificeres.
I disse tilfælde kan administrerede API’er fortsat være løsningen med lavere risiko eller mindre driftsansvar, selv når deres direkte brugsomkostninger er højere.
Omkostningsmatematikken (forsigtigt)
Opstil tre aktuelle scenarier med tilsvarende kvalitet: et API til en lukket model, administreret drift af en model med åbne vægte og selvhosting. Sammenlign ikke modellerne, før de har bestået den samme opgaveevaluering.
Beregn for hvert scenarie:
monthly total = metered inference or dedicated capacity + storage + network + observability + support + security/compliance + engineering + expected incident loss
For forbrugsafregnede API’er stammer inferensomkostningen fra faktureret input uden cache, skrivning til og læsning fra cache, output- og ræsonneringstokens, værktøjer, batchkørsler og gentagne forsøg. For selvhostet eller administreret, dedikeret kapacitet skal acceleratorpuljen omfatte udnyttet og ubrugt kapacitet samt reserve til udrulning, fejl og alternative løsninger. Læg ikke et ekstra »inferensgebyr« oveni, medmindre kontrakten har en særskilt måleenhed, der ikke overlapper de øvrige. Fordel kapacitetsomkostningen på arbejdsbelastningen ud fra benchmarkede forespørgsler pr. acceleratortime ved den krævede latenstid og tilgængelighed, ikke ud fra leverandørens maksimale gennemløb.
Kør en følsomhedsanalyse af volumen, forholdet mellem spids- og gennemsnitsbelastning, modelkvalitet, acceleratorpris, udnyttelse, personaletid og migrationsomkostninger. Nulpunktet er dér, hvor nettoomkostningerne for løsninger med tilsvarende kvalitet krydser hinanden inden for et realistisk spænd af antagelser.
Driftsomkostningerne
Ud over de direkte inferensomkostninger kommer driftsomkostningerne ved selvhosting.
Indledende opsætning:
- Valg af den rigtige inferensserver (vLLM, TGI, SGLang).
- Konfiguration til din model og hardware.
- Opsætning af GPU-infrastruktur (cloud eller ejet).
- Netværk, sikkerhed, observerbarhed.
- Kvantisering og optimering.
Estimér den indledende levering ud fra en afgrænset opdeling af arbejdet, leveringstider for hardware og leverandørydelser, sikkerhedsgennemgang, benchmarkmatrix, tilgængelighedsdesign og teamets målte gennemløb. Denne artikel angiver ikke et generelt antal ingeniøruger, der kan overføres til andre projekter.
Løbende drift:
- Overvågning (latenstid, gennemløb, fejl og GPU-udnyttelse).
- Kapacitetsplanlægning.
- Opgraderinger (nye modelversioner, opdateringer af inferensserveren og sikkerhedsrettelser).
- Hændelseshåndtering (GPU-fejl, nedbrud på grund af utilstrækkelig hukommelse og softwarefejl).
- Skalering (flere GPU’er i takt med, at belastningen vokser).
Registrér det faktiske ansvar for platform, maskinlæring, sikkerhed og vagtordning. En antagelse om en brøkdel af en fuldtidsstilling kan ikke uden videre overføres mellem organisationer.
Skjulte omkostninger:
- GPU-prisvolatilitet.
- Omkostninger til udgående cloudtrafik i en hybrid opsætning.
- Specialiseret ekspertise (CUDA, kvantisering og optimering).
- Erstatnings-/fejlomkostninger for ejet hardware.
Brug organisationens samlede personaleomkostninger og alternativomkostninger. Besparelser på tokenprisen er ikke nettobesparelser, før driftsansvaret er medregnet.
Inferensserverne
Hvis du skal selvhoste, er de vigtigste muligheder:
vLLM. En inferensmotor med åben kildekode, løbende batchbehandling og bred, versionsafhængig modelunderstøttelse. Betragt dens sikkerhedsvejledning som obligatorisk læsning.
TGI (Text Generation Inference). Hugging Faces projekt til modeldrift. Verificér den aktuelle vedligeholdelsesstatus og modelunderstøttelse i stedet for at stole på artiklens øjebliksbillede.
SGLang. En inferens- og programmeringsstak under aktiv udvikling. Benchmark de nødvendige modeller, forløbet for struktureret output og driftsværktøjerne.
LMDeploy. Endnu en kandidat til modeldrift med versionsafhængig understøttelse af modeller, kvantisering og hardware. Benchmark den med de samme godkendelsestest.
llama.cpp / Ollama. Kandidater til lokale løsninger og visse serverbaserede arbejdsbelastninger. Understøttet hardware, samtidighed, sikkerhedsgrænse, driftskontroller og egnethed til produktion skal testes; ingen af navnene garanterer et bestemt gennemløb eller produktionsmodenhed.
Administrerede, dedikerede slutpunkter. Hugging Face og andre leverandører tilbyder administrerede slutpunkter, hvis motorer, afregning, isolation og ansvarsdeling ændrer sig over tid. Verificér den aktuelle tjeneste i stedet for at antage, at den kører TGI eller bruger en bestemt afregningsmodel.
Administrerede GPU- eller inferensplatforme. De kan overtage dele af arbejdet med kapacitet og modeldrift, mens ansvaret for integration, sikkerhed, evaluering og leverandørafhængigheder består. Sammenlign aktuelle tilbud og ansvar; antag ikke et fast prisforhold til selvdrift.
Medtag kun projekter, der understøtter den præcise model, accelerator, kvantisering, API-kontrakt og sikkerhedskontroller. En reproducerbar belastningstest afgør valget mellem dem.
Hardwarevalg
GPU-spørgsmålet:
Acceleratorgenerationer, hukommelseskapaciteter og lejepriser ændrer sig hurtigt. Indhent aktuelle tilbud for den nødvendige region og bindingsperiode.
Sammenlign hukommelseskapacitet og båndbredde, understøttede talformater, forbindelser mellem acceleratorer, softwarekompatibilitet, kvoter, regional tilgængelighed, fejladfærd og pris. Spotkapacitet eller kapacitet, der kan inddrages, hører kun hjemme i modellen, hvis afbrydelser håndteres, og genoprettelsesforløbet er målt.
Kvantisering
Kvantisering er én mulighed for at påvirke kapacitet og ydeevne. Afvejningerne afhænger af model, format, kerne, hardware og opgave:
Referencepræcision i FP16/BF16-klassen. Bruges ofte som sammenligningsgrundlag for understøttede modeller og hardware; det er ikke automatisk modellens oprindelige format eller et format med »fuld kvalitet«.
INT8 / FP8 (8-bit). Kan reducere hukommelsesforbruget til vægte eller forbedre understøttede udførelsesforløb; virkningen på kvalitet og hastighed varierer.
INT4 (4-bit). Kan reducere hukommelsesforbruget til vægte yderligere; mål kvaliteten og de anvendte kerners ydeevne for det konkrete artefakt.
AWQ, GPTQ, GGUF. Forskellige kvantiseringsformater med forskellige afvejninger.
En simpel beregning ud fra antallet af parametre giver kun et nedre estimat; hukommelsesforbruget under kørsel omfatter også KV-cache, aktiveringer, arbejdsområder, fragmentering og replikaer. Brug inferensmotorens profileringsværktøj og en belastningstest. Evaluér outputkvaliteten på produktionsopgaven, ikke kun med et generelt benchmark.
Gennemløb og kapacitetsplanlægning
Et centralt planlægningsspørgsmål: hvor mange tokens/sekund har du brug for?
Mål tiden til første token, latenstiden mellem tokens, den samlede latenstid, gennemløbet, køtiden, fejlraten og hukommelsesreserven på tværs af prompt- og outputlængder samt samtidighedsniveauer.
Til kapacitetsplanlægning:
- Estimér det største antal samtidige forespørgsler.
- Estimér den gennemsnitlige forespørgselslængde.
- Beregn det samlede behov for tokens pr. sekund.
- Tilføj en reserve udledt af kravene til belastningsspidser, fejl og udrulning.
Pålidelighed og reserveløsninger
Selvhosting betyder, at du ejer pålideligheden.
Sundhedstjek. Overvåg tjenestens tilstand løbende. Genstart instanser, der ikke fungerer korrekt.
Adfærd ved overbelastning. Brug køer med fast grænse, adgangskontrol, modtryk og en testet politik for reduceret funktionalitet eller afvisning. Hvis forespørgsler får lov til at vente uden grænse, kan overbelastningen forværres, og latenstidsmålet brydes.
API’er som reserveløsning. En administreret reserveløsning kan absorbere visse driftsafbrydelser eller belastningsspidser, men kun hvis modelkvalitet, datapolitik, kontrakter, hastighedsgrænser, tilstand og failover-adfærd er kompatible og testet. Løsningen øger kompleksiteten og kan svigte samtidig med den primære løsning.
Fejlreserve. Dimensionér reservekapacitet eller en alternativ rute ud fra tilgængelighedsmålet og testede fejlscenarier. Alle acceleratorer kan svigte, men dedikeret, ubrugt hardware er ikke den eneste designmulighed.
Flere regioner. Replikér løsningen til globale brugere, eller brug administrerede API’er i fjerne regioner.
Opdateringsstrategi. Planlæg nye modelversioner og serveropgraderinger. Brug eksempelvis blue-green-udrulninger for at undgå nedetid.
Hvert af disse punkter kræver ingeniørarbejde, som administrerede API’er overtager for dig.
To beslutningsdokumenter, der skal udarbejdes
Opfind ikke et anonymiseret resultat. Udarbejd reviderbare beslutningsdokumenter ud fra aktuelle tilbud og benchmarkartefakter.
Dokumentation for selvhostingskandidaten:
- modelartefakt, revision, licens, kvantisering, inferensserverens version, accelerator, region og udrulningstopologi,
- fordeling af arbejdsbelastningen og kvalitetsevaluering i forhold til det nuværende administrerede sammenligningsgrundlag,
- kommando til belastningstest, datasæt, resultater for latenstid og gennemløb, mætningspunkt og genoprettelsesadfærd,
- kapital- eller lejeomkostning, udnyttelse, ingeniørindsats, sikkerhedsarbejde og forventet hændelsesomkostning,
- nulpunktets interval med følsomhedsanalyse og et kriterium for at forlade løsningen.
Dokumentation for den administrerede kandidat:
- leverandør, model- og revisionsadfærd, region, prisliste og dens dato, kvoter og kontraktvilkår,
- dokumentation for tilsvarende kvalitet, latenstid, hastighedsgrænser, driftsafbrydelser og datagrænser,
- migrationsindsats og risiko ved leverandørkoncentration,
- betingelser der ville udløse en ny selvhostings-evaluering.
Hvornår skal du genoverveje beslutningen
Beslutningen er ikke permanent. Gennemgå den periodisk:
Volumenændringer. Stiger volumen markant, bliver selvhosting mere attraktivt. Falder den markant, bliver det mindre attraktivt.
Prisændringer. API’er til lukkede modeller bliver billigere eller dyrere. Administrerede løsninger med åbne vægte bliver billigere. Hardware bliver billigere.
Modelforbedringer. Nye kandidater med åbne vægte eller tilgængelig kildekode, som opfylder målet for arbejdsbelastningen, eller nye lukkede modeller, der ændrer kvalitetssammenligningen. Verificér licenser og faktisk tilgængelighed.
Driftskapacitet. Teamets evne inden for maskinlæring og drift er vokset eller skrumpet.
Ændringer i databeskyttelse eller regeloverholdelse. Nye krav, der nødvendiggør selvhosting.
Fastlæg en gennemgangsfrekvens ud fra kontrakt, pris, model, arbejdsbelastning, sikkerhed og udsving i kapaciteten, og tilføj hændelsesbaserede udløsere. En kvartalsvis gennemgang er et eksempel, ikke en universel standard.
Almindelige fejl
Mønstre vi ser i selvhostingsbeslutninger:
Fejl 1: Beregning uden driftsomkostninger. Besparelser på tokens eller acceleratorer rapporteres, mens ingeniørarbejde, vagtordning, sikkerhed og hændelsesomkostninger udelades.
Fejl 2: Selvhosting for tidligt. At bruge ingeniørressourcer på selvhosting, når arbejdsbelastningen er lille. Det er for tidlig optimering.
Fejl 3: Sammenligning af løsninger med forskellig kvalitet. En billigere model vælges uden at påvise, at den opfylder arbejdsbelastningens krav til kvalitet, sikkerhed og latenstid.
Fejl 4: Ingen fejlplan. Selvhostet infrastruktur går ned uden en testet plan for reduceret funktionalitet, kø, afvisning eller en alternativ rute. Administrerede API’er kan også fejle; sammenlign begge arkitekturer med det samme tilgængelighedsmål.
Fejl 5: At antage, at den første inferenskonfiguration er effektiv. Der gennemføres ingen reproducerbar afprøvning på tværs af understøttede kvantiseringsformer, batchstørrelser, samtidighedsniveauer, promptlængder og serverindstillinger. Derfor hviler kapacitetsmodellen på en konfiguration, der ikke er verificeret.
Fejl 6: At ignorere kvalitetsforringelse. Den selvhostede model er blevet ringere end den nuværende lukkede model. Kunderne bemærker det, selv om teamet ikke gør.
Fejl 7: Ikke at genoverveje beslutningen. Når løsningen først er selvhostet, bliver den aldrig evalueret igen. Beslutningen kan have været rigtig for to år siden og være forkert nu.
Fejl 8: Spotkapacitet eller kapacitet, der kan inddrages, uden robust håndtering. Rabatteret kapacitet modelleres uden afbrydelsesfrekvens, genoprettelsestid, dobbeltarbejde eller omkostningen ved en reserveløsning.
En beslutningstjekliste
For at træffe beslutningen bevidst:
- Er administrerede og selvhostede kandidater med tilsvarende kvalitet blevet sammenlignet i en benchmark?
- Er arbejdsbelastningen stabil og forudsigelig?
- Har teamet de nødvendige kompetencer inden for MLOps og inferens, eller kan det ansætte dem?
- Findes der en kandidat med en passende licens og med åbne vægte eller tilgængelig kildekode, som opfylder arbejdsbelastningens mål for kvalitet og sikkerhed?
- Er latenskrav kompatible med selvhosting?
- Har du lavet et detaljeret omkostningsregnskab inklusive driftsomkostninger?
- Har du en plan for en reserveløsning?
- Tvinger krav til regeloverholdelse eller databeskyttelse jer til en bestemt løsning?
- Er der en dokumenteret gennemgangsfrekvens og hændelsesbaserede udløsere for væsentlige ændringer i model, pris, kontrakt, arbejdsbelastning, sikkerhed eller kapacitet?
Reducér ikke dette til antallet af afkrydsede felter. Sikkerhed, modelkvalitet eller driftsansvar kan være afgørende hindringer, selv når alle økonomiske input ser gunstige ud.
Hybride mønstre
Det er ikke alt eller intet. Mulige hybridmønstre omfatter:
Selvhosting til hovedparten; API’er til de svære tilfælde. Klassifikation og enkel generering kører selvhostet, mens kompleks ræsonnering kører via API’er til lukkede modeller.
Selvhosting til grundbelastningen; API’er til spidsbelastninger. Den selvhostede løsning håndterer grundbelastningen, mens API’er absorberer spidsbelastningerne.
Selvhosting til følsomme data; API’er til generelle data. Følsomme data går gennem den selvhostede løsning, mens generelle forespørgsler går gennem API’er.
Selvhosting til finjusterede modeller; API’er til basismodeller. Teamet kører selv de tilpassede modeller, mens standardmodeller leveres via API’er.
En hybridløsning øger kompleksiteten inden for routing, datapolitik, evaluering, observerbarhed, kontrakter og fejlhåndtering. Vælg den kun, når test viser, at opdelingen forbedrer et udtrykkeligt mål.
Beslut ud fra den aktuelle dokumentation
Selvhosting er en levedygtig arkitektur, når en understøttet model opfylder arbejdsbelastningens kvalitetsmål, og organisationen kan tage ansvar for hele inferensløsningens livscyklus.
Nulpunktet er ikke et universelt månedligt beløb. Det ændrer sig med modelkvaliteten, belastningsprofilen, udnyttelsen, accelerator- og leverandørpriserne, tilgængeligheden, kravene til datagrænser og personaleomkostningerne.
Dokumentation, der understøtter en selvhostingbeslutning, bør vise, at teamet:
- har lavet regnskabet omhyggeligt, inklusive driftsomkostninger,
- har eller kan opbygge kompetencer inden for MLOps,
- arbejder i tilstrækkelig skala til at retfærdiggøre investeringen,
- har stabile arbejdsbelastninger,
- kan undvære funktioner, der kun findes i de mest avancerede modeller,
- har planlagt pålidelighed, overvågning og opdateringer.
Dokumentation, der taler for en administreret tjeneste, kan omfatte:
- Lavere skala.
- Arbejdsbelastninger med store udsving.
- Behov for hurtig iteration.
- Små teams uden driftskapacitet.
- Behov for funktioner, der kun findes i de førende lukkede modeller.
Det rigtige svar afhænger af den konkrete arbejdsbelastning. Sammenlign kvalitet, belastning, fejl, sikkerhed og omkostninger, og vurder driftskapaciteten. Foretræk den løsning med mindst driftsansvar, som opfylder de ufravigelige krav; den kan være administreret, selvhostet eller hybrid.
Når selvhosting vælges, skal den målte fordel, antagelserne, ejeren, kriterierne for at forlade løsningen og udløseren for næste gennemgang registreres. Gør det samme for administreret inferens; ingen løsning er rigtig uden aktuel dokumentation.
