Inference与Prediction的本质区别：从机器学习工程实践看系统层与算法层的分界

在机器学习工程实践中，我几乎每天都会听到同事把“inference”和“prediction”混着用——比如在模型上线评审会上有人说“我们下周做模型 inference”，结果打开代码发现他实际调的是model.predict()；又或者在写技术文档时，把“实时 inference 延迟”写成“prediction latency”，结果被 SRE 团队追问：“你指的到底是请求处理链路中的哪一环？”这种术语误用看似微小，却会在跨职能协作中引发真实代价：部署失败、监控指标错配、A/B 实验归因偏差，甚至影响模型迭代节奏。Inference 与 prediction 并非同义替换词，而是分别锚定在系统架构层与算法语义层的两个不可互换的概念。它们的混淆，本质上是把“模型如何被使用”和“模型输出什么”混为一谈。本文不讲教科书定义，而是从我过去八年亲手交付的 37 个生产级 ML 系统（覆盖推荐、风控、IoT 设备端推理、医疗影像辅助诊断等场景）出发，用真实日志片段、部署拓扑图、API 响应体结构和线上问题排查记录，一层层剥开这两个词背后的技术契约、工程边界与协作约定。如果你正在写模型服务文档、设计 MLOps 流水线、评审模型上线方案，或只是想搞清楚为什么你的 Flask 接口返回了{"prediction": 0.82}却被平台团队要求改成{"inference_result": {"score": 0.82, "class_id": 3, "latency_ms": 14.7}}——那这篇就是为你写的。它不面向理论研究者，而面向每天要让模型在 Kubernetes 集群里稳定跑满 99.99% SLA 的工程师、MLOps 工程师、数据科学家和算法产品经理。

1. 概念本质解构：不是语义差异，而是分层契约

1.1 Inference 是一个系统行为，Prediction 是一个数学输出

这是最根本的区分点，但恰恰是多数人跳过的起点。我们先看一个真实案例：去年为某三甲医院部署肺结节良恶性判别模型时，临床科室提的需求原文是：“希望医生在 PACS 系统里点击一张 CT 图，3 秒内看到 prediction 结果”。我们团队按此开发，上线后却被叫停——不是模型不准，而是 PACS 厂商集成失败。复盘发现：PACS 要求所有第三方 AI 服务必须提供符合 DICOM-SR（结构化报告）标准的 inference response，而我们返回的纯 JSON{ "prediction": "malignant", "confidence": 0.93 }不满足其 schema 校验。这里的关键矛盾在于：临床说的 “prediction” 指的是“模型对这张图的判断结论”，而 PACS 系统要求的 “inference” 指的是“一次符合医疗设备互操作规范的完整服务调用行为”，它必须包含元数据（患者 ID、检查时间、设备型号）、输入哈希（确保可追溯）、输出结构（DICOM-SR 兼容格式）、审计字段（调用者、时间戳、版本号）以及错误处理机制（如图像质量不达标时返回INFER_STATUS_QUALITY_REJECTED而非抛异常）。

提示：Inference 的核心是上下文完备性—— 它必须能独立回答五个问题：谁发起的？输入是什么（且可验证）？在什么环境/版本下执行的？输出是否带置信度与不确定性量化？失败时能否准确定位到环节（预处理？模型加载？GPU 内存溢出？）？Prediction 只负责回答第六个问题：这个输入，模型算出来是什么？

再看一个工程侧的例子。我们在某电商实时推荐系统中，将同一个 LightGBM 模型同时用于两种场景：

• 场景 A：离线批量生成用户兴趣向量，供下游召回模块使用；
• 场景 B：在线 API 接收单条用户行为流，实时返回 top-5 商品 ID。

两个场景用的都是model.predict_proba(X)，但我们的服务命名、监控指标、告警策略、资源配额全部不同：

• 场景 A 的服务叫batch-inference-service，SLA 是“每日 6:00 前完成，延迟容忍 2 小时”，监控重点是inference_job_duration_seconds和input_data_quality_score；
• 场景 B 的服务叫realtime-prediction-api，SLA 是“P99 < 120ms”，监控重点是prediction_latency_p99_ms、prediction_error_rate和gpu_utilization_percent。

注意这里命名的刻意区分：我们坚持用 “inference” 描述批处理任务（强调其作为数据管道中一个有状态、可重试、需审计的作业），而用 “prediction” 描述在线服务（强调其作为低延迟、无状态、高并发的函数式计算）。这不是文字游戏，而是直接映射到 Kubernetes 的 HPA（Horizontal Pod Autoscaler）配置逻辑——批处理服务按 job completion rate 扩缩容，实时服务按 request per second 扩缩容。

1.2 为什么教科书和论文里常混用？——学术语境 vs. 工程语境的断裂

Alexandros Zenonos 博士原文提到“很多人混淆”，这非常准确，但原因需要深挖。在学术论文中，prediction几乎是唯一用词，例如：“Our model achieves 92.3% prediction accuracy on the test set”。这是因为论文关注的是算法输出与真实标签的映射关系，其隐含假设是：输入已清洗、特征已工程化、模型已加载、计算资源无限——所有这些“现实约束”被抽象掉了。此时，“prediction” 就是数学意义上的函数映射：f(x) → y。

而 in production，inference 是 f(x) → y 这个映射发生时所依赖的整个物理载体。它包括：

• 输入侧：HTTP 请求解析、gRPC 序列化反序列化、TensorRT 张量内存对齐、OpenVINO 预处理流水线；
• 计算侧：CUDA kernel launch、模型参数分片加载（如 DeepSpeed 的 ZeRO-3）、动态批处理（dynamic batching）的等待超时控制；
• 输出侧：JSON Schema 校验、Prometheus metrics 打点、OpenTelemetry trace 注入、响应压缩（gzip/brotli）；
• 全局侧：模型版本路由（canary rollout）、流量镜像（traffic mirroring）、异常请求自动采样（error-triggered sampling）。

举个具体参数对比：某 NLP 分类模型在 PyTorch 中model(input_ids, attention_mask)返回 logits，这是 prediction；而当它被封装进 Triton Inference Server 时，你配置的config.pbtxt文件中必须声明：

instance_group [ [ { kind: KIND_CPU count: 2 }, { kind: KIND_GPU count: 1 gpus: [0] } ] ]

这个配置本身，就是 inference 行为的契约化定义——它决定了模型以何种硬件资源、何种并行模式、何种生命周期管理方式对外提供服务。Prediction 不关心这些；inference 的全部意义，就在于精确刻画这些。

1.3 术语混淆带来的真实代价：三个血泪案例

我整理了近三年团队踩过的坑，按严重程度排序：

案例一：A/B 实验归因失效（P0 级事故）
背景：推荐算法团队上线新排序模型，A/B 实验显示新模型 CTR +2.1%，但业务方质疑：为什么 GMV 没涨？
根因分析：实验平台埋点逻辑是track_prediction_event(user_id, item_id, score)，但实际服务中，由于缓存策略（Redis 缓存了前 1000 个用户的 prediction 结果），同一 user-item 对在 5 分钟内多次请求返回完全相同的 score，导致实验平台误判为“用户对 item 的偏好稳定”，而实际上用户只是没刷出新结果。真正的 inference 行为（即模型实际计算）只发生在缓存未命中时，但实验没采集inference_cache_hit_ratio和inference_compute_count这两个关键指标。修复方案：在服务中新增inference_execution_log日志流，强制记录每次真实计算的输入指纹、耗时、GPU 显存占用，并与 prediction 埋点做 join 分析。

案例二：模型回滚失败（P1 级故障）
背景：风控模型 v2.3 上线后，资损率突增 0.8%。运维执行回滚至 v2.2，但流量切回后资损仍在上升。
根因：v2.2 版本的 inference service 镜像中，预处理模块（feature engineering）仍引用 v2.3 的特征仓库 schema，导致部分特征值被错误填充为 null，进而触发 fallback 逻辑返回默认高风险分。而 prediction 层面，v2.2 模型本身完全正确。问题出在 inference 的“输入契约”未版本化——模型版本号 ≠ inference service 版本号 ≠ feature schema 版本号。解决方案：推行 “inference contract versioning”，每个 inference service release 必须绑定三元组：(model_version, feature_schema_version, preprocessing_code_hash)，并通过 CI/CD 流水线强制校验一致性。

案例三：跨云迁移性能断崖（P2 级隐患）
背景：将某 CV 模型从 AWS EC2 迁移至阿里云 ECS，相同实例规格（g4dn.xlarge），inference P99 延迟从 45ms 涨到 180ms。
根因：AWS 的 CUDA 驱动针对 Tesla T4 优化了 TensorRT 的 kernel fusion，而阿里云的驱动版本未启用同等优化；更隐蔽的是，EC2 的nvmeSSD 读取模型权重文件速度比阿里云云盘快 3.2 倍，导致模型 warmup 阶段 inference 初始化延迟激增。prediction 计算本身（GPU kernel 执行）耗时仅差 2ms，但整个 inference 生命周期（从 HTTP request 到 response）被拖垮。这再次证明：inference 是端到端链路，prediction 只是其中一环。

这三个案例共同指向一个结论：当你在文档、会议、代码注释中随意混用这两个词时，你实际上是在模糊责任边界——是算法团队该优化 prediction 准确率，还是 infra 团队该优化 inference 延迟？是 MLOps 团队该保障 inference 可观测性，还是数据团队该校验 prediction 输入质量？

2. 工程落地全景图：从代码到监控的完整链条

2.1 代码层：函数签名、返回结构与异常分类的显式分离

在 Python 生态中，绝大多数框架（scikit-learn、XGBoost、PyTorch、TensorFlow）的.predict()方法返回的都是 pure prediction——一个 numpy array 或 tensor。这是合理的，因为框架只负责数学计算。但一旦进入服务化阶段，我们必须主动构建 inference wrapper。以下是我们团队的标准实践：

# ✅ 正确：inference service 的核心入口（FastAPI） @app.post("/v1/inference") async def run_inference( request: InferenceRequest # 自定义 Pydantic 模型，含 input_data, model_version, trace_id ) -> InferenceResponse: # 强制返回结构化响应 try: # Step 1: Input validation & preprocessing (part of inference) validated_input = await validate_and_preprocess(request.input_data) # Step 2: Model loading with version pinning (part of inference) model = load_model(request.model_version) # Step 3: Actual prediction (the math) prediction_result = model.predict(validated_input) # Step 4: Post-processing & uncertainty quantification (part of inference) final_output = postprocess_prediction( prediction_result, confidence_threshold=0.7, calibration_curve=request.calibration_curve # 可选参数 ) # Step 5: Build full inference response (with audit fields) return InferenceResponse( status="success", result=final_output, metadata=InferenceMetadata( model_version=request.model_version, input_hash=hash_input(request.input_data), compute_time_ms=round(time.time() - start_time, 3), gpu_memory_used_mb=get_gpu_memory_usage(), trace_id=request.trace_id ) ) except ValidationError as e: # Input-level error: part of inference contract violation return InferenceResponse( status="input_validation_failed", error=str(e), metadata=InferenceMetadata(trace_id=request.trace_id) ) except ModelLoadError as e: # Infrastructure-level error: inference environment failure return InferenceResponse( status="model_load_failed", error=f"Failed to load {request.model_version}: {str(e)}", metadata=InferenceMetadata(trace_id=request.trace_id) ) except Exception as e: # Unhandled error: must be logged for root cause analysis logger.error(f"Inference failed for trace_id={request.trace_id}", exc_info=True) return InferenceResponse( status="internal_error", error="Service unavailable", metadata=InferenceMetadata(trace_id=request.trace_id) )

关键设计点解析：

• InferenceRequest和InferenceResponse是领域模型，而非框架原生对象。它们的存在本身就是对 inference 行为的契约化；
• prediction_result = model.predict(...)这一行，是整个函数中唯一与 prediction 直接相关的代码，它被严格包裹在 try 块内，且不暴露给外部；
• 异常被分为三类：ValidationError（输入契约破坏）、ModelLoadError（基础设施失败）、Exception（未知错误），每种对应不同的 SLA 归责主体；
• metadata字段强制包含compute_time_ms和gpu_memory_used_mb，这是 inference 性能分析的黄金指标，而 prediction 本身无法提供这些。

对比一个反模式（我们曾在线上见过）：

# ❌ 危险：模糊边界 def predict_handler(request): # 直接调用框架 predict，无输入校验、无版本控制、无元数据 model = load_latest_model() result = model.predict(request.data) return {"prediction": result.tolist()} # 返回裸 prediction，无上下文

这种写法在 PoC 阶段可行，但一旦进入生产，就会成为事故温床——你无法回答：“这个 prediction 是哪个模型版本算的？”、“输入数据质量如何？”、“这次计算占用了多少 GPU 显存？”。

2.2 部署层：容器镜像、资源配置与服务网格的语义承载

Inference 的物理实现，最终落在 Kubernetes 的 Pod 里。我们要求每个 inference service 的 Helm chart 必须显式声明以下字段，且这些字段直接映射到业务 SLA：

特别说明inference.batch.size.max：这是 inference 层面对 prediction 计算的主动干预。一个 prediction 本身没有 batch 概念——它是单样本的数学映射。但 inference 为了提升 GPU 利用率，会将多个请求聚合成一个 batch 送入模型（NVIDIA Triton 的 dynamic batching）。这个聚合策略（如等待 10ms 或凑够 16 个请求）完全属于 inference 行为，它会导致：

• P50 延迟降低（吞吐提升）；
• P99 延迟升高（尾部请求需等待）；
• prediction 结果的时序因果性被打破（请求 A 在 t=0ms 发出，请求 B 在 t=8ms 发出，但两者在 t=12ms 同时获得结果）。

因此，在 SLA 协议中，我们必须写明：“inference P99 latency ≤ 120ms under 100 QPS and batch_size_max=32”，而不是模糊地说“prediction latency is low”。

2.3 监控层：指标体系必须反映 inference 全生命周期

我们废弃了所有以 “prediction_” 开头的监控指标，统一采用 “inference_” 前缀，并构建四级指标体系：

L1：基础可用性（SLO 核心）

• inference_request_total{status="success"}/inference_request_total{status=~"error.*"}
• inference_request_duration_seconds_bucket{le="0.1"}（直方图，用于计算 P99）
• inference_cache_hit_ratio（关键！区分真实计算与缓存返回）

L2：计算健康度（定位性能瓶颈）

• inference_gpu_utilization_percent{device="0"}
• inference_gpu_memory_used_bytes{device="0"}
• inference_model_load_duration_seconds（冷启动耗时）
• inference_preprocessing_duration_seconds（预处理耗时，常被忽略）

L3：数据质量（预防 garbage-in-garbage-out）

• inference_input_feature_distribution{feature="age", bucket="0-18"}（直方图，监控特征漂移）
• inference_input_null_ratio{feature="user_id"}（空值率突增预警）
• inference_input_outlier_count{feature="transaction_amount"}（异常值计数）

L4：业务影响（连接模型与商业目标）

• inference_business_impact_rate{impact="false_positive"}（风控场景：误拒率）
• inference_business_impact_rate{impact="false_negative"}（风控场景：漏拒率）
• inference_recommendation_coverage_rate（推荐场景：能覆盖多少用户？）

注意：所有 L3 和 L4 指标，都必须在 inference service 内部计算并上报。不能依赖下游业务系统二次加工——因为那样就丢失了 inference 的上下文（例如，不知道 false_positive 是由哪个 model_version、哪个 feature_schema 导致的）。

这套指标体系的威力，在一次大促前压力测试中得到验证：我们发现inference_preprocessing_duration_secondsP99 从 8ms 涨到 42ms，但inference_request_duration_secondsP99 仅微增。深入排查发现，是新加入的地址标准化模块（调用外部 HTTP API）未加熔断，导致预处理线程池阻塞。如果只监控 prediction 层面的model_forward_time，这个问题会被完全掩盖。

3. 实操避坑指南：来自 37 个生产系统的 12 条血泪经验

3.1 经验一：永远不要在日志中只打 prediction，必须打 inference context

新手常犯错误：在模型预测后加一行logger.info(f"Prediction: {pred}")。这在 debug 时有用，但在生产中毫无价值。正确的日志格式必须包含 inference 的五要素：

# ✅ 正确日志（JSON 格式，可被 ELK/Loki 直接索引） { "level": "INFO", "timestamp": "2024-06-15T08:23:41.223Z", "service": "recommendation-inference-service", "trace_id": "0a1b2c3d4e5f6789", "span_id": "fedcba9876543210", "inference_id": "inf-20240615-0012345", # 全局唯一 inference 实例 ID "model_version": "rec-v3.2.1", "input_hash": "sha256:abc123...", "prediction": {"item_id": "p7890", "score": 0.923}, "inference_metrics": { "preprocess_ms": 12.4, "model_forward_ms": 8.7, "postprocess_ms": 3.1, "total_ms": 24.2, "gpu_mem_mb": 1842 } }

为什么必须这样？因为线上问题 80% 无法复现。当资损发生时，你只有日志能告诉你：是不是某个特定 model_version 在特定 input_hash 下产生了异常 prediction？是不是某个 inference_id 的 total_ms 异常高，从而定位到是 GPU 显存泄漏？裸 prediction 日志连 “这是谁的请求” 都回答不了。

3.2 经验二：prediction 的不确定性必须在 inference 层量化并透出

很多团队认为 “模型输出 softmax 概率就是 uncertainty”，这是危险的简化。真实的 uncertainty 包含三类，必须在 inference service 中显式计算并返回：

我们曾在一个金融反欺诈模型中，因未透出 epistemic uncertainty，导致模型在黑产攻击初期（攻击者试探性提交少量样本）持续给出高置信度 prediction，而实际上模型对这些新攻击模式完全没见过。加入 ensemble uncertainty 后，系统自动将 high-uncertainty 请求路由至专家规则引擎，将首周资损降低了 63%。

3.3 经验三：inference 的版本管理必须是三维的，而非一维的

只管理model_version是远远不够的。我们强制实施inference version triple：

1. Model Version：模型权重与架构（如bert-base-uncased-finetuned-v2.4）；
2. Feature Schema Version：特征定义（如schema_v3.1.json，定义 age 字段为 int32，缺失值填 -1）；
3. Preprocessing Code Hash：预处理代码的 git commit hash（如a1b2c3d），因为同一 schema 下，Python 代码的int(age)和int(float(age))行为可能不同。

这三个版本必须在 inference service 启动时校验一致性。我们的校验逻辑如下：

def validate_inference_contract(model_ver, schema_ver, code_hash): # 从中央 registry 获取三元组兼容矩阵 compatibility_matrix = get_compatibility_matrix() if not compatibility_matrix.get((model_ver, schema_ver, code_hash)): raise InferenceContractViolationError( f"Invalid triple: ({model_ver}, {schema_ver}, {code_hash})" ) # 额外校验：schema_ver 必须与 model_ver 的训练时 schema 匹配 training_schema = get_training_schema_for_model(model_ver) if training_schema != schema_ver: raise SchemaMismatchError(f"Model {model_ver} trained on {training_schema}, not {schema_ver}")

这个 triple 机制让我们在一次灰度发布中避免了重大事故：v3.0 模型要求 schema_v4.0，但运维误将 schema_v3.9 部署上去，校验失败，服务启动拒绝，而非静默产生错误 prediction。

3.4 经验四：prediction 的“正确性”必须用 inference 的可观测性来定义

什么是 prediction 正确？不是 “和 label 一致”，而是 “在当前 inference 环境下，对当前输入，产生的最合理输出”。因此，我们定义了inference correctness score，它是一个加权组合：

inference_correctness_score = 0.4 * (1 - prediction_error_rate) + 0.3 * (1 - input_drift_score) + 0.2 * (1 - concept_drift_score) + 0.1 * (1 - infrastructure_stability_score)

其中：

• prediction_error_rate：与离线评估集对比的误差率；
• input_drift_score：KS 检验输入特征分布与训练集的差异；
• concept_drift_score：在线监测 prediction 分布变化（如分类模型的 class distribution entropy）；
• infrastructure_stability_score：GPU 显存泄漏率、OOM kill 次数、网络丢包率等。

这个分数每天计算，当低于 0.85 时，自动触发模型健康度报告，并建议是否需要 retrain。它把 prediction 的数学正确性，和 inference 的工程稳定性，真正统一到了一个业务可理解的指标上。

3.5 经验五：永远为 inference 设计 fallback，而非为 prediction 设计

fallback 不是 “模型挂了用规则兜底”，而是inference 链路的降级策略。我们定义了三级 fallback：

关键点：fallback 的决策必须基于 inference metrics，而非 prediction 结果。例如，不能因为 “prediction score < 0.5” 就 fallback——那是业务逻辑，不是系统可靠性问题。而应该因为inference_gpu_memory_used_bytes > 95%或inference_preprocessing_duration_seconds > 1000ms才触发。

3.6 经验六：inference 的安全边界必须比 prediction 更严格

Prediction 只涉及数学计算，而 inference 涉及系统交互，因此安全风险维度更多：

• 输入注入风险：恶意构造的input_data可能触发 pickle 反序列化漏洞（如果预处理用 pickle.load）；
• 资源耗尽风险：超大尺寸图像输入导致 GPU 显存 OOM；
• 信息泄露风险：错误地将model._parameters或梯度信息返回在 error response 中；
• 合规风险：未对输入进行 GDPR 合规脱敏（如自动删除身份证号字段）。

我们的解决方案是：在 inference ingress 层（如 Envoy Proxy）就做四重过滤：

1. Size Filter：拒绝 > 10MB 的请求体；
2. Schema Filter：用 JSON Schema 强制校验输入结构；
3. Sanitization Filter：自动 redact 敏感字段（正则匹配\d{17}[\dXx]）；
4. Rate Limit Filter：按user_id+ip限流，防暴力探测。

这些 filter 全部在 inference service 之外执行，确保即使模型代码有漏洞，攻击面也被大幅压缩。

3.7 经验七：prediction 的解释性（XAI）必须作为 inference 的标准输出项

SHAP、LIME 等解释性算法，不应在 Jupyter Notebook 里跑，而应集成到 inference service 中。我们要求所有面向业务方的 inference API，必须支持explain=true参数：

curl "https://api.example.com/v1/inference?explain=true" \ -H "Content-Type: application/json" \ -d '{"input_data": {...}}'

响应体中增加：

"explanation": { "method": "shap", "feature_importance": [ {"feature": "user_age", "contribution": 0.23}, {"feature": "last_purchase_days", "contribution": -0.18} ], "anchor_rule": "IF user_age > 35 AND last_purchase_days < 7 THEN prediction = high" }

为什么？因为业务方（如风控策略师、推荐产品经理）不关心 prediction 数值，他们关心 “为什么是这个结果”。把 XAI 作为 inference 的一部分，意味着：

• 解释性计算也受 SLA 约束（P99 < 500ms）；
• 解释结果与 prediction 同步更新（避免模型升级后解释器未同步）；
• 解释性指标（如 anchor_rule coverage）纳入监控。

3.8 经验八：inference 的测试必须覆盖全链路，而非仅 prediction 单元测试

我们废弃了所有test_model_predict()单元测试，代之以inference integration tests，运行在真实 K8s 集群的 staging 环境：

def test_inference_end_to_end(): # 1. 部署指定 model_version 的 inference service deploy_service("rec-v3.2.1", gpu_count=1) # 2. 发送真实 HTTP 请求（含 trace_id） resp = requests.post( "http://staging-rec-inference/api/v1/inference", json={"input_data": valid_user_data, "trace_id": "test-123"}, timeout=5 ) # 3. 验证全链路指标 assert resp.status_code == 200 assert resp.json()["status"] == "success" assert 0.0 <= resp.json()["result"]["score"] <= 1.0 # 4. 查询 Prometheus，验证 inference metrics 上报 metrics = query_prometheus('inference_request_total{job="rec-inference"}') assert metrics["value"] > 0 # 5. 查询 Loki，验证 inference context 日志存在 logs = query_loki('inference_id="inf-test-123"') assert len(logs) > 0 assert "preprocess_ms" in logs[0]["inference_metrics"]

这种测试能发现 90% 的集成问题：模型权重路径错误、feature schema 版本不匹配、GPU 驱动不兼容、服务网格 mTLS 配置错误等。而单元测试永远发现不了。

3.9 经验九：prediction 的 drift 检测必须基于 inference 的实时流，而非离线 batch

传统做法是每天跑一次离线 job，对比 prediction 分布。但我们发现，真正的 drift 往往发生在分钟级。例如，某次黑产攻击，攻击者在 3 分钟内提交了 2000 个高度相似的伪造身份，导致 prediction 分数集中在 0.49~0.51（故意卡在阈值边缘）。离线 job 要到第二天才发现，而实时 inference stream 检测在 47 秒内就触发了告警。

我们的实时 drift 检测架构：

• Kafka Topicinference-prediction-stream：每条消息是{"inference_id": "...", "prediction": {...}, "timestamp": ...}；
• Flink Job：窗口滑动 1 分钟，计算prediction.score的 KS statistic 与 baseline；
• 当 KS > 0.15 时，写入 AlertManager 并触发drift_analysis_job（自动拉取最近 1000 条样本做聚类，定位异常子群体）。

3.10 经验十：inference 的成本优化必须从全栈视角，而非仅 prediction 算法

很多团队花大力气剪枝、量化模型（降低 prediction 计算量），却忽视 inference 的更大成本项：

我们曾在一个视频分析服务中，将 OpenCV 的 resize 和 normalize 操作从 CPU 移到 GPU（使用 NVIDIA DALI 库），preprocessing 耗时从 18ms 降到 2.3ms，整体 inference P99 降低 41%，效果远超模型量化。

3.11 经验十一：prediction 的标签平滑（label smoothing）必须在 inference 时重放

Label smoothing 是训练技巧，但它的效果必须延续到 inference。我们发现，很多团队训练时用了 label smoothing（如smooth_factor=0.1），但 inference 时直接用原始 softmax，导致 prediction 分数过于尖锐（top-1 score 常 > 0.99），丧失了不确定性表达能力。

解决方案：在 inference service 中，对 prediction 输出应用inference-time label smoothing：

def apply_inference_smoothing(logits, smooth_factor=0.1, num_classes=10): probs = torch.softmax(logits, dim=-1) uniform = torch.ones_like(probs) / num_classes smoothed = (1 - smooth_factor) * probs + smooth_factor * uniform return smoothed

这使得 prediction 分数更