NeMo Switchyard er en open source-router, der fordeler de enkelte trin i en AI-agents arbejde mellem forskellige sprogmodeller. Målet er at bruge en mindre model til rutineopgaver og eskalere svære trin til en stærkere model, men de dokumenterede besparelser ledsages af målbar lavere nøjagtighed.
NeMo Switchyard fordeler trinene i en AI-agents arbejde mellem forskellige sprogmodeller for at afveje pris, kvalitet og svartid. Løsningen kan reducere modeludgifter, men de offentliggjorte test viser også lavere nøjagtighed og understreger behovet for egne evalueringer, tydelige datagrænser og kontrol med leverandørkæden.
Hvad er NeMo Switchyard?
NVIDIA offentliggjorde NeMo Switchyard den 11. august 2026 som software til modelrouting i agentiske arbejdsgange. En router ligger mellem et program og de tilgængelige modeller. Den vælger en model for hver forespørgsel eller hvert arbejdstrin ud fra blandt andet opgavens sværhedsgrad, pris, svartid og tidligere hændelser i sessionen.
Switchyard kan køre som proxy, indlejres som bibliotek eller forbindes med en eksisterende agentplatform. Projektet oversætter også mellem OpenAI Chat Completions, OpenAI Responses og Anthropic Messages, så en klient kan beholde sit API-format, selv om en anden modelleverandør behandler forespørgslen. Kildekoden er udgivet under Apache 2.0-licensen.
Hvordan fungerer modelrouting i praksis?
En almindelig AI-arbejdsgang kan bestå af meget forskellige trin. Agenten skal måske først læse en fil, derefter undersøge en fejl, vælge en handling og til sidst kontrollere resultatet. Hvis alle trin sendes til den dyreste model, kan rutinearbejdet blive unødigt dyrt. Hvis alle trin sendes til en lille model, kan kvaliteten falde på de vanskelige dele.
Switchyard løser ikke opgaverne selv. Routeren vurderer i stedet signaler fra forespørgslen, agentens værktøjskald, fejlforløbet eller en særskilt bedømmelsesmodel. Derefter sender den arbejdet til et mål i en konfigureret modelpulje. Systemet kan bevare en beslutning gennem en session eller vurdere hvert trin på ny.
Hvilke routertyper følger med?
| Router | Beslutningsgrundlag | Central afvejning |
|---|---|---|
| LLM-klassifikator | En model klassificerer opgaven og vælger mål | Fleksibel, men kræver et ekstra modelkald |
| Stage-router | Værktøjsaktivitet, fejl og arbejdets fase | Lav ekstra latenstid, men afhænger af tydelige signaler |
| Eskaleringsrouter | En billig model starter, og en bedømmer følger fremdriften | Sparer dyre kald, men kan reagere efter et fejlslagent trin |
| Prefill-router | Lærte signaler fra en models interne repræsentation | Kan tilpasses en arbejdsbyrde, men er fortsat forskningspræget |
De forskellige metoder er ikke udskiftelige. En stage-router passer bedst til længere agentforløb med mange synlige værktøjskald, mens klassifikation kan bruges på opgaver, hvor selve forespørgslen afslører domæne eller sværhedsgrad. Eskalation giver mest mening, når en mindre model kan udføre hovedparten af arbejdet, men vanskelige forløb skal kunne flyttes til en stærkere model.
Hvad viste benchmarktesten?
LangChain afprøvede eskaleringsrouting på 145 flertrinsopgaver med kundeservice, hændelsesundersøgelse, filoperationer, værktøjsbrug og automatisering på tværs af systemer. Routeren fordelte kald mellem NVIDIA Nemotron 3.5 Lightning og Claude Opus 4.8. Kun 7 procent af modelkaldene gik til frontiermodellen.
Den routede løsning kostede 74 procent mindre end at bruge Claude Opus 4.8 til alle kald. Nøjagtigheden faldt samtidig fra 86,0 til 80,0 procent, altså cirka seks procentpoint. Den lille model alene nåede 77,7 procent til en endnu lavere pris. Testen dokumenterer derfor en afvejning mellem pris og kvalitet, ikke en gratis effektivitetsgevinst.
Bedømmelsesmodellen stod desuden for 21,2 procent af udgiften i den routede opsætning. Andelen af dyre kald varierede mellem 4,1 og 9,1 procent på tværs af fem kørsler, og prisen svingede tilsvarende. Tallene gælder denne modelkombination og dette kontrollerede opgavesæt; de kan ikke overføres direkte til en anden organisations trafik.
Hvad kan modelrouting bruges til?
Modelrouting er især relevant i lange forløb, hvor en AI-agent eller et multiagentsystem foretager mange kald med forskellig sværhedsgrad. Det kan eksempelvis være softwareudvikling, intern søgning, sagsforberedelse eller automatiseret drift, hvor simple opslag optræder side om side med analyse og fejlhåndtering.
- Rutineprægede trin kan sendes til en mindre og billigere model.
- Fejl, gentagelser eller komplekse spørgsmål kan udløse en stærkere model.
- Routingloggen kan registrere valgt model, begrundelse, tokenforbrug, latenstid og resultat.
Fordelen ligger også i udskiftelighed. Fordi modelnavn, leverandørforbindelse og routinglogik kan holdes adskilt, kan et team ændre model eller endpoint uden at omskrive hele agentens integration. Det kræver dog fortsat test, fordi en ny model kan reagere anderledes på prompts, værktøjer og strukturerede svar.
Hvordan adskiller routing sig fra en AI-agent?
En AI-agent planlægger eller udfører handlinger ved hjælp af modeller og værktøjer. En router vælger, hvilken model der skal håndtere et bestemt kald. Switchyard er derfor et infrastrukturlag omkring agenten, ikke en færdig agent, en ny sprogmodel eller et system, der selv afgør forretningsregler.
Skellet har praktisk betydning. En router kan reducere omkostninger og gøre modelvalg mere fleksibelt, men den gør ikke agentens værktøjsadgang, databehandling eller svar korrekte. Adgangskontrol, afgrænsning af handlinger og menneskelig godkendelse skal stadig bygges ind i den samlede løsning.
Hvilke begrænsninger har Switchyard?
NVIDIAs eget kodearkiv betegner Switchyard som pre-alpha, forventer væsentlige API-ændringer før version 1.0 og advarer mod produktionsbrug. Det er en skarpere afgrænsning end blogindlæggets brede beskrivelse af produktionsnære integrationer. Organisationer bør derfor behandle projektet som eksperimentel software, selv om enkelte routingmetoder allerede er afprøvet med partneres arbejdsgange.
Routing tilføjer også nye fejlkilder. Klassifikatoren kan vælge den forkerte model, en eskalation kan komme for sent, og et ekstra bedømmelseskald kan øge både latenstid og pris. Korte opgaver giver desuden få signaler til en eskaleringsrouter. Ved meget ens modelpriser kan udgiften til bedømmelse overstige besparelsen.
Hvad betyder udviklingen for arbejdspladser?
For udviklingsteams og vidensarbejdspladser ændrer modelrouting spørgsmålet fra “hvilken model bruger vi?” til “hvilken model må bruges til hvilket trin?” Det kan give mere præcis omkostningsstyring, men kræver også fælles grænser for kvalitet, svartid, følsomme data og godkendelse af resultater.
En intern AI-politik kan derfor beskrive tilladte modelmål, hvilke datatyper der må sendes til dem, og hvornår et resultat skal kontrolleres af et menneske. Den dokumenterede benchmarkforskel viser, hvorfor en lavere pris ikke bør bruges som eneste succeskriterium. Fejlomkostningen afhænger af opgaven.
Hvordan påvirker routing data og GDPR?
En modelrouter kan sende forskellige dele af samme session til flere leverandører. Prompts, tidligere svar, værktøjsresultater og fejlbeskeder kan dermed bevæge sig gennem en længere leverandørkæde end ved brug af én model. Den konkrete behandling afhænger af konfiguration, aftaler, logning og de valgte endpoints; open source-kode gør ikke i sig selv dataflowet lokalt.
Datatilsynet skriver om cloudløsninger, at den dataansvarlige skal have overblik over hele leverandørkæden og de behandlinger, der foregår. Når modelrouting ændrer, hvem der modtager personoplysninger, eller hvordan de behandles, kan risikovurdering, databehandleraftaler og grundlaget for eventuelle tredjelandsoverførsler derfor skulle gennemgås igen. Den praktiske kontrol minder om kravene ved beskyttelse af data i AI-API’er, men nu for flere mulige modelmål.
Hvilke styringsspørgsmål følger med?
AI Act-vurderingen afhænger af det samlede systems formål og brug, ikke af at infrastrukturen hedder Switchyard. En router kan indgå i både lavrisiko-værktøjer og systemer med strengere krav. Hvis en agent bruges til beslutninger om mennesker, offentlige ydelser, uddannelse eller andre regulerede områder, skal organisationen vurdere den konkrete rolle som udbyder eller idriftsætter og de relevante krav til dokumentation, menneskeligt tilsyn og information.
Routinglogge kan støtte sporbarhed, fordi de viser modelvalg og driftsdata. De er dog ikke automatisk dokumentation for, at valget var fagligt forsvarligt. En brugbar log skal kunne forbindes med opgavens risikoniveau, den anvendte version, evalueringsresultater og organisationens beslutning om acceptable fejl.
Hvad bør testes før praktisk brug?
- Mål kvalitet, pris og latenstid på egne repræsentative opgaver i stedet for at genbruge partnerbenchmarkens procentsatser.
- Sammenlign routing med både frontiermodellen og den billige model alene.
- Kontrollér, hvilke prompts, værktøjsresultater og logs hvert endpoint modtager og opbevarer.
- Test fejlvalg, eskalation, leverandørudfald og tilbagefald til en sikker standardmodel.
- Fastlæg, hvilke opgaver der kræver menneskelig kontrol, uanset hvilken model routeren vælger.
En afgrænset pilot kan vise, om der faktisk findes nok lette kald til at betale for routinglaget. Hvis en enkelt mindre model allerede løser opgaven tilfredsstillende, kan den enklere arkitektur være både billigere og lettere at styre.
Hvilke kilder ligger til grund?
Den primære kilde er NVIDIAs lancering og tekniske gennemgang af NeMo Switchyard. Projektets modenhed, licens og API-formater er kontrolleret i det officielle Switchyard-kodearkiv, mens resultater og forbehold stammer fra LangChains benchmarkrapport. Den lokale databeskyttelsesvinkel bygger på Datatilsynets cloudvejledning, og AI Act-afgrænsningen følger EU-Kommissionens oversigt over roller og forpligtelser.