私有化部署大模型，把模型跑起来只需要一条命令，难的是另外三件事，显存要按最坏情况算、检索库的权限要提前设计、对外的合规身份要先确认。前两件做错会在上线后返工，第三件做错是法律问题。
过去一年，问"我们要不要自己部署大模型"的企业明显变多了。动机大多是两条，数据不想出内网，以及长期成本不想被 API 按次计费绑住。
但实际项目里看到的失败，原因几乎都集中在三处，一开始没算清显存、没设计权限、没确认合规身份。下面按落地顺序说。
一、先确认你要的是"聊天"还是"知识助手"
这两个需求的技术方案差别很大，选错了后面全要重做。
| 你想解决的问题 | 技术方案 | 难度 |
|---|---|---|
| 员工有个能问答的 AI，写材料、翻译、整理纪要 | 直接调用外部大模型 API | 最低 |
| 数据敏感，但只需要通用问答能力 | 内网部署一个通用模型 | 中等 |
| 让模型基于公司自己的文档、制度、方案回答 | 私有模型 + RAG（检索增强） | 高 |
| 需要模型掌握公司特有的话术与格式 | 微调 | 最高，且通常不必要 |
一个判断标准。如果员工问的是"帮我写个通知"，那是通用能力；如果问的是"我们公司的差旅标准是多少"，那是知识检索。后者要靠把文档检索做对，换一个更大的模型解决不了。
很多企业一上来就想微调，其实大部分需求用 RAG 就能满足，成本低一个数量级，而且文档一更新立刻生效。微调做不到这一点。
二、显存怎么算，一条公式和一张档位表
这是最常被低估的一步。显存需求由三部分组成。
总显存 ≈ 权重 + KV Cache + 框架与激活开销
- 权重 ≈ 参数量 × 每参数字节数。FP16 约 2 字节，INT8 约 1 字节，INT4 约 0.5 字节。所以 7B 模型 FP16 约 14GB，INT4 只有 3.5~4GB。
- KV Cache 是最不确定的一块，它随上下文长度和并发数线性增长。短问答场景可能只占权重的 10%，长文档或高并发下可能超过权重本身。
- 框架开销 通常预留 1~2GB。
工程上常参考的档位（量化方案与推理框架不同会有差异，以实测为准）。
| 模型规模 | 精度 | 权重占用 | 显存建议 |
|---|---|---|---|
| 7B | INT4 | 约 4~5GB | 16GB 单卡 |
| 7B | FP16 | 约 14~15GB | 24GB 单卡 |
| 14B | INT4 | 约 9~10GB | 24GB 单卡 |
| 32B | INT4 | 约 19~21GB | 24GB 紧张，48GB 稳妥 |
| 70B | INT4 | 约 40~45GB | 48GB 单卡，或 2×24GB |
三个必须注意的点。
- 量化会掉效果。INT4 能省大约四分之三的显存，但在归纳、长链推理、代码生成这类任务上肉眼可见地变差。同一篇文档，FP16 和 INT4 的答案质量要自己对比过再定。
- 并发不只看显存，更看计算吞吐。显存够不代表并发够。判断方法只有一个，用你们的真实提问长度和并发数做压测，看首 token 延迟和输出速度能不能接受。不要相信任何没看过你实际负载就承诺"能扛一百并发"的方案。
- 桌面级显卡和服务器卡不是一回事。消费级卡便宜，但没有 ECC、驱动面向游戏优化，长时间满载的稳定性和散热是另一套问题。先租云 GPU 把方案验证完，再决定买什么，这条能省掉大量错误采购。
三、推理框架和模型怎么选
| 框架 | 适合谁 | 特点 |
|---|---|---|
| Ollama | 个人试水、单机小团队 | 一条命令拉起，默认 4bit 量化，几乎零学习成本 |
| vLLM | 多人并发、生产环境 | 吞吐优化最好，是生产部署的主流选择，需要较好的 GPU |
| llama.cpp | 无独立显卡、边缘设备 | GGUF 量化，纯 CPU 也能跑，但速度有限 |
| TGI / SGLang | 已有 MLOps 能力的团队 | 生态与调度特性各有侧重 |
给中小企业的实用建议是用 Ollama 做验证，用 vLLM 做生产。前者让你两天内看到效果，后者让你在真实并发下不崩。
模型选择上，中文场景优先考虑国产开源模型（Qwen、DeepSeek、GLM 等系列），中文语料基础和许可证友好度通常更好。但"开源权重"不等于"可以自由商用"。不同模型、甚至同一模型的不同参数规模，许可证可能不同（有的是宽松的 Apache 2.0，有的是附加使用限制的自定义社区许可）。上线前逐字核对你要用的那个具体版本的 LICENSE 文件，不要依赖第三方博客的总结。
四、成本不是只看显卡
私有化的成本分三块，只有第一块是显性的。
- 一次性硬件。GPU 服务器是大头，另外还有存储与网络设备。具体金额随市场波动很大，任何不看你要跑什么模型、多少并发就给出的报价都不可信。
- 持续性支出。机柜托管或机房电费、散热、带宽、UPS。这部分容易被漏算，尤其在自建机房的场景下。
- 人力与集成。这是最容易被低估的一块。模型部署只是第一步，主要工作量在文档接入、权限配置、效果调优、日常运维。一个能长期维护的内部 AI 系统必须有明确的责任人。
一个实用的决策方法，先用云 GPU 按小时验证两到四周，跑通真实场景、量出真实并发和成本，再决定是自建还是继续租。一次性采购的最大风险在于买回来发现方案不对，价格反而是次要的。
五、合规边界，内部自用和对外服务的分水岭
这一节请看清楚，它决定你要不要走备案流程。
《生成式人工智能服务管理暂行办法》的适用边界很明确，它管的是向境内公众提供生成式人工智能服务的行为。同时该办法明确，企业等主体研发、应用生成式人工智能技术，未向境内公众提供服务的，不适用该办法的规定。
落到实际判断上，可以分三种情况。
- 只给内部员工用（内网知识助手、制度查询、内部客服），原则上不触发生成式人工智能服务备案或应用登记。
- 放进对外的网站、App、小程序、客户门户，让公众能用，你的身份就从"使用者"变成"提供者"，通常需要按应用或功能登记；若涉及舆论属性或社会动员能力，还要做安全评估与算法备案。
- 对外提供服务时还有内容标识义务，生成的内容需要按规定标识。
但"不需要备案"绝不等于"没有合规要求"。内部自用仍然会碰到下面这些。
- 个人信息保护。员工把客户合同、简历、工单记录投喂给模型时，你就在处理个人信息；涉及敏感个人信息的要求更严。需要在内部规则里明确哪些数据不允许上传。
- 商业秘密与权限。谁能让模型读到薪酬表、投标底价？如果检索库不做文档分级和权限，模型会替你回答本不该被看到的问题。这是私有化部署最常见也最危险的疏漏，参见我们的内部知识库方案。
- 数据出境。如果为了省事把生产数据发给境外模型 API，即便只是"测试一下"，也可能已经构成个人信息出境。这正是私有化最硬的动机。
- 等级保护。承载业务数据的 AI 平台要按等级保护要求定级备案，多数内部系统按二级考虑，涉及大量个人信息或对外服务时等级会上移。不清楚怎么定级，可以先看等保测评全流程。
- 数据备份。模型和向量库是新的核心资产，但很多人没把它纳入备份范围，而恢复演练记录同样是合规检查项，参考数据备份与容灾方案。
六、最容易踩的六个坑
- 只算权重不算 KV Cache，上线后一上并发就 OOM。
- 拿桌面卡跑生产，长稳测试一挂就是几天。
- 检索库不做权限，把全员可读的池子里混进了敏感文档。
- 没有验收标准。"效果不错"不是验收标准，要提前准备几十个真实问题当测试集，上线前后各跑一次。
- 不做引用来源。企业场景里，模型说得对不对比说得顺不顺重要得多。答案必须能点回原文，否则没人敢用。
- 建完就不管。文档会更新、模型会出新版、权限会变动，没有维护机制的内部 AI 系统会在半年内变成无人使用的摆设。
七、常见问题
一定要买 GPU 吗？ 不一定。先用云 GPU 按小时租，验证场景和并发，跑通了再决定自建。私有化的收益要在长期、稳定用量下才能摊平硬件成本。
私有化比调用 API 便宜吗？ 不一定，取决于用量规模和模型规模。判断方法是算清月调用量、租用同等算力的成本，再和 API 账单比。用量小的时候，API 几乎总是更便宜。
开源模型能商用吗？ 要看具体模型和具体版本的许可证。宽松许可（如 Apache 2.0）约束少，自定义社区许可常附带使用限制。核对原始 LICENSE 文件，不要依赖二手总结。
内部自用需要做备案吗？ 按现行办法，未向境内公众提供服务的不适用该办法，通常不触发大模型备案。但个人信息保护、商业秘密、数据出境等义务仍然存在，不能因此放松内部管控。
私有化部署这件事，技术选型只是开头，一开始有没有把显存、权限、合规身份这三件事想清楚，基本决定了后面顺不顺。如果你正在评估要不要自建，可以先做一轮现状盘点，看看现有硬件能不能用、数据敏感度到哪一级、真实并发有多少。这比先买卡靠谱得多。有需要可以联系我们一起评估。
更多选型与落地类文章，见技术分享栏目。