九月份我陪着一个业务团队把一套推荐模型从离线实验环境真正挪到了生产环境。原以为最大的坎是模型精度结果真正让人头疼的是两件听起来特别基础、做起来特别容易翻车的事数据能不能实时地喂给模型算力能不能在没有人调用的时候缩到零。这两个词放在一起其实就是“AI负载往生产里推了一把”的真实含义——实时数据让模型有了“活”的输入弹性算力让模型不再需要一台24小时空转的服务器来供养。如果你也在做模型上线、在线推理、特征管道或者AI成本治理这篇内容应该能帮上忙。我会把九月这两件事背后的技术逻辑、具体落地方案、常见坑和排查方法完整拆一遍所有配置和步骤都是基于生产实践整理的可以直接当参考。1. 九月的两件事为什么实时数据和弹性算力被同时推到台前1.1 模型从实验到生产缺的不是精度而是“流通性”很多团队在模型迭代上都有一个惯性把模型训好、指标刷高就觉得可以上线了。但真正把模型部署到生产环境后往往发现线上表现和离线评估差一大截。这不是模型本身的问题而是数据的“流通性”出了问题。离线训练时模型吃的是整理好的批量特征比如昨天的用户点击、前天的商品曝光。但生产环境里的数据是流式的、实时的用户上一秒的行为会直接影响下一秒的推荐结果。如果数据管道仍然是按天或按小时批量同步那么模型看到的基本是“过期”的用户状态。九月份我们调整了数据链路把特征从T1改成了秒级实时同一个模型的线上AUC直接提升了3个百分点代价是数据管道复杂度翻了一倍。这里想强调一点实时数据的价值不在于“快”而在于让模型能感知当前时刻的业务状态。比如做风控一个账户在10分钟内发生异常高频交易模型必须在几十毫秒内收到这个特征。用批量管道根本做不到只能靠流式处理。1.2 算力缩到零背后是AI成本模型的改变“算力要能缩到零”这句话很多人第一反应是省钱其实没那么简单。它背后是一个成本模型的转变从“包年包月买机器”变成“按实际消耗付费”。传统做法是给模型服务常驻一台GPU或者几台CPU不管有没有流量都在烧钱。一个中等规模的推荐服务光预留实例的闲置成本可能占整个AI预算的三成以上。尤其是一些内部工具类模型比如文档摘要、代码辅助、报表解读白天有人用晚上几乎没人用24小时常驻完全是浪费。Scale-to-Zero的原理是当服务在一段时间内没有请求时自动把实例缩到0来请求时再迅速拉起实例。这样不算复杂但真正落地有很多细节后面展开讲。九月我们把一个内部问答模型的推理服务改造成弹性伸缩后月度成本下降了约60%且没有明显影响用户体验。1.3 这两件事如何相互成就实时数据和弹性算力不是两个独立的方向它们在生产环境里是互相咬合的。实时数据管道意味着模型对“当下”敏感所以请求往往集中在业务高峰时段比如早晚流量高峰、大促秒杀。如果算力不能跟着流量自动伸缩要么高峰时扛不住要么低谷时空转。反过来如果算力能缩到零那么你就有底气把更多低频业务接进来哪怕一天只有几百次调用也敢上线一个实时模型。这两个能力合在一起才让AI负载第一次做到了“像普通Web服务一样”按需供给。2. 实时数据喂模型数据管道的设计与落地2.1 核心技术点拆解流式采集、特征计算、特征存储要做一个实时特征链路通常有四个核心环节数据采集、流式计算、特征存储、特征服务。数据采集是第一步。业务数据库里的变更、日志系统里的行为事件都要以毫秒级延迟进入消息队列。常用工具是Debezium这类CDCChange Data Capture工具它可以把数据库的insert/update/delete操作转成事件流也可以直接用埋点SDK把前端行为事件发到Kafka。这里的关键是事件格式要统一最好都用JSON或Avro并带上事件时间和业务主键。流式计算是第二步。拿到原始事件流后需要做窗口聚合、滑动统计、行为序列拼接。以用户最近10分钟点击次数为例用Flink或者Spark Structured Streaming做滚动窗口窗口大小设10分钟滑动步长可以设30秒这样特征延迟控制在30秒以内。要注意状态清理否则会让状态后端无限膨胀。特征存储是第三步。计算好的特征要写入一个低延迟的在线存储常见的有Redis、HBase或者专门的Feature Store特征平台。推荐用Redis Cluster因为特征读取是点查为主Redis的吞吐和延迟都比较稳。特征需要设置TTL比如用户实时行为特征保留1小时超过就自动过期避免脏数据堆积。特征服务是第四步。推理服务启动时先调用特征服务批量拉取当前请求所需的特征再拼上请求自带的上下文特征组装成模型输入。这里最容易被忽略的是特征版本管理。模型训练时用的特征版本和生产线上特征版本不一致是导致线上线下指标不一致的最大元凶。2.2 训练-推理同源离线在线一致性的三种做法实时特征落地后最大的技术债就是“离线在线不一致”。训练时用的还是T1批量的静态特征线上推理时却是实时特征模型自然会对不齐。业内比较成熟的思路有三种。第一种是最小改动方案离线特征也按实时链路的逻辑重放一遍比如把过去30天的原始事件流存下来用同一套流式计算逻辑重新生成离线特征。这样离线训练数据和在线推理数据就同源了缺点是存储和计算成本高。第二种是时间旅行方案Feature Store里保存特征的历史版本训练时指定读取某个时间点的特征快照。这样不用重放事件流但要求特征存储支持时间维度查询实现复杂度更高。第三种是混合方案核心特征如用户实时兴趣、频次走实时链路非核心特征如用户画像、商品静态属性仍然走离线批量。两套特征在Feature Store里统一注册、统一版本管理线上推理时一起拼接。九月份我们实际采用的是这种方案成本可控一致性也基本满足。无论选哪种都要记住一个原则特征的定义、加工逻辑、版本号必须由同一个平台管理不要训练一套代码、推理一套代码。2.3 一个推荐场景的实时链路实例以商品推荐为例实时链路可以这样搭。用户点击商品的事件通过前端SDK上报到KafkaTopic命名为user_behavior。Flink作业消费这个Topic按用户ID分组计算最近5分钟点击次数、最近10分钟点击品类分布、最近3次浏览的商品ID序列。计算结果写入RedisKey设计为user:{userId}:realtime_featureValue是一个JSON或Protobuf序列化的特征结构TTL设为30分钟。推理服务收到推荐请求后先从Redis批量读取当前用户的实时特征再从离线特征服务读取用户画像和商品静态特征拼接后输入模型。这套链路我们用了大约两周时间搭完整体延迟在20毫秒以内不含模型推理。需要注意的点是Kafka的分区数要结合Flink并行度设置一般分区数等于并行度乘以1.5到2Redis连接池要设置合理的最大连接数和超时时间避免流量突增时连接打满。2.4 实操配置示例与参数说明这里给一个Flink SQL的简化示例用于计算用户最近10分钟点击次数CREATE TABLE user_behavior ( user_id STRING, item_id STRING, behavior STRING, event_time TIMESTAMP(3), WATERMARK FOR event_time AS event_time - INTERVAL 10 SECOND ) WITH ( connector kafka, topic user_behavior, properties.bootstrap.servers kafka-1:9092,kafka-2:9092, format json, scan.startup.mode latest-offset ); CREATE TABLE user_click_cnt ( user_id STRING, click_cnt BIGINT, window_end TIMESTAMP(3), PRIMARY KEY (user_id) NOT ENFORCED ) WITH ( connector upsert-kafka, topic user_realtime_feature, properties.bootstrap.servers kafka-1:9092,kafka-2:9092, format json ); INSERT INTO user_click_cnt SELECT user_id, COUNT(*) AS click_cnt, HOP_END(event_time, INTERVAL 30 SECOND, INTERVAL 10 MINUTE) AS window_end FROM user_behavior WHERE behavior click GROUP BY user_id, HOP(event_time, INTERVAL 30 SECOND, INTERVAL 10 MINUTE);这里HOP是滑动窗口步长30秒长度10分钟。WATERMARK设了10秒表示允许事件乱序10秒。这个配置比较适合秒级特征需求如果业务对实时性要求不高可以把步长放宽到1分钟减少计算压力。3. 算力缩到零推理服务的弹性伸缩实践3.1 为什么常驻模型服务是浪费先算一笔账。一个内部工具类的NLP模型服务用2个4核8G的Pod常驻一天24小时运行假设每天真实处理请求的时间只有4小时那么剩下20小时基本都是空转。按云主机价格估算2个Pod的月成本大概在2000元上下实际利用率只有16%左右浪费接近1700元。这只是单个服务。如果一个公司有二三十个这类AI服务一年的闲置成本就是几十万元级别。缩到零之后这些服务在无请求时段不占用任何Pod资源成本直接归零。只有请求到来时才临时调度Pod按秒计费或者按调用量计费。但要注意不同负载的“缩零收益”不一样。高并发的核心推荐服务不能轻易缩到零因为冷启动可能造成几十秒的延迟对线上体验影响太大。适合缩零的主要是低频、延迟不敏感、内部工具类模型。3.2 Scale-to-Zero的关键冷启动与请求平滑开启自动缩容后最先遇到的问题就是冷启动。模型服务的冷启动包含几个阶段Pod调度、容器镜像拉取、模型文件加载、进程初始化。其中模型文件加载最耗时一个几百MB的BERT模型从本地磁盘加载需要数秒如果是首次从远端拉取可能要十几秒甚至更久。为了缓解冷启动有三类做法。一是镜像预热在集群节点上提前缓存模型镜像用DaemonSet或者镜像预热工具让模型文件在各节点本地落盘这样Pod启动时不用再拉取大文件。二是实例保底不把副本数缩到严格的0而是保留一个极小的占位实例或者“热实例池”比如常驻1个副本其余副本按需扩展。这不算严格意义上的缩零但成本已经大幅下降。三是延迟容忍如果调用方可以接受1-2秒的启动延迟直接把副本缩到0靠请求触发扩容依靠Kubernetes的HPA或Knative的scale-to-zero机制。实际生产里我们通常给服务设置两个阈值缩容阈值和扩容阈值。比如连续3分钟没有请求缩容到0QPS超过5时扩容到2个实例。这样既保证体验又能控制成本。3.3 基于K8s的弹性部署方案目前比较成熟的方案是Kubernetes Knative Serving或者直接用KServe来接模型推理。Knative的好处是原生支持scale-to-zero并且可以在容器层面做并发数控制、请求缓冲。下面是一个简化版的Knative Service配置只保留核心参数apiVersion: serving.knative.dev/v1 kind: Service metadata: name: rcmd-model namespace: ai-prod spec: template: metadata: annotations: autoscaling.knative.dev/target: 10 autoscaling.knative.dev/minScale: 0 autoscaling.knative.dev/maxScale: 10 autoscaling.knative.dev/window: 60s spec: containerConcurrency: 5 containers: - image: registry.example.com/rcmd-model:v3 env: - name: MODEL_PATH value: /models/rcmd_v3 - name: FEATURE_STORE_ADDR value: redis-cluster:6379 resources: requests: cpu: 1 memory: 2Gi limits: cpu: 2 memory: 4Gi几个关键参数说明一下。minScale: 0表示允许缩到零window: 60s表示伸缩评估窗口是60秒containerConcurrency: 5表示单个Pod最多同时处理5个请求防止实例被突发流量打爆。如果用的不是Knative也可以用KEDAKubernetes Event-Driven Autoscaling它可以基于Kafka积压消息数、Prometheus指标等触发伸缩比较灵活。3.4 CPU与GPU场景的差异前面讲的主要是CPU推理服务。如果是GPU模型推理缩到零面临的问题更多。GPU不能像CPU那样简单地共享和抢占缩到零后重新拉起时需要重新申请显存、加载模型冷启动时间更长。目前常见做法有三种。一是GPU时间切片让多个模型Pod共享一块GPU但这对显存隔离要求较高容易出现显存溢出。二是GPU实例池按需扩容集群中保留少量“热GPU节点”作为缓冲其余GPU节点在空闲时释放。三是把推理转为CPU优化比如模型量化、蒸馏、TensorRT加速后跑在CPU上不一定非要GPU。很多时候业务场景对延迟要求没那么苛刻用优化后的CPU推理性价比反而更高。九月份我们把一个排序模型的TensorRT引擎版跑在CPU上P95延迟在80毫秒以内与GPU版本差距不大但成本下降了七成而且还不用担心GPU冷启动问题。如果你的场景允许200毫秒以内的延迟强烈建议评估一下CPU推理方案。4. 实操过程端到端把模型负载推进生产4.1 场景与目标定义为了让上面的内容更容易落地我用一个完整案例串一遍。背景某内容社区要给“编辑精选”板块做实时排序模型输入包括用户实时点击偏好、文章实时热度、作者特征。业务目标有两个一是用户打开页面时推荐结果要能反映最近5分钟的行为变化二是该服务使用频率集中在白天工作时段夜间流量接近为零要求夜间不能空耗算力。4.2 链路搭建的五步流程第一步梳理特征清单。把模型需要的特征分成三类实时行为特征用户最近5分钟点击、最近10分钟浏览序列、离线画像特征用户年龄段、兴趣标签、静态内容特征文章分类、字数、作者等级。所有特征在特征平台里统一注册带版本号。第二步搭建实时数据管道。行为事件通过埋点上报到KafkaFlink作业消费并计算窗口特征写入Redis。离线特征继续沿用原有批量管道每天全量刷新到在线存储。第三步改造推理服务。模型服务在收到请求后先从Redis取实时特征再从特征平台取离线特征拼装成模型输入调用模型进行推理。这一阶段重点做超时控制和降级策略Redis查询设置50毫秒超时超时则降级用纯离线特征避免实时特征故障拖垮整个推荐接口。第四步接入弹性伸缩。推理服务部署到Knative最小副本0最大副本10并发数5。夜间无流量时自动缩到零白天流量高峰自动扩到5-8个实例。第五步建立监控与告警。监控三个核心指标特征管道延迟事件产生到特征可用的时间、推理P95延迟、服务的扩容/缩容事件。特征管道延迟超过60秒就告警说明Flink作业可能积压。4.3 上线后的效果与成本对比上线一周后的数据如下指标改造前改造后特征更新延迟T1小时30秒左右线上推荐AUC0.620.65推理P95延迟45ms58ms日均Pod运行时长24小时x4实例约8小时x5实例月度推理成本约8000元约2500元这里强调一下实时特征带来的AUC提升并不能完全归功于管道改造因为同期模型也做了迭代但延迟和成本的变化是确定的。推理P95有小幅上升主要是冷启动和实时特征查询带来的额外开销在可接受范围内。4.4 上线过程中踩到的三个坑第一个坑是Flink状态后端无限增长。因为按用户维度做了10分钟窗口聚合状态数据量很大一开始没设TTL跑了两天状态就超过20GB作业频繁反压。后来给状态配置了TTL只保留90秒内的数据状态降到了2GB。第二个坑是Redis热Key。某个头部作者的文章爆火后大量请求同时读取该文章的热度特征单个Redis Key的QPS飙到几千导致该Key所在分片的CPU被打满。解决方法是把热度特征做了本地缓存缓存时间5秒既保证新鲜度又分散读压力。第三个坑是缩容策略太激进。刚开始把缩容窗口设成30秒结果夜间稍微有一点监控探活请求服务就反复扩缩容一分钟内连续拉起三次Pod。后来把缩容窗口调整到5分钟并配置了最小请求缓冲扩缩容次数明显下降。5. 常见问题与排查实录5.1 实时数据延迟导致预测失真现象模型的线上表现忽好忽坏部分用户推荐结果明显不符合当前场景。排查步骤先看特征管道延迟监控。我们遇到过Kafka消费者组rebalance导致消费暂停的情况表现为某几个用户ID的特征一直停留在几分钟前。另一个常见原因是Flink作业反压状态后端或Sink写入变慢导致窗口计算延迟。解决建议把特征管道的每个环节都加埋点记录“事件产生时间”和“特征写入时间”。只要这两个时间差超过阈值就知道延迟出在哪一段。Kafka消费者组要设置合理的max.poll.interval.ms避免处理耗时太长导致rebalanceFlink的Sink建议开启批量写入并设置背压自动调节。5.2 冷启动导致请求超时现象开启缩零后服务在闲置一段时间后首次请求总是超时调用方重试后又恢复正常。根因冷启动过程中Pod调度、模型加载、进程初始化加在一起可能耗时数秒超过调用方的超时阈值通常是1秒。解决建议如果业务不能接受冷启动延迟就不要追求严格缩零改成“缩到1”保留一个最小副本。如果想继续缩零可以让入口网关对冷启动请求做额外容忍或者使用Knative的scale-to-zero配合快速镜像预热。我个人的经验是内部工具类模型可以接受2秒内冷启动核心业务模型至少保留一个热副本。5.3 特征不一致导致离线在线差异大现象模型离线AUC 0.7线上只有0.6且线上点击率低于预期。排查思路先对比线上请求日志里实际输入的特征和离线训练样本里的特征分布。我们曾发现离线训练时用户实时特征是用事件发生时刻往前推10分钟计算的而线上推理时用的是“请求时刻往前推10分钟”两者在行为密集场景下会有明显偏差。原因在于离线特征生成时采用了回填逻辑而线上没有严格按照同一逻辑重放。解决建议要么统一时间口径要么在离线回填时显式记录特征计算时间戳。最稳妥的做法是让离线特征生成和线上推理共用同一套特征计算代码不要各自实现。5.4 弹性伸缩抖动与扩容滞后现象流量突增时服务扩容速度跟不上导致部分请求被拒绝。原因Kubernetes的扩容依赖Metrics Server的指标采集默认采集周期是15秒加上Pod启动时间整体可能需要1-2分钟才能完成扩容。解决建议对流量波动大的服务可以设置一个“最低兜底实例数”比如2个不要追求缩零同时把指标采集周期调短到5秒左右。也可以配置基于Kafka积压消息量的KEDA触发器请求还没到Pod之前就提前扩容。5.5 避坑清单汇总实时特征必须有降级方案Redis或Kafka挂了不能拖垮主链路。窗口聚合状态一定要设置TTL否则状态存储会被拖垮。缩容窗口不要太短否则会出现扩缩容震荡。模型文件要提前预热到节点本地否则冷启动时间不可控。离线训练和在线推理的特征逻辑必须统一最好共用代码或者平台。线上特征取值要记录日志否则排查线上线下不一致时无据可查。6. 九月之后还可以往哪个方向走如果你已经完成了实时特征管道和弹性伸缩改造下一阶段可以考虑三件事。第一把实时特征的能力从“单一模型”扩展到“特征平台”。当多个模型都开始使用实时特征时统一平台能避免重复开发和口径混乱。第二把算力弹性策略从“按QPS伸缩”升级为“按业务价值伸缩”。比如大促期间提前预热实例非核心场景允许更长冷启动时间让算力真正跟着业务策略走。第三沉淀一套AI服务生产化配置模板。包括标准化部署清单、监控面板、成本报表让新模型上线时不用再重新踩一遍这些坑。我个人九月份最大的体会是实时数据和弹性算力都不是新技术但它们组合在一起确实把很多AI服务从“能跑起来”推向了“能省着跑、放心跑”。如果你的团队也正在做模型生产化建议先从这两个最基础又最容易被低估的环节入手改完一版再看线上运营数据你会明显感觉到差异。
九月份我陪着一个业务团队把一套推荐模型从离线实验环境真正挪到了生产环境。原以为最大的坎是模型精度结果真正让人头疼的是两件听起来特别基础、做起来特别容易翻车的事数据能不能实时地喂给模型算力能不能在没有人调用的时候缩到零。这两个词放在一起其实就是“AI负载往生产里推了一把”的真实含义——实时数据让模型有了“活”的输入弹性算力让模型不再需要一台24小时空转的服务器来供养。如果你也在做模型上线、在线推理、特征管道或者AI成本治理这篇内容应该能帮上忙。我会把九月这两件事背后的技术逻辑、具体落地方案、常见坑和排查方法完整拆一遍所有配置和步骤都是基于生产实践整理的可以直接当参考。1. 九月的两件事为什么实时数据和弹性算力被同时推到台前1.1 模型从实验到生产缺的不是精度而是“流通性”很多团队在模型迭代上都有一个惯性把模型训好、指标刷高就觉得可以上线了。但真正把模型部署到生产环境后往往发现线上表现和离线评估差一大截。这不是模型本身的问题而是数据的“流通性”出了问题。离线训练时模型吃的是整理好的批量特征比如昨天的用户点击、前天的商品曝光。但生产环境里的数据是流式的、实时的用户上一秒的行为会直接影响下一秒的推荐结果。如果数据管道仍然是按天或按小时批量同步那么模型看到的基本是“过期”的用户状态。九月份我们调整了数据链路把特征从T1改成了秒级实时同一个模型的线上AUC直接提升了3个百分点代价是数据管道复杂度翻了一倍。这里想强调一点实时数据的价值不在于“快”而在于让模型能感知当前时刻的业务状态。比如做风控一个账户在10分钟内发生异常高频交易模型必须在几十毫秒内收到这个特征。用批量管道根本做不到只能靠流式处理。1.2 算力缩到零背后是AI成本模型的改变“算力要能缩到零”这句话很多人第一反应是省钱其实没那么简单。它背后是一个成本模型的转变从“包年包月买机器”变成“按实际消耗付费”。传统做法是给模型服务常驻一台GPU或者几台CPU不管有没有流量都在烧钱。一个中等规模的推荐服务光预留实例的闲置成本可能占整个AI预算的三成以上。尤其是一些内部工具类模型比如文档摘要、代码辅助、报表解读白天有人用晚上几乎没人用24小时常驻完全是浪费。Scale-to-Zero的原理是当服务在一段时间内没有请求时自动把实例缩到0来请求时再迅速拉起实例。这样不算复杂但真正落地有很多细节后面展开讲。九月我们把一个内部问答模型的推理服务改造成弹性伸缩后月度成本下降了约60%且没有明显影响用户体验。1.3 这两件事如何相互成就实时数据和弹性算力不是两个独立的方向它们在生产环境里是互相咬合的。实时数据管道意味着模型对“当下”敏感所以请求往往集中在业务高峰时段比如早晚流量高峰、大促秒杀。如果算力不能跟着流量自动伸缩要么高峰时扛不住要么低谷时空转。反过来如果算力能缩到零那么你就有底气把更多低频业务接进来哪怕一天只有几百次调用也敢上线一个实时模型。这两个能力合在一起才让AI负载第一次做到了“像普通Web服务一样”按需供给。2. 实时数据喂模型数据管道的设计与落地2.1 核心技术点拆解流式采集、特征计算、特征存储要做一个实时特征链路通常有四个核心环节数据采集、流式计算、特征存储、特征服务。数据采集是第一步。业务数据库里的变更、日志系统里的行为事件都要以毫秒级延迟进入消息队列。常用工具是Debezium这类CDCChange Data Capture工具它可以把数据库的insert/update/delete操作转成事件流也可以直接用埋点SDK把前端行为事件发到Kafka。这里的关键是事件格式要统一最好都用JSON或Avro并带上事件时间和业务主键。流式计算是第二步。拿到原始事件流后需要做窗口聚合、滑动统计、行为序列拼接。以用户最近10分钟点击次数为例用Flink或者Spark Structured Streaming做滚动窗口窗口大小设10分钟滑动步长可以设30秒这样特征延迟控制在30秒以内。要注意状态清理否则会让状态后端无限膨胀。特征存储是第三步。计算好的特征要写入一个低延迟的在线存储常见的有Redis、HBase或者专门的Feature Store特征平台。推荐用Redis Cluster因为特征读取是点查为主Redis的吞吐和延迟都比较稳。特征需要设置TTL比如用户实时行为特征保留1小时超过就自动过期避免脏数据堆积。特征服务是第四步。推理服务启动时先调用特征服务批量拉取当前请求所需的特征再拼上请求自带的上下文特征组装成模型输入。这里最容易被忽略的是特征版本管理。模型训练时用的特征版本和生产线上特征版本不一致是导致线上线下指标不一致的最大元凶。2.2 训练-推理同源离线在线一致性的三种做法实时特征落地后最大的技术债就是“离线在线不一致”。训练时用的还是T1批量的静态特征线上推理时却是实时特征模型自然会对不齐。业内比较成熟的思路有三种。第一种是最小改动方案离线特征也按实时链路的逻辑重放一遍比如把过去30天的原始事件流存下来用同一套流式计算逻辑重新生成离线特征。这样离线训练数据和在线推理数据就同源了缺点是存储和计算成本高。第二种是时间旅行方案Feature Store里保存特征的历史版本训练时指定读取某个时间点的特征快照。这样不用重放事件流但要求特征存储支持时间维度查询实现复杂度更高。第三种是混合方案核心特征如用户实时兴趣、频次走实时链路非核心特征如用户画像、商品静态属性仍然走离线批量。两套特征在Feature Store里统一注册、统一版本管理线上推理时一起拼接。九月份我们实际采用的是这种方案成本可控一致性也基本满足。无论选哪种都要记住一个原则特征的定义、加工逻辑、版本号必须由同一个平台管理不要训练一套代码、推理一套代码。2.3 一个推荐场景的实时链路实例以商品推荐为例实时链路可以这样搭。用户点击商品的事件通过前端SDK上报到KafkaTopic命名为user_behavior。Flink作业消费这个Topic按用户ID分组计算最近5分钟点击次数、最近10分钟点击品类分布、最近3次浏览的商品ID序列。计算结果写入RedisKey设计为user:{userId}:realtime_featureValue是一个JSON或Protobuf序列化的特征结构TTL设为30分钟。推理服务收到推荐请求后先从Redis批量读取当前用户的实时特征再从离线特征服务读取用户画像和商品静态特征拼接后输入模型。这套链路我们用了大约两周时间搭完整体延迟在20毫秒以内不含模型推理。需要注意的点是Kafka的分区数要结合Flink并行度设置一般分区数等于并行度乘以1.5到2Redis连接池要设置合理的最大连接数和超时时间避免流量突增时连接打满。2.4 实操配置示例与参数说明这里给一个Flink SQL的简化示例用于计算用户最近10分钟点击次数CREATE TABLE user_behavior ( user_id STRING, item_id STRING, behavior STRING, event_time TIMESTAMP(3), WATERMARK FOR event_time AS event_time - INTERVAL 10 SECOND ) WITH ( connector kafka, topic user_behavior, properties.bootstrap.servers kafka-1:9092,kafka-2:9092, format json, scan.startup.mode latest-offset ); CREATE TABLE user_click_cnt ( user_id STRING, click_cnt BIGINT, window_end TIMESTAMP(3), PRIMARY KEY (user_id) NOT ENFORCED ) WITH ( connector upsert-kafka, topic user_realtime_feature, properties.bootstrap.servers kafka-1:9092,kafka-2:9092, format json ); INSERT INTO user_click_cnt SELECT user_id, COUNT(*) AS click_cnt, HOP_END(event_time, INTERVAL 30 SECOND, INTERVAL 10 MINUTE) AS window_end FROM user_behavior WHERE behavior click GROUP BY user_id, HOP(event_time, INTERVAL 30 SECOND, INTERVAL 10 MINUTE);这里HOP是滑动窗口步长30秒长度10分钟。WATERMARK设了10秒表示允许事件乱序10秒。这个配置比较适合秒级特征需求如果业务对实时性要求不高可以把步长放宽到1分钟减少计算压力。3. 算力缩到零推理服务的弹性伸缩实践3.1 为什么常驻模型服务是浪费先算一笔账。一个内部工具类的NLP模型服务用2个4核8G的Pod常驻一天24小时运行假设每天真实处理请求的时间只有4小时那么剩下20小时基本都是空转。按云主机价格估算2个Pod的月成本大概在2000元上下实际利用率只有16%左右浪费接近1700元。这只是单个服务。如果一个公司有二三十个这类AI服务一年的闲置成本就是几十万元级别。缩到零之后这些服务在无请求时段不占用任何Pod资源成本直接归零。只有请求到来时才临时调度Pod按秒计费或者按调用量计费。但要注意不同负载的“缩零收益”不一样。高并发的核心推荐服务不能轻易缩到零因为冷启动可能造成几十秒的延迟对线上体验影响太大。适合缩零的主要是低频、延迟不敏感、内部工具类模型。3.2 Scale-to-Zero的关键冷启动与请求平滑开启自动缩容后最先遇到的问题就是冷启动。模型服务的冷启动包含几个阶段Pod调度、容器镜像拉取、模型文件加载、进程初始化。其中模型文件加载最耗时一个几百MB的BERT模型从本地磁盘加载需要数秒如果是首次从远端拉取可能要十几秒甚至更久。为了缓解冷启动有三类做法。一是镜像预热在集群节点上提前缓存模型镜像用DaemonSet或者镜像预热工具让模型文件在各节点本地落盘这样Pod启动时不用再拉取大文件。二是实例保底不把副本数缩到严格的0而是保留一个极小的占位实例或者“热实例池”比如常驻1个副本其余副本按需扩展。这不算严格意义上的缩零但成本已经大幅下降。三是延迟容忍如果调用方可以接受1-2秒的启动延迟直接把副本缩到0靠请求触发扩容依靠Kubernetes的HPA或Knative的scale-to-zero机制。实际生产里我们通常给服务设置两个阈值缩容阈值和扩容阈值。比如连续3分钟没有请求缩容到0QPS超过5时扩容到2个实例。这样既保证体验又能控制成本。3.3 基于K8s的弹性部署方案目前比较成熟的方案是Kubernetes Knative Serving或者直接用KServe来接模型推理。Knative的好处是原生支持scale-to-zero并且可以在容器层面做并发数控制、请求缓冲。下面是一个简化版的Knative Service配置只保留核心参数apiVersion: serving.knative.dev/v1 kind: Service metadata: name: rcmd-model namespace: ai-prod spec: template: metadata: annotations: autoscaling.knative.dev/target: 10 autoscaling.knative.dev/minScale: 0 autoscaling.knative.dev/maxScale: 10 autoscaling.knative.dev/window: 60s spec: containerConcurrency: 5 containers: - image: registry.example.com/rcmd-model:v3 env: - name: MODEL_PATH value: /models/rcmd_v3 - name: FEATURE_STORE_ADDR value: redis-cluster:6379 resources: requests: cpu: 1 memory: 2Gi limits: cpu: 2 memory: 4Gi几个关键参数说明一下。minScale: 0表示允许缩到零window: 60s表示伸缩评估窗口是60秒containerConcurrency: 5表示单个Pod最多同时处理5个请求防止实例被突发流量打爆。如果用的不是Knative也可以用KEDAKubernetes Event-Driven Autoscaling它可以基于Kafka积压消息数、Prometheus指标等触发伸缩比较灵活。3.4 CPU与GPU场景的差异前面讲的主要是CPU推理服务。如果是GPU模型推理缩到零面临的问题更多。GPU不能像CPU那样简单地共享和抢占缩到零后重新拉起时需要重新申请显存、加载模型冷启动时间更长。目前常见做法有三种。一是GPU时间切片让多个模型Pod共享一块GPU但这对显存隔离要求较高容易出现显存溢出。二是GPU实例池按需扩容集群中保留少量“热GPU节点”作为缓冲其余GPU节点在空闲时释放。三是把推理转为CPU优化比如模型量化、蒸馏、TensorRT加速后跑在CPU上不一定非要GPU。很多时候业务场景对延迟要求没那么苛刻用优化后的CPU推理性价比反而更高。九月份我们把一个排序模型的TensorRT引擎版跑在CPU上P95延迟在80毫秒以内与GPU版本差距不大但成本下降了七成而且还不用担心GPU冷启动问题。如果你的场景允许200毫秒以内的延迟强烈建议评估一下CPU推理方案。4. 实操过程端到端把模型负载推进生产4.1 场景与目标定义为了让上面的内容更容易落地我用一个完整案例串一遍。背景某内容社区要给“编辑精选”板块做实时排序模型输入包括用户实时点击偏好、文章实时热度、作者特征。业务目标有两个一是用户打开页面时推荐结果要能反映最近5分钟的行为变化二是该服务使用频率集中在白天工作时段夜间流量接近为零要求夜间不能空耗算力。4.2 链路搭建的五步流程第一步梳理特征清单。把模型需要的特征分成三类实时行为特征用户最近5分钟点击、最近10分钟浏览序列、离线画像特征用户年龄段、兴趣标签、静态内容特征文章分类、字数、作者等级。所有特征在特征平台里统一注册带版本号。第二步搭建实时数据管道。行为事件通过埋点上报到KafkaFlink作业消费并计算窗口特征写入Redis。离线特征继续沿用原有批量管道每天全量刷新到在线存储。第三步改造推理服务。模型服务在收到请求后先从Redis取实时特征再从特征平台取离线特征拼装成模型输入调用模型进行推理。这一阶段重点做超时控制和降级策略Redis查询设置50毫秒超时超时则降级用纯离线特征避免实时特征故障拖垮整个推荐接口。第四步接入弹性伸缩。推理服务部署到Knative最小副本0最大副本10并发数5。夜间无流量时自动缩到零白天流量高峰自动扩到5-8个实例。第五步建立监控与告警。监控三个核心指标特征管道延迟事件产生到特征可用的时间、推理P95延迟、服务的扩容/缩容事件。特征管道延迟超过60秒就告警说明Flink作业可能积压。4.3 上线后的效果与成本对比上线一周后的数据如下指标改造前改造后特征更新延迟T1小时30秒左右线上推荐AUC0.620.65推理P95延迟45ms58ms日均Pod运行时长24小时x4实例约8小时x5实例月度推理成本约8000元约2500元这里强调一下实时特征带来的AUC提升并不能完全归功于管道改造因为同期模型也做了迭代但延迟和成本的变化是确定的。推理P95有小幅上升主要是冷启动和实时特征查询带来的额外开销在可接受范围内。4.4 上线过程中踩到的三个坑第一个坑是Flink状态后端无限增长。因为按用户维度做了10分钟窗口聚合状态数据量很大一开始没设TTL跑了两天状态就超过20GB作业频繁反压。后来给状态配置了TTL只保留90秒内的数据状态降到了2GB。第二个坑是Redis热Key。某个头部作者的文章爆火后大量请求同时读取该文章的热度特征单个Redis Key的QPS飙到几千导致该Key所在分片的CPU被打满。解决方法是把热度特征做了本地缓存缓存时间5秒既保证新鲜度又分散读压力。第三个坑是缩容策略太激进。刚开始把缩容窗口设成30秒结果夜间稍微有一点监控探活请求服务就反复扩缩容一分钟内连续拉起三次Pod。后来把缩容窗口调整到5分钟并配置了最小请求缓冲扩缩容次数明显下降。5. 常见问题与排查实录5.1 实时数据延迟导致预测失真现象模型的线上表现忽好忽坏部分用户推荐结果明显不符合当前场景。排查步骤先看特征管道延迟监控。我们遇到过Kafka消费者组rebalance导致消费暂停的情况表现为某几个用户ID的特征一直停留在几分钟前。另一个常见原因是Flink作业反压状态后端或Sink写入变慢导致窗口计算延迟。解决建议把特征管道的每个环节都加埋点记录“事件产生时间”和“特征写入时间”。只要这两个时间差超过阈值就知道延迟出在哪一段。Kafka消费者组要设置合理的max.poll.interval.ms避免处理耗时太长导致rebalanceFlink的Sink建议开启批量写入并设置背压自动调节。5.2 冷启动导致请求超时现象开启缩零后服务在闲置一段时间后首次请求总是超时调用方重试后又恢复正常。根因冷启动过程中Pod调度、模型加载、进程初始化加在一起可能耗时数秒超过调用方的超时阈值通常是1秒。解决建议如果业务不能接受冷启动延迟就不要追求严格缩零改成“缩到1”保留一个最小副本。如果想继续缩零可以让入口网关对冷启动请求做额外容忍或者使用Knative的scale-to-zero配合快速镜像预热。我个人的经验是内部工具类模型可以接受2秒内冷启动核心业务模型至少保留一个热副本。5.3 特征不一致导致离线在线差异大现象模型离线AUC 0.7线上只有0.6且线上点击率低于预期。排查思路先对比线上请求日志里实际输入的特征和离线训练样本里的特征分布。我们曾发现离线训练时用户实时特征是用事件发生时刻往前推10分钟计算的而线上推理时用的是“请求时刻往前推10分钟”两者在行为密集场景下会有明显偏差。原因在于离线特征生成时采用了回填逻辑而线上没有严格按照同一逻辑重放。解决建议要么统一时间口径要么在离线回填时显式记录特征计算时间戳。最稳妥的做法是让离线特征生成和线上推理共用同一套特征计算代码不要各自实现。5.4 弹性伸缩抖动与扩容滞后现象流量突增时服务扩容速度跟不上导致部分请求被拒绝。原因Kubernetes的扩容依赖Metrics Server的指标采集默认采集周期是15秒加上Pod启动时间整体可能需要1-2分钟才能完成扩容。解决建议对流量波动大的服务可以设置一个“最低兜底实例数”比如2个不要追求缩零同时把指标采集周期调短到5秒左右。也可以配置基于Kafka积压消息量的KEDA触发器请求还没到Pod之前就提前扩容。5.5 避坑清单汇总实时特征必须有降级方案Redis或Kafka挂了不能拖垮主链路。窗口聚合状态一定要设置TTL否则状态存储会被拖垮。缩容窗口不要太短否则会出现扩缩容震荡。模型文件要提前预热到节点本地否则冷启动时间不可控。离线训练和在线推理的特征逻辑必须统一最好共用代码或者平台。线上特征取值要记录日志否则排查线上线下不一致时无据可查。6. 九月之后还可以往哪个方向走如果你已经完成了实时特征管道和弹性伸缩改造下一阶段可以考虑三件事。第一把实时特征的能力从“单一模型”扩展到“特征平台”。当多个模型都开始使用实时特征时统一平台能避免重复开发和口径混乱。第二把算力弹性策略从“按QPS伸缩”升级为“按业务价值伸缩”。比如大促期间提前预热实例非核心场景允许更长冷启动时间让算力真正跟着业务策略走。第三沉淀一套AI服务生产化配置模板。包括标准化部署清单、监控面板、成本报表让新模型上线时不用再重新踩一遍这些坑。我个人九月份最大的体会是实时数据和弹性算力都不是新技术但它们组合在一起确实把很多AI服务从“能跑起来”推向了“能省着跑、放心跑”。如果你的团队也正在做模型生产化建议先从这两个最基础又最容易被低估的环节入手改完一版再看线上运营数据你会明显感觉到差异。
