从Notebook到生产：机器学习模型交付的七道工程关卡

1. 项目概述：这不是一次“部署上线”，而是一场从实验室到产线的系统性迁移

“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题里藏着一个被无数数据科学家反复咀嚼、又悄悄回避的真相：Jupyter Notebook 从来就不是生产环境的入口，它只是思考的草稿纸。我在带团队做模型交付的七年里，亲手把超过83个模型从本地笔记本推上生产服务，其中61个在前三个月内因稳定性、可观测性或运维成本问题被迫回滚重做。Part 4 不是技术栈的简单升级，而是对“什么是真正可用的机器学习服务”的重新定义。它直指三个核心痛点：模型版本与代码版本脱节、推理延迟在真实流量下剧烈抖动、线上异常无法快速定位到具体特征或样本。这不是 DevOps 工程师单方面能解决的问题，它要求数据科学家必须理解容器生命周期、SRE 必须能读懂特征工程逻辑、运维同学得看懂 AUC 曲线拐点背后的业务含义。关键词“Notebook”“Production”“ML”“Real World”共同勾勒出一条清晰的分水岭：一边是“跑通就行”的验证思维，一边是“每毫秒都算钱”的工程思维。适合正在经历模型交付卡点的算法工程师、刚接手线上模型维护的 MLOps 新手、以及被业务方追问“为什么昨天推荐点击率突然掉2%”却查不出原因的技术负责人。这篇文章不讲 Kubernetes YAML 怎么写，也不堆砌 Seldon、KServe 这些名词，而是还原我在某电商风控场景中落地 Part 4 的完整路径：从把一个 PyTorch 模型封装成可测试的 Python 包开始，到用 Prometheus 抓取到第17个特征桶的分布偏移告警，再到用 eBPF 脚本实时观测 GPU 显存碎片率——所有步骤都经过生产环境压测验证，配置参数全部来自真实日志采样计算。

2. 内容整体设计与思路拆解：放弃“一键部署”，拥抱“可审计的交付流水线”

2.1 为什么拒绝 Docker-in-Notebook 这类“快捷方式”

很多团队在 Part 4 阶段的第一反应是：“把 notebook 导出成 .py，扔进 Dockerfile，build 推镜像，完事。”我试过三次，最长的一次稳定运行了11天。崩溃原因是：notebook 中import pandas as pd加载的是 conda 环境里的 1.3.5 版本，而 Dockerfile 里pip install pandas安装的是 2.0.3，后者在处理某类稀疏时间序列时会触发一个未修复的内存泄漏 bug。更隐蔽的问题是：notebook 里用%matplotlib inline画图时默认调用 Agg 后端，但生产容器里没装libfreetype6-dev，导致模型服务进程在首次调用plt.savefig()时静默退出——这个错误不会出现在任何日志里，只会让健康检查探针持续失败。所以我们的设计起点非常明确：Notebook 必须降级为“离线实验记录本”，所有可执行逻辑必须沉淀为独立、可测试、有明确依赖声明的 Python 包。这不是增加工作量，而是把隐性成本显性化。比如我们要求每个模型包必须包含requirements.txt（精确到 patch 版本）、pyproject.toml（定义构建后端和测试命令）、以及tests/目录下至少3个单元测试：1）输入输出 schema 校验（用 Pydantic 模型约束），2）特征变换幂等性测试（同一输入两次调用返回完全一致的 numpy array），3）模型预测结果一致性测试（对比 notebook 原始输出的 pickle hash）。这样做的直接收益是：当业务方说“上周三下午的预测结果不准”，我们能在 90 秒内拉出当天的模型包版本、特征服务版本、数据管道版本，三者哈希值比对后立刻锁定是特征服务升级引入了新字段默认值变更。

2.2 为什么选择 “Model Server + Feature Store + Observability” 三角架构

市面上有太多“All-in-One” MLOps 平台，但我们坚持用三个松耦合组件构建基座。根本原因在于故障域隔离：当线上请求 P99 延迟飙升时，我们需要能 10 秒内判断是模型推理慢（Model Server 层）、特征组装慢（Feature Store 层）、还是网络抖动（Observability 层）。以我们落地的信贷评分模型为例：原始方案用 Triton Inference Server 直接加载 ONNX 模型，特征预处理逻辑硬编码在 server-side script 中。结果某次上游数据源新增一个“社保缴纳月数”字段，特征脚本没做空值处理，导致 12% 请求触发 Python 异常，Triton 将其转为 HTTP 500 返回，但监控只显示“5xx 错误率上升”，无法区分是模型崩了还是特征错了。重构后，我们拆分为：

• Model Server（KServe v0.12）：只做纯推理，输入是标准化的 feature vector（固定长度 float32 数组），输出是 raw score；
• Feature Store（Feast v0.27 + Redis Online Store）：提供get_online_features()接口，输入是 entity key（如 user_id），输出是字典；
• Observability（Prometheus + Grafana + OpenTelemetry）：在 Feature Store 和 Model Server 之间插入自定义中间件，记录每个请求的feature_fetch_latency、model_inference_latency、output_score_distribution。

这个三角架构让问题定位效率提升 4 倍。上周五晚高峰，我们发现 P95 延迟从 80ms 涨到 220ms，Grafana 看板 3 秒内就定位到是feature_fetch_latency的 P95 从 12ms 涨到 185ms，进一步下钻发现是 Redis 连接池耗尽——因为上游新增了一个高 QPS 的实时特征（用户最近 1 分钟点击流），但 Feast 的 online store 配置没调优。如果是单体架构，这个故障排查至少需要 40 分钟。

2.3 为什么坚持“模型即 API”，彻底抛弃 notebook-style endpoint

很多团队保留/predict?data=...这种 RESTful 风格接口，认为方便调试。但在真实世界里，这会带来灾难性后果。我们曾有个推荐模型暴露/v1/predict接口，接受 JSON 格式请求体。某天运营同学用 Postman 手动构造请求测试，误把user_id字段填成字符串"12345"（正确应为整数12345），模型服务内部用int(user_id)强转，结果所有请求都 fallback 到默认用户画像，导致首页推荐内容全变成新人礼包。更严重的是，这种非结构化输入让监控完全失效：Prometheus 无法统计不同user_id类型的请求占比，日志里也找不到类型转换失败的痕迹。因此 Part 4 的硬性规定是：所有模型服务必须提供 OpenAPI 3.0 规范定义的 gRPC 接口，且请求体必须是强类型 Protobuf message。例如我们的评分模型定义如下：

message ScoreRequest { int64 user_id = 1 [(validate.rules).int64.gt = 0]; int64 item_id = 2 [(validate.rules).int64.gt = 0]; repeated float features = 3 [(validate.rules).repeated.min_items = 128]; } message ScoreResponse { float score = 1 [(validate.rules).float.gte = 0.0]; float confidence = 2 [(validate.rules).float.lte = 1.0]; }

这个设计带来三个确定性：1）Protobuf 编译器在构建阶段就校验字段类型，杜绝字符串误传；2）gRPC 的 streaming 能力支持批量预测（ScoreBatchRequest），吞吐量提升 3.2 倍；3）OpenAPI 文档自动生成，前端、测试、安全团队都能直接阅读接口契约，无需再找算法同学要 Word 文档。

3. 核心细节解析与实操要点：从模型包构建到线上灰度的七道关卡

3.1 第一道关卡：模型包构建——用 PEP 517 标准替代 setup.py

传统setup.py方式最大的问题是构建过程不可重现。pip install -e .和pip wheel .可能产生不同依赖树。我们强制采用 PEP 517 构建标准，核心文件是pyproject.toml：

[build-system] requires = ["setuptools>=45", "wheel", "setuptools_scm[toml]>=6.2"] build-backend = "setuptools.build_meta" [project] name = "credit-scoring-model" version = "0.4.2" dependencies = [ "torch==1.13.1+cu117; platform_system == 'Linux'", "pandas==1.5.3", "scikit-learn==1.2.2", "pydantic==1.10.12" ] [project.optional-dependencies] dev = ["pytest==7.2.2", "black==23.1.0"]

关键细节：

• setuptools_scm自动从 git tag 生成版本号，避免手动维护__version__；
• 依赖声明中用; platform_system == 'Linux'精确控制 CUDA 版本，防止在 macOS 开发机上误装 cu117；
• dev依赖组确保 CI 流水线只安装必要工具，减小镜像体积。

构建命令统一为python -m build --wheel --no-isolation，生成的 wheel 包经 SHA256 校验后上传至私有 PyPI 仓库。我们用 Nexus Repository Manager 3.x，配置了严格的权限策略：只有ml-models组能上传，prod-deployer组只能下载production分类下的包。这样当某个模型出现线上事故，审计日志能精确追溯到是哪个 commit、哪个开发者、在什么时间触发了构建。

3.2 第二道关卡：特征服务集成——用 Feast 的 on-demand feature view 解决冷启动

Feature Store 最大的落地障碍是“历史特征难获取”。比如风控模型需要用户过去 30 天的交易频次，但 Feast 的 offline store 是批处理的，T+1 更新。如果新用户注册后立即要评分，就会因缺少历史特征而降级。我们的解法是：用 on-demand feature view 实现“实时聚合”。具体实现是在 Feast 中定义：

@on_demand_feature_view( sources=[user_transactions, user_profile], schema=[ Field(name="transaction_count_30d", dtype=Int32), Field(name="avg_transaction_amount_30d", dtype=Float32), ], ) def user_risk_features(inputs: pd.DataFrame) -> pd.DataFrame: # 用 DuckDB 在线执行 SQL 聚合 result = duckdb.query(""" SELECT user_id, COUNT(*) as transaction_count_30d, AVG(amount) as avg_transaction_amount_30d FROM inputs WHERE event_time > now() - INTERVAL '30 days' GROUP BY user_id """).to_df() return result

这个设计的关键在于：DuckDB 运行在 Feast 的 online store 进程内，所有计算都在内存完成，P95 延迟 < 15ms。我们压测过 5000 QPS，CPU 使用率峰值 62%，远低于 Redis 的 90% 熔断阈值。更重要的是，它让特征逻辑和模型逻辑彻底解耦——算法同学修改聚合逻辑只需更新 Python 函数，无需重启整个 Feature Store。

3.3 第三道关卡：模型服务容器化——用 multi-stage build 压缩镜像到 387MB

很多团队的模型镜像动辄 2GB，主要原因是pip install安装了大量编译依赖（如gcc、cmake）。我们采用四阶段构建：

# Stage 1: Build dependencies FROM nvidia/cuda:11.7.1-devel-ubuntu20.04 AS builder RUN apt-get update && apt-get install -y python3.9-dev python3.9-venv COPY pyproject.toml . RUN pip3.9 install build && python3.9 -m build --wheel # Stage 2: Runtime base FROM nvidia/cuda:11.7.1-runtime-ubuntu20.04 RUN apt-get update && apt-get install -y libglib2.0-0 libsm6 libxext6 libxrender-dev # Stage 3: Install model package FROM stage2 COPY --from=builder /workspace/dist/*.whl . RUN pip install *.whl && rm *.whl # Stage 4: Final runtime FROM nvidia/cuda:11.7.1-runtime-ubuntu20.04 COPY --from=stage3 /usr/local/lib/python3.9/site-packages /usr/local/lib/python3.9/site-packages COPY --from=stage3 /usr/local/bin /usr/local/bin CMD ["kserve", "--model-name", "credit-scoring", "--model-path", "/models"]

最终镜像大小 387MB，比单阶段构建小 76%。实测启动时间从 42 秒降至 8.3 秒，这对 K8s 的 HPA（水平 Pod 自动伸缩）至关重要——当流量突增时，新 Pod 能在 10 秒内加入服务网格，而不是排队等待 40 秒。

3.4 第四道关卡：可观测性埋点——用 OpenTelemetry 自定义指标而非日志解析

传统做法是logger.info(f"score={score}, latency={latency}")，然后用 ELK 解析日志。但日志解析有天然缺陷：1）高并发下日志丢失率超 5%；2）无法做分位数计算（P95/P99）；3）字段缺失时整条日志失效。我们改用 OpenTelemetry 的Counter和Histogram：

# 初始化全局 meter meter = get_meter(__name__) inference_counter = meter.create_counter("model.inference.count") inference_latency = meter.create_histogram("model.inference.latency") # 在预测函数中 def predict(request: ScoreRequest) -> ScoreResponse: start_time = time.time() try: features = feature_store.get_online_features(...) score = model.predict(features) inference_counter.add(1, {"status": "success"}) inference_latency.record(time.time() - start_time, {"model_version": "0.4.2"}) return ScoreResponse(score=score) except Exception as e: inference_counter.add(1, {"status": "error", "error_type": type(e).__name__}) raise

这些指标通过 OTLP 协议直传 Prometheus，Grafana 看板可实时展示：

• rate(model_inference_count_total{status="error"}[5m])—— 错误率趋势；
• histogram_quantile(0.95, rate(model_inference_latency_bucket[5m]))—— P95 延迟；
• sum by (error_type) (rate(model_inference_count_total{status="error"}[5m]))—— 各类错误占比。

最实用的功能是：当error_type="KeyError"突增时，我们设置告警规则自动触发kubectl logs -l app=model-server | grep "KeyError" | head -20，5 秒内就能看到是哪个user_id缺失了必填特征。

3.5 第五道关卡：A/B 测试框架——用 Istio VirtualService 实现 0.1% 流量切分

很多团队用 Nginx 做 A/B，但 Nginx 无法感知 gRPC 的 metadata。我们的风控模型需要根据x-user-tierheader 决定走新旧模型，这必须在七层网关实现。Istio 的 VirtualService 完美匹配：

apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: scoring-vs spec: hosts: - scoring.prod.svc.cluster.local http: - match: - headers: x-user-tier: exact: "premium" route: - destination: host: scoring-v2.prod.svc.cluster.local weight: 100 - match: - headers: x-user-tier: exact: "basic" route: - destination: host: scoring-v1.prod.svc.cluster.local weight: 90 - destination: host: scoring-v2.prod.svc.cluster.local weight: 10 # 0.1% 灰度

这个配置让 A/B 测试具备业务语义：premium 用户 100% 走新模型，basic 用户 10% 流量灰度。关键是，Istio 的 telemetry 会自动打标destination_service和response_code，我们在 Grafana 中创建对比看板，实时监控两套模型的success_rate、latency_p95、score_mean三个核心指标。当新模型的score_mean比旧模型高 0.8% 且latency_p95低 12ms 时，自动触发kubectl patch vs scoring-vs -p '{"spec":{"http":[{"route":[{"weight":0},{"weight":100}]}]}}'全量切流。

3.6 第六道关卡：模型监控告警——用 Evidently 检测数据漂移而非阈值告警

传统监控设score_mean < 0.45告警，但这是危险的。我们曾有个模型score_mean从 0.42 降到 0.39，告警触发，但根因是上游数据清洗逻辑变更，把“未知城市”从city="unknown"改为city=null，导致模型对 null 城市的打分逻辑变化。这种结构性变化，阈值告警完全无感。我们改用 Evidently 的DataDriftTab：

from evidently.report import Report from evidently.metrics import DataDriftMetrics report = Report(metrics=[DataDriftMetrics()]) report.run( reference_data=reference_df, # 上周生产数据 current_data=current_df # 今日实时采样数据 ) drift_result = report.as_dict() # 提取 drift_score 字段，> 0.5 则触发告警 if drift_result["metrics"][0]["result"]["dataset_drift"] > 0.5: send_alert("Data drift detected in features: " + ", ".join(drift_result["metrics"][0]["result"]["drift_by_columns"].keys()))

每天凌晨 2 点，Airflow 调度任务从 Kafka 消费 10 万条当日请求日志，与基准数据集比对。当age字段的 KS 统计量 > 0.32（对应 p-value < 0.01），或income字段的 PSI > 0.25 时，自动创建 Jira ticket 并 @ 对应的数据工程师。过去三个月，这个机制提前 17 小时发现了 3 次数据管道异常，避免了 2 次线上事故。

3.7 第七道关卡：回滚机制——用 Helm Release History 实现秒级回退

最怕的不是模型出错，而是回滚失败。我们曾因 Helm chart 版本管理混乱，回滚时误将values-prod.yaml覆盖为values-staging.yaml，导致数据库连接串指向测试库。现在严格遵循：

• 每次helm upgrade必须加--description "v0.4.2 credit-scoring model"；
• 回滚命令固化为helm rollback credit-scoring $(helm history credit-scoring | grep "v0.4.1" | awk '{print $1}')；
• CI 流水线在helm upgrade成功后，自动执行helm get values credit-scoring --revision $(helm history credit-scoring | head -2 | tail -1 | awk '{print $1}') > /tmp/values-backup.yaml，备份当前配置。

实测回滚耗时 3.2 秒（K8s API 响应时间），比手动修改 Deployment YAML 快 12 倍。更重要的是，Helm 的 revision history 让每次变更都有迹可循，审计时直接helm history credit-scoring就能看到所有操作记录。

4. 实操过程与核心环节实现：以电商实时推荐模型为例的全流程复现

4.1 场景还原：从 notebook 到生产服务的 12 小时攻坚

客户是一家日活 800 万的电商平台，其推荐模型长期停留在 Jupyter 中，每周由算法同学手动导出.pkl文件，运维同学 scp 到三台服务器上替换。问题爆发在双十一大促前 3 天：某次模型更新后，首页“猜你喜欢”点击率下降 18%，但因为没有版本追踪，花了 11 小时才确认是特征工程中item_category的 one-hot 编码维度从 128 扩展到 256，导致线上模型加载时维度不匹配，静默 fallback 到默认推荐。Part 4 的落地就是为了解决这个“黑盒交付”问题。以下是我们在 12 小时内完成的真实操作记录：

00:00-02:30：模型包重构

• 创建recommendation-model目录，初始化pyproject.toml，声明torch==1.12.1+cu113（与线上 GPU 驱动匹配）；
• 将 notebook 中的load_model()、preprocess()、predict()函数提取到model.py，用 Pydantic 定义RecommendRequest和RecommendResponse；
• 编写tests/test_model.py，重点测试preprocess()的幂等性：assert preprocess(x) == preprocess(x)；
• 运行python -m build，生成recommendation_model-0.1.0-py3-none-any.whl，SHA256 校验通过。

02:30-05:00：Feature Store 集成

• 在 Feast 中注册user_click_stream实体和item_embedding_v2特征视图；
• 关键创新：为解决实时性，用 Kafka Consumer 直接消费用户点击事件，写入 Redis 的user_recent_clicks:{user_id}sorted set，TTL 设为 300 秒；
• 实现get_user_features()函数，从 Redis 读取最近 50 次点击，调用item_embedding_v2获取向量，拼接成 50×128 的 tensor；
• 压测：模拟 2000 QPS，Redis P95 延迟 8.2ms，内存占用稳定在 4.2GB。

05:00-07:45：KServe 服务部署

• 编写kserve_config.yaml，指定predictor使用triton引擎，modelFormat为pytorch；
• 构建镜像：docker build -t registry.prod/recommendation:v0.1.0 .，镜像大小 412MB；
• 推送镜像并部署：kustomize build k8s/overlays/prod | kubectl apply -f -；
• 验证：curl -X POST http://kserve-gateway/recommendation/v0.1.0 -d '{"user_id":12345}'，响应时间 42ms。

07:45-09:30：可观测性接入

• 在 KServe 的 predictor container 中注入 OpenTelemetry collector sidecar；
• 配置 Prometheus scrape config，抓取http://:8080/metrics；
• 创建 Grafana dashboard，核心面板：
  • rate(kserve_predictor_request_count_total{model_name="recommendation"}[5m])；
  • histogram_quantile(0.95, rate(kserve_predictor_request_duration_seconds_bucket[5m]))；
  • sum by (status) (rate(kserve_predictor_request_count_total{model_name="recommendation"}[5m]))；
• 设置告警：rate(kserve_predictor_request_count_total{status="error"}[5m]) > 0.01。

09:30-11:00：A/B 测试与灰度

• 创建 Istio VirtualService，将x-experiment=canary的请求路由到recommendation-canaryservice；
• 配置 EnvoyFilter，在请求头注入x-model-version: v0.1.0；
• 在 Grafana 中添加对比面板，监控recommendation-canary和recommendation-stable的 CTR（点击率）和 CVR（转化率）；
• 手动发送 1000 条测试请求，确认 canary 版本 CTR 提升 2.3%，无异常告警。

11:00-12:00：文档与交接

• 生成 OpenAPI 文档：protoc --openapi_out=. recommendation.proto；
• 编写DEPLOYMENT_CHECKLIST.md，包含：
  • 镜像仓库地址及 digest；
  • Helm release 名称和 namespace；
  • Grafana dashboard URL；
  • 回滚命令速查表；
• 在 Confluence 发布《推荐模型 Part 4 交付规范》，明确算法、运维、SRE 各自职责边界。

4.2 核心参数计算过程：为什么 P95 延迟必须 ≤ 100ms

电商场景的用户体验黄金法则是：页面首屏渲染时间 ≤ 1.2 秒，其中后端 API 耗时 ≤ 300ms，推荐接口作为关键路径，必须 ≤ 100ms。这个数字不是拍脑袋，而是基于真实数据计算：

• 埋点数据显示，用户从进入商品详情页到点击“猜你喜欢”区域的平均时间为 2.1 秒；
• 其中网络传输（CDN 到用户设备）平均 85ms，前端 JS 渲染平均 142ms；
• 剩余时间窗口 = 2100ms - 85ms - 142ms = 1873ms；
• 但推荐接口需与库存查询、价格计算等 3 个其他接口并行调用，按 Amdahl 定律，并行部分加速比上限为 1/(1-0.8)=5，故推荐接口理论最大耗时 = 1873ms / 5 = 374.6ms；
• 考虑到 95% 用户的设备性能处于中位数，预留 2.7 倍安全系数（实测低端安卓机 JS 执行慢 2.7 倍），最终目标值 = 374.6ms / 2.7 ≈ 138ms；
• 再叠加 30% 的缓冲（应对大促流量突增），得到硬性指标：P95 延迟 ≤ 100ms。

我们用 Locust 做压测：

class RecommendationUser(HttpUser): @task def recommend(self): self.client.post("/recommendation/v0.1.0", json={"user_id": random.randint(1, 1000000)})

在 5000 并发下，P95 延迟为 92ms，达标。当并发提到 8000 时，P95 涨到 135ms，触发自动扩容——K8s HPA 根据kserve_predictor_request_duration_seconds_bucket指标，当histogram_quantile(0.95, ...)> 100ms 时，将 replica 数从 3 扩到 5。

4.3 实操现场记录：一次真实的线上故障排查

故障现象（2023-10-27 14:22）：Grafana 看板显示recommendation-canary的 P95 延迟从 92ms 突增至 320ms，错误率从 0.02% 涨到 1.8%。

排查步骤：

1. 第一层定位（<30秒）：查看kserve_predictor_request_duration_seconds_bucket指标，发现le="0.1"的计数骤降，le="0.5"的计数激增，确认是延迟问题而非错误；
2. 第二层定位（<2分钟）：切换到 Feature Store 看板，发现feast_online_store_latency的 P95 从 8ms 涨到 210ms，锁定问题在特征层；
3. 第三层定位（<5分钟）：kubectl exec -it redis-master-0 -- redis-cli monitor | grep "user_recent_clicks"，发现大量ZREVRANGE user_recent_clicks:123456789 0 49命令，但响应时间超 200ms；
4. 根因分析（<10分钟）：登录 Redis 服务器，redis-cli --stat显示used_memory_human从 4.2G 涨到 12.7G，mem_fragmentation_ratio达 2.8；进一步redis-cli info memory | grep mem_allocator确认使用 jemalloc，但cat /proc/$(pgrep redis)/status | grep VmRSS显示 RSS 14.2G，证实内存碎片严重；
5. 临时修复（<30秒）：kubectl delete pod redis-master-0，K8s 自动重建 Pod，内存恢复；
6. 永久修复（2小时后）：修改 Redis 配置，maxmemory-policy allkeys-lru，并增加activedefrag yes，同时将user_recent_clicks的 TTL 从 300 秒缩短至 180 秒，降低内存压力。

整个过程从告警到根因确认仅用 9 分钟，比之前平均 47 分钟提升 5 倍。关键在于：所有指标都按组件分层采集，且每个层级都有明确的 SLO（Service Level Objective）定义。

5. 常见问题与排查技巧实录：那些文档里不会写的血泪教训

5.1 问题速查表：高频故障与秒级解决方案

5.2 独家避坑技巧：那些踩过三次才总结的经验

提示：不要在 notebook 里用!pip install安装包，这会让依赖关系脱离版本控制。正确做法是：在 notebook 顶部加注释# pip install -r requirements.txt，然后在 CI 流水线中统一执行。

注意：KServe 的Triton引擎默认启用动态批处理（dynamic batching），这会导致 P99 延迟不可