1. 项目概述：这不是一次模型训练，而是一场交付实战

“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题里藏着太多被新手忽略的潜台词。它不是在讲怎么调参、怎么画ROC曲线，也不是教你怎么用 sklearn.pipeline.Pipeline 封装几个transformer。它直指一个残酷现实：你花三周在Jupyter里跑通的模型，上线后可能连第一个API请求都扛不住；你本地验证AUC 0.92的分类器，在生产环境里因特征时间漂移，三天后准确率掉到0.65；你自信满满的Docker镜像，部署到K8s集群后因内存限制被OOMKilled，日志里只留下一行 Killed process (python) 。我做过17个从0到1落地的ML项目，其中11个在Part 3（模型验证）之后卡死，真正走到Part 4（生产运行）并稳定服务超90天的，只有6个。这组数字背后，是数据管道断裂、监控缺失、回滚机制空白、依赖版本冲突、资源配额误判等一系列“非算法”问题。Part 4的本质，是把实验室里的“科学实验”转化为工程系统里的“可靠服务”。它要求你同时懂pandas和Prometheus，会写PyTorch也得会读Kubernetes Event日志，能推导梯度下降公式，也得能看懂 kubectl describe pod 输出里 QoS Class: Burstable 意味着什么。这篇文章不提供“一键部署脚本”，而是拆解我在金融风控、电商推荐、IoT设备预测三个真实场景中踩过的坑、验证过的方案、以及那些文档里不会写的临界值——比如为什么 workers=2 比 workers=4 在CPU密集型推理中反而吞吐更高，为什么 model.predict() 在批处理时必须加 batch_size=32 而非默认的 None ，以及当特征服务返回 503 Service Unavailable 时，第一眼该盯哪个指标。如果你刚跑通 train.py ，正准备庆祝，那现在就是停下来读完这篇的最佳时机。

2. 核心设计逻辑：为什么不能直接 pip install -r requirements.txt 就上生产

2.1 从Notebook到Production的四大断层

很多团队把Part 4失败归咎于“运维不配合”或“基础设施差”，但根子在设计阶段就埋下了。我梳理出四个最关键的断层，每个都对应一个必须主动填补的工程动作：

• 代码形态断层 ：Notebook里 df['feature_x'] = df['raw_col'].str.lower().fillna('unknown') 这种链式操作，在生产里必须拆成独立、可测试、带Schema校验的transformer类。原因很简单：当 raw_col 某天突然出现 NaN 嵌套在list里（真实案例：用户上传的JSON字段含 [null, "a", null] ），Notebook里 .fillna() 静默失败，而生产pipeline必须明确抛出 DataIntegrityError 并触发告警。我坚持所有特征工程代码必须通过 pydantic.BaseModel 定义输入/输出schema，并在 __init__ 里做类型强制转换，哪怕多写10行代码——这省去了后期80%的数据血缘排查时间。

• 依赖管理断层 ：Notebook里 !pip install xgboost==1.7.5 看似精准，但生产环境需要锁定 全部 传递依赖。XGBoost 1.7.5依赖 scipy>=1.7.0,<1.10.0 ，而你的另一个组件又依赖 scipy==1.9.3 ，表面兼容，实则 scipy 的Cython编译选项在不同Python小版本下有差异，导致 import scipy.sparse 在Python 3.9.16上成功，3.9.18上段错误。解决方案是生成 pip-compile 的 requirements.in ，再用 pip-compile --generate-hashes 生成带哈希的 requirements.txt ，并强制CI检查 pip install 后 pip list --hashes 输出是否与文件完全一致。我们曾因此拦截过一次线上 scipy.linalg.eig 计算结果偏差0.0003的事故——对风控模型来说，这足够让一个高风险客户被误判为低风险。

• 资源配置断层 ：Notebook里 model.predict(X_test) 用16GB内存跑得飞快，是因为Jupyter进程独占资源。生产API服务必须预估 并发请求下的峰值内存 。公式很直接： 峰值内存 ≈ 单请求内存 × 并发数 + 模型加载开销 + OS缓存 。单请求内存不能靠 psutil.Process().memory_info().rss 测，要测 tracemalloc 跟踪 predict() 函数内部分配。我们发现某BERT文本分类模型，单次推理内存峰值达1.2GB，若按K8s默认 memory.limit=2Gi 部署， concurrency=2 就会OOM。最终方案是：用 torch.compile(model, dynamic=True) 降低显存占用，同时将 concurrency 硬限为1，用水平扩缩（HPA）替代垂直扩缩——这牺牲了单实例吞吐，但换来99.99%的可用性。

• 可观测性断层 ：Notebook里 print(f"Accuracy: {acc:.4f}") 就是全部反馈。生产里你需要三类指标： 业务指标 （如“欺诈识别延迟<200ms”）、 系统指标 （如“GPU显存使用率>90%持续5分钟”）、 模型指标 （如“特征分布偏移KS统计量>0.3”）。关键在于，这些指标必须 同源采集 ——不能前端埋点算延迟，后端日志算耗时，Prometheus再拉一次指标。我们统一用OpenTelemetry SDK，在 predict() 入口打 start_span ，在 return 前打 end_span ，自动注入trace_id，并将业务标签（如 user_tier=premium ）和模型元数据（如 model_version=20240521-v3 ）作为span attribute。这样一条请求的完整链路，从Nginx access log到GPU metrics再到特征漂移告警，都能用同一个trace_id串联。

2.2 架构选型：为什么放弃Flask，选择FastAPI+Uvicorn+Gunicorn组合

团队初期常用Flask，理由是“简单易上手”。但Part 4的压测数据彻底否定了它：在100并发、平均请求体512KB的图像分类场景下，Flask+Gunicorn（sync workers）的P95延迟飙升至1.2秒，错误率12%。根本原因是同步IO阻塞。我们对比了三种主流方案：

方案	P95延迟(100并发)	内存占用(单实例)	热重载支持	模型热更新难度
Flask+Gunicorn(sync)	1240ms	1.8GB	✅	❌（需重启worker）
FastAPI+Uvicorn	380ms	1.1GB	❌	⚠️（需信号监听+模型缓存替换）
FastAPI+Uvicorn+Gunicorn(preload)	410ms	1.3GB	✅	✅（preload模式下共享模型实例）

关键洞察在于：Uvicorn本身是ASGI服务器，但单进程无法利用多核。Gunicorn作为进程管理器，用 --preload 参数在fork worker前加载模型，使所有worker共享同一份模型内存（PyTorch的 torch.load(..., map_location='cpu') 后 model.eval() ），避免每个worker重复加载1.2GB模型。而 --workers-per-core 2 配置，让4核机器启动8个Uvicorn worker，完美匹配I/O密集型API的并发需求。实操中，我们发现 --limit-concurrency 100 比默认值更关键——它限制每个worker同时处理的请求数，防止某个慢请求（如大图上传）阻塞整个worker。这个参数必须根据 predict() 的P99耗时动态计算：若P99=300ms，则 limit-concurrency = 1000ms / 300ms ≈ 3 ，再乘以worker数得到全局并发上限。我们曾因忽略此参数，导致突发流量下所有worker被长请求占满，新请求排队超时，触发上游熔断。

2.3 模型服务化：为什么不用Seldon或KServe，而手写轻量级服务

Seldon和KServe功能强大，但它们的抽象层级太高。当我们需要在预测前插入 实时特征计算 （如“用户过去1小时点击率”）和 预测后业务规则 （如“对VIP用户放宽阈值0.1”）时，Seldon的 Transformer 和 Router 配置变得极其臃肿。更致命的是调试成本：一个500错误，你要查Seldon Operator日志、 predictor 容器日志、 transformer 日志，三层trace ID嵌套。我们选择手写服务，核心就三个模块：

• FeatureService ：独立HTTP服务，接收 user_id 和 timestamp ，返回 {feature_1: 0.85, feature_2: 12} 。用Redis Sorted Set存用户行为流， ZRANGEBYSCORE 实时聚合，P99<50ms。
• ModelRunner ：核心预测模块，封装 model.predict() ，强制输入为 numpy.ndarray ，输出为 Dict[str, float] ，所有类型转换在边界完成。
• BusinessRuleEngine ：纯Python函数，接收 model_output 和 request_context （含用户等级、设备类型等），返回最终决策。规则用 jsonschema 校验，变更需走GitOps流程。

三者通过 httpx.AsyncClient 异步调用，用 asyncio.gather() 并发请求特征和模型，再串行执行规则。整个链路耗时可控，且每个模块可独立压测。当 FeatureService 超时， ModelRunner 能降级为使用缓存特征（ redis.get("feat_cache:user_123") ），保证基础服务可用。这种“乐高式”架构，让我们在两周内就完成了从风控模型到反作弊模型的服务复用——只需替换 ModelRunner 实现，其他模块零修改。

3. 实操细节：从代码提交到Pod就绪的17个关键步骤

3.1 代码仓库结构：为什么 src/ 目录下必须有 model/ 、 features/ 、 api/ 三个平行包

混乱的目录结构是生产事故的温床。我见过最典型的反模式是： notebooks/train_model.ipynb 、 scripts/deploy.sh 、 models/best_model.pkl 混在根目录。当需要升级特征工程逻辑时，开发者改了 notebooks/ 里的代码，却忘了同步 scripts/ 里的预处理脚本，导致训练和推理特征不一致。我们的标准结构强制隔离关注点：

src/
├── model/                 # 模型核心逻辑
│   ├── __init__.py
│   ├── trainer.py         # fit()方法，只接受X,y，不碰数据源
│   ├── predictor.py       # predict()方法，只接受X，返回numpy
│   └── artifacts/         # 保存模型、tokenizer等，由trainer.py写入
├── features/              # 特征工程
│   ├── __init__.py
│   ├── base_transformer.py # 所有transformer继承的基类，含fit/transform接口
│   ├── user_click_rate.py # 具体实现，含get_feature_names_out()
│   └── validation/        # 特征schema定义，pydantic模型
├── api/                   # 服务接口
│   ├── __init__.py
│   ├── main.py            # FastAPI app实例，路由定义
│   ├── dependencies.py    # 依赖注入，如get_model(), get_feature_service()
│   └── schemas.py         # Pydantic Request/Response模型
tests/
├── unit/                  # 单元测试，mock所有外部依赖
├── integration/           # 集成测试，启动mock特征服务
└── e2e/                   # 端到端测试，用真实模型和特征服务

关键约束有三条：

1. model/ 包 绝不导入 features/ 或 api/ ，确保模型可脱离服务独立测试；
2. features/ 包 绝不导入 model/ ，特征逻辑必须纯函数式，无状态；
3. api/ 包通过 dependencies.py 注入 model 和 features 实例，禁止在路由函数里 import src.model.predictor 。

这带来两个直接好处：一是 pytest tests/unit/model/test_predictor.py 能100%覆盖 predict() 逻辑，无需启动任何服务；二是当需要将模型集成到Spark作业时，只需 from src.model.predictor import predict ，零适配成本。我们曾用此结构，将同一个风控模型无缝接入Flink实时流和Airflow离线批处理，仅需编写不同的数据源适配器。

3.2 Docker构建：为什么基础镜像选 python:3.9-slim-bookworm 而非 nvidia/cuda:11.8.0-devel-ubuntu22.04

镜像大小和安全漏洞是生产环境的生命线。 nvidia/cuda 镜像虽方便，但其Ubuntu 22.04基础层包含大量非必要包（如 systemd 、 apt-listchanges ），扫描结果显示CVE数量超200个，且镜像体积达3.2GB。而 python:3.9-slim-bookworm 基于Debian 12，精简了90%的包，CVE<5个，体积仅120MB。关键是如何在精简镜像里装CUDA？答案是 分层构建 ：

# 构建阶段：用完整CUDA镜像编译依赖
FROM nvidia/cuda:11.8.0-devel-ubuntu22.04 AS builder
RUN apt-get update && apt-get install -y python3-dev
COPY requirements.txt .
RUN pip install --no-cache-dir --prefix /install torch==2.0.1+cu118 torchvision==0.15.2+cu118 -f https://download.pytorch.org/whl/torch_stable.html
RUN pip install --no-cache-dir --prefix /install -r requirements.txt

# 运行阶段：用slim镜像，只复制编译好的包
FROM python:3.9-slim-bookworm
# 复制builder阶段安装的包
COPY --from=builder /install /usr/local
# 复制应用代码
COPY src/ /app/src/
WORKDIR /app
# 创建非root用户
RUN addgroup -g 1001 -f mlgroup && adduser -S mluser -u 1001
USER mluser
CMD ["uvicorn", "src.api.main:app", "--host", "0.0.0.0:8000", "--port", "8000"]

此方案使最终镜像体积降至850MB（含模型权重），且通过 trivy image --severity CRITICAL my-model:latest 扫描，零高危漏洞。更重要的是，它强制我们 显式声明CUDA依赖 ——如果某个包（如 faiss-gpu ）需要特定CUDA版本，必须在builder阶段明确指定，避免运行时 ImportError: libcudart.so.11.0: cannot open shared object file 。我们曾因此提前发现 lightgbm 的CUDA后端与PyTorch 2.0不兼容，将升级计划提前了三周。

3.3 Kubernetes部署：为什么 resources.limits.memory 必须设为 2.5Gi 而非 3Gi

资源请求（requests）和限制（limits）的设置，是K8s上ML服务稳定的基石。错误配置会导致两种灾难： requests 过低，Pod被调度到资源紧张节点，引发频繁抢占； limits 过高，节点资源碎片化，无法调度新Pod。我们的计算公式如下：

# 基于实测数据
单请求内存峰值 = tracemalloc测量predict()峰值 + 模型加载内存 + Python解释器开销
并发数 = (P99延迟目标 / 单请求P99耗时) × 安全系数(1.5)
总内存需求 = 单请求内存峰值 × 并发数 × 1.2（OS缓存预留）

以我们的电商推荐模型为例：

• tracemalloc 测得 predict() 峰值为420MB
• 模型加载（PyTorch）占1.1GB
• Python基础开销约80MB
  → 单请求内存峰值 = 420 + 1100 + 80 = 1600MB
• P99耗时=350ms，目标P99延迟=800ms → 并发数 = (800/350)×1.5 ≈ 3.4 → 取整为4
  → 总内存需求 = 1600 × 4 × 1.2 = 7680MB

但 limits.memory=7680Mi 是错的！因为K8s的OOMKiller触发阈值是 limits 的90%，即6912MB。而 tracemalloc 测的是Python堆内存，实际还有 mmap 分配的显存、 libc 的 malloc 碎片。我们通过 kubectl top pod 和 kubectl describe pod 观察到：当内存使用达7.2GB时，Pod开始被驱逐。最终确定 limits.memory=2.5Gi （2560MB）是安全值——等等，这远小于7680MB？是的，因为我们 用HPA水平扩缩替代垂直扩缩 。 resources.requests.memory=1.5Gi ， limits.memory=2.5Gi ，HPA规则设为 targetCPUUtilizationPercentage=60% 。当CPU使用率达60%，自动扩容Pod。实测表明，4个Pod（每个2.5Gi）比1个Pod（7.5Gi）的P99延迟低40%，且故障域更小——单个Pod宕机只影响25%流量。这个决策背后是权衡：用稍高的运维复杂度（管理多个Pod），换取极致的稳定性和弹性。

3.4 监控告警：为什么Prometheus指标名必须以 ml_ 为前缀，且包含 model_name 和 version 标签

监控不是“把Grafana面板填满”，而是建立 可归因的因果链 。当P95延迟突增，你必须在30秒内回答：是模型问题？特征服务问题？还是网络问题？我们的指标命名规范强制包含三个维度：

• 前缀 ： ml_ （区分于 http_ 、 system_ 等）
• 主体 ： inference_latency_seconds 、 feature_fetch_errors_total 、 model_drift_ks_score
• 标签 ： model_name="fraud_v2" 、 version="20240521-v3" 、 endpoint="/predict" 、 status_code="200"

例如，一个关键指标：
ml_inference_latency_seconds_bucket{le="0.2",model_name="fraud_v2",version="20240521-v3",status_code="200"}

这带来两个不可替代的价值：

1. 快速定位版本问题 ：当 version="20240521-v3" 的 le="0.2" 桶计数骤降，而 v2 正常，立即确认是新版本引入性能退化；
2. 精准关联模型漂移 ：当 ml_model_drift_ks_score{model_name="fraud_v2"} > 0.3，同时 ml_inference_latency_seconds_count{model_name="fraud_v2"} 激增，可推断是特征分布变化导致模型计算路径变长（如稀疏特征转为稠密）。

告警规则同样严格：

- alert: MLInferenceLatencyHigh
  expr: histogram_quantile(0.95, sum(rate(ml_inference_latency_seconds_bucket{model_name=~".+"}[1h])) by (le, model_name, version)) > 0.8
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "High latency for {{ $labels.model_name }} v{{ $labels.version }}"
    description: "P95 latency > 800ms for 5 minutes"

注意 for: 5m ——这是经验之谈。少于5分钟可能是瞬时抖动；超过10分钟则可能已造成业务损失。我们曾用此规则，在一次数据库主从延迟导致特征服务超时的事故中，提前3分钟发现 ml_feature_fetch_errors_total 激增，并自动触发 kubectl scale deploy feature-service --replicas=3 ，将故障影响控制在12秒内。

4. 真实故障复盘：那些让你凌晨三点爬起来的11个典型问题

4.1 问题1：模型预测结果每天上午10点准时变差，P95延迟翻倍

现象 ：监控显示，每天UTC+8 10:00-10:05， ml_inference_latency_seconds P95从320ms跳至1800ms， ml_prediction_result_accuracy 从0.912降至0.873，持续5分钟，之后自动恢复。

排查过程 ：

• 第一反应是流量洪峰，但 rate(http_requests_total{job="ml-api"}[5m]) 无异常；
• 查 node_memory_MemAvailable_bytes ，内存充足；
• kubectl top pods 发现 model-predictor Pod内存使用率在10:00瞬间从45%升至92%，然后缓慢回落；
• kubectl logs model-predictor -c model-container --since=5m | grep -i "gc\|collect" ，发现大量 GC forced 日志。

根因 ：特征服务每小时从Hive拉取一次用户画像快照，存入Redis。快照包含 user_profile 大JSON字段（平均1.2MB）。我们的 FeatureService 用 redis.get("profile:user_123") 获取，但未做 json.loads() 后的内存释放。Python的 json.loads() 会创建大量临时字符串对象，而 redis-py 的 get() 返回 bytes ， json.loads() 后若不显式 del ，GC无法及时回收。每天10:00是快照更新高峰，大量新 bytes 对象涌入，触发Full GC。

解决方案 ：

• 在 FeatureService 中， json.loads() 后立即 del raw_json_str ；
• 用 gc.set_threshold(700, 10, 10) 降低GC频率（默认是 (700, 10, 10) ，即700个新生代对象触发minor GC）；
• 最关键 ：将大JSON字段拆分为多个小key，如 redis.hgetall("profile:user_123:basic") 和 redis.hgetall("profile:user_123:behavior") ，单次获取数据量<100KB。

提示：永远不要相信“Python有GC就不用管内存”。在高吞吐服务中，GC暂停（Stop-The-World）本身就是性能杀手。用 tracemalloc 定期采样， gc.get_stats() 监控GC频率，是ML工程师的必修课。

4.2 问题2：新模型上线后，A/B测试显示转化率提升，但风控拒绝率反降5%

现象 ：A/B测试报告称，新模型（v3）相比旧模型（v2），在相同阈值下，订单转化率+2.3%，但风控系统标记的“高风险订单”比例从12.7%降至7.1%，业务方质疑模型过于宽松。

排查过程 ：

• 对比 v2 和 v3 在相同测试集上的预测概率分布： v3 整体右偏，均值从0.41升至0.53；
• 检查特征工程代码： v3 的 user_click_rate.py 新增了 window=3600 （1小时窗口），而 v2 用 window=86400 （24小时）；
• 查 feature_service 日志： v3 的特征请求量是 v2 的3倍，且大量 404 Not Found ；

根因 ：新特征窗口更短，计算更频繁，但 FeatureService 的Redis缓存TTL仍设为 86400 （24小时）。当用户1小时内无新行为， v3 的 click_rate 特征返回 None ，而 v2 的 click_rate 因TTL长，仍返回旧值。模型将 None 当作0处理，导致对沉默用户的风险评估偏低。

解决方案 ：

• 特征TTL必须与窗口对齐 ： window=3600 → cache_ttl=3600+300 （+5分钟容错）；
• 模型输入强制校验 ：在 predictor.py 中， if np.isnan(X).any(): raise ValueError("NaN feature detected") ；
• 业务层兜底 ：风控策略引擎增加规则“若 click_rate 缺失，则使用 7d_avg_click_rate 替代”，而非默认0。

注意：特征漂移（Concept Drift）常被误认为模型退化。当你看到指标异常，先查特征服务的 4xx/5xx 错误率和缓存命中率，比查模型权重更有价值。

4.3 问题3：K8s滚动更新时，新Pod就绪后立即收到大量503错误

现象 ：执行 kubectl rollout restart deploy model-predictor ，新Pod状态变为 Running 且 Ready=True ，但 nginx-ingress 日志显示大量 503 ，持续约45秒。

排查过程 ：

• kubectl get endpoints model-predictor ，发现新Pod的IP已加入Endpoint列表；
• kubectl exec -it new-pod -- curl http://localhost:8000/healthz ，返回 {"status":"ok"} ；
• kubectl logs new-pod -c model-container | grep "startup" ，发现 Uvicorn started 日志在 Ready=True 后12秒才出现；

根因 ：K8s的 readinessProbe 配置为 httpGet: /healthz ，但 /healthz 端点只检查 app.state.model_loaded == True ，而模型加载（ torch.load() ）耗时32秒。 readinessProbe 在Pod启动后5秒首次探测，此时模型未加载完，返回 503 ，K8s误判Pod不健康，将其从Endpoint移除。当模型加载完， /healthz 返回 200 ，K8s重新加入Endpoint，但此时已有大量请求被Ingress转发到此Pod，而Uvicorn尚未启动，故返回 503 。

解决方案 ：

• 分离健康检查 ： /healthz 只检查进程存活（ return {"status": "ok"} ）， /readyz 检查模型加载（ return {"status": "ok", "model_loaded": app.state.model_loaded} ）；
• readinessProbe指向 /readyz ，并设置 initialDelaySeconds=40 （>模型加载最大耗时）；
• livenessProbe指向 /healthz ， periodSeconds=10 ，防进程僵死。

实操心得：永远不要让 readinessProbe 和 livenessProbe 用同一个端点。前者关乎流量接入，后者关乎进程生死，二者SLA完全不同。

4.4 问题4：GPU显存未满，但 torch.cuda.OutOfMemoryError 频发

现象 ： nvidia-smi 显示GPU显存使用率仅65%，但日志中频繁出现 CUDA out of memory. Tried to allocate 2.00 GiB 。

排查过程 ：

• nvidia-smi 的 Memory-Usage 显示 12288MiB / 16384MiB ，但 torch.cuda.memory_summary() 显示 allocated: 10.2GB, reserved: 12.8GB ；
• torch.cuda.memory_snapshot() 导出内存快照，用 torch.cuda._memory_viz.trace_plot() 可视化，发现大量 tensor 对象被 weakref 持有，未释放；
• 检查代码： predict() 中 with torch.no_grad(): output = model(input) ，但 output 被赋值给 self.last_output （类属性）用于调试。

根因 ：PyTorch的CUDA内存管理器（ caching allocator ）会预留显存块，避免频繁 cudaMalloc / cudaFree 开销。 reserved 是预留总量， allocated 是实际使用量。当 self.last_output 持有 output tensor，其 grad_fn （计算图）也被保留，即使 output 不再使用，计算图中的中间变量（如 model.layer2.weight ）仍被引用，导致显存无法释放。

解决方案 ：

• 绝对禁止 在 predict() 中将tensor赋值给实例变量或全局变量；
• 使用 output.detach().cpu().numpy() 立即转为NumPy，切断计算图；
• 在 predict() 末尾显式 del output, input ，并调用 torch.cuda.empty_cache() （仅在debug时，生产环境慎用）；
• 终极方案 ：用 torch.compile(model, fullgraph=True, dynamic=True) ，它会优化计算图，减少中间变量。

警告： torch.cuda.empty_cache() 不是万能药。它只释放未被tensor引用的显存，对被Python对象引用的显存无效。真正的解法是代码层面杜绝tensor泄漏。

4.5 问题5：模型服务在低流量时段CPU使用率100%，但无请求

现象 ： kubectl top pods 显示 model-predictor CPU使用率持续95%-100%，但 rate(http_requests_total[5m]) 为0， /metrics 中 ml_inference_latency_seconds_count 无增长。

排查过程 ：

• kubectl exec -it pod -- top -Hp ，找到高CPU线程PID；
• kubectl exec -it pod -- jstack <pid> （Java）不适用，改用 py-spy record -p <pid> -o profile.svg ；
• profile.svg 显示98%时间在 _socket.socket.recv_into ；

根因 ： FeatureService 客户端使用 httpx.AsyncClient ，但未设置 timeout 。当特征服务偶发网络抖动， httpx 的 recv_into 陷入无限等待，线程卡死。由于Uvicorn的event loop被阻塞，整个worker无法处理新请求，K8s认为Pod不健康，反复重启。

解决方案 ：

• 所有HTTP客户端必须设timeout ： httpx.AsyncClient(timeout=httpx.Timeout(5.0, connect=3.0, read=5.0, write=5.0)) ；
• 连接池复用 ： httpx.AsyncClient(limits=httpx.Limits(max_connections=100, max_keepalive_connections=20)) ；
• 熔断机制 ：用 tenacity 库包装 httpx 调用， @retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=1, max=10)) 。

经验：在ML服务中，外部依赖（特征服务、DB、缓存）的稳定性，往往比模型本身更脆弱。把90%的防御性编程花在HTTP客户端上，是最高效的投入。

5. 持续演进：Part 4之后，如何让模型服务真正“活”下去

5.1 模型版本灰度：为什么用Istio的 VirtualService 而非K8s原生 Service

K8s Service 的 spec.selector 只能做Pod标签匹配，无法实现基于请求内容的路由。而Istio VirtualService 支持Header匹配、Query参数匹配、甚至正则匹配，这对模型灰度至关重要。例如，我们想将 user_tier=premium 的流量100%切到 v3 ，其余流量90%走 v2 、10%走 v3 ，K8s原生方案需部署两套服务，用Nginx做前置路由，复杂且难维护。Istio方案简洁：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: model-predictor
spec:
  hosts:
  - model-api.example.com
  http:
  - match:
    - headers:
        user-tier:
          exact: "premium"
    route:
    - destination:
        host: model-predictor-v3
        subset: v3
      weight: 100
  - route:
    - destination:
        host: model-predictor-v2
        subset: v2
      weight: 90
    - destination:
        host: model-predictor-v3
        subset: v3
      weight: 10

关键是 subset 定义，它基于Pod标签：

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: model-predictor
spec:
  host: model-predictor-v2
  subsets:
  - name: v2
    labels:
      version: v2
  - name: v3
    labels:
      version: v3

此方案让我们实现了“按用户分层灰度”，而非粗暴的“按流量比例灰度”。当 v3 在VIP用户中表现优异，我们再逐步扩大到普通用户，全程无需修改任何应用代码，仅调整Istio配置。这降低了80%的灰度发布风险。

5.2 自动化回滚：为什么用Argo Rollouts而非 kubectl rollout undo

kubectl rollout undo 是手动操作，无法满足“自动发现-自动决策-自动执行”的闭环。Argo Rollouts的 AnalysisTemplate 能将Prometheus