我见过最典型的算法和infra矛盾现场基本是这样的算法同学跑了一版新模型评测指标肉眼可见涨了几个点兴冲冲要上线infra同学看了一眼显存占用和推理延迟直接来一句“这个结构线上放不下要不换轻量的要不砍一半特征”。会场瞬间安静接下来半小时双方都在用各自的话术互相说服谁也没被说服最后只能拉Leader来拍板。这不是某个团队的个例而是几乎所有上规模的AI团队都会遇到的常态。“算法-infra协同”这个短语听着像是组织管理里的套话但落到日常就是这些非常具体、非常磨人的瞬间。作为在算法和基础设施两边都待过的人我想把这几年来回切换视角看到的问题、踩过的坑、以及真正有效的协作机制完整梳理一遍。这篇文章不教你怎么调某个模型的参数也不讲某个分布式框架的源码而是讲把“算法”和“基础设施”这两拨人、两套系统、两种目标函数真正捏合到一起的方法论。适合正在带AI团队的Leader、被跨团队协作折磨的算法工程师以及明明做了很多事却不被理解的平台工程师。1. 断裂带是怎么形成的从单机跑通到大规模部署之间的巨大落差1.1 行业演进一个人全干的时代早就过去了大概在深度学习大规模普及之前算法工程师的工作模式很单纯从公开数据集下载数据在自己电脑上用sklearn或者一张消费级显卡跑通模型然后写一个简单的Flask或者FastAPI接口把模型封装成服务这事就算交付了。在那个阶段“infra”这个词根本不会出现在算法同学的词典里因为所有基础设施工作——装环境、起服务、管依赖——都是自己顺手做掉的。但后来事情彻底变了。模型从几百万参数涨到几十亿上百亿参数训练数据从几百兆涨到几个T线上请求从每天几百次涨到每秒几万次。任何一个环节单靠个人能力都撑不住了训练要分布到多机多卡推理要面对高并发和毫秒级延迟要求特征要从离线仓库和实时流里同时获取。于是基础设施团队出现了专门负责搭平台、管资源、做服务框架、做监控告警。也就是从这一刻起断裂带开始形成。算法同学的舒适区在Notebook、在实验脚本、在效果评测infra同学的舒适区在K8s集群、在服务框架、在延迟和吞吐指标。两边各自的专业性都在增强但彼此之间的理解并没有同步增强。1.2 两边口中的“算法”和“infra”根本不是同一个东西很多协同问题的第一步就卡在定义上。当你把两个团队的人拉到一起开会说“我们要加强算法和infra的协同”算法同学脑中的infra是“GPU资源管够、训练不卡、模型想上就上”而infra同学脑中的算法是“模型效果稳定、结构不折腾、上线不出幺蛾子”。再展开一点在算法团队的语境里infra至少包含这几层训练基础设施资源调度、分布式训练框架、数据加载与预处理流水线。推理服务基础设施在线服务框架、模型加速与量化、GPU/CPU资源管理、灰度发布与容灾。数据基础设施特征平台、离线数据仓库、实时计算链路、数据质量监控。可观测性基础设施监控、日志、链路追踪、告警体系。而infra团队面对的“算法”也不只是模型结构本身还包括算法同学产出的全部工作成果和工程产物训练代码、特征逻辑、模型文件、推理脚本、实验配置、上线策略。真正的协同不是两个团队彼此客客气气而是这两套体系的所有交接点都能顺畅运作。而现实是这些交接点恰恰是最容易出问题的地方。2. 认知错位是冲突的根源两种世界观、两套指标、五个高频摩擦场景2.1 算法在乎效果指标infra在乎系统指标两者之间没有天然的换算关系这是最根本的认知差异。算法同学说“这版模型效果不错”指的是AUC提升了0.3个点、点击率预估准确率改善了、线上实验正向。infra同学说“这版服务不行”指的是P99延迟从80毫秒飙到了200毫秒、可用性跌破99.9%、GPU利用率只有20%。这两套指标之间不存在一个公式可以直接换算。你很难说“AUC提升0.3个点等于P99延迟增加120毫秒的代价是否划算”因为这个权衡严重依赖业务场景。在离线推荐系统里多一点延迟也许可以接受在实时风控或者搜索场景下延迟每增加几十毫秒用户和业务方都会立刻感知。但两套指标最终是会通过同一个出口汇聚的——用户体验和业务成本。模型效果再好如果接口慢到用户流失那效果收益就被体验损失抵消了反过来infra把延迟压得再低如果特征缺失导致排序结果乱七八糟用户照样不满意。2.2 五个高频摩擦场景与它们的根因在几年的观察和实践里我总结出算法和infra之间最容易爆发的五个场景场景算法侧诉求infra侧诉求根因GPU资源之争要多卡并行跑实验快速验证想法要提高资源利用率控制成本实验的“任性”和平台的“可控”冲突特征上线流程改个特征逻辑想立刻生效要保证线上稳定走灰度发布迭代速度和变更风险冲突模型推理性能用复杂结构换效果提升要满足延迟和显存预算模型效果与系统资源冲突训练数据读取慢模型训练一半时间在等数据数据管道已经做了该做的优化小文件、随机读等数据工程问题被忽视代码与版本混乱快速改代码、快速上线要版本可追溯、可回滚工程规范和科研习惯的冲突逐个拆开看每一种冲突的根因都是同一个两个角色在各自的约束条件下做局部最优合在一起却不是全局最优。算法同学优先考虑模型效果最大化基础设施同学优先考虑系统稳定性和资源效率最大化而没有人对“整体最优”负责。2.3 拉齐目标函数的三个可行做法既然根源是目标函数不一致解法就是设计一个能让两边共同优化的目标。我见过真正有效的团队基本靠三招把效果指标和性能指标合并成线上综合收益评估。比如一个推荐系统把模型AUC提升带来的业务收益和延迟增加带来的体验损耗统一折算成对核心业务指标的影响。虽然折算系数不可能绝对精确但有了这个框架开会就不再各说各话。建立跨团队的共享OKR。算法团队和infra团队在季度目标里认领同一个数字比如“模型迭代上线周期从2周缩短到5天”或者“线上服务P99延迟维持在100毫秒以内且模型效果不降”。共享目标做一次两次可能觉得形式主义但连续几个季度拉通后双方的对话质量会有明显变化。把可观测性作为拉齐的前提。效果归因困难是互相甩锅的温床——一个线上效果波动到底是因为模型、特征、数据还是infra的抖动如果没有端到端的可观测数据争论永远不会结束。所以可观测性建设不是可选项而是协同的基础设施。3. 协同的四个主战场训练、推理、特征、调度3.1 训练侧协同资源分配与数据吞吐谁该让一步训练侧的协同常常被忽视因为直觉上觉得训练是异步任务“跑完就行又不影响线上”。但训练侧的摩擦一点都不少而且直接影响团队的迭代效率。先看数据加载。这是算法同学和infra同学最容易互相甩锅的地方。算法同学说“我模型结构没问题就是GPU利用率上不去训练速度慢得要命。”infra同学一看数据链路全是小文件一个epoch要反复随机读取几万个碎片文件IO全打到元数据服务上了。这里有个很多人都知道但经常不在实践中重视的规律分布式文件系统处理小文件极其低效。每个文件访问都要走一次元数据查询几万个文件就能让元数据服务成为瓶颈磁盘和网络带宽反而没有被充分利用。实操中怎么解决最直接的办法是把小文件合并成大文件用TFRecord、parquet这类列式存储或者SequenceFile这类行式存储统一封装让训练脚本只从几个大文件里顺序读数据。另一个常见优化是给数据加缓存层或者用内存文件系统做映射减少重复拉取。这些工作谁来牵头很多团队卡在这儿算法同学觉得数据管道是infra的事infra同学觉得数据格式得由算法定。我的经验是数据管道的所有权必须明确到具体的人否则最后一定是两不管。再看资源分配。一个中等规模的GPU集群通常被多个算法团队共享每个人都要开实验、都要复现论文。如果没有配额管理就一定会出现某个团队把资源全部占满、其他团队干瞪眼的情况。比较成熟的做法是分两层按团队定资源配额再在团队内部按任务优先级调度。重要实验比如线上模型升级高优探索性实验低优低优任务在资源紧张时可以被抢占。3.2 推理侧协同从粗糙Demo到高并发服务的性能鸿沟推理侧是冲突最密集的区域没有之一。原因很简单算法同学交付的模型是在离线环境里评估的而生产环境的水要多深有多深。两者的差距用一张表看最直观维度离线Demo环境在线生产环境显存单模型独占整卡多模型共享显存动态分配输入单张样本、离线批量高并发请求、流式数据延迟没有硬性约束P99、P999有严格SLA模型更新手动加载随时改需要热更新、平滑切换容错崩溃了重启就行限流、降级、熔断都要有这个鸿沟典型体现在批处理策略上。算法同学线下测的是单张图的推理延迟比如20毫秒觉得完全没问题。但线上真实流量是每秒成千上万个请求如果每个请求单独走一次推理GPU的算力利用不起来反而因为频繁的kernel启动和显存分配导致吞吐惨不忍睹。正确的做法是批处理batching把多条请求攒在一起喂给模型。但批处理会引入排队延迟——攒批次要等等得越久吞吐越高、单请求延迟越大。这个权衡怎么选取决于业务对延迟的敏感度。在风控场景里P99超过100毫秒可能就会导致大量超时在离线批量预测场景里吞吐优先批次可以调大。我见过不少团队在这个问题上反复折腾最后沉淀下来的经验是把批处理决策交给推理框架自己不要硬写。Triton这种专门为生产环境设计的推理服务器内置了动态批处理和并发调度比自己手写一个朴素的批处理逻辑要稳得多。还有模型复杂度和线上预算的矛盾。Transformer结构在离线评测里效果通常优于传统结构但推理开销也通常高出几倍。这个矛盾不能靠某一方单方面让步解决需要算法和infra一起来做联合优化infra了解推理引擎的加速能力比如TensorRT的算子融合、低精度推理算法了解模型结构里哪些模块是冗余的比如可以剪掉的头、可以蒸馏掉的层。两边各退一步通常能找到效果和性能的平衡点。3.3 特征平台被误解最多的“中间层”特征平台是算法和infra之间的灰色地带也是最容易出现“线上效果和离线评测不一致”的罪魁祸首。算法同学在离线训练里用了某些特征觉得效果很好上线后却翻车查来查去发现是训练特征和线上特征不一致——也就是业内常说的 training-serving skew。举一个最典型的例子某个排序模型在离线训练时用的特征是“用户的点击序列embedding”这个特征是在完整数据上算出来的。但到了线上serving环节用户的点击序列只能从最近一段时间的实时日志里恢复序列长度短了一大截embedding的结果自然对不上。算法同学离线评测看到的是“用了这个特征AUC提升了1个点”线上实际看到的是“这个特征根本没有起到预期作用”。解决training-serving skew只有一个可靠的办法训练和serving走同一套特征逻辑也就是建设统一的特征平台。特征在离线批量计算和在线实时计算中保持同一份定义算法同学不需要关心特征到底是怎么存储、怎么读取的只需要从特征平台里按名字取特征。谁来建设特征平台这通常需要infra牵头但算法必须深度参与——因为特征的定义、语义、有效性只有算法最清楚。实操中还要注意特征上线流程。特征变更在算法侧是家常便饭但在infra侧任何变更都需要版本管理、灰度发布和快速回滚。一个折中的办法是给特征建立独立的版本号模型训练时绑定特征版本线上serving时也必须加载同一个版本的特征。这样就能做到“训练什么线上就用什么”出问题时也能快速回滚到上一个特征版本。3.4 调度与弹性伸缩算法希望任性infra希望可控资源调度的矛盾贯穿算法-infra协同的始终。算法同学做实验时经常开一堆占着GPU但实际使用率不高的进程——比如在等待数据加载、在跑评测脚本、在调试模型。看一眼集群利用率报表infra同学血压就上来了明明资源被占满了有效计算率却低得可怜。处理这个问题有三个层次的解法第一层是配额管理按团队和项目设置GPU配额上限避免某个团队无限制占用共享资源。配额确定后算法同学能在配额内“任性”infra同学能保证整体可控。第二层是弹性队列和抢占机制。任务按级别划分低优先级任务在资源紧张时可以被挂起或抢占把资源让给高优任务。这个机制对算法同学来说一开始很难接受——自己跑了一天的训练被抢了谁都会火大。所以从机制设计上要保证任务能断点续训让被抢占的代价降到最低。第三层是在线离线混部把在线服务的空闲算力比如夜间CPU、低峰时段的GPU拿来跑离线训练任务。这是降本增效的大杀器但实施难度也最大因为它对隔离性、稳定性、可观测性的要求都非常高一般团队不建议一上来就做要先把前两层做好再考虑。4. 高效协同不是靠人情而是靠一套可复用的“协作协议”4.1 把需求从口头推进到文档RFC和接口契约很多协同问题出在需求根本不在纸面上。算法同学对infra同学说“我要跑一个新模型”然后第二天发现资源不够、数据格式不对、推理框架不支持于是开始扯皮——谁也没错错的是需求从来没有被正式定义过。解决这个问题最朴素也最有效的方法是把需求文档化。这里的“文档”不一定非要多正式几张PPT或者一页RFC都行关键是必须包含几个要素背景与目标、方案选项与取舍、资源预估、里程碑、风险点。infra同学看到一份写清楚的RFC比听十分钟口头需求要靠谱得多因为文档化的过程中很多隐藏的问题会被暴露出来——比如“这个模型参数量在Triton里要占多少显存”“数据从哪里来格式是什么量级多大”。接口契约也是同理。算法团队和infra团队各自维护自己的服务交接点就是接口。接口的输入输出字段、类型、语义、超时时间、错误码都应该以契约的形式定义下来。两边按契约独立开发联调时再处理边界情况而不是一边开发一边口头对齐。4.2 用性能预算和SLA数字说话协同中最讨厌的一句话是“你那边有问题”。什么算问题没有数字就没有判断标准。跨团队协作最有力的工具是性能预算。所谓性能预算就是为每个模型设定一组可量化的消耗上限推理延迟多少毫秒以内、显存占用多少GB以内、CPU使用率多少核以内、模型文件多大以内。超过预算的模型不允许上线除非业务方明确签字确认愿意支付额外的资源或性能成本。把这事做成文化之后算法同学在选型模型结构时就会主动考虑性能因素而不是等项目评审时才被infra打回来。infra同学也轻松很多不用每次都从零开始论证“你那个模型为什么在线上的表现那么差”直接把预算表摆出来就行。实操细节上性能压测报告是上线前置条件。压测不是简单地用curl打几个请求看响应时间而是要在接近真实流量的情况下测包括不同并发下的P99、P999、吞吐、资源占用等指标。这个工作最好由infra牵头搭建压测平台算法配合构造真实输入样本。4.3 可观测性建设让双方看到同一个全局算法和infra互相怀疑的时候最核心的问题是“信息不对称”算法看到的是自己的评测结果infra看到的是系统监控两边都有道理但看不到对方的全貌。可观测性建设就是来解决这个信息不对称的。一套对算法团队有意义的可观测体系至少包含三层Metrics指标除了传统的GPU利用率、QPS、P99这些系统指标还要加入模型侧和特征侧的指标比如模型版本、特征覆盖率、特征缺失率、推理超时率。算法同学不看GPU利用率但一定关心自己依赖的特征在线上到底有没有缺失。Logging日志线上请求的模型版本、特征版本、输入规模、推理结果都要记录下来。这样在复盘“线上效果和离线评测不一致”的时候可以精确地回溯到具体的输入和输出。Tracing链路追踪一个请求从进来经过特征服务、模型推理、后处理到最后返回每一步各花了多少时间。这样双方都能快速定位延迟到底出在哪个环节而不是凭感觉互相猜。把这三个层次做好之后线上排查的效率会提升一个量级。更重要的是它在心理上改变了团队的关系大家不再需要互相质问“是不是你那边出了问题”而是一起对着看板找问题。4.4 评审与变更流程质量与速度的平衡点算法团队迭代快infra团队变更重两者对“变更速度”的预期天然不一致。算法同学希望今天提的模型明天就上线infra同学希望任何变更都走完整的评审和灰度流程。这个矛盾不能靠一方妥协解决而是要设计差异化的变更流程。核心思路是区分“模型变更”和“系统变更”用不同级别的流程约束。模型变更是高频的走轻量流程性能预算检查自动、冒烟测试自动、灰度发布配合A/B实验。系统变更比如推理框架升级、基础设施重构是低频且高风险的走完整流程设计评审、压测验证、灰度观察、逐步放量。还有一个必须提前设计好的机制是快速回滚。模型上线后效果不及预期或者出现线上异常应该能在几分钟内回退到上一版本。这个能力不能等事故发生时再临时搭而是在每次模型变更时就准备好。我见过太多团队因为“回滚要重新出包、要重新走流程”而被迫在事故状态下硬扛这属于典型的工程基建不足。5. 一次从“互相甩锅”到“一起上线”的协同优化复盘5.1 问题背景一个推荐服务的P99抖动事故前面讲了不少方法论下面用一次真实的线上排查过程来串联。这是一个推荐服务团队遇到的典型问题上线了一个新的双塔召回模型离线实验显示推荐效果有提升但上线后监控显示P99延迟从80毫秒涨到了260毫秒。用户侧反馈“App变卡了”业务侧开始施压算法和infra两边进入经典的互相怀疑状态。算法同学说“模型结构完全合理离线单次推理只要20毫秒延迟暴涨跟我没关系。”infra同学说“服务配置和集群资源都没动过唯独模型从旧版换成了新版你还说跟你没关系。”两边都有道理继续争下去不会有结果。5.2 排查链路先看监控再定位热区紧接着我们开始联合排查。第一步看监控大盘发现一个关键细节P99延迟的抖动分布不是均匀的而是集中在晚高峰时段并且那个时段的CPU使用率没有满但内存占用比平常翻了一倍。这说明不是单纯的算力不够而是有额外的资源开销——大概率是内存分配和GC引起的。第二步看推理引擎的profiling信息。我们把线上模型跑了一遍profiling发现内存开销异常来源于模型输出层新模型输出的是一个特别长的dense向量长度是旧模型的4倍而且这个向量在后处理中并没有被完全消费白花了一大块存储和计算成本。这个链路在离线评测里根本暴露不出来因为离线评测只看AUC不关心内存开销。第三步排查特征侧。进一步发现特征拼接环节每次请求都会把用户和候选商品的全量embedding取出来其中很多embedding根本用不上——因为模型结构里加了attention池化但特征读取还是按照旧逻辑做的全量获取。每个请求的无效特征读取白白增加了30毫秒的IO和序列化开销。到这里延迟暴涨的根因终于清晰了并不是某个单一环节出错而是模型变复杂之后算法侧没有同步优化模型输出的消费逻辑infra侧也没有按新模型的推理特性调整特征读取策略。两边的懈怠叠加在一起P99就炸了。5.3 修复方案算法和infra各让一步定位到根因后修复方案反而是简单的。算法同学把模型改成动态长度mask只计算真实序列部分摒弃掉padding到定长带来的无效计算单次推理内存开销降了一半。infra同学把特征服务改成按需加载请求里用到哪些特征就只取哪些特征而不是把全量特征包一次性捞出。两边各改一块P99从260毫秒降回85毫秒甚至比旧模型还略低一点。这次事故给团队的启示不是“算法错了”或者“infra错了”而是两个团队在推进新模型上线时都只盯着自己那部分指标没有一个人从头到尾完整审视整条链路。性能问题的责任边界远没有想象中那么清晰。5.4 复盘之后沉淀下来的三条机制这次踩坑之后团队做了三件事直接改变了后续的协作方式把性能压测做进CI/CD流水线。从那时开始任何模型要发版必须先自动跑一遍性能压测给出延迟、内存、吞吐报告不达标就过不了流水线。这个改动看着简单但它把“性能问题上线前发现”变成了硬性流程而不是靠某个人自觉。建立模型-服务联合看板。算法和infra团队在同一个看板里看到模型指标和系统指标包括P99、QPS、显存、模型版本、特征覆盖率。出问题时双方一起看数据从根子上消除了“我看不到你的指标”这种争吵。每月做一次联合Review。会上不是互相汇报而是把过去一个月的线上异常、资源使用情况、模型迭代计划、infra变更计划全部摆出来提前识别风险点和资源冲突。6. 几次合作下来我总结的算法-Infra协同生存法则6.1 学会用对方的语言描述问题这是我感触最深的一点。很多矛盾的起点都不是立场冲突而是语言不通。跟infra同学说“模型效果不好”对方根本没办法行动——效果不好是AUC的问题、特征的问题还是数据的问题你得把问题翻译成对方能操作的术语“我的模型输入里的X特征在特征平台上有30%取值缺失导致线上排序结果比离线评测差了一截能否帮忙看下特征链路里X特征的计算逻辑是不是有bug”反过来也一样。infra同学跟算法说“你代码写得有问题”算法同学一头雾水。更好的说法是“这版代码在高峰期出现了明显的内存增长对象分配速率比上一版高3倍我怀疑是特征读取部分没有复用连接你看是不是这个原因”把现象和推测一次说清对方才能给出有效回应。6.2 先做能被度量的优化再做不能被度量的优化很多协同改进项目做不起来核心原因是它无法被度量。你说“我们要建设一个特征平台”预算申请怎么写收益怎么报决策者凭什么支持你但如果换一种说法——“现在模型上线平均要2周其中特征联调占4天做了特征平台之后特征口径统一目标是把模型迭代周期压缩到5天”——这就是一个能被度量和验证的目标。我见过的最失败的协同项目往往是花大力气搭了一个看起来很美的平台结果没人用因为它在“减少摩擦”这件事上没有明确的度量。容易被度量的优化包括模型上线周期、服务P99延迟、GPU利用率、线上异常恢复时间。不容易被度量的优化包括团队氛围、沟通效率、隐性知识沉淀。后者的价值未必更小但一定要在团队心智成熟后再推动。6.3 小团队靠默契大团队靠机制团队规模和协作方式要匹配。四五个人、一两个项目的团队每天坐在一起聊十分钟就能对齐硬套流程反而拖慢速度。这个阶段最重要的是人——有没有一个算法背景但愿意碰infra的同学或者一个infra背景但能懂模型的同学这个人就是天然的桥梁。但团队一过十个人、项目一多口头默契必然崩塌。“上次说好的”和“这次实际做的”对不上、线上出了事故找不到负责的人、模型发版没人敢拍板——这些信号出现就说明该建设机制了。文档化需求、评审流程、告警与on-call制度、SLA与预算、定期的联合Review这些机制不是负担而是规模变大之后维持信任的基础。机制建设的时机也很讲究太早大家觉得流程束缚人太晚团队已经在扯皮中损耗了大量信任。6.4 最后送你一份协同自查清单如果你正在带一个同时包含算法和infra的团队或者你正苦恼于跟对面的团队配合不畅可以从这份清单里挑几项评估一下模型上线前有没有自动化的性能压测报告还是靠上线后线上监控临时发现问题特征变更有没有版本管理和快速回滚方案训练数据管道的Owner是明确的还是算法和infra两不管算法和infra的指标在同一个看板上吗还是各看各的当模型效果和资源成本冲突时有没有明确的仲裁机制和拍板人资源配额是按团队和项目清晰划分的还是谁抢到算谁的模型版本、特征版本、代码版本能不能精确对应做到快速回滚这些问题每一条看起来都不难回答但真去核对的时候大多数团队都会发现自己有几个坑还没填。协同从来不是一劳永逸的建设而是持续对照、持续补漏的过程。在我个人的实际经验里凡是算法和infra配合顺畅的团队共同特点是双方都能理解对方的约束条件并且愿意在“整体最优”的框架下让渡一部分局部利益。这种默契不靠空喊口号靠的是一套双方都认的机制——文档、预算、SLA、可观测性、评审流程。机制先把对错边界划清楚剩下的沟通和信任才有生长的土壤。