Texo: a 20M-parameter LaTeX OCR model with a full training pipeline

The gap Texo is aimed at: formula recognition without a GPU bill

The README frames the problem narrowly. STEM students and AI learners take notes that contain mathematics, and the author argues that a free, fast and precise LaTeX OCR tool is still missing for them. The claim is that formula recognition sits in a comparatively easy corner of machine learning because the output vocabulary is closed and the generalisation demands are lower than in open-ended document understanding. Texo is therefore presented as a personal project rather than a product: a single model, a training pipeline, and a browser demo at texocr.netlify.app. The target user is someone who wants to photograph or screenshot an equation and get LaTeX back, and who cares about deployment size. The secondary audience is more unusual. The README describes the code as well organised and tutorial-like, and the repository ships a TechnoSelection/notes.md file for anyone who wants to reproduce the work from scratch. That makes Texo as much a teaching artefact as a tool.

Distillation from PPFormulaNet-S, then finetuning on UniMERNet-1M

The architecture is not invented here. Texo is a distilled version of PPFormulaNet-S, and the acknowledgements credit PaddleOCR for the model architecture and pretraining weights, with PaddleOCR2Pytorch and D-FINE listed alongside. The decoder, tokenizer and framework come from Hugging Face transformers, and the topic list names vision-encoder-decoder and PyTorch Lightning. So the pipeline is: take a 57M-parameter teacher, compress it to 20M, then finetune on UniMERNet-1M. The repository distinguishes two variants, and the distinction matters more than the headline parameter count. Texo-distill keeps the same tokenizer as UniMERNet and PPFormulaNet, which is why the README says its sequential metrics are strictly comparable. Texo-transfer uses a customised tokenizer with a smaller vocabulary, so its sequences are shorter and its BLEU and edit distance numbers are not comparable to the published baselines. The transfer variant is slightly under 20M parameters for that reason. Anyone reading the performance table should check which row they are looking at before drawing conclusions.

What the UniMERNet-Test numbers actually show

The README reports BLEU and edit distance on UniMERNet-Test across four subsets: SPE, CPE, SCE and HWE. Texo-distill reaches BLEU 0.9014 on SPE, 0.8909 on CPE, 0.7034 on SCE and 0.8606 on HWE, with edit distances of 0.0780, 0.1042, 0.1941 and 0.0995. Against UniMERNet-T at 107M parameters, which scores 0.909, 0.902, 0.566 and 0.883, Texo-distill is close on three subsets and clearly better on SCE, the handwritten subset, where it scores 0.7034 against 0.566. That SCE result is the most interesting number in the table and the README does not explain it. PPFormulaNet-S, the teacher, is listed with BLEU 0.8694 on SPE and 0.8071 on CPE, and the README notes the paper does not report SCE or HWE for it. The ONNX row is the one to watch for deployment: Texo-transfer-onnx drops to 0.8395 on SPE and 0.7787 on HWE from 0.8597 and 0.7973, so exporting costs accuracy. The README does not say why, and I would not guess.

Getting it running: uv, a Hugging Face pull script, and one training entry point

Setup is two commands. Clone the repository, then run uv sync. The README addresses people who do not use uv with a short aside rather than an alternative instruction set, so if you are on pip or conda you are adapting the environment yourself. Model weights come down through a repository script: python scripts/python/hf_hub.py pull for the model alone, or python scripts/python/hf_hub.py pull --with_useful_ckpts if you intend to train from intermediate checkpoints. Inference is demonstrated in demo.ipynb rather than through a CLI. Training is a single entry point, python src/train.py, with Hydra managing configuration. Resuming takes python src/train.py training.resume_from_ckpt="<ckpt_path>". Debugging uses a separate config: python src/train.py --config-dir="./config" --config-name="train_debug.yaml". Slurm users run python src/train.py --multirun --config-dir="./config" --config-name="train_slurm.yaml". Logs land in the outputs directory and are read with tensorboard --logdir outputs. Datasets are on Hugging Face: wanderkid/UniMER_Dataset as the upstream source, or alephpi/UniMER-Train and alephpi/UniMER-Test as the author's normalised versions.

The hardware floor is 16G of GPU memory, and that floor has conditions

The README is unusually direct about resources. The author's own setup is 50G of CPU memory and an A40 or L40S with 46G. The recommendation is 50G of CPU memory and 40G of GPU memory. The stated minimum is 20G of CPU memory with streaming dataloading and 16G of GPU memory with accumulative gradient. Those two qualifiers are doing real work. Reaching the minimum requires enabling streaming dataloading and gradient accumulation, which are configuration choices in the Hydra setup rather than defaults, and the README does not spell out which keys control them. So the honest reading is that 16G is achievable but not free, and you should expect to spend time in the config directory before a first successful run. This is the clearest limitation in the material: Texo is small at inference time, and the training pipeline is not small at all. Inference in the browser is a separate story, handled by the Texo-web repository, which the README links but does not document here.

Where Texo is the wrong tool

Texo recognises formulas. It does not read a page, segment a document, or return text and equations in reading order. If your input is a scanned paper, a photographed whiteboard with mixed prose and maths, or a PDF where you need layout preserved, this model addresses one component of that problem and you would still need detection and layout analysis around it. The README's own framing supports this: it calls formula recognition a classical pattern recognition task with a closed vocabulary. That closed vocabulary is also a boundary. The tokenizer is built from a collected and sorted set of KaTeX commands, described in the data/tokenizer directory and scripts/python/normalize.py, so constructs outside that vocabulary are not going to come back correctly. The evaluation is entirely on UniMERNet-Test, a rendered dataset with SPE, CPE, SCE and HWE splits. Nothing in the material reports accuracy on photographed handwriting, low-resolution screenshots, or formulas embedded in coloured backgrounds. The SCE number suggests handwriting is handled reasonably in the test distribution, but a test split is not a camera.

UniMERNet-T versus Texo: the same task at five times the size

The obvious alternative is UniMERNet-T, the 107M-parameter model whose dataset and image processor Texo depends on. The difference in approach is size and generalisation. UniMERNet-T is the full model; Texo is a distilled derivative that inherits its tokenizer in the distill variant and its training data in both. On the README's own table UniMERNet-T leads on SPE, CPE and HWE BLEU and on edit distance in those subsets, and trails on SCE. So the trade is roughly five times the parameters for a consistent but not dramatic accuracy edge, with Texo ahead on the handwritten split. If your constraint is deployment size, browser inference, or training on a single consumer GPU, that edge is unlikely to be worth the multiple. If your constraint is maximum accuracy on printed formulas and you can host a 107M model, UniMERNet-T is the safer choice and Texo is a compression of it rather than a replacement. Note also that Texo's dependency on UniMERNet's dataset and image processor means the two projects are not independent.

Licence and maintenance: AGPL-3.0 and a single-maintainer project

Texo is AGPL-3.0. That is a copyleft licence with a network clause, which means the obligations can attach when users interact with a modified version over a network, not only when you distribute binaries. If you plan to embed the model in a hosted product and modify it, the licence terms are worth reading in full with your own counsel; this article is not legal advice. The repository is not archived, and the last push recorded is 2026-08-17. No releases were retrieved, so there is no tagged version to pin against and you would be tracking the main branch or a specific commit. The training pipeline depends on Hydra, PyTorch Lightning, transformers and the PaddleOCR-derived architecture, so upgrades to any of those can require config changes. The README's claim that the code is well organised as a tutorial cuts both ways: a teaching repository is readable, and it is also not a library with a stable API. There is a technical report on arXiv and HAL if you want the fuller account of the design decisions, and TechnoSelection/notes.md covers reproducing the work from scratch.

Editorial conclusion

Adopt Texo if you need LaTeX formula recognition that fits in a small deployment budget and you are willing to work inside AGPL-3.0, or if you want a readable end-to-end training pipeline to learn from. Do not adopt it if you need a general document OCR system, if you cannot accept the licence terms, or if you need the strongest reported accuracy, which belongs to the larger UniMERNet-T. Before committing, verify two things yourself: whether the ONNX export path meets your latency target, since the README shows a measurable accuracy drop against the PyTorch model, and whether the texocr.netlify.app demo handles your own formula images, because the published numbers come from UniMERNet-Test and nothing in the repository reports accuracy on real photographed notes.

Official sources

1. alephpi/Texo on GitHub
2. Issues
3. License: AGPL-3.0
4. Project website
5. README