---
title: "Perplexity AI Lancia il Tokenizer Rust Open Source: 5 Volte Più Veloce di Hugging Face"
date: "2026-05-28"
category: "Intelligenza Artificiale"
tags: ["llm", "open source", "perplexity ai", "rust", "unigram"]
author: "Giuseppe Carruezzo"
description: "Perplexity AI rilascia un nuovo tokenizer Unigram in Rust, riducendo la latenza di 5 volte rispetto a Hugging Face per ottimizzare l'inferenza dei modelli LLM."
source: "https://ainsights.it/blog/perplexity-ai-tokenizer-rust-unigram-performance"
---

# Perplexity AI Lancia il Tokenizer Rust Open Source: 5 Volte Più Veloce di Hugging Face

![Perplexity AI Lancia il Tokenizer Rust Open Source: 5 Volte Più Veloce di Hugging Face](/blogai/backend/uploads/6a1883aaa7aa8.webp)

Il team di ricerca di Perplexity AI ha annunciato la pubblicazione in open source di una nuova implementazione del tokenizer Unigram scritta interamente in Rust. Questo componente, parte del repository di tecnologie di inferenza pplx-garden, promette di rivoluzionare le prestazioni della CPU nei carichi di lavoro legati ai modelli linguistici (LLM), riducendo la latenza p50 di circa 5 volte rispetto allo standard di Hugging Face e abbattendo drasticamente il consumo di risorse computazionali.

-   **5x** — Latenza p50 ridotta (Rispetto al crate tokenizers di Hugging Face)
-   **5-6x** — Utilizzo CPU (Risparmio registrato nello stack di inferenza di Perplexity)
-   **0** — Allocazioni Heap (Nello stato stazionario per massimizzare l efficienza)

## Il collo di bottiglia invisibile dell'inferenza

Sebbene l'attenzione del settore sia quasi sempre focalizzata sull'ottimizzazione dei kernel GPU e delle memorie KV cache, i modelli più piccoli — come quelli utilizzati per embedding, classificazione e reranking — presentano una dinamica differente. Questi modelli sono spesso da due a tre ordini di grandezza più piccoli rispetto ai transformer di frontiera.

In uno scenario in cui un reranker deve valutare centinaia di documenti candidati per ogni singola richiesta, il calcolo sulla GPU può concludersi in pochi millisecondi. Tuttavia, ogni input deve prima passare attraverso la tokenizzazione lato CPU. Quando le dimensioni dei batch sono elevate, la tokenizzazione smette di essere un'operazione trascurabile e diventa una frazione significativa della latenza totale della richiesta.

Il lavoro di Perplexity si concentra in particolare su **XLM-RoBERTa**, un modello con un vocabolario Unigram da 250.000 token addestrato con SentencePiece, ampiamente utilizzato in produzione per attività di ranking e similarità.

## Cos'è la tokenizzazione Unigram?

Introdotta da Kudo nel 2018, la tokenizzazione Unigram modella la segmentazione del testo come un problema del "percorso più probabile". Ad ogni token del vocabolario è assegnata una log-probabilità appresa; il tokenizer sceglie quindi la segmentazione in cui la somma dei punteggi dei token è massima.

Per trovare questo percorso ottimale viene impiegato l'**algoritmo di Viterbi**, una tecnica di programmazione dinamica del 1967. In questo contesto, le posizioni dei byte formano i livelli di un grafo, mentre i token del vocabolario rappresentano gli archi che coprono intervalli di byte contigui.

Il percorso critico dell'algoritmo (hot path) risiede nel ciclo interno che attraversa un "trie" (albero dei prefissi) per ogni posizione di byte. Su un input di 16.000 token, questo processo esegue centinaia di migliaia di transizioni nel trie.

## Analisi delle inefficienze: il confronto con Hugging Face

Il crate `tokenizers` di Hugging Face è lo standard di riferimento in ambiente Rust, ma l'analisi di Perplexity ha evidenziato tre pattern estremamente costosi nelle performance:

### Pro

-   Universalità del supporto vocabolari
-   Integrazione immediata con l ecosistema HF

### Contro

-   Allocazioni heap eccessive (oltre 7.000 per 514 token)
-   Lentezza dovuta all inseguimento dei puntatori nelle HashMap
-   Elevato tasso di cache miss L2 su input lunghi

A una lunghezza di 514 token, l'implementazione di riferimento soffre di un sovraccarico costante: circa 2 KB e 18 allocazioni per ogni singolo token, indipendentemente dalla dimensione dell'input. Questo porta a una degradazione severa quando gli input lunghi superano la capacità della cache L2 del core CPU.

```mermaid
flowchart TD
    A[Input di Testo] --> B[Attraversamento Double-Array Trie]
    B --> C{Controllo Bitmap}
    C -- Valido --> D[Aggiornamento Tabella Viterbi]
    C -- Invalido --> E[Iterazione Byte Successivo]
    D --> F[Estrazione Miglior Percorso]
    F --> G[Token IDs Finali]
```

## Le tre ottimizzazioni chiave di Perplexity

### 1\. Double-Array Trie

Mentre Hugging Face memorizza i figli in una `HashMap` per ogni nodo, richiedendo calcoli hash e de-referenziazioni multiple, Perplexity ha implementato un **double-array trie** (struttura introdotta da Aoe nel 1989). Questa struttura codifica l'intero albero in due array di interi piatti (`base` e `check`). La ricerca di un figlio diventa una semplice operazione aritmetica:

```rust
// Pseudo-logica di ricerca
let next = base[node] + byte;
if check[next] == node {
    // Transizione valida
}
```

Il risultato è drastico: la latenza p50 è scesa da 155 µs (ottenuti con un porting a zero allocazioni) a soli 68 µs.

### 2\. Bitmap e Inline Packing

Per eliminare anche il secondo caricamento dall'array (il controllo `check`), Perplexity ha introdotto una **bitmap per nodo** (32 byte) che indica quali dei 256 possibili byte hanno transizioni valide. Hanno inoltre impacchettato tutti i dati del nodo (bitmap, base, ID token e score) in una singola **linea di cache da 64 byte**. In questo modo, un singolo caricamento dalla memoria fornisce tutte le informazioni necessarie per lo step successivo.

### 3\. Huge Pages (2 MB)

Con un trie di circa 50 MB, l'utilizzo di pagine standard da 4 KB comporterebbe circa 12.000 pagine virtuali, saturando il TLB (Translation Lookaside Buffer) della CPU e causando continui "page-table walks". Utilizzando le **Huge Pages da 2 MB** tramite `mmap`, l'intera struttura risiede in sole 25 pagine, eliminando quasi totalmente i ritardi di traduzione degli indirizzi.

## Risultati dei Benchmark

I test sono stati eseguiti su un core singolo di un processore Intel Xeon Platinum 8488C. I dati mostrano una superiorità netta dell'implementazione di Perplexity rispetto a tutte le alternative esistenti.

> _\[Grafico interattivo — visibile nella versione web dell'articolo\]_

L'efficienza si riflette anche nel numero di istruzioni completate: l'implementazione finale richiede solo 1,04 milioni di istruzioni per un input da 514 token, contro i 3,60 milioni di Hugging Face.

## Punti chiave

-   La tokenizzazione su CPU è un collo di bottiglia critico per modelli di embedding e reranker ad alte prestazioni.
-   L implementazione di Perplexity elimina le allocazioni heap nello stato stazionario, migliorando la stabilità e la velocità.
-   L uso di strutture dati classiche come il Double-Array Trie, unite a ottimizzazioni moderne come le Huge Pages, permette un salto prestazionale di 5x.
-   Il codice è aperto alla comunità tramite il repository pplx-garden sotto licenza MIT.

### Un nuovo standard per l efficienza AI — 4.8/5

Perplexity AI ha dimostrato che c è ancora ampio margine di ottimizzazione nei componenti fondamentali dei sistemi AI. Il loro tokenizer non è solo più veloce, ma ridefinisce l efficienza dell infrastruttura di inferenza per i modelli di produzione.

## FAQ

### Questo tokenizer è compatibile con i modelli Hugging Face esistenti?

Sì, l output è identico a livello di token (token-exact) rispetto all implementazione di riferimento per il vocabolario Unigram di XLM-RoBERTa.

### È necessario configurare il sistema operativo per usare le Huge Pages?

Sì, in produzione è necessario configurare vm.nr\_hugepages all avvio per permettere al trie di sfruttare le pagine da 2 MB.

### Quali sono i vantaggi reali in produzione?

Perplexity ha riportato una riduzione del 5-6x dell utilizzo della CPU e un risparmio di decine di millisecondi nella latenza dei propri sistemi di reranking.

### Supporta il multi-threading?

L implementazione di base è single-threaded per massimizzare l efficienza del core, ma in produzione viene parallelizzata utilizzando il crate Rayon.

## Fonti e riferimenti

1.  [Repository GitHub pplx-garden](https://github.com/perplexityai/pplx-garden)
2.  [Dettagli Tecnici - Perplexity Research](https://research.perplexity.ai/articles/improving-unigram-tokenizer-cpu-performance)

---

*Fonte: [https://ainsights.it/blog/perplexity-ai-tokenizer-rust-unigram-performance](https://ainsights.it/blog/perplexity-ai-tokenizer-rust-unigram-performance)*