Zakaj se vaša nadzorna plošča uporabe LLM ne ujema z računom ponudnika

Če vaša nadzorna plošča uporabe LLM, konzola ponudnika, izvoz zaračunavanja v oblaku in račun stranke prikazujejo različne številke, ne začnite s predpostavko, da je en sistem napačen. Začnite z vprašanjem, katera številka je verodostojna za kateri namen.

Nadzorna plošča prehoda je običajno operativni pogled: hiter, na ravni zahtev in uporaben za opozorila. Račun ponudnika je pogled poravnanega obračunavanja: počasnejši, združen in prilagojen v skladu s pravili ponudnika za obračunavanje. Izvozi obračunavanja v oblaku dodajo še eno plast, zlasti za storitve upravljanega modela, kjer so podatki o računih lahko razvrščeni glede na projekt, SKU, regijo, vrsto uporabe ali mesec računa namesto po zahtevi API.

Praktični problem ni samo »poiskati pravo številko«. Treba je razvrstiti neujemanje, ohraniti dovolj dokazov za njegovo razlago in odločiti, kdaj je številka dovolj dobra za nadzorne plošče, finančna poročila ali zaračunavanje strankam.

Uporabite dve knjigi, ne eno številko

Najpogostejša napaka je poskus, da bi se ocena prehoda v realnem času obnašala kot končni račun. To so različni zapisi z različnimi delovnimi mesti.

Knjiga operativne uporabe

Operativno knjigo ob času zahteve zapolni vaš prehod, SDK ovoj, posrednik ali instrumenti aplikacije. Moral bi biti optimiziran za hitrost in dodeljevanje. Odgovarja na vprašanja, kot so:

• Kateri najemnik, ekipa, API ključ, projekt ali potek dela je ustvaril to zahtevo?
• Kateri model se je imenoval?
• Koliko vhodnih, izhodnih, predpomnjenih ali sklepnih žetonov je bilo opaženih ali ocenjenih?
• Ali je bila zahteva ponovni poskus, preklicana, pretočna, paketna ali neuspešna?
• Kateri interni proračun ali omejitev je treba zaračunati takoj?

Ta knjiga je bistvenega pomena za upravljanje stroškov LLM, vendar ni vedno točna glede na račun. Preden ponudnik vrne končno uporabo, lahko uporabi ocenjene žetone. Lahko uporabi zastarelo tabelo cen. Lahko šteje poskus zahteve, ki ga ponudnik ne zaračuna, ali zamudi ponovni poskus, ki ga ponudnik zaračuna.

Knjiga poravnanih stroškov

Knjiga poravnanih stroškov se izpolni iz API-jev za stroške ponudnika, poročil o uporabi ponudnika ali izvozov obračunavanja v oblaku, potem ko ponudnik zbere in razvrsti stroške. Treba ga je optimizirati za finančno poročanje. Odgovarja na vprašanja, kot so:

• Kakšne stroške je ponudnik poročal za ta dan, model, projekt, ključ, element vrstice ali vrsto uporabe?
• Katera valuta in obdobje računa veljata?
• Ali je prišlo do poznih popravkov, dobropisov ali prilagoditev?
• Katere stroške je mogoče z zaupanjem dodeliti najemnikom?
• Kateri stroški ostanejo nedodeljeni, ker manjkajo metapodatki?

Priporočila: uporabljajte operativno knjigo za opozorila, proračunske rezervacije, odpravljanje napak in nadzorne plošče v skoraj realnem času. Uporabite knjigo poravnanih stroškov za zaključek financ, račune strank, analizo marže in končno povratno bremenitev. Vsako število pred poravnavo označite kot ocenjeno ali začasno.

Razvrstite neujemanje pred odpravljanjem napak

Večina neskladij pri obračunavanju LLM spada v pet razredov. Razvrstitev vrzeli najprej prepreči ekipam, da bi lovile podrobnosti o tokenizaciji, ko je resnična težava časovna razporeditev računov, ali lovile izvoze računov v oblak, ko so resnična težava manjkajoči metapodatki najemnika.

1. Premik časovnega okna

To se zgodi, ko dva sistema združita isto uporabo v različna obdobja.

Pogosti vzroki vključujejo UTC v primerjavi z lokalnimi datumi, dneve za zaračunavanje ponudniku, ki se ne ujemajo z dnevi na nadzorni plošči, datume dokončanja paketnih opravil, ki se razlikujejo od datumov oddaje, zahteve za pretakanje, ki prečkajo datumsko mejo, in polja računa za mesec v oblaku, ki se razlikujejo od časovnih žigov uporabe. Izvozi obračunavanja v oblaku lahko vključujejo tudi popravke ali pozno ovrednoteno uporabo v kasnejšem obdobju računa.

Koraki za odpravljanje napak:

1. Pretvori vsak časovni žig v UTC pred primerjavo.
2. Ločeno primerjajte datum uporabe, začetni čas zahteve, končni čas zahteve, čas obdelave ponudnika, čas dokončanja paketa in mesec računa.
3. Najprej uskladite zaprta obdobja. Izogibajte se diagnosticiranju današnje nadzorne plošče glede na poročilo ponudnika, ki se še vedno uravnava.
4. Pri paketnih delovnih obremenitvah primerjajte datum oddaje zahteve in datum dokončanja paketa.

Priporočilo: določite koledar poročanja, ki ločuje »dan uporabe«, »dan poravnave« in »mesec računa«. Ne strnite teh polj v en datumski stolpec.

2. Premik dimenzije

To se zgodi, ko nadzorna plošča in račun združujeta različne stvari.

Vaš prehod se lahko združi glede na najemnika, ekipo, API ključ, okolje ali potek dela. Ponudnikov strošek API se lahko razvrsti po projektu, uporabniku, API ključu, modelu, vrstičnem elementu ali viru, odvisno od ponudnika in končne točke. Izvoz obračunavanja v oblaku se lahko združi glede na projekt, SKU, storitev, lokacijo, vrsto uporabe, oznake ali mesec računa. Za storitve upravljanega modela dodeljevanje poziva na zahtevo morda sploh ne obstaja v izvozu računa.

Koraki za odpravljanje napak:

1. Zapišite natančne razsežnosti združevanja, ki jih uporablja vsak sistem.
2. Normalizirajte ID-je modelov, regije, storitvene ravni, vrste žetonov, elemente vrstic in API vire, preden primerjate skupne vrednosti.
3. Preverite, ali se projekti, delovni prostori, API ključi in oznake projektov v oblaku pravilno preslikajo v vaše notranje najemnike.
4. Izrecno določite nepripisano porabo, namesto da bi jo vsilili v vedro najemnika.

Priporočilo: dodeljevanje najemnikov obravnavajte kot prvovrstno obračunsko polje, ne kot filter na nadzorni plošči. Za zanesljivo LLM API dodeljevanje stroškov zajemite identifikatorje najemnikov ob času zahteve in ohranite identifikatorje na strani ponudnika, ki so potrebni za kasnejšo pridružitev.

3. Nihanje cen

To se zgodi, ko operativna ocena uporablja drugačno cenovno logiko kot ponudnikov poravnani račun.

Pogosti vzroki vključujejo cene predpomnjenih žetonov, stroške pisanja v predpomnilniku v primerjavi s stroški zadetkov v predpomnilniku, ločene stopnje vhodnih in izhodnih žetonov, vzdevke modelov, ki so se premaknili na model z novejšo ceno, ravni storitev, geografijo sklepanja, paketne popuste, elemente vrstic za iskanje datotek ali spletno iskanje, slikovne ali zvočne enote in pretvorbo valut. Nadzorna plošča, ki pomnoži skupne žetone z eno mešano ceno, se bo spremenila takoj, ko bo račun ponudnika vseboval več vrst žetonov ali vrstičnih postavk.

Koraki za odpravljanje napak:

1. Razdelite stroške v vrstične postavke, preden primerjate skupne zneske.
2. Ločite vhodne žetone, izhodne žetone, zapise v predpomnilnik, zadetke v predpomnilniku, sklepne žetone in enote brez žetonov, kjer jih ponudniki poročajo.
3. Različica vaše notranje tabele s cenami in shranjevanje različice cene, uporabljene za vsako oceno.
4. Preverite, ali ponudnik poroča o vzdevkih modela, posnetkih modelov ali elementih linije izdelkov drugače od vašega prehoda.
5. Primerjajte v valuti zaračunavanja ponudnika, preden uporabite lastno pretvorbo valut.

Dejstva: površine za poročanje ponudnikov lahko razkrijejo razdeljene stroške in razsežnosti združevanja, kot so projekt, uporabnik, API ključ, model, postavka vrstice, delovni prostor, vrsta žetona, geografija, raven storitve ali valuta, odvisno od ponudnika in okolja. Izvozi v oblak lahko razkrijejo oznake, polja virov, časovne žige uporabe, mesec računa, kredite in popravke.

4. Zahteva za premik življenjskega cikla

To se zgodi, ko se sistemi ne strinjajo glede tega, kaj šteje za eno plačljivo operacijo.

Ponovni poskusi so običajen krivec. Če aplikacija znova poskusi po časovni omejitvi, lahko vaša nadzorna plošča izdelka obravnava končni uspešen odgovor kot eno dejanje uporabnika, medtem ko ponudnik zaračuna dva ali tri priklice modela. Nadomestno usmerjanje lahko povzroči isto težavo, ko sta en neuspešen primarni klic in en uspešen nadomestni klic prikazana kot en rezultat aplikacije.

Pretakanje doda še en vir premikanja. Uporabnik lahko prekliče tok po prejemu delnega izhoda. Ponudnik lahko generirane žetone poroča do preklica, vaša aplikacija pa beleži le neuspelo ali opuščeno zahtevo. Paketna opravila ustvarijo drugačen življenjski cikel: oddaja, preverjanje, obdelava, delna napaka, pridobivanje rezultatov in zaračunavanje morda nimajo istega časovnega žiga.

Koraki za odpravljanje napak:

1. Uporabniškemu dejanju dodelite stabilen notranji ID zahteve.
2. Dodelite ločene ID-je poskusov za vsak klic, ponovni poskus in nadomestni klic ponudnika.
3. Shranite ID-je odgovorov ponudnika in ID-je zahtev, ko so na voljo.
4. Snemanje stanja toka: dokončano, odjemalec preklican, strežnik prekinjen, časovna omejitev ali izguba omrežja.
5. Za paketna opravila shranite ID paketnega opravila, ID vhodne datoteke, kjer je na voljo, čas oddaje, čas dokončanja in status posamezne postavke, če je na voljo.

Priporočilo: primerjajte račune ponudnika s poskusi ponudnika, ne z dejanji uporabnika na ravni izdelka. Nato združite poskuse do uporabniških dejanj za analitiko izdelka.

5. Odklon poravnave ponudnika

To se zgodi, ko se podatki za obračun na strani ponudnika spremenijo, potem ko je na nadzorni plošči že prikazana številka.

API-ji za stroške ponudnika in izvozi zaračunavanja v oblaku so bližje resnici o zaračunavanju, vendar se lahko pozneje odložijo, razdelijo ali prilagodijo. Dobropisi, popravki, pozno prispela uporaba, mesečne spremembe računov in prerazvrstitev izdelkov lahko spremenijo končno številko. To je še posebej pomembno, ko finance primerjajo posnetek zaslona nadzorne plošče prvega dne v mesecu z izvozom računa, ustvarjenim pozneje.

Koraki za odpravljanje napak:

1. Sledenje, kdaj je bil pridobljen vsak paket stroškov ponudnika.
2. Shranjevanje nespremenljivih posnetkov uvozov s poravnanimi stroški.
3. Zaznaj spremembe med uvozi za istega ponudnika, obdobje in razsežnosti združevanja.
4. Ohranite pozne prilagoditve kot prilagoditvene vrstice, namesto da tiho prepisujete zgodovino.
5. Določite postopek zapiranja: na primer, obdržite obdobje začasno, dokler se podatki ponudnika ne stabilizirajo in preverjanje odstopanj ne uspe.

Priporočilo: na računih strank morajo biti uporabljena ustaljena obdobja ali izrecna začasna oznaka. Nadzorne plošče lahko dopuščajo majhna odstopanja v odprtih obdobjih; zaračunavanje strankam ne sme skrivati negotovosti.

Shema minimalnih dokazov

Postopek usklajevanja je dober le toliko, kolikor so dokazi shranjeni, preden se pojavi neujemanje. Zajemite vsaj metapodatke, ki vam omogočajo premikanje med operativnimi zapisi in zapisi o zaračunavanju ponudnika brez shranjevanja občutljive vsebine pozivov.

Priporočena polja na ravni zahteve:

• Notranji identifikatorji: internal_request_id, attempt_id, parent_request_id, tenant_id, team_id, project_id, okolje, workflow_id.
• Identifikatorji dostopa: gateway_api_key_id, provider_api_key_id, ko je na voljo, storitveni račun, user_id, kjer je primerno.
• Identifikatorji ponudnika: ponudnik, provider_project_id, provider_workspace_id, provider_response_id, provider_request_id, cloud_account_id, cloud_project_id.
• Model in usmerjanje: requested_model, resolved_model, model_version, route_policy, fallback_from, fallback_to.
• Uporaba: input_tokens, output_tokens, cached_input_tokens, cache_write_tokens, reasoning_tokens, token_unit, non_token_quantity, quantity_unit.
• Ocena cene: estimated_cost, valuta, price_table_version, estimate_source, budget_reservation_id.
• Življenjski cikel: stanje, error_class, retry_number, stream_started, stream_completed, stream_termination_status, batch_job_id, batch_item_id.
• Čas: request_started_at, request_completed_at, provider_reported_at, batch_submitted_at, batch_completed_at, usage_date_utc.

Ne shranjujte neobdelanih pozivov ali odgovorov samo za uskladitev obračunavanja. Običajno zadostujejo metapodatki zahteve, število žetonov, ID-ji ponudnika in normalizirane dimenzije. Če dnevniki klicanja morda vsebujejo občutljivo vsebino, uredite ali onemogočite zajem koristnega tovora za pozive in odzive, medtem ko obdržite polja za uporabo in identiteto.

Primerjaj z najnižjo zanesljivostjo skupnega zrna

Uskladitev na ravni zahteve se sliši privlačno, vendar ni vedno mogoča. Pravo primerjalno zrno je odvisno od tega, kaj izpostavlja ponudnik.

API-ji za stroške ponudnika

Kjer končne točke stroškov ponudnika razkrijejo dnevne segmente in razsežnosti združevanja, kot so projekt, uporabnik, API ključ, model, postavka vrstice, delovni prostor ali vrsta žetona, začnite tam. Primerjajte dnevne pakete poravnanih stroškov z dnevnimi skupnimi podatki vašega prehoda z uporabo istih dimenzij. Ne primerjajte nadzorne plošče na ravni najemnika neposredno s skupno organizacijo ponudnika, razen če je pokritost najemnika popolna.

Primer primerjalnega zrna:

• date_utc
• ponudnik
• provider_project_id ali workspace_id
• api_key_id če je na voljo
• model ali resolved_model
• line_item ali token_type
• valuta

Modelne storitve, zaračunane v oblaku

Pri storitvah, zaračunanih v oblaku, izvoz računa morda ne vključuje identifikatorjev na zahtevo. V tem primeru združite dnevnike klicanja z izvozom stroškov in uporabe v bolj grobi obliki, kot so dan, model, regija in vrsta uporabe. Za dodeljevanje najemnikov uporabite dnevnike na ravni zahtev, za skupne zneske računov pa uporabite izvoz zaračunavanja v oblaku.

Primer zrna primerjave:

• usage_date_utc
• cloud_account_id ali billing_account_id
• cloud_project_id
• regija
• model_id
• usage_type ali SKU
• invoice_month

Dejstvo: dokumentacija AWS Bedrock opisuje uporabo polj poročila o stroških in uporabi, kot so model, vrsta žetona, raven storitve in sklepanje med regijami, v podatkih o vrsti uporabe, medtem ko se za identiteto zahteve, število žetonov, ID modela, regijo in ID zahteve uporablja dnevnike klicanja modela. Dokumentacija priporoča združevanje dnevnikov klicev s CUR pri modelu, vrsti uporabe in dnevu za vsote, ki so točne na računih.

Praktični potek dela za usklajevanje

Uporabite ta potek dela, ko finance poročajo o neujemanju računa.

1. korak: Zamrznite primerjavo

Izberite enega ponudnika, eno obračunsko obdobje, eno valuto in eno primerjalno zrno. Istočasno izvozite številko nadzorne plošče, poročilo o stroških ponudnika in izvoz obračunavanja v oblaku. Zabeležite časovne žige izvoza. Številne ekipe zapravljajo ure s primerjanjem premikajočih se tarč.

2. korak: Ločite ocenjene in poravnane dolarje

Razdelite vrstice na estimated_cost in settled_cost. Ocenjeni stroški izhajajo iz tabele cen vašega prehoda. Poravnani stroški izvirajo iz podatkov ponudnika ali računa v oblaku. Nikoli ne prepišite enega z drugim; shrani oboje in sledi varianci.

3. korak: Normalizirajte dimenzije

Ustvarite tabelo preslikav za ponudnika, model, razrešen model, element vrstice, vrsto žetona, raven storitve, regijo, projekt, delovni prostor, API ključ in najemnika. Vključite »neznano« ali »nepripisano« vedro. Prisilna dodelitev je slabša od eksplicitne vrzeli, ker skrije operativni popravek.

4. korak: Uskladite vsote od zgoraj navzdol

Začnite s skupnim zneskom organizacije ponudnika v primerjavi s skupnim zneskom računa ponudnika. Nato primerjajte po dnevih. Nato primerjajte glede na model in postavko. Šele potem, ko so ti uspešni, bi morali primerjati dodelitev najemnika ali API-ključa. Ta vrstni red vam pove, ali je težava globalno določanje cen, premik časovnega okna ali pripis.

5. korak: Raziščite varianco po razredu

Uporabite pet razredov kot kontrolni seznam:

• Premik časovnega okna: Neusklajenost UTC, lokalno združevanje datumov, datum zaključka serije, mesec računa, pozna uporaba.
• Premik dimenzije: neujemanje projekta/delovnega prostora, manjkajoči ključ API, nepreslikan model, manjkajoča oznaka najemnika.
• Odmik cen: žetoni predpomnilnika, raven storitve, regija, paketne cene, vrstični elementi brez žetonov, zastarela tabela cen.
• Zahtevaj premik v življenjskem ciklu: ponovni poskusi, nadomestne možnosti, preklici pretakanja, delne paketne napake, časovne omejitve.
• Odmik ponudnika-poravnave: krediti, popravki, zakasnjeni segmenti, spremenjeni izvozi stroškov.

6. korak: Uporabite pragove variance

Različni primeri uporabe zahtevajo različne tolerance. Inženirska nadzorna plošča lahko dopušča majhno odstopanje za odprta obdobja, če je jasno označena kot čakajoča. Sistem izvrševanja proračuna bo morda potreboval konzervativne ocene, da prepreči prekomerno porabo. Račun stranke mora uporabljati poravnane stroške ali dokumentirano politiko dodelitve.

Priporočilo: pragove določite glede na primer uporabe, ne glede na ponudnika. Na primer:

• Operativna nadzorna plošča: omogoča majhno odstopanje odprtega obdobja in prikazuje čakajoče stanje.
• Opozorila o proračunu: uporabite konzervativne ocene in jih uskladite pozneje.
• Notranja povratna bremenitev: zahtevajo poravnane segmente ponudnika in preverjanje pokritosti pripisa.
• Račun stranke: zahteva zaprto obdobje, uvoz poravnanih stroškov, odstopanje pod pragom in nobeno pomembno nepripisano porabo.

Vzorec implementacije: Usklajevalne tabele

Pogosto zadostuje preprosta shema. Potrebujete ločene tabele za operativne poskuse, segmente stroškov ponudnika, normalizirane skupne vrednosti in rezultate odstopanj.

operational_attempts
- attempt_id
- internal_request_id
- tenant_id
- provider
- provider_project_id
- provider_workspace_id
- provider_api_key_id
- model_requested
- model_resolved
- region
- input_tokens
- output_tokens
- cached_input_tokens
- cache_write_tokens
- status
- retry_number
- stream_termination_status
- batch_job_id
- estimated_cost
- currency
- price_table_version
- usage_date_utc

provider_cost_buckets
- provider
- bucket_date_utc
- provider_project_id
- provider_workspace_id
- provider_api_key_id
- model
- line_item
- token_type
- service_tier
- region
- quantity
- quantity_unit
- settled_cost
- currency
- invoice_month
- imported_at

reconciliation_results
- period_start
- period_end
- grain_key
- estimated_cost
- settled_cost
- absolute_variance
- percent_variance
- variance_class
- status
- notes
- checked_at

Pomembna izbira zasnove je ohranjanje ocenjenih in poravnanih stroškov. Ko prispejo podatki ponudnika, lahko izračunate varianco, ne da bi uničili prvotni operativni zapis, ki je takrat pojasnil opozorila in proračunske odločitve.

Pogosti popravki po prvi uskladitvi

Prva uskladitev običajno razkrije operativne vrzeli. Popravki so enostavni, vendar zahtevajo lastništvo celotne platforme in financ.

• Manjkajoči metapodatki najemnika: zahtevajo tenant_id, team_id ali customer_id na meji prehoda. Zavrni ali postavi v karanteno produkcijske zahteve brez metapodatkov o dodelitvi.
• Zastarele tabele cen: cene različic, sledenje datumom veljavnosti in opozorilo, ko se spremenijo katalogi modelov ponudnika ali strani s cenami.
• Ponovni poskus prekoračitve ali premajhnega števila: ločite ID-je zahtev izdelka od ID-jev poskusov ponudnika.
• Vrzeli pri preklicu pretakanja: beleži delno uporabo, ko ga ponudnik vrne, in beleži stanje prekinitve, tudi ko odjemalec prekine povezavo.
• Paketna dvoumnost: shranite ID-je opravil in jih primerjajte po datumu dokončanja in datumu oddaje.
• Neujemanje računov v oblaku: združite dnevnike klicev izvozom obračunavanja glede na dan, model, regijo in vrsto uporabe namesto pričakovanja vrstic računa na zahtevo.
• Nepojasnjeno zakasnelo gibanje: uvozi stroškov ponudnika posnetkov in posnamejo vrstice prilagoditev za zamude pri kreditih ali popravkih.

Dejstva, priporočila in napovedi

Dejstva: Ponudniki in sistemi za obračunavanje v oblaku razkrivajo različne razsežnosti obračunavanja in ravni podrobnosti. API-ji nekaterih ponudnikov razkrivajo dnevne segmente stroškov in razsežnosti združevanja, kot so projekt, uporabnik, ključ API, model, postavka vrstice, delovni prostor, vrsta žetona, raven storitve, geografija in valuta, odvisno od končne točke in okolja. Izvozi obračunavanja v oblaku običajno vključujejo oznake projekta ali vira, časovne žige, mesec računa, kredite, popravke, SKU-je, lokacije in vrste uporabe. Storitve modela, ki se obračunavajo v oblaku, lahko zahtevajo dnevnike klicev za dodeljevanje na ravni zahteve.

Priporočila: Vodite knjigo operativne uporabe in knjigo poravnanih stroškov. Primerjajte pri najnižjem zanesljivem skupnem zrnu. Ohranite dokaze na ravni zahteve brez shranjevanja občutljivih koristnih podatkov. Pred primerjavo normalizirajte dimenzije. Za račune uporabite ustaljene podatke ponudnika ali račune v oblaku. Neprideljeno porabo obravnavajte kot težavo s kakovostjo podatkov, ne kot nekaj, kar bi morali skriti z mešano dodelitvijo.

Napovedi: Usklajevanje zaračunavanja LLM bo postalo pomembnejše, saj bodo ekipe uporabljale več predpomnjenih pozivov, paketnih opravil, ravni storitev, nadomestne poti in storitev modela, ki gostujejo v oblaku. API-ji za obračunavanje ponudnikov se bodo verjetno izboljšali, vendar ne bodo odpravili potrebe po notranjih metapodatkih najemnikov, ker ponudniki ne morejo sklepati o vaši stranki, skupini ali hierarhiji poteka dela.

Sklep

Če se nadzorna plošča LLM ne ujema z računom ponudnika, je odgovor le redko ena napaka. Običajno gre za neskladje med operativnimi ocenami, stroški, ki jih poravna ponudnik, dimenzijami zaračunavanja v oblaku in internimi pravili dodeljevanja.

Trajni popravek je priročnik za usklajevanje: vodite ločene operativne in poravnane knjige, razvrstite varianco v časovno okno, dimenzijo, ceno, življenjski cikel ali premik poravnave, ohranite dokaze na ravni zahteve in izdajajte račune samo iz poravnanih obdobij po preverjanju odstopanj. To inženirskim ekipam omogoča hiter nadzor, ne da bi od financ zahtevali, naj zaupajo začasnim številkam kot končnim dolarjem.

Sorodno branje

• dnevno usklajevanje za knjigo stroškov LLM za posamezno ekipo