很多企业想"把大模型装到自己服务器上"，但一开始就讨论买什么显卡，往往会走弯路。建议按下面五个问题的顺序来决策。
1. 要解决什么问题？
先把场景写清楚，再谈模型。常见场景大致分四类：
| 场景 | 对模型的要求 |
|---|---|
| 知识库问答（制度、手册、产品资料） | 理解中文问题、忠实引用资料，规模不必很大 |
| 文本生成（文案、回复、报告初稿） | 语言流畅、风格可控 |
| 数据分析（自然语言查报表） | 推理能力、生成 SQL 或表格的准确性 |
| 多轮对话客服 | 响应速度、并发能力、拒答与转人工 |
每个场景都要写下成功标准，例如"100 个常见问题中 90 个回答正确且给出出处"，后面的选型和验收都以此为准。
2. 选多大的模型？
主流开源中文模型都有从几十亿到几百亿参数的多个规模。一般规律是：
- 知识库问答：答案主要来自检索到的资料，中等规模（十几亿到三百亿参数级）通常够用；
- 复杂推理、长文写作：更大的模型效果更好，但硬件成本成倍增长；
- 量化：把权重从 16 位压缩到 8 位或 4 位，显存需求大幅下降，效果损失在多数业务场景中可以接受。
选型时用你自己的 20–50 条真实问题做对比测试，比看公开排行榜可靠得多。另外，各开源模型的许可协议不同，商用前要逐一确认。
3. 需要微调吗？
多数企业场景先不需要。优先采用检索增强生成（RAG）：
- 把文档切分、向量化，存入知识库；
- 用户提问时先检索相关片段；
- 把片段和问题一起交给模型作答，并给出出处。
RAG 的好处是资料更新后立即生效、回答可追溯。只有当你需要固定的输出格式、特定写作风格，或模型在专有任务上明显不够用时，再考虑用 LoRA 等方式做轻量微调。
4. 推理框架和硬件
- 推理框架：并发服务常用 vLLM、SGLang 等；单机轻量部署可用 llama.cpp、Ollama 等。框架决定了并发能力和显存利用率。
- 硬件：先按模型规模、量化方式和并发量估算显存（方法见《大模型显存与并发怎么估算》），再在消费级显卡、专业显卡或国产算力之间选择。
- 网络：模型服务部署在内网，对外只暴露业务系统，不直接暴露模型接口。
5. 上线后谁来维护？
- 权限：不同部门能检索的知识范围是否需要隔离？
- 日志与审计：谁在什么时候问了什么，是否需要留存？
- 更新：知识库多久更新一次，由谁负责？
- 升级：新模型发布后如何评估与替换？
这些问题在立项时就要定下来，否则系统上线后很快就会"没人管"。
如果你正在评估私有化部署，可以把场景和现有硬件发给我们，我们帮你做一次免费的可行性评估。