Nvidia entra nel mercato del model routing con NeMo Switchyard

Nvidia è entrata nel mercato del model routing con NeMo Switchyard, aggiungendo un nuovo livello software a un settore già affollato di gateway, proxy e sistemi di routing personalizzati. Il lancio è arrivato su Google News insieme agli ultimi annunci di modelli di Nvidia, ma la sfida va oltre il semplice lancio di un prodotto. Nvidia vuole influenzare quale modello AI gestisce ogni richiesta, non limitarsi a fornire l'hardware sottostante.

Switchyard è un proxy open source che si colloca tra un'applicazione e più backend di modelli. Può tradurre formati API, classificare le richieste, mantenere l'affinità delle conversazioni, raccogliere dati di utilizzo e inviare chiamate diverse a modelli diversi. Un agente di coding potrebbe riservare un modello avanzato alla pianificazione o al recupero dagli errori, per poi usare un modello efficiente per le modifiche di routine.

Questo design mette in discussione l'abitudine dominante di assegnare un unico modello a un'intera applicazione o sessione di agente. Mette inoltre Nvidia in competizione con gateway per modelli, piattaforme cloud, router open source e sistemi interni di orchestrazione che le aziende già gestiscono. La questione centrale è se Nvidia riuscirà a rendere la selezione automatizzata dei modelli abbastanza affidabile per il lavoro in produzione.

Nvidia è salita al di sopra dell'endpoint del modello

Switchyard trasforma la selezione del modello da impostazione dell'applicazione a politica operativa.

Secondo la sua documentazione di progetto, Switchyard accetta richieste nei formati API di OpenAI e Anthropic. Applica quindi una politica di routing prima di inoltrare ogni richiesta a un backend configurato. Il backend può essere un provider in hosting, un servizio Nvidia NIM, un endpoint privato, vLLM o un server locale come Ollama.

Questa collocazione conta. Le applicazioni di solito indicano direttamente un modello, mentre gli sviluppatori gestiscono le differenze tra provider nel proprio codice o tramite un proxy di base. Switchyard inserisce un punto decisionale programmabile tra questi due livelli. L'applicazione continua a parlare un'API familiare, mentre il router decide dove inviare la richiesta.

Il software include diversi schemi di routing. I team possono distribuire il traffico casualmente per test comparativi, usare un classificatore LLM, creare logiche di routing personalizzate o applicare una strategia consapevole delle fasi. Possono anche bypassare il routing e selezionare un modello quando un percorso deterministico conta più dell'ottimizzazione.

Il router per fasi di Switchyard è la parte più importante del lancio. Valuta i segnali dell'attività recente di un agente e sceglie tra livelli di modelli capaci ed efficienti. La guida al routing di Nvidia descrive esplorazione, ragionamento complesso e recupero dagli errori come attività per modelli più potenti. L'esecuzione più meccanica può invece passare al livello efficiente.

Non equivale a instradare ogni prompt dell'utente in base all'argomento. I carichi di lavoro degli agenti comprendono molte chiamate all'interno di un'attività e la difficoltà cambia man mano che l'attività procede. Un agente di coding potrebbe aver bisogno di un ragionamento più solido mentre ispeziona un repository sconosciuto. Una volta formulato un piano, gli aggiornamenti dei file e le trasformazioni strutturate possono richiedere meno capacità.

Switchyard prende quindi decisioni di routing all'interno di una sessione, non soltanto al suo avvio. Può mantenere i turni correlati sullo stesso backend tramite l'affinità di sessione, continuando al contempo a supportare fallback configurati. Questa combinazione affronta un problema pratico: cambiamenti senza restrizioni possono danneggiare la continuità quando i modelli interpretano il contesto in modo diverso.

Il router traduce anche tra protocolli di provider. Un client progettato intorno alla Messages API di Anthropic può raggiungere un backend compatibile con OpenAI senza riscrivere l'integrazione del client. Switchyard normalizza la richiesta, seleziona una destinazione, converte il payload e restituisce una risposta nella forma prevista dal client.

Questa traduzione amplia il ruolo di Nvidia. L'azienda non si presenta più soltanto con un endpoint ottimizzato per modelli ospitati da Nvidia. Sta offrendo software che può operare al di sopra di modelli di diversi provider, inclusi modelli che competono con il portafoglio di Nvidia.

La copertura di Google News ha presentato la mossa come l'ingresso di Nvidia in un mercato molto attivo. Il cambiamento più rilevante è architetturale. Nvidia sta cercando di rendere il proprio software parte della decisione che precede ogni chiamata di inferenza, anche quando il modello scelto è fornito da un'altra azienda.

Perché il model routing è diventato un terreno di scontro sui costi

I flussi di lavoro degli agenti hanno reso sempre più difficile giustificare l'approccio di un modello per sessione.

Un chatbot convenzionale genera spesso una risposta per una richiesta dell'utente. Un agente può ispezionare file, chiamare strumenti, rivedere un piano, recuperare da errori, convalidare l'output e produrre una risposta finale. Ogni passaggio può attivare un'altra chiamata al modello, mentre la cronologia della conversazione continua a crescere.

Usare il modello più capace disponibile per ogni passaggio semplifica l'ingegnerizzazione. Tuttavia, applica il livello più alto di ragionamento ad attività che possono consistere nel formattare JSON, riassumere l'output degli strumenti o modificare una stringa nota. Su larga scala, queste chiamate ripetute creano pressione per allineare la capacità del modello alla difficoltà effettiva dell'attività.

L'approccio opposto crea un altro problema. I team possono scrivere regole manuali che instradano i prompt in base al tipo di attività, alla lunghezza, al gruppo di utenti o allo stato dell'applicazione. Queste regole diventano infrastruttura che richiede test, monitoraggio e adeguamenti ogni volta che modelli o flussi di lavoro cambiano.

Un'analisi di InfoWorld sul model routing ha descritto questo livello emergente come un modo per variare l'uso dei modelli in base ai requisiti dei prompt. La logica di fondo è semplice. Non ogni richiesta merita lo stesso modello, ma qualcuno deve effettuare la selezione in modo affidabile.

Switchyard cerca di trasformare questa decisione in infrastruttura riutilizzabile. Il suo router per fasi esamina i segnali relativi agli strumenti nella conversazione attiva. I team configurano due destinazioni, stabiliscono il comportamento di routing e misurano il traffico risultante per livello di modello.

Il sistema può usare un classificatore per i turni incerti, ma la classificazione è facoltativa. La documentazione di Nvidia raccomanda di iniziare con i segnali degli strumenti, perché chiamare un altro modello per classificare ogni richiesta introduce latenza, costi e un ulteriore punto di errore. Un classificatore può essere limitato ai casi in cui il router non dispone di sufficiente confidenza.

Questa distinzione è importante per le implementazioni aziendali. Un router che riduce il consumo dei modelli ma aggiunge un'altra chiamata al modello a ogni turno può perdere parte del proprio vantaggio. Un router che si basa solo su regole fisse potrebbe restare veloce, ma non cogliere i cambiamenti nella difficoltà dell'attività.

Il mercato è già andato oltre la semplice distribuzione dei prompt. I gateway AI forniscono comunemente limiti di frequenza, fallback, logging, applicazione delle policy e astrazione dei provider. Una discussione di CIO sugli AI gateway cita il model routing come una parte di un più ampio livello di controllo aziendale.

Ciò significa che Nvidia non sta creando una categoria vuota. Sta entrando in un livello conteso in cui i clienti potrebbero già usare gateway commerciali, controlli cloud-native o progetti open source. Alcune organizzazioni hanno inoltre costruito sistemi di routing privati attorno ai propri dati di valutazione e alle proprie regole aziendali.

L'opportunità di Switchyard deriva dal numero crescente di applicazioni multi-modello. Le aziende combinano sempre più spesso un modello generale di ragionamento con modelli più piccoli, modelli privati ed endpoint specializzati. Una volta disponibili varie opzioni, la selezione diventa una questione operativa anziché una preferenza dello sviluppatore.

La sua sfida deriva dalla stessa diversità. Ogni organizzazione definisce la qualità in modo diverso. Un instradamento corretto per l'assistenza clienti può essere sbagliato per la generazione di codice, l'analisi di sicurezza o la revisione dei contratti. Costi e latenza sono misurabili, ma la qualità a livello di attività richiede spesso valutazioni specifiche per il dominio.

L'attenzione di Google News può creare consapevolezza, ma l'adozione dipenderà da queste misurazioni. Gli acquirenti vorranno prove che il routing produca risultati accettabili sui propri prompt, strumenti, casi di errore e confini di conformità.

Switchyard contrappone il routing guidato dalle policy alla scelta fissa del modello

La competizione principale non è Nvidia contro un singolo fornitore di gateway. È il routing dinamico contro la prevedibilità di un modello fisso.

Un percorso basato su un modello fisso presenta vantaggi evidenti. I team sanno quale provider riceve i loro dati, quale comportamento valutare, quale finestra di contesto si applica e dove indagare sui guasti. Gli aggiornamenti dei modelli introducono comunque variazioni, ma il percorso della richiesta resta relativamente semplice.

Il routing dinamico scambia parte di questa semplicità con l'efficienza. L'applicazione può chiamare modelli diversi durante lo stesso flusso di lavoro. Un modello capace gestisce il ragionamento difficile, mentre un modello efficiente elabora i turni di routine. Il sistema può anche effettuare il failover quando una destinazione non è disponibile o non può accettare il contesto corrente.

L'architettura di Switchyard separa normalizzazione delle richieste, routing, esecuzione e traduzione delle risposte. Questa separazione consente agli sviluppatori di sostituire la policy di routing senza modificare l'integrazione rivolta al client. Rende inoltre la decisione di routing un componente osservabile anziché una logica applicativa nascosta.

Il router per fasi va oltre, trattando l'esecuzione di un agente come una sequenza di condizioni mutevoli. I risultati recenti degli strumenti, gli errori e i segnali della conversazione influenzano quale livello riceve la richiesta successiva. Questo approccio riconosce che la difficoltà esiste a livello di turno, non solo a livello di applicazione.

Consideriamo un agente di manutenzione software. Può iniziare esplorando un repository, individuando i moduli pertinenti e interpretando test non familiari. Queste azioni beneficiano di un ragionamento più solido. Dopo aver identificato una correzione circoscritta, diverse modifiche e passaggi di convalida possono seguire un modello chiaro.

Una configurazione a modello fisso invia entrambe le fasi allo stesso endpoint. Un router consapevole delle fasi può riservare la propria destinazione più potente all'esplorazione e al recupero, per poi spostare il lavoro di routine verso la destinazione efficiente. Se la convalida fallisce, il router può riportare le chiamate successive verso il livello più capace.

Questo meccanismo offre maggiore flessibilità rispetto all'assegnazione di un modello al “coding” e di un altro alla “scrittura”. Crea però anche più modi in cui gli errori di routing possono influire sul risultato finale. Un modello debole selezionato troppo presto potrebbe fraintendere un vincolo, produrre una modifica difettosa o nascondere un errore dietro un output plausibile.

Le conseguenze non sono sempre visibili nel turno instradato. Un piccolo errore può rimanere nel contesto e influenzare le chiamate successive. La risposta finale può sembrare coerente perché un modello più potente ha corretto la presentazione senza individuare il difetto sottostante.

Per questo il model routing non può essere giudicato soltanto in base all'uso aggregato dei token o alla latenza media. I team necessitano di valutazioni a livello di attività che verifichino se l'intero flusso di lavoro ha avuto successo. Necessitano inoltre di tracce che colleghino ogni decisione di routing alle chiamate agli strumenti, agli output, ai tentativi ripetuti e al risultato finale.

Switchyard espone statistiche per richiesta su latenza, consumo di token e costo stimato. La documentazione del router per fasi descrive inoltre statistiche specifiche per livello. Queste misurazioni aiutano gli operatori a comprendere con quale frequenza è stato selezionato ciascun modello e dove è cambiato il comportamento di routing.

Tuttavia, l'osservabilità non stabilisce automaticamente la correttezza. Una dashboard può mostrare che un modello efficiente ha gestito la maggior parte delle chiamate, ma non può determinare se un riepilogo legale ha omesso una clausola. Tale giudizio richiede un set di valutazione o un altro affidabile test di accettazione.

L'approccio a modello fisso rimane quindi un'alternativa significativa. È più facile da spiegare, riprodurre e sottoporre ad audit. Il routing dinamico prevale solo quando il beneficio in termini di efficienza supera il costo operativo di valutazione, debug e governance.

La strategia di Nvidia è ridurre tale costo operativo. Se Switchyard fornisce traduzione dei protocolli, schemi di routing comuni, statistiche e launcher, i team possono concentrarsi su policy e valutazione. Se questi componenti restano difficili da calibrare, le organizzazioni potrebbero continuare a usare modelli fissi per i flussi di lavoro importanti.

La decisione del router può diventare l'anello più debole

Il valore di Switchyard dipende dalla selezione del modello giusto senza trasformare il processo di selezione in un altro costoso carico di inferenza.

Nessun classificatore universale può conoscere la definizione di attività semplice di ogni organizzazione. Un prompt breve può richiedere conoscenze specialistiche, mentre un prompt lungo può richiedere un'estrazione meccanica. La cronologia degli strumenti può rivelare lo stato del flusso di lavoro, ma non può garantire che il turno successivo sia semplice.

I segnali basati sulla fase forniscono un contesto utile. L'esplorazione, gli insuccessi ripetuti e i tentativi di recupero spesso giustificano un modello più potente. Un uso stabile degli strumenti e un'implementazione ripetitiva possono indicare una fase ordinaria. Tuttavia, le esecuzioni reali degli agenti non seguono sempre una progressione pulita dal ragionamento all'esecuzione.

Una modifica dall'aspetto ordinario può avere conseguenze significative. Cambiare una regola di autorizzazione può richiedere solo poche righe, ma un errore sottile può esporre dati. Una lunga richiesta di sintesi può comportare rischi ridotti quando l'output viene sottoposto a revisione umana.

Le organizzazioni hanno quindi bisogno di policy di routing che tengano conto dell'impatto, non solo della difficoltà prevista. Le operazioni sensibili potrebbero usare sempre un modello approvato. Alcuni strumenti potrebbero richiedere un livello più capace, mentre le trasformazioni a basso rischio possono restare idonee al routing efficiente.

La traduzione tra provider rappresenta un'altra fonte di incertezza. Le API di OpenAI, Anthropic e quelle compatibili non espongono semantiche identiche. Chiamate agli strumenti, campi di ragionamento, comportamento dello streaming, output strutturati e risposte di errore possono differire tra i provider.

Switchyard mira a preservare il formato di risposta atteso dal client mentre comunica con un altro backend. Tale astrazione è utile, ma i team devono testare le funzionalità specifiche da cui dipendono i loro agenti. La compatibilità di protocollo non implica equivalenza comportamentale tra i modelli.

Anche i limiti di contesto complicano il routing. Un modello selezionato per efficienza potrebbe non accettare la sessione accumulata. Secondo la documentazione del suo stage-router, Switchyard supporta un comportamento di fallback configurato per l'overflow del contesto. I fallback preservano la disponibilità, ma possono modificare costo, latenza e caratteristiche dell'output.

C'è poi il classificatore stesso. Un classificatore LLM opzionale può aiutare con richieste incerte, ma aggiunge un'altra chiamata di rete. Nvidia avverte che la condivisione della capacità del provider tra il classificatore e un target efficiente può contribuire alla pressione sui limiti di frequenza.

Anche il classificatore richiede valutazione. Se invia frequentemente richieste semplici al livello più capace, i risparmi si riducono. Se invia lavoro difficile al livello efficiente, la qualità diminuisce. Una soglia modifica l'equilibrio, ma nessuna soglia elimina il compromesso.

La ricerca sul routing si è ripetutamente concentrata sul preservare la qualità riducendo al contempo la spesa per l'inferenza. Il progetto RouteLLM ha dimostrato che router appresi possono selezionare tra modelli più forti e più deboli usando dati di preferenza. I suoi risultati sottolineano anche un punto più ampio: le prestazioni del router dipendono dai dati di addestramento, dalla progettazione della valutazione e dalla coppia di modelli instradata.

Una policy calibrata per una coppia non si trasferirà automaticamente a un'altra. I provider aggiornano i modelli, i prompt evolvono e le applicazioni acquisiscono nuovi strumenti. I team hanno bisogno di valutazioni ricorrenti, non di un singolo benchmark completato prima del deployment.

Anche il rilascio è recente. Il suo repository pubblico elenca problemi noti, sviluppo attivo e un insieme crescente di componenti di routing. Questa apertura favorisce l'ispezione e la sperimentazione, ma non dimostra che ogni funzionalità sia matura per carichi di lavoro regolamentati o ad alto rischio.

Nvidia ha presentato Switchyard come infrastruttura indipendente dai modelli, ma il suo incentivo più ampio resta chiaro. Un'inferenza più efficiente può rendere economicamente sostenibili i deployment di agenti, aumentando la domanda dei sistemi di calcolo sottostanti. Il router può supportare provider concorrenti continuando al contempo ad ampliare il volume totale di lavoro IA.

Questo incentivo non invalida il prodotto. Spiega perché Nvidia si sta muovendo verso il software al di sopra dell'endpoint di inferenza. L'azienda beneficia quando i clienti eseguono più modelli, più agenti e più inferenza su una gamma più ampia di hardware.

L'interpretazione prudente è quindi più circoscritta rispetto al ciclo di titoli di Google News. Switchyard fornisce un toolkit credibile per sperimentare il traffico multi-modello. Il suo valore in produzione dipende ancora da evidenze specifiche per il carico di lavoro, che dimostrino che gli errori di routing restano entro limiti accettabili.

Nvidia sta espandendo la sua strategia di inferenza full-stack

Switchyard collega la scelta del modello al più ampio impegno di Nvidia per controllare una porzione maggiore dello stack operativo dell'inferenza.

La posizione di Nvidia nell'IA è iniziata con gli acceleratori e si è espansa attraverso networking, librerie ottimizzate, software per il serving dei modelli, pacchetti enterprise e modelli aperti. Un livello di routing estende questo stack verso il confine applicativo.

L'azienda offre già Nvidia NIM per pacchettizzare e servire modelli tramite endpoint standardizzati. Dynamo affronta la pianificazione dell'inferenza distribuita e il posizionamento delle richieste tra i worker. NeMo supporta lo sviluppo e la personalizzazione dei modelli. OpenShell fornisce un runtime controllato per i carichi di lavoro degli agenti.

Questi sistemi risolvono problemi di routing diversi. Il routing consapevole della KV di Dynamo seleziona un worker appropriato considerando lo stato della cache riutilizzabile e il carico attivo. Switchyard seleziona un modello o un backend in base a una policy a livello applicativo.

Questa distinzione è importante. Il routing dell'infrastruttura chiede dove una richiesta debba essere eseguita per un serving efficiente. Il routing dei modelli chiede quale modello debba ricevere la richiesta. Un deployment può usare entrambe le decisioni: Switchyard seleziona il modello, poi un sistema di serving sceglie il worker.

Il risultato è una catena più lunga di componenti gestiti da Nvidia. Un'impresa potrebbe costruire un agente con gli strumenti di NeMo, instradarne le chiamate tramite Switchyard, servire un modello aperto tramite NIM e pianificare l'inferenza con Dynamo su hardware Nvidia.

Perché questa strategia sia rilevante, Nvidia non ha bisogno che ogni richiesta utilizzi un modello Nemotron. Se Switchyard diventa un punto di controllo comune, Nvidia acquisisce influenza sul modo in cui gli sviluppatori valutano e gestiscono sistemi multi-modello. Può inoltre collegare tali scelte di routing al proprio stack di serving e osservabilità.

Questa è la vera pressione competitiva creata dal lancio. I fornitori di gateway si trovano ora di fronte a un nuovo concorrente open source ben finanziato dal principale fornitore di hardware IA. I provider cloud devono dimostrare perché i loro livelli nativi di routing e governance offrano più valore. Le aziende di modelli devono rendere i propri endpoint facili da valutare in deployment misti.

I progetti open source affrontano un confronto diverso. Molti forniscono già API unificate, logica di fallback, bilanciamento del carico e selezione dei modelli. Switchyard deve competere sulla qualità del routing, sulla consapevolezza degli agenti, sulla copertura dei protocolli e sulla chiarezza operativa, piuttosto che sulla semplice capacità di inoltrare una richiesta.

La sua licenza Apache 2.0 riduce la barriera alla sperimentazione. I team possono ispezionare il codice di routing, aggiungere policy personalizzate e distribuire il proxy vicino alle loro applicazioni. Questa flessibilità può interessare le organizzazioni che non vogliono che un gateway ospitato osservi ogni prompt.

L'auto-ospitazione trasferisce tuttavia la responsabilità. Gli operatori devono proteggere le credenziali, gestire gli aggiornamenti, conservare i log, monitorare il comportamento del routing e convalidare le integrazioni con i provider. L'open source cambia chi controlla il sistema, non il lavoro necessario per gestirlo in sicurezza.

Il vantaggio più forte di Nvidia potrebbe essere l'integrazione, piuttosto che un singolo algoritmo di routing. L'azienda può collegare Switchyard con modelli, server di inferenza, runtime per agenti e telemetria hardware. Un fornitore di router più piccolo può offrire una neutralità più ampia rispetto ai provider, ma non avere questa capacità ingegneristica end-to-end.

Il pericolo per i clienti è una concentrazione non necessaria dello stack. L'uso di un unico fornitore per sviluppo, routing, serving e calcolo può semplificare il supporto. Può anche aumentare i costi di cambiamento, anche quando i singoli componenti rimangono open source.

Il supporto di Switchyard per diversi provider aiuta a mitigare questa preoccupazione. La sua utilità dipenderà dal fatto che tali integrazioni restino di primo piano mentre Nvidia espande il progetto. I clienti dovrebbero testare i backend non Nvidia con la stessa attenzione riservata a quelli ospitati da Nvidia.

La mossa dell'azienda non risolve il mercato dei router per modelli. Conferma che il routing è diventato un'infrastruttura strategica. La decisione su quale modello risponda a una richiesta ora influenza costo, latenza, affidabilità, trattamento dei dati e potere contrattuale dei provider.

Cosa dovrebbero osservare i lettori di Google News

Tre segnali mostreranno se Switchyard diventerà infrastruttura di produzione o resterà un interessante esperimento per sviluppatori.

Il primo segnale è la valutazione a livello di carico di lavoro. Nvidia e i primi adottanti devono pubblicare risultati che colleghino le decisioni di routing agli esiti completi delle attività. Un minore consumo di token conta solo quando l'agente completa ancora correttamente il proprio incarico.

Evidenze utili includerebbero tassi di errore, comportamento di recupero, distribuzioni della latenza e confronti di qualità tra più coppie di modelli. I risultati dovrebbero inoltre separare l'overhead del router dai risparmi generati spostando le chiamate a un modello efficiente.

Se test indipendenti riproducono risultati solidi a livello di attività, la tesi di Nvidia diventa più forte. Se i risultati dipendono da benchmark ristretti o coppie di modelli selezionate con cura, i deployment a modello fisso resteranno interessanti per i flussi di lavoro importanti.

Il secondo segnale è l'integrazione oltre i servizi di Nvidia. Switchyard descrive già il supporto per endpoint compatibili con OpenAI, Anthropic e OpenAI. Gli utenti in produzione verificheranno se chiamate agli strumenti, streaming, risposte strutturate, gestione del contesto ed errori rimangano affidabili tra questi provider.

Integrazioni ampie e ben mantenute sosterrebbero l'affermazione di Nvidia sull'indipendenza dai modelli. Un comportamento disomogeneo sui backend concorrenti la indebolirebbe e renderebbe più interessanti i gateway neutrali.

Il terzo segnale è il controllo enterprise. Gli acquirenti cercheranno applicazione matura delle policy, tracce di audit, isolamento delle credenziali, linee guida per il deployment e flussi di lavoro di valutazione. Avranno inoltre bisogno di un modo chiaro per vincolare le richieste sensibili a modelli approvati.

Funzionalità di governance solide sposterebbero il routing dall'ottimizzazione per sviluppatori all'ingegneria di piattaforma. Controlli deboli limiterebbero l'adozione a esperimenti, strumenti interni e agenti a rischio inferiore.

Questi segnali contano più dei conteggi di download o dei titoli. Google News può amplificare l'ingresso di Nvidia, ma non può stabilire se una decisione di routing fosse corretta. Tale prova arriverà da esecuzioni reali di agenti con modelli, strumenti e vincoli aziendali in evoluzione.

Per gli sviluppatori, l'azione immediata è pratica: scegliete un flusso di lavoro delimitato, definite il successo prima di instradarlo e confrontate Switchyard con una baseline a modello fisso. Monitorate gli esiti completi delle attività insieme a latenza e utilizzo dei modelli.

Per gli acquirenti enterprise, chiedete chi possiede la policy di routing e con quale rapidità l'organizzazione può rilevare una decisione errata. Una chiamata più economica non è davvero più economica quando crea rilavorazioni, indebolisce la conformità o nasconde un errore.

Nvidia ha reso più difficile liquidare il model routing come un’astrazione di nicchia. I prossimi mesi mostreranno se Switchyard riuscirà a rendere la scelta dinamica dei modelli una pratica operativa ordinaria quanto il bilanciamento del carico, oppure se sarà proprio il router a restare il modello più difficile di cui fidarsi.