LiteParse：457页PDF不到1秒，LlamaIndex把解析器用Rust重写了

8.6k Star，Rust 重写，零 LLM 调用，比 PyMuPDF 快 88 倍。纯本地、全平台、Agent 开箱即用。

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 重写" 就默认归因于语言。但 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 liteparse

1from 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 函数，零序列化开销。
四个入口：

WASM 版是真正的亮点。 38KB 的 JS 胶水 + wasm 二进制，直接在浏览器跑 PDFium。全程本地，零上传。Simon Willison 做了一个浏览器 Demo，验证过"解析过程中没有任何网络请求"。
但 OCR 在 WASM 里被砍了——系统依赖太多。官方方案是传 OCR callback（比如 tesseract.js）。

Agent 集成是独特优势：

1npx skills add run-llama/llamaparse-agent-skills --skill liteparse

Claude Code / Codex / OpenCode 直接就能用。不用写胶水代码。

LiteParse 的 README 很诚实，开头就写了：

这句话翻译：复杂文档别找我，去用付费版。
这是 LlamaIndex 的商业漏斗——LiteParse 是免费入口药，解决 80% 的简单场景。剩下 20% 的复杂表格、手写体、多栏排版，推你上 LlamaParse（按 token 付费的云服务）。
几个已知局限：

1. 复杂表格不如 pdfplumber——LiteParse 定位是"快"，不是"表格专家"
2. 内存管理——大文档（>500MB）内存占用高，GitHub 有 open issue 在跟
3. WASM 版无内置 OCR——浏览器里只能靠传 callback，或者用 tesseract.js
4. 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。