1. 为什么一份两年前的AI框架白皮书今天翻出来读依然值得2022年那会儿AI框架这个赛道已经卷得不像样了。国外有TensorFlow和PyTorch两座大山国内百度飞桨、华为昇思、旷视天元、一流科技OneFlow各占一方。就在这个节骨眼上一份《AI框架发展白皮书2022年》出来了。我当时第一反应是又是一份PR稿吧但翻完之后发现它把AI框架这件事从“工具”层面拉到了“基础设施”层面来讲这个视角在当年并不多见。这份白皮书的核心价值不在于它预测了什么而在于它系统性地回答了三个问题AI框架到底是什么、它为什么重要、它往哪里走。这三个问题放到2024年来看答案已经发生了不小的偏移——大模型起来了Agent火了推理部署的需求爆炸了。但恰恰因为偏移了回头再看这份白皮书反而能看清哪些判断是靠谱的哪些是被高估的哪些是当时完全没预料到的。我写这篇东西不是要复述白皮书的内容。那种事官方摘要已经做得很好了。我想做的是以一个在AI工程一线摸爬滚打的人的角度把这份白皮书里真正有含金量的判断拆出来结合这两年实际发生的变化告诉你哪些东西值得你现在花时间去理解哪些东西你可以直接跳过。如果你正在选框架、搭训练管线、或者评估推理部署方案这篇内容应该能帮你省下不少试错时间。2. 白皮书到底讲了什么核心判断的拆解与验证2.1 AI框架的定位从“深度学习工具”到“AI操作系统”白皮书里有一个很关键的定性AI框架是人工智能时代的操作系统。这个说法在2022年听起来有点大但仔细想想是有道理的。操作系统管的是硬件资源、进程调度、内存分配、文件系统AI框架管的是算力调度、内存管理、算子优化、模型表达。两者的抽象层级确实在往同一个方向走。我当时对这个判断是半信半疑的。信的部分是框架确实在往底层走比如飞桨的编译器、PyTorch的TorchScript、TensorFlow的XLA都是在做“把模型翻译成硬件能高效执行的东西”这件事。疑的部分是操作系统有极强的用户粘性和生态壁垒而AI框架的迁移成本在当时看来并没有那么高——换个框架重写模型对有经验的团队来说也就是几周的事。但这两年发生的变化让我重新审视这个判断。大模型训练动辄几千张卡框架层面的调度效率直接决定了训练成本。一个通信优化做得好的框架能把千卡训练的线性加速比从0.7拉到0.9这背后是实打实的算力费用差异。当训练成本以千万计的时候框架的“操作系统”属性就凸显出来了——它不是可选项而是决定你能不能跑得起的基础设施。2.2 四大技术趋势哪些兑现了哪些还在路上白皮书里提到了AI框架的四个发展方向全场景覆盖、全流程支持、智能化、安全可信。我逐个说一下这两年的实际进展。全场景覆盖这块兑现得最彻底。2022年的时候端侧推理还是个相对边缘的话题现在呢手机、车机、IoT设备上跑模型已经是标配需求。飞桨的Paddle Lite、PyTorch的Mobile、TensorFlow Lite都在往这个方向使劲。但实际用下来端侧部署的碎片化问题比想象中严重得多。不同芯片架构、不同内存约束、不同算子支持度导致“一次训练、多端部署”这个理想状态至今没有完全实现。我的经验是端侧部署一定要在项目早期就做算子兼容性验证不要等到模型训练完了才发现某个关键算子不支持。全流程支持是另一个兑现得比较好的方向。从数据标注、模型训练、超参调优到部署监控主流框架都在往全链路走。但这里有个坑框架自带的工具链往往只适合“标准场景”一旦你的业务流程有特殊需求比如自定义的数据增强策略、非标准的评估指标、特殊的模型导出格式你还是得自己写插件或者绕开框架的工具链。我的建议是选框架的时候不要只看它宣传的全流程能力要看它的扩展接口是否足够开放、文档是否足够详细、社区里有没有人踩过类似的坑。智能化这个方向白皮书里讲的是自动超参搜索、自动模型压缩、自动算子生成这些东西。实际进展嘛自动超参搜索如Optuna、Ray Tune确实好用但“自动”的程度有限还是需要人工定义搜索空间。自动模型压缩在特定场景下效果不错但通用性一般。自动算子生成是个很有前景的方向TVM在这方面做了不少工作但离“开箱即用”还有距离。安全可信这块白皮书提到了对抗攻击防御、模型可解释性、隐私保护。两年下来隐私保护方面的进展最明显联邦学习和差分隐私的工具链成熟了不少。但对抗攻击防御和可解释性说实话工业界落地的案例还是偏少。大部分团队在安全上的投入还是集中在数据脱敏和访问控制这些传统手段上。2.3 国内外框架格局白皮书没明说但你应该知道的事白皮书在讲框架格局的时候措辞比较克制。但作为从业者有些话我可以直说。PyTorch在2022年已经确立了学术界和工业界研究阶段的统治地位这个趋势到现在没有改变。TensorFlow在工业部署侧还有不少存量但新项目的选择比例在下降。国内框架里飞桨的生态完整度是最高的从训练到部署到硬件适配都有覆盖而且中文文档和社区支持对国内团队确实友好。昇思在华为昇腾硬件上的表现有优势但跨硬件的通用性相对受限。OneFlow在分布式训练的一些场景下有性能优势但生态规模相对小一些。这里有一个选型时容易被忽略的点框架的“退出成本”。你选了一个框架训练了十几个模型部署了五六个服务这时候想换框架成本是极高的。所以选型的时候不能只看当前项目的需求要看未来两三年可能的业务方向。如果你未来可能要做端侧部署那框架的端侧支持能力就是必须提前考虑的如果你未来可能要用国产芯片那框架对国产芯片的适配程度就是关键指标。3. 从白皮书到落地AI框架选型的实操框架3.1 选型的第一性原理你的瓶颈在哪里我见过太多团队在选框架的时候陷入“功能对比表”的陷阱——把几个框架的功能列出来打个勾谁勾多选谁。这个方法不能说错但效率很低而且容易选错。更有效的思路是先搞清楚你的瓶颈在哪里。AI项目的瓶颈通常出现在四个地方训练速度、显存占用、部署延迟、开发效率。不同的瓶颈对应不同的框架优势。如果你的瓶颈是训练速度尤其是大规模分布式训练那你要重点看框架的通信优化能力。PyTorch的DDP、飞桨的集合通信库、OneFlow的流水线并行各有各的优化策略。实测下来在千卡级别的训练任务上不同框架的性能差异可以到20%到30%这个差距在算力成本面前是很可观的。如果你的瓶颈是显存占用那你要看框架的显存管理策略。PyTorch的显存碎片问题在长序列训练时比较明显飞桨和昇思在这方面做了一些优化。另外梯度检查点、混合精度、ZeRO这些技术的框架支持程度也要重点考察。如果你的瓶颈是部署延迟那你要看框架的推理引擎优化。TensorRT、OpenVINO、Paddle Inference、ONNX Runtime各有各的适用场景。这里的关键是训练框架和推理框架可以不一样。你完全可以用PyTorch训练导出ONNX然后用TensorRT部署。不要被“全家桶”思维限制住。如果你的瓶颈是开发效率那你要看框架的API设计是否直观、调试工具是否好用、社区是否活跃。PyTorch在这方面的优势是公认的动态图、Pythonic的API、丰富的调试工具让研究阶段的迭代速度很快。3.2 一个真实的选型案例从PyTorch到飞桨的迁移去年我参与了一个项目需要把一套已经在PyTorch上跑通的模型迁移到国产硬件平台上。这个项目的选型过程比较有代表性我详细说一下。第一步是算子兼容性评估。我们把模型里用到的所有算子列出来逐个检查目标框架是否支持。这一步就发现了问题有几个自定义算子只有PyTorch实现目标框架没有对应的版本。解决方案有两个一是用目标框架的基础算子重新实现二是用目标框架的自定义算子接口写一个。我们选了后者因为重新实现的风险太大可能影响模型精度。第二步是精度对齐。同样的模型权重在不同框架上的推理结果可能有细微差异。我们设了一个阈值相对误差不超过1e-4。实际测试下来大部分层的误差在1e-6到1e-5之间但有几层超过了阈值。排查后发现是某个算子的实现细节不同导致的调整后解决了。第三步是性能调优。迁移完成后推理延迟比PyTorch版本高了30%。我们用了目标框架的性能分析工具定位到瓶颈在某个卷积算子上。换了框架推荐的替代实现后延迟降到了原来的1.1倍。这个过程中框架的profiling工具好不好用直接决定了调优的效率。这个案例给我的经验是框架迁移不是“换个import”那么简单它涉及到算子兼容、精度对齐、性能调优三个环节每个环节都可能踩坑。选型的时候一定要把迁移成本算进去。3.3 选型检查清单我实际会看的几个维度下面这个清单是我自己在选型时实际会过一遍的分享出来供参考。维度具体检查项为什么重要算子覆盖模型所需算子是否全部支持不支持的是否有替代方案算子缺失是迁移失败的首要原因硬件适配目标硬件是否有官方支持性能数据是否公开硬件适配程度决定实际性能分布式训练支持哪些并行策略通信优化做了什么大规模训练的效率关键推理部署支持哪些推理引擎量化工具是否完善部署延迟和成本直接相关生态工具可视化、调试、调优工具是否完善影响开发和调优效率社区活跃度Issue响应速度、文档更新频率、中文支持遇到问题能否快速解决版本稳定性API变更频率、向后兼容策略影响长期维护成本这个清单不是让你逐项打分而是让你在选型的时候有一个结构化的思考框架。实际决策时权重最高的通常是前两项——算子和硬件因为这两项是硬约束其他项是软约束。4. 大模型时代AI框架面临的新挑战4.1 训练侧千卡集群下的框架瓶颈白皮书发布的时候千亿参数模型的训练还不是普遍需求。但现在大模型训练已经是很多团队的日常。这对框架提出了新的要求。第一个挑战是显存墙。一个千亿参数的模型光是权重就要占几百GB显存加上优化器状态、梯度、激活值单卡根本放不下。解决方案是模型并行但模型并行的实现复杂度很高框架需要提供足够好的抽象。PyTorch的FSDP、飞桨的Sharding、DeepSpeed的ZeRO都是在解决这个问题。实际用下来FSDP的易用性不错但在某些网络拓扑下通信开销较大DeepSpeed的ZeRO-3显存优化最彻底但配置复杂度也最高。第二个挑战是通信效率。千卡训练时梯度同步的通信量是巨大的。如果通信优化做得不好算力利用率可能只有50%甚至更低。框架层面的通信优化包括梯度压缩、通信重叠、拓扑感知的通信调度等。这些优化对普通用户是透明的但效果差异很大。选框架的时候如果有大规模训练需求一定要看它在类似规模下的实际性能数据。第三个挑战是容错和恢复。千卡训练跑几天硬件故障是大概率事件。框架需要支持checkpoint的快速保存和恢复最好能支持弹性训练——故障节点退出后训练能自动调整并行策略继续跑。这个能力在实际生产中非常重要但很多框架的支持还不够成熟。4.2 推理侧从“能跑”到“跑得便宜”大模型推理的成本压力比训练还大。训练是一次性投入推理是持续性的支出。一个日活百万的应用推理成本可能是训练成本的几十倍。框架在推理侧要解决的问题包括KV Cache管理、连续批处理、投机采样、量化压缩。这些技术各自能带来2到5倍的性能提升组合起来就是数量级的差异。KV Cache管理是其中最关键的一环。大模型推理时每个token的Key和Value向量需要缓存下来供后续token使用。如果管理不当显存占用会随序列长度线性增长很快就把显存吃满。vLLM的PagedAttention是一个很好的解决方案它把KV Cache分成固定大小的块来管理显存利用率能到90%以上。TensorRT-LLM也有类似的机制。连续批处理是另一个关键优化。传统推理是“一个请求处理完再处理下一个”GPU利用率很低。连续批处理把多个请求的动态合并让GPU始终有活干。这个技术对吞吐量的提升非常明显实测下来能有5到10倍的差异。量化压缩是降低推理成本最直接的手段。INT8量化能把模型大小减半推理速度提升1.5到2倍精度损失通常在1%以内。INT4量化更激进模型大小降到四分之一但精度损失需要仔细评估。框架对量化的支持程度直接决定了你能不能低成本地部署大模型。4.3 Agent时代框架需要提供什么新能力最近“AI Agent”是个热词阿里云也发了相关的白皮书。Agent对AI框架提出了新的需求。Agent的核心是“规划-执行-反思”的循环它需要框架提供几个关键能力一是工具调用Agent需要调用外部API、数据库、代码解释器框架要提供标准化的工具注册和调用接口二是记忆管理Agent需要维护短期记忆和长期记忆框架要提供高效的向量存储和检索能力三是多轮交互Agent和用户的对话可能是几十轮甚至上百轮框架要能高效管理长上下文。目前来看这些能力更多是在应用层实现的框架层的支持还在早期。但趋势是明显的框架会逐渐向上层延伸提供更多Agent原生的能力。如果你现在在做Agent相关的开发选框架的时候可以关注一下它在工具调用、记忆管理方面的支持程度。5. 实操避坑我在框架使用中踩过的坑5.1 版本升级的坑不要盲目追新框架版本升级是个让人又爱又恨的事。新版本通常有性能提升和新功能但也可能引入不兼容的变更。我踩过最惨的一次坑是生产环境用的PyTorch 1.8为了用某个新特性升级到了1.10结果发现某个自定义算子的行为变了导致线上模型精度下降。排查了两天才定位到问题。从那以后我定了一个规矩生产环境的框架版本升级必须经过完整的回归测试而且要在灰度环境跑至少一周。另一个经验是不要同时升级框架版本和CUDA版本。这两个东西的兼容性矩阵很复杂同时升级会让问题排查变得极其困难。正确的做法是先升级一个验证稳定后再升级另一个。5.2 分布式训练的坑通信瓶颈比你想的严重分布式训练的性能瓶颈十有八九出在通信上。我见过太多团队把注意力放在计算优化上结果发现通信才是大头。一个典型的场景是用NCCL做梯度同步在单机8卡上性能很好但扩展到多机16卡后性能不升反降。排查后发现是网络拓扑的问题——跨机的通信带宽远低于机内而框架默认的通信策略没有考虑这个差异。解决方案通常有两个一是调整通信策略让跨机通信量最小化二是用梯度压缩减少通信数据量。这两个方案框架通常都支持但需要手动配置。我的建议是做分布式训练之前先用框架自带的通信分析工具跑一遍看看通信占比是多少。如果超过30%那通信优化就是必须做的。5.3 模型导出的坑ONNX不是万能药ONNX是框架间模型交换的标准格式但它不是万能的。我遇到过好几次ONNX导出失败或者导出后精度不一致的情况。常见的问题包括动态shape支持不完整、自定义算子无法导出、某些算子的ONNX实现和原框架有差异。解决这些问题通常需要一是简化模型结构把不支持的算子替换掉二是用ONNX的扩展机制注册自定义算子三是在导出后做精度对齐测试。我的经验是如果你的模型要在不同框架间迁移最好在模型设计阶段就考虑ONNX的兼容性。比如避免使用框架特有的算子尽量用标准算子组合来实现功能。这样后续导出会顺利很多。5.4 常见问题速查表问题现象可能原因排查思路解决方案训练loss不收敛学习率设置不当、数据有问题、算子实现差异先用小数据集过拟合测试调整学习率、检查数据管线、对比算子输出分布式训练加速比低通信瓶颈、负载不均衡用profiling工具看通信占比调整通信策略、优化数据分片推理延迟高算子未优化、batch size不合适、显存瓶颈逐层profiling定位瓶颈换优化算子、调整batch策略、用量化模型导出失败算子不支持、动态shape问题逐算子检查导出兼容性替换算子、固定shape、用扩展机制显存溢出batch太大、激活值未释放、显存碎片用显存分析工具看占用分布减小batch、用梯度检查点、调整显存分配策略6. 框架的未来从白皮书到下一个三年白皮书里对AI框架未来的判断有些已经兑现有些还在路上。站在现在这个时间点我觉得有几个方向是值得关注的。第一个方向是框架和编译器的融合。TVM、MLIR这些编译器技术正在被越来越多的框架采用。未来的框架可能不再是一个“运行时”而是一个“编译器运行时”的组合。你写的模型会被编译成针对特定硬件优化的代码性能会比现在的解释执行方式好很多。第二个方向是框架的“去框架化”。随着ONNX、MLIR这些中间表示的发展模型和框架的耦合度在降低。你可以在PyTorch上训练导出成标准格式然后在任何支持这个格式的运行时上部署。框架会逐渐变成一个“开发工具”而不是“运行环境”。第三个方向是AI框架和云原生技术的结合。Kubernetes、Ray、Volcano这些云原生技术正在和AI框架深度融合。未来的训练和推理任务会像现在的微服务一样在集群上动态调度和弹性伸缩。框架需要提供和这些云原生基础设施的标准化对接能力。这些方向不是孤立的它们会相互促进。编译器技术让框架能更好地适配多样化硬件去框架化让模型能在不同运行时之间自由迁移云原生让算力资源能更高效地利用。这三个方向叠加起来会重塑AI框架的形态。我在实际项目中的体会是不要被“框架”这个词限制住。框架只是工具你的目标是高效地训练和部署模型。如果某个场景下不用框架反而更简单那就不要用。如果某个框架的某个功能不好用那就绕开它用更底层的接口或者第三方工具。保持灵活性比忠诚于某个框架重要得多。最后分享一个小技巧如果你在选框架的时候拿不定主意可以试试“一周原型法”。用候选框架各花一天时间搭一个最小可用的训练和推理管线跑通一个简单的模型。这个过程能暴露很多文档里不会写的问题比如安装配置的复杂度、API的直观程度、调试工具的可用性。一周下来你对该选哪个框架会有更清晰的判断。
