A poco più di cinque mesi dalla Series A da 80 milioni di dollari, Gimlet Labs raccoglie altri 300 milioni e raggiunge una valutazione di 3 miliardi di dollari, secondo quanto indicato dal CEO Zain Asgar a Bloomberg.
Il nuovo round, guidato da Andreessen Horowitz, porta a 392 milioni il capitale complessivamente raccolto dalla startup e sostiene l’espansione di una piattaforma che distribuisce le diverse fasi dell’inference sull’hardware più adatto, riducendo tempi, consumi e costi.
La velocità con cui Gimlet ha raggiunto questa dimensione finanziaria accompagna una crescita altrettanto rapida dell’infrastruttura: da marzo la startup dichiara miliardi di dollari di ricavi contrattualizzati, una pipeline di data center nell’ordine dei gigawatt e un’espansione verso centinaia di megawatt di capacità gestita.
Dietro questi numeri c’è il problema che Gimlet vuole affrontare. Modelli più grandi, context window che arrivano ormai al milione di token e workload agentici composti da numerose inferenze consecutive stanno aumentando contemporaneamente la quantità di calcolo richiesta e la pressione sull’infrastruttura. L’energia disponibile nei data center diventa così un limite tanto importante quanto la disponibilità dei chip.
Gimlet parte dall’idea che GPU, CPU, sistemi near-memory, architetture dataflow e altri acceleratori specializzati siano efficienti in momenti diversi dell’inference. Se il workload può essere scomposto, ciascuna fase può essere assegnata al tipo di hardware che offre il rapporto migliore fra capacità di calcolo, banda di memoria, latenza e consumo.
Secondo Gimlet, questa disaggregazione eterogenea consente di ottenere speedup fra 5 e 10 volte mantenendo lo stesso power footprint, oppure incrementi analoghi del throughput a parità di latenza. La startup indica inoltre prestazioni da 3 a 10 volte superiori rispetto a infrastrutture omogenee su alcuni workload frontier della propria inference cloud.
Sono risultati riferiti alle configurazioni e ai carichi utilizzati da Gimlet, ma rendono evidente quale sia il parametro economico che la startup vuole ottimizzare: quanta inference è possibile ottenere da una quantità finita di hardware ed energia.
Il routing scende dal modello all’hardware
Il routing è già una tecnica diffusa nella parte alta dello stack AI. Un sistema può decidere, per esempio, di affidare una richiesta semplice a un modello piccolo ed economico e utilizzare un modello frontier soltanto quando il compito lo richiede. Allo stesso modo è possibile scegliere dinamicamente tra provider o deployment differenti in funzione di disponibilità, prezzo o latenza.
Gimlet porta questa logica più vicino al calcolo. La decisione non riguarda soltanto quale modello eseguire, ma anche dove eseguirne le diverse parti.
La piattaforma di Gimlet Labs analizza il workload, lo scompone in componenti schedulabili e le assegna alle risorse disponibili in funzione delle loro caratteristiche. Il principio è che non esiste necessariamente un singolo acceleratore ottimale per l’intera inferenza: alcune operazioni richiedono soprattutto potenza di calcolo, altre sono limitate dalla banda di memoria, mentre altre ancora possono essere eseguite più efficientemente da CPU o da chip specializzati.
Gimlet utilizza quindi un planner per suddividere il lavoro, uno scheduler per scegliere dove eseguirlo e un compiler che adatta le diverse parti all’architettura selezionata. Il placement può inoltre essere modificato dinamicamente in funzione dell’hardware disponibile, evitando che capacità computazionale rimanga inutilizzata mentre altri acceleratori sono saturi.
In termini economici, significa cercare di evitare di utilizzare sistematicamente una risorsa costosa quando una diversa architettura può svolgere quella particolare operazione più rapidamente, consumando meno o con un costo inferiore.
Per gli agenti il problema si moltiplica
Questa impostazione diventa particolarmente rilevante con gli agenti AI. Una singola richiesta può innescare decine di inferenze consecutive, chiamate a strumenti, ricerca, accesso a database, esecuzione di codice e utilizzo di modelli differenti prima di arrivare al risultato.
Gimlet rappresenta questi workload come grafi multistadio nei quali possono comparire LLM, modelli multimodali e di diffusione, code sandbox, filesystem remoti, web search, server MCP, codice applicativo e fonti dati.
I nodi del grafo non hanno necessariamente lo stesso profilo computazionale. Un LLM di grandi dimensioni può richiedere acceleratori molto potenti; un modello di visione può presentare esigenze differenti; un’operazione applicativa può funzionare bene su CPU. Lo scheduler può quindi distribuire il grafo in funzione delle caratteristiche di ogni fase.
Il vantaggio potenziale cresce insieme alla lunghezza del workflow. Una piccola riduzione della latenza o del costo di una singola inferenza incide relativamente poco in una normale conversazione; se l’operazione viene ripetuta decine di volte da un agente, la stessa inefficienza si accumula sull’intero tempo di esecuzione e sulla quantità complessiva di risorse consumate.
Prefill e decode non hanno le stesse esigenze
L’esempio più immediato di questa eterogeneità si trova già all’interno dell’inference di un singolo LLM.
Durante il prefill, il modello elabora l’intero prompt, produce il primo token e costruisce la KV cache. È una fase fortemente orientata al calcolo, nella quale è possibile eseguire in parallelo grandi quantità di operazioni.
Il decode produce invece i token successivi uno alla volta. Pesi del modello e KV cache devono essere letti ripetutamente e il collo di bottiglia tende quindi a spostarsi verso la banda di memoria.
La separazione fra prefill e decode è già utilizzata per migliorare l’efficienza dell’inference. Gimlet estende però la tecnica a un ambiente multivendor, nel quale le due fasi possono essere eseguite da acceleratori di produttori differenti.
Nei test sulla disaggregazione prefill-decode multivendor, la startup ha analizzato, tra le altre, una configurazione con NVIDIA B200 per il prefill e Intel Gaudi 3 per il decode. I risultati sono stati confrontati con una configurazione disaggregata nella quale entrambe le fasi vengono eseguite su NVIDIA H100.
Per un workload Llama orientato al prefill, con 4.096 token in ingresso e 512 in uscita, il modello elaborato da Gimlet indica per B200-Gaudi 3 un vantaggio sul TCO fino a 3 volte rispetto alla configurazione H100-H100. Con un workload maggiormente orientato al decode, composto da 512 token in ingresso e 4.096 in uscita, il vantaggio calcolato arriva fino a 4 volte.
La stessa analisi indica un miglioramento più generale di circa 1,7 volte rispetto alle configurazioni di disaggregazione single-vendor considerate.
Non significa che B200 e Gaudi 3 costituiscano sempre la combinazione migliore. Il risultato mostra invece il principio su cui si basa il sistema: l’acceleratore più performante per una fase può non essere quello economicamente più efficiente per quella successiva.
Gimlet divide anche speculative decode, attention e FFN
La separazione tra prefill e decode è soltanto il caso più conosciuto. Gimlet sta lavorando con una granularità maggiore, intervenendo anche su speculative decoding e sulla separazione fra attention e feed-forward network (FFN).
Le diverse strategie producono compromessi differenti. Gimlet indica la separazione prefill-decode come particolarmente adatta a contenere la latenza, mentre altre forme di disaggregazione possono privilegiare maggiormente il throughput.
Lo stack traccia e scompone il modello, quindi sceglie la suddivisione e gli acceleratori sulla base degli SLA del workload e delle risorse effettivamente disponibili. Se il tipo di chip preferibile per il decode è saturo, per esempio, il sistema può utilizzare altri acceleratori compatibili invece di lasciare la richiesta in attesa.
È questo passaggio a trasformare il semplice placement dell’hardware in una forma di routing computazionale dinamico.
Spostare il calcolo ha però un costo
Distribuire parti dello stesso workload su chip differenti introduce a sua volta un problema: i dati devono spostarsi insieme al calcolo.
Se prefill e decode vengono separati, la KV cache generata durante la prima fase deve essere trasferita al nodo che esegue la seconda. Con acceleratori di produttori differenti può essere necessario convertirne anche il formato.
Nel caso della configurazione B200-Gaudi 3, Gimlet ha misurato fra 20 e 50 microsecondi per questa conversione. La KV cache può inoltre essere trasferita progressivamente, layer dopo layer, invece di aspettare che il prefill sia completato interamente.
La rete diventa quindi parte del problema di ottimizzazione. Non è sufficiente individuare il chip con il costo o la prestazione teoricamente migliori: il vantaggio deve essere superiore alla latenza e alle risorse necessarie per trasferire dati, sincronizzare le fasi e convertire le rappresentazioni.
Più aumenta la granularità della disaggregazione, più diventa importante coordinare efficacemente calcolo e comunicazione.
Gli acceleratori specializzati diventano complementari alle GPU
La strategia di Gimlet acquista interesse anche perché il panorama dell’hardware AI è diventato molto più articolato.
Le GPU mantengono una grande flessibilità e un’enorme capacità di calcolo, ma sono affiancate da architetture progettate con compromessi differenti. I sistemi near-memory cercano di ridurre il movimento dei dati avvicinando elaborazione e memoria; le architetture dataflow organizzano l’esecuzione intorno al flusso dei dati; i chip SRAM-centrici dispongono di grandi quantità di memoria estremamente vicine alle unità di calcolo.
Gimlet non considera necessariamente queste piattaforme sostitutive delle GPU. Al contrario, la possibilità di utilizzarle insieme è alla base della propria proposta.
Un esempio è il lavoro realizzato con d-Matrix Corsair, acceleratore SRAM-centric dotato di 2 GB di SRAM on-chip e progettato per workload di inference sensibili alla banda di memoria.
Gimlet ha utilizzato gpt-oss-120b come modello principale e un modello da 1,6 miliardi di parametri per lo speculative decoding. Prefill e verifica dei token rimangono sulla GPU, mentre la generazione speculativa viene spostata su Corsair, fase particolarmente sensibile alla banda di memoria.
Nei test con d-Matrix Corsair, rispetto all’esecuzione dello stesso speculative decoder sulla GPU e a parità di consumo energetico, Gimlet ha misurato miglioramenti end-to-end fra 2 e 5 volte nelle configurazioni ottimizzate per l’interattività e fino a 10 volte in quelle orientate all’efficienza energetica.
Anche qui la questione non è stabilire quale chip sia complessivamente più veloce. La domanda diventa quale architettura svolga con maggiore efficienza quella specifica porzione del workload.
L’ottimizzazione arriva fino ai kernel
Una volta scelto il processore più adatto, rimane da assicurarsi che il software riesca a sfruttarlo efficacemente.
Gimlet lavora quindi anche sui kernel, le routine a basso livello utilizzate dai framework di machine learning per eseguire le operazioni matematiche sugli acceleratori.
Con kforge, la startup utilizza l’AI per generare automaticamente kernel ottimizzati a partire da codice PyTorch e supporta backend differenti, tra cui CUDA, ROCm e Metal.
L’obiettivo è ridurre la necessità di ottimizzare manualmente ogni operazione per ciascuna architettura: il workload può rimanere espresso a un livello più alto, mentre il sistema genera l’implementazione più efficiente per il dispositivo al quale lo scheduler ha assegnato il calcolo.
Nei benchmark sui kernel CUDA generati automaticamente, condotti su NVIDIA H100, i kernel hanno raggiunto una velocità media di circa 1,8 volte quella della baseline PyTorch, compreso torch.compile, sui problemi utilizzati da KernelBench.
La generazione automatica pone però anche un problema di affidabilità. Un kernel può superare i test numerici disponibili senza essere matematicamente equivalente all’implementazione originale per tutti gli input.
Nel luglio 2026 Gimlet ha quindi presentato un sistema sperimentale di formal verification dei kernel che traduce le operazioni PyTorch e quelle del kernel ottimizzato in rappresentazioni matematiche confrontabili. Un solver tenta quindi di dimostrarne l’equivalenza oppure di individuare input per i quali i risultati divergono.
Routing, scheduling, compilazione e kernel generation diventano così parti della stessa strategia: scegliere l’hardware più efficiente e adattare il software perché riesca effettivamente a sfruttarlo.
La sfida si sposta anche nel data center
La disaggregazione non può fermarsi al software. Acceleratori differenti devono poter comunicare rapidamente e, quando si sale a centinaia di megawatt di capacità, entrano in gioco alimentazione, networking, raffreddamento e densità molto differenti tra le varie piattaforme.
La inference cloud di Gimlet è costruita per collegare hardware eterogeneo attraverso fabric ad alta velocità e presentarlo allo scheduler come un insieme di risorse utilizzabili per lo stesso workload.
La startup offre questa infrastruttura come servizio gestito, ma il suo stack può essere distribuito anche nei data center dei clienti.
La Series B dà a questa strategia una dimensione industriale decisamente maggiore. Gimlet afferma di essere in espansione verso centinaia di megawatt di capacità gestita e di avere una pipeline di data center misurata in gigawatt. La questione dell’efficienza non riguarda quindi soltanto il prezzo di acquisto del singolo acceleratore: diventa determinante anche il numero di token che un data center riesce a produrre per ogni kilowatt disponibile.
Da 80 a 300 milioni in poco più di cinque mesi
La nuova raccolta segue a distanza molto ravvicinata la Series A da 80 milioni di dollari, annunciata il 23 marzo 2026 e guidata da Menlo Ventures. Allora Gimlet indicava una base clienti triplicata nei cinque mesi successivi all’uscita dallo stealth, con un frontier lab e un hyperscaler tra gli utilizzatori della piattaforma.
La Series B da 300 milioni è guidata da Andreessen Horowitz. Partecipano anche Sapphire Ventures, Menlo Ventures, 645 Ventures, Arm, Eclipse, Emergence, Factory, Hudson River Trading, M12, OnePrime Capital, Prosperity7, QuantumLight, Samsung Ventures, Tiger Global Management, Triatomic, Wing Ventures e XTX Markets.
Tra i nuovi investitori hanno particolare rilievo anche Arm e M12, il fondo di venture capital di Microsoft. Gimlet sta inoltre lavorando con Arm per estendere la compatibilità del proprio software alle diverse architetture della società britannica.
Il rapido passaggio dalla Series A alla valutazione da 3 miliardi di dollari riflette l’interesse per una parte dell’economia dell’AI destinata a pesare sempre di più man mano che i modelli vengono utilizzati su larga scala: non quanto costa addestrarli una volta, ma quanto costa eseguirli continuamente.
Con gli agenti la questione si amplifica ulteriormente. Una richiesta dell’utente può trasformarsi in decine di chiamate sequenziali ai modelli, e ogni miglioramento di latenza, throughput o costo viene moltiplicato lungo l’intero workflow.
La scommessa di Gimlet consiste nel considerare GPU, CPU e acceleratori specializzati non più come piattaforme alternative tra cui sceglierne una, ma come componenti complementari dello stesso sistema di inference. In questa prospettiva, la prestazione del singolo chip diventa meno importante della capacità dello stack di decidere, momento per momento, dove conviene eseguire il calcolo.
La metrica finale è più concreta: quanti token è possibile produrre, con quale latenza e a quale costo, utilizzando una determinata quantità di hardware ed energia.
