Yzma: embedding fino a 2,6x più veloci di Ollama, il confronto

Yzma è un motore di inferenza scritto in Go che fa una cosa semplice da dire e rara da fare: chiama llama.cpp dentro al suo stesso processo. Niente server separato, niente REST, niente attese. Il risultato, sui numeri pubblicati dal team, è un motore che genera gli embedding fino a 2,6x più in fretta di Ollama. In questo articolo prendiamo i benchmark di riferimento, facciamo i conti noi e guardiamo cosa cambia quando l'embedding diventa il collo di bottiglia del tuo RAG.

Cos'è Yzma e perché dovrebbe interessarti

Yzma è un motore di inferenza open source scritto in Go puro. Non reimplementa il motore: incorpora llama.cpp in-process via purego/ffi, senza CGo. Legge i modelli GGUF e gira su CUDA, Metal, Vulkan e OpenVINO, fino ad arrivare al browser con WebGPU. Copre circa il 96% della funzionalità di llama.cpp, con punte di 840 tok/s su una workstation desktop e 30 tok/s su una scheda Arduino.

Per chi non ha mai sentito parlare di engine di inferenza: è il software che fa girare il modello. Ollama è uno di questi engine — un server che espone un'API locale. Yzma si posiziona in un punto diverso: è una libreria che metti dentro la tua applicazione Go, con l'opzione di un server OpenAI-compatible se ti serve.

La differenza di architettura è tutto il punto: quando il tuo codice chiama un embedding, in Ollama la richiesta parte verso un server, attraversa la rete, il server decodifica la richiesta, llama.cpp calcola, il vettore torna indietro e il server lo incapsula di nuovo. In Yzma il vettore nasce dentro il tuo processo e arriva direttamente alla tua variabile.

I numeri: embedding 2,6x più veloci

I benchmark di riferimento sono pubblicati sul sito del progetto, raccolti il 16 ottobre 2026 su un laptop Intel Core i9-13900HX con RTX 4070. Versioni usate: yzma 1.30.0, Ollama 0.40.5, Docker Model Runner v1.2.8. Modello di embedding: bge-small, 29 token di prompt, vettore di 384 dimensioni.

Motore	Latenza per embedding	Throughput prompt	Indice di 10.000 documenti
Yzma	1,7 ms	17.123 tok/s	17 s
Ollama	4,5 ms	6.393 tok/s	45 s
Docker Model Runner	4,6 ms	6.360 tok/s	46 s

Facciamo i conti da soli, senza fidarci della tabella:

• Rapporto di latenza: 4,5 ms ÷ 1,7 ms = 2,65. Il "2,6x" dichiarato torna esatto.
• Rapporto di throughput: 17.123 ÷ 6.393 = 2,68. Stesso risultato dal secondo lato.
• Per un indice di 10.000 documenti: 10.000 × 1,7 ms = 17 s con Yzma; 10.000 × 4,5 ms = 45 s con Ollama. Un indice che impazzisce in 17 secondi richiede un quarto del tempo con il motore più usato.

La stessa pagina misura anche la generazione di testo, dove il vantaggio si assottiglia: 9,2–12,1% in più in velocità e un time-to-first-token tra il 48% e il 60% di quello del server. Con Gemma 4: 118,6 tok/s contro 105,8 (ttft 12,3 ms contro 24,6). Con Qwen3-VL: 166,9 tok/s contro 152,8 (ttft 9,0 contro 15,1).

Perché l'in-process vince sulle embedding

La ragione è tutta meccanica. In un server, il round trip REST esiste a prescindere da cosa il modello restituisce. Per la generazione di testo il round trip è quasi gratuito: il token arriva via streaming e il trasferimento di rete è una frazione minima del tempo totale. Per l'embedding no: la risposta è un solo vettore, magari 384 numeri. Il modello lavora per meno di 2 millisecondi, e la parte fissa — HTTP, serializzazione, decodifica della richiesta — pesa la stessa cifra.

In numeri: se il round trip REST costa ~2,8 ms e il calcolo ~1,7 ms, il server totalizza 4,5 ms e l'in-process 1,7 ms. Il 62% del tempo di Ollama in quella misura non è il modello: è la plumbing.

La conseguenza pratica riguarda chi costruisce RAG: l'indicizzazione è il punto in cui le embedding si chiamano a migliaia, l'una dietro l'altra. Un quarto del tempo di indicizzazione è tempo di setup rimborsato, e una latenza di 1,7 ms rende sensato fare embedding di più in fase di query. Il confronto più ampio tra i due engine — architettura, formati, quando scegliere — ce l'abbiamo già fatto in Ollama vs llama.cpp: sotto il cofano; e se vuoi capire dove finiscono le tue embedding una volta calcolate, parte da RAG: fai domande ai tuoi documenti.

Come lo usi

Yzma è prima di tutto una libreria per servizi Go. Tre comandi:

go install github.com/hybridgroup/yzma@latest
yzma install --lib
export YZMA_LIB=$HOME/yzma

Poi, nel tuo codice Go, la libreria carica il modello GGUF e restituisce il vettore della tua chiamata, senza avviare nessun altro processo. Se invece vuoi un server: yzma ne parte uno con API compatibile OpenAI, così un client esistente — Python, Node, curl — punta a localhost al posto di Ollama.

Se non va: se la riga go install non trova i toolchain, aggiorna Go; se il server non risponde sul porto locale, verifica che la variabile YZMA_LIB punti davvero alla libreria installata — è il motivo di fallimento più comune nel setup.

E i limiti?

• I numeri sono pubblicati dal team di yzma, su una sola macchina di riferimento. Nessun laboratorio indipendente ha replicato la misurazione: trattali come dichiarati, non come verificati.
• Yzma non è un sostituto drop-in di Ollama: non erediti la libreria di modelli, l'ecosistema e gli aggiornamenti settimanali. È un'alternativa per chi costruisce servizi in Go e vuole il percorso più corto verso l'embedding.
• Il vantaggio sul testo generato è marginale (9–12%). Se il tuo caso è il chatbot, l'argomento Yzma si regge solo sul time-to-first-token, non sul throughput.

Fonti

• Benchmark ufficiali del progetto
• Repository GitHub di Yzma
• Thread Hacker News del 19 ottobre 2026

In sintesi

Yzma incorpora llama.cpp dentro al processo, senza REST in mezzo: sul benchmark pubblicato dal team (16 ottobre 2026, i9-13900HX + RTX 4070) gli embedding scendono da 4,5 ms a 1,7 ms, il che è 2,6x — e il calcolo torna: 4,5 ÷ 1,7 = 2,65. L'indice di 10.000 documenti passa da 45 a 17 secondi. Sul testo generato il vantaggio è 9–12% con un time-to-first-token dimezzato. È open source, in Go, e copre circa il 96% di llama.cpp: i numeri li ha pubblicati il vendor su una singola macchina, quindi prima di decidere, misura sul tuo hardware.

Articolo generato con IA