上周写完我爱死deepseek-v4-flash了这篇后，又中高强度地用 deepseek-v4-flash（reasoning effort set to max）干了几天活，真的是太便宜了，几乎就像是不要钱一样。
从截图可以看到，这个月套餐额度只用了 11%，deepseek-v4-flash 干了绝大部分活，费用和其他模型比，几乎可以忽略不计。
后面会说到的 GLM 和 Kimi 虽然只跑了两三次，费用反而占了绝大多数。这俩按量计价比 DSVF 贵得多，跑两三次就顶 DSVF 跑好几天。
Image
Image
模型虽好，但是始终有个痛点挥之不去，那就是目前它还不支持多模态。我平时做的事里，有一块就是处理 PDF 文档。
简单说，我隔三差五要从 PDF 里提取文字，存到本地知识库。这项任务我本来都是让 gpt-5.5 来接管的，但是最近我的套餐快到期了，之后只能原价续费，而我又如此推崇 deepseek v4 系列模型，所以我想本着能省则省的原则，如果 deepseek 能完全替我把活全扛了就好了。
可是奈何它还不具备多模态的能力，幽怨之余，我正好刷到一个小红书笔记，于是我留下了如下评论。
Image
没想到随手发了一条，炸出好多热心网友，给出了一堆方案，然后我挨个试了一遍。
首先排除 pdfparser.io 和 Doc2X，因为这俩都是要把数据上传云端且付费的，不符合我这种疑神疑鬼的穷鬼博主人设。
其次排除微软的 MarkItDown，因为它的主要功能是将各种格式转为 markdown，但对于特别精细的要求可能无能为力。
之后再排除 MinerU、Docling，因为这俩至少需要 16GB+ 的内存，我跑这任务的 T430s 硬件够呛。其实我几年前就试过在线版的 MinerU，质量没得说，非常稳定，唯一美中不足的是，有些字（比如说“嫖”）始终识别不出，为此我还专门在他们的 github repo 上提交过 issue。
网友还提到可以试试 Qwen 3.6 Plus 和 Mimo 模型，不过我看到晚了，已经找到了别的办法，所以没尝试，但是我试了 GLM 5.1 和 Kimi K2.6（我为啥不试 MiniMaxImage）之后，发现效果都不好，可能是我的问题，不过连最基本的指令遵循都做不好，也是有点惊讶。我之后有机会会再试试千问和小米的模型。
网友还推荐了通过 MCP Server，让多模态小王子 Gemini 来处理 OCR 的任务。我想到之前买的 Github Copilot Pro 套餐（前情提要：试了下新出的爱马仕（Hermes Agent）里有 Gemini 系列模型可用，兴高采烈地试了下，结果发现 Copilot 里的 Gemini 多模态能力被阉割了，我又不想花钱配 Gemini API，结果只能作罢。
还有一个 PaddleOCR，前面提到的 MinerU 其实内核用的也是这个工具。我挺看好这个的，因为初看上去在性能要求和表现之间找到了个平衡，我准备用穷鬼博主是怎么跑本地模型的这篇里提到的服务器跑这个，等我之后的反馈吧。
说了这么多，我现在到底用了什么方案？
我目前的工作流是，先将 PDF 文档全部复制到工作区，然后将其转成 markdown 文件：内嵌文字的 PDF 就用 fitz 将文字提取出来，而那些纯扫描版的则用 pytesseract 通过 OCR 来识别文字。模型不读图，只看生成的 md 文档即可。
之后，对每个 PDF 原始文件，抽取目录页的 fitz 文本、OCR 文本和 markdown 文本进行对照，输出对比报告。模型就靠这份报告确认目录内容、页码范围、是否跨页等。
模型接着就根据页数、目录跨页情况、目录条目数判断：正文页码和目录页码的对应关系、目录占几页以及对应的单个文件数量。
最后就是根据前面的判断结果，将一整坨 markdown 文件拆分成和目录能够一一对应的单个文件，并进行验证，如果验证下来有问题，则标注出来，形成工作报告，等待人工复核。
整套工作流基本上就到此结束了。
说实话，一整套搞下来还是有点折腾的，不过我想着，好好学学怎么用有短板的模型建工作流来完成任务，也还算值得。但对于大多数人来说，我觉得老老实实用 gpt-5.5 会更省心些。Image