Quando un modello risponde '2' alla domanda 'Quanto fa 1+1?' senza aggiungere un'emoticon o una riga di spiegazione, non è solo una curiosità stilistica. Oc-e-Non-v1, costruito a partire da Qwen3-4B-Instruct-2507, riduce della metà la lunghezza media delle risposte e porta in superficie un aspetto spesso trascurato dell'inference locale: il costo dei token in uscita.

Il nome riprende il soprannome che alcuni contemporanei avrebbero dato a Riccardo I d'Inghilterra, Oc-e-Non, 'sì e no' in occitano, per la sua tendenza a usare poche parole. L'autore del progetto ha usato Heretic, un framework per intervenire sul comportamento di un LLM, insieme al file di configurazione config.terse.toml. Non si tratta di un semplice prompt di sistema: il comportamento sintetico viene incorporato nel modello, una differenza non banale per chi cerca risposte prevedibili senza dipendere da istruzioni testuali che il modello può interpretare in modo variabile.

La base scelta è Qwen3-4B-Instruct-2507, indicata come l'ultima versione nativa non-thinking di Qwen conosciuta dall'autore. Anche il controllo dello sforzo di reasoning non è ancora disponibile in Heretic, il che rende questo modello un banco di prova interessante per separare la sintesi dalla capacità di ragionamento.

Dietro il tono leggero c'è un vincolo concreto. La generazione testuale è sequenziale: ogni token aggiuntivo richiede un passaggio di decodifica. In un deployment self-hosted, risposte più corte non migliorano solo la leggibilità; riducono il tempo di completamento e, su carichi batch o con code di richieste, liberano capacità di calcolo. Su un modello da pochi miliardi di parametri il guadagno assoluto per singola chiamata può sembrare modesto, ma su migliaia di richieste l'effetto sul throughput è strutturale.

La sintesi forzata, però, non è neutrale. Togliere spiegazioni e passaggi intermedi può ridurre trasparenza e verificabilità. In contesti regolati o in pipeline in cui serve giustificare una decisione, una risposta secca come 'Sì' può essere un problema, non un vantaggio. Il valore dipende dal carico di lavoro: agenti software che devono passare output compatti a un altro modulo, sistemi di estrazione dati e API sensibili ai costi beneficiano della tersificazione; assistenti educativi, strumenti di debugging e analisi che richiedono motivazioni potrebbero perdere informazione utile.

Per chi valuta deployment on-premise, esperimenti come questo segnalano che l'efficienza dell'output sta diventando una leva di progettazione accanto alla quantization, alla cache e alla scelta dell'hardware. Se un comportamento può essere incorporato nel modello, cambia anche il ruolo del prompt engineering, che da correttore continuo diventa configurazione iniziale.

L'autore stesso invita a non prendere il progetto troppo sul serio, definendolo un esperimento leggero in attesa di Qwen4. Ma la domanda che lascia aperta è concreta: quanta verbosità possiamo togliere prima che la risposta smetta di essere utile?