很多普通开发者第一次接触AI模型部署，都会有一个固定认知，觉得AI模型就是训练完成后得到的一个数据文件，把文件放到服务器上，开个端口接收请求，剩下的问题都是AI模型本身的好坏决定的。我接触这个领域快四年，见过不下几十个类似的问题，大部分稳定性故障都和AI模型本身没关系，反而是部署环节的细节没处理好。这些细节平时不显眼，一到高并发或者长期运行的场景，就会直接暴露出来，把整个服务拖垮。
资源分配别只盯着GPU
大部分人采购或者分配服务器资源，第一个关注的就是GPU的显存大小和算力，毕竟多数从业者都清楚AI模型推理靠GPU。CPU和内存的配额往往随便留一点，觉得能跑系统和网络转发就够了。实际上，AI模型处理一次完整请求，链路比普通web服务长很多：用户请求进来之后，先对原始数据做预处理，比如图片要裁剪、归一化，文本要分词、转张量，这些步骤做好之后，才会把数据传给GPU做推理，推理得到结果还要做后处理，再返回给用户。 绝大多数AI框架默认把预处理和后处理放在CPU上运行，不会自动把这些计算转移到GPU。哪怕你的GPU性能再强，这部分卡住了，GPU也拿不到数据只能空转。我那个朋友的问题就是典型，他给配了16G显存的GPU，只给了2核4G内存的CPU，高峰期请求一多，预处理排队把CPU跑满，GPU利用率一直维持在20%不到，看起来还有大量剩余资源，实际上整个链路已经堵死了。后来我们把CPU扩容到8核16G内存，高峰期CPU利用率降到60%左右，GPU利用率直接升到70%以上，超时率从15%一下子降到0.1%以下，问题就解决了。 怎么判断是不是这个问题？其实很简单，看监控数据就能区分。
如果高峰期你的服务错误率和延迟上涨，但是GPU利用率和显存占用都上不去，反而是CPU利用率先跑到100%，基本就可以确定是这里出问题。解决的方向也很明确，要么直接给CPU多分配核心和内存，要么把预处理步骤提前到客户端，或者用框架支持的GPU预处理能力，把计算转移过去，调整之后很快就能看到效果。另外，内存配额也不能太小，除了CPU要放预处理数据，AI模型的权重首先要加载到系统内存，再转到GPU显存，如果内存不够，系统会把部分数据换到磁盘交换分区，读写速度比内存慢几百倍，整个服务的性能都会被拖垮，哪怕GPU资源够也没用。所以分配资源的时候，CPU和内存都要留够余量，不能只盯着GPU。
启动预热一定不能省
做服务发布的时候，大部分人习惯停掉旧服务、启动新服务，确认端口通了就直接切流量。有一些体积很大的AI模型，加载权重本身就需要一两分钟，很多服务管理工具只要端口监听成功就判定服务启动完成，实际上AI模型还在加载，这时候接请求也会报错，所以一定要等加载完成、预热结束，再接入流量。这个流程对普通web服务没什么问题，但是放到AI模型服务上，很容易刚上线就爆错误率。 原因说起来不复杂，AI模型的权重文件通常都很大，小的几百兆，大的能到几十G。大部分推理框架在服务启动的时候，只是把权重从磁盘读到服务器的内存里，不会提前把数据搬到GPU显存，也不会提前做框架内核的初始化。
这些工作都要等第一次推理请求进来才会执行。加起来的话，第一次请求的延迟会从正常的几十毫秒，涨到几秒甚至十几秒，要是启动完直接切流量，第一批请求几乎全部超时，错误率一下子就上来了。 我之前在公司做新环境上线，就踩过这个坑。当时第一次切流量，五分钟内错误率超过30%，我们当时慌得不行，都以为是AI模型文件损坏，或者训练出了问题，已经准备回滚了。后来有人提议，给新服务发几个测试请求试试，结果发完测试请求，再切流量，一点问题都没有。从那之后，我不管帮谁看AI模型部署，都会特意提醒这一点：不管用什么发布方式，一定要加预热步骤。 最简单的预热方法，就是在服务启动完成、接入流量之前，自动发送几个符合格式要求的测试请求，把需要初始化的步骤都跑完，等推理延迟降到正常范围之后，再对外开放流量。如果你用了弹性扩缩容，高峰时候自动扩容出来的新实例，更要做预热，不然刚扩容出来的实例一接流量就全错，扩容不仅起不到作用，反而会把整个集群的错误率拉上去。哪怕是滚动发布，每次只更一个实例，也要给每个新实例做完预热再加到集群里，不然轮询到新实例的请求还是会报错，影响用户体验。
批量推理要找平衡
很多人做在线推理，默认来一个请求处理一个，觉得这样每个请求的延迟最低。实际上，大部分AI框架对批量推理做了大量优化，一次处理多个同尺寸的请求，总耗时比分开处理低很多，GPU利用率也能提上去，整体吞吐能涨好几倍。但批量大小不是越大越好，这里必须找一个平衡，不是越大性能越好。 如果把最大批量设得太大，服务需要攒够足够多的请求才会开始一次推理。要是刚好遇到低峰期，流量比较小，半天攒不够一批，每个进来的请求都要等攒批完成才能处理，平均延迟反而会涨好几倍。我之前见过一个项目，为了提吞吐，把最大批量设到128，结果低峰期平均延迟从50毫秒涨到200多毫秒，用户反馈明显变慢，后来不得不改成32，延迟才降下来。反过来，批量设太小，GPU利用率上不去，高峰期吞吐不够，还是会出现超时。
那怎么选合适的批量？我自己的经验是，先看自己服务平时的平均并发，把最大批量设成平均并发的1.5到2倍左右，再给攒批加一个最大等待时间，哪怕没攒够批量，到了时间也开始处理，这样既拿到了批量推理的性能收益，也不会让请求白白等很久。现在很多主流推理框架都支持动态批量，能自动根据当前请求量调整批量大小，不用自己写攒批逻辑，大部分场景都能用，只要把默认参数改成符合自己业务并发的数值就好，不用直接用默认值，默认参数往往偏保守，发挥不出框架的性能。还有，如果你的服务处理的请求输入尺寸不固定，太大的批量会因为要填充补齐浪费很多计算资源，这种情况批量可以设小一点，不要盲目追求大批量。
AI模型选型别盲目贪大
很多人选AI模型，默认选参数最多、效果最好的那个，觉得效果好就行了，部署的问题后面再说。参数多的AI模型效果确实通常更好，但是参数多带来的是显存内存占用高、推理速度慢，很多业务场景其实根本不需要这么大的模型。 我之前接触过一个业务项目，要做图片内容的初步筛选，一开始开发为了效果，选了一个10G参数的AI模型，结果一台带32G显存的服务器只能跑两个实例，高峰期一点扩容空间都没有，稍微有点流量波动就超时。后来我们找了同系列量化后的1G参数的AI模型，测试下来准确率只降了0.2%，完全满足业务需求，一台服务器能跑16个实例，扩容轻松很多，稳定性一下子就上去了。 所以部署AI模型的时候，不要只看模型在测试集上的效果指标，一定要结合你手里的部署资源、业务能接受的最大延迟，来选最合适的。现在很多预训练的AI模型都会提供不同参数大小的版本，还有量化压缩后的版本，一定要都部署测试一遍，测延迟、测吞吐、测资源占用，再测业务实际效果，选各方面都满足要求的，不是越大越好。很多时候小模型带来的稳定性收益，远大于那一点点效果的提升。
别忽视内存泄漏问题
AI模型服务很多是要长期运行的，很多人上线前只测了峰值性能，没做长时间的压测，很容易遇到内存泄漏的问题。尤其是用Python封装AI模型服务的，这个问题出现的概率更高。 我之前遇到过一个案例，服务上线之后前三天一切正常，第四天开始慢慢变慢，第五天直接因为内存占满被系统杀掉。查了很久才发现，开发把每次请求的中间张量存在了一个全局列表里，做日志用，但是从来没清理过，内存每天都涨两个G，慢慢就把内存占满了。
还有很多情况，是处理完请求之后，中间变量没有释放，引用没有断，垃圾回收不了，内存就会慢慢涨。这个问题的特点是初期不明显，积累几天才会暴露，排查起来很费时间。 所以上线AI模型服务之前，一定要做几个小时的持续压测，跑的时候观察内存的变化曲线，如果内存是持续上涨不回落，基本就是有泄漏，要提前改，不要等上线出了问题再排查。上线之后也要加上内存使用率的告警，提前发现问题，不要等服务挂了才知道出问题。
还有一个容易被忽略的点，是请求队列的长度限制。AI模型服务的流量经常不均匀，有时候会突然来一波突发流量，请求量一下子涨好几倍，如果没有队列长度限制，所有请求都堆在服务端的队列里，所有请求的延迟都会被拉长，严重的时候整个服务会被拖垮。 很多人觉得队列越长，能容纳的请求越多，不会丢请求，体验更好。
实际上，队列太长的时候，排在后面的请求要等很久才能处理，用户早就超时重试了，这些请求的处理本身就是浪费资源，还影响了排在前面的请求。合理的做法是给服务端设置一个最大队列长度，要是队列满了，就直接返回让客户端重试，或者让负载均衡把请求发到其他空闲实例，这样反而能保证大部分请求的正常响应，不会把整个实例拖垮。
另外，监控指标要做细分，很多人部署AI模型服务，只监控GPU利用率和显存占用，出了问题只能知道服务慢了，不知道哪里慢了。其实最好把整个链路的时间拆开，分别统计预处理时间、排队时间、推理时间、攒批时间，出问题的时候看哪个时间涨了，一下子就能定位到问题，不用像我那个朋友一样，一开始错怪AI模型本身，查半天才找到问题根源。
总的来说，AI模型部署的稳定性，很少是因为AI模型本身的问题，大部分都是细节没做到位。很多开发者刚从业务开发转过来做AI模型相关的服务，容易把注意力都放在模型训练和效果上，忽略部署环节的这些细节，结果上线之后各种问题，浪费很多时间排查。这些坑看起来都是小事，但是真出问题，排查起来成本很高，所以我感觉比较值得提前注意。其实只要把这些常见的坑提前避开，做好测试，AI模型服务的稳定性就能提升很多，不会动不动就出问题。