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-48GBINT4量化单卡可跑FP16需要更大显存32B单张48GB或双卡24GB量化后单卡可行注意KV Cache余量70B双卡48GB或单卡80GBINT4量化下双卡较稳需考虑卡间通信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工程化程度高适合标准化服务TGIText 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、队列长度。定扩缩容横向多实例负载均衡预留备用机。建台账模型、框架、驱动版本统一登记变更留痕。私有化部署这件事说难不难说简单也不简单。它考验的不是某一项技术而是把硬件、框架、服务、运维串成一条稳定链路的能力。我个人最大的体会是别追求一步到位先把最小闭环跑通再一个环节一个环节地优化。很多坑只有真正跑起来才会遇到纸上谈兵永远发现不了。等你把第一个生产实例稳稳跑上一个月回头看那些当初觉得棘手的问题其实都有迹可循。