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

PDF 解析速度提升 88 倍：LlamaIndex 团队用 Rust 和 C 引擎重构解析器，Agent 处理文档不再需要等待

给 AI Agent 喂 PDF，第一步永远是解析。这个环节到底有多慢？

PyMuPDF，Python 生态中最常用的 PDF 库，解析一份 100MB、457 页的文档，耗时

。等 Agent 看到文档内容的时候，用户大概已经泡好咖啡了。

而 LiteParse 完成同样的任务，只用了

。不是靠多线程，也不是靠 GPU，核心变化就是：用 Rust 替换了 Python。

这不仅仅是一个新的 PDF 库

LiteParse 是 LlamaIndex 团队今年 2 月开源的。最初版本是用 TypeScript 写的，只有 Node.js 能用。到了 4 月底，LlamaIndex 做了一个相当大胆的决定：

。

但替换的不只是语言。底层引擎从 PDF.js 换成了

——Google 给 Chromium 写的 PDF 渲染引擎，使用 C 语言，具备原生速度。这才是实现 88 倍性能差距的核心原因：不是“用了 Rust 所以快”，而是“换成了 C 引擎加上 Rust 绑定，所以快”。

整个处理流程是这样的：

• 输入：PDF / DOCX / XLSX / PPTX / Images
• 通过 LibreOffice 或 ImageMagick 转换为 PDF
• PDFium（Google C 引擎，与 Chromium 同款）进行原生文本提取
• 对于 PDFium 提取失败的区域，降级使用内置的 Tesseract 做 OCR
• 智能合并原生文本与 OCR 去重结果
• 通过 Grid Projection 重建空间布局
• 输出：JSON（含 bbox）、Text、或 Screenshots

v2.0 上周刚刚发布。目前项目已经积累 8.6k Star，有 20 位贡献者，发布了 50 个版本。社区的增长速度相当快。

为什么快：关键在于 PDFium，而不是 Rust

很多人看到“Rust 重写”就默认把原因归结到语言上。但 LiteParse 真正快的关键是

。

PDFium 是什么？你打开 Chrome，点开一个 PDF 文件——渲染它的就是 PDFium。Google 维护了十几年，用 C 语言编写，经过亿级用户的验证。而 PDF.js（火狐的方案，也是 v1 用的）是 JS 实现，从架构上就不可能比 C 语言快。

LiteParse 做的事情是：用 Rust 写了一个 PDFium 的 FFI 绑定（pdfium-sys + pdfium crate），然后基于它做了文本提取、Grid Projection 和 OCR 合并。

默认只对 PDFium 提取失败的区域（比如扫描件、图片嵌入）做 OCR 处理。内置了 Tesseract，也支持通过 HTTP 调用 OCR Server（EasyOCR 或 PaddleOCR 都可以接入）。这个“能省就省”的思路把 CPU 的浪费压到了最低。

实测表现

在 Python 版中跑了几个真实文档，体验很直接：

pip install liteparse

from liteparse import LiteParse

parser = LiteParse()
result = parser.parse("irs_1040.pdf")
print(f"Pages: {len(result.pages)}, Items: {len(result.pages[0].text_items)}")
# Pages: 2, Items: 127

一份 IRS 税表，两页，127 个文本项。每个项都有精确的 bbox 坐标和 confidence 分数：

{
  "text": "Form 1040",
  "bbox": [72.0, 96.0, 228.0, 118.0],
  "confidence": 1.0
}

批处理也很顺手：

lit batch-parse ./pdfs ./output --format json --recursive

截图功能是专门给 Agent 用的——lit screenshot doc.pdf 可以生成每页 PNG，直接喂给 LLM 看图。

多语言绑定：不是包装，是原生

很多人以为“支持 Python”就是包了一层 CLI 调用。LiteParse 不是这样做的——它用了

（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

38KB 的 JS 胶水加 wasm 二进制文件，直接在浏览器里运行 PDFium。全程本地，零上传。Simon Willison 做了一个浏览器 Demo，验证过“解析过程中没有任何网络请求”。

不过 OCR 在 WASM 版本中被移除了——系统依赖太多。官方方案是传入 OCR callback，比如配合 tesseract.js 使用。

同类对比

拿 LiteParse v2 跟几个常见方案做个对比：

• 引擎：PDFium (C) vs PyMuPDF (MuPDF, C) vs pdfplumber (pdfminer, Py) vs LlamaParse (LLM + Layout)
• 457 页耗时：0.777s vs 68.8s vs ~120s vs N/A（云延迟）
• OCR：内置 Tesseract vs 无 vs 无 vs LLM
• 表格：基础 vs 基础 vs 强 vs 强（LLM）
• 隐私：纯本地 vs 纯本地 vs 纯本地 vs 上传
• 价格：免费 vs 免费 vs 免费 vs 按 token
• Agent 集成：已有 Skill 直接使用

Agent 集成是 LiteParse 的独特优势：

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

Claude Code、Codex、OpenCode 直接就能用，不需要再写胶水代码。

但它不是银弹

LiteParse 的 README 相当诚实，开头就写清楚了：

“如果本地解析达到了极限，对于复杂文档（密集表格、多栏布局、图表、手写文本或扫描 PDF），使用 LlamaParse 会获得显著更好的结果。”

这句话翻译过来就是：

这是 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 做基础文本提取——88 倍的速度差距实在太大了

• 需要精确表格提取——用 pdfplumber 或 LLM 方案更合适
• 扫描件为主——OCR 质量取决于 Tesseract，不如 Gemini 或 Claude Vision
• 生产级复杂文档清洗——LlamaParse 云版才是团队主推的方案

总结

LiteParse 是目前

，没有之一。

核心决策——PDFium 引擎加 Rust 绑定加选择性 OCR——让它在简单文档场景下比 PyMuPDF 快出两个数量级。多语言原生绑定和 Agent Skill 让它对 AI 工作流特别友好。

但不要把它当万能药。LlamaIndex 的意图很清楚：LiteParse 解决“快”，LlamaParse 解决“准”。你需要哪一个，取决于你的文档到底有多复杂。

LiteParse — Apache 2.0 协议，Rust 占比 70%。v2.0 上周刚发布，目前 8.6k Stars。