
Kolibri vs Intern-Decision 4B: Uno scrive documenti, l'altro si rifiuta di scrivere qualsiasi cosa
- openaiNUOVOOpenAI: GPT-6.1 Sol2026-09-2952Intelligenza
- anthropicNUOVOAnthropic: Claude Sonnet 5.52026-09-2856Intelligenza
- typesafeNUOVOTypeSafe: Jev 1.132026-09-24$0.04 / $0.00 per 1M di token · 217 tok/s
- OpenAINUOVOOpenAI: GPT-6 Luna2026-09-2238Intelligenza
- OpenAINUOVOOpenAI: GPT-6 Sol2026-09-2248Intelligenza
- AnthropicNUOVOAnthropic: Claude Opus 5.52026-09-2258Intelligenza
- xAINUOVOGrok 4.72026-09-2146Intelligenza
- OrcaOrca: OrcaCyber Zero 1.02026-09-17$3.00 / $7.50 per 1M di token · 117 tok/s
- OrcaOrca: OrcaVerify Text 1.02026-09-16$2.00 / $0.00 per 1M di token · 969 tok/s
- DeepSeekDeepSeek: DeepSeek V4.1 Flash2026-09-1040Intelligenza
- OpenAIOpenAI: GPT-6 Astra2026-09-0453Intelligenza77Codice
- GoogleGoogle: Gemini 3.8 Flash2026-09-0241Intelligenza76Codice
- AlibabaQwen: Qwen3.8 Max (0902)2026-09-0245Intelligenza76Codice
- AnthropicAnthropic: Claude Fable 5.12026-09-0153Intelligenza82Codice
- TencentTencent: Hy4 preview2026-08-28$0.83 / $2.50 per 1M di token · 52 tok/s
- AlibabaQwen: Qwen3.8 Flash2026-08-26$0.15 / $0.47 per 1M di token · 100 tok/s
- z-aiZ.ai: GLM 5.3 Flash2026-08-2642Intelligenza72Codice
- DeepSeekDeepSeek: DeepSeek V4 Flash Vision (Exp)2026-08-21$0.22 / $0.66 per 1M di token · 214 tok/s
- z-aiZ.ai: GLM 5.32026-08-1845Intelligenza75Codice
- obsidianQwen3.8 27B2026-08-1534Intelligenza68Codice
La cosa più utile da notare riguardo a Kolibri e Intern-Decision-4B è che non sono lo stesso tipo di oggetto, e trattare questa come una comparazione modello contro modello sarebbe un errore di categoria. Kolibri è il modello linguistico mixture-of-experts da 78,1 miliardi di parametri di Aleph Alpha, rilasciato il 3 ottobre 2026, che attiva 3,46 miliardi di parametri per token e scrive testo in tedesco e in inglese. Intern-Decision-4B è un modello decisionale strutturato multimodale da 4,54 miliardi di parametri del team InternLM, caricato su Hugging Face il 26 settembre 2026, la cui scheda afferma senza mezzi termini che esso "non chiama generate() né campiona testo in forma libera" affatto. Uno produce prosa. L'altro produce una distribuzione di probabilità sulle opzioni che gli fornite, in un singolo passaggio in avanti, e non ha alcuna capacità di scrivere una frase. Diventano concorrenti solo in una ristretta situazione, e sapere esattamente quale sia quella situazione è, guarda caso, la cosa più utile in entrambe le pubblicazioni.
Due release, due affermazioni stringate completamente diverse
La scheda di Kolibri è la specifica di un grande modello linguistico sparso: 50 livelli, ognuno dei quali è un mixture-of-experts, 384 esperti per livello con uno condiviso e sei instradati, un contesto nativo di 262.144 token validato fino a 1.048.576, quattro livelli di sforzo di ragionamento, tool calling in stile Hermes con un parser vLLM incluso, pesi FP8 in blocchi 128×128 e termini Apache 2.0. Il suo addestramento ha utilizzato 20.000 miliardi di token su 768 NVIDIA B200 nell'arco di 21 giorni — 392.000 ore GPU a un valore riportato di 6,4×10²³ FLOP e un valore stimato di 9,5×10² MWh, incluso l'overhead del data center, escludendo il fine-tuning supervisionato e l'apprendimento per rinforzo. La configurazione minima di servizio della scheda è due schede A100 da 80 GB, due H100 SXM5, una H200, una B200 o una B300, e l'ingombro FP8 è di circa 78 GB. È un'infrastruttura seria, e risponde alle domande generando testo.
Intern-Decision-4B è il tipo opposto di oggetto e la scheda è di una franchezza rinfrescante al riguardo. È un fine-tune di Qwen3.5-4B in cui la torre visiva e il proiettore sono congelati e viene addestrato solo il backbone linguistico. Gli si passa uno stato, uno schema di domande con nome e, facoltativamente, fino a otto immagini, e restituisce contemporaneamente una distribuzione sulle risposte candidate per ogni domanda. Il meccanismo è insolito e vale la pena enunciarlo con precisione: le opzioni sono mappate a simboli a token singolo che coprono A–Z, a–z e 0–9 — 62 candidati, quindi un massimo di 62 opzioni per domanda — il prompt viene renderizzato con un segnaposto per campo, e il modello legge i logits nella posizione immediatamente prima di ciascun segnaposto. La softmax opera solo sui logits dei simboli consentiti per quel campo, una temperatura specifica del checkpoint calibra il risultato, e i simboli vengono rimappati ai valori originali delle tue opzioni come JSON tipizzato. Non c'è alcun ciclo di decodifica, né campionamento, né prosa.
• Output — Kolibri: testo generato liberamente in tedesco o inglese, chiamate a strumenti, tracce di ragionamento. Intern-Decision-4B: risposte JSON tipizzate con una probabilità per opzione.
• Parametri — Kolibri: 78.103.074.560 totali, 3.457.573.120 attivi. Intern-Decision-4B: 4,54 miliardi distribuiti su quattro shard safetensors in bfloat16, con una torre di visione congelata.
• Input — Kolibri: solo testo. Intern-Decision-4B: testo più fino a otto immagini.
• Capacità di domande — Intern-Decision-4B: fino a 62 opzioni per campo, in un singolo forward pass, con le tipologie di domanda 'choice', 'score' e 'noul' (sì/no). Kolibri: illimitata in linea di principio, un token alla volta in pratica.
• Lingua — Kolibri: tedesco e inglese per costruzione. Intern-Decision-4B: qualunque cosa porti con sé Qwen3.5-4B, con tutte le suite di valutazione pubblicate in inglese.
• Latenza — Intern-Decision-4B: 44,16 ms di media, 44,03 ms di mediana e 44,60 ms P95 per query su una singola RTX 4090, secondo la sua stessa misurazione. Kolibri: nessun dato pubblicato per query, in assoluto.
• Licenza — entrambe Apache 2.0; Intern-Decision-4B viene distribuito con il file di licenza Qwen conservato insieme ad esso.

Perché mai esiste uno scorer 4B
La tesi a favore di Intern-Decision-4B non è che sia piccolo. È che chiedere a un grande modello generativo una probabilità non equivale a misurarla, e la differenza è misurabile.
La tabella di benchmark della scheda stessa sostiene la tesi con una quantità insolita di auto-rivelazione. Su sette suite di accuratezza, Intern-Decision-4B ha una media di 90,02 — contro 88,74 della baseline più forte con cui si confronta, un modello chiamato Jev. Ma l'accuratezza è la metà poco interessante. La tabella riporta anche il punteggio di Brier e l'errore di calibrazione atteso, e lì il quadro è più severo. Il 4B registra un Brier di 0,347 e un ECE di 0,065, contro 0,358 e 0,095 di Jev. È nei fratelli minori che la storia della calibrazione diventa davvero informativa. Intern-Decision-2B ottiene una media di 84,68, ben davanti al modello 0.8B a 79,38 — eppure il suo ECE di 0,100 è peggiore dello 0,066 del 0.8B e dello 0,065 del 4B, con un Brier di 0,437 contro lo 0,530 del 0.8B. Il più accurato dei due modelli piccoli è il meno onesto riguardo alla propria confidenza. Se avessi dato per scontato che la calibrazione migliori con l'accuratezza, o con il numero di parametri, quella tabella è il controesempio su entrambi i fronti.
Una seconda diagnostica separata copre 96 casi costruiti con distribuzioni di riferimento esatte anziché etichette hard campionate — estrazioni casuali, eventi composti, storia condizionata, puzzle di probabilità. L'errore del modello 4B su quel pilot è sceso da 0,628 a 0,550 sulla metrica riportata, mentre il modello di confronto si attestava a 0,595. La scheda specifica esplicitamente che questo pilot non è stato usato per adattare o selezionare la temperatura pubblicata; la temperatura del 4B, 1,992418, è stata adattata separatamente su un set di calibrazione. Il team di InternLM ha anche rilasciato il benchmark stesso all'interno del repository GitHub — il generatore deterministico, i riferimenti e lo scorer offline — il che significa che l'affermazione sulla calibrazione è di quel raro tipo che una terza parte può effettivamente rieseguire invece di prenderla per fede.
Nulla nel rilascio di Kolibri offre un equivalente. La sua tabella di confronto riporta l'accuratezza di quattordici modelli su un unico harness di un fornitore, e l'accuratezza è ciò su cui si può misurare un modello generativo. Non c'è alcun valore di calibrazione, nessun Brier o ECE da nessuna parte nel materiale, e non c'è modo di chiedergli «la probabilità che questa clausola contrattuale sia azionabile» che non comporti campionare una frase e leggerla.
L'unica cucitura in cui si incontrano davvero
Metti i due fianco a fianco in una pipeline reale e le rispettive forme diventano evidenti. Un flusso di lavoro documentale tedesco ha bisogno di entrambe le metà, e nessuno dei due strumenti copre la metà dell'altro.
Kolibri è la metà che legge e scrive. Un team con contratti o documentazione tecnica in tedesco ottiene una finestra nativa da 262.144 token, una cache KV in FP8, un tokenizer bilingue che Aleph Alpha dichiara a 4,90 byte medi per token su testi web in tedesco, e il tool calling di Hermes — vale a dire, un modello in grado di riassumere un documento depositato, redigere una risposta e gestire un ciclo di tool. Ciò che non sa fare è comunicarti il proprio livello di confidenza in modo che tu possa verificarlo, perché tutto ciò che emette è una stringa campionata.
Intern-Decision-4B è la metà che decide. Data una pagina di testo tedesco e un insieme fisso di opzioni, restituisce una distribuzione calibrata in 44 millisecondi su una singola GPU consumer, senza alcun passaggio di generazione e quindi senza alcuna varianza di campionamento. Ciò che non è in grado di fare è produrre il testo tedesco in primo luogo, e le sue suite di valutazione pubblicate sono in inglese — il suo comportamento in tedesco è ereditato dalla base Qwen3.5-4B anziché essere stato addestrato allo scopo, il che rappresenta un limite reale per un deployment in lingua tedesca e che nessuno ha valutato.
Quindi, la risposta ingegneristica onesta per un flusso di lavoro regolamentato in lingua tedesca è che queste sono due fasi di un’unica pipeline, non due candidati per un unico slot. La domanda pratica è dove viene eseguito ciascuno. Kolibri richiede due H100 o una B200 e circa 78 GB. Intern-Decision-4 richiede una RTX 4090 ed esegue una query in meno di 1 secondo. L’asimmetria di costo è di circa due ordini di grandezza sull’hardware, e indica un’architettura in cui un modello piccolo viene eseguito in modo continuo su ogni caso e il grande generatore viene invocato solo quando un caso richiede prosa. È una scelta più economica e più favorevole agli audit rispetto all’instradare ogni caso attraverso il modello 78B per ottenere una risposta che poi devi interpretare.

La realtà dell'hosting per entrambi, e a cosa serve il livello
Nessuno dei due modelli è disponibile come API ospitata, e lo abbiamo verificato invece di darlo per scontato. Intern-Decision-4B non ha un endpoint del fornitore; il rilascio consiste nei pesi, in un repository GitHub e in uno Hugging Face Space. I suoi conteggi di download e like sono cambiati da metà settimana, il che indica che le persone lo stanno adottando, ma non esiste ancora alcuna rotta richiamabile a pagamento che potremmo indicare.
Allo stesso modo, Kolibri non ha uno SKU API di Aleph Alpha — il rilascio consiste in pesi, un report tecnico e un'immagine container su ghcr.io/aleph-alpha/aleph-alpha-inference. E non è su OrcaRouter: abbiamo sondato il catalogo con ogni grafia del prefisso del fornitore e del nome del modello e restituisce "not found", cosa che preferiamo dire piuttosto che lasciar intendere il contrario.
Quello che un livello di routing cambia qui non è l'accesso a questi due modelli, è l'economia del decidere se acquistare l'hardware per l'uno o per l'altro. Il test onesto pre-acquisto per la metà generativa è eseguire il carico di lavoro su un piccolo tier mixture-of-experts già instradato — la variante Gemma 4 26B-A4B a $0,06 per milione di token in input e $0,33 per milione in output con una finestra di 262.144 token e input di testo, immagini e video — su una chiave compatibile con OpenAI al prezzo di listino del fornitore senza nulla in più, e vedere se il carico di lavoro sui documenti tedeschi ha davvero bisogno di 78 miliardi di parametri prima di ordinare le GPU. La metà decisionale non ha una scorciatoia del genere, perché il comportamento della distribuzione calibrata è l'intero punto del modello e nessun tier instradato lo fa. Ma questa è di per sé la scoperta: ti dice che lo scorer da 4B è la parte che ospiterai davvero in autonomia, e il generatore è la parte che vale la pena ritestare rispetto a qualcosa che puoi noleggiare questo pomeriggio.
Cosa lo risolverebbe
Due misurazioni, e nessuna delle due esiste ancora.
Il primo è Intern-Decision-4B su input tedesco. Ogni suite pubblicata è in inglese e il modello è un fine-tune di una base multilingue, quindi la sua calibrazione in tedesco è sconosciuta — e la calibrazione è esattamente la proprietà che non si trasferisce gratuitamente da una lingua all'altra. Una versione tedesca del pilot di distribuzione a 96 casi sarebbe il singolo artefatto più informativo che chiunque potrebbe pubblicare su questo modello.
Il secondo è il costo per decisione di Kolibri. La sua tesi di economia di servizio è una frontiera di Pareto della qualità rispetto ai token decodificati al secondo per GPU, e non esiste una pagina di Artificial Analysis per Kolibri né una replica di terze parti del sistema di test. Finché qualcuno non lo esegue, "78 miliardi di parametri" è una specifica piuttosto che un costo, e la ragione per mantenere uno scorer da 44 millisecondi davanti ad esso rimane un argomento di progettazione piuttosto che un argomento misurato.
Fino ad allora, il modo giusto di leggere questo abbinamento non è come una gara. Intern-Decision-4B è il rilascio tecnicamente più interessante dei due, perché l'output strutturato consapevole della calibrazione è una capacità che quasi nessun modello generativo offre, e la sua scheda ti permette di verificare l'affermazione. Kolibri è il rilascio di maggiore impatto, perché un laboratorio europeo che distribuisce un modello Apache 2.0 da 78 miliardi di parametri, con la pipeline dati pubblicata insieme ad esso, è più un evento di supply chain che un evento legato al modello. Nessuno dei due sostituisce l'altro. I team che necessitano di entrambi dovrebbero pianificare per entrambi e dimensionare l'hardware di conseguenza, e l'harness attorno a essi è dove va effettivamente lo sforzo ingegneristico.

