# DeepSeek、Qwen 本地部署：让大模型读懂 ERP 数据

> Source: https://netray.co/zh/deepseek-qwen-local-deploy-erp-rag
> Language: zh
> Publisher: Netray (netray.co)

在 ERP 数据上用本地大模型，关键不是挑哪个模型，而是显存估算、检索与查询设计、权限映射和评测。多数场景用检索和只读查询就够，不需要微调。模型用 vLLM 或 Ollama 部署在厂内 GPU 上，数据全程不出厂。

DeepSeek 和 Qwen 都提供开放权重的模型，工厂可以下载后部署在自己的服务器上。对于鼎捷、用友、金蝶、SAP 等 ERP 的用户，这意味着可以在不把数据送往外部接口的前提下，获得自然语言问答和文档理解能力。

但从下载模型到真正可用，中间有不少工程问题：需要多少显存、如何接 ERP 数据、怎样控制权限、怎样验证答案可信。本文按这条线逐项说明，并指出哪些事情不必做。

## 模型选型与显存估算

显存需求大致由参数量和精度决定：以 16 位精度加载，每十亿参数约占两个吉字节显存，另外还要给上下文缓存留空间。量化到 8 位或 4 位可以显著降低占用，但会有一定精度损失，需要用您自己的问题测试。

DeepSeek 的大参数模型需要多卡甚至多机，而较小的蒸馏版本和 Qwen 的中等规模模型可以在单台多卡服务器上运行。问数和文档问答通常不需要最大的模型，先用中等规模验证，再按效果决定是否升级。具体型号和版本请以发布方最新说明为准。

- 参数量乘以精度字节数，估算权重显存
- 并发越高，上下文缓存占用越大
- 量化可省显存，但要用真实问题复测
- 先中等规模验证，再决定是否加大

## 服务化：vLLM 或 Ollama

vLLM 适合多用户并发，吞吐高，提供兼容常见接口的服务；Ollama 部署简单，适合试点和小团队。两者都可以在内网运行，不需要连接公网，模型权重下载后可离线保存。

上线时要考虑服务监控、日志、限流和模型版本管理。更换模型版本前，用同一批评测问题回归，避免升级后答案悄悄变差。

## 让模型读 ERP 数据的两种方式

第一种是结构化查询：模型把问题转成只读 SQL，在业务视图上执行，结果再由模型解释。适合库存、订单、成本这类精确数字，答案必须来自实时数据并显示所用查询。

第二种是检索增强（RAG）：把工艺文件、质量记录、合同、维修手册切块建立向量索引，问答时检索相关片段再回答，并给出出处。适合非结构化文档。两种方式常配合使用，由路由层判断问题属于哪类。

## 权限、审计与写回

权限要沿用 ERP 的角色，在查询层按用户限制可见范围；文档检索也要按文档权限过滤，否则模型可能把无权限的内容摘要出来。每次问答记录用户、问题、查询和来源，便于审计。

写回 ERP 的动作默认关闭。需要时只生成草稿，由有权限的人审批后通过标准接口提交。模型的输出不应直接成为业务单据。

## 要不要微调

多数制造企业不需要微调。企业术语、料号体系和流程，通过提示词、检索和视图命名就能很大程度上解决。微调需要整理高质量标注数据，维护成本高，且知识更新后要重新训练。

只有在固定格式输出、特定领域语言风格或小模型需要提升某类任务时，才值得考虑微调，并且应先用评测证明收益。

## 评测与上线

准备一份由业务人员出题的评测集，覆盖常见查询、模糊问法和应当拒答的问题，记录答对率、拒答是否合理、响应时间。试点阶段每周复盘错误案例，多数错误来自口径或视图设计。

合规方面，国内企业要关注生成式人工智能相关管理规定以及数据安全、个人信息保护要求。对内部使用的系统，通常侧重数据分级、访问控制和日志留存；具体是否需要备案或评估，请由您的法务确认。

## FAQ

### DeepSeek 和 Qwen 选哪个？

没有统一答案。用您的真实问题对几个候选模型评测，比较准确率、响应时间和显存占用后再决定。

### 没有 GPU 能跑吗？

小模型可以在 CPU 上运行，但速度慢，只适合验证。正式使用建议配 GPU。

### 本地模型的回答会比云端差吗？

取决于任务。结合实时查询和检索的问答，差距常常不大；复杂推理和长文写作可能不及最大规模的云端模型。

### 需要把 ERP 全部数据导入向量库吗？

不需要。精确数字用只读查询，向量库只用于文档类内容，避免数据过期和权限泄露。

### 模型会学习我们的数据吗？

推理时不会修改模型权重。除非您主动微调，否则数据只作为上下文使用。
