CUDA显存是否足够应通过“尝试分配+捕获失败”实测判断，而非依赖cudaMemGetInfo等不可靠查询；典型做法是在GPU上执行小batch前向推理并捕获RuntimeError等异常，失败则降级至CPU。
如何检测 GPU 显存是否足够并触发降级
核心不是“预估显存”，而是“尝试分配 + 捕获失败”。CUDA 不提供可靠的显存剩余量查询（cudaMemGetInfo 返回的空闲值受碎片、驱动预留、上下文缓存干扰，常误判），正确做法是直接调用 cudaMalloc 或框架内存申请接口，用异常或返回码判断是否失败。
实操建议：
- 在模型加载/首次推理前，用小 batch（如 batch=1）+ 最小输入尺寸，在 GPU 上执行一次前向（不依赖显存预估，只依赖真实分配结果）
- 捕获
std::runtime_error（PyTorch）、TRITONSERVER_ERROR_UNAVAILABLE（Triton）或 CUDA 错误码cudaErrorMemoryAllocation - 若失败，记录日志并切换至 CPU 设备；成功则继续使用 GPU
- 避免轮询
cudaMemGetInfo做决策——它在多进程/容器环境下尤其不准
PyTorch 中实现设备自动选择与模型迁移
PyTorch 本身不自动降级，需手动控制 device 和 model.to(device) 的时机。关键点在于：模型和数据必须同设备，且降级后不能残留 GPU 张量引用。
实操建议：
- 封装一个
get_preferred_device()函数，内部先试torch.cuda.is_available()，再试torch.cuda.memory_allocated()辅助判断（仅作参考），最终以try { torch.zeros(1).cuda() } catch实锤 - 模型加载后立即调用
model.to(device)，不要延迟到 inference 时才传 device 参数 - 确保所有输入
tensor都显式调用.to(device)，别依赖默认设备；降级时注意清除torch.cuda.empty_cache()防止残留 - 如果用了
torch.compile或torch.jit.script，需在降级后重新编译/脚本化，否则可能仍绑定原设备
TensorRT / ONNX Runtime 如何支持运行时设备切换
TensorRT 本身不支持运行时从 GPU 切换到 CPU；ONNX Runtime 则可通过 SessionOptions 动态指定执行提供者（Execution Provider），但切换需重建 session —— 这是唯一安全方式。
实操建议：
- 初始化时不要直接 new
Ort::Session，而是封装create_session(device_type)工厂函数，接受"CUDA"或"CPU" - 首次尝试
create_session("CUDA")，若构造抛出异常（如Ort::Exception含 "CUDA" 字样），立即 fallback 调用create_session("CPU") - 避免复用 session 对象：GPU session 无法通过 API 切换为 CPU，强行调用
Run会 crash - ONNX 模型导出时保留 float32（别用 fp16），否则 CPU 推理可能因缺少算子支持而失败
降级后如何避免性能断崖与逻辑错乱
自动降级不是“加个 try-catch 就完事”，CPU 推理慢 5–20 倍，若没做请求队列、超时控制或响应格式对齐，用户会感知为服务不可用。
实操建议：
- 降级后强制设置更长的
timeout_ms（比如从 500ms → 5000ms），并在 HTTP 响应头中添加X-Fallback: cpu便于监控 - 统一输入预处理逻辑：GPU 版常用
torchvision.transforms在 GPU 上做归一化，降级后需确保 same transform 在 CPU tensor 上行为一致（禁用to_device=True类参数） - 输出后处理（NMS、解码）也需适配：例如 TensorRT 的
IPluginV2自定义层在 CPU 下不存在，降级路径必须走纯 PyTorch 实现 - 最易忽略的一点：日志中打印降级原因时，要记录
cudaGetLastError()或框架原始错误字符串，而不是只写 “OOM”——下次可能是 driver bug 或权限问题
健壮性不体现在“能切”，而体现在“切了之后请求不丢、结果不错、问题可追溯”。降级不是兜底，是明确的故障转移策略，每条路径都得走通测试。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
