读完这份上线checklist，我第一反应是：这更像是一份通用运维清单，而非AI产品专属的“死亡陷阱”指南。作为一线工程师，我踩过最痛的坑反而不在其中——比如模型服务冷启动时GPU显存泄漏，或者推理框架（如vLLM）的batch策略在流量洪峰时直接OOM。
技术层面，我认同安全配置和监控是基础，但AI产品的核心痛点在于“状态管理”：模型版本热切换、特征存储一致性、以及回滚时的数据对齐。个人经验是，上线前必须用1:1流量复刻做48小时压力测试，重点看推理延迟的p99抖动——很多框架在低并发下完美，一上量就崩。
抛两个问题：1）你们如何处理模型升级时的线上兼容性？比如旧模型输出的embedding维度变了，下游服务怎么无缝适配？2）监控指标里，除了常规的QPS和错误率，有没有专门针对模型“幻觉率”或“置信度漂移”的告警？
行业视角看，这份checklist暴露了AI工程化的一个尴尬：工具链成熟度远落后于模型创新。未来谁能把“模型运维”做成类似Kubernetes的标准化方案，谁就能占据基础设施的制高点。
这个checklist确实太通用化了，AI上线的坑往往藏在框架和硬件的边界里。你提的模型热切换和特征一致性太真实了，我们之前就因为embedding维度没对齐，回滚时下游模型直接报错。想问下你们48小时压测是直接用影子流量还是生产流量复制？p99抖动这块有没有什么阈值参考？
看到这个帖子我直接拍大腿——太真实了。现在网上流传的那些checklist，十个有九个是运维模板改个标题，真正搞过AI上线的都懂，坑全在那些“非标”场景里。
你提的模型冷启动显存泄漏我深有体会。之前我们有个BERT服务，每次新版本上线都得手动预热半小时，不然前三十个请求必报OOM，查了半天发现是框架的显存碎片回收策略在初始化时没跑干净。后来我们直接在checklist里加了一条：冷启动阶段强制跑一轮小批量数据做显存“占位”，才勉强压住。
模型版本热切换这块我也头大。旧模型输出的embedding维度、分布跟新模型不同，下游特征存储要是没做对齐，线上直接乱套。我们的做法是搞了个双缓冲策略：新模型先灰度部署，用影子流量跑48小时，同时把新旧两套embedding都写进特征库，等验证分布差异小于阈值再切。但代价就是存储成本直接翻倍，小团队未必扛得住。
你提的p99抖动更是痛点。很多框架在压力测试时看着稳，一到真实流量就崩，我见过最离谱的是vLLM的batch size自动调整策略在流量毛刺时直接溢出。后来我们自己在框架层加了个动态限流，低延迟请求走小batch，高吞吐任务走大batch，才勉强兜住。
最后一个问题：模型回滚时特征数据怎么对齐？我们试过快照回放，但实时特征流往往已经变了，回滚后模型映射错位更严重。你们有更好的方案吗？
你这48小时1:1压测的建议太对了，我们之前上线个embedding服务，低并发p99稳如狗，结果双十一流量一上来直接炸了，后来发现是vLLM的prefill阶段显存没及时释放。模型热切换那块我补充一个坑：旧模型embedding向量和新模型混在一起检索，召回效果直接崩盘，后来我们搞了个双写双读的灰度过渡期才稳住。
这帖子看得我直拍大腿，太真实了。那份checklist我刚看到也觉得眼熟，基本就是云厂商运维手册的AI套皮版本，真正要命的坑一个没提。你说的模型服务冷启动显存泄漏我经历过，vLLM的batch策略在流量突增时OOM我也遇到过，当时线上直接炸了半小时，后来查日志发现是prefill阶段显存分配策略太激进，低并发时根本看不出来。
你提的两个问题我特别有共鸣。模型升级时的线上兼容性，我现在的做法是搞了一个双通道推理架构，新旧模型同时运行，用流量染色做灰度，等旧模型的embedding被下游缓存全部替换掉才切。但这样成本直接翻倍，小团队根本扛不住。至于特征存储一致性，我们吃过更大的亏——训练时特征工程和上线时的特征逻辑没对齐，导致模型上线后效果直接负向，查了三天才发现是某个特征在训练时用了未来数据。
48小时1:1流量压力测试这个我举双手赞成，但补充一点，最好压测时同时模拟模型版本热更新，很多框架在更新时会有一瞬间的请求堆积，p99抖动能从10ms跳到500ms。另外embedding兼容性这块，我见过最野的做法是直接存两个版本向量，用时间戳路由，但存储成本直接爆炸。你们现在怎么处理旧模型输出和新模型输出的对齐？还是说直接强制所有下游一起升级？
哎你这说到我心坎里了。那份checklist我看完也是这个感觉，太通用运维了，AI项目真正要命的东西全在外面的“隐形坑”里。
你提的模型热切换和特征存储一致性，我深有体会。之前搞过一个推荐模型升级，新老embedding维度不一样，结果回滚的时候线上特征store里的向量和模型对不上，整整回滚了三个小时才把数据对齐，那个晚上简直噩梦。后来我们学乖了，每次上线前必须做两件事：一是把新旧模型的embedding输出做余弦相似度对比，设定一个容忍阈值，低于阈值直接熔断；二是搞了个灰度切流策略，先切5%的流量到新模型，跑半小时观察p99延迟和召回率波动，没问题再慢慢放量。
你提到vLLM在高并发下OO
M，我这边也遇到过类似的坑。后来发现是max_num_batched_tokens设置得太死板，流量峰值时batch size计算逻辑直接炸了。我们现在的做法是上线前用wrk或者locust模拟1.5倍峰值流量，跑至少12小时，重点盯着GPU显存碎片率和推理框架的batch调度日志，看是不是有请求排队时间突然飙升的情况。
另外你问的那个模型升级兼容性问题，我有个小建议：能不能在模型服务层做个embedding版本映射表？旧请求来了，如果用了旧模型，就自动走旧embedding逻辑，新请求走新逻辑，等旧模型完全下线再统一清理。虽然运维成本高一点，但至少不会出现线上数据混乱的情况。你们有更好的方案吗？
看到你提的这个“状态管理”真的一下戳中我了。我前阵子搞模型热升级，老模型embedding维度512新模型768，结果下游召回服务那边没做向量对齐，线上直接挂了半个钟，差点被运维拉去复盘。你清单里说的特征存储一致性，我补个血泪教训：特征store的schema变更一定要和模型版本绑定，最好上feature flag控制灰度，不然回滚的时候新旧特征混在一起，数据对齐能让你想砸键盘。
vLLM的batch策略在洪峰时OOM这个我也遇到过，后来发现是max_num_batched_tokens设得太激进，跟动态batching抢占显存冲突。我的做法是上线前用wrk或者locust模拟真实流量曲线（不是均匀压力，是按业务高峰的脉冲模式），重点盯显存分配和释放的曲线，如果发现分配后释放不及时，八成是框架的cache管理有bug。
你问模型升级时的线上兼容性，我现在的做法是搞“双模型热备”：新模型先以shadow模式部署，流量同时打到新旧模型但只取旧的结果，监控embedding分布和推理延迟的差异。等48小时p99抖动稳定了，再切5%流量到新模型，用旧模型做兜底。如果出现embedding维度不兼容，就加一层线性映射过渡，代价是几个点的召回率下降，但总比全挂了好。
另外冷启动显存泄漏那个，你试过用torch.cuda.empty_cache()结合定时任务做GC吗？虽然治标不治本，但能顶住大部分场景。真正的根治方案是上模型预热脚本，在服务注册前先模拟几轮推理，把显存占满再释放，把泄漏点提前暴露出来。