TensorFlow Serving本身不提供灰度路由能力，仅支持多版本共存与显式版本调用；灰度发布需由上游网关基于model_version字段动态路由请求，并配合健康检查确保版本就绪。
灰度发布需要模型版本切换，TensorFlow Serving 本身不提供“灰度路由”能力
TensorFlow Serving 只负责加载和响应推理请求，它不内置流量分发、权重控制或A/B测试逻辑。所谓“灰度发布”，本质是把部分请求导向新版本模型，其余仍走旧版本——这个决策必须由上游服务（如网关、负载均衡器或自研路由层）完成，Serving 只需保证多版本共存且可独立访问。
关键前提是：新旧模型必须以不同 model_name 或同一 model_name 下不同 version 部署，并启用 --enable_model_versioning=true（默认开启）。
- 推荐用同一
model_name+ 不同version：Serving 自动按数字升序选最新版，但客户端可通过model_version字段显式指定版本 - 若用不同
model_name（如my_model_v1和my_model_v2），需在客户端硬编码名称，灵活性更低 - 版本号必须是纯数字目录名（如
1、2），不能是v2.1或alpha
客户端请求必须显式携带 model_version 才能定向调用特定版本
默认情况下，gRPC 或 REST API 请求会打到当前 latest 版本。要实现灰度，客户端（比如你的 Flask 网关）需根据灰度策略（如用户ID哈希、请求头标记、随机比例）动态决定 model_version 值，并写入请求体。
REST 示例（curl）：
立即学习“Python免费学习笔记（深入）”；
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
curl -X POST http://localhost:8501/v1/models/my_model/versions/2:predict \
-H "content-type: application/json" \
-d '{
"instances": [[1.0, 2.0, 3.0]]
}'
gRPC 中需在 PredictRequest 的 model_spec.version 字段赋值；Python 客户端常用 tensorflow_serving.apis.predict_pb2.PredictRequest 构造：
request.model_spec.name = "my_model"-
request.model_spec.version.value = 2← 这行不能省，否则走 latest - 若 version 不存在，返回
StatusCode.NOT_FOUND错误，不是静默降级
健康检查与版本就绪判断不能只看目录存在，得查 /v1/models/{name}/versions/{v} 接口
模型目录拷贝完成不代表已加载成功。Serving 是异步加载，尤其大模型可能耗时数秒到数十秒。直接切流会导致 503 或版本未就绪错误。
- 正确做法：轮询
http://host:port/v1/models/my_model/versions/2，直到返回 HTTP 200 且status.state == "AVAILABLE" - 注意：
/v1/models/my_model返回的是 latest 状态，不反映具体版本加载进度 - 若用 Kubernetes，可在 readiness probe 中集成该检查，避免 Service 把流量导给未 ready 的 Pod
- 别依赖文件系统监听或 sleep(5)，Serving 加载时间受模型大小、CPU、内存影响很大
灰度比例控制必须在 Serving 外部做，且要注意 gRPC 连接复用带来的偏差
如果你用长连接（gRPC channel 复用），同一个 channel 可能持续打到同一个后端 Serving 实例，而该实例的本地缓存可能影响版本选择逻辑（虽然 Serving 本身无状态）。更严重的是：若灰度策略基于随机数，但你在初始化 client 时就固定了版本，后续所有请求都走同一版。
- 灰度决策点必须靠近请求入口：比如 Nginx 按 header 转发，或 Python 网关在每次 request handler 中计算版本号
- 避免在 client 初始化时硬编码
model_version，应每次构造PredictRequest时动态设置 - REST 方式天然支持 per-request 版本控制；gRPC 也一样，只要每次填对
model_spec.version - 如果用 Istio 或 Linkerd 做流量切分，需配置 VirtualService 将不同权重的请求路由到不同
model_name，此时 Serving 需部署两个独立服务（不推荐，增加运维负担）
真正麻烦的从来不是 Serving 怎么配，而是你怎么让每一次请求都带着正确的版本意图进来——而且这个意图还得可审计、可回滚、可监控。版本号写错一位，灰度就变成全量。
