实时数据与弹性算力：AI模型从实验到生产的落地关键

九月份我陪着一个业务团队，把一套推荐模型从离线实验环境真正挪到了生产环境。原以为最大的坎是模型精度，结果真正让人头疼的，是两件听起来特别基础、做起来特别容易翻车的事：数据能不能实时地喂给模型，算力能不能在没有人调用的时候缩到零。这两个词放在一起，其实就是“AI负载往生产里推了一把”的真实含义——实时数据让模型有了“活”的输入，弹性算力让模型不再需要一台24小时空转的服务器来供养。

如果你也在做模型上线、在线推理、特征管道或者AI成本治理，这篇内容应该能帮上忙。我会把九月这两件事背后的技术逻辑、具体落地方案、常见坑和排查方法完整拆一遍，所有配置和步骤都是基于生产实践整理的，可以直接当参考。

1. 九月的两件事：为什么实时数据和弹性算力被同时推到台前

1.1 模型从实验到生产，缺的不是精度而是“流通性”

很多团队在模型迭代上都有一个惯性：把模型训好、指标刷高，就觉得可以上线了。但真正把模型部署到生产环境后，往往发现线上表现和离线评估差一大截。这不是模型本身的问题，而是数据的“流通性”出了问题。

离线训练时，模型吃的是整理好的批量特征，比如昨天的用户点击、前天的商品曝光。但生产环境里的数据是流式的、实时的，用户上一秒的行为会直接影响下一秒的推荐结果。如果数据管道仍然是按天或按小时批量同步，那么模型看到的基本是“过期”的用户状态。九月份我们调整了数据链路，把特征从T+1改成了秒级实时，同一个模型的线上AUC直接提升了3个百分点，代价是数据管道复杂度翻了一倍。

这里想强调一点：实时数据的价值不在于“快”，而在于让模型能感知当前时刻的业务状态。比如做风控，一个账户在10分钟内发生异常高频交易，模型必须在几十毫秒内收到这个特征。用批量管道根本做不到，只能靠流式处理。

1.2 算力缩到零背后，是AI成本模型的改变

“算力要能缩到零”这句话，很多人第一反应是省钱，其实没那么简单。它背后是一个成本模型的转变：从“包年包月买机器”变成“按实际消耗付费”。

传统做法是给模型服务常驻一台GPU或者几台CPU，不管有没有流量，都在烧钱。一个中等规模的推荐服务，光预留实例的闲置成本可能占整个AI预算的三成以上。尤其是一些内部工具类模型，比如文档摘要、代码辅助、报表解读，白天有人用，晚上几乎没人用，24小时常驻完全是浪费。

Scale-to-Zero的原理是：当服务在一段时间内没有请求时，自动把实例缩到0；来请求时，再迅速拉起实例。这样不算复杂，但真正落地有很多细节，后面展开讲。九月我们把一个内部问答模型的推理服务改造成弹性伸缩后，月度成本下降了约60%，且没有明显影响用户体验。

1.3 这两件事如何相互成就

实时数据和弹性算力不是两个独立的方向，它们在生产环境里是互相咬合的。

实时数据管道意味着模型对“当下”敏感，所以请求往往集中在业务高峰时段，比如早晚流量高峰、大促秒杀。如果算力不能跟着流量自动伸缩，要么高峰时扛不住，要么低谷时空转。反过来，如果算力能缩到零，那么你就有底气把更多低频业务接进来，哪怕一天只有几百次调用，也敢上线一个实时模型。这两个能力合在一起，才让AI负载第一次做到了“像普通Web服务一样”按需供给。

2. 实时数据喂模型：数据管道的设计与落地

2.1 核心技术点拆解：流式采集、特征计算、特征存储

要做一个实时特征链路，通常有四个核心环节：数据采集、流式计算、特征存储、特征服务。

数据采集是第一步。业务数据库里的变更、日志系统里的行为事件，都要以毫秒级延迟进入消息队列。常用工具是Debezium这类CDC（Change 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 训练-推理同源：离线在线一致性的三种做法

实时特征落地后，最大的技术债就是“离线在线不一致”。训练时用的还是T+1批量的静态特征，线上推理时却是实时特征，模型自然会对不齐。

业内比较成熟的思路有三种。第一种是最小改动方案：离线特征也按实时链路的逻辑重放一遍，比如把过去30天的原始事件流存下来，用同一套流式计算逻辑重新生成离线特征。这样离线训练数据和在线推理数据就同源了，缺点是存储和计算成本高。

第二种是时间旅行方案：Feature Store里保存特征的历史版本，训练时指定读取某个时间点的特征快照。这样不用重放事件流，但要求特征存储支持时间维度查询，实现复杂度更高。

第三种是混合方案：核心特征（如用户实时兴趣、频次）走实时链路，非核心特征（如用户画像、商品静态属性）仍然走离线批量。两套特征在Feature Store里统一注册、统一版本管理，线上推理时一起拼接。九月份我们实际采用的是这种方案，成本可控，一致性也基本满足。

无论选哪种，都要记住一个原则：特征的定义、加工逻辑、版本号，必须由同一个平台管理，不要训练一套代码、推理一套代码。

2.3 一个推荐场景的实时链路实例

以商品推荐为例，实时链路可以这样搭。

用户点击商品的事件通过前端SDK上报到Kafka，Topic命名为user_behavior。Flink作业消费这个Topic，按用户ID分组，计算：最近5分钟点击次数、最近10分钟点击品类分布、最近3次浏览的商品ID序列。计算结果写入Redis，Key设计为user:{userId}:realtime_feature，Value是一个JSON或Protobuf序列化的特征结构，TTL设为30分钟。

推理服务收到推荐请求后，先从Redis批量读取当前用户的实时特征，再从离线特征服务读取用户画像和商品静态特征，拼接后输入模型。

这套链路我们用了大约两周时间搭完，整体延迟在20毫秒以内（不含模型推理）。需要注意的点是：Kafka的分区数要结合Flink并行度设置，一般分区数等于并行度乘以1.5到2；Redis连接池要设置合理的最大连接数和超时时间，避免流量突增时连接打满。

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分钟没有请求，缩容到0；QPS超过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，也可以用KEDA（Kubernetes 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分钟浏览序列）、离线画像特征（用户年龄段、兴趣标签）、静态内容特征（文章分类、字数、作者等级）。所有特征在特征平台里统一注册，带版本号。

第二步，搭建实时数据管道。行为事件通过埋点上报到Kafka，Flink作业消费并计算窗口特征，写入Redis。离线特征继续沿用原有批量管道，每天全量刷新到在线存储。

第三步，改造推理服务。模型服务在收到请求后，先从Redis取实时特征，再从特征平台取离线特征，拼装成模型输入，调用模型进行推理。这一阶段重点做超时控制和降级策略：Redis查询设置50毫秒超时，超时则降级用纯离线特征，避免实时特征故障拖垮整个推荐接口。

第四步，接入弹性伸缩。推理服务部署到Knative，最小副本0，最大副本10，并发数5。夜间无流量时自动缩到零，白天流量高峰自动扩到5-8个实例。

第五步，建立监控与告警。监控三个核心指标：特征管道延迟（事件产生到特征可用的时间）、推理P95延迟、服务的扩容/缩容事件。特征管道延迟超过60秒就告警，说明Flink作业可能积压。

4.3 上线后的效果与成本对比

上线一周后的数据如下：

这里强调一下，实时特征带来的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，避免处理耗时太长导致rebalance；Flink的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服务从“能跑起来”推向了“能省着跑、放心跑”。如果你的团队也正在做模型生产化，建议先从这两个最基础又最容易被低估的环节入手，改完一版再看线上运营数据，你会明显感觉到差异。