Pakkumine on veenev: rendi või osta kiirendid, käita avatud kaaludega mudelit ja asenda muutuv API-arve. Mudelid ei ole aga automaatselt samaväärsed, GPU-d ei püsi täielikult kasutusel ning mudeliserveri tarkvarapinu turvalisus ja töökindlus jäävad sinu vastutada.
See on kulude modelleerimise juhend, mitte võrdlustest. Enne serveri valimist tutvu vLLM-i dokumentatsiooni, vLLM-i turvajuhiste, SGLangi dokumentatsiooni ja Hugging Face’i TGI dokumentatsiooniga. Võrdle toetatud versioone sihtriistvaral.
Reaalsus on keerulisem. Ise hostimine võidab tõeliselt teatud mastaapidel. Teistel kääbustab operatiivkulu inferentsisäästu. Tasuvuspiir varieerub töökoormuse, mudeli suuruse, latentsuse nõuete ja tiimi võimekuse järgi.
See artikkel läheb sügavale matemaatikasse, operatiivsetesse reaalsustesse ja mustritesse, mis eristavad tiime, kes peaksid ise hostima, neist, kes ei peaks. Eeldame, et sa kaalud seda tõsiselt ja tahad ausaid numbreid.
Millal ise hostimisel on mõte
Mõned omadused, mis soosivad ise hostimist:
Mastaap ja kasutus. Püsiv, prognoositav nõudlus võimaldab reserveeritud võimsuse kulusid tasuvaks muuta. Kasuta mõõdetud tunnist koormusjaotust; üksnes igakuine API-kulu ei ole tasuvuskünnise testi aluseks.
Ennustatav töökoormus. Stabiilne, ennustatav kasutus. Ise hostimine nõuab võimsuse planeerimist; tipuvahelised töökoormused raiskavad võimsust (alakasutus) või ebaõnnestuvad (üleküllastus).
Privaatsuse / vastavuse nõuded. Andmed, mida ei saa pilve pakkujatele saata (reguleeritud tööstused, teatud valitsuse lepingud, ainult sisekasutuseks olevad andmed).
Kohandatud mudelid. Peenhäälestused, kohandatud arhitektuurid või spetsialiseeritud variandid, mida hallatud pakkujad ei paku.
Latentsuse kontroll. Kasutajale lähemal majutamine ja pakktöötluse juhtimine võivad latentsust vähendada, kuid määravaks jäävad võrk, järjekord, mudeli suurus, prompti pikkus ja koormus. Mõõda sihtprotsentiilidele lähtetasemed võrdlustestiga.
Kulu kõne kohta tasuvuspiirist allpool. Kui sa teed matemaatika ja ise hostimine tõeliselt võidab.
Kui enamik neist on tõsi, on ise hostimine tõsiseks kaalumiseks väärt.
Millal ise hostimisel ei ole mõtet
Teine pool. Omadused, mis soosivad hallatud API-sid:
Madal või muutuv skaala. Tühikäekapasiteet ja tipukoormuse varumine võivad hävitada näivaid tokenihindu. Hallatud inferents võib sobida paremini, kuid käivita mõlemad mudelid.
Lõhestunud töökoormused. Suured erinevused tipu ja vaikse perioodi vahel võivad jätta reserveeritud võimsuse tühjaks või nõuda kulukat tipukoormuse varumist.
Suletud mudeli võimekuse vajadus. Mõned praegused mudelid, modaalvõimalused, turvasüsteemid või hostitud tööriistad on saadaval ainult pakkuja teenuse kaudu. Kui töökoormuse hindamine nõuab üht neist, lisa pakkuja tee ja kohaldatava lepingu piirangud, mitte ei asenda seda hindamata avatud mudeliga.
Väike tiim. Ise hostitud inferents nõuab operatiivset ekspertiisi. Ilma pühendatud võimekuseta asjad lähevad katki.
Kiire iteratsioon. Paljude erinevate mudelite, konfiguratsioonide, pakkujate proovimine. API-d teevad selle lihtsaks; ise hostimine muudab iga muudatuse eraldi juurutustööks.
Mitme regiooni / globaalsed kasutajad. Enesehostimine võib nõuda piirkondlikku võimsust, suunamist, andmeside ja taastumise tegevusi. Hallatud API-d võivad vähendada osa infrastruktuuri valitsemisest, kuid piirkonna kättesaadavus, andmeresidentsus, hädaolukorra üleminek ja võrgu latentsus nõuavad siiski kontrollimist.
Nende juhtumite jaoks võivad hallatud API-d jääda madalama riskiga või väiksema valitsemisvajadusega variant isegi siis, kui nende otsene kasutuskulu on kõrgem.
Kuluarvutus (hoolikalt)
Koosta kolm ajakohast ja kvaliteedilt võrreldavat stsenaariumi: suletud mudeli API, avatud kaaludega mudeli hallatud teenindamine ning oma taristus majutamine. Ära võrdle mudeleid enne, kui need on läbinud sama ülesandepõhise hindamise.
Arvuta iga stsenaariumi kohta:
monthly total = metered inference or dedicated capacity + storage + network + observability + support + security/compliance + engineering + expected incident loss
Mahupõhise API puhul moodustavad inferentsikulu arveldatud vahemällu salvestamata sisend, vahemälu kirjutus- ja lugemistoimingud, väljundi- ja arutlustokenid, tööriistad, paketid ning korduskatsed. Oma taristus või hallatud reserveeritud võimsusega lahenduse puhul peab kiirendite kulubaas hõlmama kasutatud ja jõudeoleku võimsust, varu, juurutusi ning rikke- ja taastevõimsust. Ära lisa teist „inferentsitasu“, kui lepingus pole eraldi, teineteist välistavat mahupõhist tasu. Jaga võimsuse kulu töökoormuse ühikutele nõutava latentsuse ja saadavuse juures mõõdetud päringute arvu järgi kiirenditunni kohta, mitte pakkuja suurima deklareeritud läbilaskevõime järgi.
Tee tundlikkusanalüüs mahu, tipp- ja keskmise koormuse suhte, mudeli kvaliteedi, kiirendi hinna, kasutusastme, töötajate ajakulu ning migreerimiskulu suhtes. Tasuvuspunkt on koht, kus kvaliteedilt võrreldavate lahenduste netokulud usutavate eelduste vahemikus ristuvad.
Operatiivkulu
Lisaks puhtale inferentsikulule, ise hostimise operatiivkulu.
Algne seadistus:
- Õige inferentsserveri valimine (vLLM, TGI, SGLang).
- Konfigureerimine oma mudeli ja riistvara jaoks.
- GPU infrastruktuuri seadistamine (pilv või omanduses).
- Võrgustamine, turvalisus, vaadeldavus.
- Kvantiseerimine ja optimeerimine.
Hinda esialgne kohaletoimetamine kitsendatud töödekomplekti alusel, riistvara/pakkuja tarneaegade, turvalisuse ülevaate, võrdlusmatriitsi, saadavuse disaini ja meeskonna tegeliku läbilaskevõime põhjal. See artikkel ei väida, et inseneri-nädalate vahemik oleks üle kantav.
Pidev tegevus:
- Seire (latentsus, läbilaskevõime, vead, GPU kasutus).
- Võimsuse planeerimine.
- Uuendused (uued mudelite versioonid, inferentsserveri uuendused, turvaplaastrid).
- Vahejuhtumitele reageerimine (GPU rikked, OOM-kokkujooksmised, tarkvarabuugid).
- Skaleerimine (rohkem GPU-sid, kui koormus kasvab).
Märki tegelik vastutus platvormi, ML-i, turvalisuse ja on-kalli tööde vahel. Murdosa-FTE eeldus ei ole organisatsioonidevaheline.
Peidetud kulud:
- GPU hinnavolatiilsus.
- Pilve väljaminekukulud, kui hübriidne.
- Eriekspertiis (CUDA, kvantiseerimine, optimeerimine).
- Asenduse / rikete kulud omanduses olevale riistvarale.
Kasuta organisatsiooni täiskuluga tööjõumäärasid ja võimalikest alternatiividest tulenevat kuluhinda. Tokenihindade sääst ei ole netosääst, kuni operatiivne vastutus on kaasatud.
Inferentsserverid
Kui sa kavatsed ise hostida, on peamised valikud:
vLLM. Avatud lähtekoodiga mudelite serveerimise mootor pideva pakktöötluse ja laia, versioonist sõltuva mudelitoe. Pea selle turvajuhtmeid kohustuslikeks lugemiseks.
TGI (Text Generation Inference). Hugging Face’i serveerimisprojekt. Kontrolli praegust hooldusolekut ja mudelituge; ära tugine ainult selle artikli hetkeseisule.
SGLang. Serveerimis- ja programmeerimisstack, mida aktiivselt arendatakse. Võrdle vajalike mudelite, struktureeritud väljundi tee ja operatiivsete tööriistade jõudlust.
LMDeploy. Veel üks serveerimisserveerimiskandidaat, mille mudeli-, kvantiseerimis- ja riistvaratugi sõltub versioonist; testi seda samade vastuvõtutestide all.
llama.cpp / Ollama. Kandidaadid kohalikeks ja mõneks serveri töökoormuseks. Testi toetatud riistvara, paralleelsust, turvapiiri, operatiivseid kontrollmeedeid ja sobivust tootmiskeskkonnas; ükski neist ei garanteeri madalamat läbilaskevõimet ega tootmiskõlblikkust.
Hallatud pühendatud endpointid. Hugging Face ja teised pakkujad pakuvad hallatud lõpupunktide tooteid, mille mootorid, arvestus, isolatsioon ja operatiivne vastutusjaotus aja jooksul muutuvad. Kontrolli praegust teenust, ära eelda, et see töötab TGI-ga või kasutab üht kindlat arvestusmudelit.
Hallatud GPU või inferentsplatvormid. Need võivad vähendada mõningaid mahutavuse ja serveerimise töökoormusi, säilitades samas integratsiooni, turva, hindamise ja pakkujast sõltuvused. Võrdle praeguseid pakkumisi ja vastutusi; ära eelda fikseeritud hinnasuhet ise opereerimisega.
Vali ainult need projektid, mis toetavad täpselt sama mudelit, kiirendit, kvantiseerimist, API-lepingut ja turvakontrollmeedeid. Reprodutseeritav koormustest määrab valiku nende vahel.
Riistvara valikud
GPU küsimus:
Kiirendite põlvkonnad, mälumaht ja rendihinnad muutuvad kiiresti. Hanki praegused hinnapakkumised vajaliku regiooni ja sidusaja kohta.
Võrdle mälumahtu ja andmeedastuskiirust, toetatud arvutusvorme, ühendusliidest, tarkvarakompaktiivsust, kvooti, regionaalset saadavust, rikkekäitumist ja hinda. Spot- või preemptible-võimsus kuulub mudelisse ainult koos katkestuste käsitlemise ja mõõdetud taastumistee abil.
Kvantiseerimine
Kvantiseerimine on üks mahutavuse ja jõudluse valikuid. Selle kompromissid sõltuvad mudelist, vormingust, tuumast, riistvarast ja ülesandest:
FP16/BF16-klassi viidetäpsus. Sageli kasutatav võrdluslähtetasemeks toetatud mudelitele ja riistvarale; see ei ole automaatselt mudeli algne ega „täiskvaliteediline” vorming.
INT8 / FP8 (8-bitine). Võib vähendada kaalude mälu või parandada toetatud täitmisteid; kvaliteedi- ja kiirusmõjud varieeruvad.
INT4 (4-bitine). Võib vähendada kaalude mälu veelgi; mõõda kvaliteeti ja tuuma jõudlust konkreetse artefakti jaoks.
AWQ, GPTQ, GGUF. Erinevad kvantiseerimise vormingud erinevate kompromissidega.
Parameetrite arvu liitmine on vaid alumine hinnang; tööaja mälu sisaldab ka KV-vahemälu, aktiveerimisi, tööruume, fragmenteerumist ja koopiad. Kasuta serveerimismootori profiilerit ja koormustesti. Hinda väljundikvaliteeti tootmiskeskkonna ülesande peal, mitte ainult üldise võrdlustesti põhjal.
Läbilaskevõime ja võimsuse planeerimine
Peamine planeerimisküsimus on: mitu tokenit sekundis sul vaja on?
Mõõda esimese tokeni aega, tokenite vahelist latentsust, otsast lõpuni kuluvat aega, läbilaskevõimet, järjekorra ooteaega, veamäära ja mäluressursi reservi erinevate prompti/väljundi pikkuste ja samaaegsuse tasemete puhul.
Võimsuse planeerimiseks:
- Hinda samaaegsete päringute tipparvu.
- Hinda keskmist päringu pikkust.
- Arvuta vajalik tokenite koguarv sekundis.
- Lisa tippkoormuse, rikete ja juurutuse nõuetest tulenev reserv.
Usaldusväärsus ja varuvariant
Ise hostimine tähendab, et omad usaldusväärsust.
Tervisekontrollid. Pidev tervise seire. Taaskäivita ebatervislikud instantsid.
Ülekoormuskäitumine. Kasuta piiratud järjekordi, sisselaskekontrolli, tagasirõhku ja testitud degradeerimis- või tagasilükkamispoliitikat. Päringute lõpmatu järjekorda panek võib halvendada ülekoormust ja rikkuda latentsuse eesmärke.
API-de varuvariant. Hallatud varuvariant võib neelata osa väljakukkumisi või tippe, kuid ainult siis, kui mudeli kvaliteet, andmepoliitika, lepingud, kiiruspiirangud, olek ja failoveri käitumine on ühilduvad ja testitud. See lisab keerukust ja võib ebaõnnestuda samaaegselt.
Rikete taluvus. Planeeri varuvõimsus või alternatiivne tee lähtuvalt saadavuse eesmärgist ja testitud riketüüpidest; iga kiirendi võib ebaõnnestuda, kuid pühendatud seisvate seadmete kasutamine ei ole ainus lahendus.
Mitmeregiooniline. Globaalsete kasutajate jaoks replikeeri. Või kasuta kaugemate regioonide jaoks hallatud API-sid.
Uuendusstrateegia. Uued mudelite versioonid, serveri uuendused. Sinine-roheline juurutamine, et vältida tööseisakut.
Iga neist on inseneritöö, mille hallatud API-d sulle endasse imevad.
Kaks otsustust kirjeid koostada
Ära leiuta anonüümset tulemust. Koosta audititavad otsustuse kirjed praeguste tsitaatide ja benchmarki artefaktide põhjal.
Ise hostimise kandidaadi kirje:
- mudeli artefakt, revisjon, litsents, kvantiseerimine, serveerimise versioon, kiirendaja, piirkond ja juurutuse topoloogia,
- töökoormuse jaotus ja kvaliteedi hindamine praeguse hallatud lähtetaseme suhtes,
- koormustesti käsk, andmestik, latentsuse ja läbilaskevõime tulemused, küllastuspunkt ning taastumiskäitumine,
- kapitali või rendikulu, kasutustegur, inseneritöö, turvatöö ja oodatav häirekulu,
- tasuvuspunkti vahemik tundlikkusanalüüsiga ja väljumiskriteerium.
Hallatud kandidaadi kirje:
- pakkuja, mudeli/revisjoni käitumine, piirkond, hinnalehe kuupäev, kvoodid ja lepingutingimused,
- võrdväärne kvaliteet, latentsus, kiiruspiirang, tööseisakud ja andmepiiride tõendid,
- migratsiooni jõupingutused ja müüja kontsentratsioonirisk,
- tingimused, mis käivitavad uue ise hostimise hindamise.
Millal otsust üle vaadata
Otsus pole püsiv. Vaata perioodiliselt üle:
Mahu muutused. Märkimisväärselt üles: ise hostimine atraktiivsem. Märkimisväärselt alla: vähem atraktiivne.
Hinnamuutused. Suletud API-d odavnevad või kallinevad. Hallatud avatu odavneb. Riistvara odavneb.
Mudeli täiused. Uued avatud kaaludega või lähtekoodiga kandidaadid, mis vastavad töökoormuse sihtväärtustele, või uued suletud mudelid, mis muudavad kvaliteedivõrdluse. Kontrolli litsentse ja tegelikku kättesaadavust.
Käitusvõimekus. Meeskonna masinõppe- ja käituspädevus suurenes või vähenes.
Privaatsuse / vastavuse muutused. Uued nõuded, mis nõuavad ise hostimist.
Määra ülevaatuste sagedus lepingu, hinna, mudeli, töökoormuse, turvalisuse ja mahuvõimekuse muutlikkuse põhjal ning lisa sündmuspõhised käivitajad. Kvartaliülevaade on näide, mitte universaalne vaikeväärtus.
Tavalised vead
Mustrid, mida me näeme ise hostimise otsustes:
Viga 1: Kuluarvutus ilma operatiivkuluta. Tokenite või kiirendajate säästu teatatakse, kuid inseneritöö, valmisolekuteeninduse, turvalisuse ja juhtumite kulud jäetakse arvestamata.
Viga 2: liiga vara ise hostida. Inseneeria pingutuse kulutamine ise hostimisele, kui töökoormus on väike. Optimeerimine enneaegne.
Viga 3: Mittevõrdväärse kvaliteedi võrdlemine. Madalama hinnaga mudel valitakse ilma, et oleks näidatud, kas see vastab töökoormuse kvaliteedi-, turvalisus- ja latentsinõuetele.
Viga 4: Puudub rikekava. Ise hostitud infrastruktuur kukub maha ilma testitud degradeerumis-, järjekorda-, tagasilükkamis- või varutee võimalusteta. Haldatavad API-d võivad samuti ebaõnnestuda; võrdle mõlemat arhitektuuri sama saadavusobjektiivi vastu.
Viga 5: Eeldus, et esimene serveerimiskonfiguratsioon on tõhus. Tuginedes kinnitamata konfiguratsioonile, ei tehta toetatud kvantiseerimise, pakktöötluse, paralleelsuse, promptide pikkuste ja serveri seadete üle ühtegi reprodutseeritavat läbivaatust.
Viga 6: kvaliteeditriivi ignoreerimine. Ise hostitud mudel on degradeerunud vs praegune suletud. Kliendid märkavad; tiim ei märka.
Viga 7: mitte uuesti kaaluda. Korra ise hostides, ei vaata enam üle. Otsus võis olla õige kaks aastat tagasi ja vale nüüd.
Viga 8: Spot/preemptible ilma sujuva käsitlemiseta. Soodushinnaga võimsus modelleeritakse arvestamata katkestuste sagedust, taastumisaega, topelttööd või varutee kulu.
Otsustusekontrollnimekiri
Otsuse tahtlikuks tegemiseks:
- Kas kvaliteedilt samaväärsed hostitud ja ise hostitud kandidaadid on läbi testitud?
- Kas töökoormus on stabiilne ja ennustatav?
- Kas tiimil on või saab palkada MLOps/inferentsi eksperdi?
- Kas on olemas sobiva litsentsiga avatud lähtekoodiga kandidaat, mis vastab töökoormuse kvaliteedi- ja turvanõuetele?
- Kas latentsusnõuded lubavad ise hostimist?
- Kas oled teinud detailse kuluarvutuse, kaasa arvatud operatiivkulud?
- Kas sul on varuplaan?
- Kas vastavus-/privaatsusnõuded ei sunni ühele teele?
- Kas on dokumenteeritud läbivaatuste sagedus ja sündmuspõhised käivitajad oluliste mudeli, hinna, lepingu, töökoormuse, turvalisuse või mahuvõimekuse muutuste korral?
Ära piirdu lihtsalt märkeruutude loendamisega. Turvalisus, mudeli kvaliteet või operatiivne vastutus võivad olla vetopunktiks isegi siis, kui kõik finantsandmed näivad soodsad.
Hübriidmustrid
See ei ole valik ‘kas või mitte midagi’. Hübriidmustrite kandidaadid sisaldavad:
Ise hostitud massi jaoks; API-d raskete juhtumite jaoks. Klassifikatsioon, lihtne genereerimine ise hostitud; keerukas arutlus suletud API-del.
Ise hostitud stabiilse jaoks; API-d tippude jaoks. Ise hostitud käsitleb põhikoormust; API-d neelavad tipud.
Ise hostitud tundliku jaoks; API-d üldise jaoks. Tundlikud andmed läbi ise hostitud; üldised päringud läbi API-de.
Ise hostitud lahendus peenhäälestustele; API-d baasmudelitele. Käita kohandatud mudeleid ise ja kasuta valmismudeleid API-de kaudu.
Hübriidlahendus toob juurde keerukuse marsruutimises, andmepoliitikas, hindamises, jälgitavuses, lepingutes ja rikete käsitluses. Kasuta seda ainult siis, kui testid näitavad, et jaotus parandab konkreetset eesmärki.
Otsusta ajakohaste tõendite põhjal
Ise hostimine on elujõuline lahendus, kui toetatud mudel vastab töökoormuse kvaliteedieesmärgile ja organisatsioon suudab teenindusetsükli üle võtta.
Tasuvuspunkt ei ole universaalne kuuene kulu. See muutub sõltuvalt mudeli kvaliteedist, nõudluse kujust, kasutustasemest, kiirendi- ja pakkujahindadest, saadavusest, andmepiirangute nõuetest ja personali kuludest.
Ise hostimise otsust toetavad tõendid peaksid näitama:
- On teinud matemaatika ausalt, kaasa arvatud operatiivkulud.
- Neil on MLOps-võimekus või nad suudavad selle luua.
- Jooksevad piisavas mastaabis, et õigustada investeeringut.
- Nende töökoormus on stabiilne.
- Ei vaja eesliini-ainult võimekusi.
- Planeerivad usaldusväärsust, seiret ja uuendusi.
Hallatava teenuse otsust toetavad tõendid võivad hõlmata:
- Madalam mastaap.
- Tipuvahelised töökoormused.
- Vaja kiiret iteratsiooni.
- Väikesed tiimid ilma operatiivvõimekuseta.
- Vaja eesliini-suletud võimekusi.
Õige vastus sõltub töökoormusest. Tee kvaliteedi, koormuse, rikete, turvalisuse ja kulude võrdlused ning hinda operatiivvõimekust. Eelista võimalikult madala kogukuluvarianti, mis rahuldab kohustuslikke nõudeid; see võib olla hallatud, ise hostitud või hübriidne.
Kui valitakse ise hostimine, kirjuta üles mõõdetud kasu, eeldused, vastutaja, väljumiskriteeriumid ja järgmise läbivaatuse käivitaja. Tee sama ka hallatud lahenduse puhul; ükski tee ei ole õige ilma ajakohaste tõenditeta.
