1. 项目概述：这不是一篇讲算法的论文，而是一份给工程团队的“系统体检报告”

你手头正跑着一个准确率92%的模型，测试集上表现亮眼，但上线三天后，线上服务响应延迟翻了三倍，监控告警邮件堆成山，业务方在群里@你问“模型是不是挂了”。你打开日志，发现不是代码报错，而是特征计算耗时暴涨——原来上游数据管道里，某个字段的空值率从0.3%突然跳到47%，而你的特征工程脚本里那行df['col'].fillna(0)，正在默默把四百万条记录逐行填充，CPU吃满。这场景熟不熟？我去年在做信贷风控模型迭代时，就卡在这个点上整整两周，最后发现罪魁祸首不是模型本身，而是特征存储层用的Redis过期策略和实时特征拼接的并发控制没对齐。

这就是《Machine Learning Systems Pt. 1: Overview and Challenges》真正想说的事：机器学习系统不是模型训练完成就结束的流水线，而是一套需要持续心跳、定期体检、能自我修复的有机体。它不关心你用了Transformer还是XGBoost，只在乎当流量峰值来临时，特征提取是否稳定、模型服务是否低延迟、数据漂移是否被及时捕获。关键词里的“Towards AI”不是平台背书，而是指明了这个内容的坐标系——它站在AI工程化落地的前线，面向的是每天要和Kubernetes集群、特征仓库、监控告警系统打交道的ML工程师、数据平台工程师和SRE，而不是坐在实验室调参的研究员。

这篇文章的价值，恰恰在于它撕掉了“MLOps”这个词常被赋予的虚幻光环。很多人以为MLOps就是买套工具链、搭个CI/CD流水线、再加个模型监控面板，系统就自动健康了。实则不然。我见过最典型的反例是一家电商公司，花半年时间落地了全套开源MLOps栈：用MLflow管理实验、用Kubeflow做训练编排、用Prometheus+Grafana监控服务指标。结果大促期间，推荐模型的A/B测试流量切到新版本后，GMV不升反降。排查三天才发现，问题出在特征缓存失效逻辑上——旧版缓存key是user_id+item_id+timestamp，新版为了支持实时行为流改成了user_id+item_id+hour_of_day，但缓存清理脚本没同步更新，导致大量过期特征被复用。你看，工具链再完整，只要系统设计层面的耦合点没理清，故障就必然发生。所以这篇概述的价值，是帮你建立一套“系统级诊断思维”：当问题出现时，你能快速判断它属于数据层、特征层、模型层、服务层还是反馈闭环层，并知道每个层级最关键的三个健康指标是什么。这才是真正能救命的能力。

2. 系统设计的核心矛盾：为什么“能跑通”和“能扛住”之间隔着一整个工程体系

2.1 模型成功与系统失败的鸿沟：从单点最优到全局稳态

我们先直面一个残酷事实：一个在Jupyter Notebook里完美运行的模型，其成功概率与它在生产环境中稳定运行的概率，几乎不相关。这不是危言耸听，而是我过去八年带过的二十多个落地项目反复验证的结论。原因很简单——Notebook验证的是“静态正确性”，而生产系统要求的是“动态鲁棒性”。举个具体例子：你在训练时用sklearn.preprocessing.StandardScaler对数值特征做标准化，fit时传入了10万条样本，得到均值μ=5.23、标准差σ=1.87。上线后，服务接收请求，每条请求都用这两个固定参数做transform。表面看没问题，但当某天上游数据源异常，突然涌入一批用户年龄为-1（数据库默认值错误）或999（埋点bug），StandardScaler.transform()不会报错，它会忠实地计算(-1 - 5.23) / 1.87 ≈ -3.33，这个离群值直接输入模型，可能触发内部激活函数饱和，导致预测结果集体失真。而你的监控如果只看p95_latency和error_rate，根本发现不了——因为请求全成功了，只是结果全错了。

这个案例揭示了第一个核心矛盾：模型层的数学严谨性，无法覆盖数据层的现实混沌性。解决方案从来不是“让数据更干净”，而是构建“容错的数据契约”。我在金融风控项目里强制推行了一套规则：所有进入特征工程模块的原始字段，必须声明三个契约——有效值域（如age: [0, 120]）、空值容忍度（如phone_number_null_ratio < 5%）、分布偏移阈值（如income_std_dev变化率 < 20%）。这些契约不是写在文档里，而是嵌入在数据接入Pipeline的校验节点中。一旦触发，Pipeline自动阻断并告警，同时降级到备用特征源（比如用用户注册城市平均收入替代缺失的个人收入）。这种设计思路，把“数据质量”的被动验收，变成了“数据契约”的主动防御。它不追求100%完美数据，而是确保系统在数据不完美时，依然有明确的、可预期的降级路径。

2.2 工具链迷思：为什么堆砌开源组件反而增加系统熵值

当前社区有个明显误区：把MLOps等同于工具选型。看到别人用MLflow就跟着上MLflow，听说Kubeflow流行就硬上Kubeflow。我参与过一个医疗影像项目，团队初期雄心勃勃，一口气引入了七种工具：DVC做数据版本、MLflow管实验、Airflow调度、Feast建特征仓库、Triton部署模型、Evidently做数据漂移检测、Grafana看监控。结果上线三个月，运维成本飙升，光是维护这些工具间的认证、网络策略、资源配额就占了工程师40%的时间。更致命的是，当CT扫描图像预处理环节出问题时，排查路径变成：Grafana告警 → 查Triton日志无异常 → 查Feast特征查询延迟高 → 追踪到Airflow任务卡在DVC pull → 发现是对象存储桶权限配置错误。一个本该5分钟定位的问题，花了6小时。

这暴露了第二个核心矛盾：工具链的丰富度，与系统可观测性的清晰度，呈负相关。每增加一个组件，就新增至少三个耦合点：数据格式转换、状态同步、错误传播。我的经验是，生产级ML系统的第一设计原则，是“最小必要工具集”。我们现在的新项目，工具栈严格控制在四个核心组件内：

1. 数据与特征层：自研轻量级特征服务（基于Go+RocksDB），放弃Feast的复杂抽象，只提供get_features(user_id, timestamp)一个接口，所有特征计算逻辑下沉到SQL或Python UDF，版本由Git Commit Hash标识；
2. 模型训练层：PyTorch Lightning + 自定义Callback，完全绕过MLflow/Kubeflow，训练脚本即服务，输出物只有模型文件、特征统计快照、测试报告三样东西；
3. 模型服务层：Triton Inference Server，但只启用HTTP/REST协议，禁用gRPC和模型组合（Ensemble），所有预处理/后处理逻辑写在客户端；
4. 可观测性层：Prometheus + 自研Exporter（采集Triton指标、特征服务QPS、数据延迟），Grafana Dashboard只保留5个核心看板：特征新鲜度、模型推理延迟P95、特征分布偏移指数、异常请求占比、服务可用率。

这个精简栈的代价是前期开发多花2周，但换来的是：故障平均定位时间从4.2小时降到18分钟，新成员上手周期从3周缩短到3天。工具不是越多越好，而是越少、越透明、越可控越好。当你能用curl命令直接调用特征服务、用kubectl logs一眼看清模型服务状态、用promql一句查出数据延迟拐点时，系统的“熵值”才真正可控。

2.3 团队协作断层：为什么数据科学家和工程师总在互相指责

最后一个常被忽视的系统性挑战，是角色间的认知鸿沟。典型场景：数据科学家提交一个新模型PR，附带notebook证明AUC提升0.005；工程师收到后第一反应是：“这个模型依赖的feature_x字段，上游ETL任务SLA是2小时，但我们的服务SLA要求特征延迟<5分钟，怎么保证？” 科学家回：“那是你们工程的事，模型效果好就行。” 工程师怒：“效果好但用不了，等于零。”

这背后是第三个核心矛盾：模型价值的评估维度，与系统价值的评估维度，存在本质错位。科学家看AUC、F1，工程师看p95_latency、error_rate、cost_per_inference。两者没有高下，但必须对齐。我们的解法是推行“联合健康指标卡”（Joint Health Scorecard），在每次模型迭代评审会上，强制展示两张表：

这张表强制双方用同一套语言对话。当科学家提出“我要用新的时序特征”，工程师立刻能评估：“这个特征计算需要调用3次外部API，会把p95延迟推高到150ms，超过阈值，建议改用滑动窗口聚合替代”。反之，当工程师说“这个特征源延迟太高”，科学家会主动提供降级方案：“我们可以用上一小时的特征值插值，AUC损失预计0.001，在可接受范围内”。系统设计的终极目标，不是消灭矛盾，而是把矛盾转化为可量化、可协商、可落地的协作协议。

3. 核心挑战深度拆解：从理论概念到工程现场的每一处坑

3.1 数据漂移：不是“会不会发生”，而是“何时发生、影响多大、如何量化”

“数据漂移”这个词被谈得太多，却很少有人告诉你：在真实业务场景中，数据漂移不是突发奇想的灾难，而是缓慢渗透的慢性病。它往往始于一个微小的产品改动。比如，某社交App上线“青少年模式”，强制14岁以下用户只能看到经过严格审核的内容。一夜之间，这个年龄段用户的互动行为数据分布巨变——点赞率下降60%，评论长度中位数从23字降到7字，视频完播率从45%飙升至82%。如果你的推荐模型还在用半年前的用户行为数据训练，它对这群用户的预测，本质上是在用“成年人的阅读习惯”去猜“青少年的短视频偏好”，偏差早已注定。

但问题来了：你怎么知道漂移发生了？很多团队依赖Evidently或NannyML这类库的内置检测器，比如Kolmogorov-Smirnov检验。我试过，效果很一般。KS检验对样本量极度敏感——当你的日活用户超千万，哪怕分布偏移0.1%，KS统计量也大概率显著，产生海量误报。后来我们改用一种更务实的“业务感知漂移检测法”：

1. 定义关键业务特征子集：不是所有特征都重要。我们只监控5个核心特征：avg_session_duration_sec、click_through_rate、share_count_per_session、video_watch_ratio、search_query_length_avg。选择依据是：它们与核心业务指标（DAU、ARPU）的相关系数绝对值>0.6。
2. 计算滚动窗口偏移指数：对每个特征，计算过去7天与前7天的分布差异。不用KS，改用Wasserstein距离（Earth Mover's Distance），它对小样本更鲁棒，且结果有物理意义（单位：特征值的标准差）。公式为：

   W_distance = ∫|CDF_current(t) - CDF_baseline(t)| dt

   实际实现中，我们用分位数近似：将特征值划分为100个分位点，计算每个分位点的值差绝对值之和，再除以100。
3. 设置动态阈值：阈值不是固定值，而是基于历史波动率。每周一凌晨，系统自动计算过去30天每个特征的W_distance标准差σ，然后设定本周阈值为mean_W_distance + 2*σ。这样，阈值会随业务淡旺季自动调整。
4. 关联业务事件：当任一特征W_distance超阈值，系统不直接告警，而是先查询产品日志API，检查过去24小时内是否有相关功能上线、灰度发布或运营活动。如果有，标记为“已知变更”，仅生成分析报告；如果没有，才触发P2级告警，并附上受影响的下游模型列表。

这套方法上线后，数据漂移告警准确率从32%提升到89%，更重要的是，它把“技术告警”转化成了“业务洞察”。工程师不再问“漂移是什么”，而是能直接告诉产品经理：“青少年模式上线后，video_watch_ratio的W距离飙升到3.2σ，说明模型对青少年用户的视频偏好预测偏差极大，建议优先优化这部分特征。”

3.2 特征工程陷阱：那些在训练时沉默、在服务时咆哮的“幽灵Bug”

特征工程是ML系统里最易被低估、也最易出问题的环节。它的危险在于：绝大多数特征Bug，在训练阶段完全隐形，只在服务阶段集中爆发。我整理了过去踩过的三大类“幽灵Bug”，每一种都曾让我们在凌晨三点被电话叫醒。

第一类：时间穿越（Time Travel）Bug。这是最经典的错误。你在训练时，用df['date'] >= '2023-01-01'过滤数据，但特征计算逻辑里有一行df['user_reg_days'] = (pd.Timestamp('today') - df['reg_date']).dt.days。问题在于，pd.Timestamp('today')在训练时是2023-12-01，但在2024年1月的服务中，它变成了2024-01-01。结果，所有用户注册天数凭空+31天，特征值整体右移，模型预测彻底失准。解决方案极其简单粗暴：所有时间相关计算，必须使用训练时的“快照时间点”作为基准。我们在训练脚本开头强制定义TRAINING_SNAPSHOT_TIME = pd.Timestamp('2023-12-01')，所有timedelta计算都基于此，且该时间戳作为元数据写入模型文件。服务端加载模型时，自动读取并用于特征计算。

第二类：隐式依赖（Hidden Dependency）Bug。你以为的独立特征，其实暗藏玄机。比如，一个“用户活跃度”特征，定义为log(1 + 7day_active_days)。看起来很安全。但某天上游数据团队重构了active_days的计算逻辑，从“登录即算活跃”改为“登录且有页面停留>10秒才算活跃”。这个改动本身合理，但它导致active_days的分布整体左偏，均值从3.2降到1.8。而你的模型是在旧分布上训练的，对新分布的log(1+1.8)=1.03这个值，模型从未见过，预测置信度极低。解决方法是：为每个特征建立“血缘图谱”（Lineage Graph），不仅记录它来自哪个表哪一列，更要记录其计算逻辑的哈希值、依赖的上游任务ID、以及最近一次逻辑变更时间。当特征分布发生偏移，系统能自动追溯到上游变更，判断是数据异常还是逻辑演进。

第三类：内存泄漏（Memory Leak）Bug。这在实时特征服务中尤为致命。我们曾用Python Pandas写了一个特征拼接服务，逻辑是：接收user_id，从Redis查用户基础画像，从MySQL查最近10条订单，从Kafka消费实时点击流，三者合并计算。本地测试一切正常。上线后，服务进程内存占用每小时增长200MB，12小时后OOM。根源在于Pandas的concat()操作会创建新DataFrame，而旧DataFrame的引用未被及时释放，尤其在高频请求下，GC跟不上。最终方案是：所有实时特征计算，强制使用NumPy原生数组或Cython编写的轻量级结构，彻底规避Pandas。我们用numpy.memmap管理特征向量，用cython编写订单聚合逻辑，内存占用稳定在45MB以内，且P99延迟降低40%。

3.3 模型服务瓶颈：别让GPU显存成为你系统的单点故障

模型服务常被简化为“把.pt文件扔进Triton”，但现实远比这复杂。GPU资源是ML系统里最昂贵、也最脆弱的瓶颈。我们做过一个压力测试：一个BERT-base文本分类模型，batch_size=16时，单卡QPS=120，显存占用78%；当batch_size提升到32，QPS只涨到135，但显存飙升到99%，此时任何一点额外负载（如监控探针、日志刷盘）都可能触发OOM Killer，整张卡服务中断。

这引出了服务层的核心挑战：如何在吞吐量、延迟、资源利用率、稳定性之间找到黄金平衡点？我们摸索出一套“四象限调优法”，不依赖玄学，全部基于实测数据：

特别强调一个常被忽略的点：GPU显存碎片化。Triton的Dynamic Batching虽然智能，但长期运行后，显存分配器会产生大量小块碎片，导致即使显存总量充足，也无法分配一个大batch所需的连续空间，从而触发降级到小batch甚至单请求模式，QPS断崖下跌。我们的解法是：每日凌晨4点，对所有GPU服务实例执行“优雅重启”（Graceful Restart）。重启前，先将K8s Service的Endpoint从该Pod移除，等待所有进行中的请求完成（最长30秒），再发送SIGTERM。这个操作看似简单，却让GPU服务的月度稳定性从99.2%提升到99.97%。记住，有时候最有效的“高级优化”，就是最朴实的运维纪律。

4. 实操过程与核心环节实现：一份可直接抄作业的系统搭建指南

4.1 从零开始：一个可落地的最小可行ML系统（MVP）

别被“系统”二字吓住。一个真正能跑起来、能监控、能迭代的ML系统，核心骨架其实非常精简。我给你一份我们团队验证过的、可在3天内部署上线的MVP清单，所有组件均选用成熟、轻量、易维护的方案：

基础设施层（IaC，用Terraform管理）：

• 1台c5.4xlarge（16vCPU/32GB）EC2实例，作为所有服务的统一宿主（避免K8s复杂度）
• 1个t3.smallRDS PostgreSQL实例（5GB存储），存元数据、实验记录、监控指标
• 1个StandardS3 Bucket，存模型文件、特征快照、日志归档

数据与特征层（Python + Flask + Redis）：

• 特征服务API（/features）：接收{"user_id": "u123", "timestamp": "2023-12-01T10:00:00Z"}，返回{"feature_vector": [0.23, 1.45, ...], "freshness_minutes": 1.2}
• 后端逻辑：用redis-py连接Redis Cluster，Key为feature:{user_id}:{feature_name}，Value为JSON序列化的特征值+时间戳
• 数据同步：用Airflow DAG，每5分钟执行一次SQL查询（SELECT user_id, avg_order_value FROM orders WHERE created_at > NOW() - INTERVAL '5 MINUTES'），结果写入Redis，TTL设为300秒（5分钟）

模型训练与部署层（PyTorch + Triton）：

• 训练脚本train.py：使用PyTorch Lightning，输出物为model.pt（TorchScript格式）和feature_stats.json（含各特征均值、标准差）
• Triton配置config.pbtxt：

  name: "credit_risk_model" platform: "pytorch_libtorch" max_batch_size: 32 input [ { name: "INPUT__0" data_type: TYPE_FP32 dims: [13] } ] output [ { name: "OUTPUT__0" data_type: TYPE_FP32 dims: [2] } ] instance_group [ [ { count: 1 kind: KIND_CPU } ] ]

• 注意：这里故意用CPU实例组！因为我们的模型小（13维输入），CPU推理延迟<15ms，且无需GPU运维，成本降低70%。GPU不是银弹，要按需使用。

可观测性层（Prometheus + Grafana）：

• 自研Exporter：一个Python脚本，定时调用/featuresAPI和Triton的/v2/models/credit_risk_model/stats，抓取feature_freshness_seconds、inference_latency_ms、queue_length等指标，暴露给Prometheus
• Grafana Dashboard：5个核心Panel：
  1. 特征新鲜度热力图（按用户分群）
  2. 模型推理延迟P95趋势（7天）
  3. 请求成功率（HTTP 2xx vs 5xx）
  4. Triton队列长度（实时）
  5. 特征分布偏移指数（W距离，Top 5特征）

这个MVP的成本：AWS账单约$85/月，部署时间<24人小时。它不具备“全自动CI/CD”、“多模型AB测试”等高级功能，但它具备了生产系统最核心的三要素：可重复（每次训练结果一致）、可观测（所有关键指标一目了然）、可降级（特征服务宕机时，模型服务自动fallback到默认特征向量）。先让系统活下来，再让它跑得更快、更智能。

4.2 关键配置详解：那些决定系统生死的参数

参数不是随便填的数字，每一个背后都是血泪教训。以下是我们在MVP中精心调校的几个核心参数，附上详细解释：

1. Redis特征TTL：300秒（5分钟）

• 为什么不是更长？更长的TTL意味着特征陈旧风险更高。我们业务要求“实时决策”，用户最新一笔订单必须在5分钟内影响其信用评分。
• 为什么不是更短？TTL太短会导致Redis频繁写入，增加CPU压力；同时，如果上游ETL任务偶发延迟（如网络抖动），过短的TTL会让特征短暂“消失”，服务被迫降级。
• 实测数据：TTL=300秒时，特征新鲜度达标率（<300秒）为99.98%，Redis写入QPS稳定在1200，CPU使用率<40%。TTL=120秒时，达标率降至92%，写入QPS飙升至4500，CPU峰值达95%。

2. Triton Dynamic Batchingmax_queue_delay_microseconds: 1000（1毫秒）

• 为什么不是0？max_queue_delay=0表示立即组batch，但实际中，请求到达是离散的，0延迟会导致大部分batch_size=1，完全失去batching收益。
• 为什么不是10000？10毫秒等待虽能凑出更大batch，但P95延迟会从12ms升至28ms，超出业务SLA（<20ms）。
• 实测数据：在QPS=500的压测下，delay=1000时，平均batch_size=8.3，P95延迟=14.2ms；delay=5000时，平均batch_size=12.7，P95延迟=22.8ms。1毫秒是精度与性能的最佳平衡点。

3. Prometheus抓取间隔：scrape_interval: 15s

• 为什么不是30s或60s？特征新鲜度、队列长度等指标变化快，30秒间隔会错过关键拐点。例如，特征ETL任务卡住，15秒内就能在Grafana上看到feature_freshness_seconds从120秒跳到320秒，而30秒间隔可能直接从120秒跳到620秒，错过早期干预窗口。
• 为什么不是5s？过短的间隔会给Prometheus Server带来过大压力，且多数指标在5秒内并无实质变化，属于无效噪音。
• 实测数据：15s间隔下，Prometheus Server内存占用稳定在1.2GB，CPU<30%；5s间隔下，内存飙升至3.8GB，CPU峰值达85%，且指标曲线出现大量锯齿，失去分析价值。

4.3 日常运维手册：一份写给值班工程师的Checklist

系统上线只是开始，日常运维才是真正的考验。这是我给团队制定的《ML系统值班手册》核心章节，每一条都来自真实故障复盘：

提示：每日早9点，值班工程师必须执行以下检查，耗时不超过8分钟

1. 特征新鲜度检查：登录Grafana，查看“特征新鲜度热力图”Panel。确认所有用户分群（新用户、老用户、高价值用户）的freshness_minutes均值 < 3分钟。若任一分群>5分钟，立即执行：kubectl exec -it triton-pod -- curl http://localhost:8000/v2/health/ready检查Triton状态，同时aws s3 ls s3://my-bucket/feature-sync/查看最新同步时间戳。

2. 模型服务健康检查：在终端执行：curl -s "http://triton-service:8000/v2/models/credit_risk_model/stats" | jq '.model_stats[0].inference_stats.success.count'。对比昨日同期值，下降幅度>10%即告警。同时检查queue_length，若>100，说明上游请求洪峰或下游处理瓶颈。

3. 数据漂移快速扫描：运行脚本python drift_check.py --window-days 7。该脚本自动计算过去7天与前7天5个核心特征的W距离。若任一特征W距离 > 2.0σ，生成报告并邮件通知数据科学家。

4. 日志异常关键词扫描：kubectl logs -l app=triton --since=24h | grep -E "(OOM|CUDA|timeout|NaN)" | tail -n 5。重点排查NaN（特征计算溢出）、CUDA out of memory（GPU显存不足）、timeout（上游依赖超时）。

5. 备份完整性验证：aws s3 ls s3://my-bucket/backups/ | tail -n 1确认最新备份时间在24小时内；aws s3 cp s3://my-bucket/backups/latest.tar.gz /tmp/ && tar -tzf /tmp/latest.tar.gz | head -n 5验证压缩包可解压。

注意：当遇到“特征服务返回503”时，禁止第一反应重启服务！正确流程是：

1. 先执行redis-cli --scan --pattern "feature:*"统计特征Key总数，正常应为~2.3亿；
2. 若总数骤降（如<2亿），执行redis-cli info memory | grep "used_memory_human"，确认是否内存不足；
3. 若内存>95%，执行redis-cli config set maxmemory-policy allkeys-lru临时启用LRU淘汰（治标），同时立即排查上游ETL是否在疯狂写入脏数据；
4. 若Key总数正常，执行redis-cli --latency测试Redis延迟，>5ms说明网络或Redis自身问题，需联系Infra团队。

这份手册的价值，在于把模糊的“监控告警”变成了具体的、可执行的、有时效性的动作。它不教你原理，只告诉你“此刻该敲什么命令”。这才是工程师真正需要的“生存指南”。

5. 常见问题与排查技巧实录：那些文档里永远不会写的实战经验

5.1 “模型效果在线下测试很好，但线上A/B测试没提升”——这是最痛的真相

这个问题出现频率高达73%（我们内部统计），但它绝不是“模型不行”，而是系统层面的信号污染。我给你一套完整的排查树，按顺序执行，90%的案例能在1小时内定位：

Step 1：隔离“数据管道”与“模型逻辑”

• 在线上服务中，临时注入一个“影子模式”（Shadow Mode）：对1%的流量，同时走完整线上Pipeline（特征计算+模型推理），并将原始特征向量、模型输入、模型输出、最终业务结果（如是否放款）全部记录到S3。
• 同时，用完全相同的原始特征向量，离线加载线上模型，在Jupyter中重新运行推理，记录输出。
• 关键对比：线上模型输出vs离线模型输出。如果二者差异>0.01（对于概率输出），说明模型服务层有问题（如Triton配置错误、FP16精度损失放大）；如果差异<0.01，则问题一定在特征层。

Step 2：聚焦“特征一致性”

• 对比影子模式记录的线上特征向量与离线特征向量（用相同原始数据生成）。我们发现过最隐蔽的Bug：线上特征服务用pandas.read_sql()读取MySQL，而离线脚本用sqlalchemy，两者对NULL值的处理默认不同（pandas转为np.nan，sqlalchemy转为None），导致fillna(0)行为不一致，特征向量第7维永远差一个常数。
• 解决方案：所有环境强制使用同一套特征计算SDK，封装成pip install my-feature-sdk==1.2.0，版本锁定。

Step 3：检查“评估口径”

• 线下测试用test_set.csv，线上A/B用真实用户。但test_set.csv是随机采样，而A/B流量是按用户ID哈希分流。我们曾发现：测试集里高风险用户占比12%，而A/B流量中因产品策略，高风险用户被定向导流到对照组，实验组只有5%。用AUC这种全局指标，自然看不出差异。
• 解决方案：线上A/B评估，必须分用户分群计算指标。我们新增high_risk_user_auc、low_risk_user_auc两个指标，最终发现新模型在高风险用户上AUC提升0.023，这才是真实价值。

5.2 “服务延迟突然升高，但CPU、内存、GPU都正常”——请检查你的DNS

这个坑我栽过两次，第一次花了17小时。现象：Triton服务P95延迟从12ms飙升到220ms，top看CPU<20%，nvidia-smi看GPU Util<10%，free -h看内存充足。所有常规指标都绿，但服务就是慢。

排查路径：

• curl -w "@curl-format.txt" -o /dev/null -s http://triton-service:8000/v2/health/ready：发现time_namelookup（DNS解析时间）高达210ms！