人工智能正经历一场由大模型引发的革命。这些拥有数十亿甚至万亿参数的庞然大物，正在重塑我们对 AI 能力的认知，也构筑起充满挑战与机遇的技术迷宫——从计算集群高速互联网络的搭建，到训练过程中模型稳定性和鲁棒性的提升，再到探索更快更优的压缩与加速方法，每一步都是对创新者的考验。

面对快速演变的市场，企业如何在大模型投入与应用间寻求平衡？AI 从业者又该如何在这复杂的产业生态中找准定位，最大化自身价值？这些问题不仅关乎技术与商业，更直指 AI 产业的未来走向。

本期机器之心《智者访谈》邀请到腾讯机器学习平台部总经理／混元大模型负责人王迪先生，深入腾讯从 0 到 1 自研万亿级 MoE 大模型的历程。

王迪强调，大模型是一项跨领域的系统工程，需要在约束下高效整合工程、算法、数据和业务应用，对组织能力提出了前所未有的挑战。同时，业务团队需要明确模型的能力边界，辨识哪些问题适合用模型去解决，哪些则需要通过产品设计来应对，只有技术与业务紧密协作，才能快速推出满足应用需求的 AI 产品。

腾讯的这条实践之路，让我们得以窥见大模型研发和工程的整个链路：从基础设施的构建到训练推理框架的优化，再到业务场景的落地，为理解大模型提供一个独特的视角。

时间戳

01:07

小模型成趋势的深层逻辑

05:54

腾讯为何选择从零自研大模型

10:37

MoE Scaling Law：腾讯的着眼点

20:22

布局全模态：统一到 Transformer

23:06

平台层如何衔接上层应用与下层算力

35:39

技术路径选择：直觉从何而来？

39:55

万亿 MoE 实践：稳定性、鲁棒性

48:10

算力集群发展及 AI Infra 展望

访谈文字整理

机器之心：王迪老师好，非常高兴您做客机器之心的《智者访谈》。腾讯作为国内，应该说是全球范围内为数不多的几家能够支持万亿乃至更大规模参数的模型，以及相关基础设施平台的机构之一，我们希望这次访谈能够从您这里获得关于大模型、机器学习平台以及 AI 基础设施方面的洞见。

王迪：好的，谢谢。

机器之心：前段时间 GPT-4o mini 发布，OpenAI 也开始做小模型了，以它为代表，目前小模型也成为一种趋势。从您的角度，如何理解 OpenAI 的这个举措？

王迪：GPT-4o mini 替换了 GPT-3.5，效果好了很多，速度也是非常非常快。但是，你刚才说 OpenAI 是不是突然做小模型，其实不是这样的。实际上，GPT-3.5 本身的 size 就是相对比较小的，激活参数也是比较小的，所以它才能做到那么快。

GPT-4o mini 出来之后，能够很好地替换 GPT-3.5 这样的模型，我觉得这可能还是一种需求导向，因为很多应用可能不需要像 GPT-4 Turbo 或者 GPT-4o 这样一个更大或者延时更高的模型，对于它们的场景来说，像 GPT-3.5 或者 GPT-4o mini 这样一个很快的模型已经足够了。

想把模型做小，首先需要能够把模型做大，因为单纯做一个小模型是很容易的，比如我们做一个 3B 的、1B 的，或者 1B MoE、3B MoE 这样的模型很简单，但是要保障 3B 小模型的效果也非常好，这就是一件很难的事情，需要在数据上、模型架构上做很多独特的工作。

GPT-4o 是一个端到端的全模态模型，它有两个方面令大家印象很深，一是加入了语音，这是模态方面或者用户体验方面不太一样的地方。还有一点，它的速度非常快，端到端的延时只有 300 毫秒左右，同时又保持了语言模型非常好的智能。这种情况下，我们判断 GPT-4o 的模型效果非常好，它的模型 size 应该不会很小，这是一个常识问题。模型 size 不太小的情况下，延时又很低，那么它在整个模型架构，包括 Transformer 计算方面，应该做了很多能够节省耗时的优化。

这会对很多业务场景带来无限的想象力，比如实时客服的对话，打游戏的过程中真人和 NPC 之间更好的交互，以及社交场景的沟通等等，实时语音交互会带来全新的体验。

机器之心：可不可以这样理解，OpenAI 如今发布模型时也是非常考虑应用侧需求的？

王迪：我觉得是的。因为模型做得再好、做得再大，最终还是需要结合业务场景，看能不能给用户带来价值。所以，自然语音的交互，包括未来视频的交互，实时的视觉交互，是非常重要的。

但这并不代表 OpenAI 没有持续投入研发更好的模型，比如他们一直在说的 GPT-5，包括前段时间 Sam Altman 说他们对 AGI 路线的规划，对行业还是非常有启发的，也能证明他们在 AGI 目前还没有很好解决的技术问题上，还在不断尝试和布局，这些是值得我们整个行业从业者学习的。

比如他们会提到，当前 GPT-4 这类模型的智能所处的阶段可能类似于一个高中生，或者刚上大学的本科生的水平，18 个月之后，他们希望新一代的 model 达到博士生的水平，这中间可能还有哪些方面需要突破呢？

规划的能力、深度推理能力，面对一个很复杂的任务，模型需要首先把它拆分成若干个子问题，每一个子问题可能还需要联网、需要计算、需要判断，然后再串行起来，这样已经非常像人在解决一个复杂问题时的表现。这些背后我们看到的是，OpenAI 如何把模型能力跟人类解决复杂问题的分析、推理工作相结合，这也体现了 OpenAI 现在思考的一些问题的方向。

机器之心：回到国内，关于开源和闭源的讨论也有很多，腾讯选择从零自研万亿规模的大模型，这到底能够带来什么价值，您能分享一下吗？

王迪：这次以生成式 AI 为代表的人工智能的突破性发展，我们认为可能是几十年，甚至百年一遇的技术革新和革命。在这种情况下，我们并没有那么着急拿一个开源的模型迅速在业务上做一些精调，然后上线，这可能会很快（出结果），但会带来一个问题，那就是我们不知道这个新的技术从底座开始，它的运行机制是怎么样的，优点缺点是怎么样的。

比如我们看 OpenAI，从 GPT-1、2、3 到 Codex——Codex 是非常重要的一个阶段性产品，后来到 3.5，也就是大家所熟知的 ChatGPT，然后 GPT-4、GPT-4 Turbo，到现在的 GPT-4o，可能未来的 GPT-5，在这样一个过程中，我们发现它的技术路线的演进是非常清晰的，包括每一个阶段、每一个模型相比以前解决了什么新的问题，OpenAI 是非常清楚的。

其实我们更想要探索这样一条路经，在这个路径中学会怎么样训练一个千亿模型，接着才会知道怎么训练一个万亿模型，万亿的模型做出来之后发现，它的性能刚开始不够好，我们才能知道怎么做自己的混元的 Turbo 的 model。做了这些之后，你会发现可能需要加语音，可能需要加视频……这个过程，如果我们只是去看别人是怎么做的，由此得到的感知和认知就会非常肤浅。

我们自己做了，从服务器的搭建、网络的搭建，包括训练平台的搭建，一步一步训练过程中，自然会知道哪里是核心的重点，哪里是有问题的，我们需要进一步优化。整个过程中，就会走出我们自己的，也就是腾讯公司大模型的技术路径和路线，也才能知道这次的人工智能技术的演进是这样的，怎么样才能更好支持业务的发展，这是非常有价值的。

机器之心：之前跟高校的老师交流过，说哪怕是小模型，也得自己从头训过一遍才知道有哪些问题，包括最基础的问题是如何让卡几小时不要发生故障。

王迪：这个你说得非常对。小模型训练本身可能对资源需求不是那么大，但训好也不是很容易的。很多公司在一些 1B、2B、3B 的模型上已经得到很好的效果，背后从数据到训练框架，到训练策略，包括模型的设置，对齐的一些数据、思路和方法，都是有很多讲究的。

机器之心：不过，训练一个 1B 的小模型，这个经验能够迁移到更大的模型上去吗？

王迪：这正是我们行业讲的，要探索 Scaling Law，比如我们做 MoE 的万亿的模型，首先行业没有先例，同时我们的资源相对是有限的。在资源相对有限的情况下，怎么预判，比如说数据分布是怎么样的，MoE 的专家数怎么设置，激活参数怎么设置，包括路由，每一个 token 到底路由到哪个专家，怎么样才是合理的，这个事情很复杂，可能中间我们要考虑的因素有大几十个，这种情况下，不可能一次做一个实验，用很多卡去做，时间也来不及。

因此，一定是先在很小的模型上，比如刚开始可能是 10M，然后 30M，1B、3B，这样一些不同 size 的模型上探索，最后预测出来我们要做一个万亿的 MoE 怎么样选择中间的设置，以及预测最后训练了多少 token，我们的 lost 会收敛到什么样的点，这样的一个过程，就是我们在探索 MoE 的 Scaling Law。

如果没有这个工作，研发效率会非常低。也不是不能做，当你有无限多的资源，无限多工程师的时候，就可以做。但现实来讲，做大模型就是一个在约束条件下怎么样高效地把工程、算法、数据以及业务应用整个串联起来的工作，它对组织能力的要求是非常高的。

机器之心：您提到了 MoE Scaling Law，这跟一般说的 Scaling Law 有什么区别？

王迪：从概念上并没有本质的区别。Scaling Law 是什么？就是去判断我的模型 size 怎么样增长，到什么程度，然后在我们自己的数据集上，预测我的模型最后收敛到什么地方，收敛的结果是否符合我们的预期，这样一个工作。至于是基于 dense model 做还是基于 MoE 做，没有本质的差异。

但是在选项方面不一样，因为 dense 模型，参数的选择、激活函数的选择，包括 tokenizer 等等，要做的实验会比 MoE 少很多，因为 MoE 有很多个专家，每层的专家数量是否相同也不确定，激活个数也不一定每层都是一样的。

探索 MoE Scaling Law 相当于是在实操上把事情难度变大了一些，可能大家要做一些更加细致的工作，更加高效的实验，把自己的 Scaling Law 做得更好。这样的话，去做一个万亿的甚至未来更大的 MoE 就会更有信心，浪费的时间更短。

机器之心：您认为 Scaling Law 接下来空间还有多大？我们目前红利还有多少？

王迪：首先现在 Scaling Law 还没有失效。其次我是从另外一个视角看这个问题，不能单独看 Scaling Law，因为我们是在做系统，是在做一个真正的模型，它一定是有约束的，也就是说资源是有限的。资源分几方面：第一，最大的就是算力资源，总是有限的；第二，时间也是有限的；第三，数据也是有限的。

这三个约束条件之下，我们要动态看待这个问题。今时今日和去年相比，你会看到今年小的模型要比去年的一些大模型要好，为什么？数据是很重要的原因。在很多公司里，数据是一条研发线，数据质量持续提升，数据的分布足够多，数据的配比足够好之后，即便是一个小的模型，什么都不干，可能在新的数据集上训练出来的效果，也会比去年一个相对更大的模型要好。从这个角度讲，可能模型并没有变，但 scaling 的效果可能已经不一样了，所以这也是 Scaling Law 需要考虑的一种情况。

另外模型结构方面，你也会做很多调整，比如 MoE 我们怎么做激活，怎么选择专家，保证 tokenizer 怎么设置等等，都会影响你的 Scaling Law。去年我的 Scaling Law 是这样子的，今年其他地方改变一下之后，发现我的 Scaling Law 最后收敛效果更好，这也是会发生的。

所以我为什么说要动态看这个事情，所有东西都不变，就是增大资源、增加数据，这样做效率很低的。在实践中，我们看到的是数据变得更好了，模型的算法做了一些优化之后，它能够带来的价值是更大的，然后再配合上 Scaling Law，整个的发展就会非常好。

去年很多人还担忧大模型应用的成本问题，其实我去年一点不担忧，为什么？我们不是简单看成本，成本一定要跟效果相结合的。比如说，我们今年在某个问题上，就可以用比去年还要低的成本去实现跟 GPT-3.5 Turbo 相当的效果，如果这样看成本，相比去年可能是几十倍的下降。我们再去预测明年，比如我们现在看 GPT-4o，它的端到端延时很短，如果只是看成本，不考虑延时，是一方面，如果把延时考虑进去，对用户的体验来讲，整体成本就会下降非常多。

机器之心：非常有启发。腾讯选择 MoE 架构，所有专家都是在一个高维空间里面，我们并不知道具体激活的是哪个，万亿 MoE 模型就更复杂了，对此您是怎么看的？

王迪：其实去年我们在研发的时候，中间还是走了一些弯路的。可能一开始大家直观的感觉，专家指定好，最简单，确实这样做风险是最低的，因为训练最容易收敛，行业上，包括学术界，很多也是这么做的。

但后来我们发现这样做存在一些不合理的地方。比如说一篇文章，到底是属于科技、财经，还是数学？一道物理计算的问题，它里面又有数学、又有逻辑，又有物理，到底应该分到哪个专家呢？

后来我们觉得既然做大模型了，为什么还要做人工设定的东西呢？就应该让模型自己学习，后来我们没有任何的人工指定，任何一篇文章出来，每一个 token 是基于整个 MoE 的网络的 gating，它自己选择应该去到不同的专家里面。进去之后，确实很难解释哪个专家负责了什么。但最后我们还是分析到，不同的专家还是有一定差异性的，不同层的专家也有一定的差异性，但是差异的程度是不一样的。越往上层的专家彼此间的差异性越大，就像人一样，最上面毕竟是要干交付的，工种还是不一样的，有的比较擅长数学，有的比较擅长英语，但底层的这些，可能相对来讲更多学习到一些语言的表征、语法等等这样一些比较粗的特征。

其实我们看到，越是坚持这些最基本认知的东西，你会发现大模型它自然会学到很多东西，你越是加很多规则、人工的经验进去，越会发现这个东西不 work，有无穷无尽的麻烦要解决。

接下来 MoE 需要优化和提升的地方还有很多，其中有一点，MoE 存在训练效率的问题，它比 dense 模型训练效率的提升要难很多。理论上讲也是这样的，MoE 有很多个专家，专家数相对来说越多越好，但是我们又希望模型要高效，高效的话每次就只能激活少量的专家，只激活少量专家的话，算力利用率就不会很高，这样在整个过程中，计算和通信之间的配比如何设置，才能让训练更加高效，这里面就有很多的讲究，比如说怎么样在保证效果的情况下，让训练变得更快，比如说 batch size 变得更大，但是 batch size 变大后梯度同步就会变少，效果就会变差，这种情况下怎么办。

这些问题其实学术上也会有一些论文去探讨，包括我们前一段也发表了一些论文，还有一些面向新的，比如说关于视频的理解和生成，在一个 model 的话，那我的窗口变得更大，这在今年上半年国内也是一个热点。

但国内的讨论更多的还是说怎么样去做长窗口的文本类的理解，大家很少去讨论模型百万级的窗口、千万级的窗口该怎么去训练。我说的是原生长窗口，RAG 不算，尽管 RAG 很重要，但是原生长窗口，比如说视频的训练 1 分钟可能需要百万级的 token，如果我们想做 10 分钟该怎么办，40 分钟呢？

不知道你有没有注意，我们最近在元宝上跟《长相思》合作，有一个相柳 AI bot，我看到我们的用户每天跟它交流有高达几千轮的，那这几千轮下来，用户会觉得已经把相柳 bot 变成自己心目中的相柳了，希望它能记住所有的对话，但这对技术要求是极其高的，怎么样在每一次回复的时候，让模型能把之前几千轮的内容自动从里边筛选出来，然后回复跟这次相关的一些东西。

所有这些都是我们在 MoE 架构下未来需要去进一步优化和探索的，包括专家的平衡，包括更高效的训练。所谓高效本身也不是一个简单的工程问题，它是一个带效果约束的高效，比如长窗口下如何更高效，我想训练更多的 token，那我的训练速度要更快，训练速度更快，怎么保证效果，等等这样一系列问题。

机器之心：腾讯也在做文生图等多模态相关的工作，在模态统一方面您有怎样的预判？

王迪：谈不上预判，因为这是今年整个行业，不管是工业界、学术界大家都非常关注的一个方向，腾讯这边也是在积极地布局。我们现在是多模态的，未来也会向全模态的方向去演进。输入是文本、图片、视频、音频，输出也是这样的 4 种模态。

但这还需要挺长的路去走，为什么？视频生成本身最近几个月国内外大家的进展都蛮快，虽然效果很惊艳，但是离工业界、离真正人人可用的效果还是有一定的差距，当然相比于过往来讲已经有一个飞跃性的进步了。但不管是 OpenAI 还是 Google，现在对视频生成这块还是用相对独立的 model 去演进和发展。

我们认为未来一定会走向一个统一的 model，但还需要一定的时间，包括是基于 diffusion 还是说基于自回归的 model，现在图像和视频生成领域可能 diffusion 的多一点，尤其在工业界，但是学术上也有全自回归的 model，各有优劣，我觉得还是需要一定的时间去验证它的效果和利弊。

机器之心：从您的角度是不是比较难下一个定论，说我们会都统一到 Transformer，还是说 diffusion model 和 Transformer 两者结合，或者说一个全新的架构？

王迪：目前来讲，统一到 Transformer 这样一个总的框架下，应该是没有太大疑问了，即便是 Sora 用的 DiT，也是用 Transformer 实现的 diffusion model，所以说已经完全离不开 Transformer 了。至于说还要不要 diffusion 这样一套思想，现在还没有定论，因为还有很多的地方需要去实践和实验。

机器之心：例如不同的场景，有些时候 diffusion 可能会更好一些？

王迪：对，是的。多模态或全模态的端到端架构，现在不管是学术界、工业界大家都在积极探索，我们看到还是有很多地方，还有一定的不确定性，比如说 tokenizer 怎么做，音频的，视频的，包括之前说的按照最后的生成，到底基于自回归还是 diffusion，未来终局怎么样等等，这些地方我的看法是，它们本身不能孤立去看，算法怎么样、模型怎么样，一定要跟工程、平台一起去看。

机器之心：上次我参加了元宝的媒体沟通会，让我非常印象深刻的是，因为腾讯有大量的应用，并且是大规模的应用，有的问题别的公司还没遇到，腾讯就已经解决了。您作为腾讯机器学习平台部总经理，从您的角度，平台层怎么样去协调好上层的应用和下层的算力？

王迪：在腾讯我们确实有很好的实践经验。我们的模型训练好之后，第一步就要满足公司所有业务的需求，比如说我们的 QQ 浏览器、腾讯新闻、微信读书、微信公众号、广告、客服、游戏……方方面面的需求。我们的模型在内部是给我们的这些业务开源的，大家可以去调用我们的模型，针对自己的业务场景对模型再做进一步的精调，去改各种 lost，都是 OK 的。

但最后上线时，还是会有各种各样个性化的需求，比如说有的业务觉得模型速度还是不够快，有的业务可能只有一些低端的、很早以前的推理卡，对这些业务来讲，它受约束的资源层面，我们的模型效果，包括训练和推理的平台，算力调度等等就要去做很多针对性的优化。这些针对性的优化，后续会沉淀为平台的一部分能力，提供给其他的业务。

例如腾讯会议，大家可能会用到一个叫 AI 小助手的东西，我们去年就开始跟腾讯会议的团队合作。一开始我们是用一个千亿的模型支持他们，效果还不错。但他们上线的时候发现速度太慢，再来每天开会的用户很多，成本也很高，那怎么办呢？我们就需要把这个模型精减下来，刚开始精减成 70B 的 dense model，很快能满足业务的需求了。

但由于是会议场景，经常有用户询问会议中的相关内容，有时候可能还要等个 4、5 秒，还是觉得慢，怎么办呢？正好我们有一个 7B MoE，发现效果跟 70B dense 模型效果差不多，那么我们就用 7B MoE 再去替换。替换过程中，由于这个 7B MoE 最终要部署在腾讯会议的计算集群里面，硬件又有一些部署的要求，比如通信的效率、显存的利用等等，那这些又会对我们的训练框架，甚至是对我们 7B MoE 的模型设计本身提出了一些新的要求。最后我们发现，对腾讯会议这个场景，就是一个相对来说定制的 7B MoE、3B MoE 这样一些很小的模型，就能很好地满足业务的需求。

机器之心：混元大模型目前在腾讯内部支持了近 700 个业务，并可能继续增长。从支援的角度，您从这些应用里面发现了哪些问题？进行了哪些创新？

王迪：现在确实混元在公司集团内部的应用需求量越来越多，包括推理的规模也是日益变大，速度越来越快。在这个过程中我们发现，集团很多的业务其实已经不再只是把混元大模型用来解决单点的业务需求，不是像去年或者更早的时候，需要做一个摘要、做一个总结这样的单点，现在更多是全链路的一些接入。

比如腾讯广告的场景，从去写一个广告开始，到审核、入库、对用户的理解，再到在线广告的匹配，整个广告体系里所有能够使用大模型去提高效果的、提升效率的，比如说通过妙思平台的文生图功能，让广告主创作广告时有更多的创意，创造出的广告更加适合最后用户的体验等等，它是一个全链路接入混元的过程。

机器之心：这又回到了您刚才提到的系统性工程，包括现在业界也是在强调，不是一个应用调用了大模型就完了，而是要真正去看模型对整体工作流程的影响，如何融入已有的工作流程，包括优化甚至改变既有的工作流程，这方面腾讯是不是已经有一些业务因为大模型而改变了？

王迪：还是举广告这个例子，因为广告主会上传很多广告素材，这个规模是很大的，这些素材需要审核，以前审核系统里面还需要一些人工，或者说是一些传统的 NLP 或多模态的模型再去做审核，这个过程其实效率是比较低的。现在整个广告都是 AIGC 的，生成的过程自然就知道，整个提效非常明显。

机器之心：腾讯会议、微信读书、腾讯音乐等所有业务都是由您这边来支持，他们的需求各不相同，在人员、资源以及方法上面，您是如何操作的？

王迪：这个问题要分好几个层面，第一，我们做大模型的目的是什么？就是为了一个模型去解决很多不同的问题，通用性很重要。因此，很多需求默认是首先去看通用的 API 能不能解决问题，当你模型足够好的时候，绝大部分的问题是能直接解决的。这样相对来讲，绝大部分需求用 API 就直接搞定了。

但坦白说，模型当前阶段在很多的垂直业务场景还没有那么好，达不到 99% 的精准度或者这样的一些场景要求。这时候我们的做法是，在公司内部有一个太极混元一站式的平台，我们所有的模型在这个平台上是对所有公司业务开放的。

公司业务的团队，他们也有一些做 NLP、做多模态算法的同学，他们拿到这些模型之后，可以针对业务场景做一些自己的精调，之后很快就满足业务需求了。有一些业务团队可能没有做算法的同学，但又很着急要上线，这时候我们的团队就会有少量的同学去支持他们，因为这个业务场景很重要，虽然它是个垂直的场景，但是因为通用的 API 还不是足够好，那么我们针对这个业务场景去做一些优化，比较少的情况是还需要下沉到预训练去做一些优化，大部分是 post-training 阶段做一些优化后，这些数据很快就会在独立的垂直业务场景满足业务需求了，业务那边很快就能上线了。

但事情并没有结束，这部分独立的优化数据，我们在征得业务场景同意，进行相关处理，比如去掉敏感信息之后，会把这些数据反哺到我们底座的模型。因为我们的底座模型有一个周期性迭代的节奏，在下一个版本，甚至下下个版本，我们整个底座就会很好地支持这个垂直场景的需求，那么这个垂直场景就不需要专门的优化了，专门的模型都不需要了。

尤其是腾讯会议、腾讯文档，这类业务的一些需求并不只是代表他们自己，也代表了很多公司，包括整个 B 端市场很多创作类的、长文阅读理解等等的需求。因此，做好一个场景，反哺底座模型后，就足够支持更多的一些需求，最终我们的底座慢慢地就会以 API 的形式默认支持绝大部分的业务需求，所以我们很少的人可以支持公司数百个业务各自特殊的需求。关键是说要有一个内部的太极混元一站式平台，在这个平台上我们可以方便地让业务同学自助做精调等操作。

机器之心：您刚刚提到混元一站式这个平台，它跟 Angel 机器学习框架有什么区别呢？

王迪：它们是在一起的，Angel 机器学习平台我们做了十多年了，而且很多地方已经对行业开源了。Angel 机器学习平台是训练和推理的框架，相当于是中间最核心的一层。

太极混元一站式平台有一个 web 用户界面，我们的同事进来之后，可以看到所有的模型都在这里，可以选一个模型快速导入自己的数据，自动调用底层的 Angel 训练框架和推理框架，能快速地看到自己的模型训练出来，快速看到模型的推理效果，包括评测、最后的模型发布这些都能看到。这个一站式的平台所有东西都在一起的。

机器之心：刚刚聊了您的团队如何支持各个业务，那么作为您的客户，比如说我现在是腾讯会议的算法或工程人员，是选择调用 API、拿来精调，还是说其他的方式，对于如何用好大模型，您有什么建议吗？

王迪：建议谈不上，我可能说一些比较常规的做法，因为公司业务有很多，业务团队一定要去了解模型的能力边界在什么地方，哪些是模型应该去解决的问题，哪些是产品的设计和规划上应该去包容的。这样两边相互结合，最后才能做出一个在业务场景非常契合的，能够快速上线的，满足业务新需求的 AI 型产品。它不是单纯某一边特别强，某一边就是被动接受的过程，这是动态的，并且是双向的。

机器之心：在资源有限的情况下，如何选择我们的路径，或者说技术路线，目前大家都是在探索，并没有一个行业的最佳实践，国外在采访的时候他们都用的是「直觉」这个词，what is your intuition about something。您在探索的时候是怎样判断的呢？

王迪：我觉得还是蛮对的，直觉确实很重要。怎么说？腾讯技术还是比较务实的。我非常看重整个团队把问题罗列出来，这一点很重要，一定要暴露出来问题，其实只要问题找对了，解决方案有很多种。

但解决方案有时候太多了，怎么去从中选择，聚焦到最后决策，这个时候是需要内部充分讨论，甚至经常有一些比较激烈的争论，这都是很正常的，最后确实直觉很重要，但这个直觉怎么来呢？我觉得一定是有过往的经历。我为什么说 knowhow 很重要，因为只有刚开始做过那些觉得很傻的一些事情之后，你才能知道怎么去训练一个千亿模型，你只有做了没有那么干净的数据才知道，不干净的数据到底会带来什么，所以这个过程很重要。

第二，过往做机器学习，包括做传统的 NLP、多模态这些方面的一些经验，也是非常重要的，包括对业务的支持，过往支持了很多个业务，才能知道在支持业务的过程中可能会发生什么，比如这个问题出了一个 bad case，我应该能够迅速判断出来到底是哪里的问题。所以虽然「直觉」两个字是对的，但它背后还是有很多的技术上的积累，包括说走过的一些弯路。

腾讯混元团队在搜索、机器学习，包括大模型的基础设施等方面有很多年的积累。公司数百个业务，大家一直以来非常好的合作关系，各方面迭代的节奏等等，因此当有一些问题需要去决策的时候，我们能够快速地找到这样一些路径。

机器之心：也就是说，您认为上一代的机器学习方法，尤其是 NLP 方法，或者 CV 的一些方法，在大模型时代仍然适用，并且是非常有益的？

王迪：对，一定是非常有用的，绝对不是说完全不需要的。这个地方我们要辩证地去看，如果说在当前这个时代，我们还只是抱着以前解决问题的具体思路和方法，那完全是不对的，因为你完全不应该那么去做很多事情，这样你整个做事的方法论就会有大的问题。

但是，当前我们在做大模型的过程中，有很多地方需要去提效的，比如我遇到 bad case，不可能所有的 bad case 全部都人标，第一耗时耗力，其次有很多问题，比如说 AI 搜索，标注本身就会非常难，你怎么办？

这一类问题的解决上，制造工具很重要，怎么样让模型自动地去评价我们自己的模型好不好，这些能力我们叫 critic model（评价模型），但评价模型的设计，怎么样才能设计好，过往有很好的 NLP 经验的同学就能够设计得更好、更快。当然，并不是说没有这些经验的人做不了，但可能他们对问题的理解，包括做事的速度会略微慢一点。所以我一直说这两个东西都是需要，并且是相互结合的。

机器之心：虽然 NLP 的一些任务可能不再需要了，甚至被淘汰了，但是因为学习或者训练过那些任务积累下来的经验是非常有用的。

王迪：对，相当于说是方法可能不会是以前的方法，但是问题还是类似的，解决问题背后的这种原理性的东西还是类似的。我们过往解决 NLP 很多方法论的东西，现在还是可以借鉴的。

机器之心：在大模型的训练过程中，对于训练的稳定性和模型的鲁棒性，业界当前面临哪几大难题，腾讯是如何应对和解决的？

王迪：训练一个万亿的 MoE 模型，怎么样能让训练的过程变得更加稳定，很多时候是整个基础设施的团队密切配合，像我们公司服务器的团队，针对我们的算力需求重新做了设计，服务器也是自研的。第二个星脉 2.0 高速互联的网络，也是为大模型定制的，非常好的网络设备，包括整个的解决方案。还有我们的 AngelPTM 训练框架，这三者是非常好地紧密在协作。

整个集群在运维层面，从卡到网络，再到运行过程中所有网络的通信拥塞，包括说资源利用率，甚至最早的时候也发生过因为利用率过高，使得整个卡的温度太高而发生问题等等。我们去年是做了大量的基础设施和运维能力方面的工作，因为出现故障是不可避免的，我们要提前做好预测和防范，现在我们已经可以做到通过对网络流量的监控，预判是否有一些卡出现拥塞，包括对卡的温度做监控等等，提前预判它是否有可能会出问题。

最后，出了故障，这是很正常的，我们过往也出过故障，因为本身 AI 芯片就有一定的坏卡率，包括说网络设备，上万张卡总有坏的时候，那坏了之后，第一个怎么能快速地定位是哪张卡出了问题，然后快速把它踢掉，再快速重新拉起训练服务，这过程中涉及到比如怎么样快速把 checkpoint 写到磁盘上，再重新 load 进来，这个过程如果是两个小时和五分钟，那是有天壤之别，等等这些问题吧。做过大规模集群管理的团队，应该都是有相关经验的。

至于训练过程中模型的鲁棒性，我们过往也确实发现一些问题，就是你发现流程都没有问题，但最后突然模型到某一个阶段的时候效果不好，这就很麻烦，所有地方都没发现错误，最后出错了，怎么去找问题？我们去年就遇到过这个问题，最后定位是在某一张卡的某一个时间，它的梯度出现了溢出。

于是，我们就把这些东西全部做到监控里，对这种梯度、范围、阈值等等做了很多监控，然后我们还定期有 checkpoint，每隔一定的训练时间之后有一个固定的 checkpoint，每一个 checkpoint 要去走我们标准的测试流程，保证比如每训练 200B、300B 之后，模型是否还在正常运行。基本上我们内部会去看标准的 benchmark 上的一些指标，比如说 MMLU、MATH、HumanEval 这种常规的，当然也会有我们自建的很多 benchmark 去评估。

机器之心：这样看来，虽说目前大模型没有理论，但从您的角度，不管是经验还是直觉，还是有一套标准去指引的，而且现在大模型的研究重任似乎放到企业这边，因为学界没有这么多资源来训练模型，关于理论和实践及其发展，您是如何权衡与判断的？

王迪：我是觉得很多问题，很难区分它是工程问题还是研究问题。还说那个例子，原生长窗口的训练，本质上是为了解决一个百万级、千万级甚至上亿 Transformer 窗口的训练，从模型的训练来讲这是个效果问题，我解决它是个工程问题，最后发现归结到并行化计算的一些工作，你说这是工程问题还是研究问题？

在我看来不用去区分，我们是在解决问题。我前段时间跟一位清华教授交流，也谈到这点，现在的大模型的很多问题，很多时候是用一些数据的方法解决，包括用一些工程化的思路去解决，让模型变得更快，我问这是科学吗？大模型要做很多的奥数，甚至是高等数学，这个问题还是很难，科学上怎么办？

这位教授给我的启发是，在人类历史发展的过程中，很多时候科学都是因为要解决现实生活中的问题才出现的，很少情况下可能像量子力学这样，是相对论出现之后，用理论来指导实践，更多时候科学理论是为了解决问题（才出现的），我觉得蛮有道理，所以今天分享给大家，我们不用一定说哪些是研究还是科学，哪些是工程还是系统，我们更多是去解决当前存在的问题。

我们现在跟国内很多高校在大模型方面有很多很深入的合作，包括一些联合实验室一起推进。在我看起来大模型里面有很多没有解决好的问题，这些问题可以抽象成很多研究性的课题，比如模型怎样可以足够快，模型结构 Transformer 是否就是终局了，我们还有更好的模型架构吗？

包括幻觉的问题，现在其实并没有被很好地解决，还有模型的评价问题，长窗口的问题，现在很多还是用所谓大海捞针的方法，但当用户真正用的时候，对长窗口的要求是更高的，等等这些都值得学术界、研究机构和我们一起研究和探索，从我们的角度来讲是非常期待可以去深入合作的。

机器之心：面对不断增长的算力需求，万卡似乎是大模型训练的标配了，对于构建百万卡甚至更大规模的集群，您的预判是怎么样的？

王迪：这是一个非常好的话题，也是在当前全球 AI 算力紧缺的情况下，大家必须去面对的一个问题。从我们的角度来讲，万卡是现在正常训练的标配，但下一个阶段是 10 万卡，从 1 万到 3.2 万到 6.4 万到 12.8 万，再到更大的资源层面，不过百万卡目前看有点夸张。

单纯说卡，任何一家的卡都不足以有这么大的体量，但我们同时可以有很多不同的卡，所以我们正在做并且非常看好的一件事是构建异构卡的集群，用不同厂家的卡，以及同一个厂家不同算力单位的卡、不同型号的卡，能不能在一起训练同一个任务？

这个潜力是非常大的，背后需要几方面的工作，首先一定要有统一的卡间互联、机间互联的解决方案，这一块正好腾讯有星脉高性能计算网络 2.0，不同的卡都可以用同样的互联协议联起来，性能也很好。

第二点，也很有挑战的，不同的卡之间怎么样去训练同一个任务，这件事本身在以前是没有遇到过的，现在一定要做，主要还是解决两个核心问题，第一个是不同卡需要统一的编译环境，这样代码才是统一的，不然英伟达的卡或者各种国产的卡，各家对编程接口的要求是不一样的，在腾讯内部是有一个叫 ABO 的统一编译层去适配不同的编译和接口。

第三点更为关键，不同的卡算力不一样，过往的机器学习训练，尽管我们有 5 种并行策略，但卡是一样的，训练框架写起来就比较简单，但现在高算力的卡和低算力的卡放在一起，我们就需要把 5D 并行的策略本身，基于卡的算力水平以及训练任务的特点，比如说模型并行和数据并行应该怎么样区分，序列并行、流水线并行和专家并行怎么样根据现在的资源情况自动化设计好，能让大家相对不要等待，这是非常核心也是非常有挑战的，也是我们 AngelPTM 训练框架正在做的。

此外，大模型训练还存在一个线性加速比的问题。用 1000 张卡是一个情况，1000 变 5000、5000 变 1 万张卡，是否还 OK？我们现在万卡训练没问题，但是到 10 万张卡，还需要考虑整个交换机、路由器的通信能力，等等这些方面，这也是一个很好的值得我们持续探索和实践的方向，但未来是不是真的百万张卡我不确定，但突破 10 万是非常有希望的。

机器之心：从您的角度来看，接下来要探索到什么程度？因为芯片会不断发展，万一有一天一块卡就可以了，我们探索了很多，这里面走的弯路，是否值得？

王迪：我觉得这还是很值得的，大模型整个过程，链条还是很长的，越是底层的变化，对上层的影响越大，所以不管哪一家，对芯片级别的变化都是慎之又慎。我们可能有一个新的卡，它的能力很强，但这张卡本身的生态链、运营运维体系，还需要花很多时间适应，把整体契合起来，需要一定的时间。

我非常认同并且坚信未来芯片能力会越来越好，但芯片再强，也只是芯片性能本身，整个链路的 AI 基础设施，包括训练框架，包括模型对芯片的要求，也是一个系统性的工程。

再来，算力越来越好的时候，人们对大模型的预期也会越来越高，这个东西水涨船高，也是一样的。

我们现在在看另外一件事，叫训推一体化。当前推理确实在不停地上量，提升速度也很快，但推理本身对资源的要求没有那么高，为什么？因为我们有很多的方法，把一个模型在推理的时候让它变得更小，一个推理的实例需要多台机器互联的需求是比较小的，这样就会大大降低新卡或者异构卡本身出问题对整个平台的影响，所以我们认为推理对大规模互联这方面的风险，容忍度就会更高一些。

另外，当前核心的矛盾还是在训练，大规模的训练，万卡、甚至数万卡训练一个更大的模型，还是一个核心的矛盾。但资源又是有限的，所以我们内部使用一种叫做潮汐调度的方法，比如说白天的量很大，需要很多的推理卡，但晚上量小了，就通过太极平台，把这些卡晚上调度给训练去用，提高卡的利用率。

机器之心：现在业界尤其是投资圈在看衰对 AI Infra 的投资，因为全球也就只有那么几家公司能投资得起，接下来腾讯关于这方面的投入是怎样考虑的？有没有一个上限？

王迪：基于当前我们看到的一些趋势，首先是内部业务应用的一些场景，包括腾讯云都在快速上量，这个给我们带来很大信心，我们在推理卡上，包括今年也会有更大的布局和投入。

第二是底座模型本身的演进，我们看到像全模态，甚至说未来更加大、更加智能的模型，我们这方面肯定也会持续投入，肯定会突破万卡的，但像百万卡可能现在确实在行业里也没有说哪家公司已经是百万卡放在那了，我们可能还是相对来说，是非常乐观地去看待，但又会是一步一个脚印往前推进，泰山不是一天建起来的，一万卡用好了，接下来几万卡、十万卡也能建好、用好，我觉得这是比较务实的角度。

机器之心：最后，您能对 AI Infra 未来的发展趋势做一些展望吗？

王迪：这个问题我们一直有思考，基于 AI 算力的大模型是驱动 AI 算力走向集群化、规模化的核心，包括刚才讲的大算力、大集群，整个训练和推理框架等等这些。

我们过往几年基于 Angel 做了很多事情，比如说怎么样用低端的卡也能训练大模型，怎么样把显存内存一体化管理起来，怎么样去把星脉网络的传输和计算做更好的结合，这些工作在 Angel 平台上已经取得了比较好的结果，我们也获得了 2023 年中国电子学会的科技进步一等奖。

但这在我们看起来只是一个开始，为什么这么说呢？其实我们去看基于 CPU 的算力和云计算，当用户说需要算力资源的时候，他们说的是我要多少核、要多少内存、要多少通信带宽。

对于 GPU 或者对于 AI 算力长远来讲，我们也希望有一天，用户不再关注于卡本身，而是更关注计算的 Flops，更关注显存数量、显存的大小，更关注通信带宽，然后通过一个更加统一的调度平台，训练框架等等这样一个一站式的平台，能够给我们公司内部这些不同的业务，以及云上不同的客户，去提供更好的、更加方便的，以及低成本的、更加通用的 AI 算力云的计算能力，我觉得这是未来一个很好的方向。

嘉宾简介

王迪，2008 年加入腾讯，拥有十多年在 AI 领域的深厚技术研发经验，在超大规模生成式大模型、搜广推稀疏大模型、搜索平台、GPU 算力和任务调度等技术领域取得显著成就，目前是腾讯太极机器学习平台和混元大模型技术负责人。

文章来源于“机器之心”，作者“闻菲”