LiteParse：457页PDF不到1秒，LlamaIndex把解析器用Rust重写了
alitrack约 5 分钟LiteParse：457 页 PDF 不到 1 秒，LlamaIndex 把解析器用 Rust 重写了
8.6k Star，Rust 重写，零 LLM 调用，比 PyMuPDF 快 88 倍。纯本地、全平台、Agent 开箱即用。
给 Agent 喂 PDF，第一步永远是解析。这个环节有多慢？
PyMuPDF，Python 生态最常用的 PDF 库，解析一份 100MB、457 页的 PDF，68.8 秒。等 Agent 看到文档内容，用户已经泡好咖啡了。
LiteParse 做同一件事：0.777 秒。
不是多线程，不是 GPU，就是 Rust 替换了 Python。
这不是又一个 PDF 库
LiteParse 是 LlamaIndex 团队今年 2 月开源的。一开始是 TypeScript 写的，只有 Node.js 能用。4 月底——LlamaIndex 做了一个狠决定：全量 Rust 重写。
替换的不只是语言。底层引擎从 PDF.js 换成了 PDFium——Google 给 Chromium 写的 PDF 渲染引擎，C 语言，原生速度。这才是 88 倍差距的核心原因：不是"用 Rust 所以快"，是"换成 C 引擎 + Rust 绑定所以快"。
1输入：PDF/DOCX/XLSX/PPTX/Images
2 ↓ LibreOffice / ImageMagick 转 PDF
3PDFium（Google C 引擎，Chromium 同款）
4 ├─ 原生文本提取
5 ├─ OCR 降级（Tesseract 内置，只对图片区域）
6 └─ 智能合并（原生文本 + OCR 去重）
7 ↓ Grid Projection（空间布局重建）
8输出：JSON(含bbox) / Text / Screenshots
v2.0 上周刚发。8.6k Star，20 个 contributors，50 个 release。社区增速很快。
为什么快：不是 Rust，是 PDFium
大部分人看到 "Rust 重写" 就默认归因于语言。但 LiteParse 快的关键是 PDFium。
PDFium 是什么？你打开 Chrome，点一个 PDF——渲染它的就是 PDFium。Google 维护了十几年，C 语言，经过亿级用户验证。PDF.js（火狐的方案，也是 v1 用的）是 JS 实现，架构上就不可能比 C 快。
LiteParse 做的事：用 Rust 写了一个 PDFium 的 FFI 绑定（pdfium-sys + pdfium crate），然后基于它做了文本提取、Grid Projection、OCR 合并。
OCR 策略也很聪明：不是全文 OCR。 默认只对 PDFium 提取失败的区域（扫描件、图片嵌入）做 OCR。内置 Tesseract，也支持 HTTP OCR Server（EasyOCR / PaddleOCR 随便接）。这个"能省就省"的思路把 CPU 浪费压到最低。
实测
装了 Python 版跑了几份真实文档。
1pip install liteparse1from liteparse import LiteParse
2
3parser = LiteParse()
4result = parser.parse("irs_1040.pdf")
5print(f"Pages: {len(result.pages)}, Items: {len(result.pages[0].text_items)}")
6# Pages: 2, Items: 127
一份 IRS 税表，两页，127 个文本项。每个项有精确的 bbox 坐标和 confidence 分数：
1{
2 "text": "Form 1040",
3 "bbox": [72.0, 96.0, 228.0, 118.0],
4 "confidence": 1.0
5}
批处理也顺手：
1lit batch-parse ./pdfs ./output --format json --recursive截图功能是给 Agent 用的——lit screenshot doc.pdf 生成每页 PNG，喂给 LLM 看图。
多语言绑定：不是包装，是原生
很多人把"支持 Python"理解为"包了一层 CLI 调用"。LiteParse 不是——它用了 PyO3（Rust → Python 原生绑定），Python 调用直接走 Rust 函数，零序列化开销。
四个入口：
| 入口 | 安装 | 实现 |
|---|---|---|
| Rust | cargo install liteparse | 原生 |
| Python | pip install liteparse | PyO3 原生绑定 |
| Node.js | npm i @llamaindex/liteparse | napi-rs 原生绑定 |
| 浏览器 | npm i @llamaindex/liteparse-wasm | wasm-bindgen |
WASM 版是真正的亮点。 38KB 的 JS 胶水 + wasm 二进制，直接在浏览器跑 PDFium。全程本地，零上传。Simon Willison 做了一个浏览器 Demo，验证过"解析过程中没有任何网络请求"。
但 OCR 在 WASM 里被砍了——系统依赖太多。官方方案是传 OCR callback（比如 tesseract.js）。
和同类比
| LiteParse v2 | PyMuPDF | pdfplumber | LlamaParse(云) | |
|---|---|---|---|---|
| 引擎 | PDFium (C) | MuPDF (C) | pdfminer (Py) | LLM + Layout |
| 457页耗时 | 0.777s | 68.8s | ~120s | N/A(云延迟) |
| OCR | 内置 Tesseract | 无 | 无 | LLM |
| 表格 | 基础 | 基础 | 强 | 强(LLM) |
| 隐私 | 纯本地 | 纯本地 | 纯本地 | 上传 |
| 价格 | 免费 | 免费 | 免费 | 按 token |
| Agent Skill | ✅ 已集成 | ❌ | ❌ | API |
Agent 集成是独特优势：
1npx skills add run-llama/llamaparse-agent-skills --skill liteparseClaude Code / Codex / OpenCode 直接就能用。不用写胶水代码。
但它不是银弹
LiteParse 的 README 很诚实，开头就写了：
"Hitting the limits of local parsing? For complex documents (dense tables, multi-column layouts, charts, handwritten text, or scanned PDFs), you'll get significantly better results with LlamaParse."
这句话翻译：复杂文档别找我，去用付费版。
这是 LlamaIndex 的商业漏斗——LiteParse 是免费入口药，解决 80% 的简单场景。剩下 20% 的复杂表格、手写体、多栏排版，推你上 LlamaParse（按 token 付费的云服务）。
几个已知局限：
- 复杂表格不如 pdfplumber——LiteParse 定位是"快"，不是"表格专家"
- 内存管理——大文档（>500MB）内存占用高，GitHub 有 open issue 在跟
- WASM 版无内置 OCR——浏览器里只能靠传 callback，或者用 tesseract.js
- Go 绑定暂无——有需求，但短期内不太可能有
谁适合用
适合：
- AI Agent 流水线里的文档预处理——快、本地、有 skill
- RAG 系统的大批量文档解析——批量模式 + 并发 worker
- 浏览器端隐私敏感场景——WASM 全程不上传
- 替代 PyMuPDF 做基础文本提取——88x 速度差距太大
不适合：
- 需要精确表格提取——用 pdfplumber 或 LLM 方案
- 扫描件为主——OCR 质量取决于 Tesseract，不如 Gemini/Claude Vision
- 生产级复杂文档清洗——LlamaParse 云版才是他们主推的
总结
LiteParse 是目前最快的开源 PDF 解析器，没有之一。
核心决策——PDFium 引擎 + Rust 绑定 + 选择性 OCR——让它在简单文档场景下比 PyMuPDF 快两个数量级。多语言原生绑定和 Agent Skill 让它对 AI 工作流特别友好。
但不要把它当万能药。LlamaIndex 的意图很清楚：LiteParse 解决"快"，LlamaParse 解决"准"。你要的是哪个，取决于你的文档有多复杂。
LiteParse — Apache 2.0，Rust 70%。v2.0 上周刚发，8.6k Stars。