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做训练编排、用PrometheusGrafana监控服务指标。结果大促期间推荐模型的A/B测试流量切到新版本后GMV不升反降。排查三天才发现问题出在特征缓存失效逻辑上——旧版缓存key是user_iditem_idtimestamp新版为了支持实时行为流改成了user_iditem_idhour_of_day但缓存清理脚本没同步更新导致大量过期特征被复用。你看工具链再完整只要系统设计层面的耦合点没理清故障就必然发生。所以这篇概述的价值是帮你建立一套“系统级诊断思维”当问题出现时你能快速判断它属于数据层、特征层、模型层、服务层还是反馈闭环层并知道每个层级最关键的三个健康指标是什么。这才是真正能救命的能力。2. 系统设计的核心矛盾为什么“能跑通”和“能扛住”之间隔着一整个工程体系2.1 模型成功与系统失败的鸿沟从单点最优到全局稳态我们先直面一个残酷事实一个在Jupyter Notebook里完美运行的模型其成功概率与它在生产环境中稳定运行的概率几乎不相关。这不是危言耸听而是我过去八年带过的二十多个落地项目反复验证的结论。原因很简单——Notebook验证的是“静态正确性”而生产系统要求的是“动态鲁棒性”。举个具体例子你在训练时用sklearn.preprocessing.StandardScaler对数值特征做标准化fit时传入了10万条样本得到均值μ5.23、标准差σ1.87。上线后服务接收请求每条请求都用这两个固定参数做transform。表面看没问题但当某天上游数据源异常突然涌入一批用户年龄为-1数据库默认值错误或999埋点bugStandardScaler.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系统的第一设计原则是“最小必要工具集”。我们现在的新项目工具栈严格控制在四个核心组件内数据与特征层自研轻量级特征服务基于GoRocksDB放弃Feast的复杂抽象只提供get_features(user_id, timestamp)一个接口所有特征计算逻辑下沉到SQL或Python UDF版本由Git Commit Hash标识模型训练层PyTorch Lightning 自定义Callback完全绕过MLflow/Kubeflow训练脚本即服务输出物只有模型文件、特征统计快照、测试报告三样东西模型服务层Triton Inference Server但只启用HTTP/REST协议禁用gRPC和模型组合Ensemble所有预处理/后处理逻辑写在客户端可观测性层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在每次模型迭代评审会上强制展示两张表指标类型科学家关注项工程师关注项联合阈值当前值效果AUC (test)AUC (online A/B)ΔAUC 0.0030.0042性能—p95_latency (ms) 120ms98ms稳定性—error_rate (%) 0.01%0.003%成本—cost_per_inference ($) $0.0002$0.00015指标类型数据质量项特征工程项联合阈值当前值新鲜度raw_data_delay (min)feature_freshness (min) 3min2.1min一致性null_ratio (col_x)feature_distribution_drift 15%8.2%覆盖率user_coverage (%)feature_coverage (%) 99.5%99.7%这张表强制双方用同一套语言对话。当科学家提出“我要用新的时序特征”工程师立刻能评估“这个特征计算需要调用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统计量也大概率显著产生海量误报。后来我们改用一种更务实的“业务感知漂移检测法”定义关键业务特征子集不是所有特征都重要。我们只监控5个核心特征avg_session_duration_sec、click_through_rate、share_count_per_session、video_watch_ratio、search_query_length_avg。选择依据是它们与核心业务指标DAU、ARPU的相关系数绝对值0.6。计算滚动窗口偏移指数对每个特征计算过去7天与前7天的分布差异。不用KS改用Wasserstein距离Earth Movers Distance它对小样本更鲁棒且结果有物理意义单位特征值的标准差。公式为W_distance ∫|CDF_current(t) - CDF_baseline(t)| dt实际实现中我们用分位数近似将特征值划分为100个分位点计算每个分位点的值差绝对值之和再除以100。设置动态阈值阈值不是固定值而是基于历史波动率。每周一凌晨系统自动计算过去30天每个特征的W_distance标准差σ然后设定本周阈值为mean_W_distance 2*σ。这样阈值会随业务淡旺季自动调整。关联业务事件当任一特征W_distance超阈值系统不直接告警而是先查询产品日志API检查过去24小时内是否有相关功能上线、灰度发布或运营活动。如果有标记为“已知变更”仅生成分析报告如果没有才触发P2级告警并附上受影响的下游模型列表。这套方法上线后数据漂移告警准确率从32%提升到89%更重要的是它把“技术告警”转化成了“业务洞察”。工程师不再问“漂移是什么”而是能直接告诉产品经理“青少年模式上线后video_watch_ratio的W距离飙升到3.2σ说明模型对青少年用户的视频偏好预测偏差极大建议优先优化这部分特征。”3.2 特征工程陷阱那些在训练时沉默、在服务时咆哮的“幽灵Bug”特征工程是ML系统里最易被低估、也最易出问题的环节。它的危险在于绝大多数特征Bug在训练阶段完全隐形只在服务阶段集中爆发。我整理了过去踩过的三大类“幽灵Bug”每一种都曾让我们在凌晨三点被电话叫醒。第一类时间穿越Time TravelBug。这是最经典的错误。你在训练时用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 DependencyBug。你以为的独立特征其实暗藏玄机。比如一个“用户活跃度”特征定义为log(1 7day_active_days)。看起来很安全。但某天上游数据团队重构了active_days的计算逻辑从“登录即算活跃”改为“登录且有页面停留10秒才算活跃”。这个改动本身合理但它导致active_days的分布整体左偏均值从3.2降到1.8。而你的模型是在旧分布上训练的对新分布的log(11.8)1.03这个值模型从未见过预测置信度极低。解决方法是为每个特征建立“血缘图谱”Lineage Graph不仅记录它来自哪个表哪一列更要记录其计算逻辑的哈希值、依赖的上游任务ID、以及最近一次逻辑变更时间。当特征分布发生偏移系统能自动追溯到上游变更判断是数据异常还是逻辑演进。第三类内存泄漏Memory LeakBug。这在实时特征服务中尤为致命。我们曾用Python Pandas写了一个特征拼接服务逻辑是接收user_id从Redis查用户基础画像从MySQL查最近10条订单从Kafka消费实时点击流三者合并计算。本地测试一切正常。上线后服务进程内存占用每小时增长200MB12小时后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_size16时单卡QPS120显存占用78%当batch_size提升到32QPS只涨到135但显存飙升到99%此时任何一点额外负载如监控探针、日志刷盘都可能触发OOM Killer整张卡服务中断。这引出了服务层的核心挑战如何在吞吐量、延迟、资源利用率、稳定性之间找到黄金平衡点我们摸索出一套“四象限调优法”不依赖玄学全部基于实测数据调优维度可选项测试方法关键观察指标我们的实践选择Batching策略Dynamic Batching (Triton) / Static Batching / No Batching用Locust模拟不同QPS下的P95延迟、显存占用、GPU UtilBatch延迟 vs 吞吐增益曲线启用Dynamic Batching但设置max_queue_delay_microseconds10001ms避免过度等待实例部署Single Model per GPU / Multi-Model per GPU / Model Parallelism在单卡部署1/2/4个相同模型实例压测对比QPS总和、显存总占用、P95延迟单卡单模型显存预留15%给系统开销避免争抢精度优化FP32 / FP16 / INT8 Quantization使用TensorRT或Triton的量化工具对比精度损失与加速比Accuracy drop (ΔAUC), Latency reduction, GPU Util dropFP16量化AUC损失0.0008在可接受范围延迟降低35%弹性伸缩K8s HPA (CPU/Memory) / Custom Metrics (QPS, Queue Length)模拟流量脉冲观察扩缩容响应时间与服务中断扩容延迟、缩容后残留实例、服务抖动基于自定义指标triton_queue_length伸缩阈值设为50扩容延迟30秒特别强调一个常被忽略的点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.4xlarge16vCPU/32GBEC2实例作为所有服务的统一宿主避免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 ClusterKey为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结果写入RedisTTL设为300秒5分钟模型训练与部署层PyTorch Triton训练脚本train.py使用PyTorch Lightning输出物为model.ptTorchScript格式和feature_stats.json含各特征均值、标准差Triton配置config.pbtxtname: 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等指标暴露给PrometheusGrafana Dashboard5个核心Panel特征新鲜度热力图按用户分群模型推理延迟P95趋势7天请求成功率HTTP 2xx vs 5xxTriton队列长度实时特征分布偏移指数W距离Top 5特征这个MVP的成本AWS账单约$85/月部署时间24人小时。它不具备“全自动CI/CD”、“多模型AB测试”等高级功能但它具备了生产系统最核心的三要素可重复每次训练结果一致、可观测所有关键指标一目了然、可降级特征服务宕机时模型服务自动fallback到默认特征向量。先让系统活下来再让它跑得更快、更智能。4.2 关键配置详解那些决定系统生死的参数参数不是随便填的数字每一个背后都是血泪教训。以下是我们在MVP中精心调校的几个核心参数附上详细解释1. Redis特征TTL300秒5分钟为什么不是更长更长的TTL意味着特征陈旧风险更高。我们业务要求“实时决策”用户最新一笔订单必须在5分钟内影响其信用评分。为什么不是更短TTL太短会导致Redis频繁写入增加CPU压力同时如果上游ETL任务偶发延迟如网络抖动过短的TTL会让特征短暂“消失”服务被迫降级。实测数据TTL300秒时特征新鲜度达标率300秒为99.98%Redis写入QPS稳定在1200CPU使用率40%。TTL120秒时达标率降至92%写入QPS飙升至4500CPU峰值达95%。2. Triton Dynamic Batchingmax_queue_delay_microseconds: 10001毫秒为什么不是0max_queue_delay0表示立即组batch但实际中请求到达是离散的0延迟会导致大部分batch_size1完全失去batching收益。为什么不是1000010毫秒等待虽能凑出更大batch但P95延迟会从12ms升至28ms超出业务SLA20ms。实测数据在QPS500的压测下delay1000时平均batch_size8.3P95延迟14.2msdelay5000时平均batch_size12.7P95延迟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.2GBCPU30%5s间隔下内存飙升至3.8GBCPU峰值达85%且指标曲线出现大量锯齿失去分析价值。4.3 日常运维手册一份写给值班工程师的Checklist系统上线只是开始日常运维才是真正的考验。这是我给团队制定的《ML系统值班手册》核心章节每一条都来自真实故障复盘提示每日早9点值班工程师必须执行以下检查耗时不超过8分钟特征新鲜度检查登录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/查看最新同步时间戳。模型服务健康检查在终端执行curl -s http://triton-service:8000/v2/models/credit_risk_model/stats | jq .model_stats[0].inference_stats.success.count。对比昨日同期值下降幅度10%即告警。同时检查queue_length若100说明上游请求洪峰或下游处理瓶颈。数据漂移快速扫描运行脚本python drift_check.py --window-days 7。该脚本自动计算过去7天与前7天5个核心特征的W距离。若任一特征W距离 2.0σ生成报告并邮件通知数据科学家。日志异常关键词扫描kubectl logs -l apptriton --since24h | grep -E (OOM|CUDA|timeout|NaN) | tail -n 5。重点排查NaN特征计算溢出、CUDA out of memoryGPU显存不足、timeout上游依赖超时。备份完整性验证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”时禁止第一反应重启服务正确流程是先执行redis-cli --scan --pattern feature:*统计特征Key总数正常应为~2.3亿若总数骤降如2亿执行redis-cli info memory | grep used_memory_human确认是否内存不足若内存95%执行redis-cli config set maxmemory-policy allkeys-lru临时启用LRU淘汰治标同时立即排查上游ETL是否在疯狂写入脏数据若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.nansqlalchemy转为None导致fillna(0)行为不一致特征向量第7维永远差一个常数。解决方案所有环境强制使用同一套特征计算SDK封装成pip install my-feature-sdk1.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飙升到220mstop看CPU20%nvidia-smi看GPU Util10%free -h看内存充足。所有常规指标都绿但服务就是慢。排查路径curl -w curl-format.txt -o /dev/null -s http://triton-service:8000/v2/health/ready发现time_namelookupDNS解析时间高达210ms