PDF 解析是 RAG 流水线上最不受待见的一环。它蹲在系统最前面，像一台不声不响的水泵：不出毛病的时候谁都想不起它，一旦慢了、漏了，后面的检索和生成全跟着遭殃。LlamaIndex 刚放出的 LiteParse 2.14.6，就是在给这台水泵换叶轮——文本提取平均 2.76 毫秒一页，markdown 渲染 3.94 毫秒一页，比上一版快了 20% 到 25%。
快 25%，赢的是一次内存分配的换血
先把结论摆出来：这次提速跟"更聪明的解析算法"关系不大。LlamaIndex 动的是地基层——他们维护着一份自己的 PDFium fork，在里面把内存分配换成了 mimalloc，再配上一轮针对性的调优。
解析慢，通常慢在你看不见的地方
PDF 文档天生就碎。一页正文拆成几百上千个文本对象、图形状态、字体引用和坐标矩阵，解析器每读一个 token 都要申请一小块内存，用完立刻还回去。单页看微不足道，可一批处理几千份文档、再开几个线程并行，分配器就成了唯一的收费站。
glibc 默认的 malloc 和 Windows 的堆管理器，都不是为这种高频小对象场景设计的。线程一多，锁竞争和 arena 切换的开销会迅速吃掉 CPU 时间。你以为瓶颈在读文件、在解压流，实际上处理器有相当一部分时间在排队等一个空闲块。
为什么非得自己 fork 一份 PDFium
PDFium 是 Chromium 的 PDF 引擎，稳定、格式覆盖广，但它不会为你的解析场景做定制。上游的合并节奏、回归测试、发布周期，轮不到一个文档处理库来指手画脚。
自己 fork 意味着接过维护成本：跟随上游安全补丁、处理构建差异、保证跨平台行为一致。代价不小。换来的好处是优化能塞进引擎内部，而不是在外面裹一层——改分配策略、调整对象生命周期、砍掉渲染路径上根本不需要的分支。LiteParse 这次的收益，基本都来自这层贴身改造。
mimalloc 装进去之后，账是这么算的
mimalloc 是微软开源的内存分配器，核心思路是按线程分片、用线程本地空闲链表处理小对象，把加锁的路径尽量压短。它对"大量短命小对象 + 多线程"这种负载特别友好，而这恰好是 PDF 解析的日常画像。
装进 fork 之后的结果写得很直白：平均每页文本提取 2.76 毫秒，markdown 渲染 3.94 毫秒，整体下降 20% 到 25%。用户不需要设置 LD_PRELOAD，也不用在部署脚本里替换系统库——分配器跟着库一起走，装完即生效。
快只是入场券，表格才是分水岭
速度能让你少开几台机器，但决定要不要换方案的，永远是解析得对不对。PDF 里最难啃的从来不是正文流，而是版面结构。
复杂表格一直是那块试金石
跨页表格、无线框表格、合并单元格、正文里嵌半张表——这类东西在真实业务文档里遍地都是。财报、招股书、合同附件、科研论文，一份文件里能凑齐全部变体。解析器在这里的错误通常不是"读不出来"，而是读出来之后行列错位、表头丢失、脚注混进数据行。
这种错误特别阴险。它不会让流水线报错，只会安静地把脏数据喂给后面的向量化和检索。等模型答非所问的时候，你早就找不到源头了。
那些对比数据该用什么姿势读
看这类更新给出的实测对比，第一眼别盯平均耗时。先看两组数：一是在你实际会遇到的文档类型上，表格结构还原的准确率是多少；二是端到端延迟里，解析到底占几成。
如果解析只占整条流水线的 5%，那 25% 的提速换来的是 1% 出头的总收益，谈不上救命。反过来，如果你在做大规模离线抽取、每天要过几百万页，每页省下的这零点几毫秒会直接变成真金白银的机器账单。
新 API 摆上桌，迁移这笔账得自己算
2.14.6 除了性能，还带了接口层面的补充。LlamaIndex 在博客里把速度、表格准确率和 API 变更三块信息一起给出来，意思很明显：他们希望你把这当成一次可评估的替换候选，而不是一次无感升级。
接口的变化到底动了什么
新增 API 主要解决"拿到结构化结果之后怎么办"的问题——解析产物怎么衔接下游节点、怎么在既有的 ingestion 流程里落地。如果你现在用的是自己拼的解析脚本，这部分工作可能要重写；如果本来就走官方管道，改造成本会低很多。
什么时候该切，什么时候再等等
判断标准不复杂。手上如果有成熟的 PDF 解析方案且运行稳定，那就拿一批有代表性的真实文档做 A/B：同一份样本，分别跑老方案和 LiteParse 2.14.6，比表格还原质量、比端到端耗时、比失败样本的类型分布。跑完再决定。
如果你压根没有专用解析器，靠 pdfplumber 或者临时正则硬扛，那这次的收益值得认真对待。2.76 毫秒一页意味着单核每秒能处理三百多页，这个量级足够撑起大多数中小规模的文档库。
fork 的代价，别装作看不见
自维护 fork 是一把双刃剑。你拿到了定制化的性能，也接过了长期跟进上游的责任。选它之前，最好先确认这份 fork 的更新频率和 issue 响应速度——PDF 格式的坑深得很，一个人维护的引擎和一群人维护的引擎，三五年后会差出很远。
