🏷️ GPU

去年年底，我们那条模型推理管线的告警，几乎每天都把我从工位上薅起来。不是推理服务挂了，而是“慢”——客服机器人突然卡了超过两秒，业务方在群里@我说用户开始骂人了。我打开Grafana一看，同一时刻有几百个离线批处理请求涌进来，把在线请求的GPU显存和算力全部挤占。那些批处理是给后台运营同事生成报表用…

我把团队云IDE的延迟从300ms降到了50ms，不是靠换更快的网，而是拆解了五层瓶颈，把WebRTC塞进JetBrains Gateway，又搞定了GPU显存零拷贝。本文从系统性能工程角度，还原网络、协议、渲染的深层次优化，并对比自建方案与GitHub Codespaces的真实成本和体验，给出选型建议。

把GPU推理成本砍掉67%的同时保持99.9%可用性，这听起来像天上掉馅饼。但我在帮一个日活30万的短视频平台做架构优化时发现，Spot实例的中断不是意外而是确定性事件——关键是在2分钟窗口内完成检测、摘除、迁移。这篇文章记录了从预热池设计到多区域切换的完整踩坑过程，以及三个让可用性从99.87%提升到99.96%的关键修复。

那天晚上，告警群炸了：推理延迟飙到2秒，客户在直播间等出图 事情得从去年夏天说起，我们团队负责一个内容平台的 AI 推理服务，日活大概 30 万，不算大但业务场景挺花哨——同时跑着三个模型：一个 BERT 做实时评论情感分类，一个 事故复盘：时间片共享的假象与 GPU 饥饿 接到报警时我正窝在沙发上…

在Jetson AGX Orin上部署YOLOv8，从45ms延迟艰难优化到8ms。详细记录了TensorRT层融合、INT8量化的校准集精度陷阱、DLA加速器的隐藏坑，以及用共享内存多模型流水线把吞吐拉到45fps的全过程。还有差点烧坏板子的散热教训和生产环境的自动恢复设计。