1. 私有化部署的真实驱动力：为什么企业不再满足于调API
这两年跟不少团队交流下来，我发现一个很明显的分水岭：前两年大家聊大模型，问的都是"哪家API便宜、哪家响应快"；现在再聊，话题几乎都变成了"我们想把模型搬到自己的机器上"。这个转变不是跟风，而是被现实逼出来的。
最直接的推力是数据主权。很多业务场景里，喂给模型的输入本身就带着敏感信息——合同条款、客户档案、内部工单、医疗记录。这些数据一旦离开自己的网络边界，合规部门第一个不答应。哪怕服务商承诺不训练、不留存，审计那一关也很难过。私有化部署最朴素的价值，就是让数据从"出网"变成"不出网"，这条链路短了，风险面自然就小了。
第二个推力是成本结构的重构。API按token计费，用量小的时候很香，但一旦业务量上来，尤其是那种高频、短文本、7×24小时跑的场景，账单会以肉眼可见的速度膨胀。私有化部署是典型的重资产模式：前期买卡、搭环境、调优，一次性投入大，但边际成本极低。当你的日均调用量跨过某个临界点，自建的性价比就反超了。这个临界点没有统一答案，得自己算。
第三个推力是可控性与定制化。API是黑盒，你只能调参数，改不了模型本身。但私有化之后，你可以做量化压缩、可以接自己的知识库做RAG、可以针对垂直领域做微调、可以控制推理时的并发和超时策略。这种"从里到外都能动"的自由度，是很多做深度业务的团队真正想要的。
不过我得先把丑话说在前面：私有化部署不是把模型文件下载下来、跑个启动脚本就完事了。从"能跑起来"到"能扛住生产流量"，中间隔着一整套工程体系。下面我就按实际落地的顺序，把这条链路拆开讲。
2. 硬件选型：先算清楚你要喂多大的模型
硬件是整个私有化部署的地基，选错了后面全是坑。而选硬件的核心变量只有一个：你要部署多大的模型，以及要支撑多大的并发。这两件事决定了显存、算力和带宽的下限。
2.1 显存是硬门槛，先按参数量估个底
大模型推理时，权重、KV Cache、激活值都要占显存。最粗略的估算方式是看权重占用：
- FP16精度下，每10亿参数大约占2GB显存。一个70B的模型，光权重就要140GB左右。
- INT8量化后大约减半，70B约70GB。
- INT4量化后大约再减半，70B约35GB。
但这只是权重。真正跑起来，KV Cache才是吃显存的大户，而且它跟并发数、上下文长度成正比。上下文越长、同时处理的请求越多，KV Cache膨胀得越厉害。所以你不能只看"模型能不能装下"，还要留出足够的余量给KV Cache和运行时开销。
我的经验是：权重占用之外，至少再留30%到50%的显存余量。比如70B的INT4模型权重约35GB，那单卡至少要有48GB以上才比较从容，80GB的卡会更舒服。
2.2 单卡还是多卡：别一上来就堆集群
很多人一听说要部署大模型，第一反应是"上八卡机"。但其实要看模型规模：
| 模型规模 | 推荐配置 | 说明 |
|---|---|---|
| 7B及以下 | 单张24GB消费级卡 | 量化后单卡轻松跑，适合验证和轻量业务 |
| 13B-14B | 单张24GB-48GB | INT4量化单卡可跑，FP16需要更大显存 |
| 32B | 单张48GB或双卡24GB | 量化后单卡可行，注意KV Cache余量 |
| 70B | 双卡48GB或单卡80GB | INT4量化下双卡较稳，需考虑卡间通信 |
| 100B以上 | 多卡多机 | 必须上并行推理框架，工程复杂度陡增 |
多卡不是简单地把卡插上去就行。张量并行（Tensor Parallelism）会引入卡间通信开销，如果卡间带宽不够（比如走PCIe而不是NVLink），推理速度可能不升反降。所以能单卡解决就别多卡，这是省事的第一原则。
2.3 别忽略CPU、内存和存储
GPU是主角，但配角掉链子照样翻车。CPU负责数据预处理、tokenize、调度，核心数太少会成为瓶颈；系统内存要能装下模型加载时的临时副本，通常是显存的1.5到2倍；存储方面，模型文件动辄几十上百GB，用机械盘加载会慢到怀疑人生，NVMe SSD是标配。
提示：采购前一定要确认GPU的驱动版本、CUDA版本和你要用的推理框架是否兼容。我见过太多团队卡在"卡到了但驱动装不上"这一步，白白耽误一周。
3. 推理框架怎么挑：vLLM、TGI还是TensorRT-LLM
模型文件准备好了，接下来要选一个推理引擎。这一步的选择直接决定了吞吐、延迟和你的运维复杂度。市面上主流的几个方案各有脾气，我按实际使用感受说一下。
3.1 vLLM：吞吐优先场景的默认答案
vLLM最大的卖点是PagedAttention，它把KV Cache像操作系统管理内存页一样分块管理，极大减少了显存碎片，从而支持更高的并发。实测下来，同样的卡，vLLM的吞吐经常能比朴素实现高好几倍。
它的优点是开箱即用、社区活跃、对新模型支持快，OpenAI兼容的API接口也让它很容易接入现有系统。缺点是它对显存的要求相对"贪"，而且早期版本在多卡并行上的稳定性一般。不过这两年迭代很快，生产可用性已经不错了。
如果你追求的是"单位时间内处理尽可能多的请求"，vLLM基本是首选。
3.2 TGI：工程化程度高，适合标准化服务
TGI（Text Generation Inference）是另一套成熟的推理服务框架，它的特点是工程化做得很扎实：内置了连续批处理、张量并行、token流式输出，还带了监控指标和健康检查接口。部署成服务之后，运维起来比较省心。
它的短板是模型支持的跟进速度有时不如vLLM快，一些新出的模型架构可能要等官方适配。另外它的配置项比较多，初次上手需要花点时间读文档。
如果你的团队偏运维导向，希望有一个"配置好就稳定跑"的服务，TGI值得考虑。
3.3 TensorRT-LLM：极致性能，但门槛高
TensorRT-LLM是英伟达自家的方案，能把模型编译成高度优化的推理引擎，在自家卡上性能拉满。但它的代价是编译流程复杂：模型要先转换、再编译，针对不同的batch size和序列长度可能要编译多个引擎，换模型或换卡都要重新走一遍。
它适合那种模型固定、流量巨大、愿意为性能投入专门人力的场景。对大多数中小团队来说，这个投入产出比不一定划算。
3.4 选型建议：先跑通再优化
我的建议是分两步走：先用vLLM或TGI把服务跑通，验证业务闭环；等流量上来了、性能成为瓶颈，再考虑要不要上TensorRT-LLM做深度优化。一上来就追求极致性能，很容易在工程细节里陷进去，反而拖慢整体进度。
4. 从裸模型到生产服务：中间要补的几块拼图
模型能推理，只是万里长征第一步。真正让它变成"生产环境可用"，还得补上量化、服务封装、并发控制这几块。
4.1 量化：用精度换显存和速度
量化是把模型权重从高精度（如FP16）压到低精度（如INT8、INT4）的过程。它的收益很直接：显存占用下降、推理速度提升。代价是精度可能略有损失。
常见的量化方案有GPTQ、AWQ、GGUF等。我的经验是：
- INT8：精度损失很小，大多数场景可以放心用。
- INT4：显存省得多，但精度损失开始明显，尤其是对推理能力要求高的任务，要仔细评估。
- AWQ相比GPTQ在某些模型上精度保持更好，值得优先试。
量化不是无脑压到最低，而是要在"显存够不够"和"效果能不能接受"之间找平衡。建议对同一批测试用例，分别跑FP16和量化版本，对比输出质量再决定。
4.2 服务封装：OpenAI兼容接口是省事的关键
生产环境里，模型服务不可能孤立存在，它要被上层应用调用。这时候提供一个OpenAI兼容的API几乎是标配——因为大量现成的客户端、框架、工具链都默认支持这套接口，你只要对齐了，接入成本几乎为零。
vLLM和TGI都内置了OpenAI兼容的server，启动时指定端口和模型路径即可。封装时要注意几点：
- 加上鉴权，别让服务裸奔。
- 配置请求超时和最大token限制，防止单个请求拖垮整个服务。
- 开启流式输出，改善前端体验。
4.3 并发与批处理：吞吐的命门
单请求推理是浪费算力的。生产环境必须开启连续批处理（Continuous Batching），让多个请求动态拼成一个batch一起算，把GPU利用率拉满。vLLM和TGI都默认支持这个机制。
但批处理也有代价：batch越大，单个请求的延迟可能越高。所以要在吞吐和延迟之间调参。一般做法是设置一个最大batch size和最大等待时间，超过等待时间就立即执行，避免请求被无限期积压。
注意：并发数不是越高越好。当并发超过GPU处理能力，请求会排队，延迟飙升，甚至触发OOM。压测时一定要找到系统的"拐点"，把并发控制在拐点之前。
5. 上线之后：监控、扩缩容和那些踩过的坑
服务跑起来不等于万事大吉，生产环境的考验才刚开始。
5.1 必须盯住的几个指标
- GPU利用率：长期偏低说明资源浪费，长期打满说明该扩容了。
- 显存占用：要留出安全水位，接近上限就要警惕OOM。
- 首token延迟（TTFT）：用户感知最明显的指标，流式场景尤其重要。
- 每秒生成token数（TPOT）：反映持续生成速度。
- 请求队列长度：队列持续增长说明处理能力不足。
这些指标建议接入统一的监控面板，设置告警阈值。别等用户投诉了才发现服务已经卡了半天。
5.2 扩缩容策略
私有化部署的扩缩容比云上麻烦，因为机器是固定的。常见做法是：
- 横向扩展：多起几个推理实例，前面挂负载均衡。适合无状态服务。
- 纵向优化：通过量化、批处理调参榨干单卡性能。
- 分级服务：把高优先级请求和低优先级请求分到不同实例，避免互相影响。
如果预算允许，可以考虑预留一台备用机，主节点故障时能快速顶上。
5.3 我踩过的几个坑
坑一：显存碎片导致OOM。早期用朴素实现时，长上下文请求跑多了显存就碎，最后明明总量够却分配不出来。换用带PagedAttention的框架后基本解决。
坑二：模型加载慢。第一次从机械盘加载70B模型，等了快半小时。换成NVMe SSD后缩短到几分钟。模型文件一定要放在高速盘上。
坑三：并发压测没做，上线就崩。有次直接按"能跑通"的状态上线，结果十几个并发就把服务打挂了。后来老老实实做了压测，找到拐点，才敢放量。
坑四：忽略了tokenizer的CPU开销。高并发下，tokenize反而成了瓶颈，CPU核心数不够会拖慢整体。后来把CPU核数提上去才缓解。
坑五：版本管理混乱。模型文件、推理框架、驱动版本没有统一记录，出问题时排查半天。后来建了个清单，每次变更都登记，省了很多事。
6. 一套可复用的落地清单
最后把整条链路浓缩成一份清单，方便你对照执行：
- 明确需求：模型规模、并发量、延迟要求、数据合规边界。
- 算硬件：按参数量和量化方案估显存，留30%-50%余量，配足CPU、内存、NVMe。
- 选框架：吞吐优先选vLLM，运维优先选TGI，极致性能再考虑TensorRT-LLM。
- 做量化：优先试AWQ/INT8，对比精度后再定。
- 封装服务：OpenAI兼容接口+鉴权+超时+流式输出。
- 调并发：开启连续批处理，压测找拐点，控制并发在拐点前。
- 上监控：盯GPU利用率、显存、TTFT、TPOT、队列长度。
- 定扩缩容：横向多实例+负载均衡，预留备用机。
- 建台账：模型、框架、驱动版本统一登记，变更留痕。
私有化部署这件事，说难不难，说简单也不简单。它考验的不是某一项技术，而是把硬件、框架、服务、运维串成一条稳定链路的能力。我个人最大的体会是：别追求一步到位，先把最小闭环跑通，再一个环节一个环节地优化。很多坑只有真正跑起来才会遇到，纸上谈兵永远发现不了。等你把第一个生产实例稳稳跑上一个月，回头看，那些当初觉得棘手的问题，其实都有迹可循。
