最简单方案是用tf.keras.models.load_model加载模型后以flask/fastapi封装接口；tf serving适合高并发多模型生产环境，但单模型验证时反而复杂。
直接用 tf.keras.models.load_model 加载模型 + Flask 或 FastAPI 封装接口，是最简单、最可控的起步方案。TF Serving 更适合高并发、多模型、需版本管理的生产环境，但对单模型快速验证反而增加复杂度。
用 Flask 快速启动一个可调用的预测接口
这是本地验证、POC 或小流量场景下最省心的做法：模型加载一次，HTTP 请求进来就做推理，不依赖额外服务。
-
model.save("my_model")保存后，必须用tf.keras.models.load_model("my_model")加载 —— 别用tf.keras.models.load_model("my_model.h5")去读 SavedModel 目录，会报ValueError: No model found in config file - 图像类模型注意输入预处理：用
PIL.Image.open()+np.array()+tf.image.resize()统一尺寸，再tf.expand_dims(..., 0)补 batch 维度 - 避免在每次请求里重复加载模型：把
model = tf.keras.models.load_model(...)放在全局作用域，不是放在@app.route函数里 - 如果用
Flask，启动时加--threaded（默认已启用），否则并发请求会阻塞；用FastAPI+uvicorn更推荐：uvicorn model_api:app --reload --workers 2
导出 SavedModel 格式时必须显式指定 save_format='tf'
很多人用 model.save("my_model") 后发现 TF Serving 启动失败，根本原因是 TF 2.x 默认行为可能写成 HDF5（.h5），或路径里自动加时间戳，导致目录结构不合规。
- 正确写法：
tf.keras.models.save_model(model, "models/my_model/1", save_format="tf")—— 末尾/1是版本号目录，TF Serving 只认纯数字子目录 - 检查导出是否有效：
saved_model_cli show --dir models/my_model/1 --all，确认输出里有serving_defaultsignature，且 input tensor 名（如input_1:0）和你后续 gRPC 请求中用的一致 - 目录权限要设为
755，variables/ 下文件需可读；Docker 挂载时若用bind mount，宿主机目录权限没放开会导致Failed to get matching files
TF Serving 的 REST 接口不能当主力用
它只支持最基础的 /v1/models/{name}:predict，没有健康检查、模型状态查询、版本切换等能力，且从 2.10 开始仍是实验性功能，文档里都写着 not recommended for production。
- 启动命令必须同时带两个参数：
--rest_api_port=8501和--enable_batching=true，缺一不可；否则 batch size=1 时延迟飙升，甚至返回空响应 -
curl http://localhost:8501/v1/models/my_model返回 404？先确认MODEL_NAME=my_model环境变量和模型目录名完全一致（区分大小写），且容器内挂载路径是/models/my_model - 真正可靠的生产架构是：TF Serving 跑 gRPC（端口
8500），再套一层FastAPI做协议转换 —— 这样既能复用 TF Serving 的 batching 和模型热加载，又能自定义输入校验、日志、熔断等逻辑
gRPC 客户端调用时版本必须严格匹配
TF Serving 的 Python client（tensorflow-serving-api）不是纯 Python 包，它底层绑定的是特定版本的 C++ serving library。版本不一致会直接 core dump 或抛出奇怪的 StatusCode.UNIMPLEMENTED。
- 查当前 TF Serving 镜像版本：
docker run --rm tensorflow/serving:latest --version，比如输出2.16.0 - 对应安装 client：
pip install tensorflow-serving-api==2.16.0（不是tensorflow-serving-api-cpu，那个包已废弃） - stub 实例必须全局复用，不要每次请求都新建
prediction_service_pb2_grpc.PredictionServiceStub，否则连接开销极大，QPS 上不去 - 如果你只是临时测试，用
requests+ REST 接口更轻量；但只要考虑压测或长期运行，gRPC + stub 复用是唯一合理选择
最容易被忽略的是签名（signature）和 tensor 名的对齐 —— 导出时没留意 serving_default 里 input key 是 input_1 还是 images，请求体里就容易传错字段，错误信息却只显示 KeyError 或空 response，排查起来非常耗时。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
