必须全局初始化device并用map_location加载模型，强制.eval()和with torch.no_grad()确保推理稳定；直接torch.load()易致设备不匹配或显存泄漏。
直接用 torch.load() 加载模型后扔进 Flask/FastAPI 路由里跑推理，90% 会出设备不匹配或显存泄漏——不是模型不行，是加载和执行方式错了。
torch.load() 必须配 map_location，否则设备错乱
常见错误现象：RuntimeError: Input type (torch.FloatTensor) and weight type (torch.cuda.FloatTensor) should be the same。这是因为模型在 GPU 上保存时，torch.load('model.pth') 默认把权重读进 CPU 内存，但模型结构里还残留 CUDA 层引用。
- 全局定义
device = torch.device('cuda' if torch.cuda.is_available() else 'cpu')，别每次请求都重算 - 加载时强制指定
map_location=device：torch.load('model.pth', map_location=device) - 加载完立刻调用
model.to(device)，确保整个模型（含 buffer/param）都在同一设备上
推理必须包裹在 torch.no_grad() + .eval() 里
漏掉这两步，Dropout 和 BatchNorm 行为异常，且梯度缓存持续堆积，导致响应变慢、显存不释放——尤其在并发稍高时，nvidia-smi 显示显存占用一路涨到爆。
-
model.eval()要在服务启动时调用一次，不是每次请求都调 - 所有预测逻辑必须包在
with torch.no_grad():块内 - 返回前可加
del output（非必需，但在长连接或高频请求下能加速 GC）
Flask vs FastAPI：选哪个取决于你卡在哪一步
Flask 更适合本地快速验证或低并发内部工具；FastAPI 是生产级部署的默认选择，不是因为它“高级”，而是它天然规避了几个关键坑。
立即学习“Python免费学习笔记（深入）”；
- Flask 用
request.files['image'].read()拿原始字节没问题，但文本类输入得自己json.loads(request.get_data())，容易因编码或空 body 报错 - FastAPI 用
UploadFile参数自动处理二进制上传，用 Pydantic 模型（如class PredictRequest(BaseModel): text: str）自动校验字段类型和长度，省掉一堆try/except - FastAPI 默认异步，单个 GPU 实例能扛住更高并发；Flask 默认同步，需配合 gunicorn + workers 才能撑住多请求，配置稍重
图像/文本输入怎么安全传进来
别用 request.json() 解析图片 Base64 字符串——解码开销大，还常因 padding 或字符集问题失败。
- 图像上传：用
UploadFile（FastAPI）或request.files（Flask），await file.read()或file.read()拿bytes，再喂给PIL.Image.open(io.BytesIO(...))或torchvision.io.decode_image() - 文本输入：FastAPI 定义 Pydantic 模型约束长度（
text: str; max_length: int = 512），Flask 则建议用request.get_json(force=True)+ 手动 key 检查 - 批量输入：接收 JSON 数组时，别直接
torch.tensor(data)，先做维度对齐：torch.tensor(data).reshape(-1, input_dim)，避免张量形状爆炸
最易被忽略的是模型加载时机和设备绑定——它必须发生在服务启动阶段，而不是每次请求里；一旦写成“请求来了再 load 再 to cuda”，冷启动延迟、设备错位、显存碎片就全来了。
