Kako oblikovati račune storitev LLM za produkcijske delovne obremenitve

Proizvodne delovne obremenitve LLM se ne smejo preverjati kot ljudje. Opravilo CI, zaledna storitev, izvajalec agentov, paketni procesor ali prehod, usmerjen v partnerja, potrebuje lastno nečloveško identiteto z jasnim lastnikom, ozkim obsegom, proračunom, revizijsko sledjo in potjo zaustavitve. Brez tega modela lahko en ključ, ki je ušel, predstavlja preveč sistemov, izključitev ne odstrani dostopa in poročila o uporabi ne morejo pojasniti, katera delovna obremenitev je povzročila strošek ali tveganje.

Ta vodnik daje inženirskim ekipam in skupinam platforme praktično zasnovo za upravljanje računa storitve LLM prek API-jev ponudnika in notranjih prehodov. Ločuje preverjena dejstva ponudnika od priporočil za implementacijo in kliče napovedi, kjer se bo operativni model verjetno razvijal.

Kaj je račun storitve LLM?

Dejstvo: Storitveni računi so nečloveške identitete, ki jih uporabljajo aplikacije in delovne obremenitve, ne pa posamezni uporabniki. OpenAI API projekti podpirajo storitvene račune v obsegu projekta in API ključe. Anthropic opisuje storitvene račune kot poimenovane nečloveške identitete znotraj organizacije. Google Cloud IAM opisuje storitvene račune kot nečloveške uporabnike za aplikacije in delovne obremenitve.

Za sisteme LLM mora storitveni račun predstavljati mejo delovne obremenitve: ena zaledna storitev, ena družina poteka dela CI, eno izvajalno okolje agenta, en paketni cevovod ali ena partnerska API stopnja integracije. Ne sme predstavljati osebe, celotnega podjetja ali vsake aplikacije v okolju.

Uporaben zapis storitvenega računa odgovarja na pet vprašanj:

• Katera aplikacija ali potek dela ima to identiteto?
• V katerem okolju se lahko izvaja?
• Katera ekipa je odgovorna za stroške, dostop in incidente?
• Kateri modeli, končne točke, orodja, pravilniki o podatkih in regije so dovoljeni?
• Kako se poverilnica rotira, prekliče ali nadomesti z zvezo?

Kdaj ustvariti račun storitve

Ustvarite račun storitve, ko je klicatelj operativna programska oprema in ne človek. Pogosti primeri vključujejo opravila CI/CD, ki izvajajo vrednotenja, produkcijske API storitve, delavce za obdelavo dokumentov, kopilote za podporo strankam, čakalne vrste avtonomnih agentov, načrtovana opravila obogatitve in interne platforme za razvijalce, ki posredujejo dostop do LLM za številne ekipe.

Ne ustvarjajte novega storitvenega računa za vsakega razvijalca, vsak lokalni poskus ali vsak poziv. Človeško raziskovanje se skriva za uporabniško identiteto in kratkotrajnimi razvojnimi poverilnicami. Dodeljevanje na ravni poziva in funkcij je mogoče zajeti kot metapodatke zahteve pod identiteto delovne obremenitve.

Preprosto pravilo odločanja deluje dobro:

• Če klicatelj lahko deluje nenadzorovano, uporabite račun storitve.
• Če klicatelj služi produkcijskemu prometu, uporabite storitveni račun glede na delovno obremenitev in okolje.
• Če klicatelj deluje v imenu stranke ali partnerja, ločite identiteto delovne obremenitve od delegirane identitete najemnika.
• Če je klicatelj človek, ki uporablja konzolo ali prenosni računalnik, tega ne skrivajte za računom produkcijske storitve.

Začnite z inventarjem identitete

Migracija se mora začeti z inventarjem, ne z menjavo ključev. Ekipe pogosto odkrijejo, da en ključ ponudnika uporabljajo produkcijske storitve, uprizoritvena opravila, lokalni skripti, cevovodi eval in opuščene integracije. Če najprej zavrtite ta ključ, ustvarite tveganje, ne da bi izboljšali lastništvo.

Izdelajte inventar s temi kategorijami:

• Ponudnik v lasti ljudi API ključi.
• Računi storitve delovne obremenitve.
• Identitete CI/CD.
• Notranji ključi, ki jih izda prehod.
• Ključi, delegirani od partnerja ali stranke.
• Poverilnice za razbitje stekla v sili.
• Neznani ključi, ki še vedno povzročajo uporabo.

Za vsako poverilnico, ponudnika zapisa, projekt ali delovni prostor, lastnika ključa, porabniško aplikacijo, okolje uvajanja, skrivno lokacijo, dovoljene modele, lastnika porabe, zadnji viden časovni žig in tveganje preklica. Ta inventar postane vir resnice za LLM API upravljanje ključev, vendar bi morali storitvene račune modelirati kot prvorazredne identitete delovne obremenitve in ne le še eno oznako ključa.

Uporaba enega storitvenega računa na mejo delovne obremenitve

Glavna izbira oblikovanja je razdrobljenost. Premalo storitvenih računov ustvari skupni radij eksplozije. Preveč povzroča hrup med delovanjem. Prava enota je najmanjša meja delovne obremenitve, ki ima ločeno lastništvo, dovoljenja, stroškovni profil ali potrebe po odzivu na incident.

Uporabite ločene storitvene račune za:

• Proizvodna in neprodukcijska okolja.
• Različne aplikacije v lasti različnih ekip.
• Storitve, namenjene strankam, v primerjavi z internimi zaposlitvami.
• Interaktivne poti zahtev v primerjavi z asinhronimi paketnimi procesorji.
• Izvajalni časi agentov, ki lahko kličejo orodja ali izvajajo zanke.
• Partner API površine, ki izpostavljajo pooblaščeni dostop.

Praktičen vzorec poimenovanja je:

llm-sa-{app}-{env}-{team}-{purpose}

Primeri:

llm-sa-supportbot-prod-cx-chat
llm-sa-contracts-stg-legal-extract
llm-sa-evals-ci-platform-regression
llm-sa-agentrunner-prod-eng-tools

V imenu računa ne kodirajte skrivnosti, imen strank, osebnih imen ali začasnih številk vozovnic. Namesto tega spremenljive podrobnosti vnesite v oznake ali metapodatke.

Preslikava računov ponudnika v model identitete prehoda

Dejstvo: Zmogljivosti ponudnika se razlikujejo. OpenAI podpira storitvene račune znotraj API projektov, storitveni računi projekta pa so edinstveni za projekt, kjer so ustvarjeni. Anthropic delovni prostori lahko vsebujejo člane, storitvene račune, API ključe in omejitve virov. Anthropic federacija identitete delovne obremenitve omogoča delovnim obremenitvam uporabo podpisanih žetonov identitete namesto statičnih Anthropic poverilnic, pri čemer so omejitve dodeljevanja in hitrosti povezane z delovnim prostorom, ko so konfigurirane.

Priporočilo: Ohranite model storitvenega računa na ravni prehoda, tudi če obstajajo izvorni storitveni računi ponudnika. Identiteta prehoda bi morala biti stabilen notranji objekt, na katerega so povezani politika, poročanje, proračuni in revizijski dokazi. Poverilnice ponudnika so nato podrobnosti o izvedbi, preslikane pod njimi.

Na primer:

internal_service_account:
  id: sa_01h_supportbot_prod
  name: llm-sa-supportbot-prod-cx-chat
  owner_team: customer_experience
  environment: production
  app: supportbot
  allowed_models:
    - provider: openai
      model_family: gpt-4.1
    - provider: anthropic
      model_family: claude-sonnet
  data_policy: no_training_required
  monthly_budget_usd: 2500
  provider_bindings:
    openai_project: proj_supportbot_prod
    anthropic_workspace: ws_supportbot_prod

Ta preslikava je pomembna v večmodelnem API prehodu umetne inteligence, ker navzgornji ponudniki izpostavljajo različne strukture računov, polja za obračunavanje, dovoljenja modela in možnosti združevanja. Ena sama notranja plast identitete omogoča ekipam, da uveljavijo eno pogodbo o pravilniku, hkrati pa ohranijo kontekst, specifičen za ponudnika, za odpravljanje težav.

Ozko dovoljenja obsega

Storitveni račun bi moral biti opredeljen glede na to, kar potrebuje delovna obremenitev, ne pa glede na to, kaj ključ ponudnika dovoljuje. Določite vsaj obseg v teh dimenzijah:

• Meja ponudnika: kateri ponudniki in projekti ali delovni prostori ponudnika se lahko uporabljajo.
• Meja modela: dovoljene družine modelov, različice, modeli za predogled in nadomestni modeli.
• Meja končne točke: klepet, odgovori, vdelave, paketi, datoteke, fina nastavitev, pomočniki, orodja ali skrbniški API-ji.
• Meja okolja: razvoj, uprizarjanje, produkcija, peskovnik ali partner.
• Meja podatkov: politika hrambe, regija, razred občutljivih podatkov in dovoljene funkcije za spremljanje stanja.
• Meja proračuna: mehka opozorila, stroge omejitve, omejitve na minuto in mesečne omejitve.
• Meja omrežja: sprejeta izvorna omrežja, identitete delovne obremenitve ali platforme za uvajanje.

Skrbniška API dovoljenja skoraj nikoli ne bi smela biti na voljo računom izvajalnih storitev. Ločite avtomatizacijo zagotavljanja od delovnih obremenitev sklepanja. Zaledna storitev, ki pošilja pozive, prav tako ne bi smela imeti možnosti ustvarjanja novih ključev ponudnika, spreminjanja proračunov ali odobritve dostopa do modela.

Daj prednost federaciji kot statičnim ključem, kjer je to praktično

Dejstvo: Anthropic dokumentira zvezo identitete delovne obremenitve kot način, da delovna obremenitev uporablja podpisane žetone identitete namesto statičnih Anthropic poverilnic. Google Cloud opozarja, da ključi računov storitev, ki jih upravljajo uporabniki, predstavljajo varnostno tveganje, če niso skrbno upravljani, in priporoča varnejše alternative, kjer je to mogoče. OWASP priporoča centralizirano skrivno shranjevanje, nadzor skrivnih zahtev in uporabe, rotacijo, preklic in potek, kjer je to mogoče.

Priporočilo: Dajte prednost zvezi identitete delovne obremenitve ali kratkotrajni izmenjavi žetonov za storitve, ki gostujejo v oblaku, in sisteme CI/CD, kjer obstaja podpora ponudnika. Uporabite statične ključe API samo, če povezava ni na voljo, je ne podpira pot ponudnika, ki jo potrebujete, ali je operativno neupravičena za delovno obremenitev z nizkim tveganjem.

Zvezni tok običajno izgleda takole:

1. Delovna obremenitev poteka v oblaku, CI ali principalu ponudnika identitete.
2. Delovna obremenitev pridobi podpisan žeton identitete od tega ponudnika identitete navzgor.
3. Ponudnik LLM ali notranji prehod potrdi izdajatelja, ciljno skupino, zadevo in trditve.
4. Prehod preslika žeton v račun notranje storitve.
5. Prehod sproži kratkotrajno sejo ali neposredno avtorizira zahtevo LLM.

Potrdi več kot izdajatelja. Preverite ciljno skupino, zadevo, repozitorij ali pot delovne obremenitve, okolje, vejo ali trditve o uvajanju, kjer so na voljo, in življenjsko dobo žetona. Zveza preusmeri tveganje s statičnega uhajanja skrivnosti na konfiguracijo ponudnika identitete. Šibke trditve, politike širokega zaupanja ali permisivna okolja CI lahko še vedno omogočijo nenameren dostop.

Zahtevaj metapodatke o dodelitvi pri vsaki zahtevi

Storitveni računi določajo delovno obremenitev, vendar ne smejo biti edino polje dodeljevanja. Produkcijske zahteve LLM potrebujejo dovolj metapodatkov za hiter odgovor na operativna vprašanja.

Zahtevaj ta polja na prehodu:

• service_account_id
• app
• environment
• owner_team
• deployment_id ali izdaja različice
• request_purpose, kot je klepet, ekstrakcija, klasifikacija, vrednotenje ali agent_tool_use
• tenant_id ali identifikator stranke, če je na voljo
• workflow_id ali identifikator opravila za asinhrono delo

Ta polja podpirajo LLM API dodeljevanje stroškov, odziv na incidente, odločitve o omejitvi stopnje in usklajevanje računov ponudnika. Preprečujejo tudi običajni način napake, kjer je vsaka zahteva ključa v skupni rabi označena samo kot »backend«.

Priložite proračune in opozorila identitetam delovne obremenitve

Storitveni računi pogosto delujejo brez nadzora. Zaradi tega je nadzor nad stroški pomembnejši, ne manj pomemben. Uporabnik lahko opazi bežno sejo klepeta. Načrtovani posrednik ali ponovni poskus paketnega opravila lahko čez noč porabi proračun.

Nastavite proračune na več ravneh:

• Proračun projekta ponudnika ali delovnega prostora, kjer je podprt.
• Mesečni proračun na ravni prehoda na storitveni račun.
• Zaznavanje anomalij s kratkim oknom za nenadne skoke.
• Najvišji ocenjeni strošek na zahtevo ali na opravilo.
• Ločene omejitve za produkcijske, uprizoritvene, CI in evalvacijske delovne obremenitve.

Uporabite različna dejanja za različne pragove. Pri 50 odstotkih obvestite ekipo lastnikov. Pri 80 odstotkih zahteva potrditev. Pri 100 odstotkih blokirajte nekritične zahteve, znižajte na cenejše odobrene modele ali zahtevajte izrecno preglasitev. Pravilno vedenje je odvisno od tega, ali je delovna obremenitev namenjena strankam, interna, paketna ali kritična za varnost.

Oblikovanje delovnega toka življenjskega cikla

Storitveni račun brez kontrol življenjskega cikla postane še ena neupravljana skrivnost. Določite potek dela pred široko uporabo.

Zahteva

Vlagatelj mora navesti ime aplikacije, okolje, lastniško ekipo, poslovni namen, pričakovano mesečno porabo, klasifikacijo podatkov, zahteve za model, zahteve za končno točko in ali je združevanje možno.

Odobritev

Odobritev mora izhajati iz lastniške ekipe in platforme ali varnostne politike. Delovne obremenitve z visokim proračunom, občutljivimi podatki, partnerji ali uporabo orodij bi morale zahtevati strožji pregled kot opravila notranjega povzemanja z nizkim tveganjem.

Omogočanje

Ustvarite račun notranje storitve, vezavo ponudnika, proračun, politiko modela, ponor revizije in tajno ali zvezno zaupanje. Zagotavljanje prek avtomatizacije namesto ročnega dela konzole, kjer je to mogoče.

Skrivna dostava

Če je potreben statični ključ, ga dostavite samo centraliziranemu tajnemu upravitelju ali platformi za uvajanje. Ne pošiljajte ključev prek klepeta, vstopnic, lokalnih datotek ali strani z dokumentacijo.

Pregled

Preglejte storitvene račune s fiksno kadenco. Potrdite lastniško ekipo, zadnjo uporabo, dovoljenja, proračun, dostop do modela, politiko podatkov in ali je mogoče statične ključe zamenjati z zveznimi.

Onemogoči in izbriši

Pred brisanjem onemogočite neuporabljene storitvene račune. To ustvari okno za obnovitev, če je bila odvisnost delovne obremenitve zgrešena. Po obdobju karantene izbrišite račun in prekličite vse ponudnikove vezave in skrivnosti.

Vpišite dogodke, ki jih potrebujejo nadzorniki in odzivniki

Revizijski dnevniki morajo zajemati tako dejavnost nadzorne kot podatkovne ravnine. Vsaj dnevnik:

• Ustvarjanje, posodabljanje, onemogočanje in brisanje storitvenega računa.
• Ustvarjanje poverilnice, branje, rotacija in preklic.
• Ustvarjanje zveznega zaupanja in spremembe pravilnika o zahtevkih.
• Spremembe dovoljenj, dostopa do modela, dostopa do končne točke in podatkovnih pravilnikov.
• Vsaka zahteva za LLM z računom storitve, najemnikom, modelom, ponudnikom, uporabo žetonov, ocenjenimi stroški, statusom in namenom zahteve.
• Dogodki proračunskega praga, blokade trdih omejitev in ročne preglasitve.
• Skrbniški API klici, ki vplivajo na projekte ponudnika, delovne prostore, storitvene račune ali ključe.

Pošlji te dogodke v nespremenljiv revizijski tok ali revizijski tok, odporen na posege. Telemetrijo zahtev z visoko kardinalnostjo hranite ločeno od dolgotrajnih revizijskih dokazov, če to pomaga nadzorovati stroške shranjevanja, vendar ohranite ključe za združevanje, potrebne za preiskave.

Načrt selitve iz ključev v skupni rabi

Ključe v skupni rabi je mogoče zamenjati postopoma. Izogibajte se selitvi velikega poka, razen če je ključ že ogrožen.

1. Prepoznajte najbolj obremenjene ključe v skupni rabi. Razvrstite glede na porabo, promet, dostop do modela in neznano lastništvo.
2. Združi klicatelje v meje delovne obremenitve. Uporabi dnevnike, izvorne repozitorije, spremenljivke uvedbe, uporabniške agente in izvorne podatke omrežja.
3. Ustvarite storitvene račune z obsegom. Začnite s proizvodnimi delovnimi obremenitvami, ki imajo jasne lastnike in visoko porabo ali visoko tveganje.
4. Usmerjanje skozi prehod. Začasno ohranite stari ključ ponudnika za prehodom, če bi neposredna selitev ponudnika trajala dlje.
5. Dvojno dodeljevanje. Primerjajte promet, stroške, napake, zakasnitev in zaračunavanje ponudnika, preden v celoti presežete.
6. Izmenjava klicateljev. Posodobite skrivnosti uvajanja, spremenljivke CI in konfiguracijo aplikacije eno delovno obremenitev naenkrat.
7. Prekliči skupni ključ. Najprej v karanteno, če je polmer eksplozije nejasen, nato prekliči po opazovalnem oknu.

Cilj ni zgolj vrtenje ključa. Cilj je zamenjati dvoumen dostop z identiteto, politiko, proračunom in dokazi v lasti delovne obremenitve.

Kompromisi, da bi bili eksplicitni

Več računov storitev izboljša nadzor, vendar poveča administracijo. Pravila o poimenovanju, metapodatki o lastništvu, opravila čiščenja in poteki dela pregledovanja so tisto, zaradi česar je model uporaben.

Zvezovanje zmanjša tveganje statične tajnosti, vendar doda odvisnost od ponudnika identitete. Izmenjava žetonov lahko spodleti zaradi sprememb izdajatelja, zamika zahtevkov, poševnosti ure ali sprememb konfiguracije CI. Oblikujte jasne načine napak in opozorila.

Izvorni kontrolniki ponudnika so dragoceni, vendar nedosledni. Nekateri ponudniki različno izpostavijo projekte, delovne prostore, storitvene račune, proračune ali zvezo. Sloj identitete na ravni prehoda zagotavlja dosledno politiko in poročanje, vendar mora ohraniti zgornji kontekst za preiskave kvot, zaračunavanja in podpore.

Kratkotrajne poverilnice izboljšajo varnost, vendar povečajo zapletenost izvajalnega časa. Skrbno predpomnite žetone, upoštevajte potek veljavnosti in preprečite, da bi bila vsaka zahteva LLM odvisna od počasnega klica nadzorne ravnine.

Centralizirano uveljavljanje izboljšuje upravljanje, vendar povečuje odgovornost platforme. Če ima prehod v lasti pravilnik, proračune in dodeljevanje, mora biti zelo opazen in operativno zrel.

Kontrolni seznam za implementacijo

• Ustvarite popis človeških ključev, identitet delovne obremenitve, identitet CI, partnerskih ključev in poverilnic za razbito steklo.
• Določite dogovor o poimenovanju z aplikacijo, okoljem, lastniško ekipo in namenom.
• Uporabite en storitveni račun na mejo produkcijske delovne obremenitve.
• Povežite vsako identiteto z ozkimi projekti ali delovnimi prostori ponudnika.
• Omeji družine modelov, končne točke, regije, pravilnike o podatkih in proračune.
• Dajte prednost zvezni ali kratkotrajni izmenjavi žetonov, kjer je podprto.
• Shranite statične ključe samo v centraliziranem tajnem upravljanju.
• Zahtevaj metapodatke o dodelitvi pri vsaki zahtevi.
• Nastavite proračune storitvenih računov in opozorila o nepravilnostih.
• Beležite poverilnice, dovoljenja, zahteve, proračun in dogodke preklica.
• Onemogočite neuporabljene račune, preden jih izbrišete.
• Preselite ključe v skupni rabi glede na delovno obremenitev, nato prekličite staro poverilnico.

Sklep

Upravljanje storitvenega računa LLM je operativni model za produkcijski dostop do umetne inteligence. Vsakega nenadzorovanega klicatelja obravnavajte kot identiteto delovne obremenitve z lastnikom, namenom, mejo dovoljenja, proračunom in življenjskim ciklom. Uporabite izvorne storitvene račune ponudnika, kjer vam pomagajo, izberite zvezo, kjer je to praktično, in normalizirajte identiteto na prehodu, tako da je mogoče dosledno upravljati OpenAI, Anthropic, Gemini in notranje sisteme.

Napoved: Platforme LLM se bodo še naprej odmikale od širokih statičnih ključev k modelom storitvenega računa in identitete delovne obremenitve. Ekipe, ki zdaj vzpostavijo čisto lastništvo delovne obremenitve, bodo pozneje imele lažjo pot do združevanja ponudnikov, pripravljenosti na revizijo, partnerskega API upravljanja in zanesljivega nadzora stroškov.

Sorodno branje

• API ključno upravljanje za ekipe