ML模型生产化实战：监控、漂移检测与在线推理服务化

1. 项目概述：这不是一次“部署上线”，而是一场系统性交付实战

“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题里藏着太多被日常讨论轻描淡写带过的重量。它不是教你怎么把model.predict()封装成API，也不是演示用Flask跑个/predict端点就叫“上生产”。我带团队落地过17个跨行业ML项目，从银行反欺诈模型到工厂设备振动异常识别，再到连锁药店的销量动态补货策略，每一次真正进入生产环境后头三个月的故障日志，都比训练阶段的loss曲线更值得反复研读。Part 4之所以关键，在于它直面的是模型交付链路上最脆弱、也最容易被技术人回避的一环：当数据不再静止、当用户行为不可控、当基础设施会抖动、当业务指标每天波动±15%，你的模型还能不能稳住底线？这不是工程能力的终点，而是ML系统生命周期的真正起点。核心关键词——模型监控、数据漂移检测、在线推理服务化、A/B测试框架、回滚机制、可观测性埋点——每一个词背后都不是配置项，而是需要你亲手设计、验证、压测、并写进SLO（服务等级目标）里的硬性契约。适合谁看？如果你已经能熟练写出PyTorch训练循环、调通MLflow实验跟踪、甚至搭好Kubeflow pipeline，但一听到“线上模型突然掉点查不出原因”就头皮发紧；或者你正被产品追问“为什么推荐点击率上周涨了8%这周又跌回原点”，却只能翻Jupyter历史记录找线索——那这篇就是为你写的。它不讲理论推导，只讲我在产线踩坑后重写的6版监控脚本、在K8s里调试37小时才稳定的gRPC流式推理配置、以及那个让运维同事第一次主动给我倒咖啡的自动降级开关设计。

2. 内容整体设计与思路拆解：为什么必须放弃“单体模型思维”

2.1 从“模型即服务”到“模型即系统”的范式迁移

很多团队卡在Part 4，本质是还活在“Notebook思维”里：模型是一个静态文件（.pkl或.onnx），输入是干净的DataFrame，输出是确定的预测值。但真实世界的数据流是脉冲式的——凌晨三点的支付风控请求可能突增200%，而特征计算依赖的上游订单库正在做每日备份锁表；下午两点的电商推荐请求里混入大量爬虫UA，导致用户画像特征向量集体失真；更别说AB测试中同时跑着3个版本的排序模型，流量分配策略本身就在动态调整。这时候，如果还把模型当黑盒塞进一个Flask服务里，等于把核电站反应堆装进自行车车筐——物理上可行，逻辑上自杀。

我们最终采用的架构不是“微服务”，而是“可编排的模型服务网格”。核心组件包括：

• 特征服务层（Feature Serving）：独立于模型服务，通过Redis+Protobuf提供毫秒级特征查询，所有特征计算逻辑与模型解耦，支持TTL缓存和离线特征快照回填；
• 模型路由网关（Model Router）：基于请求上下文（user_id、device_type、region）动态选择模型版本、特征集、甚至降级策略，不依赖DNS或K8s Service，而是内嵌规则引擎；
• 可观测性探针（Observability Probe）：在特征获取、模型加载、前向推理、后处理四个环节埋点，采集延迟P99、内存驻留峰值、GPU显存占用、输入张量shape分布等12类指标，全部直连Prometheus，不经过任何中间聚合服务；
• 自动决策中枢（Auto-Decision Hub）：当检测到数据漂移（KS检验p-value < 0.01持续5分钟）或服务延迟超阈值（>200ms P95达3次/分钟），自动触发预设动作：切流至影子模型、启用缓存兜底、或强制降级为规则引擎。

这个设计放弃的不是技术复杂度，而是“一次性交付幻觉”。它承认模型会老化、数据会变异、基础设施会故障——所以所有组件必须具备独立健康检查、独立升级路径、独立熔断能力。比如特征服务宕机时，模型服务不报错，而是自动切换到本地缓存特征（带时间戳校验），同时向告警通道发送“特征陈旧度>15min”事件。这种设计让我们的平均故障恢复时间（MTTR）从17分钟压缩到43秒。

2.2 为什么不用现成MLOps平台？三个血泪教训

看到这里你可能想：Kubeflow、Seldon、BentoML这些不是现成方案吗？我们确实试过。第一版用Kubeflow部署，上线第三天凌晨收到告警：模型服务Pod内存持续增长，3小时后OOM Kill。排查发现是Kubeflow的TensorRT优化器在加载ONNX模型时，对动态batch size的内存预分配策略有缺陷，而我们的风控场景请求batch size从1到500随机波动。第二版换Seldon，AB测试功能很炫，但当需要同时对比模型A（实时特征）、模型B（T+1特征）、模型C（混合特征）时，它的流量分割器无法按特征新鲜度做条件路由，只能粗暴按请求ID哈希，导致实验组数据污染。第三版用BentoML，本地开发丝滑，但生产环境镜像体积暴涨到2.3GB（含所有conda环境），每次模型更新都要重新拉取镜像，CI/CD流水线卡在镜像推送环节平均耗时8分23秒。

最终我们选择“乐高式自建”：用FastAPI写轻量服务框架（启动<300ms），用Docker BuildKit做多阶段构建（最终镜像<380MB），用Argo Workflows编排训练-评估-部署流水线（失败自动重试+人工审批门禁）。关键不是拒绝工具，而是拒绝把工具当解决方案。就像不会因为有电钻就放弃学木工榫卯结构——MLOps平台是锤子，而模型生产化是整栋房子的地基、承重墙和电路布线图。

2.3 数据漂移检测：别再只盯着KS检验

几乎所有教程都教你用KS检验或PSI（Population Stability Index）检测数据漂移，但真实场景中，这两个指标在三个致命场景下会集体失明：

• 类别型特征的长尾分布漂移：比如电商用户设备类型字段，正常情况下iOS占比62%，Android 35%，其他3%。某次APP更新后，鸿蒙设备突然涌入，占比升至8%，但iOS和Android比例微调，KS检验p-value=0.12（未报警），而实际模型在鸿蒙设备上的F1下降23%；
• 时序相关特征的相位漂移：比如“用户最近1小时点击次数”，在工作日早高峰（9-10点）和周末晚高峰（20-21点）的分布形态相似，但峰值时间偏移3小时，KS检验无法捕捉这种相位变化；
• 多维特征的联合漂移：单独看“年龄”和“城市等级”都没漂移，但“18-25岁一线城市的用户”群体占比从12%骤降至4.7%，这种交叉漂移KS检验完全无感。

我们的解决方案是“三阶漂移检测矩阵”：

1. 基础层（Statistical Drift）：保留KS检验，但仅用于数值型特征的单变量检测，阈值设为p-value < 0.001（比常规严10倍）；
2. 结构层（Structural Drift）：对类别型特征，用卡方检验+长尾桶合并（将占比<0.5%的类别全归为“other”），并引入类别熵变率（ΔH = |H_t - H_{t-1}|），当熵变率>0.15时触发告警；
3. 语义层（Semantic Drift）：对文本/图像等非结构化特征，用预训练模型（如Sentence-BERT）提取特征向量，计算滑动窗口内向量簇的余弦相似度标准差，当标准差连续3个窗口>0.08时判定为语义漂移。

这套组合拳让我们在某次新闻热点引发的用户搜索词突变中，提前47分钟捕获到语义漂移，比业务侧感知早2小时15分钟。

3. 核心细节解析与实操要点：监控不是加指标，而是建契约

3.1 模型服务的可观测性埋点：12个必埋指标详解

很多人以为监控就是加几个time.time()打点，但生产环境的监控必须回答三个问题：哪里坏了？坏到什么程度？影响多少用户？这需要指标具备可聚合性、可下钻性、可告警性。我们定义的12个核心指标不是随便选的，每个都对应一个明确的SLI（Service Level Indicator）：

提示：不要用logging.info()打点！所有指标必须通过OpenTelemetry SDK直接上报Prometheus，避免日志解析的延迟和丢失。我们曾因用日志埋点，在一次大规模故障中丢失了关键的fallback_trigger_count数据，导致无法复盘降级决策链路。

3.2 在线推理服务的gRPC优化：为什么HTTP/1.1撑不住高并发

很多团队坚持用Flask/FastAPI的HTTP接口，理由是“开发快、调试方便”。但在真实高并发场景下，HTTP/1.1的连接复用机制和序列化开销会成为瓶颈。我们做过压测：同一台T4 GPU服务器，用FastAPI（JSON序列化）处理1000 QPS时，平均延迟217ms，CPU使用率82%；换成gRPC（Protobuf二进制序列化）后，延迟降至89ms，CPU使用率41%。差距来自三个层面：

第一，序列化效率：Protobuf二进制编码比JSON文本小63%，网络传输耗时减少；更重要的是，Protobuf在Python中用C扩展实现，反序列化速度是JSON的4.2倍（实测10KB payload）。我们的特征向量是128维float32，JSON序列化后约2.1KB，Protobuf仅780字节。

第二，连接管理：HTTP/1.1默认短连接，每个请求建立TCP三次握手；gRPC基于HTTP/2，支持多路复用，单个TCP连接可承载数千并发流。我们在K8s中观察到，HTTP服务的ESTABLISHED连接数峰值达3200+，而gRPC稳定在23个。

第三，流式能力：风控场景需要实时拦截恶意请求，gRPC的Server Streaming让我们能在模型推理中途就返回“拒绝”信号，而HTTP必须等整个响应体生成。这使高风险请求的平均拦截延迟从310ms降至142ms。

实操中我们踩过两个坑：一是Protobuf的oneof字段在Python客户端解析时容易出错，必须严格校验WhichOneof()返回值；二是gRPC的keepalive参数不配会导致K8s Service Mesh（如Istio）误判连接死亡，必须设置grpc.keepalive_time_ms=30000且grpc.keepalive_timeout_ms=10000。

3.3 A/B测试框架：流量分割不是随机哈希，而是业务语义路由

绝大多数A/B测试框架用请求ID哈希做流量分割，这在技术上简单，但业务上危险。举个真实案例：某次我们测试新推荐模型，按user_id哈希分5%流量给新模型。结果发现新模型在iOS用户上CTR提升12%，但在Android用户上下降9%。由于哈希分流不保证设备类型均匀分布，实际iOS用户在新模型组占比高达73%，导致整体实验结论严重偏差。

我们的解决方案是“语义分层路由”：

• 第一层（强业务约束）：按region（地域）和app_version（APP版本）做静态分组，确保每个实验组包含所有地域和版本的最小样本量（如每组至少1000个iOS 15.4用户）；
• 第二层（动态负载均衡）：在满足第一层约束后，用一致性哈希（Consistent Hashing）对user_id分片，避免单个用户在不同请求中被分到不同组；
• 第三层（实验隔离）：每个实验有独立路由规则，支持“交集”（同时参与多个实验）和“互斥”（只能参与一个实验）模式，规则引擎用Rete算法实现，匹配速度>50万次/秒。

这套系统让我们在一次跨12个业务线的大型模型升级中，实现了零感知灰度——先对1%的低价值用户（LTV<50元）全量切流，验证无误后再按用户价值分层逐步放量，全程业务方无需改任何代码。

4. 实操过程与核心环节实现：从代码到SLO的完整闭环

4.1 数据漂移检测模块的完整实现（Python）

以下是我们生产环境运行的漂移检测核心代码，已脱敏并注释关键设计点。注意：这不是玩具代码，而是每天处理2.3亿条请求特征的工业级实现。

import numpy as np from scipy import stats from sklearn.metrics import pairwise_distances from sentence_transformers import SentenceTransformer import torch class DriftDetector: def __init__(self, window_size=3600, min_samples=1000): """ 初始化漂移检测器 :param window_size: 滑动窗口大小（秒），对应1小时数据 :param min_samples: 触发检测的最小样本数，避免冷启动误报 """ self.window_size = window_size self.min_samples = min_samples # 语义层模型（轻量版） self.semantic_model = SentenceTransformer('paraphrase-multilingual-MiniLM-L12-v2', device='cpu') # CPU推理足够，避免GPU争抢 def _statistical_drift(self, current_data: np.ndarray, ref_data: np.ndarray) -> dict: """基础统计漂移检测（仅用于数值型特征）""" if len(current_data) < self.min_samples or len(ref_data) < self.min_samples: return {'drifted': False, 'p_value': 1.0, 'method': 'insufficient_samples'} # KS检验，但用双样本KS（更严格） ks_stat, p_value = stats.ks_2samp(current_data, ref_data, alternative='two-sided') drifted = p_value < 0.001 # 严苛阈值 return {'drifted': drifted, 'p_value': p_value, 'method': 'ks_2sample'} def _structural_drift(self, current_cats: list, ref_cats: list) -> dict: """结构漂移检测（类别型特征）""" # 合并长尾类别 def merge_tail(categories, threshold=0.005): cat_counts = {} for c in categories: cat_counts[c] = cat_counts.get(c, 0) + 1 total = len(categories) merged = {} tail_sum = 0 for c, cnt in cat_counts.items(): if cnt / total >= threshold: merged[c] = cnt else: tail_sum += cnt if tail_sum > 0: merged['other'] = tail_sum return merged curr_merged = merge_tail(current_cats) ref_merged = merge_tail(ref_cats) # 构建对齐的频次向量 all_cats = set(curr_merged.keys()) | set(ref_merged.keys()) curr_vec = [curr_merged.get(c, 0) for c in all_cats] ref_vec = [ref_merged.get(c, 0) for c in all_cats] # 卡方检验 chi2, p_value, _, _ = stats.chi2_contingency([curr_vec, ref_vec]) drifted = p_value < 0.01 # 同时计算类别熵变率 def entropy(vec): probs = np.array(vec) / sum(vec) return -sum(p * np.log2(p) for p in probs if p > 0) curr_ent = entropy(curr_vec) ref_ent = entropy(ref_vec) entropy_delta = abs(curr_ent - ref_ent) entropy_drifted = entropy_delta > 0.15 return { 'drifted': drifted or entropy_drifted, 'p_value': p_value, 'entropy_delta': entropy_delta, 'method': 'chi2_entropy' } def _semantic_drift(self, current_texts: list, ref_texts: list) -> dict: """语义漂移检测（文本特征）""" if len(current_texts) < self.min_samples or len(ref_texts) < self.min_samples: return {'drifted': False, 'std_dev': 0.0, 'method': 'insufficient_samples'} # 批量编码，避免OOM def encode_batch(texts, batch_size=32): embeddings = [] for i in range(0, len(texts), batch_size): batch = texts[i:i+batch_size] # CPU编码，避免GPU显存碎片 with torch.no_grad(): emb = self.semantic_model.encode(batch, convert_to_tensor=True, show_progress_bar=False) embeddings.append(emb.cpu().numpy()) return np.vstack(embeddings) curr_emb = encode_batch(current_texts) ref_emb = encode_batch(ref_texts) # 计算余弦相似度矩阵（仅计算上三角，节省内存） from sklearn.metrics.pairwise import cosine_similarity curr_sim = cosine_similarity(curr_emb) # 取上三角并展平 curr_upper = curr_sim[np.triu_indices_from(curr_sim, k=1)] ref_sim = cosine_similarity(ref_emb) ref_upper = ref_sim[np.triu_indices_from(ref_sim, k=1)] # 计算标准差差异 curr_std = np.std(curr_upper) ref_std = np.std(ref_upper) std_diff = abs(curr_std - ref_std) drifted = std_diff > 0.08 and curr_std > 0.05 # 避免低相似度噪声 return { 'drifted': drifted, 'std_diff': std_diff, 'curr_std': curr_std, 'method': 'cosine_similarity_std' } def detect_drift(self, feature_name: str, current_data, ref_data, data_type: str) -> dict: """ 统一漂移检测入口 :param feature_name: 特征名（用于日志和告警） :param current_data: 当前窗口数据（list或np.ndarray） :param ref_data: 参考数据（通常为过去24小时） :param data_type: 'numerical', 'categorical', 'text' :return: 检测结果字典 """ if data_type == 'numerical': result = self._statistical_drift(current_data, ref_data) elif data_type == 'categorical': result = self._structural_drift(current_data, ref_data) elif data_type == 'text': result = self._semantic_drift(current_data, ref_data) else: raise ValueError(f"Unsupported data_type: {data_type}") result['feature_name'] = feature_name result['timestamp'] = int(time.time()) result['window_size_sec'] = self.window_size # 关键：添加业务上下文标签，便于告警分级 if feature_name in ['user_device_type', 'app_version']: result['severity'] = 'high' # 设备类特征漂移直接影响用户体验 elif feature_name.startswith('embedding_'): result['severity'] = 'medium' else: result['severity'] = 'low' return result # 使用示例（在特征服务中定时调用） detector = DriftDetector(window_size=3600) # 每小时从特征库拉取最新1小时数据 current_features = get_feature_window('user_click_count', hours=1) ref_features = get_feature_window('user_click_count', hours=24, offset_hours=1) result = detector.detect_drift( feature_name='user_click_count', current_data=current_features, ref_data=ref_features, data_type='numerical' ) if result['drifted']: alert_slack(f"⚠️ 数据漂移告警: {result['feature_name']} | {result['method']} | p={result['p_value']:.4f}")

注意：这段代码的关键不在算法，而在工程鲁棒性。比如encode_batch函数强制CPU推理，是因为GPU显存会被主模型服务抢占；merge_tail函数的阈值0.005是经过23次线上实验调优的，太大会漏掉重要长尾，太小会导致other类别膨胀；severity分级直接对接PagerDuty告警级别，高危漂移15秒内电话通知，低危漂移仅邮件汇总。

4.2 模型服务的自动降级开关设计（Kubernetes ConfigMap驱动）

降级不是“服务挂了切备用”，而是“在可控范围内优雅妥协”。我们的降级开关是声明式的，由K8s ConfigMap驱动，无需重启服务。ConfigMap内容如下：

# drift-fallback-config.yaml apiVersion: v1 kind: ConfigMap metadata: name: model-fallback-config namespace: ml-production data: # 全局开关：true表示启用降级策略 enabled: "true" # 特征服务超时降级（单位：毫秒） feature_timeout_ms: "300" # 模型推理超时降级（单位：毫秒） model_timeout_ms: "500" # 缓存兜底策略 cache_fallback: | { "enabled": true, "max_age_seconds": 300, "stale_while_revalidate": true } # 规则引擎降级（当模型完全不可用时） rule_fallback: | { "enabled": true, "rules": [ {"condition": "user_ltv > 1000", "action": "recommend_high_value_items"}, {"condition": "user_click_rate < 0.01", "action": "show_popular_items"} ] } # AB测试降级（当实验组数据异常时） ab_test_fallback: | { "enabled": true, "default_group": "control" }

服务启动时加载此ConfigMap，并监听其变更（通过K8s watch API）。当检测到feature_timeout_ms从300改为100时，服务会在10秒内生效新策略——这意味着运维可以半夜收到告警后，用一条kubectl patch命令就把特征超时阈值收紧，而不用等研发上线。

降级逻辑在服务代码中实现为装饰器：

def fallback_handler(func): """降级装饰器，支持多级降级""" @functools.wraps(func) def wrapper(*args, **kwargs): config = get_fallback_config() # 从ConfigMap实时读取 # 第一级：特征超时降级 if config.get('feature_timeout_ms'): try: # 设置特征获取超时 future = executor.submit(get_features, args[0]) features = future.result(timeout=int(config['feature_timeout_ms'])/1000) except concurrent.futures.TimeoutError: if config.get('cache_fallback', {}).get('enabled'): features = get_cache_fallback(args[0]) else: raise else: features = get_features(args[0]) # 第二级：模型推理降级 try: result = func(features, timeout=int(config['model_timeout_ms'])/1000) except ModelTimeoutError: if config.get('rule_fallback', {}).get('enabled'): result = apply_rule_fallback(features) else: raise return result return wrapper @fallback_handler def predict(features: dict) -> dict: # 主模型推理逻辑 pass

实操心得：降级策略必须可测试、可审计、可回滚。我们要求每个降级分支都有单元测试覆盖，且每次降级触发都会记录fallback_reason和fallback_duration到审计日志。曾经有一次因ConfigMap格式错误导致规则引擎降级失效，审计日志帮我们3分钟内定位到是JSON语法错误，而不是模型问题。

4.3 SLO（服务等级目标）的制定与量化：把“可用”变成数字

很多团队说“我们要99.9%可用”，但没人定义“可用”是什么。我们的SLO文档是这样写的：

关键创新点在于SLO不是静态的。比如p95_inference_latency在凌晨0-5点允许放宽到200ms（因为流量低，资源可调度），而早9点高峰必须≤120ms。这个动态SLO通过Prometheus的hour()函数实现：

# 动态延迟SLO：工作日9-18点更严格 100 * ( sum(rate(http_request_duration_seconds_bucket{job="ml-model", le="0.12"}[5m])) / sum(rate(http_request_duration_seconds_count{job="ml-model"}[5m])) ) * on() group_left() ( # 工作日9-18点：要求≤120ms (day_of_week() > 1 and day_of_week() < 7) * (hour() >= 9 and hour() < 18) * 1 + # 其他时间：≤150ms (1 - ((day_of_week() > 1 and day_of_week() < 7) * (hour() >= 9 and hour() < 18))) * 1 )

SLO的量化直接驱动我们的容量规划。当feature_freshness_minutes连续一周在14:00-15:00超标，我们就知道特征计算Pipeline的Spark作业需要增加executor数量，而不是盲目加机器。

5. 常见问题与排查技巧实录：那些凌晨三点的救火笔记

5.1 “模型准确率没变，但业务指标掉了”——如何定位隐性衰减

这是最折磨人的故障：离线评估AUC 0.82，线上A/B测试组CTR却比对照组低3.7%。我们建立了“三层归因漏斗”来系统排查：

第一层：数据层归因

• 检查特征分布：用上面的漂移检测模块，发现user_session_length_minutes特征在实验组的P95从12.3min降至8.1min，说明新模型吸引的用户停留时间更短；
• 检查样本偏差：发现实验组中new_user占比从18%升至29%，而模型在新用户上表现本就较差（离线测试显示新用户AUC仅0.71）；

第二层：服务层归因

• 检查延迟分布：实验组P95延迟142ms，对照组138ms，看似差别不大，但P99延迟实验组291ms vs 对照组215ms——说明长尾请求受影响更大；
• 检查降级率：实验组fallback_trigger_count是对照组的3.2倍，主要触发原因是feature_timeout，根源是新模型需要更多特征，而特征服务未扩容；

第三层：业务层归因

• 检查用户分群：把用户按LTV分四档，发现新模型在LTV>500元用户中CTR+5.2%，但在LTV<100元用户中CTR-12.8%；
• 检查场景分布：新模型在首页Feed流CTR+8.3%，但在搜索结果页CTR-6.1%，说明模型对搜索意图理解有偏差。

最终根因是：新模型特征工程过度依赖实时行为，而搜索场景用户行为稀疏，导致特征向量质量差。解决方案不是回滚，而是动态特征开关：对搜索请求，自动关闭3个高成本实时特征，改用T+1离线特征。

5.2 “GPU显存没满，但推理延迟飙升”——CUDA上下文泄漏排查

某次上线新版本后，T4 GPU的nvidia-smi显示显存占用仅65%，但inference_latency_ms_p95从89ms飙升至327ms。nvtop显示GPU利用率忽高忽低，不像计算瓶颈。

排查步骤：

1. 确认是否CUDA上下文泄漏：执行nvidia-smi --query-compute-apps=pid,used_memory --format=csv，发现有12个残留进程，每个占用200MB显存，但ps aux | grep python找不到对应进程——这是典型的CUDA上下文未释放；
2. 定位泄漏点：在模型加载代码中加入torch.cuda.memory_summary()，发现每次model.eval()后显存未释放，原因是模型中用了nn.DataParallel（已弃用），改用torch.nn.parallel.DistributedDataParallel后问题解决；
3. 预防措施：在服务启动脚本中加入nvidia-smi --gpu-reset -i 0（仅限测试环境），并在K8s Liveness Probe中加入显存泄漏检测：

# K8s liveness probe script #!/bin/bash # 检查是否有僵尸CUDA上下文 ZOMBIE_COUNT=$(nvidia-smi --query-compute-apps=pid,used_memory --format=csv,noheader,nounits | wc -l) if [ "$ZOMBIE_COUNT" -gt 5 ]; then echo "Zombie CUDA contexts detected: $ZOMBIE_COUNT" exit 1 fi # 检查显存占用率 MEM_USAGE=$(nvidia-smi --query-gpu=memory.used --format=csv,noheader,nounits | head -1 | awk '{print $1}') if [ "$MEM_USAGE" -gt 8000 ]; then echo "GPU memory usage too high: ${MEM_USAGE}MB" exit 1 fi exit 0

5.3 “AB测试流量不均”——K8s Service负载均衡陷阱

我们用Istio VirtualService做AB测试流量分割，配置了5%流量到新模型。但监控显示新模型组QPS只有预期的62%。根本原因在于：Istio默认使用轮询（Round Robin）负载均衡，而我们的模型服务Pod在K8s中启用了readinessProbe，但probe路径/healthz的响应时间不稳定（有时120ms，有时450ms），导致Istio认为部分Pod“不健康”而跳过它们，实际流量只打到响应快的2个Pod上。

解决方案是：

• 将readinessProbe改为exec类型