longcat ai不处理pdf解析，内存溢出主因是mineru等工具的光栅化爆炸、全量加载、中间对象滞留及多模型并行；可通过切cpu模式、分页流式处理、输入压缩缓解。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
LongCat AI 本身并不直接处理 PDF 解析，你提到的“LongCat AI”大概率是指美团 LongCat 团队开源的 LongCat-Image-Editn（图像编辑模型），它专注图文编辑，不负责 PDF 文本提取或结构化解析。真正常因大 PDF 触发内存溢出的，是 MinerU、PDF-Extract-Kit、Langchain-Chatchat 等 PDF 解析/知识库工具。
为什么大 PDF 容易内存溢出？
不是模型“太重”，而是 PDF 处理链路中多个环节叠加吃内存：
- 光栅化爆炸：PDF 被逐页转成高分辨率图像（如300dpi A4图单页≈180MB显存），100页就超16GB GPU显存；
- 全量加载模式：工具默认把整份PDF解码进内存，而非流式读取；
- 中间对象滞留：文本分割后原始 Document 不释放，RecursiveCharacterTextSplitter 会生成数倍于原文的 chunk 副本；
- 多模型并行加载：表格识别、公式 OCR、主干模型三者权重合计超4GB，推理时还需缓存特征图。
不改代码也能快速缓解的实操方法
针对 MinerU / PDF-Extract-Kit 类工具，无需重装、不用写新逻辑，三步见效：
-
强制切 CPU 模式：设环境变量
export CUDA_VISIBLE_DEVICES=-1，绕过显存限制，用 CPU 稳定跑完（速度慢但不崩）； -
分页流式预处理：用
pdfplumber按页读取+拼接，每处理10页就做一次文本分块并清空full_text缓冲区； -
提前压缩输入源：对扫描版 PDF 先用
pdf2image降采样（如150dpi）、对文字版 PDF 用qpdf --stream-compress减体积，再送入解析流程。
长期稳定运行的关键配置
若需批量处理数百页文档，建议从数据源头控制：
- 格式前置转换：PDF → Markdown/TXT（用 MinerU 导出后清洗，或在线工具+OCR），AI 读纯文本 Token 更少、内存占用直降50%以上；
-
文件粒度拆分：用
pdftk或 Python 的PyPDF2按章节/页码范围拆成小 PDF（如每50页一个文件），再逐个喂给解析器； -
显存分级调度：在
start.sh中加export PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:128，避免显存碎片导致分配失败。
本质上，大 PDF 内存问题不是某一个模型的缺陷，而是整个解析流水线缺乏资源节制意识。控制输入规模、释放中间对象、切换执行载体——这三点做到位，90% 的 OOM 都能避开。
