Zgradite knjigo zmogljivosti št. AI API, preden sprejmete nove najemnike

Ne čakajte na promet v živo, da ugotovite, da nove stranke ni mogoče postreči. Dušilci izvajalnega časa odgovarjajo na ozko vprašanje: naj se ta zahteva zažene takoj? Ne odgovarjajo na komercialno vprašanje, ki je pomembno pred vkrcanjem: ali lahko ta ponudnik računa, projekt, delovni prostor, regija, družina modelov in ovojnica porabe podpira najemnika, ki ga boste prodali?

Knjiga zmogljivosti AI API daje na to vprašanje konkreten odgovor. Pretvori zgornje meje v notranjo ponudbo, odšteje rezervacije, uporabi višino prostora in blokira ustvarjanje načrta ali aktivacijo najemnika, ko obljubljena delovna obremenitev nima verodostojne podporne zmogljivosti.

Kaj nadzoruje Capacity Ledger

Knjiga zmogljivosti ni nadomestilo za omejevanje hitrosti izvajanja, zaračunavanje ali odziv na incidente. Zadeva se prej v življenjskem ciklu: prodaja, načrtovanje načrta, zagotavljanje najemnikov, dodelitev profila modela in nadgradnje.

Težava z bralnikom je specifična: AI API preprodajalci in skupine SaaS lahko prodajo dostop hitreje, kot lahko ponudniki na višji stopnji odobrijo, izpostavijo ali vzdržujejo kvoto. Stranka lahko kupi načrt, ki obljublja model, regijo, stopnjo zakasnitve ali mesečni obseg, preden kdor koli preveri, ali obstaja ustrezen nabor navzgor. Rezultat je predvidljiv: napake 429, blokirane nadgradnje, nujne zahteve za kvoto, vsiljeni nadomestni modeli in nerodna komunikacija s strankami.

Knjiga mora odgovarjati na vprašanja, kot so:

• Ali lahko aktiviramo tega najemnika v tej družini modelov, ne da bi porabili rezervirano zmogljivost podjetja?
• Ali lahko preprodajalec ustvari načrt, ki obljublja 20 milijonov žetonov na mesec v določeni regiji?
• Ali lahko ta stranka nadgradi z razpočnega dostopa na dodeljeno zmogljivost?
• Katera skupina ponudnikov podpira obljubo in kdaj je treba to predpostavko pregledati?
• Kaj se zgodi, če omejitev ponudnika nedavno ni bila usklajena?

To je še posebej pomembno za AI API platformo preprodajalcev, kjer lahko spodnji portali prodajo paketni dostop številnim strankam, medtem ko navzgornja kvota ostaja koncentrirana v majhnem številu računov ponudnika.

Dejstva, ki jih je treba upoštevati

Naslednje so dejanske omejitve iz dokumentacije ponudnika in bi morale oblikovati zasnovo.

• OpenAI dokumentira API omejitve stopnje na ravni organizacije in projekta. Omejitve se razlikujejo glede na model, lahko si jih delijo družine modelov in jih je mogoče pregledati prek glav odgovorov.
• OpenAI dokumentira nadzor mesečne porabe ločeno od omejitev stopnje. Vsiljene omejitve trde porabe lahko vrnejo 429 napak, uveljavitev pa morda ne bo takojšnja.
• OpenAI Skrbniški API-ji podpirajo organizacijske poteke dela, kot so administracija projektov, API upravljanje ključev, omejitve porabe, opozorila, revizijski dnevniki in operacije omejitve stopnje.
• Anthropic dokumentira skrbniške API omejitve hitrosti API za poizvedovanje po konfigurirani organizaciji in omejitvah delovnega prostora.
• Anthropic API odgovori vključujejo glave omejitve hitrosti, ki prikazujejo vsiljeno omejitev, trenutno uporabo in čas ponastavitve.
Kvota
• Azure OpenAI je dodeljena glede na naročnino, regijo, model in vrsto uvedbe v enotah žetonov na minuto. Razmestitve porabljajo iz razpoložljivega nabora kvot.
• Dokumentacija Azure priporoča vlogo Cognitive Services Usages Reader kot minimalni dostop za ogled razpoložljive kvote v naročnini.
• Google Kvote v oblaku omejujejo, koliko virov lahko uporabi projekt, pogosto jih je mogoče prilagoditi in se spremljajo prek kvot v oblaku. Sistemske omejitve so določene.

Ta dejstva nakazujejo oblikovno zahtevo: glavna knjiga ne more modelirati zmogljivosti kot eno samo globalno število. Ohraniti mora razsežnosti, specifične za ponudnika, hkrati pa izpostavljati normalizirano odločitev o sprejemu vašemu izdelku in partnerju API.

Priporočeni model Ledger

Modelirajte zmogljivost navzgor kot prvorazredni objekt nadzorne ravnine. Uporaben zapis o naboru zmogljivosti običajno potrebuje ta polja:

• ponudnik: openai, anthropic, azure_openai, gemini ali drug navzgor.
• provider_account_id: organizacija, naročnina, račun za obračunavanje ali najemnik, ki ima v lasti kvoto.
• scope: organizacija, projekt, delovni prostor, projekt v oblaku, regija, uvedba ali račun storitve.
• regija: potrebna za Azure in delovne obremenitve, ki so občutljive na prebivališče; izbirno ali globalno za ponudnike, kjer omejitve niso regionalne.
• model_family: normalizirana notranja družina, ne le natančen niz modela ponudnika.
• deployment_type: standardni, omogočeni, paketni, prednostni, v realnem času ali drug razred zmogljivosti.
• rpm_limit: zahtev na minuto, kjer je na voljo.
• tpm_limit: žetonov na minuto ali enakovredna zmogljivost žetonov.
• batch_queue_limit: opravila v čakalni vrsti, žetoni v čakalni vrsti, velikost datoteke ali asinhronska zmogljivost, specifična za ponudnika.
• monthly_spend_cap: trda ali konfigurirana proračunska meja navzgor.
• sellable_fraction: odstotek izmerjene zmogljivosti, dovoljen za komercialne obveznosti.
• effective_from in effective_until: tako da začasna povečanja kvot ne postanejo trajne predpostavke.
• vir: API, dokaz konzole, odobritev upravitelja računa, ročna preglasitev ali sklepanje iz glav.
• last_reconciled_at: za opozorila o zastarelih podatkih in prehode za odobritev.

Nato dodajte zapise rezervacij, ki porabljajo iz teh skupin:

• tenant_id ali reseller_customer_id: stranka ali najemnik na nižji stopnji.
• reservation_class: dodeljeno, razpočno, interno, paketno, free_trial ali v sili.
• model_profile_id: sveženj modelov in nadomestnih različic, usmerjen v izdelek.
• required_rpm in required_tpm: ocena vstopa.
• monthly_volume_commitment: pričakovana mesečna količina žetonov ali poraba.
• region_policy: zahtevano, prednostno ali neomejeno.
• stanje: v teku, aktivno, poslabšano, poteklo, zavrnjeno ali awaiting_provider_quota.
• approved_by in approval_reason: za komercialne izjeme.
• review_at: ko je treba znova preveriti zmogljivost.

Bistvo ni v popolni napovedi vsakega žetona. Bistvo je, da so odločitve o prodaji in uvajanju dovolj jasne, da jih je mogoče pregledati, izpodbijati in posodobiti, preden so stranke odvisne od njih.

Nadzor sprejema se razlikuje od dušenja izvajalnega časa

Dušenje izvajalnega časa je zaščita na ravni zahteve. Oceni ali izmeri pritisk za živo zahtevo in se odloči, ali bo odposlal, odložil, zmanjšal ali zavrnil. To je potrebno, vendar je reaktivno.

Nadzor sprejema je načrtovanje na strani ponudbe. Odloča, ali je dovoljen obstoj najemnika, načrta preprodajalca, profila modela ali nadgradnje. Močna izvedba povezuje preverjanje zmogljivosti z partnerjem API avtomatizacijo, preverjanjem načrta, vključitvijo strank in skrbniškimi odobritvami.

Na primer, izdelava načrta ne bi smela prestati preverjanja, če načrt obljublja:

• modelna družina, ki nima preslikane skupine ponudnikov;
• regija, kjer ni kvote;
• stopnja zakasnitve, podprta le z zmogljivostjo najboljšega napora;
• dodeljena količina žetona je večja od prodajne zmogljivosti;
• paketna raven, kjer omejitve čakalne vrste niso znane;
• obveznost porabe, ki bi račun ponudnika potisnila blizu trde omejitve.

To ni dušenje, obrnjeno k strankam. To je celovitost izdelka. Če vaš prehod dovoljuje preprodajalcu, da oglašuje načrt, ki ga ne more podpreti kvota ponudnika, bo izvajalna koda podedovala obljubo, ki je ne more izpolniti.

Izračun prodajne zmogljivosti z višino

Ne prodajajte 100 odstotkov prodajne številke. Omejitve ponudnikov se lahko spreminjajo, modelne družine si lahko delijo bazene, ponovni poskusi porabijo dodatno kvoto in promet strank ne prihaja enakomerno. Praktična politika izpostavlja le delček izmerjene zmogljivosti kot prodajno.

Za začetek je dovolj preprosta formula:

sellable_tpm = provider_tpm_limit * sellable_fraction
available_tpm = sellable_tpm - active_reserved_tpm - pending_reserved_tpm

Če skupina ponudnikov izpostavi 1.000.000 TPM in vaš pravilnik proda 70 odstotkov, je za zaveze na voljo le 700.000 TPM. Če aktivni najemniki rezervirajo 500.000 TPM in odobritve v teku rezervirajo 100.000 TPM, je preostali razpoložljivi TPM 100.000.

Prodajljiva frakcija se mora razlikovati glede na vrsto skupine:

• Stabilno zbiranje velikega obsega: 70-80 odstotkov je morda razumnih, ko je uskladitev zrela.
• Nov račun ponudnika: 50-60 odstotkov je varnejših, dokler dejanski promet ne potrdi obnašanja.
• Skupni bazen družine modelov: zmanjšajte prodajno zmogljivost, ker lahko nepovezani vzdevki modelov tekmujejo.
• Ročni ali zastareli dokazi: zmanjšajte prodajno zmogljivost ali blokirajte nove zaveze.
• Nadomestni bazen v sili: ne prodajajte ga kot običajno zmogljivost.

Omejitve porabe potrebujejo podobno obravnavo. Omejitev trde porabe ponudnika je varovalo proračuna in ne načrt zmogljivosti izdelka. Če je trda omejitev navzgor 50.000 USD na mesec, mora prehod rezervirati nižji notranji prag za načrtovano uporabo in opozoriti, preden lahko trda omejitev prekine produkcijski promet.

Uporaba razredov rezervacij namesto rezervacij na zahtevo

Ne poskušajte rezervirati zmogljivosti ponudnika za vsako možno zahtevo med sprejemom. To sodi v dušenje med izvajanjem. Sprejem zmogljivosti deluje bolje z rezervacijskimi razredi.

Zavezane stranke

Zavezane stranke dobijo izrecne rezervacije zmogljivosti. Njihovi načrti bi morali določati zahtevane družine modelov, regije, raven storitev, predpostavke glede stopnje žetonov in datume pregleda. Nedejavne rezervacije zmanjšajo izkoriščenost, vendar naredijo obljube verodostojne.

Burstabilne stranke

Burstable stranke črpajo iz skupnega bazena. Uporabijo lahko zmogljivost, ko je na voljo, vendar ne smejo blokirati predanega vkrcanja. Jezik njihovega načrta, stanje API in obnašanje pri poslabšanju morajo biti jasni.

Notranje delovne obremenitve

Notranja ocenjevanja, podporna orodja, analitična opravila in administrativne avtomatizacije bi morali imeti lasten razred rezervacij. V nasprotnem primeru lahko notranji promet tiho porabi zmogljivost, za katero prodaja meni, da je na voljo.

Paketna opravila

Paketna zmogljivost potrebuje ločeno modeliranje, ker jo lahko urejajo velikost čakalne vrste, število opravil, žetoni v čakalni vrsti, omejitve datotek ali zaveze o obratovanju in ne samo RPM in TPM.

Brezplačni preizkusi

Brezplačne preskusne različice morajo uporabljati namenoma omejena področja. Brezplačna preskusna različica ne bi smela porabiti omejene regionalne ali prednostne zmogljivosti, razen če je to del namerne odločitve o vstopu na trg.

Uskladite zmogljivosti ponudnika na urniku

Knjiga je uporabna le, če se napaja z usklajevanjem. Nadzorne ravni ponudnika se spreminjajo zunaj vašega prehoda: skrbniki prilagodijo projekte, delovne prostore, uvedbe, omejitve porabe, ključe, regije in razpoložljivost modela. Po znanih skrbniških spremembah ustvarite načrtovane umike in preverjanja na podlagi dogodkov.

Praktična usklajevalna zanka izgleda takole:

1. Pridobi omejitve, vidne ponudniku, kjer obstajajo API-ji.
2. Normalizirajte dimenzije v zapise o zmogljivosti.
3. Primerjajte nove vrednosti s prejšnjim posnetkom glavne knjige.
4. Označite rezervacije kot ogrožene, če se zmogljivost zmanjša ali izgine.
5. Začasna povečanja potečejo, ko se konča njihovo dokazno okno.
6. Sproži opozorila, ko zastarela združenja še vedno podpirajo aktivne obveznosti.
7. Vsako spremembo zabeležite v revizijski dnevnik.

Nekateri dokazi o zmogljivosti bodo nepopolni. Ponudnik lahko izpostavi omejitve prek API, konzole kvote v oblaku, glav odgovorov ali delovnega toka zastopnika računa. Podprite vse to kot različne vrste dokazov. Glavna knjiga mora izkazovati zaupanje in svežino, ne pa se pretvarjati, da vsak ponudnik oddaja iste podatke nadzorne ravnine.

To se prekriva s širšim AI API upravljanjem kvot, vendar ima knjiga zmogljivosti ožji namen: odločanje o tem, kaj je mogoče varno prodati ali aktivirati, preden pride promet.

Vstopni pregledi za vključitev v izdelek

Dostop do zmogljivosti bi moral biti del delovnih tokov, kjer se ustvarjajo obljube. Najbolj uporabna preverjanja so običajno ta.

Preverjanje ustvarjanja načrta

Ko skrbnik ustvari načrt preprodajalca, preveri oglaševane družine modelov, ravni storitev, regionalne zaveze, mesečno količino, predpostavke o izbruhu in nadomestni pravilnik. Če nobena skupina ponudnikov ne more podpreti načrta s prostorom, mora načrt ostati osnutek ali zahtevati preglasitev.

Preverjanje aktivacije najemnika

Ko je stranka omogočena, rezervirajte ustrezni razred zmogljivosti. Aktivacijski odgovor mora izpostaviti stanje, kot je aktivno, čaka na odobritev kvote, znižano na nadomestno ali blokirano.

Preverjanje nadgradnje

Preden povečate najemnikov načrt, zaženite isti izračun vstopnine glede na ciljno rezervacijo. Če je zmogljivost nezadostna, mora nadgradnja postati čakajoča zahteva, povezana s potekom dela kvote ponudnika.

Preverjanje profila modela

Če se vzdevki modela ali profili spremenijo, ponovno izračunajte rezervacije. Neškodljiva promocija vzdevka lahko premakne najemnike iz enega ponudnika v drugega in prekine model ponudbe.

Preverjanje regionalne politike

Za Azure in delovne obremenitve, ki so občutljive na prebivališče, izrecno potrdite regijo. Enakovredni modeli v drugi regiji ne izpolnjujejo obljube stalnega prebivališča, razen če pravilnik o strankah dovoljuje nadomestno možnost.

Podrobnosti o izvedbi: Oblika odločitve o sprejemu

Rezultat sprejema naj bo strojno berljiv. Partnerju API, portalu preprodajalcev ali notranjemu skrbniškemu uporabniškemu vmesniku ne bi bilo treba razčleniti človeških zapiskov.

{
  "decision": "approved",
  "tenant_id": "tenant_123",
  "model_profile_id": "profile_support_fast",
  "reservation_class": "committed",
  "backing_pool_id": "pool_azure_eastus_gpt4_standard",
  "required_tpm": 120000,
  "required_rpm": 600,
  "sellable_tpm_before": 700000,
  "reserved_tpm_before": 520000,
  "available_tpm_after": 60000,
  "headroom_policy": "standard_70_percent",
  "evidence_freshness": "fresh",
  "review_at": "2026-11-01T00:00:00Z"
}

Za zavrnitev vrnite razlog, na katerega lahko deluje potek dela izdelka:

{
  "decision": "blocked",
  "reason_code": "insufficient_regional_tpm",
  "required_region": "eastus",
  "required_tpm": 300000,
  "available_tpm": 90000,
  "recommended_action": "request_provider_quota_increase",
  "fallback_options": [
    "standard_global_pool",
    "lower_volume_plan",
    "pending_activation"
  ]
}

Izogibajte se vračanju le »brez zmogljivosti«. Klicatelj mora vedeti, ali je težava regionalna kvota, razpoložljivost modela, zastareli dokazi, izpostavljenost omejitvi porabe, manjkajoča uvedba ali navzkrižje pravilnika.

Revizija komercialne odločitve

Vsako odločitev o zmogljivosti je treba preveriti. Zapis:

• ki je zahteval najemnika, načrt ali nadgradnjo;
• kdo je odobril ali razveljavil odločitev;
• katera skupina ponudnikov je podprla obljubo;
• kateri pravilnik o višini prostora je bil uporabljen;
• kateri vir dokazov je bil uporabljen;
• ko rezervacija poteče ali jo je treba pregledati;
• kaj se spremeni, če je bil najemnik degradiran ali premaknjen v drugo skupino.

To je pomembno med incidenti. Če skupina izčrpa kvoto, mora ekipa vedeti, ali je težava nastala zaradi nepričakovanega prometa, zastarelih dokazov ponudnika, preglasitve, selitve profila modela ali prodajnega načrta, ki ne bi smel biti aktiviran.

Kompromisi

Knjiga zmogljivosti doda operativne stroške. Prav tako lahko zavrne prihodek, dokler ni potrjena kvota navzgor. To je frustrirajoče, vendar je bolje kot prodajati načrte, ki ne uspejo pod obremenitvijo.

Trde rezervacije izboljšajo predvidljivost za najemnike z visoko vrednostjo, vendar zmanjšajo izkoriščenost, ko so stranke nedejavne. Mehke rezervacije izboljšujejo izkoriščenost, vendar zahtevajo močnejše kontrole izvajalnega časa in jasnejša pravila degradacije, namenjena strankam.

Regionalno modeliranje je potrebno za Azure in delovne obremenitve, ki so občutljive na prebivališče, vendar otežuje nadomestno usmerjanje. Model, ki je na voljo v eni regiji, morda ne bo zadovoljil najemnika, katerega podatki morajo ostati v drugi regiji.

Ročnim dokazom se včasih ni mogoče izogniti. Tveganje ni v tem, da obstajajo ročni dokazi; tveganje je, da jo obravnavamo kot svežo API-izpeljano resnico. Uporabite opozorila o zastarelih podatkih, datume veljavnosti in zahteve za odobritev.

Omejitve trde porabe ponudnika so koristne varovalke, vendar lahko prekinejo produkcijski promet s 429-ji. Prehod bi moral interno opozoriti in rezervirati, preden zgornje trde omejitve postanejo mehanizem uveljavljanja.

Kaj je priporočilo in kaj napoved?

Priporočila: modelirajte zmogljivost kot objekte glavne knjige, uskladite omejitve ponudnika, uporabite prostor za višino, rezervirajte glede na razred najemnika, povežite preverjanja sprejema z načrtom in potekom dela najemnika ter revidirajte vsako odločitev.

Napovedi: sprejem zmogljivosti bo postal pomembnejši, ko bodo portali preprodajalcev, ponudbe agencij in vkrcanje najemnikov SaaS postali bolj avtomatizirani. Stranke bodo pričakovale takojšnjo aktivacijo, medtem ko bodo odobritve ponudnikovih kvot in regionalne zmogljivosti ostale neenakomerne. Ekipe, ki izrecno navedejo dobavo v nadzorni ravni, bodo imele manj stopenj v sili kot ekipe, ki se zanašajo samo na dušilke med izvajanjem.

Dejstva: zgornje izjave, specifične za ponudnika, je treba obravnavati kot dejstva iz trenutne javne dokumentacije, vendar se API-ji ponudnika in semantika kvote lahko spremenijo. Preglejte kodo usklajevanja in povezave do dokumentacije.

Uporabni sklep

Začnite z enim potekom dela z visoko vrednostjo: blokirajte aktivacijo odobrenega najemnika, razen če nova skupina ponudnikov lahko podpira zahtevano družino modelov, regijo, stopnjo in ovojnico porabe po višini. Nato dodajte preverjanje načrta, preverjanje nadgradenj, opozorila o zastarelih dokazih in polja statusa partnerja API.

Najmanjša uporabna različica je majhna: biljardna miza z zmogljivostjo, rezervacijska miza, usklajevalni posel, politika višine in odločitev o sprejemu API. To je dovolj za prenos zmogljivosti iz plemenskega znanja v ravnino nadzora izdelka, kjer lahko prodaja, podpora, operacije in portali preprodajalcev vidijo, ali je obljuba dejansko podprta z ponudbo.

Sorodno branje

• oblikovanje omejitve hitrosti izvajanja za promet umetne inteligence v živo API