Inspur costruisce un'infrastruttura per agenti intelligenti: 40.000 agenti per rack e collaborazione multimodello

Introduzione

L'infrastruttura AI sta superando l'epoca in cui elaborava una singola richiesta per modello.

Un agente intelligente di livello produttivo non si limita a ricevere un prompt e restituire una risposta. Può suddividere un'attività in più fasi, richiamare strumenti esterni, mantenere il contesto, coordinarsi con sotto-agenti, verificare output intermedi e rimanere attivo a lungo. Quando un'impresa implementa contemporaneamente migliaia di questi agenti, le esigenze infrastrutturali differiscono radicalmente dall'inferenza di un chatbot comune.

Al 2026 Open Compute Technology Summit di Pechino, Inspur ha proposto due direzioni infrastrutturali per questo nuovo carico di lavoro:

1. Server rack raffreddato a liquido nativo per CPU, progettato per supportare oltre 40.000 agenti simultanei in un singolo rack.
2. La combinazione del supernodo MetaBrain SD200 con l'API di fusione multi-modello EPAI, che consente a più modelli linguistici di grandi dimensioni di generare, verificare e comporre risposte per attività complesse.

La prima direzione si concentra sulla scala: mantenere online un gran numero di agenti a lunga esecuzione. La seconda si concentra sulla qualità: consentire a più modelli con punti di forza diversi di collaborare, invece di costringere un singolo modello a gestire ogni parte di un compito difficile.

Le diverse sfide infrastrutturali poste dai carichi di lavoro degli agenti

L'inferenza tradizionale dei modelli linguistici di grandi dimensioni segue solitamente uno schema semplice:

1. L'utente invia una richiesta.
2. Il modello esegue l'inferenza.
3. Il sistema restituisce una risposta.
4. La sessione termina o attende la richiesta successiva.

Il percorso di esecuzione di un'applicazione agente è molto più lungo.

Un singolo compito aziendale può coinvolgere:

• Pianificazione
• Scomposizione del compito
• Recupero informazioni
• Chiamata a strumenti
• Esecuzione di codice
• Controllo delle autorizzazioni
• Processi in sandbox
• Inferenza multi-turno
• Coordinamento sotto-agenti
• Validazione dell'output
• Aggregazione dei risultati
• Gestione dello stato a lunga esecuzione

Di conseguenza, l'infrastruttura deve supportare non solo l'inferenza del modello, ma anche un gran numero di processi software persistenti.

In un ambiente aziendale, il numero di agenti attivi può passare da poche decine a migliaia o decine di migliaia. Alcuni agenti possono funzionare in modo continuo, mentre altri vengono creati dinamicamente per compiti brevi e distrutti al completamento.

Ciò modifica l'equilibrio tra risorse CPU e GPU.

GPU: generazione di token

Le GPU rimangono indispensabili per:

• Inferenza di modelli linguistici di grandi dimensioni
• Prefill e decodifica
• Generazione di embedding
• Elaborazione multimodale
• Produzione di token ad alta produttività
• Esecuzione parallela di modelli

CPU: esecuzione dell'ambiente agente

La CPU gestisce gran parte del lavoro periferico:

• Scheduling dei processi agente
• Chiamata a strumenti
• Gestione del contesto e dello stato
• Interazione con i sistemi aziendali
• Esecuzione in sandbox
• Operazioni di rete e storage
• Autenticazione e autorizzazione
• Coordinamento del flusso di lavoro
• Preparazione dei risultati

Il modello può essere responsabile della generazione di ragionamento o testo, ma la CPU solitamente esegue l'ambiente operativo in cui l'agente agisce.

Pertanto, l'infrastruttura per agenti si sta evolvendo da un design incentrato sulla GPU a un sistema in cui CPU, GPU, rete, storage, raffreddamento e software di orchestrazione collaborano.

Perché la densità della CPU sta diventando sempre più importante

Nei normali server aziendali, la densità della CPU è stata storicamente limitata da consumo energetico, raffreddamento, spazio, cablaggio, ventole e requisiti di manutenzione.

Le implementazioni di agenti cambiano il modello economico.

Se migliaia di agenti richiedono risorse CPU per orchestrazione, chiamata a strumenti e ambienti runtime isolati, i rack a bassa densità di CPU occuperanno più spazio in sala server, più connessioni di rete e più infrastruttura di supporto.

Allo stesso tempo, i data center AI si stanno evolvendo verso potenze per rack più elevate.

Secondo fonti di informazione, Inspur prevede che la potenza dei rack AI nazionali si avvicinerà a 300 kilowatt, mentre alcuni progetti globali stanno già puntando a sistemi rack a livello di megawatt. Il raffreddamento ad aria tradizionale è solitamente limitato a decine di kilowatt per rack e diventerà sempre più difficile a queste densità.

Pertanto, il raffreddamento a liquido non è più un problema esclusivo delle GPU.

Anche i rack CPU che supportano i carichi di lavoro degli agenti devono corrispondere all'architettura di potenza e raffreddamento dei data center AI di prossima generazione.

Un singolo rack può supportare oltre 40.000 agenti

Inspur ha lanciato quello che afferma essere il primo server rack raffreddato a liquido nativo per CPU al mondo.

Il sistema si basa sull'architettura di raffreddamento a liquido OCM 2.0 e supporta processori x86 e Arm.

I suoi parametri principali includono:

Caratteristica	Parametri dichiarati dal produttore
Numero massimo di CPU per rack	384
Numero di agenti simultanei supportati	Oltre 40.000
Architettura del processore	x86 e Arm
Ambito di raffreddamento	CPU, memoria, SSD, scheda di rete, modulo ottico e altri componenti che generano calore
Densità di calcolo	4 CPU integrate in uno spazio 0.5U
Modalità di manutenzione	Manutenzione a ciclo di vita completo per raffreddamento a liquido
Scenari target	Data center AI ad alta densità e a livello di gigawatt

Questo sistema non tratta il raffreddamento a liquido come un componente aggiuntivo dopo il completamento del design del server.

Al contrario, la disposizione del calcolo e l'architettura di raffreddamento sono state sviluppate in modo coordinato.

Dall'espansione della piastra fredda per CPU al raffreddamento completo dei componenti

I server tradizionali con piastra fredda

possono raffreddare direttamente il processore, ma la memoria, la rete, lo storage, i componenti di alimentazione e altre apparecchiature necessitano ancora del raffreddamento ad aria delle ventole.

Con l'aumento della densità, questo approccio diventa meno efficace.

L'architettura di raffreddamento a liquido nativo di Inspur integra i principali componenti che generano calore in un sistema di raffreddamento unificato:

• CPU
• Memoria
• Scheda di rete
• Modulo ottico
• Unità a stato solido
• Componenti di comunicazione

Ciò riduce la dipendenza dal flusso d'aria interno, consentendo una disposizione più compatta dei componenti.

Sotto sono presenti tre icone blu: "Architettura di raffreddamento a liquido", "Connessione di raffreddamento a liquido" e "Manutenzione del raffreddamento a liquido". L'immagine è strettamente correlata al contesto e mostra visivamente la situazione del server con architettura di raffreddamento a liquido Inspur, in linea con la progettazione dell'architettura di raffreddamento a liquido descritta nel documento.](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/44c90e20-2048-4f43-8d1d-8516006843e0-d14e80b4-e2a0-4468-a7b6-77e5229ab1ca.png)

Unità di calcolo compatta

Il rapporto descrive un'unità di calcolo compatta che integra più gruppi di processori e componenti periferici in un telaio sottile e leggero.

L'obiettivo progettuale è recuperare lo spazio precedentemente occupato dai seguenti componenti:

• Ventole di grandi dimensioni
• Canali d'aria
• Tubazioni di raffreddamento
• Cavi interni
• Vassoi per server tradizionali

La disposizione dei componenti piatti consente a un'unica piastra fredda di grandi dimensioni di coprire più aree del sistema.

Il rack adotta un design interno con meno cavi o senza cavi, supportando la manutenzione senza spegnimento. Inspur afferma che ciò migliora l'efficienza di distribuzione e manutenzione dell'intero rack.

Perché l'OCM è importante

OCM è l'acronimo di Open Compute Module.

L'architettura modulare mira a disaccoppiare il modulo processore dalla progettazione complessiva del sistema. Questo design consente di supportare più facilmente processori di diverse generazioni o architetture, senza dover riprogettare l'intero rack per ogni processore.

Per le aziende e gli operatori di data center, questa soluzione può offrire i seguenti vantaggi:

• Più scelte hardware
• Aggiornamenti della piattaforma più facili
• Riduzione del lavoro di progettazione ridondante
• Migliore compatibilità con le architetture x86 e Arm
• Prolungamento del ciclo di vita dell'infrastruttura del rack

I risultati effettivi dipendono dalla compatibilità dell'ecosistema, dall'interoperabilità e dalla disponibilità dei componenti correlati.

Scala non significa intelligenza

L'esecuzione di decine di migliaia di agenti che risolvono problemi di capacità non migliora automaticamente la qualità delle risposte.

I grandi modelli linguistici hanno ciascuno le proprie specializzazioni.

Alcuni modelli potrebbero essere più bravi in:

• Ragionamento logico
• Scrittura di codice
• Analisi di testi lunghi
• Ricerca tecnica
• Scrittura naturale
• Estrazione strutturata
• Attività multilingue

Anche i modelli su larga scala hanno dei punti deboli.

Quando si affrontano compiti complessi, un singolo modello potrebbe trascurare questioni chiave che altri modelli possono individuare. Un singolo modello potrebbe anche fornire risposte con sicurezza, senza rivelare incertezze o considerare interpretazioni alternative.

Pertanto, la seconda direzione infrastrutturale di Inspur si concentra sulla collaborazione multimodello.

Elaborazione collaborativa della stessa attività con più modelli

L'API di fusione multimodello EPAI distribuisce le attività complesse in parallelo a più modelli candidati.

Ogni modello genera una risposta in modo indipendente. Un modello di revisione e fusione aggiuntivo confronta le risposte candidate per identificare:

• Conclusioni comuni
• Giudizi contraddittori
• Informazioni mancanti
• Intuizioni uniche

Non supporta l'affermazione:

• Aree che necessitano di coordinamento

Successivamente, la piattaforma genera una risposta integrata.

Non si tratta di una semplice votazione a maggioranza, né di una semplice concatenazione di tutte le risposte. Il flusso di lavoro previsto è il seguente:

1. Generazione candidata
2. Revisione incrociata tra modelli
3. Analisi delle differenze e delle omissioni
4. Fusione nell'output finale

Inspur riferisce che il sistema ha raggiunto 53,9% nella valutazione DRACO, superando ogni singolo modello nel pool di candidati utilizzato per il test.

Questo risultato dovrebbe essere considerato come un benchmark riportato dalla piattaforma, non come un'affermazione che la fusione dei modelli superi sempre il miglior modello singolo. Le prestazioni dipenderanno dai modelli candidati, dal modello di valutazione, dalla logica di routing, dal tipo di attività, dai prompt e dal metodo di scoring.

Per le attività semplici si utilizza ancora un singolo modello

Se ogni richiesta eseguisse più modelli, aumenterebbe inutilmente costi e latenza.

Pertanto, EPAI distingue tra attività brevi e prevedibili e attività complesse.

Attività adatte a un singolo modello

I modelli leggeri potrebbero essere sufficienti per:

• Domande e risposte semplici
• Conversione di formato
• Estrazione di base
• Attività di classificazione
• Chiamate di strumenti brevi
• Conversione di contenuti ordinari

Attività più adatte alla fusione multimodello

Più modelli potrebbero essere utili per:

• Ricerca approfondita
• Confronto tecnico
• Analisi architetturale
• Pianificazione complessa
• Ragionamento su testi lunghi
• Revisioni ad alto rischio
• Attività con prove ambigue
• Output che richiedono verifica indipendente

Questo principio di routing è cruciale per i sistemi di produzione.

La collaborazione multimodello è più preziosa quando il potenziale miglioramento della qualità compensa i costi aggiuntivi di token, tempo GPU e latenza di risposta.

Flusso di lavoro di fusione multimodello EPAI

L'API EPAI è progettata per nascondere l'orchestrazione multimodello dietro un'interfaccia unificata.

Gli sviluppatori inviano una richiesta alla piattaforma. EPAI gestisce:

• Selezione dei modelli candidati
• Distribuzione parallela delle attività
• Raccolta delle risposte
• Esecuzione del modello di valutazione
• Analisi delle differenze
• Generazione della risposta finale

La stessa interfaccia può essere integrata in applicazioni di agenti e framework di sviluppo, senza che ogni team debba costruire sistemi di routing e valutazione personalizzati.

Questa architettura è adatta per le aziende che utilizzano una combinazione di:

• Modelli open source
• Modelli proprietari
• Modelli generici
• Modelli specifici per dominio
• Modelli distribuiti on-premise
• Modelli API cloud

La principale sfida operativa è che più grandi modelli potrebbero dover rimanere disponibili contemporaneamente. Ciò richiederà maggiori risorse di memoria dell'acceleratore, larghezza di banda di interconnessione, scheduling e comunicazione a bassa latenza.

MetaBrain SD200 come motore di token

Il supernodo MetaBrain SD200 è la piattaforma hardware che supporta il flusso di lavoro di fusione multimodello.

Questo sistema adotta un'architettura di comunicazione multi-host, a bassa latenza e basata sulla memoria semantica. Secondo Inspur, è in grado di interconnettere 64 acceleratori GPU nazionali all'interno di un unico sistema.

Il suo design include:

• Architettura di calcolo aperta OCM e OAM
• Interconnessione 3D Mesh
• Indirizzamento unificato degli acceleratori
• Comunicazione peer-to-peer ad alta velocità
• Memoria condivisa di grande capacità

Capacità

• Supporto per più modelli con trilioni di parametri
• Ottimizzazione sinergica hardware-software

Si afferma che questo supernodo possa supportare un singolo modello con una scala fino a quattro trilioni di parametri, o più modelli con trilioni di parametri utilizzati simultaneamente da applicazioni di agenti.

Tempo di generazione del token nei test Inspur: 4,77 millisecondi

Inspur riferisce che l'SD200 ha ridotto il tempo di generazione di un singolo token per il modello Kimi K2.6 con trilioni di parametri a 4,77 millisecondi.

L'azienda riferisce inoltre che il tempo di generazione del primo token è stato ridotto del 35% rispetto all'implementazione precedente.

Questi dati si riferiscono a risultati ottenuti in ambienti di ottimizzazione e test specifici e non devono essere interpretati come latenza garantita per ogni modello, distribuzione, lunghezza del prompt, livello di concorrenza o carico di lavoro di produzione.

Questi miglioramenti sono attribuiti a diverse tecnologie.

Predizione multi-token

I modelli autoregressivi di solito generano prima un token, verificano il nuovo stato e poi generano il successivo.

La predizione multi-token tenta di generare più token candidati in un unico passaggio e di verificarli insieme.

Quando l'accuratezza della predizione è elevata, si possono ridurre i cicli di decodifica sequenziale.

Quantizzazione W4A8

L'ottimizzazione ha utilizzato pesi INT4 e calcolo di attivazione INT8 in alcuni carichi di modelli misti di esperti.

Rispetto al calcolo BF16, ciò può ridurre:

• Pressione sulla larghezza di banda della memoria
• Utilizzo della memoria dell'acceleratore
• Requisiti di calcolo
• Costo di inferenza per token

La quantizzazione può influenzare la qualità del modello, quindi i team di produzione devono valutare l'accuratezza in base ai propri carichi di lavoro, non solo basarsi sui risultati di velocità.

Compilazione Just-In-Time del kernel

La compilazione JIT genera kernel acceleratori specializzati in fase di esecuzione, basati sulla forma del tensore, sul layout e sul tipo di dati.

Rispetto alle implementazioni statiche generiche, i kernel specializzati possono ridurre i rami non necessari e migliorare l'accesso alla memoria.

Separazione prefill-decodifica

Il prefill del prompt e la decodifica dei token hanno caratteristiche prestazionali diverse.

Separare le due fasi consente di allocare risorse in modo differenziato e di trasferire la cache KV in modo asincrono, riducendo la contesa tra calcolo e comunicazione.

Compatibilità dei modelli

Inspur afferma che l'SD200 ha completato l'ottimizzazione delle prestazioni per diversi modelli open source popolari, tra cui:

• Kimi K2.6
• DeepSeek V4
• GLM 5.2
• MiniMax M3

La compatibilità non implica necessariamente che ogni modello raggiunga la stessa latenza o throughput.

L'architettura del modello, il numero di parametri, il design MoE, la lunghezza del contesto, la quantizzazione, il batch processing e il software di servizio influenzano tutti le prestazioni.

L'edizione Enterprise abbassa la barriera di implementazione

Il supernodo a 64 acceleratori è adatto per grandi progetti di infrastruttura AI, ma per molte aziende è troppo grande e costoso.

Inspur ha anche lanciato l'edizione Enterprise YuanBrain SD200.

L'edizione Enterprise riduce il dominio di calcolo con scalabilità verticale da 64 a 16 acceleratori, mirando alla distribuzione locale di modelli con trilioni di parametri.

Le sue caratteristiche dichiarate includono:

• Dominio di interconnessione unificato per 16 acceleratori
• Comunicazione nativa con semantica di memoria
• Indirizzamento unificato
• Memoria unificata per acceleratori a livello di terabyte
• Miglioramento superiore al 40% del tempo di generazione del primo token per l'inferenza di modelli con trilioni di parametri
• Supporto nativo per modelli open source leader con trilioni di parametri
• Costi di migrazione e adattamento inferiori rispetto a un sistema SD200 completo

Questa edizione Enterprise è principalmente mirata ai seguenti carichi di lavoro:

• Comprensione di documenti lunghi
• Ragionamento logico complesso
• Distribuzione di modelli privati
• Collaborazione multi-agente
• Ricerca interna
• Applicazioni aziendali sensibili

Fornisce un punto di ingresso più piccolo per le organizzazioni che necessitano del controllo locale del modello ma non possono giustificare un supernodo a 64 acceleratori.

Lo stack di infrastrutture sta diventando più integrato

I prodotti lanciati all'OCTS 2026 mostrano un'architettura a tre livelli.

Livello	Responsabilità principale
Piattaforma software	Accesso al modello, routing delle attività, orchestrazione, autorizzazioni, valutazione e fusione dei risultati
Infrastruttura CPU	Processi agente, chiamate a strumenti, esecuzione sandbox, gestione del contesto e interazione con i sistemi aziendali
Supernodo GPU	Inferenza di modelli grandi, generazione di token ad alto rendimento ed esecuzione multi-modello

Il sistema funziona correttamente solo quando tutti e tre i livelli lavorano insieme.

Un cluster GPU veloce non può compensare una pianificazione agente debole. Un rack CPU ad alta densità non può migliorare la qualità dell'inferenza se non può accedere a modelli potenti. Un'API di fusione complessa non può fornire una latenza utile se il modello sottostante non può essere caricato o connesso in modo efficiente.

Questo è il cambiamento principale nella competizione per l'infrastruttura agente.

Il mercato iniziale si concentrava principalmente su quanto bene un singolo server supportasse un singolo modello grande. L'era degli agenti ha spostato l'attenzione sulle prestazioni a livello di sistema:

• Quanti processi agente possono rimanere online?
• Quanto velocemente possono chiamare modelli e strumenti?
• È possibile eseguire più modelli contemporaneamente?
• Come viene condivisa o isolata la memoria?
• Come vengono applicate le autorizzazioni?
• La piattaforma può instradare in modo diverso compiti semplici e complessi?
• Il sistema rimane stabile sotto elevata concorrenza?
• Quanto efficientemente genera token utili?

Cosa dovrebbero valutare le aziende prima della distribuzione

I numeri impressionanti forniti dai venditori sono utili, ma non sufficienti per scegliere una piattaforma di infrastruttura agente.

Una valutazione in ambiente di produzione dovrebbe misurare il carico di lavoro completo.

1. Concorrenza degli agenti

Non solo contare gli utenti attivi, ma anche:

• Sotto-agenti per attività
• Processi degli strumenti
• Sandbox
• Lavori in background
• Sessioni persistenti
• Picchi di attività
• Processi di ripristino da guasti

2. CPU e memoria per agente

Un agente di recupero leggero ha caratteristiche di fabbisogno di risorse molto diverse rispetto a un agente di codifica con un ambiente di sviluppo indipendente.

La metrica "numero di agenti per rack" deve essere mappata sulla memoria effettiva, CPU, storage e requisiti di rete dell'applicazione target.

3. Latenza del modello

Da misurare:

• Tempo di generazione del primo token
• Latenza tra i token
• Tempo totale dell'attività end-to-end
• Latenza di coda
• Latenza di chiamata dello strumento
• Latenza in scenari concorrenti

Un basso tempo di generazione del token nei benchmark non garantisce una bassa latenza nei flussi di lavoro end-to-end.

4. Economia multi-modello

La fusione multi-modello può migliorare la qualità, ma può portare a un aumento esponenziale dei costi di inferenza.

I team dovrebbero confrontare:

• Precisione del singolo modello
• Precisione del modello fuso
• Numero di token consumati
• Utilizzo della GPU
• Tempo di risposta
• Costo del modello di revisione
• Tasso di fallimento
• Riduzione del controllo umano

5. Raffreddamento e compatibilità delle strutture

I rack raffreddati a liquido nativi richiedono un'infrastruttura di supporto.

Da verificare:

• Unità di distribuzione del liquido refrigerante
• Temperatura di mandata e ritorno
• Requisiti di pressione e portata
• Rilevamento delle perdite
• Procedure di manutenzione
• Piani di recupero del calore
• Capacità di alimentazione del rack
• Portata del pavimento del data center

6. Portabilità del modello e dell'acceleratore

Gli standard modulari aperti possono aumentare la flessibilità, ma la portabilità effettiva dipende dalla compatibilità del software.

Da verificare:

• Framework del modello
• Motore di inferenza
• Supporto per la quantizzazione
• Disponibilità del kernel
• Maturità del driver
• Strumenti di monitoraggio
• Sostituzione dell'acceleratore
• Procedure di aggiornamento

7. Affidabilità e governance

Gli agenti a lunga esecuzione necessitano di un forte controllo su:

• Autenticazione
• Impostazioni delle autorizzazioni
• Gestione delle chiavi
• Accesso alla rete
• Ambiente sandbox
• Log di audit
• Limitazione della velocità
• Approvazione umana
• Routing del modello
• Conservazione dei dati

La densità dell'infrastruttura non dovrebbe andare a scapito dell'isolamento operativo.

Domande frequenti

Cos'è il rack agente CPU raffreddato a liquido nativo di Inspur?

È un server CPU a rack completo progettato attorno a un sistema di raffreddamento, non un raffreddamento a liquido aggiunto a un design tradizionale raffreddato ad aria. Inspur afferma che può ospitare fino a 384 CPU e supportare oltre 40.000 agenti concorrenti.

Un rack può davvero eseguire 40.000 agenti AI?

Questa cifra è il valore massimo riportato dal fornitore nel rapporto di riferimento dell'architettura di Inspur. La capacità effettiva dipende dalle risorse di CPU, memoria, storage, rete e isolamento sandbox richieste da ciascun agente.

Perché gli agenti AI necessitano di così tante CPU?

I modelli linguistici possono funzionare sulle GPU, ma gli agenti necessitano anche di CPU per l'esecuzione della pianificazione, l'esecuzione degli strumenti, la gestione dello stato, l'accesso ai sistemi aziendali, i controlli di sicurezza e gli ambienti di runtime isolati. I flussi di lavoro a lunga esecuzione e multi-agente aumentano ulteriormente questa necessità di CPU.

Cos'è OCM 2.0?

OCM è un'architettura di modulo di calcolo aperto utilizzata per separare i moduli di calcolo dal design del rack più ampio. Il sistema OCM 2.0 raffreddato a liquido di Inspur supporta più architetture CPU e raffreddamento a liquido a componente completo.

Cos'è MetaBrain SD200?

MetaBrain SD200 è il supernodo AI di Inspur, progettato per l'inferenza di modelli grandi e carichi di lavoro multi-modello. Utilizza un'architettura di scalabilità a 64 acceleratori, supportando indirizzamento unificato e interconnessione ad alta velocità.

Cos'è l'API di fusione multi-modello EPAI?

È un'API che può inviare un'attività a più modelli candidati, raccogliere le loro risposte indipendenti e utilizzare un modello di revisione e fusione per identificare consenso, dissenso, omissioni e intuizioni uniche prima di generare una risposta finale.

La fusione multi-modello è sempre superiore a un singolo modello?

No. La fusione multi-modello può migliorare le prestazioni su compiti complessi, ma aumenta il consumo di token, i costi di calcolo e la latenza. I compiti semplici sono più adatti per essere instradati a un singolo modello leggero.

Qual è la differenza tra SD200 e l'edizione Enterprise SD200?

L'SD200 completo utilizza un dominio di scalabilità a 64 acceleratori per carichi di lavoro su larga scala, mentre l'edizione Enterprise SD200 riduce il dominio a 16 acceleratori, rivolgendosi alle aziende che necessitano di distribuire modelli con trilioni di parametri localmente con un'infrastruttura meno impegnativa.

Strumenti correlati

• Inspur EPA Piattaforma AI a livello aziendale: supporta la gestione dei modelli, lo sviluppo di applicazioni, il recupero, la distribuzione e flussi di lavoro multi-modello.
• Soluzione di raffreddamento a liquido Inspur: soluzione infrastrutturale per la distribuzione di server CPU/GPU raffreddati a liquido.
• Open Compute Project: comunità industriale che sviluppa progetti hardware aperti per server, rack, alimentazione, raffreddamento e data center.
• Kimi: piattaforma assistente e modello di Moonshot AI, i cui risultati di ottimizzazione sono citati nell'Inspur SD200.

DeepSeek: fornitore di modelli di IA, il cui modello open-source è stato incluso nell'elenco di compatibilità SD200.

Link correlati

• Annuncio dell'infrastruttura per agenti intelligenti di Inspur: comunicazione ufficiale riguardante rack CPU a raffreddamento liquido, SD200 e supernodi enterprise.
• Comunicato sulle prestazioni da 4,77 ms del MetaBrain SD200: panoramica tecnica di Inspur sull'ottimizzazione del SD200 e sui risultati di generazione dei token.
• API di fusione multimodello EPA: spiegazione ufficiale dei meccanismi di generazione candidata, revisione, fusione e punteggio DRACO.
• Pagina prodotto Inspur EPA: informazioni sul prodotto per la piattaforma di sviluppo di modelli enterprise di grandi dimensioni.
• Soluzione per data center a raffreddamento liquido Inspur: informazioni ufficiali sulle soluzioni di data center a raffreddamento liquido.
• Open Compute Technology Summit 2026: pagina evento OCTS 2026 e annunci relativi al calcolo open source.
• Open Compute Project Foundation: informazioni ufficiali sugli standard di infrastruttura aperta e sui progetti della comunità.

Riepilogo

Gli annunci di Inspur all'OCTS 2026 affrontano due problemi principali sollevati dagli agenti enterprise.

Il rack CPU nativo con raffreddamento liquido si concentra sulla scalabilità, fornendo un ambiente ad alta densità per la pianificazione degli agenti, gli strumenti, i sandbox, la gestione del contesto e i flussi di lavoro lunghi. Il flusso di lavoro di fusione multimodello SD200 ed EPA si concentra sull'intelligenza, consentendo a più modelli di grandi dimensioni di collaborare su compiti complessi, con un modello di revisione che integra i risultati finali.

La lezione più ampia è: l'infrastruttura per agenti intelligenti non può essere ridotta a un singolo acceleratore più veloce. I sistemi di produzione richiedono il coordinamento di

CPU, GPU, memoria, interconnessioni, raffreddamento, orchestrazione, autorizzazioni e valutazione.

La metrica centrale dell'infrastruttura per agenti intelligenti sta passando dall'efficienza operativa di un singolo modello alla capacità dell'intero sistema di pianificare efficientemente migliaia di agenti e produrre risultati affidabili in modo continuo.