从Jupyter到Kubernetes：机器学习模型服务化落地全链路

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

“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题里藏着一个被无数数据科学家反复咀嚼、又悄悄回避的真相：Jupyter Notebook 从来就不是生产环境的入口，它只是思考的草稿纸。我在带团队做模型交付的七年里，亲手把超过83个模型从本地笔记本推上生产服务，其中61个在前三个月内遭遇了至少一次非预期中断。真正卡住90%团队的，从来不是模型精度掉0.5%，而是当PM凌晨三点发来消息：“用户反馈推荐页白屏了，是不是你们的模型挂了？”——你翻着日志发现，问题出在模型加载时找不到那个只存在于你本机/Users/alex/data/raw/路径下的预处理字典文件。这根本不是代码bug，是环境契约的彻底失约。

Part 4 这个编号很关键。它意味着前三个部分已经覆盖了数据版本控制（DVC）、特征工程流水线（Feast或自建Feature Store）和模型训练自动化（MLflow或Kubeflow Pipelines）。而这一部分，直指所有前期努力能否落地的生死线：如何让一个在MacBook Pro上跑通的.ipynb，在Kubernetes集群里稳定、可观测、可回滚、能应对每秒2000次请求的流量洪峰，并且当它出错时，运维同事不用翻三小时日志就能定位到是特征偏移还是GPU显存泄漏。它解决的不是“能不能跑”，而是“敢不敢让老板的客户用”。适用人群非常明确：刚从Kaggle冠军转型为算法工程师的新人、正被业务方催着上线却卡在CI/CD环节的ML Team Lead、以及那些技术栈还停留在“python app.py扔进screen里跑”的小团队架构师。核心关键词——模型服务化（Model Serving）、推理性能调优、生产可观测性、灰度发布策略、资源弹性伸缩——每一个词背后都对应着真实世界里摔过的跟头和交过的学费。

我见过太多团队把精力全耗在模型结构调参上，却对服务端的gRPC连接超时设置一无所知；也见过用TensorFlow SavedModel导出的模型，在Triton推理服务器上因输入张量shape未对齐直接报INVALID_ARGUMENT，而错误日志只显示“failed to load model”，连具体哪一层出错都不提示。Part 4 的价值，正在于把这些“不写在论文里、但决定你KPI能不能达成”的硬核细节，掰开揉碎讲透。它不教你怎么设计SOTA模型，它教你如何让模型成为公司基础设施里一块沉默但可靠的砖。

2. 整体架构设计与方案选型逻辑：为什么放弃Flask，又为什么没选Seldon？

2.1 架构演进的三阶段陷阱：从“能跑”到“稳跑”的认知跃迁

很多团队的第一反应是：把Notebook里model.predict()那段代码封装成一个Flask API，Docker打包，docker run -p 5000:5000，搞定。我试过，而且不止一次。2019年我们给电商风控团队上线第一个实时反欺诈模型时，就是这么干的。结果呢？单节点QPS卡死在120，CPU利用率常年98%，一旦流量突增，Flask主线程阻塞，新请求排队等待，超时率瞬间飙到40%。更致命的是，当模型需要更新时，必须停服重启——那意味着整整3分钟内，所有支付请求都会被拒绝。业务方的电话直接打到CTO办公室。

这就是典型的“能跑”阶段：功能正确，但完全无视并发、延迟、容错。第二阶段是“能扛”，比如用Gunicorn多Worker + Nginx负载均衡，或者改用FastAPI异步IO。这确实能提升吞吐，但问题转向了新维度：模型加载内存爆炸（一个BERT-base模型加载后占3.2GB RAM，8个Worker就是25GB）、GPU显存无法共享（每个Worker独占一块GPU）、模型版本切换需滚动重启导致短暂不可用。我们曾在一个金融预测项目中，因Gunicorn Worker数配置不当，导致K8s Pod因OOMKilled频繁重启，监控图上像心电图一样起伏。

第三阶段才是“稳跑”：模型即服务（MaaS），而非模型+服务。它要求模型加载、推理、监控、扩缩容全部解耦，由专业组件各司其职。此时，选型不再是“哪个框架语法熟”，而是“谁最擅长解决我的瓶颈”。我们最终在Part 4中采用的架构是：Triton Inference Server（模型加载与推理核心） + KServe（K8s原生编排层） + Prometheus+Grafana（指标采集与可视化） + Jaeger（分布式追踪）。这个组合不是拍脑袋定的，而是踩过坑后用数据验证的。

2.2 Triton为何成为推理引擎的首选：不只是快，更是“可控”

为什么不是直接用TensorFlow Serving或TorchServe？我们做过横向压测。在相同硬件（A100 GPU x2, 32vCPU, 128GB RAM）上，对同一个ResNet-50图像分类模型（ONNX格式）进行1000并发请求测试：

Triton胜出的关键不在绝对速度，而在资源效率与运维友好性。它的核心设计哲学是“模型即配置”。你只需提供模型文件（ONNX/TensorRT/PyTorch等）、一个config.pbtxt配置文件，Triton就能自动管理模型生命周期。例如，config.pbtxt中这一段：

dynamic_batching [batch_size 32] instance_group [ [ { count: 2 kind: KIND_GPU gpus: [0] } ] ]

直接告诉Triton：启用动态批处理，最大批大小32；在GPU 0上启动2个模型实例。这意味着，当100个请求涌入时，Triton会自动将它们聚合成3-4个批次（每批32个），而不是让每个请求单独走一遍前向传播。这直接将GPU计算单元利用率从45%拉高到89%。而TF Serving的动态批处理需要手动编写C++插件，TorchServe则根本不支持跨请求批处理。

更重要的是热更新。在Triton中，你只需把新模型文件放到指定目录，修改config.pbtxt中的版本号，然后发送一个curl -X POST http://localhost:8000/v2/repository/models/{model_name}/load，几秒钟内新模型就绪，旧模型自动卸载——整个过程服务零中断。我们在某新闻推荐场景中，利用此特性实现了“模型AB测试”：同一服务端口，通过HTTP HeaderTriton-Model-Version: v2指定调用不同版本模型，A/B流量按比例分发，效果数据实时对比。这种灵活性，是其他引擎难以企及的。

2.3 KServe替代自研K8s Operator：省下的不是代码，是三年运维成本

早期我们尝试过自研K8s Operator来管理模型服务。想法很美好：定义ModelServiceCRD，Operator监听创建事件，自动部署Deployment+Service+HPA。但现实很快打脸。当需要支持Triton、TF Serving、自定义Python Backend三种后端时，Operator代码迅速膨胀到5000行，每次K8s版本升级（如1.22移除v1beta1 API），都要花两周时间适配。更麻烦的是，当某个模型服务因OOM被K8s Kill后，Operator要判断是资源不足还是模型bug，这个逻辑复杂到无法维护。

KServe（原KFServing）的出现，让我们果断砍掉了自研项目。它不是简单的CRD封装，而是一套经过大规模生产验证的、开箱即用的MLOps编排协议。它的InferenceServiceCRD天然支持多引擎、多框架、多协议（REST/gRPC）。一个典型的KServe YAML长这样：

apiVersion: "kserve.kserve.io/v1beta1" kind: "InferenceService" metadata: name: "resnet50-triton" spec: predictor: triton: storageUri: "gs://my-bucket/models/resnet50" resources: limits: nvidia.com/gpu: 1 requests: nvidia.com/gpu: 1 transformer: custom: container: image: "my-transformer:latest" env: - name: MODEL_NAME value: "resnet50"

注意transformer字段——它允许你在模型推理前/后插入任意预处理/后处理逻辑，且与模型本身解耦。比如，我们的图像模型需要先从S3 URL下载图片、解码、归一化，这些逻辑全写在my-transformer容器里，模型容器只负责纯数学计算。这种关注点分离，让模型迭代和预处理迭代可以并行推进，互不影响。KServe还内置了金丝雀发布（Canary Rollout）能力：你可以声明canaryTrafficPercent: 10，KServe会自动创建两个Service，将10%流量导向新版本，90%留在旧版本，并集成Prometheus指标自动判断新版本是否健康（如错误率<0.1%且P95延迟<旧版110%），达标后自动切全量。这个功能，我们自研花了六个月都没做到稳定，KServe一行配置搞定。

3. 核心实操环节详解：从Notebook到K8s集群的七步落地法

3.1 步骤一：Notebook代码的“外科手术式”剥离——哪些该留，哪些必须砍？

这是最容易被忽视，却最致命的一步。很多人以为“把model.predict()包成API就行”，结果把整个Notebook的依赖链都拖进了生产环境。请记住一个铁律：生产服务容器里，只应存在运行推理所必需的、且经过严格验证的代码与依赖。我们有一套清晰的剥离清单：

• 必须保留：

  • 模型加载逻辑（tritonclient.http.InferenceServerClient初始化）
  • 输入数据解析与标准化函数（如def preprocess_image(image_bytes: bytes) -> np.ndarray:）
  • 输出后处理函数（如def postprocess_output(output_tensor: np.ndarray) -> Dict[str, float]:）
  • 健康检查端点（/v1/health返回{"status": "ok", "model_version": "v2.1"}）

• 必须删除/重构：

  • 所有EDA（探索性数据分析）代码：plt.hist(),df.describe()——这些在生产里毫无意义，还引入Matplotlib等大依赖。
  • 数据获取逻辑：pd.read_csv("s3://bucket/train.csv")——生产环境数据源应由外部配置注入，而非硬编码。
  • 实验性代码：# TODO: try quantization here、if DEBUG_MODE:——DEBUG标志在生产里是定时炸弹。
  • Jupyter专属魔法命令：%timeit,%%capture——它们会让Python解释器直接报错。

实操技巧：我们强制要求所有模型服务代码必须通过pylint --disable=all --enable=import-error,unused-import,undefined-variable静态检查。任何未声明的导入（如Notebook里import seaborn as sns但服务代码里没用到）都会被拦截。这看似严苛，但避免了因seaborn依赖引发的ImportError: No module named 'PIL'这类低级故障——因为seaborn会偷偷拉取Pillow，而Pillow在Alpine Linux基础镜像里编译失败是家常便饭。

3.2 步骤二：模型格式转换与优化——ONNX不是终点，TensorRT才是临门一脚

Notebook里torch.save(model, "model.pth")出来的PyTorch模型，绝不能直接扔进生产。原因有三：格式私有（其他框架无法加载）、无量化支持（FP32精度浪费算力）、无图优化（存在冗余计算节点）。我们的标准流程是：PyTorch → ONNX → TensorRT（GPU） / ONNX Runtime（CPU）。

以一个文本分类模型为例。原始PyTorch模型在A100上单次推理耗时18ms。转换为ONNX后：

# 导出ONNX（注意dynamic_axes参数！） torch.onnx.export( model, dummy_input, "model.onnx", input_names=["input_ids", "attention_mask"], output_names=["logits"], dynamic_axes={ "input_ids": {0: "batch_size", 1: "seq_len"}, "attention_mask": {0: "batch_size", 1: "seq_len"}, "logits": {0: "batch_size"} }, opset_version=14 )

关键在dynamic_axes——它告诉ONNX运行时哪些维度是动态的（如batch_size=1或32都行）。若忽略此参数，生成的ONNX模型会将batch_size硬编码为1，后续在Triton中设置max_batch_size=32时直接报错。

ONNX模型在Triton上推理耗时降至12ms。但这还不够。我们进一步用NVIDIA TensorRT优化：

# 使用trtexec工具生成优化引擎 trtexec --onnx=model.onnx \ --saveEngine=model.plan \ --fp16 \ --workspace=2048 \ --minShapes=input_ids:1x128,attention_mask:1x128 \ --optShapes=input_ids:8x128,attention_mask:8x128 \ --maxShapes=input_ids:32x128,attention_mask:32x128

--fp16开启半精度计算，--min/opt/maxShapes定义动态形状范围。生成的model.plan引擎，在同样硬件上推理耗时锐减至6.8ms，吞吐量翻倍。更重要的是，TensorRT引擎对GPU显存使用进行了极致压缩——从ONNX的1.8GB降至0.9GB，这意味着单卡可部署的模型实例数从2个提升到4个。这个优化不是“锦上添花”，而是决定你能否用一张A100支撑起整个业务线的“雪中送炭”。

3.3 步骤三：构建最小可行镜像——Alpine + Multi-stage，体积直降80%

生产镜像大小直接影响部署速度与安全风险。一个基于ubuntu:20.04的PyTorch镜像轻松突破2GB。我们的目标是：小于300MB，且不含任何shell（/bin/sh）——杜绝攻击者通过漏洞执行任意命令。

我们采用Multi-stage构建：

# 构建阶段：安装编译依赖 FROM nvidia/cuda:11.8.0-devel-ubuntu20.04 AS builder RUN apt-get update && apt-get install -y python3-pip python3-dev COPY requirements.txt . RUN pip3 install --no-cache-dir -r requirements.txt # 运行阶段：极简Alpine FROM nvcr.io/nvidia/tensorrt:23.07-py3 AS runtime # 移除所有shell，只保留必要二进制 RUN rm -rf /bin/* /sbin/* /usr/bin/* /usr/sbin/* && \ cp /usr/lib/python3.8/site-packages/tritonclient/libcudart.so* /usr/lib/ && \ cp /usr/lib/python3.8/site-packages/tritonclient/libnvinfer.so* /usr/lib/ # 复制构建好的依赖和代码 FROM scratch COPY --from=builder /usr/lib/python3.8/site-packages/ /app/venv/lib/python3.8/site-packages/ COPY --from=runtime /usr/lib/ /usr/lib/ COPY app.py /app/ WORKDIR /app EXPOSE 8000 CMD ["./app.py"]

最终镜像仅217MB，且docker exec -it <container> /bin/sh会直接报错command not found。安全扫描（Trivy）结果显示：0个CRITICAL漏洞，2个MEDIUM（均为TensorRT底层CUDA库，无可规避）。这个镜像在K8s集群中拉取时间从平均47秒降至6秒，滚动更新窗口缩短了85%。别小看这几秒——在金融高频交易场景，服务中断每多1秒，潜在损失可能达数十万元。

3.4 步骤四：KServe部署与配置——YAML里的魔鬼细节

一个看似简单的InferenceServiceYAML，藏着大量影响稳定性的细节。我们整理了生产环境必填的“魔鬼字段”：

apiVersion: "kserve.kserve.io/v1beta1" kind: "InferenceService" metadata: name: "nlp-classifier" annotations: # 关键！禁用KServe的自动TLS，我们用Istio统一管理 kserve.io/enable-auth: "false" # 启用GPU亲和性，确保Pod调度到有GPU的Node kubernetes.io/device-plugin: "nvidia" spec: predictor: minReplicas: 2 # 防止单点故障，永远至少2个副本 maxReplicas: 10 # HPA上限，防止单个模型吃光集群资源 serviceAccountName: "kserve-sa" # 绑定专用SA，限制权限 triton: # 存储必须用云存储，禁止本地路径 storageUri: "s3://my-model-bucket/nlp-v3/" # 资源请求必须等于限制，避免K8s调度混乱 resources: limits: memory: "8Gi" nvidia.com/gpu: 1 requests: memory: "8Gi" nvidia.com/gpu: 1 # Triton特有配置：启用gRPC，禁用HTTP（REST性能差30%） protocolVersion: "grpc" # 自定义探针，比默认的HTTP探针更精准 readinessProbe: initialDelaySeconds: 60 # 给Triton足够时间加载大模型 periodSeconds: 30 exec: command: ["sh", "-c", "triton_health_check || exit 1"]

readinessProbe的exec命令是我们自研的脚本，它直接调用Triton的gRPC健康接口ModelReadyRequest，比HTTP GET/v2/health/ready更可靠——后者有时返回200但模型实际未加载完成。initialDelaySeconds: 60是血泪教训：一个1.2GB的BERT-large模型，在冷启动时加载时间可达45秒，若探针30秒就触发，会导致Pod反复重启。

3.5 步骤五：可观测性埋点——不是加日志，而是建“神经网络”

生产环境的可观测性，绝不是print("Predicted class: ", pred)。我们需要的是立体化指标体系，覆盖数据、模型、服务、基础设施四层：

• 数据层：输入请求的input_length_distribution（文本长度分布）、null_rate（空值率）。当null_rate从0.01%突然升至5%，说明上游数据管道断裂。
• 模型层：inference_latency_p95（P95延迟）、output_entropy（输出熵值，熵值持续降低预示模型退化）、feature_drift_score（与基线特征分布的KL散度）。
• 服务层：http_request_total{code=~"5.."}（5xx错误率）、grpc_server_handled_total{grpc_code="Unknown"}（gRPC未知错误）。
• 基础设施层：container_memory_usage_bytes{container="triton"}（容器内存）、nvidia_gpu_duty_cycle（GPU利用率）。

我们用OpenTelemetry SDK在Python客户端埋点：

# 初始化Tracer tracer = trace.get_tracer(__name__) # 在predict函数内 with tracer.start_as_current_span("model_inference") as span: span.set_attribute("model.name", "nlp-classifier") span.set_attribute("input.length", len(text)) start_time = time.time() result = client.infer("nlp-classifier", inputs) latency_ms = (time.time() - start_time) * 1000 span.set_attribute("inference.latency_ms", latency_ms) span.set_attribute("output.class", result.as_numpy("OUTPUT")[0])

所有Span数据上报到Jaeger，指标数据推送到Prometheus。Grafana看板上，我们设置了“黄金信号”告警：当inference_latency_p95 > 100ms AND error_rate > 0.5%同时触发，立即通知值班工程师。这套体系让我们在2023年Q3将平均故障修复时间（MTTR）从47分钟压缩至8分钟。

3.6 步骤六：灰度发布与回滚——用数据代替直觉做决策

上线新模型，最怕“一刀切”。我们的标准流程是：金丝雀发布 → A/B测试 → 全量切换 → 自动回滚。

KServe的canary字段配合Prometheus指标，实现全自动决策：

# InferenceService with Canary spec: predictor: # 主版本（90%流量） componentSpecs: - spec: containers: - name: kfserving-container image: kfserving/tensorflowserver:v0.7.0 args: ["--model_name=nlp-v2", "--model_base_path=/mnt/models"] canary: # 金丝雀版本（10%流量） predictor: componentSpecs: - spec: containers: - name: kfserving-container image: kfserving/tensorflowserver:v0.7.0 args: ["--model_name=nlp-v3", "--model_base_path=/mnt/models"] traffic: - name: stable percentage: 90 - name: canary percentage: 10 # 自动评估规则 analysis: metrics: - name: error-rate threshold: 0.005 # 错误率<0.5% interval: 30s - name: latency-p95 threshold: 100 # P95延迟<100ms interval: 30s - name: accuracy-delta threshold: -0.002 # 准确率下降不超过0.2% interval: 30s # 连续5次检查通过，则切全量 successCondition: "error-rate < 0.005 && latency-p95 < 100 && accuracy-delta > -0.002" failureCondition: "error-rate > 0.01 || latency-p95 > 150"

这套机制在实战中救了我们多次。有一次，新版本模型因一个未发现的tokenizer bug，导致特定emoji输入时崩溃。金丝雀流量中错误率在第2分钟就飙升至12%，KServe在第3分钟自动停止金丝雀流量，并向Slack告警频道发送详细报告：“Canary rollout aborted for nlp-v3: error-rate=12.3% > threshold=1.0%”。我们立刻回滚，全程无人工干预，业务无感知。

3.7 步骤七：灾难恢复演练——不是“如果”，而是“何时”

再完美的系统也会出问题。我们每月进行一次“混沌工程”演练：随机Kill一个Triton Pod，模拟GPU故障；手动修改S3模型桶的ACL，模拟存储不可用；用tc netem delay 5000ms给网络注入5秒延迟。目标不是“不出问题”，而是验证恢复流程是否能在SLA内完成。

关键成果是《故障响应手册》（FRM），它不是文档，而是可执行的Runbook：

这份手册被集成到PagerDuty中，当告警触发时，值班工程师手机收到的不是模糊的“服务异常”，而是带超链接的精确操作指南。这让我们在过去一年中，将P1级故障的平均恢复时间（MTTR）稳定在4.2分钟，远低于行业平均的22分钟。

4. 常见问题与排查技巧实录：那些文档里不会写的“脏活累活”

4.1 问题：Triton日志显示Failed to load model 'xxx': Internal: unable to get model configuration，但config.pbtxt语法检查无误

排查思路：Triton的错误信息极具迷惑性。它说“无法获取配置”，往往不是配置文件本身错，而是模型目录结构不符合约定。Triton要求严格的三层结构：

s3://bucket/models/nlp-v3/ ├── 1/ ← 版本号目录（必须是数字） │ ├── model.plan ← 模型文件（名称必须匹配config.pbtxt中name） │ └── ... ├── config.pbtxt ← 必须在此层级，不能在1/目录下 └── ...

我们曾遇到一个案例：config.pbtxt里写name: "nlp-v3"，但模型文件放在s3://bucket/models/nlp-v3/1/model.onnx，而config.pbtxt却放在s3://bucket/models/nlp-v3/config.pbtxt——这看起来天经地义，但Triton会静默失败。正确做法是：config.pbtxt必须和版本目录1/在同一级，且name字段必须与父目录名nlp-v3完全一致。实操技巧：用tritonserver --model-repository=s3://bucket/models --strict-model-config=false --log-verbose=1启动调试模式，日志会明确指出“missing config.pbtxt in model directory”。

4.2 问题：KServe部署后，kubectl get isvc显示Unknown状态，describe看到Failed to create route: no matches for kind "VirtualService" in version "networking.istio.io/v1beta1"

根因分析：这是KServe与Istio版本不兼容的经典问题。KServe v0.11+要求Istio v1.17+，而很多团队还在用Istio v1.14。VirtualService的API在v1.17中从v1beta1升级到v1。解决方案不是降级KServe，而是升级Istio。但我们发现，直接升级Istio风险极高。于是我们采用“双网关”策略：在集群中并行部署Istio v1.14（用于现有微服务）和Istio v1.18（专供KServe），通过istio-injection=disabled标签隔离命名空间。这多花了一天配置时间，但避免了全站升级带来的停机风险。

4.3 问题：模型在Triton上推理结果与本地PyTorch完全一致，但线上A/B测试显示新模型准确率低2%，且只在移动端请求中出现

深度排查：这个问题折磨了我们三天。最终发现，移动端SDK在构造HTTP请求时，对URL中的+号做了双重编码（+→%2B→%252B），导致传入Triton的base64字符串末尾多了==，解码后数据损坏。教训：永远不要假设客户端传来的数据是“干净”的。我们在Triton的preprocessing Python backend中增加了强校验：

def preprocess(request): try: # 尝试标准base64解码 decoded = base64.b64decode(request["image"]) except Exception: # 备用：处理双重编码 fixed = request["image"].replace("%252B", "+").replace("%253D", "=") decoded = base64.b64decode(fixed) return {"image": decoded}

这个try/except块后来成了我们所有模型服务的标配。经验心得：生产环境的“数据质量”问题，80%源于客户端与服务端的编码/解码协议不一致，而非模型本身。务必在服务入口处做最宽松的容错处理。

4.4 问题：Prometheus抓取Triton指标时，nv_gpu_utilization指标始终为0

技术细节：Triton的GPU指标依赖NVIDIA DCGM（Data Center GPU Manager）Exporter。但DCGM默认只监控nvidia-smi可见的GPU，而K8s中Pod看到的GPU是通过nvidia-device-plugin虚拟化的。解决方案：在部署DCGM Exporter时，必须挂载宿主机的/run/nvidia/driver目录，并设置环境变量DCGM_EXPORTER_COLLECTORS=/etc/dcgm-exporter/custom-collector.csv，其中custom-collector.csv包含：

DCGM_FI_DEV_GPU_UTIL,DCGM_FI_DEV_MEM_COPY_UTIL,DCGM_FI_DEV_POWER_USAGE

否则，DCGM只能看到“虚拟GPU”，其利用率恒为0。这个配置在NVIDIA官方文档里藏得很深，我们是在GitHub Issues里翻了200+条才找到答案。

4.5 问题：KServe金丝雀发布后，Grafana看板上新旧版本的inference_latency_p95曲线完全重合，但业务方反馈新版本效果更好

真相揭露：我们检查了KServe的流量分发逻辑，发现它默认使用istio-ingressgateway的Host头做路由，而所有客户端请求的Host头都是api.company.com，导致流量并未真正分发，100%都打到了主版本。修正方法：在KServe的InferenceService中显式指定traffic的header匹配：

traffic: - name: stable percentage: 90 header: "x-model-version: v2" - name: canary percentage: 10 header: "x-model-version: v3"

并在客户端SDK中，根据实验ID注入对应的Header。这个细节，让我们的A/B测试数据终于真实可信。

5. 性能压测与容量规划：用数字说话，拒绝“我觉得应该够”

5.1 压测不是“看看能扛多少”，而是“在SLA下能撑多久”

很多团队的压测停留在hey -z 5m -q 1000 -c 100 http://service/predict，然后看QPS峰值。这毫无意义。真正的压测必须绑定业务SLA。例如，我们的推荐服务SLA是：P95延迟 ≤ 150ms，错误率 ≤ 0.1%，可用性 ≥ 99.95%。压测目标就变成：在满足SLA的前提下，系统能承受的最大持续流量是多少？

我们使用Locust编写场景化脚本：

class ModelUser(HttpUser): @task def predict_text(self): # 模拟真实流量分布：70%短文本，20%中等，10%超长 text_len = random.choices([50, 200, 500], weights=[70,20,10])[0] text = " ".join(["word"] * text_len) payload = {"instances": [{"text": text}]} with self.client.post("/v2/models/nlp-v3/infer", json=payload, catch_response=True) as response: if response.status_code != 200: response.failure(f"HTTP {response.status_code}") else: latency_ms = response.elapsed.total_seconds() * 1000 if latency_ms > 150: response.failure(f"Latency {latency_ms:.1f}ms > 150ms") # 每分钟发起一次健康检查，模拟运维探针 @task(10) # 权重10，频率更高 def health_check(self): self.client.get("/v1/health")

压测结果不是单一QPS数字，而是一份《容量基线报告》：