1. 负载上生产的两大抓手实时数据管道与弹性算力调度九月份我花了大半个月时间带着团队把两套AI负载从“能跑就行”的状态真正推到了生产级。一是在线推理链路里把实时数据管道彻底打通模型不再吃T-1的离线特征二是把推理服务的算力调度策略从固定副本改成了“按流量伸缩、空闲缩到零”。这两件事看着不相关实际上都是在解决同一个问题AI负载在生产环境里的成本与响应速度。先说结论实时数据喂模型这件事难点从来不在模型侧而在数据侧。模型推理本身几百毫秒就能完成但特征数据从业务库到模型服务之间要走的消息管道、清洗逻辑、特征拼接、缓存失效机制任何一个环节多出几秒延迟端到端延迟就压不下来。而“算力缩到零”这事难点也同样不在服务框架而在“怎么缩、缩了之后怎么拉起来、拉起来之后会不会打爆数据库”这一整套调度逻辑上。这篇文章我把自己踩过的坑、验证过的配置、以及目前线上稳定运行的那套方案完整梳理一遍。适合正在做模型服务化改造、或者被推理成本压得头疼的团队参考不管是已有一套传统架构想升级还是从零搭一套生产级推理链路都能从中找到可以直接抄作业的部分。我把整件事拆成四个部分讲实时数据链路的整体设计与组件选型、核心环节的配置细节、完整实操过程、以及我们上线后处理过的典型故障。每个部分都会附上我自己总结的经验保证你照着做不会走太多弯路。2. 实时数据管道从离线批处理到在线特征服务的改造全记录2.1 为什么一定要“实时喂”离线特征的时效性瓶颈我先算一笔账。当时线上的推荐模型用的是LightGBM特征主要分两类用户长期偏好画像一周更新一次和短期行为序列一天更新一次。在离线批量更新的架构下模型读到的用户最近一次点击行为实际上已经是几个小时甚至一天前的数据。这意味着什么用户在凌晨三点浏览了一款商品早上八点再看推荐位时模型根本不知道他昨晚看过什么推荐结果和用户当下的意图完全是错位的。延迟的代价我举一个更直观的例子。电商大促期间用户把商品加入购物车后退出两分钟后又回来了。这时候如果模型能看到“刚刚加购了A商品”这个实时特征推荐位就应该立刻展示A的配套商品、优惠券、同类替代品。但批量更新的特征服务要等到下一个调度周期才能刷新用户回来时看到还是旧推荐转化机会就这样白白溜走。实测下来把特征从T-1改成准实时后推荐位的点击率提升了大概11%这个数字背后就是时效性的价值。所以“数据要实时喂模型”本质上是把特征新鲜度从小时级压到秒级。但这句话说起来容易真正做起来牵扯到的第一个决策就是用什么方式把数据从业务系统搬到特征服务。2.2 管道选型为什么我们选了消息队列流处理而不是直连数据库刚开始我们走过弯路图省事直接让特征服务定时去业务库查增量数据。上线第一天就出问题业务库是MySQL主从架构从库本来就扛着报表查询我们每30秒轮询一次大表直接导致从库CPU飙到90%连主库都受到拖累。后来才明白生产环境的数据库不是给你模型随便轮询的特征管道必须和业务系统解耦。最终方案是用消息队列做中间层。业务系统把行为日志以事件方式异步写入Kafka流处理任务消费Kafka里的原始事件实时清洗、拼接、计算再写入特征存储供模型服务查询。这套架构的好处是业务系统只需要关心“把事件发出去”不关心下游谁在消费特征服务也不直接碰业务库数据压力被彻底隔离。选型上我们用的是Kafka Flink的组合。Kafka负责事件缓冲和解耦Flink负责窗口计算和特征聚合。可能有人会问特征聚合用Spark Streaming行不行我的答案是能跑但实时性天花板不一样。Flink是真正的流处理引擎处理延迟可以做到毫秒级窗口计算是纯内存状态Spark Streaming本质是微批次最小批次间隔也要几百毫秒到秒级而且状态管理不如Flink方便。对于特征服务这种对延迟敏感的场景Flink更合适。当然Flink也有学习成本团队如果没有流处理经验初期建议先从Kafka 轻量消费脚本开始把链路跑通后再逐步替换成Flink。我就是这么干的先把复杂问题简单化再在简单方案的基础上迭代。2.3 特征存储的读写策略Redis缓存与冷热分层数据流到了特征存储层我们又遇到一个新问题。模型服务一次推理请求需要读取几十个特征每个特征在存储里对应一条记录。如果每次推理都去查一遍数据库查询开销比模型计算本身还大端到端延迟根本压不下来。解决思路是给特征存储加上Redis缓存层而且是要区分热点特征和冷特征的分层策略。我们当时把特征分成了三层第一层是Redis热缓存存放活跃用户最近的短期行为特征这类特征访问频率最高、变动最频繁缓存过期时间设成5分钟。第二层是特征数据库存放长期偏好类特征这种特征相对稳定直接从数据库读取就行。第三层是大规模离线特征更新频率以天为单位直接从数仓同步过来数量级大但访问频率不高不需要进缓存。这里最关键的配置是Redis的过期策略和缓存击穿保护。我做了一个很细节的调整给每个特征设置了动态过期时间不是固定5分钟而是根据特征更新时间动态推算。比如某个特征刚刚更新完就意味着未来5分钟内它一定是新的直接命中缓存就行。这样能避免一个典型问题缓存刚刚过期特征存储恰好还没更新完同一时刻大量请求同时穿透到数据库把下游打挂。2.4 滑动窗口特征的计算难点与工程化处理实时特征里有一类比较特殊滑动窗口特征。比如“用户最近3分钟点击了哪些商品”“最近1小时内浏览的品类分布”。这类特征不是简单查一条记录而是要维护一个时间窗口内的行为集合窗口不停滑动特征值持续变化。我们最初的实现是用Redis的List结构存行为序列每次新事件进来就LPUSH进去然后定期清理过期元素。但流量上来后发现问题很大List越来越长清理时要从尾部遍历删除而且每次计算特征时还要把整个List读出来反序列化CPU开销和内存开销都扛不住。后来换成了Redis的ZSet用时间戳做score事件ID做member。新事件进来直接ZADD过期元素用ZREMRANGEBYSCORE一条命令清掉。计算“最近N分钟的行为”用ZRANGEBYSCORE直接取不用读全量数据。这一改单条特征计算的耗时从原来的几十毫秒降到了不到5毫秒内存占用也降了一个量级。这里有个细节值得强调窗口大小的选择不能拍脑袋要根据业务场景试出来。窗口太短特征抖动剧烈模型输出的稳定性差窗口太长特征失去实时性意义。我们在推荐场景里分别试过1分钟、3分钟、5分钟、10分钟窗口最后3分钟窗口在“实时性”和“稳定性”之间取得了最好平衡模型评估的AUC也最高。所以说工程上很多参数不是越短越好是要拿数据说话的。3. 算力缩到零Serverless推理的弹性扩缩容实践3.1 缩到零的动机推理服务闲时占用资源的账目细算说完实时数据再来说算力缩到零这件事。当时我们线上有一个面向内部运营的模型服务白天业务高峰时每秒大概要处理300个请求到了凌晨到早上六点流量几乎归零每秒不到5个请求。但原来的部署方式是固定副本数始终常驻4个推理Pod每个Pod占1张GPU卡。凌晨那六个小时这4张GPU卡就是白烧电费。我算了一笔账按当时的GPU租赁行情一张A10卡每小时成本大概在3块左右4张卡跑24小时是288块但其中6个小时的服务流量几乎为零。也就是说每天有72块钱是花在“空转”上的一个月就是两千多。这还算少的如果服务更多、业务更闲浪费比例更大。所以“算力要能缩到零”不是炫技是实实在在的成本优化。但“缩到零”也不能盲目缩。有些服务必须保持实时响应如果缩到零之后冷启动要两分钟用户点一下等两分钟那是灾难。所以我们的策略是区分场景核心在线服务设置最小副本数保证底线容量非核心的、能容忍冷启动延迟的服务才真正缩到零。3.2 弹性伸缩策略配置HPA、冷启动与突发流量之间的平衡Kubernetes原生的HPA只能看CPU、内存这类指标但推理服务的负载和CPU占用并不是线性关系。我们最终是用自定义指标做扩缩容监听每个Pod的“在途请求数”以此为信号触发伸缩。这个指标的意义在于它能直接反映服务的真实排队压力比CPU监控精准得多。配置上我给出几个关键参数的参考值。扩张阈值设在“平均每个Pod在途请求数超过5”收缩阈值设在“低于1”扩缩容冷却时间给60秒。为什么冷却时间给60秒而不是默认的5分钟因为5分钟太长流量突然起来时反应不过来容易在冷启动期内把新Pod打爆。但60秒也不能再短了否则流量小波动就会导致频繁扩缩Pod反复重建反而更浪费资源。真正的难点在缩容策略。Pod缩容下去之后K8s会先等它处理完当前请求再终止这是优雅退出机制默认的terminationGracePeriodSeconds是30秒。但如果正好有长连接请求在跑30秒不够请求就会被强制掐断。我们在配置里把这个值调到了120秒同时给服务加了一个PreStop钩子在Pod收到终止信号后先主动从负载均衡摘除自己再sleep 5秒留出时间让在途请求排空。这套组合拳下来缩容期间的错误率从0.3%降到了0.02%以下。3.3 GPU资源池化显存碎片与设备插拔的工程细节真正把算力缩到零之后又冒出一个新问题GPU显存被占着不释放。推理服务退出后显卡驱动层的显存回收有时候不是即时的下一批Pod调度上来时发现显存居然不够用。我们排查下来这涉及NVIDIA Container Toolkit的设备插拔逻辑如果上一个容器没有干净地释放CUDA上下文驱动层会有一段残留状态。这个问题的标准解法是使用GPU资源池化方案把物理GPU切成更细粒度的算力单元让多个推理任务可以共享一张卡同时做到任务结束立即回收显存。我们在生产环境用了一套相对成熟的方案按显存大小分配虚拟GPU单元一个推理任务分到几分之一张卡跑完自动归还。这里我提醒一句GPU池化不是所有场景都适用。如果模型输入张量特别大几个任务挤一张卡会导致显存溢出。我们在试点时发现轻量级BERT类模型和LightGBM模型适合池化但SD类图片生成模型、超长序列的LLM推理就不建议池化容易互相拖垮。要不要池化得先量化好单次推理的峰值显存。4. 实操过程从代码改造到生产验证的完整拆解4.1 第一阶段模型服务化与实时特征接入的代码改造整个改造我是分三个阶段推进的每个阶段都有明确的验收标准。第一阶段是代码层改造目标是让模型服务能读到实时特征。我拿当时用的验证模型举例。这是一个基于LightGBM的点击率预估服务原始版本是从离线特征表批量加载特征模型预测时用内存里的静态字典查特征。第一版改造我把特征查询从“本地静态字典”改成了“远程特征服务调用”代码看起来简单但至少动了三个关键点加上了远程调用的超时控制、加上了缓存降级逻辑、加上了特征缺失时的默认值填充。实战中这段逻辑很容易写翻车。比如远程调用超时时间设太短流量一大就频繁超时导致整批请求都走到默认特征模型预测结果全部失真。我最后的配置是连接超时200ms读取超时300ms超过就降级到本地缓存特征再不行就用默认值。宁可特征旧一点也不能让推理链路因为特征服务被拖垮。模型服务的接口改造也值得一提。我们用gRPC替代了原先的HTTP接口不是因为HTTP不行而是批量推理场景下gRPC的protobuf序列化更高效长连接也更省资源。改造后同一批请求的吞吐量提升了近40%这属于白捡的优化。手里是Python技术栈的团队我推荐用gRPC或至少用HTTP/2都能明显改善性能。4.2 第二阶段特征管道部署与生产参数校准第二阶段是把特征管道真正部署起来。我们从业务方接入了三类事件曝光事件、点击事件、加购事件。每条事件从业务系统发出到Kafka topic落盘再由Flink消费计算成特征最终写入Redis并更新特征服务整条链路的目标是端到端延迟不超过3秒。当时校准参数花了不少时间。Kafka的topic分区数我们设成了12消费者并发和分区数对应上保证消费速度能跟上生产速度。Flink的checkpoint间隔设成了10秒一次这个值不要设太频繁否则状态快照写入外部存储的开销会把吞吐拖垮。Redis那边我单独给特征服务开了AOF持久化防止进程重启后热数据丢失AOF的刷盘策略用的everysec平衡了可靠性和写入性能。管道跑起来之后我专门对比了一组数据旧链路下特征更新到模型生效的平均耗时是37分钟新链路压到了2.1秒。这个数字就是改造效果的直观体现。提醒一句各位Flink任务的并行度不要盲目设大。并行度越大占用的slot越多状态后端的内存压力也越大。我最初把并行度从2调到8结果处理延迟没有明显降低反而内存OOM了三次。因为瓶颈根本不在计算能力而在Kafka消费速度。在动手调并行度之前先看监控面板里哪个环节的堆积量最大。4.3 第三阶段服务网格化改造与算力伸缩上线第三阶段才是真正的弹性伸缩改造。我们把推理服务接入了服务网格流量入口统一走网关每个Pod的实时指标上报给K8s的metrics-server。然后配置自定义HPA规则同时把“最小副本数设成0”写进了服务配置。这里特别说一下“最小副本数设成0”的副作用。K8s默认调度器对0副本服务是不会做任何预热的流量进来的第一个请求必然经历冷启动。冷启动时长取决于模型加载方式如果你用ONNX Runtime加载模型一个LightGBM模型大概2到3秒能完成加载如果是PyTorch加载大模型那就要按秒级到分钟级估了。我们的处理是在服务启动脚本里加了一个“预加载模型”的阶段Pod一旦被拉起就先加载模型再对外宣告就绪。这样流量真正到达时模型已经热好了。整体上线后我们观察了一周的指标白天高峰期Pod数量自动从0拉到了12个吞吐量稳定维持在设计的峰值凌晨流量回落后Pod数量自动收缩到0GPU占用归零。整周算下来GPU资源成本下降了大概47%而服务的可用性依然保持在99.9%以上。5. 上线后遇到的典型故障与排障速查5.1 缓存击穿引发的特征服务雪崩上线第二天就遇到一个典型的故障某个热门特征在Redis里的缓存刚好过期而特征数据库因为Flink任务恰好延迟了一批更新导致大量请求在同一个时间窗口内穿透缓存打到了数据库上。结果数据库连接池被打满特征服务整体变慢进而拖垮了所有推理请求。排查过程是这样的先看监控面板Redis命中率从正常的95%骤降到30%数据库的慢查询数量暴涨。然后定位到具体是哪个特征出了问题最后发现是因为Flink的重启导致窗口状态丢失特征更新延迟触发了缓存击穿。修复分三步走。第一步给Redis加上了空值缓存即使数据库里查不到该特征也缓存一个空标记防止同一时刻的请求反复穿透。第二步在特征查询代码里加上了单飞的分布式锁同一特征同一时刻只有一个请求能去查数据库其他请求等待锁释放后直接读新缓存。第三步给Flink任务加了更稳的checkpoint恢复策略避免窗口状态丢失。这套组合之后类似的击穿问题再没出现过。5.2 冷启动争抢资源引发的连锁故障另一次故障出现在流量突增时。那天运营做了一场活动流量瞬间从每秒50个请求涨到400个弹性扩容策略立刻触发一次性拉起了8个Pod。但这8个Pod同时做模型加载CPU和内存瞬时飙高反而把正在处理业务请求的旧Pod挤得资源不足导致一部分请求超时。这个问题的根源是“扩容风暴”和“冷启动资源争夺”。我们的解法不复杂给扩容加上了一个速率限制HPA每轮最多新增2个Pod等它们稳定后再继续扩下一批。同时给Pod加了资源预留在调度阶段就确保每个新增Pod有足够的CPU配额做初始化不跟旧Pod抢资源。改造后流量突增场景下虽然扩容速度略慢了一点但整体稳定性明显改善没有再出现过因扩容而导致的连锁故障。5.3 常见问题速查表我把上线前后遇到过的典型问题整理成了一张速查表方便各位对号入座。| 问题现象 | 可能原因 | 排查思路 | 解决方案 | | 推理延迟偶尔飙升 | 特征查询穿透数据库 | 看Redis命中率是否骤降 | 加空值缓存、分布式锁 | | Pod反复创建销毁 | HPA阈值过于敏感 | 看扩缩容事件频率 | 调大冷却时间、加扩缩速率限制 | | 缩容后请求被掐断 | 优雅退出时间不足 | 看终止阶段的错误日志 | 调大terminationGracePeriodSeconds加PreStop钩子 | | 扩容后新Pod启动失败 | 冷启动资源不足 | 看Pod调度时的资源请求 | 设置资源预留、限制单轮扩容数量 | | 特征长期不一致 | 事件丢失或重复消费 | 对比Kafka生产和消费条数 | 开启Flink精确一次语义、幂等写入 | | GPU显存不释放 | CUDA上下文未被回收 | 看显卡显存占用率 | 使用池化方案、任务结束显式释放 | | 模型读取特征超时 | 特征服务端到端延迟超标 | 看各环节耗时分布 | 优化Redis查询、加本地缓存降级 |5.4 几个容易忽略但特别关键的小细节最后分享几个很小的细节每一个都在线上真实坑过我。第一个是Kafka消费组的提交方式。我们最初用的是自动提交结果Flink任务重启时经常出现重复消费特征被算了两遍窗口统计翻倍。改成手动提交等一批数据处理完再提交offset虽然稍微复杂一点但数据一致性有了保证。自动提交适合容忍重复的场景特征计算这种事必须精确。第二个是模型推理时特征拼接顺序要和训练时完全一致。这个坑看似低级但改特征管道后特别容易踩。我们在训练代码里是A、B、C顺序拼接推理代码不知道什么时候被人改成了C、A、B模型不报错但预测结果完全乱套。后来我在推理服务里加了一道校验用一小批已知样本比对预测输出每次发布后先跑校验再放流量。第三个是日志采样策略。推理服务在高峰期每秒几百个请求全量打日志的话日志系统先被撑爆。我们一开始没做采样结果日志服务磁盘直接写满反噬到主服务。后来改成按比例采样加错误日志全量保留既保住了排查问题的能力又控制了日志开销。6. 生产环境验证与后续可扩展的方向通过这一轮的改造我们验证了一个事实AI负载上生产模型本身的精度只是一部分真正决定能否稳定落地的是它周围的数据管道和资源调度体系。这套体系跑稳之后后续还可以往两个方向继续扩展。一是用特征平台统一管理所有特征把特征从“某个服务的内部实现”升级成“组织级的资产”实现特征的一次定义、多处复用。二是引入更细粒度的算力调度策略比如根据请求优先级动态分配GPU份额把缩到零的钱省得更极致。如果你也正在做类似的改造我的建议是从一条链路开始试点不要一上来就铺开全局。先选一个业务价值最明确的服务跑通实时数据管道和弹性伸缩把性能基线打出来再逐步复制到其他服务。这样每一步都有数据支撑团队信心也会稳步建立起来。我个人在实际操作中最深的一个体会是实时数据链路和弹性算力调度看上去是两个独立的技术栈但它们有一个共同点——都是在为“不可预测”做准备。流量不可预测所以要能缩能放数据延迟不可预测所以要用缓存和窗口计算把波动吸收掉。做生产系统真正有价值的不是把正常的路径做好而是把异常的路径想清楚。这也是我在这个项目里学到的最重要一课。
1. 负载上生产的两大抓手实时数据管道与弹性算力调度九月份我花了大半个月时间带着团队把两套AI负载从“能跑就行”的状态真正推到了生产级。一是在线推理链路里把实时数据管道彻底打通模型不再吃T-1的离线特征二是把推理服务的算力调度策略从固定副本改成了“按流量伸缩、空闲缩到零”。这两件事看着不相关实际上都是在解决同一个问题AI负载在生产环境里的成本与响应速度。先说结论实时数据喂模型这件事难点从来不在模型侧而在数据侧。模型推理本身几百毫秒就能完成但特征数据从业务库到模型服务之间要走的消息管道、清洗逻辑、特征拼接、缓存失效机制任何一个环节多出几秒延迟端到端延迟就压不下来。而“算力缩到零”这事难点也同样不在服务框架而在“怎么缩、缩了之后怎么拉起来、拉起来之后会不会打爆数据库”这一整套调度逻辑上。这篇文章我把自己踩过的坑、验证过的配置、以及目前线上稳定运行的那套方案完整梳理一遍。适合正在做模型服务化改造、或者被推理成本压得头疼的团队参考不管是已有一套传统架构想升级还是从零搭一套生产级推理链路都能从中找到可以直接抄作业的部分。我把整件事拆成四个部分讲实时数据链路的整体设计与组件选型、核心环节的配置细节、完整实操过程、以及我们上线后处理过的典型故障。每个部分都会附上我自己总结的经验保证你照着做不会走太多弯路。2. 实时数据管道从离线批处理到在线特征服务的改造全记录2.1 为什么一定要“实时喂”离线特征的时效性瓶颈我先算一笔账。当时线上的推荐模型用的是LightGBM特征主要分两类用户长期偏好画像一周更新一次和短期行为序列一天更新一次。在离线批量更新的架构下模型读到的用户最近一次点击行为实际上已经是几个小时甚至一天前的数据。这意味着什么用户在凌晨三点浏览了一款商品早上八点再看推荐位时模型根本不知道他昨晚看过什么推荐结果和用户当下的意图完全是错位的。延迟的代价我举一个更直观的例子。电商大促期间用户把商品加入购物车后退出两分钟后又回来了。这时候如果模型能看到“刚刚加购了A商品”这个实时特征推荐位就应该立刻展示A的配套商品、优惠券、同类替代品。但批量更新的特征服务要等到下一个调度周期才能刷新用户回来时看到还是旧推荐转化机会就这样白白溜走。实测下来把特征从T-1改成准实时后推荐位的点击率提升了大概11%这个数字背后就是时效性的价值。所以“数据要实时喂模型”本质上是把特征新鲜度从小时级压到秒级。但这句话说起来容易真正做起来牵扯到的第一个决策就是用什么方式把数据从业务系统搬到特征服务。2.2 管道选型为什么我们选了消息队列流处理而不是直连数据库刚开始我们走过弯路图省事直接让特征服务定时去业务库查增量数据。上线第一天就出问题业务库是MySQL主从架构从库本来就扛着报表查询我们每30秒轮询一次大表直接导致从库CPU飙到90%连主库都受到拖累。后来才明白生产环境的数据库不是给你模型随便轮询的特征管道必须和业务系统解耦。最终方案是用消息队列做中间层。业务系统把行为日志以事件方式异步写入Kafka流处理任务消费Kafka里的原始事件实时清洗、拼接、计算再写入特征存储供模型服务查询。这套架构的好处是业务系统只需要关心“把事件发出去”不关心下游谁在消费特征服务也不直接碰业务库数据压力被彻底隔离。选型上我们用的是Kafka Flink的组合。Kafka负责事件缓冲和解耦Flink负责窗口计算和特征聚合。可能有人会问特征聚合用Spark Streaming行不行我的答案是能跑但实时性天花板不一样。Flink是真正的流处理引擎处理延迟可以做到毫秒级窗口计算是纯内存状态Spark Streaming本质是微批次最小批次间隔也要几百毫秒到秒级而且状态管理不如Flink方便。对于特征服务这种对延迟敏感的场景Flink更合适。当然Flink也有学习成本团队如果没有流处理经验初期建议先从Kafka 轻量消费脚本开始把链路跑通后再逐步替换成Flink。我就是这么干的先把复杂问题简单化再在简单方案的基础上迭代。2.3 特征存储的读写策略Redis缓存与冷热分层数据流到了特征存储层我们又遇到一个新问题。模型服务一次推理请求需要读取几十个特征每个特征在存储里对应一条记录。如果每次推理都去查一遍数据库查询开销比模型计算本身还大端到端延迟根本压不下来。解决思路是给特征存储加上Redis缓存层而且是要区分热点特征和冷特征的分层策略。我们当时把特征分成了三层第一层是Redis热缓存存放活跃用户最近的短期行为特征这类特征访问频率最高、变动最频繁缓存过期时间设成5分钟。第二层是特征数据库存放长期偏好类特征这种特征相对稳定直接从数据库读取就行。第三层是大规模离线特征更新频率以天为单位直接从数仓同步过来数量级大但访问频率不高不需要进缓存。这里最关键的配置是Redis的过期策略和缓存击穿保护。我做了一个很细节的调整给每个特征设置了动态过期时间不是固定5分钟而是根据特征更新时间动态推算。比如某个特征刚刚更新完就意味着未来5分钟内它一定是新的直接命中缓存就行。这样能避免一个典型问题缓存刚刚过期特征存储恰好还没更新完同一时刻大量请求同时穿透到数据库把下游打挂。2.4 滑动窗口特征的计算难点与工程化处理实时特征里有一类比较特殊滑动窗口特征。比如“用户最近3分钟点击了哪些商品”“最近1小时内浏览的品类分布”。这类特征不是简单查一条记录而是要维护一个时间窗口内的行为集合窗口不停滑动特征值持续变化。我们最初的实现是用Redis的List结构存行为序列每次新事件进来就LPUSH进去然后定期清理过期元素。但流量上来后发现问题很大List越来越长清理时要从尾部遍历删除而且每次计算特征时还要把整个List读出来反序列化CPU开销和内存开销都扛不住。后来换成了Redis的ZSet用时间戳做score事件ID做member。新事件进来直接ZADD过期元素用ZREMRANGEBYSCORE一条命令清掉。计算“最近N分钟的行为”用ZRANGEBYSCORE直接取不用读全量数据。这一改单条特征计算的耗时从原来的几十毫秒降到了不到5毫秒内存占用也降了一个量级。这里有个细节值得强调窗口大小的选择不能拍脑袋要根据业务场景试出来。窗口太短特征抖动剧烈模型输出的稳定性差窗口太长特征失去实时性意义。我们在推荐场景里分别试过1分钟、3分钟、5分钟、10分钟窗口最后3分钟窗口在“实时性”和“稳定性”之间取得了最好平衡模型评估的AUC也最高。所以说工程上很多参数不是越短越好是要拿数据说话的。3. 算力缩到零Serverless推理的弹性扩缩容实践3.1 缩到零的动机推理服务闲时占用资源的账目细算说完实时数据再来说算力缩到零这件事。当时我们线上有一个面向内部运营的模型服务白天业务高峰时每秒大概要处理300个请求到了凌晨到早上六点流量几乎归零每秒不到5个请求。但原来的部署方式是固定副本数始终常驻4个推理Pod每个Pod占1张GPU卡。凌晨那六个小时这4张GPU卡就是白烧电费。我算了一笔账按当时的GPU租赁行情一张A10卡每小时成本大概在3块左右4张卡跑24小时是288块但其中6个小时的服务流量几乎为零。也就是说每天有72块钱是花在“空转”上的一个月就是两千多。这还算少的如果服务更多、业务更闲浪费比例更大。所以“算力要能缩到零”不是炫技是实实在在的成本优化。但“缩到零”也不能盲目缩。有些服务必须保持实时响应如果缩到零之后冷启动要两分钟用户点一下等两分钟那是灾难。所以我们的策略是区分场景核心在线服务设置最小副本数保证底线容量非核心的、能容忍冷启动延迟的服务才真正缩到零。3.2 弹性伸缩策略配置HPA、冷启动与突发流量之间的平衡Kubernetes原生的HPA只能看CPU、内存这类指标但推理服务的负载和CPU占用并不是线性关系。我们最终是用自定义指标做扩缩容监听每个Pod的“在途请求数”以此为信号触发伸缩。这个指标的意义在于它能直接反映服务的真实排队压力比CPU监控精准得多。配置上我给出几个关键参数的参考值。扩张阈值设在“平均每个Pod在途请求数超过5”收缩阈值设在“低于1”扩缩容冷却时间给60秒。为什么冷却时间给60秒而不是默认的5分钟因为5分钟太长流量突然起来时反应不过来容易在冷启动期内把新Pod打爆。但60秒也不能再短了否则流量小波动就会导致频繁扩缩Pod反复重建反而更浪费资源。真正的难点在缩容策略。Pod缩容下去之后K8s会先等它处理完当前请求再终止这是优雅退出机制默认的terminationGracePeriodSeconds是30秒。但如果正好有长连接请求在跑30秒不够请求就会被强制掐断。我们在配置里把这个值调到了120秒同时给服务加了一个PreStop钩子在Pod收到终止信号后先主动从负载均衡摘除自己再sleep 5秒留出时间让在途请求排空。这套组合拳下来缩容期间的错误率从0.3%降到了0.02%以下。3.3 GPU资源池化显存碎片与设备插拔的工程细节真正把算力缩到零之后又冒出一个新问题GPU显存被占着不释放。推理服务退出后显卡驱动层的显存回收有时候不是即时的下一批Pod调度上来时发现显存居然不够用。我们排查下来这涉及NVIDIA Container Toolkit的设备插拔逻辑如果上一个容器没有干净地释放CUDA上下文驱动层会有一段残留状态。这个问题的标准解法是使用GPU资源池化方案把物理GPU切成更细粒度的算力单元让多个推理任务可以共享一张卡同时做到任务结束立即回收显存。我们在生产环境用了一套相对成熟的方案按显存大小分配虚拟GPU单元一个推理任务分到几分之一张卡跑完自动归还。这里我提醒一句GPU池化不是所有场景都适用。如果模型输入张量特别大几个任务挤一张卡会导致显存溢出。我们在试点时发现轻量级BERT类模型和LightGBM模型适合池化但SD类图片生成模型、超长序列的LLM推理就不建议池化容易互相拖垮。要不要池化得先量化好单次推理的峰值显存。4. 实操过程从代码改造到生产验证的完整拆解4.1 第一阶段模型服务化与实时特征接入的代码改造整个改造我是分三个阶段推进的每个阶段都有明确的验收标准。第一阶段是代码层改造目标是让模型服务能读到实时特征。我拿当时用的验证模型举例。这是一个基于LightGBM的点击率预估服务原始版本是从离线特征表批量加载特征模型预测时用内存里的静态字典查特征。第一版改造我把特征查询从“本地静态字典”改成了“远程特征服务调用”代码看起来简单但至少动了三个关键点加上了远程调用的超时控制、加上了缓存降级逻辑、加上了特征缺失时的默认值填充。实战中这段逻辑很容易写翻车。比如远程调用超时时间设太短流量一大就频繁超时导致整批请求都走到默认特征模型预测结果全部失真。我最后的配置是连接超时200ms读取超时300ms超过就降级到本地缓存特征再不行就用默认值。宁可特征旧一点也不能让推理链路因为特征服务被拖垮。模型服务的接口改造也值得一提。我们用gRPC替代了原先的HTTP接口不是因为HTTP不行而是批量推理场景下gRPC的protobuf序列化更高效长连接也更省资源。改造后同一批请求的吞吐量提升了近40%这属于白捡的优化。手里是Python技术栈的团队我推荐用gRPC或至少用HTTP/2都能明显改善性能。4.2 第二阶段特征管道部署与生产参数校准第二阶段是把特征管道真正部署起来。我们从业务方接入了三类事件曝光事件、点击事件、加购事件。每条事件从业务系统发出到Kafka topic落盘再由Flink消费计算成特征最终写入Redis并更新特征服务整条链路的目标是端到端延迟不超过3秒。当时校准参数花了不少时间。Kafka的topic分区数我们设成了12消费者并发和分区数对应上保证消费速度能跟上生产速度。Flink的checkpoint间隔设成了10秒一次这个值不要设太频繁否则状态快照写入外部存储的开销会把吞吐拖垮。Redis那边我单独给特征服务开了AOF持久化防止进程重启后热数据丢失AOF的刷盘策略用的everysec平衡了可靠性和写入性能。管道跑起来之后我专门对比了一组数据旧链路下特征更新到模型生效的平均耗时是37分钟新链路压到了2.1秒。这个数字就是改造效果的直观体现。提醒一句各位Flink任务的并行度不要盲目设大。并行度越大占用的slot越多状态后端的内存压力也越大。我最初把并行度从2调到8结果处理延迟没有明显降低反而内存OOM了三次。因为瓶颈根本不在计算能力而在Kafka消费速度。在动手调并行度之前先看监控面板里哪个环节的堆积量最大。4.3 第三阶段服务网格化改造与算力伸缩上线第三阶段才是真正的弹性伸缩改造。我们把推理服务接入了服务网格流量入口统一走网关每个Pod的实时指标上报给K8s的metrics-server。然后配置自定义HPA规则同时把“最小副本数设成0”写进了服务配置。这里特别说一下“最小副本数设成0”的副作用。K8s默认调度器对0副本服务是不会做任何预热的流量进来的第一个请求必然经历冷启动。冷启动时长取决于模型加载方式如果你用ONNX Runtime加载模型一个LightGBM模型大概2到3秒能完成加载如果是PyTorch加载大模型那就要按秒级到分钟级估了。我们的处理是在服务启动脚本里加了一个“预加载模型”的阶段Pod一旦被拉起就先加载模型再对外宣告就绪。这样流量真正到达时模型已经热好了。整体上线后我们观察了一周的指标白天高峰期Pod数量自动从0拉到了12个吞吐量稳定维持在设计的峰值凌晨流量回落后Pod数量自动收缩到0GPU占用归零。整周算下来GPU资源成本下降了大概47%而服务的可用性依然保持在99.9%以上。5. 上线后遇到的典型故障与排障速查5.1 缓存击穿引发的特征服务雪崩上线第二天就遇到一个典型的故障某个热门特征在Redis里的缓存刚好过期而特征数据库因为Flink任务恰好延迟了一批更新导致大量请求在同一个时间窗口内穿透缓存打到了数据库上。结果数据库连接池被打满特征服务整体变慢进而拖垮了所有推理请求。排查过程是这样的先看监控面板Redis命中率从正常的95%骤降到30%数据库的慢查询数量暴涨。然后定位到具体是哪个特征出了问题最后发现是因为Flink的重启导致窗口状态丢失特征更新延迟触发了缓存击穿。修复分三步走。第一步给Redis加上了空值缓存即使数据库里查不到该特征也缓存一个空标记防止同一时刻的请求反复穿透。第二步在特征查询代码里加上了单飞的分布式锁同一特征同一时刻只有一个请求能去查数据库其他请求等待锁释放后直接读新缓存。第三步给Flink任务加了更稳的checkpoint恢复策略避免窗口状态丢失。这套组合之后类似的击穿问题再没出现过。5.2 冷启动争抢资源引发的连锁故障另一次故障出现在流量突增时。那天运营做了一场活动流量瞬间从每秒50个请求涨到400个弹性扩容策略立刻触发一次性拉起了8个Pod。但这8个Pod同时做模型加载CPU和内存瞬时飙高反而把正在处理业务请求的旧Pod挤得资源不足导致一部分请求超时。这个问题的根源是“扩容风暴”和“冷启动资源争夺”。我们的解法不复杂给扩容加上了一个速率限制HPA每轮最多新增2个Pod等它们稳定后再继续扩下一批。同时给Pod加了资源预留在调度阶段就确保每个新增Pod有足够的CPU配额做初始化不跟旧Pod抢资源。改造后流量突增场景下虽然扩容速度略慢了一点但整体稳定性明显改善没有再出现过因扩容而导致的连锁故障。5.3 常见问题速查表我把上线前后遇到过的典型问题整理成了一张速查表方便各位对号入座。| 问题现象 | 可能原因 | 排查思路 | 解决方案 | | 推理延迟偶尔飙升 | 特征查询穿透数据库 | 看Redis命中率是否骤降 | 加空值缓存、分布式锁 | | Pod反复创建销毁 | HPA阈值过于敏感 | 看扩缩容事件频率 | 调大冷却时间、加扩缩速率限制 | | 缩容后请求被掐断 | 优雅退出时间不足 | 看终止阶段的错误日志 | 调大terminationGracePeriodSeconds加PreStop钩子 | | 扩容后新Pod启动失败 | 冷启动资源不足 | 看Pod调度时的资源请求 | 设置资源预留、限制单轮扩容数量 | | 特征长期不一致 | 事件丢失或重复消费 | 对比Kafka生产和消费条数 | 开启Flink精确一次语义、幂等写入 | | GPU显存不释放 | CUDA上下文未被回收 | 看显卡显存占用率 | 使用池化方案、任务结束显式释放 | | 模型读取特征超时 | 特征服务端到端延迟超标 | 看各环节耗时分布 | 优化Redis查询、加本地缓存降级 |5.4 几个容易忽略但特别关键的小细节最后分享几个很小的细节每一个都在线上真实坑过我。第一个是Kafka消费组的提交方式。我们最初用的是自动提交结果Flink任务重启时经常出现重复消费特征被算了两遍窗口统计翻倍。改成手动提交等一批数据处理完再提交offset虽然稍微复杂一点但数据一致性有了保证。自动提交适合容忍重复的场景特征计算这种事必须精确。第二个是模型推理时特征拼接顺序要和训练时完全一致。这个坑看似低级但改特征管道后特别容易踩。我们在训练代码里是A、B、C顺序拼接推理代码不知道什么时候被人改成了C、A、B模型不报错但预测结果完全乱套。后来我在推理服务里加了一道校验用一小批已知样本比对预测输出每次发布后先跑校验再放流量。第三个是日志采样策略。推理服务在高峰期每秒几百个请求全量打日志的话日志系统先被撑爆。我们一开始没做采样结果日志服务磁盘直接写满反噬到主服务。后来改成按比例采样加错误日志全量保留既保住了排查问题的能力又控制了日志开销。6. 生产环境验证与后续可扩展的方向通过这一轮的改造我们验证了一个事实AI负载上生产模型本身的精度只是一部分真正决定能否稳定落地的是它周围的数据管道和资源调度体系。这套体系跑稳之后后续还可以往两个方向继续扩展。一是用特征平台统一管理所有特征把特征从“某个服务的内部实现”升级成“组织级的资产”实现特征的一次定义、多处复用。二是引入更细粒度的算力调度策略比如根据请求优先级动态分配GPU份额把缩到零的钱省得更极致。如果你也正在做类似的改造我的建议是从一条链路开始试点不要一上来就铺开全局。先选一个业务价值最明确的服务跑通实时数据管道和弹性伸缩把性能基线打出来再逐步复制到其他服务。这样每一步都有数据支撑团队信心也会稳步建立起来。我个人在实际操作中最深的一个体会是实时数据链路和弹性算力调度看上去是两个独立的技术栈但它们有一个共同点——都是在为“不可预测”做准备。流量不可预测所以要能缩能放数据延迟不可预测所以要用缓存和窗口计算把波动吸收掉。做生产系统真正有价值的不是把正常的路径做好而是把异常的路径想清楚。这也是我在这个项目里学到的最重要一课。
