Gli articoli di Millebit sono scritti con l’intelligenza artificiale a partire da fonti citate in ogni pezzo. Come lavoriamo
Interesse pratico per scalabilità e affidabilità dei sistemi AI, dalle verifiche video alle soluzioni hardware e al throughput massivo.
Want better quality output from your agent? Give it a way to verify its own work. Love what Warp is doing here: every agent gets a computer and brings back a video of what it did. I do something similar in my workflow - on top of E2E tests, Claude gives me recorded videos + screenshots as part of the evidence work is "done". My bet is verification becomes one of the most important problems to work on this year.
I always thought it was a shame that modest default stack setups made alloca() a generally-frowned-upon technique in C/C++. With 64 bit architectures, give every stack a virtual address space equal to the physical memory by default! You can do a surprisingly good job of memory management with just the stack, and I contend that it has both correctness and performance advantages. Allocations are a trivial pointer adjustment, and frees are literally free. Keeping everything linearly packed is friendlier for all layers of the cache hierarchy, and it makes keeping everything in huge / gigantic pages easy.
John Carmack propone stack virtuali molto più grandi su 64 bit per sdoganare alloca e uno stile centrato sullo stack. Conta perché Carmack ha spremuto processore e cache per anni. Il bersaglio sono stack predefiniti piccoli e policy nate quando l’indirizzamento era stretto. Promessa del bump allocator: «allocazioni come aggiustamento del puntatore» e free che non costa.
Il collo di bottiglia passa dall’allocatore alla memoria virtuale. Stack enormi implicano commit su richiesta e page fault al primo accesso. Il millisecondo della prima pagina pesa più dei microsecondi risparmiati evitando malloc. Servono temporanei prevedibili, altrimenti scatti di latenza difficili da riprodurre. Giudizio della redazione: idea valida come tecnica locale, non default di piattaforma. Beneficia codice engine e HPC su misura.
DeepSeek is serving 150T tokens a day on one cluster, more than the open model inference on OpenRouter, Fireworks, Together, and BaseTen combined. Below is my reconstruction of various inference volume reports across said companies.
La redazione giudica la tesi plausibile, ma chiede una verifica quantitativa indipendente su volumi e SLO. Nathan Lambert, ricercatore dell’Allen Institute, attribuisce a DeepSeek «150 trilioni di token al giorno» su un solo cluster. Se il dato tiene, il KPI per chi pianifica infrastrutture diventa il volume di token serviti con SLO credibili. In pratica il collo di bottiglia si sposta dal numero di modelli al motore di erogazione, e il vantaggio va a chi controlla fine tuning e scheduler dell’inferenza.
Per validare, serve un confronto controllato su un workload comune con log firmati che riportino token serviti e latenza p95 per GPU su finestre orarie, affiancando DeepSeek a un operatore come OpenRouter. La misura che conta è il throughput per GPU stabile sotto SLO pubblici, non il catalogo modelli.
Addy Osmani sposta il baricentro sugli esiti verificabili. Il suo lavoro su Chrome dà contesto a un messaggio semplice: la qualità sale quando l’agente dimostra cosa ha fatto. Warp assegna un computer a ogni agente e restituisce un video. Nel suo flusso Claude produce video e screenshot oltre ai test E2E. La posizione prende di mira il ciclo esegui e spera con un log e i benchmark sintetici che non chiudono un compito.
Cambia la definizione di fatto: un compito è completo con test E2E verdi e una traccia verificabile. Questo implica pipeline con ambienti isolati e riproducibili per ogni run, raccolta e archiviazione delle evidenze e integrazione in CI con criteri di accettazione e limiti su dati e credenziali. La redazione concorda. Gli E2E restano fragili e il video può ingannare, quindi servono ripetibilità e storage a prova di manomissione. Chi offre sandbox e prove firmate arriverà prima.