Azure AI Foundry Model Router
Azure AI Foundry model router je Foundry model deployment, který pro každý požadavek vybírá vhodný underlying velký jazykový model. V Siesta AI ho používejte stejně jako jiný Azure AI Foundry deployment name: nastavte Azure AI Foundry připojení, vyberte router deployment pro agenta, šablonu nebo workflow a provoz řiďte přes přístupy, analytiku a token limity v Siesta AI.
Hodí se tam, kde je workload smíšený. Jednoduché prompty mohou běžet na rychlejších a levnějších modelech, zatímco komplexní reasoning, orchestrace nástrojů nebo syntéza se může směrovat na silnější modely bez toho, aby uživatel vybíral model pro každý prompt.
Kdy model router použít
Model router použijte, když:
- agenti řeší jednoduché i komplexní požadavky,
- customer support nebo interní helpdesk má mnoho krátkých dotazů a občas složité případy,
- workflow obsahují klasifikaci, sumarizaci, RAG nebo tool-calling kroky,
- admini chtějí jeden deployment name místo mnoha modelových voleb pro jednotlivé agenty,
- záleží na optimalizaci nákladů, ale kvalita má zůstat spolehlivá u náročnějších promptů.
Přímý model deployment použijte místo routeru tehdy, když workflow musí vždy používat přesně jeden schválený model, potřebuje model-specific parametry u každého požadavku nebo má compliance rozhodnutí, které nedovoluje dynamický výběr modelu.
Nastavení deploymentu
- V Azure AI Foundry nasaďte model
model-router. - Vyberte typ deploymentu podle požadavků na data residency a throughput.
- Začněte s routing mode Balanced, pokud workload není jednoznačně cost-sensitive nebo quality-critical.
- Volitelně zapněte Route to a subset of models, pokud chcete omezit pool modelů.
- V Siesta AI vyberte Azure AI Foundry jako model provider a použijte název router deploymentu, například
model-router.
Pro běžné použití routeru není potřeba nasazovat každý supported underlying model zvlášť. Microsoft dokumentuje Claude jako speciální případ: Claude modely musí být nasazené předem, aby mohly být součástí router subsetu. Před finálním produkčním subsetem vždy ověřte aktuální Microsoft seznam podporovaných modelů.
Routing modes
| Režim | Kdy použít | Provozní doporučení |
|---|---|---|
| Balanced | Většina produkčních agentů a smíšené workloady | Výchozí startovací bod. Nejdřív sledujte provoz, potom upravujte. |
| Quality | Kritické výstupy, komplexní reasoning, právní nebo riziková kontrola, náročná RAG syntéza | Počítejte s vyššími náklady. Použijte pro agenty, kde je kvalita důležitější než úspora. |
| Cost | High-volume klasifikace, triage, jednoduché Q&A, drafty nebo dávkové úlohy | Použijte jen tam, kde je malý tradeoff v kvalitě akceptovatelný. Sledujte negativní feedback. |
Změny routing mode nebo model subsetu se v Azure AI Foundry mohou projevit až po několika minutách.
Model subsets
Model subset je nejbezpečnější způsob, jak chování routeru sladit se zákaznickou politikou. Berte ho jako compliance a provozní hranici:
- zahrňte jen modely schválené zákazníkem nebo security týmem,
- ponechte v subsetu alespoň dva modely, aby routing a failover stále měly hodnotu,
- vyřaďte preview nebo partner modely, pokud je zákazník výslovně neschválil,
- zvedněte minimální context-window tím, že vyberete jen modely schopné obsloužit očekávanou velikost promptu,
- subset znovu zkontrolujte, když Microsoft přidá nové podporované modely.
Nové modely nepovažujte za schválené jen proto, že je router podporuje. Přidávejte je záměrně po kontrole bezpečnosti, kvality a nákladů.
Doporučené profily
U enterprise zákazníků vytvářejte oddělené router deploymenty místo jednoho deploymentu s nejasným účelem:
| Deployment | Routing mode | Typický subset | Použití |
|---|---|---|---|
router-balanced | Balanced | Schválené general-purpose a reasoning modely | Výchozí agenti, interní asistenti, smíšený chat |
router-quality | Quality | Silnější reasoning a synthesis modely | Právní, finanční, executive nebo komplexní RAG práce |
router-cost | Cost | Menší schválené modely | Triage, klasifikace, jednoduché Q&A, high-volume workflow |
V Siesta AI přiřaďte profil podle typu agenta nebo workflow. Uživatelům tím zůstane jednoduché prostředí a adminům kontrola.
Data residency
Typ deploymentu je důležitější než samotný název routeru:
- Global Standard může zpracovávat inference traffic v libovolném Azure regionu, kde je vybraný model dostupný. Použijte ho, když zákazník akceptuje globální zpracování a chce širší dostupnost a vyšší výchozí kvóty.
- Data Zone Standard zpracovává prompty a odpovědi jen v Microsoft-defined data zone, například v EU nebo US data zone. Použijte ho, když zákazník potřebuje data-zone residency.
- Regional Standard zpracovává požadavky v deployment regionu, pokud je podporovaný. Použijte ho pro přísnější regionální požadavky s tím, že dostupnost modelů a kvót může být užší.
Data uložená at rest zůstávají v zákazníkem určené Azure geografii podle Microsoft Foundry data-residency závazků. Prompty a completions pro Models sold by Azure nejsou dostupné OpenAI ani jiným model providerům a nepoužívají se k trénování foundation modelů bez svolení nebo instrukce zákazníka.
Pokud se EU zákazník ptá, jestli data mohou jít do United States, neodpovídejte jen podle routing mode. Zkontrolujte Azure deployment type. Pokud jde o Global Standard, inference processing může probíhat globálně. Pokud to není přijatelné, použijte EU Data Zone deployment, kde je požadovaný router a model subset podporovaný.
Observability
Používejte tři vrstvy evidence:
- Azure AI Foundry playground: testujte prompty a sledujte, který underlying model byl vybraný.
- API response: pole
modelidentifikuje underlying model, který požadavek obsloužil. - Azure Monitor a Azure Cost Management: filtrujte podle model router deploymentu a podle možností rozdělte metriky podle underlying modelu.
V Siesta AI používejte Analytics Cost grafy a token limity pro sledování usage modelového připojení podle agenta, model connection, týmu a uživatele. Pro distribuci underlying modelů v routeru používejte jako source of truth Azure Monitor.
Doporučení pro customer care
Když model router doporučujete zákazníkům, popisujte ho jako modelovou strategii:
- uživatelé mají vybírat správného agenta, ne model pro každý prompt,
- admini mají jednou schválit model subset a nechat routing řešit per-request výběr,
- začněte v Balanced mode, sledujte provoz a potom oddělte kritické nebo high-volume workloady do Quality nebo Cost router deploymentů,
- kombinujte router s token limity, review feedbacku a agent analytics v Siesta AI,
- dokumentujte deployment type, aby šla jasně zodpovědět data residency otázka.
Neslibujte fixní úspory. Úspora závisí na mixu workloadu, délce promptů, tool usage, vybraném subsetu a aktuálním Azure pricingu.
FAQ
Podle čeho router rozhoduje?
Microsoft dokumentuje, že model router analyzuje požadavek v reálném čase, včetně system message, user message, conversation history, tool definitions, typu úlohy, komplexity a routing mode. Potom vybere eligible underlying model z nakonfigurovaného poolu.
Musí být nasazené všechny podporované modely?
Ne. Pro běžné použití Microsoft balí router jako jeden deployment a vyvolává podporované underlying modely. Claude modely jsou dokumentovaná výjimka a před zahrnutím do routingu musí být nasazené.
Vidí admini, který model byl použitý?
Ano. Foundry playground a API response ukazují vybraný underlying model. Azure Monitor lze použít pro kontrolu routing distribution a performance podle deploymentu a underlying modelu.
Co když router vybere nečekaný model?
Zkontrolujte routing mode a model subset. Pokud zákazník model neschvaluje, odeberte ho ze subsetu nebo vynucujte schválené modely přes Azure Policy. Pokud workload potřebuje jeden přesný model, použijte přímý deployment místo model routeru.
Jak nastavovat token limity?
V Siesta AI nastavte token limity na model connection, která ukazuje na router deployment. Router berte jako jedno sdílené modelové připojení pro budget enforcement a pro hlubší cost analýzu underlying modelů použijte Azure Cost Management.
Co může způsobit vysokou latenci?
Latence může vznikat kvůli router overheadu, vybranému underlying modelu, dlouhým promptům, tool calls, RAG retrievalu nebo regionální kapacitě. U jednoduchých high-volume workloadů otestujte Cost mode. Pro předvídatelný high-throughput provoz zvažte provisioned deployment možnosti v Azure.
Co může způsobit quota errors?
Router deploymenty pořád používají Azure quota a rate limity. Pokud dochází k throttlingu, navyšte kvótu, snižte concurrency, použijte retry s backoffem nebo rozdělte traffic přes zkontrolované deploymenty, pokud to Azure architektura umožňuje.
Užitečné odkazy
- Microsoft model router guide: Use model router for Microsoft Foundry
- Microsoft concept guide: Model router for Microsoft Foundry
- Microsoft routing details: How model router works
- Microsoft deployment types: Deployment types for Microsoft Foundry Models
- Microsoft data privacy: Data, privacy, and security for Models sold by Azure