B2BB2B LLM
Biznesa ieskats

Kā izveidot izmaksu ziņā zinošu LLM modeļa maršrutēšanu, nezaudējot kvalitāti

Praktiska arhitektūra izmaksu ziņā apzinātai LLM modeļa maršrutēšanai, kas izmanto uzdevumu klasifikāciju, kvalitātes līmeņus, pakalpojumu sniedzēja ierobežojumus, izmaksu aprēķinus un audita žurnālus, nevis naivu lētāko modeļu izvēli.

Izmaksu zinoša LLM modeļa maršrutēšana nedrīkst nozīmēt katra pieprasījuma nosūtīšanu uz lētāko pieejamo modeli. Tādējādi tiek izveidots kluss atteices režīms: rēķini tiek uzlaboti dažas nedēļas, pēc tam produktu komandas atklāj bojātas shēmas, vājāku pamatojumu, nekonsekventu toni vai atbalsta melnrakstus, kas prasa vairāk cilvēku tīrīšanu.

Labāks modelis ir eval atbalstīta maršrutēšanas politika. Klasificējiet pieprasījumu, definējiet šī uzdevuma minimālo pieņemamo kvalitāti, noņemiet maršrutus, kas neatbilst spēju vai pārvaldības ierobežojumiem, novērtējiet maršruta ekonomiku un pēc tam izvēlieties piemērotāko modeli ar viszemākajām izmaksām. Maršrutēšanas lēmums kļūst izskaidrojams izmaksu pārskatīšanas laikā, jo tas ir saistīts ar politikas versiju, nevis ar izstrādātāja izvēli vai neskaidru pakalpojumu sniedzēja noklusējuma iestatījumu.

Ko optimizē izmaksu ziņā apzināta maršrutēšana

Praktisks maršrutētājs optimizē lētāko maršrutu, kas joprojām atbilst uzdevuma darbības prasībām. Tas atšķiras no optimizācijas lētākajam modelim.

Fakti: lielākie modeļu nodrošinātāji publicē marķiera cenas ar atsevišķām dimensijām, piemēram, ievades marķieriem, kešatmiņā saglabātajiem ievades marķieriem, izvades marķieriem, tūlītēju kešatmiņu un pakešu apstrādi. Daži pakalpojumu sniedzēji atklāj arī lietojuma laukus, kas ziņo par kešatmiņā saglabāto marķieru darbību. Tas nozīmē, ka zemāko izmaksu opcija var mainīties atkarībā no uzvednes formas, paredzamā izvades garuma, piemērotības kešatmiņai un to, vai darba slodze var darboties asinhroni.

Ieteikums: uztveriet maršrutēšanu kā politikas problēmu vairāku modeļu AI API vārtejā, nevis kā lietojumprogrammas līmeņa slēdža paziņojumu. Vārteja vienuviet redz nodrošinātāja iespēju ierakstus, nomnieku kārtulas, API atslēgu metadatus, cenu tabulas, lietojuma telemetriju un atkāpšanās darbības.

Prognoze: komandām, kuras maršrutēšanas loģiku izkaisa pa lietojumprogrammu krātuvēm, vēlāk būs grūti izskaidrot izmaksu izmaiņas. Viņi joprojām var samazināt tēriņus, taču tiem būs vājāki pierādījumi, kāpēc konkrētajā pieprasījumā tika izmantots konkrēts modelis.

Sāciet ar uzdevumu klasēm, nevis pakalpojumu sniedzēju nosaukumiem

Lai maršrutētājs varētu pieņemt noderīgu lēmumu, tam ir nepieciešama darba slodzes etiķete. Viens noklusējuma modelis nevar atspoguļot katra pieprasījuma riska profilu.

Noderīgas uzdevumu klases ietver:

  • Iegūšana: konvertējiet nestrukturētu tekstu laukos, bieži izmantojot stingru shēmas validāciju.
  • Klasifikācija: piešķiriet iezīmes, prioritāti, nolūku, uzskatus vai maršrutēšanas kategorijas.
  • Apkopojums: saspiest garo ievadi, vienlaikus saglabājot galvenos faktus un lēmumus.
  • Klientu atbalsta projektēšana: ģenerējiet atbildi, ko cilvēks var pārskatīt vai nosūtīt.
  • RAG atbilžu sintēze: atbilde no izgūtā konteksta ar atsauces vai pamatojuma prasībām.
  • Koda pārskatīšana: pārbaudiet atšķirības vai avota failus, lai noteiktu pareizību, risku vai stila problēmas.
  • Ilga konteksta analīze: iemesls saistībā ar līgumiem, stenogrammām, žurnāliem, politikām vai pētījumu pakotnēm.
  • Ietekmes lēmumu atbalsts: jebkura darbplūsma, kurā slikta atbilde var ietekmēt naudu, atbilstību, drošību vai klientu uzticību.

Uzdevumu klase var nākt no precīza pieprasījuma metadatiem, API atslēgas darbības jomas, lietojumprogrammas maršruta vai viegla klasifikatora. Skaidri metadati parasti ir labāki nekā nolūka izsecināšana no uzvednes teksta, jo neskaidras uzvednes liek maršrutētājam izmantot konservatīvus noklusējuma iestatījumus.

Katram uzdevumam pievienojiet kvalitatīvu grīdu

Izmaksu zinoša maršrutēšana darbojas tikai tad, ja katram uzdevumam ir kvalitatīva zemākā vērtība. Bez tā maršrutētājam nav principiāla veida, kā noraidīt lētāku modeli.

Kvalitatīvā grīda var ietvert vairākas pārbaudes:

  • Replayable eval set: reprezentatīvi piemēri no izstrādes un ražošanas, noņemot sensitīvus datus, ja nepieciešams.
  • Shēmas derīgums: izvadei ir jāparsē, jāapstiprina kanoniskā shēma un jāizvairās no neatbalstītiem laukiem.
  • Satura kritēriji: atbildei ir jāatbilst uzdevuma stila, atteikuma, pamatojuma un pilnīguma noteikumiem.
  • Drošības kritēriji: izvade nedrīkst nopludināt slēptos norādījumus, ignorēt politikas robežas vai izpildīt neuzticamus norādījumus no izgūtā satura.
  • Cilvēka pārskats: nepieciešams augstas ietekmes darbplūsmām vai jauna maršruta reklamēšanai.
  • Regresijas slieksnis: kandidāta maršrutam ir jāsasniedz vai jāpārsniedz pašreizējais maršruts kritisko kļūdu kategorijās, nevis tikai vidējais rezultāts.

Fakts: nodrošinātāja dokumentācijā ir aprakstīti novērtējumi kā veids, kā pārbaudīt modeļa rezultātus atbilstoši noteiktiem satura un stila kritērijiem. Viena mitinātā eval produkta novecošana ir plānota, tāpēc maršrutēšanas sistēmām ir jāsaglabā pakalpojumu sniedzējam neitrālas eval datu kopas, paredzamie rezultāti, vērtēšanas rubrikas un rezultāti, nevis atkarībā no vienas nodrošinātāja mitinātas eval virsmas.

Ieteikums: saglabājiet eval rezultātus pēc uzdevuma klases, modeļa, nodrošinātāja adaptera versijas, uzvednes versijas, shēmas versijas un eval versijas. Maršrutam nevajadzētu kļūt par piemērotu tikai tāpēc, ka modelis ir jauns vai lētāks. Tas kļūst piemērots, kad tas pārsniedz uzdevuma pašreizējos kvalitātes ierobežojumus.

Izveidojiet nodrošinātāja iespēju reģistru

Pirms izmaksu aprēķināšanas noņemiet visus maršrutus, kas nevar apmierināt pieprasījumu. Šī darbība neļauj maršrutētājam izvēlēties lētu modeli, kuram trūkst nepieciešamo iespēju.

Iespēju ierakstā jāiekļauj:

  • Atbalstītās ievades un izvades modalitātes.
  • Konteksta loga ierobežojumi.
  • Strukturēta izvade un rīku izsaukšanas atbalsts.
  • Straumēšanas atbalsts.
  • Tūlītēja kešatmiņas atbalsts un kešatmiņas telemetrijas pieejamība.
  • Pakešu API atbalsts.
  • Reģionālās apstrādes iespējas.
  • Datu saglabāšanas un ļaunprātīgas izmantošanas uzraudzības noteikumi, kas ir svarīgi jūsu politikai.
  • Darbības ierobežojuma izmēri un pašreizējā jauda.
  • Zināmās izvades līgumu atšķirības jūsu adaptera slānī.

Šis reģistrs ir jāuztur atsevišķi no lietojumprogrammu uzvednēm. Tas atrodas netālu no maršrutēšanas un pakalpojumu sniedzēja adaptera slāņa, kur sistēma var salīdzināt modeļus, katrā lietojumprogrammā nenopludinot pakalpojumu sniedzējam raksturīgus pieņēmumus.

Aprēķiniet maršruta izmaksas pirms atlases

Maršrutētājs pirms izpildes nevar zināt galīgās izmaksas, taču tas var pietiekami labi novērtēt, lai izvēlētos piemērotos maršrutus. Aprēķinos ir jāiekļauj mainīgie, kas faktiski pārvieto rēķinu.

estimated_cost =
  input_tokens * input_token_price
  + cached_input_tokens * cached_input_token_price
  + output_tokens_expected * output_token_price
  + tool_call_overhead_expected
  + retry_allowance_expected
  - batch_discount_if_eligible

Izmantojiet jaunākos telemetrijas datus, lai novērtētu izvades marķierus pēc uzdevumu klases. Piemēram, ekstrakcijas uzdevumiem var būt ierobežots izvades garums, savukārt ilgtermiņa konteksta analīze var ievērojami atšķirties. Aģentiem, kas izmanto rīkus, var būt papildu slēptās izmaksas, kas saistītas ar rīku izsaukumu plānošanu, mēģinājumiem un starpposma ziņojumiem.

Izmaksu aprēķinos ir jāņem vērā arī kešatmiņas un paketes piemērotība:

  • Kešatmiņas piemērotība: stabils uzvednes prefikss, atkārtoti lietojami sistēmas norādījumi, atkārtoti izgūtais konteksts, atbalstīta pakalpojumu sniedzēja darbība un pietiekama kešatmiņas trāpījuma varbūtība.
  • Pakešu piemērotība: darba slodze var pagaidīt, ir identiska pieprasījumu apstrāde, ilgstoša darba izsekošana, un tai nav nepieciešama interaktīva straumēšana.
  • Izvades marķiera risks: modelim vienam un tam pašam uzdevumam ir tendence sniegt garākas vai īsākas atbildes, un saīsināšana var kaitēt kvalitātei.
  • Atkārtoti mēģināt: nodrošinātājam vai modelim ir paaugstināts kļūdu līmenis, shēmas labošanas līmenis vai latentuma kļūmes šim uzdevumam.

Šajā vietā izmaksu maršrutēšana savienojas ar plašāku LLM izmaksu pārvaldību. Ar cenu tabulu vien nepietiek. Maršrutētājam ir nepieciešami pieprasījuma metadati, uzvednes struktūra, kešatmiņas trāpījumu mērījumi un noteikti lietojuma dati, lai uzzinātu, vai paredzamie ietaupījumi patiešām ir notikuši.

Izmantojiet modeļu līmeņus viena globālā noklusējuma vietā

Daudzpakāpju politiku ir vieglāk izskaidrot nekā lielu pakalpojumu sniedzēja izņēmumu sarakstu. Katrā līmenī ir jāietver viens vai vairāki piemēroti modeļi, kas ir izturējuši uzdevumu specifiskās robežas.

TierLietošanas gadījumsTipisks maršrutēšanas noteikums
EkonomikaZema riska deterministisks darbs, piemēram, vienkārša ekstrakcija, marķēšana vai īsa klasifikācijaIzmantojiet zemāko izmaksu modeli, kas iztur shēmas un precizitātes vārtus
LīdzsvarotsNormāla produkcijas izstrāde, kopsavilkums un RAG sintēzeIzdodiet priekšroku rentabliem modeļiem ar stabilu kvalitāti un latentumu
PremiumLielas likmes, neskaidri, gara konteksta vai zemas ticamības uzdevumiIzmantojiet modeļus ar augstāku spēju, ja vien pārliecība un eval history neatbalsta pazemināšanu
RestrictedRegulētas, sensitīvas, reģionālas vai līgumiskas darba slodzesAtļaut tikai tos pakalpojumu sniedzējus un modeļus, kas apstiprināti saskaņā ar pārvaldības politiku

Neļaujiet līmenim aizstāt evals. Modelis var būt ekonomisks klasifikācijai, bet nederīgs atbalsta izstrādei. Cits modelis var būt labs kopsavilkumam, bet pārāk dārgs īsai deterministiskai marķēšanai.

Maršruts ar skaidru lēmumu secību

Izmaksu zinošam maršrutētājam ir jābūt pietiekami determinētam, lai varētu atkļūdot. Precīza ieviešana ir atšķirīga, taču lēmumu secībai ir jābūt stabilai.

  1. Lasīt nomnieka, API atslēgas, vides un lietojumprogrammas metadatus.
  2. Identificējiet uzdevuma klasi pēc skaidriem metadatiem vai klasifikatora izvades.
  3. Ielādējiet maršrutēšanas politikas versiju šim nomniekam vai darbvietai.
  4. Piemērojiet pārvaldības ierobežojumus, piemēram, datu saglabāšanu, reģionu, modeļa atļaušanas sarakstu un funkciju ierobežojumus.
  5. Filtrējiet pēc nepieciešamajām iespējām: konteksta garuma, rīkiem, strukturētās izvades, straumēšanas, modalitātes un pakešu atbalsta.
  6. Filtrējiet pēc eval atbalstītās kvalitātes zemākās vērtības uzdevumu klasei.
  7. Aprēķiniet izmaksas, izmantojot ievades marķierus, paredzamos izvades marķierus, kešatmiņas piemērotību, pakešu piemērotību un atkārtotā mēģinājuma risku.
  8. Lietot budžeta politiku un nomnieka preferences.
  9. Atlasiet piemērotāko maršrutu ar viszemākajām izmaksām.
  10. Pievienojiet rezerves maršruta, taimauta, atkārtota mēģinājuma un labošanas politiku.
  11. Reģistrējiet lēmumu ar stabilu iemesla kodu.

Pseidokodā maršrutētājam vairāk jāizskatās pēc politikas novērtējuma, nevis pēc kodēta pakalpojumu sniedzēja preferences:

function selectRoute(request):
  context = buildRoutingContext(request)
  task = classifyTask(context)
  policy = loadPolicy(context.tenant_id, task)

  candidates = modelRegistry.models
    .filter(model => policy.allows(model))
    .filter(model => model.supports(context.required_capabilities))
    .filter(model => evalStore.passes(task, model, policy.quality_floor))

  priced = candidates.map(model => ({
    model,
    estimated_cost: estimateCost(model, context),
    expected_latency: estimateLatency(model, context),
    risk_flags: estimateRisk(model, context)
  }))

  eligible = priced.filter(route => route.risk_flags.noneBlocking())
  return minBy(eligible, route => route.estimated_cost)

Reģistrējiet katru lēmumu par maršrutēšanu

Ja finanses jautā, kāpēc tika izmantots augstākās kvalitātes modelis, vai inženierzinātnes jautā, kāpēc kvalitāte pazeminājās, maršrutētājam ir jāatbild no žurnāliem. Nepaļaujieties uz nodomu rekonstrukciju no uzvednēm pēc fakta.

Ierakstiet šos laukus katram pieprasījumam:

  • Pieprasījuma ID, nomnieka ID, API atslēgas ID, lietojumprogrammas ID un vide.
  • Uzdevumu klasifikatora rezultāts un pārliecība.
  • Maršrutēšanas politikas versija.
  • Izmantota Eval datu kopas versija un kvalitātes vārti.
  • Piemērotie modeļi un noraidītie modeļi.
  • Iemesls, kādēļ tika izslēgts katrs noraidītais modelis.
  • Aptuvenās ievades, kešatmiņas ievades un izvades pilnvaras.
  • Paredzamās maršruta izmaksas un galīgās norēķinu izmaksas, ja tādas ir pieejamas.
  • Atlasītais pakalpojumu sniedzējs, modelis, adaptera versija un līmenis.
  • Atkāpšanās maršruta un atkārtota mēģinājuma politika.
  • Kešatmiņā trāpīts vai izlaista telemetrija, ja tā ir pieejama.
  • Pakešu un sinhronās izpildes režīms.
  • Shēmas validācija, remonta mēģinājumi, atteikuma statuss un drošības karodziņi.

Šie žurnāli atbalsta arī LLM API izmaksu attiecinājumu, jo modeļa izvēle ir tikai viena daļa no tēriņiem. Komandām joprojām ir jāsadala izmaksas pēc nomnieka, darbvietas, atslēgas, produkta, darbplūsmas vai klienta.

Pievienojiet dreifēšanas vadīklas, pirms reklamējat lētākus maršrutus

Modeļa uzvedības, cenu noteikšanas, uzvedņu un darba slodzes kombinācijas izmaiņas. Maršruts, kas pagājušajā mēnesī bija drošs, var kļūt vājš pēc tūlītējas pārskatīšanas vai modeļa atjaunināšanas.

Pamata dreifēšanas vadības cilpā jāietver:

  • Atlasiet neseno ražošanas pieprasījumu paraugus pēc uzdevumu klases.
  • Noņemiet vai pārveidojiet sensitīvus datus saskaņā ar politiku.
  • Atkārtoti atskaņojiet pašreizējos un kandidātu maršrutus.
  • Salīdziniet kvalitāti, shēmas derīgumu, atteikuma darbību, izmaksas un latentumu.
  • Pārskatiet neveiksmes pēc kategorijas, nevis tikai pēc apkopotā rezultāta.
  • Reklamējiet lētāku maršrutu tikai tad, ja tas atbilst kvalitātes un darbības ierobežojumiem.
  • Kanāri jaunais maršruts nelielai satiksmes daļai.
  • Automātiska atgriešana shēmas kļūmes, izmaksu pārsniegšanas, latentuma pārkāpuma vai cilvēka veiktās pārskatīšanas eskalācijas gadījumā.

Ieteikums: padariet maršruta reklamēšanu par izmaiņu pārvaldības pasākumu. Ierakstiet, kas to apstiprināja, kādu eval komplektu tas ir izturējis, kādu trafika procentuālo daļu tas ietekmē, kad beidzas derīguma termiņš vai kad tas ir jāpārskata un kā darbojas atcelšana.

Piešķiriet komandām ignorēšanu, taču ļaujiet tām beigties

Ir likumīgi iemesli ignorēt maršrutēšanu: pakalpojumu sniedzēja incidents, budžeta ārkārtas situācija, atbilstības pārskatīšana, klientu eskalācija vai modeļa regresija. Problēma nav ignorēšana. Problēma ir ignorēšana, kas kļūst par neredzamu pastāvīgu politiku.

Katrā ignorēšanā jāiekļauj:

  • Tvērums: nomnieks, lietojumprogramma, API atslēga, uzdevuma klase, modelis, nodrošinātājs vai reģions.
  • Iemesls: incidents, budžets, kvalitāte, atbilstība, latentums vai klienta pieprasījums.
  • Apstiprinātājs.
  • Sākuma laiks un derīguma termiņš.
  • Paredzamā ietekme uz izmaksām, latentumu un kvalitāti.
  • Atcelšanas nosacījums.

Ignorējumi, kuriem beidzies derīguma termiņš, nevar tikt slēgti saskaņā ar parasto maršrutēšanas politiku vai ir jāatjauno. Tādējādi ārkārtas lēmumi nekļūs par slēptām izmaksām vai kvalitātes risku.

Izmaiņas, lai padarītu skaidru

Izmaksu zinošai maršrutēšanai ir reālas darbības izmaksas. To joprojām ir vērts darīt, ja LLM tēriņi ir būtiski, taču kompromisiem ir jābūt redzamiem.

  • Metadatu atkarība: maršrutēšanas kvalitāte ir atkarīga no precīzām uzdevumu etiķetēm un darba slodzes metadatiem. Trūkstošās etiķetes novirza trafiku uz konservatīviem noklusējuma iestatījumiem.
  • Eval uzturēšana: uzdevumu evals ir jāatjaunina, jo mainās uzvednes, produkti un lietotāju uzvedība.
  • Pakalpojumu sniedzēja sarežģītība: kešatmiņas un pakešu atlaides var uzlabot ekonomiku, bet padarīt maršrutēšanas loģiku sarežģītāku.
  • Pārnesamības risks: pakalpojumu sniedzēja funkcijām ir jāatrodas adapteros un iespēju ierakstos, nevis produkta kodā.
  • Aplēsts nenoteiktība: galīgais izvades garums, rīku izsaukumi, atkārtojumi un kešatmiņas trāpījumi pirms izpildes nav pilnībā zināmi.
  • Izskaidrojamības slogs: agresīva optimizācija var padarīt produkta darbību grūti izskaidrojamu, ja vien katrs lēmums netiek reģistrēts ar politikas versijas un iemeslu kodiem.

Ieviešanas kontrolsaraksts

  • Definējiet uzdevumu klases populārākajām LLM darbplūsmām pēc tēriņiem un ietekmes uz uzņēmējdarbību.
  • Izveidojiet novērtēšanas kopas un kvalitātes līmeņus katrai uzdevumu klasei.
  • Izveidojiet nodrošinātāja un modeļu iespēju reģistru.
  • Saglabājiet pašreizējās cenu tabulas un cenu modifikatorus pēc nodrošinātāja, modeļa un izpildes režīma.
  • Aprēķiniet ievades pilnvaras, paredzamās izvades pilnvaras, kešatmiņas piemērotību, pakešu piemērotību un atkārtotā mēģinājuma risku.
  • Pirms izmaksu optimizācijas filtrējiet kandidātus pēc pārvaldības ierobežojumiem.
  • Izvēlieties viszemāko izmaksu modeli tikai pēc tam, kad ir nodrošināta iespēja un kvalitāte.
  • Reģistrējiet atlasītos un noraidītos maršrutus ar iemesla kodiem.
  • Salīdzināt aptuvenās izmaksas ar norēķināto lietojuma un rēķinu datiem.
  • Pirms lētāku maršrutu reklamēšanas veiciet periodiskas atkārtošanas pārbaudes.
  • Kanāriju maršruta izmaiņas un definējiet atcelšanas aktivizētājus.
  • Pieprasīt derīguma termiņu manuālai ignorēšanai.

Secinājums

Praktiskais mērķis nav novirzīt katru pieprasījumu uz lētāku modeli. Mērķis ir pārtraukt pārmaksāt par ikdienas darbu, vienlaikus aizsargājot kvalitāti, līgumus, pārvaldības noteikumus un izskaidrojamību.

Izveidojiet maršrutētāju, pamatojoties uz uzdevumu klasēm, kvalitātes līmeni, pakalpojumu sniedzēja iespējām, izmaksu aprēķiniem un politiku žurnāliem. Pēc tam izvēlieties piemērotāko maršrutu ar viszemākajām izmaksām. Šis viens vārds “piemērots” ir tas, kas atšķir izmaksu ziņā atbilstošu maršrutēšanu no lētākā modeļa maršrutēšanas.

Saistīta informācija

FAQ

Bieži uzdotie jautājumi

Vai maršrutētājam, kas ir informēts par izmaksām, vienmēr vajadzētu izvēlēties lētāko modeli, kas atbilst prasībām?
Ne vienmēr. Pēc pārvaldības ierobežojumu, spēju prasību, kvalitātes zemāko līmeņu, paredzamo latentuma, budžeta politikas un riska kontroles piemērošanas tai jāizvēlas piemērotākais maršruts ar viszemākajām izmaksām. Modelis, kas iztur šauru pārbaudi, joprojām var nebūt piemērots regulētam nomniekam, straumēšanas darbplūsmai vai uzdevumam ar stingriem izvades līgumiem.
Cik bieži ir jāatjaunina maršrutēšanas novērtējumi?
Atjauniniet evals ikreiz, kad mainās uzvednes, shēmas, modeļu versijas, nodrošinātāja adapteri vai galvenie darba slodzes modeļi. Darbplūsmām, kas tērē lielus izdevumus vai ir liela ietekme, veiciet arī plānotos atkārtošanas novērtējumus, izmantojot jaunākos ražošanas paraugus, lai maršruta kvalitāte nemainītos klusi.
Kāda ir lielākā kļūda LLM izmaksu ziņā zinošā maršrutēšanā?
Lielākā kļūda ir uzskatīt bāzes marķiera cenu par visu lēmumu. Reālās maršruta izmaksas ir atkarīgas no ievades marķieriem, izvades garuma, kešatmiņā saglabāto marķieru darbības, pakešu piemērotības, atkārtošanas mēģinājumiem, rīku izsaukumiem, shēmas labošanas un kļūmju apstrādes. Pirms izmaksu ranžēšanas ir jāpiemēro kvalitātes un pārvaldības ierobežojumi.
Kur būtu jādzīvo maršrutēšanas politikai?
Maršrutēšanas politika parasti ietilpst vārtejas vai vadības plaknes slānī, kur ir pieejami nodrošinātāja iespēju ieraksti, nomnieku kārtulas, cenu tabulas, lietojuma analīze un audita žurnāli. Lietojumprogrammu komandas joprojām var nodot uzdevumu metadatus un ignorēt pieprasījumus, taču galīgajam politikas lēmumam ir jābūt centralizētam un versijai.