昨天深夜，线上推理服务突然开始返回乱码。监控显示GPU利用率满负荷，但吞吐量直接掉零。紧急回滚到三个版本前的模型，服务立刻恢复正常。问题出在新模型转换时一个不起眼的--opset-version参数上——ONNX导出用了最新版本，而生产环境的TensorRT却还守着老旧的7.2。这种训练与部署环境脱节的问题，咱们应该都不陌生。

模型转换的暗礁

训练框架和推理引擎之间，永远隔着一条鸿沟。PyTorch训练出的model.pt，到生产环境里可能要通过ONNX、TensorFlow Lite、Core ML这些中间表示走一遭。我习惯在训练脚本里就埋入导出逻辑：

# 训练循环结束后立即做转换验证
torch.onnx.export(
    model, 
    dummy_input,
    "model.onnx",
    opset_version=11,  # 这里踩过坑：必须对齐推理端支持的版本
    do_constant_folding=True,
    input_names=["pixel_values"],
    output_names=["logits"]
)

# 立刻用ONNX Runtime跑一遍推理
ort_session = ort.InferenceSession("model.onnx")
ort_inputs = {ort_session.get_inputs()[0].name: dummy_input.numpy()}
ort_outputs = ort_session.run(None, ort_inputs)
# 对比输出差异，超过阈值就告警

别等到交付前才做转换，那时发现问题可能得重新训练。更狠一点的做法是，把ONNX导出和验证作为CI/CD流水线的必过环节，任何提交导致转换失败就直接阻断。

推理引擎的调优实战

TensorRT、OpenVINO、TFLite这些引擎，每个都有自己的脾气。拿TensorRT来说，同样的模型用FP32和FP16精度，性能能差出两倍以上，但有些模型就是受不了精度损失。我的调试流程一般是这样的：

# 先跑基准测试
trt_logger = trt.Logger(trt.Logger.WARNING)
with trt.Builder(trt_logger) as builder:
    builder.max_batch_size = 32  # 根据实际业务流量设定
    builder.fp16_mode = True  # 先尝试FP16
    builder.strict_type_constraints = False  # 允许类型转换
    
    # 动态shape支持现在必须考虑
    profile = builder.create_optimization_profile()
    profile.set_shape("input", 
                      min=(1, 3, 224, 224),   # 最小batch
                      opt=(8, 3, 224, 224),   # 典型batch  
                      max=(32, 3, 224, 224))  # 最大batch
    
    # 构建引擎
    engine = builder.build_cuda_engine(network)
    
# 测试阶段别偷懒，各种输入尺寸都测一遍
for batch in [1, 4, 8, 16, 32]:
    inputs = torch.randn(batch, 3, 224, 224).cuda()
    # 跑100次取P99延迟

遇到过一个坑：某模型在batch=8时性能最优，但实际请求都是单张图片。硬是加了请求队列做动态batching，把延迟从15ms降到4ms。推理优化就是这样，没有银弹，得根据流量模式慢慢调。

服务化部署的工程细节

模型转换好了，引擎也调优了，接下来是怎么把它暴露给业务方。Flask写个API是最快的，但生产环境我绝对不推荐。内存泄漏、并发瓶颈、监控缺失——随便一个都能让你半夜爬起来。现在主流是用Triton Inference Server或TorchServe，但我自己更偏爱用FastAPI搭配异步worker：

# 服务层代码示例
app = FastAPI()
model_pool = []  # 模型实例池，避免加载锁

@app.on_event("startup")
async def load_models():
    # 预热加载，别等第一个请求来了才初始化
    for _ in range(config.WORKER_NUM):
        engine = load_trt_engine("model.plan")
        model_pool.append(engine)
    
@app.post("/infer")
async def infer(request: InferRequest):
    # 从池里取实例，用完归还
    engine = model_pool.pop()
    try:
        # 这里一定要做超时控制
        result = await asyncio.wait_for(
            run_inference(engine, request.data),
            timeout=0.1  # 100ms超时
        )
        return {"data": result}
    except asyncio.TimeoutError:
        logger.warning(f"请求超时: {request.request_id}")
        raise HTTPException(408)
    finally:
        model_pool.append(engine)

# 监控埋点别忘了
@app.middleware("http")
async def add_process_time_header(request, call_next):
    start_time = time.time()
    response = await call_next(request)
    process_time = time.time() - start_time
    metrics.latency.observe(process_time)  # 推给Prometheus
    return response

健康检查、熔断降级、灰度发布这些微服务的老套路，在AI服务上一个都不能少。特别提醒：模型版本管理要用语义化版本，并且每个版本都要保留完整的转换参数记录——你永远不知道什么时候需要回滚。

边缘端的特殊挑战

在嵌入式设备上部署又是另一番景象。内存按KB算，算力捉襟见肘。上周给一块STM32H7部署目标检测模型，光是量化校准就折腾了两天：

// 边缘端C++代码片段
void run_inference() {
    // 静态内存分配，运行时绝不malloc
    static int8_t input_buffer[3*224*224];
    static int8_t output_buffer[1000];
    
    // 用CMSIS-NN这类优化库
    arm_convolve_wrapper(input_buffer, 
                         weights_quantized,
                         output_buffer);
    
    // 输出后处理也要轻量
    int top_k[5];
    arm_top_k_q7(output_buffer, 1000, 5, top_k);
    
    // 日志？用串口输出都嫌重，最好用条件编译控制
    #ifdef DEBUG_MODE
    printf("推理完成，耗时：%d ms\n", get_tick_count());
    #endif
}

边缘部署最大的教训是：训练阶段就要考虑部署约束。加入蒸馏、剪枝、量化感知训练，比事后压缩要管用得多。另外，测试数据一定要覆盖极端场景——高温低温、电压波动、内存碎片，这些在服务器上不用考虑的问题，在边缘端都是致命伤。

一些血泪经验

模型部署这活儿，三分靠技术，七分靠经验。说几条个人体会：

第一，训练和部署的环境尽量用容器镜像固化下来。别相信“这两个版本应该兼容”这种鬼话，我吃过亏——PyTorch 1.8和1.9的ONNX导出结果在特定算子处理上就是有细微差异，导致线上指标掉了0.3%，查了一整周。

第二，监控要打到细粒度。不仅要有请求量、延迟这些业务指标，还要有GPU内存使用率、显存碎片率、kernel执行时间这些底层指标。某次线上问题就是显存碎片积累到一定程度后，突然触发OOM，常规监控根本看不出来。

第三，压测要做全链路。单独压模型推理每秒能处理1000张图，加上前后处理、网络序列化、业务逻辑后，可能就剩200张了。用真实流量模板去压，别用合成数据。

最后，文档要写给六个月后的自己看。记录下每个决策背后的原因：为什么选这个opset版本？为什么量化校准用1000张图片而不是500张？为什么服务超时设100ms而不是200ms？这些上下文信息，关键时刻能救命。

模型部署从来不是把文件丢到服务器就完事了。它是一整套工程体系，从训练时的前瞻性设计，到转换时的严格验证，再到服务时的稳定性保障，每一步都得踩稳了。咱们这行，线上不出问题就是最大的功劳。