Nvidia Switchyard: AI-router sænker

Nemotron 3.5 Lightning er bygget til at være hurtig og billig i drift, ikke til at vinde benchmarks mod de største modeller på markedet. Den er tænkt som arbejdshesten i de trin, hvor opgaven er rutine: at hente data, formatere et svar, klassificere en besked eller udføre et simpelt værktøjskald. Switchyard er det lag, der beslutter, hvornår Lightning er nok, og hvornår en opgave skal eskaleres til en større, dyrere model.

Det er selve kombinationen, der er pointen. En lille model alene løser ikke komplekse ræsonnementer godt nok til produktion. En stor model alene er unødvendigt dyr til at hente et telefonnummer eller opsummere en mail. Ved at sætte en router foran hele modelparken kan man lade hvert trin i en agentkæde blive løst af den model, der reelt matcher sværhedsgraden, i stedet for at hele kæden trækker på den dyreste ressource af vanens magt.

Switchyard evaluerer hvert trin i en agents arbejdsgang, før det sendes videre, og vurderer, om opgaven kræver dyb kontekstforståelse og flertrins-ræsonnement, eller om den kan klares af en hurtigere model. Vurderingen sker løbende, ikke én gang for hele opgaven, så en enkelt agentsession kan sagtens skifte model flere gange undervejs. Et forespørgselstrin, der beder om at hente strukturerede data, kan gå til Lightning. Et trin, der kræver at afveje modstridende informationer og formulere en anbefaling, kan blive eskaleret til en tungere model.

Den mekanik ligner i praksis, hvordan mange udviklingsteams allerede forsøger at styre omkostninger manuelt, ved at hardkode regler for, hvornår en billig model er god nok. Forskellen er, at Switchyard gør det dynamisk og indbygget i selve orkestreringslaget, så teamet ikke skal vedligeholde de regler selv, efterhånden som opgaverne og modellerne ændrer sig.

I Nvidias egne tests af opsætningen faldt omkostningerne per løst agentopgave til omkring en tredjedel af, hvad det kostede at køre den samme opgave udelukkende på en stor model. Besparelsen kommer ikke fra en enkelt optimering, men fra at fjerne den unødvendige dyre model fra de trin, hvor den aldrig var nødvendig i første omgang.

Størrelsen af besparelsen vil naturligt variere med, hvor mange trin i en given arbejdsgang der reelt er rutineopgaver. En kundeserviceagent, der for det meste slår op i en videnbase og formulerer standardsvar, har potentiale for store besparelser. En agent, der løser komplekse juridiske eller finansielle vurderinger i næsten alle trin, vil naturligt eskalere oftere og se en mindre gevinst. Det er derfor mere retvisende at tænke på Switchyard som en mekanisme, der fjerner spild, end som en garanteret rabat på tværs af alle opgavetyper.

Det er et mønster, jeg ser igen og igen: mange organisationer lander på én model til hele arbejdsgangen, fordi det er den simple løsning at implementere, ikke fordi det er den billigste at drive. I mine egne agenter hos Agent Enterprise har jeg flyttet flere trin over til lettere modeller, fordi det simpelthen er billigere at lade den lette model tage de trin, den rent faktisk kan klare, i stedet for at lade den tungeste model køre hele vejen igennem af vane. Model-routing som Switchyard peger på den samme vej: design agenter til at bruge flere modeller bevidst, i stedet for at vælge én model og leve med, at den koster mest på hvert eneste trin.

For virksomheder, der allerede har agenter i produktion, er den mest umiddelbare pointe ikke nødvendigvis at skifte til Nvidias stak, men at spørge sig selv, om deres nuværende arkitektur reelt matcher modelstyrke til opgavesværhedsgrad. Mange agentsystemer i drift i dag bruger den samme model til at klassificere en simpel besked og til at ræsonnere sig frem til en kompleks anbefaling. Det er præcis den type spild, som routing-lag som Switchyard er designet til at fjerne, og det er et princip, man kan begynde at anvende uafhængigt af, hvilken modelleverandør man i øvrigt bruger.

Den praktiske konsekvens for teams, der bygger eller vedligeholder agentsystemer, er, at modelvalg ikke længere bør være en beslutning, man tager én gang for hele arbejdsgangen. Det bør være en beslutning, man tager per trin, og som løbende kan justeres, efterhånden som nye og billigere modeller kommer til. Det kræver en anden måde at designe agentarkitektur på, men det er en investering, der typisk betaler sig hurtigt tilbage i lavere driftsomkostninger, når agenterne først kører i stor skala.