共计 2052 个字符，预计需要花费 6 分钟才能阅读完成。
业务场景警示录
在开始技术选型前，先看两个真实案例：
- 实时推荐系统卡顿
某电商团队为追求模型复杂度，选择 TensorFlow 构建深度 CTR 模型，但未考虑线上推理的延迟要求。上线后 API 响应时间突破 500ms，导致大促期间流量暴跌 23%。事后分析发现： - 计算图优化不足
- 未启用 TensorRT 加速
-
服务化方案采用低效的 gRPC 封装
-
工业质检误判率高
某制造业团队用 PyTorch 快速迭代 Unet 分割模型，但将训练代码直接迁移到生产环境时发现： - 缺少模型序列化规范导致版本混乱
- 显存泄漏引发 GPU 节点频繁崩溃
- 缺乏分布式训练支持无法处理新增产线数据
框架对比矩阵
| 维度 | TensorFlow | PyTorch |
|---|---|---|
| 开发体验 | 静态计算图（2.x 支持动态） | 动态计算图 |
| 部署便利性 | SavedModel 标准格式 | TorchScript 需额外转换 |
| 移动端支持 | TFLite 成熟 | TorchMobile 逐步完善 |
| 分布式训练 | 原生支持 ParameterServer | 依赖 Horovod 或 DDP |
| 可视化工具 | TensorBoard 完善 | 可接入 TensorBoard |
| 社区生态 | 工业界主流 | 学术界首选 |
选型决策树
graph TD
A[数据量 >1TB?] -->| 是 | B[需要分布式训练?]
A -->| 否 | C[延迟要求 <100ms?]
B -->| 是 | D[TensorFlow+ParameterServer]
B -->| 否 | E[团队熟悉 PyTorch?]
C -->| 是 | F[TensorFlow+TensorRT]
C -->| 否 | G[需要快速原型开发?]
E -->| 是 | H[PyTorch+DDP]
E -->| 否 | D
G -->| 是 | H
G -->| 否 | F技术验证实战
训练耗时对比
# mlflow 实验记录（PEP8 格式）import mlflow
from time import perf_counter
def train_model(framework: str, epochs: int=10) -> float:
start = perf_counter()
# 模拟训练过程（实际替换为真实训练代码）if framework == 'tensorflow':
import tensorflow as tf
model = tf.keras.Sequential([...])
else:
import torch
model = torch.nn.Sequential(...)
with mlflow.start_run():
mlflow.log_param('framework', framework)
mlflow.log_metric('train_time', perf_counter()-start)
return perf_counter() - startREST API 服务化
# FastAPI 部署示例（带类型注解）from fastapi import FastAPI
import numpy as np
app = FastAPI()
@app.post('/predict')
async def predict(input_data: list[float]):
"""
Args:
input_data: 特征向量，长度需匹配模型输入维度
Returns:
JSON 格式预测结果
"""
tensor = np.array(input_data).astype(np.float32)
# 实际加载已导出的模型
return {'prediction': float(model(tensor))}内存监控方案
# GPU 显存监控代码片段
import pynvml
def check_gpu_memory(threshold: int=1024) -> bool:
"""检查显存是否超过阈值 (MB)"""
pynvml.nvmlInit()
handle = pynvml.nvmlDeviceGetHandleByIndex(0)
info = pynvml.nvmlDeviceGetMemoryInfo(handle)
return (info.used//1024**2) > threshold生产环境必选项
模型版本管理
- 采用 MLflow Model Registry 实现：
- 自动记录训练参数和指标
- 支持模型版本线形图可视化
- 提供阶段过渡（Staging→Production）
GPU 调度策略
- 容器化部署时设置资源限制：
--gpus='capabilities=utility,memory=16GB' - 使用 Kubernetes Device Plugins 实现：
- 多卡任务的自动分配
- 显存碎片整理
性能优化技巧
- IO 瓶颈 ：
- 使用 TFRecord/Petastorm 替代原始图片加载
- 启用预取机制 (prefetch)
- 计算瓶颈 ：
- 应用 XLA 编译器优化
- 使用混合精度训练
- 显存泄漏 ：
- 定期运行
torch.cuda.empty_cache() - 避免在循环中累积计算图
留给读者的思考
- 当前项目的批处理大小是否达到 GPU 计算最优利用率？
- 模型服务化是否需要考虑灰度发布方案？
- 特征工程管道是否与模型框架强耦合？
技术选型没有银弹，希望这篇指南能帮你避开我们踩过的坑。记住：最适合当前业务阶段的技术，就是最好的选择。
正文完
