★ FEATURED ARTICLE 1. 私有化部署到底在解决什么问题第一次被问到“大模型能不能部署到我们自己的机房里”的时候我脑子里第一反应不是技术方案而是三个很现实的问题数据能不能出去、推理成本能不能控住、模型效果能不能达标。这三个问题基本决定了一个私有化部署项目是能落地还是变成一堆废铁。所谓私有化部署说白了就是把原本跑在别人服务器上的大模型搬到你自己能控制的硬件环境里。这个环境可以是公司内部的机房也可以是某个云服务商提供的专属实例核心特征是模型权重在你手里推理请求不经过第三方数据不出你的网络边界。听起来很简单但真正做过的人都知道从“能跑起来”到“能扛住生产流量”之间隔着一条巨大的鸿沟。我见过太多团队在演示环境里跑通了几个对话就以为私有化部署已经完成了。结果一上生产并发稍微高一点就超时显存动不动就爆模型回答质量忽高忽低运维同学半夜被叫起来重启服务。这些问题的根源往往不在模型本身而在于整个部署架构的设计思路从一开始就没有考虑生产环境的要求。这篇文章想聊的就是从零到一搭建一套能真正用于生产的大模型私有化部署方案。我会把重点放在架构选型、硬件估算、推理引擎配置、性能调优和线上问题排查这几个环节尽量把每个决策背后的逻辑讲清楚。适合正在评估私有化部署可行性的技术负责人也适合已经动手但遇到瓶颈的工程师。不管你是刚开始调研还是已经在踩坑的路上希望这些经验能帮你少走一些弯路。2. 部署方案的整体设计与选型思路2.1 先搞清楚你的场景到底需要什么私有化部署最怕的就是一上来就选模型、买显卡完全不考虑实际业务场景。我一般会先问三个问题第一你的用户量级和并发峰值大概是多少第二你对首字延迟和整体响应时间的要求是什么第三你的数据敏感级别和合规要求有多高这三个问题的答案会直接决定后面的所有技术选型。举个例子如果是内部知识库问答用户可能就几十个人并发不超过个位数那单卡部署一个中等规模的模型就足够了重点应该放在检索增强的准确率上。但如果是面向外部客户的客服系统并发可能上百那就必须考虑多卡推理、请求队列、自动扩缩容这些生产级特性。场景不同方案的成本可能差十倍以上。还有一个容易被忽略的点是模型的输出长度。有些场景只需要回答一两句话有些场景需要生成完整的报告。输出长度直接决定了推理时间和显存占用因为大模型的解码过程是逐token生成的输出越长占用显存的时间就越久。我在估算资源的时候通常会按照峰值并发乘以平均输出长度的两倍来预留余量这个系数是根据实际压测经验得来的能覆盖大部分突发情况。2.2 模型选型的几个关键权衡模型选型是私有化部署里最纠结的环节之一。开源模型现在很多参数规模从几十亿到上千亿都有但并不是越大越好。我的经验是在满足效果要求的前提下选最小的那个。原因很简单模型越大推理成本越高部署复杂度也越高。具体来说70亿参数级别的模型经过量化后单张消费级显卡就能跑起来适合预算有限或者并发不高的场景。130亿到340亿参数的模型通常需要专业级显卡比如A100或者同级别的卡适合对效果有较高要求且有一定预算的团队。700亿参数以上的模型基本就要多卡并行推理了硬件成本和运维复杂度都会显著上升。量化是另一个关键决策点。简单说量化就是把模型权重从高精度浮点数压缩成低精度表示比如从16位压缩到8位甚至4位。这样做的好处是显存占用大幅降低推理速度也能提升但代价是模型效果可能会有轻微下降。我实测下来8位量化对大多数任务的效果影响很小基本可以忽略但4位量化在一些需要精细推理的任务上就会出现明显的质量下降。所以我的建议是优先考虑8位量化除非显存实在不够再考虑4位。还有一个经常被忽视的因素是模型的许可证。有些开源模型虽然权重公开但商用需要额外授权或者对使用场景有限制。这个在选型阶段就要确认清楚不然后面法务那边过不了整个项目都要推倒重来。2.3 推理引擎怎么选推理引擎是私有化部署的核心组件它负责加载模型、处理请求、管理显存、调度计算。目前主流的选择有几个方向一种是直接用模型官方提供的推理代码简单但性能一般另一种是用专门的推理框架比如vLLM、TGI这类性能好但需要额外的学习成本。我个人的选择逻辑是这样的如果是做原型验证或者并发极低直接用官方代码最省事。但只要是生产环境我一定会用专门的推理框架。原因在于这些框架做了大量底层优化比如连续批处理、页式注意力、张量并行等这些优化能把吞吐量提升几倍甚至十几倍。没有这些优化你的显卡利用率可能连30%都不到等于在烧钱。以vLLM为例它的核心优势是PagedAttention机制简单理解就是把显存里的键值缓存像操作系统管理内存页一样管理起来避免了传统实现中的显存碎片问题。这个机制让它在高并发场景下的吞吐量表现非常突出。TGI则是另一个成熟选择对HuggingFace生态的支持更好部署也更简单。两者各有优劣选哪个主要看你的技术栈和团队熟悉程度。3. 硬件估算与资源规划实操3.1 显存到底怎么算显存估算是私有化部署里最容易翻车的地方。很多人只算了模型权重占用的显存忽略了推理过程中键值缓存和中间激活值的开销结果一跑起来就爆显存。我一般会用一个简化的公式来估算总显存需求等于模型权重加上键值缓存加上中间激活值再乘以一个安全系数。模型权重的计算比较直接参数量乘以每个参数的字节数。比如一个70亿参数的模型用16位精度存储就是70亿乘以2字节大约14GB。如果用8位量化就是7GB左右。这部分是固定的不会随并发变化。键值缓存才是真正的变量。它的大小取决于并发数、序列长度、模型层数和注意力头数。简化估算的话每个token的键值缓存大约等于模型层数乘以隐藏维度乘以2乘以精度字节数。以一个32层的模型为例隐藏维度409616位精度每个token大约需要0.5MB的键值缓存。如果并发是10平均序列长度是2048那键值缓存就需要10乘以2048乘以0.5MB大约10GB。这个数字会随着并发和序列长度线性增长所以高并发场景下键值缓存往往比模型权重还大。中间激活值的开销相对小一些但也不能忽略一般预留2到4GB比较稳妥。把这些加起来再乘以1.2的安全系数就是你应该准备的显存下限。我一般还会再留20%的余量因为实际运行中会有各种临时分配和碎片算得太紧很容易出问题。3.2 显卡选型的实际考量知道了显存需求接下来就是选显卡。这里有一个常见的误区只看显存大小不看显存带宽。大模型推理是典型的显存带宽瓶颈任务因为每生成一个token都要把整个模型权重读一遍。显存带宽越高推理速度越快。所以同样是80GB显存的卡带宽高的那张可能比带宽低的快一倍以上。另一个考量是卡的数量和互联方式。如果单卡显存不够就需要多卡并行。多卡并行有两种主要方式张量并行和流水线并行。张量并行是把每一层的计算拆到多张卡上通信量大但延迟低流水线并行是把不同层分配到不同卡上通信量小但会有气泡时间。生产环境里我一般优先考虑张量并行因为延迟更可控但前提是卡之间有高速互联比如NVLink或者高速PCIe。还有一个很现实的问题显卡的供应和成本。高端显卡不是想买就能买到的价格波动也很大。所以在方案设计阶段就要考虑替代方案比如用多张中端卡代替一张高端卡或者接受稍低的效果用更小的模型。我一般会准备两套方案一套是理想配置一套是降级配置这样在采购遇到问题时能快速调整。3.3 存储和网络别拖后腿硬件规划里最容易被忽视的就是存储和网络。模型文件动辄几十GB甚至上百GB如果存储的读取速度跟不上加载模型就要等很久。我建议用NVMe SSD做模型存储读取速度比普通SSD快好几倍模型加载时间能从几分钟缩短到几十秒。网络方面如果是多机部署节点之间的通信带宽直接影响推理延迟。我遇到过因为用了千兆网络导致多机推理比单机还慢的情况后来换成万兆网络才解决。如果是单机多卡那卡之间的互联带宽就是关键PCIe 4.0 x16的带宽是32GB/sNVLink能到几百GB/s差距非常大。还有一点是请求的入口网络。如果服务是对外提供的入口带宽要能扛住峰值流量。一个简单的估算方法是峰值并发乘以平均请求大小乘以8再除以响应时间要求就是需要的带宽下限。这个数字看起来可能不大但实际中经常因为忽略了响应体的传输时间而导致超时。4. 推理服务的部署与调优4.1 从零搭建一个推理服务假设我们现在要部署一个中等规模的模型硬件是单机四卡。第一步是准备环境包括显卡驱动、CUDA、Python环境这些基础依赖。这里有一个坑显卡驱动版本和CUDA版本必须匹配而且要和推理框架的要求一致。我一般会先查推理框架的官方文档确认它支持的CUDA版本范围然后倒推去装对应的驱动。环境准备好之后就是下载模型权重。如果是从公开渠道下载要注意权重的完整性和版本。我遇到过下载过程中断导致权重文件损坏的情况加载的时候报了一堆莫名其妙的错误排查了半天才发现是文件不完整。所以下载完一定要校验文件的哈希值确认和官方提供的一致。接下来是配置推理框架。以vLLM为例启动命令里需要指定模型路径、张量并行数、显存利用率上限、最大序列长度这些参数。张量并行数一般等于显卡数量显存利用率上限我一般设成0.9留一点余量给系统。最大序列长度要根据实际场景设置设得太大浪费显存设得太小又会导致长请求被截断。启动之后先用几个简单的请求测试一下确认服务能正常响应。然后逐步增加并发观察显存占用、延迟、吞吐量的变化。这个过程我一般会持续跑几个小时因为有些问题只有在长时间运行后才会暴露比如显存泄漏、连接池耗尽等。4.2 关键参数的调优经验推理框架的参数调优是提升性能的关键。我挑几个最重要的参数说一下我的经验值。第一个是最大批处理大小。这个参数控制一次前向计算能处理多少个请求。设得太小显卡利用率上不去设得太大延迟会显著增加。我的经验是从小往大试找到一个吞吐量和延迟的平衡点。一般来说对于70亿参数的模型批处理大小在16到32之间比较合适对于更大的模型可能要降到8甚至4。第二个是键值缓存的块大小。这是PagedAttention机制里的概念块太小会导致管理开销大块太大又会浪费显存。默认值通常是16我实测下来大多数场景下这个值都够用不需要调整。但如果你的请求序列长度分布很不均匀可以尝试调大一些。第三个是调度策略。推理框架一般支持多种调度策略比如先来先服务、最短作业优先等。生产环境里我一般用先来先服务因为行为可预测不会出现长请求被饿死的情况。但如果你的场景里短请求占绝大多数用最短作业优先能显著降低平均延迟。还有一个容易被忽略的参数是请求的超时时间。设得太短正常的长请求会被误杀设得太长异常请求会占用资源很久。我一般会根据实际场景的P99延迟来设置通常是P99延迟的两到三倍。4.3 多卡并行的配置要点多卡并行是提升推理能力的必要手段但配置起来有不少坑。首先是张量并行的切分方式不同的切分策略对通信量的影响很大。我一般用框架默认的切分方式因为它是经过优化的手动调整往往得不偿失。其次是卡之间的负载均衡。如果某张卡的计算量比其他卡大整个推理速度就会被这张卡拖慢。这种情况在模型层数不能被卡数整除时尤其明显。解决办法是选择卡数能整除模型层数的配置比如32层的模型用4卡或8卡而不是3卡或5卡。还有一个实际问题是显存的不均衡。由于键值缓存是动态分配的不同卡上的显存占用可能会有差异。如果某张卡先满了整个服务就会开始拒绝请求。我一般会设置一个显存水位线当任何一张卡的显存超过阈值时就触发告警提前介入处理。多机部署的话还要考虑网络延迟对张量并行的影响。张量并行每层都要通信网络延迟会直接累加到推理延迟上。所以多机张量并行只适合有高速互联的场景否则还是用流水线并行更实际。5. 生产环境的稳定性保障5.1 监控体系怎么搭生产环境和实验环境最大的区别就是你不可能一直盯着服务看。所以一套完善的监控体系是必须的。我一般会监控四个层面的指标硬件层、服务层、业务层和成本层。硬件层主要看显卡利用率、显存占用、温度、功耗这些。显卡利用率长期低于50%说明资源浪费长期高于90%说明快到瓶颈了。显存占用要特别关注键值缓存的部分如果持续增长不回落可能有内存泄漏。服务层看请求量、延迟分布、错误率、队列长度这些。延迟不能只看平均值要看P50、P95、P99因为平均值会被大量快速请求拉低掩盖长尾问题。队列长度是很好的预警指标队列开始积压说明处理能力跟不上了。业务层看模型输出的质量指标比如回答长度分布、拒答率、用户反馈等。这些指标能帮你发现模型效果的变化有时候硬件没问题但模型效果下降了可能是输入分布变了。成本层看每千token的推理成本、显卡利用率对应的有效吞吐量等。这个指标能帮你判断资源是否用在了刀刃上也为后续扩容提供依据。5.2 常见故障和排查思路私有化部署的故障排查有一套通用的思路先看硬件再看框架最后看模型。硬件问题通常表现为服务直接崩溃或者显卡报错这种看日志就能定位。框架问题表现为服务能跑但性能不达标需要看框架的日志和监控指标。模型问题表现为输出质量异常需要对比输入输出和预期。我整理了一个常见问题速查表都是实际踩过的坑现象可能原因排查方法解决措施服务启动即崩溃显存不足或CUDA版本不匹配查看启动日志中的错误码降低显存利用率上限或重装匹配的CUDA推理速度突然变慢显存碎片或键值缓存占满监控显存占用和碎片率重启服务或调整键值缓存块大小高并发下大量超时队列积压或批处理过大查看队列长度和批处理大小增加实例或调小批处理大小输出质量下降量化精度损失或输入分布变化对比量化前后的输出换用更高精度或重新校准显存缓慢增长不释放内存泄漏或缓存未清理长时间监控显存曲线升级框架版本或定期重启还有一个很隐蔽的问题是显卡降频。当显卡温度过高时它会自动降低频率来保护硬件导致推理速度下降。这个问题在监控里表现为显卡利用率没变但吞吐量下降了。解决办法是改善机箱散热或者限制功耗。5.3 灰度发布和回滚机制生产环境的任何变更都应该有灰度发布和回滚机制。模型更新、参数调整、框架升级这些操作都可能引入问题。我的做法是先把新版本部署到一个独立的实例上用一小部分流量测试确认没问题再逐步扩大流量比例。灰度发布的关键是流量切分要精确。我一般用请求头里的某个字段来做路由比如用户ID的哈希值这样同一个用户的请求会稳定地打到同一个版本上避免体验不一致。流量比例从1%开始观察至少半天确认各项指标正常后再增加到10%、50%、100%。回滚机制要能在分钟级别完成。这意味着新版本的部署不能覆盖旧版本而是并行部署通过路由切换来生效。旧版本的资源要保留至少一天确认新版本稳定后再释放。我遇到过新版本上线后第二天才发现问题的情况如果旧版本已经释放了回滚就要重新部署时间会长很多。6. 成本控制与性能平衡6.1 推理成本的构成分析私有化部署的成本不只是显卡的采购费用还包括电费、机房空间、运维人力、模型更新等。我一般会把成本拆成固定成本和变动成本两部分。固定成本是硬件采购和机房租赁这部分和并发量无关。变动成本是电费和运维这部分和实际使用量相关。电费经常被低估。一张高端显卡的功耗在300到700瓦之间四卡服务器加上其他组件整机功耗可能超过3千瓦。按工业电价算一年电费可能就够买一张新卡了。所以在估算总拥有成本的时候电费一定要算进去。运维人力是另一个隐性成本。私有化部署意味着你要自己负责服务的可用性出了问题要自己排查。如果团队里没有熟悉大模型推理的工程师这个成本会很高。我一般建议至少有一个专职人员负责推理服务的运维兼职的话很容易出问题。6.2 提升吞吐量的实用技巧提升吞吐量是降低单位成本的最直接手段。除了前面说的批处理和并行配置还有几个技巧很实用。第一个是请求预处理。把多个短请求合并成一个长请求能显著提升显卡利用率。这个技巧在客服场景特别有效因为用户的问题通常很短单独处理很浪费。合并的时候要注意保持请求的独立性不能把不同用户的请求混在一起。第二个是输出长度控制。很多场景其实不需要模型生成很长的回答但模型默认会一直生成到结束符。通过设置最大输出长度或者引导模型生成简短回答能大幅减少计算量。我实测下来把平均输出长度从500token降到200token吞吐量能提升一倍以上。第三个是缓存常用回答。对于一些高频的、答案固定的问题可以把模型的输出缓存起来下次遇到同样的问题直接返回缓存结果。这个技巧在FAQ场景特别有效能减少大量重复计算。缓存的失效策略要根据业务特点来定我一般用时间加内容双重失效确保回答的时效性。6.3 什么情况下该考虑扩容扩容的时机判断很重要扩早了浪费钱扩晚了影响体验。我一般看三个信号第一P99延迟持续超过目标值第二队列长度在高峰时段持续增长第三显卡利用率在高峰时段持续超过85%。这三个信号出现任何一个就说明当前资源已经接近瓶颈了。但扩容之前我会先确认是不是可以通过调优来解决问题。很多时候延迟高不是因为资源不够而是因为配置不合理。比如批处理大小设得太大导致单个请求等待时间过长或者键值缓存块大小不合适导致显存浪费。这些通过调参就能解决不需要加卡。如果确认是资源瓶颈扩容也有两种方式纵向扩容和横向扩容。纵向是换更强的卡适合单请求延迟敏感的场景。横向是加更多的实例适合高并发的场景。我一般优先考虑横向扩容因为更灵活也更容易做灰度发布和故障隔离。7. 模型更新与版本管理7.1 模型迭代的工程化流程私有化部署不是一次性的工作模型会不断更新业务需求也会变化。所以需要一套工程化的流程来管理模型迭代。我一般把流程分成四个阶段评估、测试、灰度、全量。评估阶段是判断新模型是否值得更新。我会用一组固定的测试用例来对比新旧模型的效果包括准确率、响应长度、拒答率等指标。只有新模型在关键指标上有明显提升才会进入下一阶段。测试阶段是在实验环境里部署新模型用模拟流量压测确认性能和稳定性达标。这个阶段要特别关注显存占用和延迟的变化因为新模型可能更大或者结构不同资源需求会变化。灰度阶段就是前面说的用一小部分真实流量验证。全量阶段是逐步扩大流量到100%。每个阶段都要有明确的通过标准和回滚预案不能凭感觉推进。7.2 版本回滚的实操细节版本回滚看起来简单实际操作中有很多细节要注意。首先是模型文件的存储旧版本的权重不能删要保留到新版本稳定运行至少一周。其次是配置文件的版本管理推理框架的参数、环境变量这些都要和模型版本对应起来回滚的时候一起回滚。还有一个容易忽略的是缓存的一致性。如果用了输出缓存回滚模型后缓存里的内容可能和新模型的行为不一致。我一般会在回滚时清空缓存虽然会导致短暂的性能下降但能避免不一致的问题。回滚的触发条件也要提前定义好。我一般设三个触发条件错误率超过阈值、P99延迟超过阈值、业务指标下降超过阈值。任何一个触发就自动回滚不需要人工判断。自动回滚能大大缩短故障时间特别是在半夜出问题的时候。7.3 多模型共存的资源隔离有时候业务需要同时运行多个模型比如一个通用模型加一个专用模型。这种情况下资源隔离就很重要。我一般用两种方式一种是物理隔离不同模型跑在不同的显卡上另一种是逻辑隔离用推理框架的多模型支持共享显卡但限制各自的资源配额。物理隔离的好处是互不影响一个模型出问题不会影响另一个。缺点是资源利用率低因为每个模型都要预留峰值资源。逻辑隔离的好处是资源利用率高但一个模型的高负载可能会影响另一个模型的延迟。我的选择逻辑是如果两个模型都很重要且延迟敏感用物理隔离如果一个是主要服务一个是辅助服务用逻辑隔离。不管用哪种方式都要有独立的监控和告警能快速定位是哪个模型出了问题。8. 安全与合规的落地要点8.1 数据不出域的边界控制私有化部署的核心价值之一就是数据不出域但这个边界需要技术手段来保证。我一般从三个层面来控制网络层、应用层和数据层。网络层是最基础的推理服务部署在内网不暴露公网入口。所有请求都通过内网网关转发网关做认证和审计。如果必须对外提供服务那入口要做严格的访问控制比如IP白名单、请求签名等。应用层是控制哪些数据能进入模型。我一般会在请求进入模型之前做一次敏感信息过滤把身份证号、手机号这类信息脱敏或者拦截。这个过滤规则要根据业务场景来定太严会影响正常使用太松又起不到保护作用。数据层是控制模型的输出。有些模型可能会在回答里泄露训练数据中的敏感信息所以输出也要做过滤。我一般会用关键词匹配加模型判断的双重机制关键词匹配快速拦截明显的敏感内容模型判断处理更隐蔽的泄露。8.2 访问控制和审计日志访问控制的核心是最小权限原则。每个调用方只能访问它需要的模型和接口不能跨权限访问。我一般用API Key加权限列表的方式来实现每个Key绑定一组允许的模型和操作。Key要定期轮换泄露了能快速失效。审计日志要记录每一次请求的完整信息谁在什么时候调用了哪个模型输入是什么输出是什么耗时多久。这些日志不仅是安全审计的需要也是排查问题和分析用量的依据。日志的存储要注意脱敏不能把敏感信息明文存下来。日志的保留时间要根据合规要求来定我一般至少保留半年。存储成本不低所以我会做冷热分离最近一个月的日志放在快速存储里方便查询更早的日志归档到低成本存储。8.3 模型输出的内容安全模型输出的内容安全是私有化部署里比较棘手的问题。因为模型是生成式的你很难预测它会输出什么。我一般用三层防护输入过滤、输出过滤和人工审核。输入过滤是拦截明显恶意的请求比如试图让模型生成违规内容的提示词。这个用规则加模型判断的方式来做规则处理已知的攻击模式模型判断处理变种。输出过滤是对模型的回答做检查发现违规内容就拦截或者替换。这个的难点是平衡过滤太严会导致正常回答被误杀过滤太松又起不到作用。我一般会设置一个置信度阈值高置信度的违规直接拦截低置信度的标记出来人工审核。人工审核是最后一道防线适合对内容安全要求极高的场景。但人工审核的成本很高不可能对所有输出都审核。我一般用采样加重点监控的方式对高风险场景的输出做全量审核对低风险场景做抽样审核。9. 从单机到集群的扩展路径9.1 什么阶段该从单机走向集群单机部署的瓶颈通常出现在两个地方显存不够或者并发不够。显存不够表现为模型加载不了或者键值缓存经常占满并发不够表现为队列经常积压。这两个问题出现任何一个就说明该考虑集群了。但集群不是简单的加机器它带来的是架构复杂度的指数级上升。你需要考虑负载均衡、服务发现、配置同步、日志聚合、监控统一这些问题。所以我的建议是能单机解决就单机解决实在不行再上集群。单机四卡能支撑的并发量其实不小很多场景根本用不到集群。判断是否该上集群的一个简单方法是看显卡利用率。如果单机的显卡利用率在高峰时段已经超过80%而且通过调优无法降下来那说明单机确实到瓶颈了。如果利用率只有50%但延迟还是高那问题可能在别的地方加机器也解决不了。9.2 集群部署的架构设计集群部署的核心是负载均衡和故障转移。负载均衡我一般用两种方式一种是四层负载均衡根据连接数或者轮询来分发请求另一种是七层负载均衡根据请求内容来分发。四层更简单七层更灵活。我一般用四层做基础分发七层做灰度发布和特殊路由。故障转移是集群必须有的能力。任何一个节点挂了请求要能自动转到其他节点。这个用健康检查加自动摘除来实现。健康检查的频率要适中太频繁会增加开销太慢又会导致故障发现不及时。我一般设成每5秒检查一次连续3次失败就摘除。配置同步是集群部署里容易出问题的地方。所有节点的模型版本、推理参数、环境变量必须一致否则会出现行为不一致的问题。我一般用配置中心来管理所有节点从配置中心拉取配置变更时统一推送。配置变更也要走灰度流程先推一个节点确认没问题再推全部。9.3 弹性伸缩的实现思路弹性伸缩是集群的高级能力能根据负载自动调整节点数量。实现思路是监控关键指标当指标超过阈值时自动增加节点低于阈值时自动减少节点。听起来简单但实际做起来有很多细节。首先是扩容的触发指标。我一般用队列长度而不是显卡利用率因为队列长度更直接地反映了处理能力是否足够。队列开始积压就扩容队列清空就缩容。阈值要根据实际压测来定我一般设成队列长度超过10就扩容低于2就缩容。其次是扩容的速度。新节点从启动到能处理请求需要时间包括加载模型、预热等。这个时间可能长达几分钟所以扩容要有提前量。我一般会在预测的高峰期之前就提前扩容而不是等队列积压了才扩。缩容要更谨慎因为缩容过程中正在处理的请求会受影响。我一般会先停止向要缩容的节点发送新请求等它处理完存量请求后再下线。这个等待时间要根据最长请求的处理时间来定我一般设成5分钟。10. 实际项目中的经验与教训10.1 那些文档里不会写的坑第一个坑是显卡的ECC内存。有些专业显卡默认开启ECC会损失一部分显存和带宽。如果你的显存估算刚好卡在边界上ECC可能就是压垮骆驼的最后一根稻草。我一般会在部署前确认ECC的状态如果不需要可以关掉能多出一些可用显存。第二个坑是CUDA的上下文初始化时间。第一次加载模型的时候CUDA要初始化上下文这个过程可能长达几十秒。如果服务启动后马上接收请求可能会超时。我一般会在服务启动后先发几个预热请求等CUDA上下文初始化完成后再接入流量。第三个坑是文件描述符的限制。高并发场景下每个连接都要占用一个文件描述符系统默认的限制可能不够。我遇到过因为文件描述符耗尽导致新连接无法建立的情况排查了很久才发现是系统限制的问题。解决办法是调大系统的文件描述符上限同时确保推理框架也配置了足够的连接数。第四个坑是时间同步。集群部署时如果节点之间的时间不同步日志的时间戳会对不上排查问题的时候很痛苦。我一般会用NTP服务来同步时间确保所有节点的时间误差在毫秒级以内。10.2 性能调优的实战案例有一个项目模型部署上去之后延迟一直不达标P99延迟是目标值的两倍。排查了一圈硬件没问题框架配置也没问题。最后发现是请求的输入长度分布很不均匀大部分请求很短但少数请求特别长。长请求会占用大量的键值缓存导致后续的短请求也要等待。解决办法是做了请求分级。短请求走快速通道用较小的批处理大小和较短的超时时间。长请求走普通通道用较大的批处理大小。两个通道用不同的模型实例来处理互不影响。这样调整之后短请求的P99延迟降到了目标值以内长请求的延迟虽然稍高但也在可接受范围内。另一个案例是显存碎片问题。服务运行几天后显存占用越来越高最后OOM。排查发现是键值缓存的分配和释放产生了碎片虽然总空闲显存够但没有连续的大块可用。解决办法是调整了键值缓存的块大小从默认的16调到32减少了碎片产生的概率。同时加了定期重启的策略每周重启一次彻底清理碎片。10.3 团队协作和流程建设私有化部署不是一个人的事需要算法、工程、运维多个角色配合。我一般会建立几个固定的流程来保证协作顺畅。模型交接流程算法团队提供模型时要附带模型卡说明模型的训练数据、评估指标、已知限制、推荐参数。工程团队根据模型卡来配置推理服务避免因为不了解模型特性而配置不当。变更管理流程任何对生产环境的变更都要走审批包括模型更新、参数调整、框架升级。审批时要评估影响范围和回滚方案不能随意变更。故障响应流程定义故障的等级和响应时间一级故障要立即响应二级故障要在半小时内响应。每次故障后要做复盘找出根因并制定改进措施避免同样的问题再次发生。这些流程看起来繁琐但能大大减少沟通成本和故障概率。我经历过没有流程时的混乱也体验过有流程后的顺畅差别真的很大。最后分享一个小心得私有化部署的文档一定要写而且要写得详细。包括架构图、配置说明、操作手册、故障排查指南。这些东西在项目初期可能觉得没必要但等到人员变动或者出故障的时候一份好的文档能救命。我一般要求团队里的每个人都能根据文档独立完成部署和排查做不到就说明文档还不够好。
阅读完成 · 觉得有帮助？
