UnlimitedOCR v2 di Baidu: il modello OCR 3B per PDF di 300 pagine
300 pagine. Una sola richiesta.
UnlimitedOCR v2, pubblicato da Baidu come Unlimited OCR 2, è un modello OCR da circa 3 miliardi di parametri pensato per estrarre testo, tabelle e struttura da documenti lunghi. Baidu lo ha valutato su documenti da 103 a 300 pagine.
La difficoltà è mantenere il filo: una tabella può continuare nella pagina successiva, così come un paragrafo o una sezione. V2 introduce una nuova gestione dell'attention e della memoria per affrontare questi passaggi.
Vediamo cosa cambia rispetto a UnlimitedOCR v1, come si comporta v2 nei benchmark e come provarlo in locale. Su Mac trovi gli esempi con la mia libreria unlimitedocr.c, scritta in C con kernel Metal e wrapper Python, e le funzioni di ImageXtract per lavorare sui documenti senza scrivere codice.
- Dimensione nominale del modello
- 3B MoE
- MPDocBench, misura Baidu
- 84,59
- MarathonDocBench, misura Baidu
- 77,06
- File v2 mixed Q4 in unlimitedocr.c
- circa 1,85 GB
In questa guida
UnlimitedOCR v1 e v2: cosa cambia
Baidu ha presentato Unlimited OCR il 22 giugno 2026 e Unlimited OCR 2 il 27 ottobre 2026, secondo il registro delle release ufficiale. Entrambi eseguono document parsing: dalle immagini delle pagine estraggono il testo e identificano elementi come titoli, paragrafi, formule e tabelle, insieme alla loro posizione.
La famiglia deriva da DeepSeek-OCR: conserva il DeepEncoder per rappresentare le immagini e un decoder Mixture-of-Experts (MoE). I paper indicano circa 3B parametri totali e 0,5B attivi per token. Il numero di parametri attivi riguarda il calcolo del decoder e non equivale alla memoria necessaria per caricare il modello.
| Aspetto | UnlimitedOCR v1 | UnlimitedOCR v2 |
|---|---|---|
| Attention del decoder | R-SWA | SR-SWA |
| Testo già generato | Finestra locale, 128 token di default | Finestra locale e selezione dei riferimenti visivi |
| Accesso alle immagini | Tutti i token visivi di riferimento | Selezione per pagina e per blocchi di token |
| Lunghezza massima di training | 32K token | 64K token |
| Obiettivo documentale | Decine di pagine | Centinaia di pagine con gestione a finestre |
| Runtime ufficiali documentati | Transformers, vLLM, SGLang | Transformers e SGLang personalizzato |
UnlimitedOCR v1: leggere più pagine senza accumulare tutto il testo
In un decoder con full attention, ogni nuovo token può consultare tutta la sequenza precedente. Durante una lunga trascrizione, la KV cache cresce insieme al testo prodotto. UnlimitedOCR v1 sostituisce questa attention con la Reference Sliding Window Attention, abbreviata R-SWA.
Il modello conserva due tipi di memoria: i token di riferimento, cioè immagini e prompt, e una finestra degli ultimi token generati. Il testo più vecchio esce dalla finestra; le immagini restano consultabili.
La KV cache resta stabile durante la generazione per un documento già caricato. Se aggiungi pagine, aumentano comunque i token visivi da conservare e consultare: è questo il limite che v2 affronta.
Benchmark di v1 e confronto con Qwen2.5-VL-72B
Il primo modello era già competitivo nell'OCR di una singola pagina. Nel paper v1 raggiunge 93,23 su OmniDocBench v1.5, contro 87,01 di DeepSeek-OCR. Nella stessa tabella, v1 supera anche Qwen2.5-VL-72B e Qwen3-VL-235B sul punteggio Overall di OmniDocBench v1.5.
| Modello | Parametri nominali | Overall | Formula CDM | Table TEDS | Note |
|---|---|---|---|---|---|
| DeepSeek-OCR | 3B, 0,5B attivi | 87,01 | 83,37 | 84,97 | Baseline di v1 |
| Qwen2.5-VL-72B | 72B | 87,02 | 88,27 | 82,15 | 24 volte i parametri totali nominali |
| Qwen3-VL-235B | 235B | 89,15 | 88,14 | 86,21 | Variante non ulteriormente specificata nella tabella |
| UnlimitedOCR v1 | 3B, 0,5B attivi | 93,23 | 92,61 | 90,93 | Misura Baidu |
Rispetto a Qwen2.5-VL-72B, il vantaggio è di 6,21 punti Overall, con un rapporto nominale di 24 a 1 nei parametri totali: calcolo nostro. È un risultato su document parsing, non una classifica delle capacità generali dei modelli. Inoltre OmniDocBench v1.5 e v1.6 sono benchmark diversi: non confrontare direttamente questo 93,23 con i numeri della sezione su v2.
Velocità di v1 e un caso d'uso concreto
Sul carico OmniDocBench in modalità Base, Baidu riporta 5.580 token/s con concorrenza 512, contro 4.951 di DeepSeek-OCR: circa 12,7% in più, ricalcolato dai valori pubblicati. È throughput aggregato del sistema, non la velocità di una singola richiesta e neppure una misura su Mac.
Un caso d'uso locale più semplice è trasformare una cartella di scansioni in testo da indicizzare. Con unlimitedocr.c puoi caricare v1 una volta e riutilizzare l'istanza per più immagini. Trovi il codice nella procedura per Mac. Le chiamate separate dell'esempio elaborano pagine indipendenti: non ricostruiscono automaticamente un contesto documentale condiviso.
Come funziona UnlimitedOCR v2: l'attention SR-SWA
La seconda versione introduce Sparse Reference Sliding Window Attention, o SR-SWA. La sua idea centrale è limitare anche i riferimenti visivi consultati durante ogni passo di generazione. Il modello seleziona le parti utili della pagina invece di riconsiderare tutti i token visivi del documento.
Page Gate
Restringe i blocchi visivi candidati in base alla pagina associata alla query. Le posizioni separano la coordinata di pagina da quella interna alla pagina, per gestire meglio documenti lunghi.
Token Sieve
Assegna un punteggio ai blocchi candidati e seleziona quelli più rilevanti, entro un budget fisso. La selezione viene ottimizzata insieme al modello durante il training.
Continuazione tra finestre
Il runtime suddivide il documento in gruppi di pagine sovrapposti, riusa la cache della pagina di confine e una coda del testo, poi libera i riferimenti non più necessari.
SR-SWA riduce il lavoro di attention per token. La gestione a finestre limita invece le pagine residenti in GPU. Servono entrambe per ottenere il comportamento descritto come unlimited-horizon parsing: caricare in anticipo tutte le immagini conserverebbe comunque un costo di memoria proporzionale al documento.
Anche "one-shot" va letto nel senso corretto: una sola richiesta documentale può essere eseguita internamente in più finestre. E una latenza quasi costante per token non rende costante il tempo totale per trascrivere un libro.
Benchmark UnlimitedOCR v2: confronto con v1, Qwen e InternVL
MPDocBench arriva a 30 pagine. MarathonDocBench, introdotto dagli stessi autori di v2, contiene 100 documenti da 103 a 300 pagine, con circa 205.000 elementi di layout annotati. Oltre a testo, formule e tabelle, questi benchmark valutano la continuità tra pagine.
| Modello | Overall | T-Text Edit | T-Table TEDS | Note |
|---|---|---|---|---|
| UnlimitedOCR v1 | 61,89 | 0,605 | 60,76 | Predecessore, misura nello stesso report |
| InternVL-3.5-38B | 57,01 | 0,515 | 51,69 | Circa 12,7 volte i parametri totali nominali |
| Qwen3-VL-235B | 73,98 | 0,187 | 61,25 | Circa 78,3 volte i parametri totali nominali |
| Qwen3.8-Max | 78,30 | 0,196 | 67,18 | Miglior Overall concorrente della tabella |
| Qwen-3.8-Flash-Next | 77,36 | 0,163 | 88,36 | Vicino a v2 sulle tabelle tra pagine |
| UnlimitedOCR v2 | 84,59 | 0,100 | 89,54 | Miglior Overall nella tabella |
V2 guadagna 22,70 punti Overall su v1 e 6,29 sul miglior concorrente riportato, Qwen3.8-Max. Il vantaggio su Qwen3-VL-235B è di 10,61 punti. Sono differenze ricalcolate dai valori Baidu; i rapporti dimensionali usano i parametri totali nominali, non quelli attivi del MoE.
InternVL-3.5-38B ha circa 12,7 volte i parametri totali nominali di UnlimitedOCR v2. Il rapporto descrive la dimensione dei modelli; memoria e velocità dipendono anche dall'architettura, dalla precisione dei pesi e dal runtime.
| Modello | Overall | T-Text Edit | T-Table TEDS | Note |
|---|---|---|---|---|
| UnlimitedOCR v1 | n.d. | n.d. | n.d. | Non valutato: il report cita un limite di input di 40 pagine |
| Qwen3.8-Max | 22,93 | 0,804 | 13,71 | Modello generalista |
| Gemini-3.8-Flash | 28,61 | 0,658 | 19,56 | Modello generalista |
| Kimi-K3 | 33,74 | 0,664 | 26,30 | Miglior Overall concorrente della tabella |
| UnlimitedOCR v2 | 77,06 | 0,123 | 71,11 | Parsing di centinaia di pagine |
Su MarathonDocBench il distacco dal miglior concorrente riportato, Kimi-K3, arriva a 43,32 punti Overall: calcolo nostro. È il risultato più forte della release e riguarda il compito per cui v2 è stato progettato: mantenere la continuità del parsing su centinaia di pagine.
OCR su una singola pagina: v2 migliora rispetto a v1?
| Modello | Overall | Text Edit | Formula CDM | Table TEDS | Note |
|---|---|---|---|---|---|
| DeepSeek-OCR 2 | 90,25 | 0,050 | 91,84 | 83,89 | 3B, 0,5B attivi |
| UnlimitedOCR v1 | 93,92 | 0,042 | 95,79 | 90,16 | Predecessore |
| UnlimitedOCR v2 | 94,02 | 0,038 | 96,29 | 89,60 | +0,10 Overall; -0,56 Table TEDS rispetto a v1 |
| OvisOCR2 | 96,47 | 0,027 | 97,49 | 94,58 | 0,8B; superiore a v2 in questa tabella |
| TeleOCR | 96,91 | 0,027 | 96,60 | 96,82 | 1,2B; superiore a v2 in questa tabella |
Sulla singola pagina, v1 e v2 restano molto vicini: su OmniDocBench v1.6 il punteggio Overall passa da 93,92 a 94,02, con un guadagno di appena 0,10 punti. Il miglioramento principale di v2 emerge invece nei documenti multipagina.
V2 migliora il riconoscimento di testo e formule, ma il Table TEDS scende di 0,56 punti. Inoltre OvisOCR2 e TeleOCR, entrambi più piccoli, ottengono punteggi superiori nella stessa tabella. Se lavori soprattutto con ricevute o singole pagine, valuta il passaggio a v2 sui tuoi documenti.
Velocità e memoria: cosa significano i numeri di v2
| Modalità | Picco KV cache, batch 1 | Throughput, batch 16 | Note |
|---|---|---|---|
| Standard decoding | 47,00 GB | 360 token/s | Pagine mantenute insieme |
| Unlimited-Horizon Decoding | 1,77 GB | 1.315 token/s | Finestre con riuso della cache di confine |
Con la gestione a finestre, il picco della KV cache scende da 47 a 1,77 GB nel test con batch 1, un rapporto di circa 26,6 a 1. Nel test separato con batch 16, il throughput passa da 360 a 1.315 token/s, circa 3,65 volte quello iniziale. I rapporti sono calcoli nostri sui valori Baidu.
1,77 GB riguarda la KV cache, non tutta la memoria dell'applicazione: pesi, immagini e buffer di lavoro sono costi aggiuntivi.
In un esperimento separato, con modalità Gundam, batch 3 e 1.024 token generati per pagina, il paper riporta a 100 pagine un vantaggio per passo di 7 volte rispetto alla full attention e 5,6 volte rispetto a R-SWA. Questi numeri non vanno trasferiti alle prestazioni di unlimitedocr.c su Apple Silicon: runtime, kernel e hardware sono diversi.
unlimitedocr.c: inferenza in C e Metal, con wrapper Python
Ho realizzato unlimitedocr.c per eseguire UnlimitedOCR sul Mac attraverso una piccola API Python. Il motore di inferenza è scritto in C e usa kernel Metal sulla GPU, senza richiedere PyTorch. Python gestisce le immagini, il prompt e la conversione tra testo e token.
La versione 0.5.0, pubblicata il 29 ottobre 2026, aggiunge il supporto sperimentale a v2 su una pagina alla volta, nei profili base e gundam. Il modello predefinito resta v1 e la precisione predefinita resta FP16. Negli esempi scegliamo esplicitamente modello e mixed Q4, il profilo principale per v2 nella release.
Quanta memoria serve su Mac: FP16, Q8 e Q4
| Modello e profilo | File | Selezione Python | Note |
|---|---|---|---|
| v1 FP16 | 6,7 GB | model="v1" | Default se ometti quant |
| v1 mixed Q8 | 3,5 GB | model="v1", quant="q8" | Matrici quantizzate a 8 bit |
| v1 mixed Q4 | 1,8 GB | model="v1", quant="q4" | Mix di Q4, Q8 e FP16 |
| v2 mixed Q4 | 1,85 GB | model="v2", quant="q4" | Profilo principale, single-page sperimentale |
La parola "mixed" conta: nel profilo Q4 le proiezioni di attention del decoder restano Q8 e alcune parti restano FP16. In v2, per esempio, i 60 tensori dei router DASH sono conservati in FP16. Non si tratta di un GGUF da passare a llama.cpp: la conversione produce il formato nativo .uocr.
Sulle fatture usate nelle verifiche della release, v2 mixed Q4 ha raggiunto picchi di memoria nativa tracciata di 3,33 GB in Base e 4,14 GB in Gundam. Sono misure di quei casi specifici, non limiti garantiti né la memoria totale del processo.
Il primo avvio scarica il checkpoint e lo converte. I due shard ufficiali di v2 occupano complessivamente circa 6,69 GB, calcolati dalle dimensioni dei file Hugging Face: prevedi spazio anche per questi, oltre al modello convertito e alla cache del tokenizer.
Come usare UnlimitedOCR su Mac con Python
La wheel 0.5.0 richiede Apple Silicon, macOS 15 o successivo e Python 3.12 o successivo. Include la libreria nativa e i kernel Metal precompilati. I comandi seguenti creano un ambiente separato; richiedono uv già installato.
Gli esempi Mac e CUDA di questa guida sono stati controllati sulla documentazione e sul codice delle versioni indicate, ma non eseguiti per questo articolo.
1. Crea l'ambiente
1. Crea l'ambiente
mkdir unlimitedocr-demo
cd unlimitedocr-demo
uv venv --python 3.12
uv pip install "unlimitedocr-c==0.5.0"
2. Prepara le immagini
2. Prepara le immagini
Copia nella cartella page-1.png e page-2.png per l'esempio v1, oppure fattura.png per v2. generate() riceve immagini, non direttamente un PDF: renderizza prima le pagine oppure usa un'app che gestisca questo passaggio. Il profilo base usa una vista globale; gundam aggiunge il tiling per le pagine più dense.
v1: una cartella di scansioni
v1: una cartella di scansioni
Questo esempio riusa il modello e conserva il markup grezzo in due file distinti. Eseguilo dalla cartella appena creata:
uv run python - <<'PY'
from pathlib import Path
from unlimitedocr_c import UnlimitedOCR
pages = [Path("page-1.png"), Path("page-2.png")]
for page in pages:
if not page.is_file():
raise FileNotFoundError(page)
with UnlimitedOCR(model="v1", quant="q4") as ocr:
for page in pages:
raw = ocr.generate(page, profile="base")
page.with_suffix(".ocr.txt").write_text(raw, encoding="utf-8")
PY
Le pagine sono indipendenti. I file .ocr.txt contengono anche i marcatori di layout, non Markdown già ripulito. Il context manager chiude il motore anche in caso di errore.
v2: una fattura con blocchi e coordinate
v2: una fattura con blocchi e coordinate
Questo esempio estrae il contenuto di una fattura e salva sia l'output originale sia i blocchi riconosciuti in JSON. Il parser verifica la struttura del markup; non verifica che importi e codici fiscali siano stati letti correttamente.
uv run python - <<'PY'
import json
from dataclasses import asdict
from pathlib import Path
from unlimitedocr_c import UnlimitedOCR, OCRParseError, parse_ocr
page = Path("fattura.png")
if not page.is_file():
raise FileNotFoundError(page)
with UnlimitedOCR(model="v2", quant="q4") as ocr:
raw = ocr.generate(page, profile="base")
Path("fattura.ocr.txt").write_text(raw, encoding="utf-8")
try:
document = parse_ocr(raw)
except OCRParseError as exc:
raise SystemExit(f"Markup non valido; conserva il raw: {exc}")
Path("fattura.json").write_text(
json.dumps(asdict(document), ensure_ascii=False, indent=2),
encoding="utf-8",
)
PY
Per una pagina densa puoi provare profile="gundam", con un costo di memoria maggiore. parse_ocr() restituisce record Document, Page e Block, con bounding box normalizzate tra 0 e 1 quando presenti. Mantiene le etichette e i collegamenti di merge, ma non fonde automaticamente le tabelle tra pagine.
Il wrapper costruisce il prompt e gestisce la generazione: l'API generate(image, profile) non espone parametri di sampling come quelli di un generico chatbot. Non aggiungere argomenti come temperature presi dagli esempi Transformers.
Dopo aver preparato modello e tokenizer, download=False richiede che entrambi siano già disponibili in locale. Per mantenere privato anche il caricamento delle immagini, usa file locali invece di URL.
Come eseguire UnlimitedOCR v2 multipagina con Transformers
Per elaborare più pagine nella stessa richiesta, puoi usare il runtime Transformers di Baidu su una GPU NVIDIA. L'esempio riguarda un contratto di tre pagine, fornite come immagini nell'ordine corretto. Non include la gestione a finestre necessaria per documenti molto lunghi, disponibile nell'implementazione SGLang personalizzata descritta più avanti.
La model card documenta un ambiente con Python 3.10 e una NVIDIA A800 da 80 GB. È la configurazione usata da Baidu, non un requisito minimo universale di VRAM.
1. Prepara un ambiente CUDA separato
1. Prepara un ambiente CUDA separato
Queste sono le versioni indicate nella model card. torchvision e alcune dipendenze non sono fissate dalla ricetta ufficiale: verifica la compatibilità con PyTorch e con i driver della tua macchina.
uv venv --python 3.10 .venv-uocr2-cuda
source .venv-uocr2-cuda/bin/activate
uv pip install torch==2.13.0 torchvision pillow \
transformers==4.52.1 huggingface-hub==0.36.0 \
tokenizers==0.21.4 addict==2.4.0 einops==0.8.2 easydict==1.13
2. Passa le pagine in un'unica chiamata
2. Passa le pagine in un'unica chiamata
Salva questo codice in parse_document.py accanto a page-1.png, page-2.png e page-3.png. Il checkpoint e il codice remoto sono fissati alla revisione usata dal supporto v2 di unlimitedocr.c 0.5.0. trust_remote_code=True esegue codice del repository: esaminalo prima di usarlo in un ambiente sensibile.
from pathlib import Path
import torch
from transformers import AutoModel, AutoTokenizer
repo = "baidu/Unlimited-OCR-2"
revision = "c14071b549f4fcab10909f3c4acc6a2edb366947"
pages = [Path(f"page-{i}.png") for i in range(1, 4)]
for page in pages:
if not page.is_file():
raise FileNotFoundError(page)
if not torch.cuda.is_available():
raise RuntimeError("Questo esempio richiede una GPU NVIDIA CUDA")
tokenizer = AutoTokenizer.from_pretrained(
repo, revision=revision, trust_remote_code=True,
)
model = AutoModel.from_pretrained(
repo, revision=revision, trust_remote_code=True,
use_safetensors=True, torch_dtype=torch.bfloat16,
).eval().cuda()
with torch.inference_mode():
text, num_tokens = model.infer_multi(
tokenizer,
image_files=[str(page) for page in pages],
output_path="output/contratto",
save_results=True,
temperature=0.0,
no_repeat_ngram_size=35,
ngram_window=1024,
max_new_tokens=24000,
)
Path("contratto.ocr.txt").write_text(text, encoding="utf-8")
if num_tokens >= 24000:
raise RuntimeError("Budget di output raggiunto: controlla il risultato")
Esegui nell'ambiente CUDA attivato:
python parse_document.py
infer_multi() usa Base di default e costruisce il prompt "<PAGE><image>" * numero_pagine + "Multi page parsing.". Non serve un system prompt aggiuntivo. I parametri anti-ripetizione riprendono la configurazione multipagina documentata; 24.000 token è il budget scelto per questo esempio, non una soglia consigliata da Baidu. Restare sotto il budget non dimostra da solo che la trascrizione sia completa.
Nel codice fissato alla revisione indicata, infer_multi() ha un limite predefinito di 131.072 token tra input e generazione. Per documenti molto lunghi, Baidu raccomanda il proprio SGLang personalizzato, distribuito nella wheel 0.5.20.dev13+g75b9b06b02, che integra la gestione delle finestre e il riuso della cache. Non basta installare una versione qualsiasi di SGLang.
Se parti da un PDF, converti prima le pagine in immagini mantenendo il loro ordine: infer_multi() accetta la lista delle immagini, non il percorso del PDF.
ImageXtract: usare l'OCR locale in un'app per macOS
Se preferisci lavorare sui documenti senza preparare un ambiente Python, ho sviluppato ImageXtract per macOS. L'app riunisce l'intero flusso di lavoro: importazione dei PDF, OCR locale, verifica dei risultati sulla pagina originale, ricerca nei documenti ed esportazione. Integra un modello Baidu Unlimited OCR quantizzato, un motore C e kernel Metal.
Controllare il risultato sulla pagina
Le regioni riconosciute restano collegate alla pagina originale. Puoi confrontare il testo con la sorgente, verificare le tabelle e recuperare le figure rilevate come immagini.
Ritrovare e riutilizzare i documenti
Progetti persistenti e ricerca full-text rendono consultabili i documenti dopo l'OCR. L'esportazione include Markdown, Word, JSON, HTML e testo spaziale; una cartella osservata può produrre automaticamente file Markdown accanto agli originali.
Come documentato nella pagina del prodotto, la versione App Store di ImageXtract non dispone del permesso di accesso alla rete e disabilita i download di modelli e immagini durante il riconoscimento. Il modello è incluso nell'app e l'OCR viene eseguito sul Mac. I requisiti sono Apple Silicon e macOS 15.5 o successivo; i PDF protetti da password non sono attualmente supportati.
Come leggere i confronti
Le metriche misurano aspetti diversi. Text Edit e T-Text Edit sono distanze: più basse sono, meglio è. TEDS valuta la somiglianza della struttura delle tabelle; CDM riguarda le formule. Il prefisso T nelle metriche multipagina riguarda gli elementi che attraversano il confine tra pagine. Un Overall di 94 non significa che il 94% dei documenti sia interamente corretto.
Conta anche il post-processing. Lo script ufficiale di v2 interpreta i marcatori di pagina e di blocco, riunisce frammenti di tabelle e rimuove intestazioni ripetute. Il parser di unlimitedocr.c conserva la struttura e i collegamenti senza eseguire quelle fusioni: un JSON esportato dal wrapper non è già l'output Markdown usato nella valutazione Baidu.
Un controllo tra fonti: lo stesso v1 non ha numeri identici
| Metrica | Paper Baidu | Leaderboard OmniDocBench | Differenza | Note |
|---|---|---|---|---|
| Overall | 93,92 | 94,00 | +0,08 | Stesso nome del modello; fonti diverse |
| Text Edit | 0,042 | 0,0394 | -0,0026 | Più basso è meglio |
| Formula CDM | 95,79 | 95,7234 | -0,0666 | Più alto è meglio |
| Table TEDS | 90,16 | 90,21 | +0,05 | Più alto è meglio |
Non attribuiamo una causa precisa a queste differenze: possono dipendere da dettagli di valutazione, post-processing o aggiornamenti dei risultati, che andrebbero ricostruiti prima di trarre conclusioni. Però il controllo è utile: uno scarto tra fonti di 0,08 punti sullo stesso v1 è vicino al miglioramento di 0,10 punti tra v1 e v2 nel paper.
Questo non annulla il confronto interno al report. Suggerisce di non presentare il piccolo guadagno single-page come una svolta. I distacchi multipagina sono molto più ampi, ma restano da riprodurre; il benchmark MarathonDocBench è stato proposto dagli stessi autori del modello.
Licenza e limiti da considerare
Licenza dei modelli Baidu
Le model card di v1 e v2 dichiarano MIT; il file LICENSE della repo Baidu contiene il testo MIT, che consente anche l'uso commerciale mantenendo gli avvisi di copyright e licenza. Il software viene fornito senza garanzie. Questo non sostituisce la verifica delle licenze di runtime, dipendenze e altri componenti che distribuisci.
La comprensione globale resta un limite
Gli autori riconoscono che l'attention sparsa di v2 non conserva tutte le informazioni globali del documento. Strutture come la gerarchia dei titoli possono risentirne. Segnalano inoltre una diversità ancora limitata nei dati di training.
Per dati contabili, sanitari o legali, verifica gli elementi critici contro la pagina originale. Il modello può sbagliare testo, ordine di lettura e collegamenti tra blocchi. Anche un parser rigoroso controlla la sintassi, non la fedeltà della trascrizione; eventuale HTML presente nell'output va trattato come contenuto non fidato e sanitizzato prima di mostrarlo sul web.
Domande frequenti su UnlimitedOCR v2
UnlimitedOCR v2 è sempre migliore di v1?
No. Nei risultati Baidu migliora molto il parsing multipagina, ma su OmniDocBench v1.6 guadagna solo 0,10 punti Overall e perde 0,56 punti Table TEDS. Per le singole pagine serve una valutazione sui tuoi documenti.
Posso elaborare un libro intero con unlimitedocr.c?
Puoi costruire un flusso che elabori immagini una alla volta. Nella release 0.5.0, però, v2 supporta solo la pagina singola: le chiamate separate non condividono il contesto e non implementano la continuazione tra finestre del runtime ufficiale.
Bastano 1,85 GB di RAM per v2?
No: circa 1,85 GB è la dimensione del file mixed Q4 di unlimitedocr.c. Servono anche memoria per immagini, attivazioni, KV cache e buffer. I picchi nativi documentati su alcune fatture sono già superiori e non descrivono ogni possibile input.
Funziona con documenti in italiano?
Le model card classificano i modelli come multilingue, ma le fonti qui esaminate non forniscono un benchmark specifico per l'italiano. Verifica accenti, separatori decimali, codici e tabelle su un campione rappresentativo dei tuoi documenti.
L'inferenza sul Mac funziona offline?
Con unlimitedocr.c sì, dopo aver preparato modello e tokenizer in locale e usando immagini locali. ImageXtract include il modello nell'app e la pagina del prodotto documenta un'elaborazione senza servizio OCR cloud. Le condizioni di installazione sono diverse.
Quando scegliere ImageXtract invece della libreria Python?
Scegli la libreria se vuoi integrare l'OCR nei tuoi script e controllare la pipeline. ImageXtract è adatto quando vuoi importare PDF, verificare visivamente i risultati, cercare nei progetti ed esportare senza sviluppare questi strumenti.
Fonti
Dati aggiornati al 30 ottobre 2026. I benchmark sono quelli pubblicati da Baidu e dalla leaderboard OmniDocBench; non li abbiamo riprodotti in modo indipendente. Differenze di punteggio, rapporti dimensionali, rapporti di throughput e memoria e somma delle dimensioni degli shard sono calcoli nostri. I casi d'uso sono illustrativi e gli esempi di inferenza non sono stati eseguiti per questo articolo. Le verifiche descritte nelle note di unlimitedocr.c appartengono alla release del progetto, non a nuovi test svolti per questa guida.
Trasparenza: unlimitedocr.c e ImageXtract sono miei progetti. Le loro funzioni sono descritte separatamente dai risultati del modello Baidu.
References
- Baidu Unlimited-OCR: README e registro release
- Unlimited OCR Works: paper v1
- Unlimited OCR Works 2: report tecnico, tabelle 1-4 e limiti
- Model card Baidu Unlimited-OCR v1
- Model card Baidu Unlimited-OCR-2
- Unlimited-OCR-2: elenco e dimensioni dei file
- Implementazione Transformers v2 alla revisione c14071b
- unlimitedocr.c: documentazione della versione 0.5.0
- unlimitedocr.c 0.5.0: supporto v2, verifiche e limiti
- ImageXtract per macOS: OCR locale e gestione documentale
- OmniDocBench: leaderboard v1.6_full allo snapshot ea2d138
- Baidu: post-processing del markup UnlimitedOCR v2
- Baidu Unlimited-OCR: licenza MIT