Intelligenza Artificiale
Architetture AI on-premise, LLM locali, RAG, agenti autonomi. L’intelligenza che non si può permettere di vedere spenta va posseduta.
Scopri →
Servizi & Sistemi Linux
Progettazione, deploy e gestione di infrastrutture Linux on-premise: dai server all’hardware AI, con dati che restano tuoi.
Scopri →
Admina Enterprise
Governance AI Open Source: audit trail, PII redaction, policy bidirezionali ALLOW/BLOCK/REDACT su qualsiasi modello, locale o remoto.
Scopri Admina →
Ricerca & Sviluppo
Ricerca applicata e prototipazione, dall’AI all’infrastruttura, in collaborazione con università e centri di ricerca.
Scopri →Cos’è KTransformers
KTransformers è un motore di inferenza ibrida CPU/GPU rilasciato con licenza Apache-2.0 da MADSys Lab del Politecnico di Tsinghua, Approaching.AI e 9#AISoft. Fa una cosa che sembra impossibile: far girare modelli Mixture of Experts enormi, come DeepSeek-R1/V3 da 671 miliardi di parametri, su una singola GPU da 24 GB (una RTX 4090) affiancata da RAM di sistema abbondante, dell’ordine dei 512 GB. Il lavoro è stato pubblicato a SOSP 2025, la principale conferenza di sistemi.
Nota. Le cifre di prestazione qui riportate provengono dalla documentazione del progetto e da benchmark della comunità, non da test indipendenti di noze. Dipendono molto da hardware, quantizzazione e configurazione, e si riferiscono alle versioni indicate. Le riportiamo come indicative.
L’idea: gli esperti stanno in RAM, l’hot path sulla GPU
Il trucco nasce da una proprietà dei modelli MoE: sono sparsi. Un modello come DeepSeek-R1 ha 671 miliardi di parametri totali, ma per ogni token ne attiva solo una piccola frazione, perché il router sceglie pochi esperti tra le centinaia disponibili. La stragrande maggioranza di quei parametri, quindi, per un dato token sta ferma.
KTransformers sfrutta questa asimmetria distribuendo il modello tra GPU e CPU secondo cosa serve davvero, e quando. I componenti dell’hot path, cioè l’attenzione (MLA nel caso di DeepSeek) e la KV cache, restano sulla GPU, dove la banda di memoria conta di più. Gli esperti della parte MoE, che occupano il grosso dei parametri ma vengono toccati raramente, vivono nella RAM di sistema, molto più capiente e molto più economica della VRAM. È lo stesso cambio di prospettiva che abbiamo raccontato per colibri e DwarfStar 4: la quantità di VRAM smette di essere un muro e diventa una delle variabili di un sistema a più livelli, dove RAM e disco entrano nella gerarchia.
Come ci riesce: i kernel CPU contano
Spostare gli esperti in RAM ha un costo: qualcuno deve calcolarli, e quel qualcuno è la CPU. Se il calcolo lato CPU è lento, l’intero vantaggio svanisce. È qui che sta il contributo tecnico di KTransformers: kernel CPU molto veloci, scritti per sfruttare le istruzioni Intel AMX e AVX-512 su quantizzazioni INT4/INT8. Nei benchmark del progetto, il kernel MoE basato su AMX arriva fino a circa 27,8× più veloce dell’implementazione di llama.cpp su un test con 2×32 core (dove llama.cpp fermava a circa 10,31 token/s).
Attorno a questo ci sono le altre tecniche che rendono il tutto praticabile:
- Gestione della memoria NUMA-aware, per i sistemi CPU multi-socket dove la località della RAM cambia le prestazioni.
- Kernel GPU quantizzati (Marlin) e pesi ibridi FP8, con kernel FP8 che estendono il contesto fino a circa 139K token su 24 GB di VRAM.
- Una cache di prefisso a tre livelli (GPU, CPU, disco) per riusare il lavoro già fatto lungo la gerarchia di memoria.
Le prestazioni, prese come indicative, danno l’idea del salto: sul 671B il prefill arriva fino a circa 286 token/s in configurazioni ottimizzate; la generazione è più lenta e dipende molto dall’hardware. In una configurazione server con 8 GPU L20 e uno Xeon, il progetto riporta circa 227 token/s aggregati e 87 token/s in output con 8 richieste concorrenti. Non è la velocità di un cluster dedicato, ma è la differenza tra “questo modello non ci gira” e “questo modello ci gira”.
Cosa ci gira, e con quale hardware
KTransformers si è mosso in fretta dietro alla frontiera open weight. La versione v0.6.3 (giugno 2026) dichiara supporto, spesso “day-0”, a una lista che è un chi è chi dei MoE aperti: DeepSeek-V3/R1, Kimi K2/K2.5, GLM-5 e GLM-5.2, Qwen3-MoE e Qwen3-Next, MiniMax. Sul fronte hardware va oltre NVIDIA, con supporto ad AMD ROCm, Intel Arc e NPU Ascend.
Non è solo inferenza: il progetto ha aggiunto anche il fine-tuning su hardware modesto, integrandosi con LLaMA-Factory. Un SFT di DeepSeek-V3 gira, nei dati riportati, a circa 3,7 iterazioni al secondo su 4×RTX 4090 con circa 80 GB di memoria totale, un risultato descritto come 6-12× più veloce rispetto ad alternative comparabili. Sul piano dell’integrazione, KTransformers si aggancia a SGLang per il serving, agli strumenti dell’ecosistema HuggingFace Transformers, espone API compatibili con OpenAI e legge i formati quantizzati GGUF.
Soluzioni simili
KTransformers è la punta più visibile di un movimento più ampio, e vale la pena inquadrarlo accanto agli altri approcci, perché i compromessi sono diversi.
- llama.cpp ha reso mainstream l’idea dell’offload selettivo: con l’opzione
--override-tensorsi scelgono quali tensori (tipicamente gli esperti MoE) tenere sulla CPU e quali sulla GPU. È portabile e universale; KTransformers punta invece su kernel CPU specializzati (AMX) e batte llama.cpp proprio sul calcolo lato CPU. - ik_llama.cpp, un fork di llama.cpp, spinge su quantizzazioni e kernel CPU ottimizzati per i MoE, in una nicchia simile a KTransformers ma nella tradizione di llama.cpp.
- PowerInfer e Fiddler attaccano lo stesso problema da angoli diversi: PowerInfer separa neuroni “caldi” e “freddi” tra GPU e CPU, Fiddler ottimizza il percorso di calcolo degli esperti su CPU.
- E poi ci sono i motori di cui abbiamo già scritto: colibri, che streamma gli esperti dal disco NVMe anziché tenerli in RAM, e DwarfStar 4, che fa lo stesso con la KV cache.
La linea che li unisce è una sola: i modelli MoE di frontiera sono grandi ma sparsi, e la sparsità è una leva. Chi la sfrutta con la RAM (KTransformers), chi con il disco (colibri), chi separando caldo e freddo (PowerInfer). Il risultato pratico è lo stesso: la frontiera scende dal data center al server sotto la scrivania.
Cosa ne pensiamo
KTransformers è un tassello importante di una storia che seguiamo pezzo per pezzo. Ogni volta che esce un modello a pesi aperti sempre più grande, da GLM 5.2 a Inkling fino a Kimi K3 da 2,8 trilioni di parametri (con i pesi in arrivo), la domanda pratica è sempre la stessa: ci gira davvero, e su cosa? Motori come KTransformers rispondono che sì, ci gira, e su hardware che un’azienda può permettersi: una workstation con una GPU e tanta RAM, non un cluster.
È esattamente la direzione in cui lavoriamo. Un modello di frontiera che gira on-premise, dove il dato non lascia il perimetro, non è più un esercizio teorico: è una scelta di sovranità che diventa possibile perché i sistemi la rendono economica. Poi resta l’altra metà del lavoro, governare ciò che gira, con audit e policy su qualunque modello, come fa Admina. È il senso di Open Intelligence, Secure Governance: possedere il pavimento operativo, su infrastruttura Linux che resta tua, e tenerne il controllo. Un MoE da 671 miliardi di parametri su una singola 4090, un anno fa, sembrava una battuta. Oggi è una questione di kernel, di RAM e di come distribuisci il lavoro.