# 关于 Qwen 3.5 4B 和 llamaparse 的问题 - 原标题：Questions about Qwen 3.5 4B and llamaparse - 类型：帖子 - 来源：Reddit - 发布时间：2026-10-27 - 首次精选：2026-10-27 11:32 - 分级：值得看 - 学习层级：入门 - 主题：[inference-hardware-memory]()（第 1 位）、[document-understanding]()（第 2 位）、[local-model-deployment]()（第 5 位） - 原文链接：[https://reddit.com/r/LocalLLaMA/comments/1xg4q3i/questions\_about\_qwen\_35\_4b\_and\_llamaparse]() - 本站页面：[https://oplearnx.com/resources/pk\_824f762742a4]() ## 摘要 r/LocalLLaMA 上的一个求助帖，发帖者为附近实体店店主搭建一套包含员工出入记录、现金与发票、二维码扫描等功能的流程，主要顾虑是店主设备多为 16GB 内存、少数为 8GB，询问适合这类设备的本地模型，并考虑 Qwen 3.5 4B 用于简单的发票处理判断。发帖者原本想用云端解析工具 llamaparse 处理不同格式发票表格，也在询问其它本地替代方案。 ## 原帖 > 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 — lucasbennett\_1 · 2026-10-27 · [原帖]() ## 中文大意 发帖人是开发者，为附近几家实体店主做一个员工进出时间、现金与发票、二维码扫描的记录流水线，很在意客户信任。他的两个问题：一是多数店铺 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 做入口。（[出处]()） --- 来源：LearnMap · 学径（https://oplearnx.com）