HunyuanOCR-1.5: faster decoding for long structured OCR output

Four OCR tasks share one unchanged backbone

HunyuanOCR-1.5 is a lightweight, end-to-end OCR specialized vision-language model that folds document parsing, text spotting, information extraction and text-image translation into a single end-to-end VLM. What the 1.5 line does not do is redesign the backbone inherited from HunyuanOCR-1.0; the engineering went into decoding speed and training instead. That choice keeps the architecture comparable across both versions, so an evaluation of 1.0 does not carry over, and anyone holding older weights has to switch to the `v1.0` branch rather than the default `main` branch to reproduce old numbers. The audience is narrow and identifiable: teams whose documents produce very long outputs, where tables and formulas dominate page cost, plus developers who want the same model on a laptop instead of a multi-GPU server. Inference code and model weights have been public since the 2025/11/25 entry, which is the earliest date there is anything to run.

DFlash drafts tokens in parallel, the target verifies once

Autoregressive output is where OCR bills get paid, because dense pages emit the longest sequences. HunyuanOCR-1.5 adapts a speculative decoding framework called DFlash: a lightweight block-diffusion draft model proposes several candidate tokens in parallel, and the target model verifies all of them in one pass. The stated payoff is lower decoding latency on long structured output while preserving the output distribution of the target model. Read that claim narrowly. It is a statement about the accelerated model matching its own unaccelerated distribution, not about matching HunyuanOCR-1.0, and not about matching a different serving framework, since an older note still records a residual accuracy difference between the Transformers and vLLM frameworks and calls it work in progress. DFlash also changes the hosting bill, because a draft model is a second set of weights to load, and nothing in the README gives its memory cost or its acceptance rate.

Inference runs in three mutually exclusive environments

The root `requirements.txt` is unusually honest about its own limits, and the closing comment spells out the split:

# Inference is NOT covered by this file. It uses three separate, mutually
# exclusive environments (vLLM release / vLLM nightly+DFlash / transformers),

Each of those three environments carries its own requirements file under `inference/`, and `inference/README.md` is the index. Dependencies are therefore chosen by path rather than by project: a stock vLLM install, a vLLM nightly plus DFlash, and transformers are three setups that will not share one virtualenv. Picking the wrong one tends to surface as an import error or a silently unused acceleration path rather than as a clear message. Worth noting for anyone skimming: the file the README treats as the inference entry point is not the file at the repository root, and the root one is a training stack.

llama.cpp moves the same model onto a laptop CPU

Beyond the server-grade vLLM path, the project documents PC-side deployment through `llama.cpp`, aimed at CPU, consumer-GPU and laptop hardware. The named pieces are a GGUF-converted checkpoint and an OpenAI-compatible `llama-server`, with the walkthrough in `docs/llama_cpp.md`. The difference from the vLLM path is one of kind, not degree: one loads a quantized GGUF through a C++ inference server exposing an OpenAI-shaped HTTP API, the other serves the original weights through a paged-attention engine on GPUs. Local deployment is also the cheapest way to evaluate the model, because it skips the dependency stack that trips people up, and llama.cpp needs no torch, deepspeed or flash-attn. What the README leaves open is whether DFlash speculative decoding is reachable through llama.cpp at all, and it gives no quantization level, no context length and no hardware table for the checkpoint.

Training is a four-step chain ending in a draft model

Training is presented as an ordered chain rather than one entry point. Step one prepares packed training data, which explains why the root requirements pull in `lmdb` and `binpacking`. Step two is supervised fine-tuning of the HunyuanOCR base model. Step three trains the DFlash draft model from scratch, and step four continues from an existing DFlash checkpoint instead. Those middle two steps are not independent, since a draft model only earns its place if it tracks the target it accelerates, so the base model has to be settled first. The 2026/07/24 entry widens the picture with a unified inference environment documented at `docs/inference/inference.md` and a verl-based reinforcement learning stack described in `train_verl/README_en.md`. Having a reinforcement learning path sitting beside the supervised one shows the project is still moving past fine-tuning, and the agent-driven data flow it describes targets long-tail work such as low-resource OCR, ancient-script OCR and multi-image text-centric QA.

CHAOS-Bench corrupts characters to catch hallucination

The benchmark work is the most concrete part of the repository. CHAOS-Bench, added on 2026/07/13 and kept at `benchmarks/CHAOS-Bench`, is a character-level hallucination benchmark: it injects character-level corruptions into academic-paper images and measures whether a model reports what it can actually see. That targets a failure mode accuracy tables hide, namely a fluent transcription of a glyph that is not there. The same group points at Chronicles-OCR, an ancient-text perception benchmark covering the evolutionary trajectory of the Seven Chinese Scripts and built with the Palace Museum and Anyang Normal University, plus ChartArena for chart parsing, Wild-OmniDocBench for document parsing and MMTIT-Bench for text-image translation. None of those results appear in the README, so anyone choosing on numbers has to read the papers.

The lightweight label meets a manual flash-attn build

Lightweight here describes the model, not the install. The repository root declares `torch>=2.1.0`, `transformers>=4.57.0`, `accelerate>=0.34.0` and `deepspeed>=0.14.0`, alongside an image and data stack:

Pillow>=10.0.0
opencv-python>=4.8.0
numpy>=1.24.0
lmdb>=1.4.0
binpacking>=1.5.2

Then the line that decides whether your afternoon is pleasant:

flash-attn>=2.5.0  # requires manual install: pip install flash-attn --no-build-isolation
openai>=1.30.0  # OpenAI-compatible client for benchmarking

The file itself marks flash-attn as needing a manual build, and the only inference-adjacent entry in the whole file is a client for benchmarking. Anyone who just wants to try the GGUF checkpoint needs none of it, which is exactly why the inference environments live elsewhere.

No pip line, no accuracy table, no rollback path

The table of contents promises Environment setup, Download the weights, Quick start (vLLM AR, single GPU) and PC-side deployment via llama.cpp, and the visible text stops before any of those commands. A reader has to open `inference/README.md` for the three environments, `docs/inference/inference.md` for the unified one, `docs/llama_cpp.md` for the local path, and take the weights from:

https://huggingface.co/tencent/HunyuanOCR

No context length, no quantization level, no DFlash acceptance rate and no batch settings are given, and there is no rollback path. The root listing also mixes code and content in one place, with `train/`, `train_verl/`, `inference/`, `llama_cpp/`, `benchmarks/`, `configs/`, `scripts/`, `tools/`, `tests/`, `assets/`, `ruff.toml` and `HunyuanOCR_v1.0/` sitting beside a requirements file that disclaims inference. The last push landed on 2026-09-24 and the repository is not archived, so the code is moving. The LICENSE file carries custom terms that no common identifier names, so anyone planning to ship the weights inside a product has to read that file directly.

Editorial conclusion

Adopt HunyuanOCR-1.5 when long structured output is your real cost and decoding latency, not accuracy, is what hurts day to day. Leave it aside if you need a single pip install path or a published accuracy table, because the README stops short of both. Before committing, open `inference/README.md` and match your serving stack against the three environments it lists, then read the terms file at the repository root, whose wording is custom. Run one CHAOS-Bench image through your own build first, and time the decode step on it.

Frequently asked questions

Official sources

1. Issues
2. README
3. Tencent-Hunyuan/HunyuanOCR on GitHub