关于 Qwen 3.5 4B 和 llamaparse 的问题
Questions about Qwen 3.5 4B and llamaparse
r/LocalLLaMA 上的一个求助帖，发帖者为附近实体店店主搭建一套包含员工出入记录、现金与发票、二维码扫描等功能的流程，主要顾虑是店主设备多为 16GB 内存、少数为 8GB，询问适合这类设备的本地模型，并考虑 Qwen 3.5 4B 用于简单的发票处理判断。发帖者原本想用云端解析工具 llamaparse 处理不同格式发票表格，也在询问其它本地替代方案。
- 分级
- 值得看
- 收录时间
- 2026-10-27
原帖
Most of them use a 16gb RAM but a few of them which i cannot consider as exception have 8Gb , so which local LLM model would be appropriate for their devices without making things slow, shall i go with Qwen 3.5 4B, its jsut for small judgements about the invoice handling, nothing complex
中文大意
发帖人是开发者，为附近几家实体店主做一个员工进出时间、现金与发票、二维码扫描的记录流水线，很在意客户信任。他的两个问题：一是多数店铺 16GB 内存、少数 8GB，选哪个本地 LLM 才不卡，是否用 Qwen 3.5 4B 做发票处理的小判断；二是他用 LlamaParse 是因为它擅长表格、各家店发票格式不同，但它是云端解析，想找本地替代方案。评论主要给出：8GB 上用 Q4 量化、控制上下文长度；用 Docling 或 Marker 本地解析表格；不要用云解析；金额校验放在代码里而不是交给模型；设人工复核队列；结合 OCR 置信度或多次运行一致性来判断低置信项。适合在低配机器上部署本地发票处理流水线、关注数据不上云的开发者阅读。
讨论区核心观点
依据 15 条评论
- 8GB 机器上用 Q4 量化版的 4B 模型可行，关键是把上下文压短，只喂提取出的字段或单张发票，不要整批或整份 OCR 文本；上线前用最弱的机器和真实发票版式实测。 出处（新标签页打开）
- 为保留客户信任不要在云端解析发票，本地可用 Docling 处理版式和表格，Marker 是另一个本地 PDF 转 markdown 的选项，可在真实发票上对比。 出处（新标签页打开）
- 不要让 LLM 做金额计算：模型只负责提取和分类字段，小计、税额、总计用代码校验，对不上或低置信的进人工复核队列。 出处（新标签页打开）
- 不要相信模型自评置信度，它会普遍偏高；改用 OCR 后端给出的逐 token 置信度，或同一发票跑 2-3 次看字段一致性，两者都有时取较小值。 出处（新标签页打开）
- Docling 本身在 8GB 上负担不重（CPU 版式/表格流程，几百 MB 级），真正风险是和 Qwen 同时驻留内存；应分两步处理，长期服务可每张发票用短命子进程释放内存。 出处（新标签页打开）
- 让解析器承担难活、模型保持简单：先用 pypdf/pdfplumber 抽文本，失败再上 Docling 或小 VL 模型；表格转成 CSV 类文本，用固定 schema（可含 unknown 桶）约束输出，扫描件可考虑 Paperless-ngx 做入口。 出处（新标签页打开）