推理工程大师课 — Philip Kiely & Ali Taha，Baseten
The Inference Engineering Masterclass — Philip Kiely & Ali Taha, Baseten
Base10推理团队与《Inference Engineering》作者Philip及Ali讨论长查询（20万token）的推理流程，涵盖缓存感知路由、预填充与解码分离、推测解码（SpecDec）及量化（NVFP4）等优化。新模型（如GLM-5.2、KIMI K3）发布需大量推理工程工作，包括量化校准、训练投机解码器及架构适配。团队还探讨了工具调用、结构化输出、张量并行与专家并行、视频扩散模型及训练与推理融合趋势。
好的，今天我们请到了Philip，他是《Inference Engineering》这本书的老朋友，也是Base10的合作伙伴，还有我们之前一起合作过的所有项目，以及Ali。欢迎。
很高兴见到你。
滑铁卢实习生。
滑铁卢实习生。
你什么时候开始用“滑铁卢实习生”这个称呼的？
我觉得改名大概是在三月中旬。当我看到这个称呼可用时，我就想，我必须得抢到手。
问题是Ali工作太出色了，他很快就不再是实习生了。所以我们必须得想清楚，谁来接这个称呼。
好吧，我会把接力棒传给——
哦，好的。这可以像你把它传给另一个滑铁卢毕业生一样。
传给另一个滑铁卢实习生。实习生。
实习生。你得从滑铁卢找个实习生来。
是的，我们得从滑铁卢找个实习生。
但这个人可能来自Base10。所以无论Base10从滑铁卢招到谁，都会拥有“滑铁卢毕业生”的头衔。
他们得通过你的考试。实习进行到一半时，要么拿到这个头衔，要么就出局。
你还应该搞一个盛大的毕业典礼。在那里换掉这个称呼。
就说，“B。”我是说，你们显然很擅长搞仪式。我们新书发布办得很不错，非常成功。但在进入正题之前，我想先问你一个有趣的问题。好的。你是专家级推理工程师。当我发送一个长查询，比如20万token到Base10的推理系统时，会发生什么？查询经过GPU模型路由、负载均衡等流程是怎样的？那些我们通常不会想到的环节是什么？
具体到长查询，我首先要问的是，你之前是否给我发送过这个查询，或者至少是其中的一部分？我真的希望你有，因为这样对我来说会容易得多，对你来说也会便宜得多。所以我们要做的第一件事是某种缓存感知路由，我们会查看——我们可能有很多实例和副本在服务你访问的模型。我们希望把这个查询发送到这样一个地方：第一，有可用的预填充工作节点；第二，理想情况下那里已经有缓存输入，这样我们至少可以跳过这20万token中的一部分预填充。如果你在处理20万token，那很可能是编码任务或多轮agent之类的场景，你可能会期望有缓存。如果没有，我们就得把它发送到预填充工作节点。至少在某些模型上，我们已经将预填充和解码分离了。所以你会有一组GPU专门处理输入，创建KV缓存，并生成第一个token。然后这个结果会被传递给另一组GPU，用于运行解码。我们会迭代地生成这些token。嗯，我们可能还会在前面加一个推测模型。我假设你在做编码任务。正因为如此，我们的推测模型——它假设你在做编码——会有很高的草稿token接受率。如果我猜错了，你是在让我总结所有《哈利·波特》的书，那速度就会慢一些。然后我们把输出流式传输给你，并计费，嗯，收你几分钱。然后说，嘿，你想再发一个吗？
但Base10不是按几分钱收费的。
嗯，是的，我们收费——
我们——
我假设我们说的是公共模型API。如果你是在搭建专用部署，那确实不是几分钱的事。
是的。我的意思是，当我最初和Base10交流时，一个关键区别是，那些需要极高吞吐量的用户其实只需要按整机租赁，因为那样的话，如何让机器满载就由你自己来决定了。
而且很多时候，如果你每小时推送数百万token，按小时付费比按token付费要便宜得多。
是的，确实如此。我觉得我们越来越多地看到对按token付费API的需求，因为每个人都想尝试开源模型。而一旦他们找到了真正有粘性的用例，就会转向专用部署。
有没有关于何时切换到专用部署的最佳实践？
有几个原因。是的，可靠性，这是个大问题，对吧？
比如如果他们有非常特定的用例，他们希望你为他们专门训练某些东西，比如他们想要自己的规格，比如针对他们自己的流量。
SpecDec就是推测解码。
推测解码，是的，是的，是的。抱歉，就是推测性的那种方式，基本上如果你有一个巨大的模型，对吧？模型每次前向传播只能生成一个token。所以我们在这个模型上附加一个小的寄生层，这个模型只需要做预测。它做3次非常快速、激进的向前传播，预测出3个特定的token。然后你对整个原始模型做一次前向传播，看看这些预测是否正确。然后你接受或拒绝它们。这个草稿模型是针对特定流量的。所以如果像Philip说的，你在总结《哈利·波特》的书，我可以专门在《哈利·波特》的书上训练那个草稿模型，我可以保证每次都能接受那3个token。在这种情况下，我提高了你的解码速度。如果你要共享端点，我就无法提供这个服务，因为我不知道你是在处理《哈利·波特》还是在做编码，是在处理英文还是什么，我们不知道。另外，书里提到过，如果他们真的关心特定阈值的话。我记得是第4章。你还记得吗？
是的。你可以做的事情包括设置特定的批处理大小、特定的并行策略。如果你在优化吞吐量而不是延迟，你可以，嗯，也许NVF P4 Quant没有通过你的基准测试，你想以更高精度运行模型。你可以这样做。有很多原因可能让你想要自己的端点。当然，最大的原因就是，你不必在恰好要服务用户的时候，还要应付别人向端点发送1亿token的基准测试流量。
是的。
我觉得有一件事是经典的旅程，你知道，就像Vibo在问，当你在浏览器里输入Google时会发生什么？工具调用就只是生成JSON，还是背后有更复杂的机制？
我们的一些客户拥有自己后训练的模型。因此，他们要求的工具调用不仅仅是解析文件或查询天气这类简单操作，而是非常特定且必须经过后训练才能实现的功能。如果模型的后训练质量不佳，或者后训练后为了加速推理而进行的量化处理不当，模型在读取JSON文件和执行工具调用时就会遇到困难。但这并不需要单独的沙箱环境，因为工具调用不会用于逃逸沙箱，也不需要被隔离，它可以只是一个普通的专用部署。工具调用面临的挑战似乎越来越多地在于，企业希望实现特定的工具调用，而这在训练上非常敏感。由于涉及大量JSON输出，如果请求结尾没有以特定方式闭合，模型可能完成了工具调用和思考过程，但由于没有看到结果，在解码时便凭空捏造了结果。这似乎是工具调用中最棘手的问题，而非沙箱本身。
是的，这是训练方面的挑战。而在推理方面，可以通过限制可能的输出来解决。我们大约两年前就发布了这个问题的解决方案，基本上就是构建一个状态机，用它来约束输出为特定格式。这就是结构化输出问题。如果你还记得的话——是的，有特定的语法规则。
嗯，GML有这个东西。
对，就像老派的“确保只返回JSON，否则我奶奶会死”那种做法。
BNF语法？OpenAI曾发布过类似的东西，说如果你想约束输出，就写BNF语法。
嗯，在Snore的推理系统中，就是指定输出格式，这样就能保证输出会按照该格式结构化。应用到工具调用上，虽然不能避免调用错误的工具或根本不调用工具，但至少解决了工具调用中的输出结构化问题。
而MCP只是另一种工具形式，对吧？
我想是的。
对，没错。
那里没有什么特别之处。
我经常向人们解释的是，LLM实际上无法执行任何操作，它只能提出建议。如果这些建议以特定格式呈现，并应用于一个知道如何处理它们的系统，那么行动才会发生。
是的。
有趣的是，这个问题在工具调用之外也能解决，比如在代理循环中。如果输出不正确，或者推理和工具调用以推理风格进行，就可以说“我不知道该怎么办，让我再试一次”。经过几次尝试后，可能就成功了。关于你提到的训练问题，这在较小的模型中有时更难，当你从大模型切换到小模型时，输出质量可能不会完全相同，对吧？
是的，我想说，在我们回到推理工程本身之前，我曾预期会有东西取代JSON，因为JSON难以流式处理，它必须完整，必须有开闭括号等。因此，在流式传输过程中解析或验证内容很困难。人们发明了各种替代方案，我忘了其中一些的名字，但基本上类似于TOML、YAML之类的东西。但JSON似乎仍然占据主导地位。
JSON输出并不长。
对吧？
我想，你可能会有很长的输出，因为工具调用也包含参数，也许某个工具需要传递很长的参数。但我的印象是，典型的工具调用涉及的token数量相对较少，对吧？因此，我认为投机解码对于像JSON这样格式化的内容通常表现不错，解码速度会很快，流式处理的价值可能不大。但也许我对此判断有误。
我认为你还受到软件或模型将要集成的系统的限制，如果软件是用JSON进行工具调用，或者你的客户说他们的软件就是这样工作的，工具通过JSON接口，你可以要求他们更改软件，说这对模型更好。但在湿训练方面，差别应该不大。而且，如果输出更多token，可能也更有利可图。
这取决于你的商业模式。确实如此。但我要说的是，作为一个经常处理AI生成内容的写作者，我确实尝试从文本转向JSON文本，那是非常长的JSON，对吧？每个字段里都有段落，因为我试图结构化内容。我希望你先做事实陈述，然后是观点，再是要点总结，包含日期、实体引用、参考来源等等。总之，这些是真正尝试结构化输出的人需要关注的事情。但让我们稍微向上回溯一下。在开始录制之前，你提到了一件很酷的事情，那就是当新的模型提供商发布新模型时，会有大量的推理工程工作。对吧？比如GLM 5.2、KIMI K3。我之前以为，特别是像GLM 5到5.1再到5.2这样的升级，既然之前已经支持过，工作量会很大吗？
工作量很大。
好的。所以，每当新模型发布时，很多人，包括你们，都会急着说“哦，Hugging Face支持这个，Fireworks支持这个，Space 10支持这个”。我会想，当然我们支持。但背后需要做什么呢？
我认为不仅仅是支持那么简单，对吧？这对消费者好处很大。比如KIMI K2.5或最新的GLM 5.2，当时有一场推理竞赛，某提供商达到每秒90个token，第二天我们就到了150。
我算是引发了那场竞赛，为GLM-5-2写了一篇Twitter文章，获得了大约50万次浏览。
嗯，因为排名第一。
对。
是的。
这让大家都兴奋起来，想着如何进一步优化基准测试。支持模型和让模型能产出token之间是有区别的，后者意味着我有生产就绪的API。让模型能产出token并不难，因为通常开源推理引擎，比如VLMs、SGLang等，往往能提前获得权重。维护者或模型开发者会合并PR以确保支持。所以大多数情况下，你可以在标准开源栈上轻松运行，没有太多麻烦。挑战在于，每家推理公司都有自己的专有栈，有些开源组件，有些是内部开发的。对于任意模型，总会有一些新东西。有时你很幸运，比如K25到K26就相当相似。
是的，如果我没记错的话，那纯粹是持续的后训练。
即使在这些情况下，仍然有必须做的工作。你得重新做量化。你要把模型从——通常这些模型发布时并不是 NVFP4 格式，而我们希望它们以 NVFP4 格式运行以获得最佳的 Blackwell 兼容性。所以我们必须执行量化，并且校准量化过程，确保不会导致模型智能水平出现任何回退。然后我们还得训练投机解码器，这个我们之前聊过。一般来说，我们的模型 API 有零数据保留（ZDR）策略，所以我们并不确切知道用户发送的流量内容，但我们知道哪些用例受欢迎。我们知道编码用例很热门，我们也知道 agent（智能体）类用例很热门，所以我们可以获取代表这类流量的公开数据集，训练通用的投机解码器。而目前的投机解码器需要用基础模型本身来训练，因为你要从模型对这些特定 prompt 运行推理时获取隐藏状态，这些就是用来创建投机解码器的训练数据。所以这个过程需要真实的模型权重。然后当然还有搭建后端基础设施、加载所有内容、进行测试的流程。而且当出现架构更新的新模型时，我觉得 DeepSeq 系列的模型通常最具挑战性，因为它们在架构上的创新最多，一个模型接一个模型。但每个新模型都有点新东西。我是说，KIMI-K2 有——抱歉，GLM-5.2 有稀疏化。对。
就是那个从 DeepSeq 引入的 DSA。
对，没错。而且你知道，我们可以复制粘贴然后直接做。我不太清楚具体机制。但我们得在运行时里构建对它的支持。而且你说得对，这些开源实验室互相借鉴的方式确实很有意思。比如 GLM 5.2 没有视觉能力。所以我们团队有个叫 Hailey 的人，如果我们能看一下这个，他基本上是把 KIMI 的视觉编码器嫁接到了 GLM 5.2 上。
完整地训练投影器。
完全正确。所以你想一下编码器，编码器是负责看图像并将其转化为潜在信息的部分，然后是投影器，它负责——
你可以说空间上的，没关系。
然后是投影器，它把信息映射到模型本身。再然后是模型权重。你不想动模型权重，因为那样有可能让模型为了获得视觉能力而在其他方面表现退化。所以 Harry 一开始只用了投影器，那只有几百万个参数。对。
你能展示一下训练过程吗？Grok 的方式非常非常——
也许 Ali，你来接着讲吧。你比我更了解这个。
好的，你可以看到他的训练方式真的非常酷。一开始，他只是用类似"这是一张山的图片，你能描述一下山里有什么吗"这样的方式训练。这导致了第一次学习损失。但你可以看到，我们试图教它的只是翻译编码后的信息——它已经从 ChemiK 那里拿来了编码器。它已经拿到了图像。对，冻结的，冻结的。
冻结的，冻结的。
带适配器。所以理解能力——大脑是冻结的。眼睛也是冻结的。我们只是试图在眼睛和大脑之间建立连接，对吧？就是投影器。所以你拿到 token，然后他会说"你能描述一下这张图片里有什么吗"，然后它说"哦，这是一座山"，或者"这是一个人的"，或者"这是一个人类"，诸如此类。但这并没有带来完整的理解。所以他改变了方式，让每张图片都关联一个问答数据集，比如"这张图片里有没有白人男性？""这张图片的右上角有没有鸟？""这张图片里有没有科学家？"等等。它必须正确回答这些问题。而且不只是训练描述图片，而是能够回答问题、回答问题、回答问题，反复进行问答。你可以看到 Grokking 现象，这真的很不可思议——给一个大语言模型加装视觉能力居然能学到这种程度。即使对于它表现不佳的图片，比如你给它一张斯蒂芬·霍金的照片问"这是谁"，它可能答不上来，但它会说"这是阿尔伯特·爱因斯坦"之类的话。它仍然理解这是一位科学家、一位男性、做出了重要成就的人。所以这真的非常非常酷。
是的。我们之前聊过 Hao Tian，他是 LAVA 论文的作者，那篇论文之前就做过类似的事情。我觉得对于任何没做过视觉工作的人来说，那都是非常基础性的工作。
CLIP 和 MetaCLIP 也是一样，从单纯的图像描述转向基于图像构建问题，性能提升有多大。
对，对，对。没错。
但这件事最令人兴奋的地方在于，如果你看这样一个模型——显然这更像是一个研究项目。它在 MMU Pro 上大概拿到了 56% 的分数，所以还不是特别出色。但如果你运行这个模型，你的 GLM-5.2 质量没有任何损失。如果没有图像输入，它的行为就和以前完全一样。
而且最终在推理代码里，你根本不会包含另一部分，对吧？对。
我的意思是，如果没有图像输入，你直接跳过编码器就行了。
好的，确认一下。
对。
从整体推理侧来看，你并没有增加太多东西，只是加了一个很小的视觉编码器。这些通常不到十亿参数。
是的，视觉编码器之间的标准化程度确实低一些，所以支持矩阵可能会稀疏一点，但总体来说，它只是整个系统中一个很小的组成部分。最终你得到的是一个同时拥有 KIMI 视觉、GLM 权重和 DeepSeq 注意力机制的统一模型。我认为这正是开源的力量和美妙之处——你可以把所有这些不同的组件组合在一起，形成一个比任何单一模型都更强大的系统。
以前人们说还会做 Frankenmerge，就是从每个模型里取一些层拼在一起。现在还有人这么做吗？
说到你之前提到的，当模型刚发布时需要投入大量工作来支持它，比如GLM-5.2或Minimax-M3这类情况，有时确实需要替换一些组件。例如，Minimax-M3的头部使用了全注意力机制。而使用全注意力时，你会遇到一个严重的瓶颈问题，因为你在为3个token做自回归生成，同时要对序列中的所有token进行O（复杂度）操作。你的KV缓存非常大，因为它不是稀疏的，也不是top-k的。所以我们发现更好的做法是，比如，用另一个使用GQX的模型中的层来替换这一层。然后通过正确的训练，你可以让它达到相同的接受率。所以从其他模型改造层是完全可行的，而且实际上非常必要。如果某一层效率低下，训练就成了挑战。你如何确保正确训练它？这又回到你之前的观点，即训练和推理之间的衔接——你需要非常好的训练才能实现快速推理。我觉得这一点越来越成为事实。
是的。在支持方面，当你说让它完全达到生产就绪状态时，还有其他方面吗？
是的，我觉得还有一个问题就是，我们可以对模型进行相当广泛的测试，但我们试图快速推出它，然后你会看到其他人测试它，得到一些有趣的结果。GLM曾经短暂出现过一个问题，我们遇到了一些模式崩溃的情况，在某些提示和特定温度下，它会一遍又一遍地输出同一个token。一旦你把端点暴露给真实世界，就会有更多种类的输入，你就能发现并修复问题。所以这不是一个第一天就完成的过程。在接下来的一周、一个月里，如果模型仍然受欢迎，你既要修复bug，又要继续推动性能提升。
你什么意思，你不想让你的模型输出SSSSS？
顺便问一下，那上面有循环检测吗？这种情况仍然经常发生，挺让人惊讶的。
在我们的端点中，如果模型连续输出4次以上相同的token，我们就会截断生成。我们会说，抱歉，请重试，或者我们会重新处理请求。因为我们知道，如果连续4次是同一个token，那很可能是崩溃了。
是的。有没有办法选择退出，以防我真的想要那样？
你真的想要那样？我觉得我们有办法处理。我不太确定。我觉得在某些模型中，当它们输出内容时，你可以想象一个表格，比如，它们想画12个破折号和12个破折号。是的，我觉得有办法让这种情况发生。我想我们只对某些token这样做。我们排除某些特殊字符。所以我们只对某些token这样做，比如S是最常见的，几乎GLM52就是这样。我觉得DSV4也是。就像你会有循环问题，它会一直——
是的。S有什么特别的吗？
没有，只是看起来就是那一个token。
是的。而且只在温度0时发生，还是其他温度也会？
不，不，即使在0.9或其他温度，它仍然会崩溃。
那很奇怪，对吧？
说实话，这是一个推理问题。就像软件问题。很多时候你运行的镜像，比如NVIDIA会发布一个镜像，如果我们把他们的最新RTLM镜像的更改上游到我们的栈中，我们会发现它能修复这个问题。或者很多时候这只会发生在你使用的推理引擎中，比如SG Lang。但如果你切换到VLM，就不会出现这种情况。所以这似乎是一个非常非确定性的软件问题，而不是真正的模型问题。这不是权重问题。人们说，哦，这是量化的问题，我们PTQ做错了。但那说不通，因为相同的权重使用不同的推理引擎不会重复这个问题。有时是后端使用的内核有这些非常微妙的、有时是竞态条件的问题，如果你在一个集群上托管这个模型，你永远不会遇到这个问题。
天哪。
但如果你在另一个集群上托管它，你就会遇到。原因是那个集群中KV缓存在节点间传输使用的互连比另一个集群的节点间互连慢。所以这暴露了竞态，而在另一个集群中不会。所以最后你只能这样，好吧，这个模型不能托管在这个集群上。我们要把它托管在另一个集群上，因为那个集群暴露了这个问题。但最后又会变成，是软件的问题？是模型权重的问题？还是硬件的问题？
关于温度为零时仍然不是确定性的，这确实是个问题，对吧？主要是因为硬件，即使在温度为零时，同一个模型，你也不总是能得到相同的输出。
但我对竞态条件那个感到惊讶，因为我以为PyTorch是一个图，能保证至少按正确顺序执行事情。
嗯，不，确实。我不是说存在风险。嗯，你有像PGL优化这样的东西，你可以在前一个内核结束之前启动一个内核。而那是你想要的。就像流水线一样。完全正确，完全正确。但你不是干净地做。你会重叠一点执行。不，我觉得很可能内核本身，那个应该在某个时间实例运行的块，那个内核本身就有竞态条件。比如，缺少一个屏障。通常如果你在设计一个内核并希望它非常快，如果你没有广泛测试它，某些线程可能会在寄存器中的数据被其他线程写入之前就访问它们，比如，因为你的屏障错了或者同步错了。但确实，测试本身在大多数情况下非常非常困难——
而且没有借用检查器——那是什么意思？就像Rust，如果你想有内存安全，这听起来是一个类似的问题。
嗯，是的，但你是在CUDA中工作，对吧？而视频GPU，就像你只需要一个像Modular这样的高级语言。
也许这就是Modular应该做的。
我不知道。你们怎么看保持模型质量的问题？你谈到了所有这些步骤，比如，你得做量化，训练自己的投机解码器，在不同硬件上运行。看看其他模型提供商，你在消费端发起了一场推理速度竞赛。在它们之间保持相同质量需要什么，对吧？当然，你可以运行基准测试，但比如，你如何确定多少量化？有标准吗？
质量方面涉及几个因素。大多数推理优化是无损的。例如，KV缓存，你只是在重新计算或避免重复计算相同的值。推测解码当然，如果草稿token错误，它会被拒绝。主要的有损优化是量化。这主要归结为三点：第一，数据格式；第二，你选择量化模型的哪些部分、哪些层；第三，对量化权重进行大量校准，以确保保留所有异常值。不过还有其他技巧。一个重要方面是长上下文，因为你一开始就问过，如果我发送一个20万token的请求会怎样？显然，对于长输入序列，你需要存储更多信息，处理更多token。因此，即使模型具有特定长度的上下文，作为推理提供商，你可能会选择构建一个上下文较短的API，当然也会提供完整长度的版本。因为如果用户不需要完整的百万token上下文，你可以为他们提供更好的性能。我不确定这是否完全属于模型质量。我对质量的理解是，我们在多大程度上忠实于原始模型。如果你设想一个模型的黄金实现，它完全按照模型设计的方式运行，我认为质量就是我们离那个100%保真度有多近。当然，你也可以从训练角度考虑质量，以及如何超越100%。但当我纯粹考虑推理优化时，就是在更快的同时尽可能接近那个100%保真度。当然，我们内部的标准是，用户应该无法区分我们的API和官方API。我认为KIMI在供应商基准测试方面做得特别好。
是的。他们发布了实际的供应商基准。
没错。是的。
因为他们指责了一些人，亚马逊？有个供应商在KIMI的基准上表现不佳。
是的。
所以，这会让我们看起来很糟糕。
那是很久以前的事了。
对吧？
不，大概三四五个月前。
这也发生在，我不记得是哪个模型了，但他们撤下了不少，然后开始了一个完整的图表。
可能是Jimmy Vendor Verifier。
是的。
是的。因为你会很生气，对吧？比如，如果我是消费者，使用亚马逊的端点，然后我用KIMI，我会觉得，天哪，这太差了。我不会说亚马逊量化模型的方式不好，我会说，KIMI真糟糕。对吧。所以看起来就是这样。
是的，他们在乎。他们在乎。
有道理。
这可能是个愚蠢的问题，但只是确认一下，量化有没有带来任何改进？量化是否总是严格更差？
嗯，从技术上讲，这是有损量化。这是一个有损实现。
速度提升了。
速度提升了。显然，数字率——
我总是在寻找逆缩放定律。这是我从Noam Brown那里学到的，通常朝一个方向运作的事物有时会反向。
嗯，从技术上讲，当你运行基准测试时，因为这些模型是非确定性的，有时你的NVFT4量化结果可能比你的——高出两个基点。
那是噪声。
是的，没错。是的，在误差范围内，这就是为什么我总是说在误差范围内。我实际上不再这么说了，因为每个人都以为我的意思是，在某个误差范围内，我们勉强处于最差的那一侧。但确实，有时它只是给出更高的输出分数，但就像Ali说的，那是噪声。据我所知，你不一定能让结果更好。你只是在努力，再次强调，保持与原始模型尽可能接近100%的保真度。
关于你的观点，我们在MP上做了研究。我不知道你是否能拉出我们发的一条推文。我们的研究实习生之一Joshua，我想是那条关于我们比NVIDIA有20%更好的量化JLM-5-2的推文。基本上，我们在这两个月的研究中发现的是，量化是有损的——你将数据从16位压缩到4位。例如。所以你显然会丢失一些信息，你试图最小化这种损失。所以当我说我要量化模型时，我的工作变成了如何找到可以量化的层和不能量化的层。例如，对于图像模型，我不量化调制层，也不量化输出投影，因为这两个就像——输出投影是用户看到的，调制是模型看到或理解的。对吧，没错。所以我想对他的论文，你有——我想没有——是的，这是一篇很长的论文。我不知道我能不能找到它。
如果有可搜索的部分，或者可能在帖子里。
可能在帖子里。但基本上，简而言之，量化更多模型层很可能使结果更好——比如，如果我有一个量化了第1、5、10层的模型，另一个只量化了第1、2层的模型，那么量化更多信息的模型可能表现更好，因为量化误差已经相互抵消了。
那个。
所以Joshua在他的数学证明中展示了，他有一个验证器，你可以预测哪些层的量化误差会相互抵消，然后你选择量化那些层。因此，这种数学量化的结果是，你最终得到一个比其他供应商量化程度高20%的模型。所以你获得20%更多的吞吐量，因为更多层在VFP4中运行，而且你的质量比那个其他量化更好，因为你选择量化的层的误差相互抵消，比如一层偏右，一层偏左，一层偏右，你最终的logit分布更接近原始模型的分布。所以你有更好的保真度。我们证明这一点的方式是使用KL散度。所以不是仅仅在基准上打分，我们计算了量化模型和原始全精度模型logit分布之间的KL散度。我们展示了使用这种技术，我们得到——如果你的logit分布中它想选择的token的概率分布与原始模型更一致，你很可能保持对原始模型的忠实。所以看起来之前，行业似乎认为，量化越多，效果越差，因为引入的损失越多。这并不完全正确。所以是的，它不会改进，但可以抵消。
我想可能是这个，但这让我想起了剪枝，你可以剪掉某些层。但非常有趣。不知道你们还发了这么一篇完整的论文。
有趣的事实，这篇论文最初是72页。然后我们决定不能发布。所以现在是425页。
还是39页，内容非常充实。我们聊了评估以及加速方面的各种可能性，我想这大概是大家最关心的一点，也是你在文章里写到的内容。官方API每秒70个token，你把它提升到了90。这是正常现象吗？
在influence工作最酷的地方在于，我认为influence会长期是适合做工程的地方，原因是如果你看看高度优化的领域，比如金融，如果你在金融行业，你会用基点来衡量进步。比如，我提升了5个基点，也就是0.05%的提升，那已经是重大新闻了，因为一切都优化到了极致。而我们发布优化成果时，动辄是20%、100%、200%的提升。所以老实说，可能还有很大的提升空间。当研究人员开始发表论文说他们如何把某个东西提速了1%时，你就知道推理优化基本到头了。
顺便说一句，因为我本身有金融背景，在70年代，那是当时的利润率。你做量化金融研究时，你会发现——
大概20%？百分之几十？
对，是的。
而现在只是极小的一部分。
有兴趣的朋友可以去看看Andrew Lo的论文。他有一个很有意思的图示，展示了量化统计的分布从70年代那种20%的差异，收窄到今天几乎为零，非常酷。
没错。我们也正处于同类进程的起点。现在做基准测试很难，我想任何人都会告诉你这一点。而给服务商的速度做基准测试更难，因为涉及的变量太多了。你用什么硬件？系统负载多大？提示词和输入输出序列长度的具体特征是什么？诸如此类。但总体而言，当你把这些改进叠加起来，你看到的是倍数级的提升。最常见的衡量方式当然是TPS，也就是每秒token数，这个命名其实不太好，是我们行业内的叫法，因为实际上有两种“每秒token数”。一种是吞吐量指标，另一种是延迟指标。
对。
比如GPU整体输出的每秒总token数，那是吞吐量指标。大多数人关心的只是作为延迟指标的每秒token数，这个其实应该叫ITL，即token间延迟，但我们没这么叫。总之，你可以想象一个标准的API，没有太多优化，跑一个1万亿参数的模型，在合理的流量特征下，大概在每秒30到50个token的范围内。我们通常的目标是把它推到10倍，但不一定是一开始就能做到，而是通过叠加足够的优化。比如你有4个优化，每个都能让性能翻倍——或者抱歉，3个优化，每个翻倍——叠加起来就是8倍的提升。这就是我们在这个领域里努力的方向。我们要做的是大幅提速，而不是仅仅从70提升到90。
你是说你们已经做到了？
这么说吧，假设你有一个合理的基线，每秒30或40个token，你可以实现10倍的提升。比如在GLM 5.2上，如果你不量化运行，哪怕是在Hopper上，只用现成的引擎，没有特别的优化，没有投机解码，没有KV路由之类的额外配置，没有分离式推理，那你大概就是那个30到40的水平。你觉得这个基线合理吗？
对，对。
要达到10倍左右，你需要做很多权衡。如果我们运行在每秒300到400个token的范围，显然你用的是最好的硬件，有优化过的投机解码器，完成了所有量化工作，缓存命中率很高，批处理规模合理，并行配置是针对延迟而非吞吐量调优的，但这是可以做到的。所以你在Artificial Analysis或OpenRouter上看到的差距，从最差的服务商到最好的服务商，往往能达到那个量级。10倍当然是非常激进的，通常可能更多是4到6倍的提升，但正是这种性能让我们真正兴奋——能获得巨大的提升，而不是仅仅从70个token到90个token。
这也跟硬件有关。比如你显然可以在一个H100节点上提供服务，然后你把模型分片到4个B200节点上。但你可以通过投入更多硬件来提升速度，如果归一化到完全相同的硬件和相同数量的GPU，那就是另一回事了。
对。那样的话，你看到的是2到4倍的提升，取决于推理优化的程度。所以一部分取决于车是什么，一部分取决于司机是谁。
如果把2到4倍拆解一下，比如在B200单节点上跑GLM 5.2，对吧？为了榨取最后一点性能，成本权衡是怎样的？而人们应该怎么想这个问题？
投机量化和量化。
投机量化和量化。
那大概占了95%。
那能带来多少提升？对普通人来说做起来有多容易？比如现在我想把GLM-5.2的权重放到一个B200节点上。找到投机解码器模型或已经量化好的模型有多容易？需要做多少工作？
如果你从头开始做，工作量相当大。如果你现在做，会有人已经发布了相关成果，你可以直接拿来用——拿一些NVFP4权重，拿一个投机解码器。如果我们想想叠加的那些2倍提升：从BF16到NVFP4，那不到2倍，对吧？我觉得大概30%到40%的提升，从16位到8位，然后再乘上30%到40%，从8位到4位。所以那加起来不到2倍，但大致接近2倍。投机解码器大约2倍。再加上分离式推理，如果你有足够的硬件和流量，又是大约2倍。然后再加上一些两位数的百分比提升，来自更好的运行时，比如最新的内核之类的。大概就是这么叠加的。构建量化权重，对真正懂行的人来说，是几小时到几天的工作量。构建投机解码器也是几小时到几天，分离式推理的搭建也是几小时到几天。好吧，一旦你有了，一旦你有了，对，对。
第一次让分离式推理跑通，当然是非常难的，但边际实现成本就低多了。如果你只是一个普通用户，有一台B200节点，想知道怎么自己托管，你不需要自己量化模型。总会有人发布开源的量化检查点。如果没人做，NVIDIA也会推一个出来。通常服务商也会有自己的投机解码器，是训练好的。你不需要自己训练，直接用就行。
对，比如QEMEI GLM-52自带MTP。
什么？什么？
多token预测，多token预测。
对。
我开玩笑的。
我只是个专家。
我可以帮你做，以防我做错了。
错了，你知道，呃，实际上如果我们错了你应该纠正，但他们的多令牌预测可以用于自推测解码。
我其实不太确定。
我半信半疑，但有人可以查证。但你知道，这有助于描绘一个场景：不只是普通人，比如说一家公司想从无服务器推理切换过来，我想把它部署上去，你知道，我想租一些GPU，然后部署上去。这些是你需要采取的步骤，才能比直接放在VLLM后面快得多。
对。
我一直在等有人提到Dynamo。呃，我觉得，呃，那应该是你用来对比的基线。
我会把Dynamo看作更像是一个构建工具包，而不是一个开箱即用的系统。所以当我们讨论做KV感知路由、做KV卸载、做PD分离时，Dynamo本质上——顺便说一句，Dynamo是NVIDIA的一个开源库。
我们已经和Kyle做过一期播客了。好的，不错。
所以，那么你的听众就知道它支持所有不同的推理框架。呃，而且它实际上是多硬件的，这挺有意思，但它只是一个路由器。
它不是一个优化层。
对。Dynamo擅长做的就是，它是一个在集群、硬件之间移动信息的库。所以如果你在一个地方有KV缓存，而你需要它在另一个地方，Dynamo会协调Nixil帮你移动它。这并不意味着开箱即用，你只要说，你知道，pip install Dynamo，然后就能获得巨大的性能提升。呃，它更像是一个开发者工具包。
对。
我会说它确实附带了一组默认配置，你可以替换掉。
确实如此。呃，如果整个行业都在大规模部署这些标准配置，我想那它会是一个可信的基线。但是，嗯，我们得对照我们在实际环境中看到的情况来做基准测试。
我确实想再多聊聊PD分离，因为那可能是继量化和推测解码之后第三重要的东西。但在你的书里，呃，我只是想翻出来，比如第522节讲Medusa，第523节讲Eagle，第524节讲NM。
第555节应该是讲分离的。
嗯，不，我只是想多谈谈其他的，比如你选择包含什么？你选择不包含什么？因为我觉得还有其他这些技术。
对。
这些还相关吗？因为我觉得它们大概是一年半前出来的，也许。
Medusa挺老的了。
对，Medusa老了。
但它在书里是作为一个好的基线吗？
比如，你应该知道这个。
比如，我读了论文，我就想，啊，这太有道理了。
对。
写这本书时，我有几个目标。呃，一个是给人们提供整个领域的实用词汇，另一个是让他们对这些技术各自的工作原理有一些直觉。正如我在AI Engineer演讲中提到的，那是这本书的第一个公开补充，推测领域的发展速度比其他所有领域都快。所以，即使在我写书的时候，Medusa，我非常明确地把它作为让人们理解这个领域如何演进的工具，而不是作为最现代的技术。现在当然还有D-Flash、D-Spark，呃，还有比Eagle更新的技术，尽管Eagle仍然非常常用。
SpecSpecDec？
对，推测解码。
什么？你能？
它基于TreeDawn的一篇论文，基本上就是在做推测解码。
嗯哼。
针对推测器。
天哪。
它真的只是另一个，就像，对，这是最简单的解释。而且看起来他在那里获得了不小的加速，但训练上的复杂性，在我看来至少，几乎和训练GAN一样复杂。那是一个非常微妙的平衡，而且很多时候你——它只是额外的开销。但没错，它字面上就是推测解码，非推测解码。
推测解码。
对，我们看过这篇论文。
这挺有意思的，对吧？我甚至不会觉得它训练起来特别特殊。我天真的想法是，好吧，训练一个推测解码器。
这说得通。推测解码的整个想法是，你——这几乎就像普通模型的iPhone自动补全，对吧？你生成3个令牌，然后说，好，对它们做预填充。这样你就为原始模型省下了那3轮。现在你的推测解码器在做3轮自回归。那为什么不干脆用一个更小的模型呢？
我想另一个问题是推测器的大小是多少？
比如对于GLM，大概是10亿参数。
比如对于Minimax，它只有一层，大概是原始模型的1/60。
对，实际上，我觉得我们回办公室后应该做一篇论文。推测，推测，推测解码。
不，这确实看起来，你什么时候停下来？但这也看起来，如果你能训练SpecSpecDecode，比如说，如果你能有一个小模型准确预测中间推测器会预测什么，而那个中间推测器能预测原始目标模型会预测什么，那为什么不直接使用那个最小的模型呢？对吧？
对。这跟路由问题很接近，对吧？
对。
对。
关于推测器，使用它们的实际限制之一是，你必须在运行大模型的同一硬件上运行一个小模型。这本身就存在编排和资源竞争的问题。这是推测技术普遍面临的一个约束，即草稿令牌的生成需要消耗资源，管理它们也需要软件复杂性。所以如果你有无限递归的推测器，你不仅在训练过程中，而且在推理引擎的实际实现中也会增加相当多的复杂性。
我正想说，我想知道你是否能做类似的蒸馏和剪枝，你知道，这是同一回事。它只是一个模型。我们不能蒸馏很多方法来量化推测器吗，但这超出我的领域了。我想另一个问题是，这都是针对大型服务器工作负载的，对吧？其中有多少适用于，比如，我有这台MacBook，我想高效运行Gemma。问题类似，但不完全相同。
相当不同。几周前我在Celo的播客上聊过这个。数据中心和生产负载的推理工程与本地AI的推理工程之间的区别在于，我们一开始就面临根本不同的约束和目标。对于本地AI，问题是“如何把这个模型塞进我的硬件，然后让它不那么笨？”而对于数据中心推理，则是“如何加载这个模型，然后让它不那么慢？”显然，我们关心的是“不那么笨”，他们关心的是“不那么慢”，但我认为本地AI的推理工程生态系统实际上有很多值得我们数据中心领域学习的地方。他们在各种形式的量化方面是专家，包括我们几乎不碰的动态量化，还有剪枝、蒸馏，以及层移除等等。还有——
层移除没那么重要。
对。
真正重要的是剪枝。
对。
但，但还有很多——
这挺意外的，对吧？但那是——
只是为了塞进笔记本里。
对，对，对。
所以，是的，我觉得这是个有趣的领域，不一定说他们的技术对我们数据中心适用，因为显然我们有不同的资源和目标，但更多的是那种过程以及该领域的开放性值得赞赏。
对，就像你说的，有些优化可能不会，比如TurboQuant，你肯定听说过，在NeXT上炒得特别火。我们在Twitter上做了个深度分析，我当时想，这是什么？它怎么工作？为什么好或不好？然后它在本地设备上火了，因为像MacBook这样的设备内存带宽很慢。但把同样的东西放到NVIDIA GPU的B200上，TurboQuant就不会被用。NVIDIA明确表示这不是个好优化，我们也亲眼看到，在kernel内部做反量化和量化的开销，TurboQuant kernel本身，会吃掉你从带宽节省的时间，而且实际上慢得多。因为在B200上，你有大约3.5TB每秒的带宽。你不需要大幅减少存储，不需要做FD4-KB缓存，不需要用重新量化器。有更好的优化方式。但在边缘设备上，这极其重要，极其有用。所以，看起来是不同的优化，但它们都独特地结合在一起，比如你想量化模型，你想做投机解码，像某些常见前缀，两者都有原则。对，没错，没错。
他们还做了很多模型并行的工作，尤其是在异构拓扑上，比如你有一些Sparks，它们通过以太网连接，DGX Sparks。
对，这是Exolabs那帮人。
对。
你有一堆Mac Mini叠起来。你知道，机器之间的互联是我们都必须面对的问题，虽然他们面对得更多。这就是为什么，比如，我们经常做张量并行，那是用所有8个GPU，把模型分片到上面。张量并行不太适合本地AI，因为它假设有像NVLink这样的高带宽互联。而他们可能被迫做流水线并行，除非我们做某种多节点推理，否则我们永远不会用那个。
既然你提到了，我其实不确定我们会不会覆盖这个，但让我们简单解释一下张量并行和专家并行，因为你有一些很好的图。我就想展示一下你的图。
对，感谢Base10设计团队的Luke做了这些漂亮的图。哦，在进入这个之前，还有一个区别是，我们经常谈论Mixture of Experts模型的激活参数。对本地推理的人来说，这很重要，因为如果你批量大小为1，你只激活那么多参数。当我们做——
对，那本来要叫扩散对话的。对。
对。当我们处理一个MoE模型，托管它给API用，我们假设所有参数都会被激活，因为你的批次会覆盖所有东西。好，大致来说，张量并行适用于任何模型。专家并行只适用于MoE模型。实际上，现在所有模型都是MoE模型。至少所有大到需要跨多个GPU并行化的模型都是。所以那个细微差别现在不那么重要了。专家并行的思路是把整个专家放在一个GPU上。通常专家数多于GPU数。你可能每个GPU放n个专家，比如每个GPU 8个专家。然后你复制路由器，路由器在每个GPU上都很小。然后通过让生成过程从一个专家移到另一个专家，每个专家都在一个GPU内，它们不竞争资源。你大幅提高了吞吐量。GPU到GPU的连接不那么重要，因为通信量不大。张量并行要求你能做all-gather、all-reduce这类操作。所以你基本上把模型完全分片到多个GPU上，每一步都要合并每个GPU的结果，这就是为什么互联很重要。而且通常——当然，这是一个非常高层面的概括，有很多地方不准确，但一般来说，TP有助于降低延迟。在很多情况下，你会在模型中组合使用这两种并行，而不是只选一种。你想补充点什么吗？
对，通常在一个模型里，它们不是互斥的。你会做张量并行，也会做专家并行。流水线并行用得少。在我看来，我们从来不用流水线并行。对。
你唯一需要做流水线并行的情况，就是把不同层分开，一半层放在一个硬件上，另一半放在另一个上，是因为你被迫做多节点推理，因为模型太大，超出了你现有的硬件。比如说，假设你在H100上部署，不管什么原因，放一个万亿参数模型，你必须用多个H100节点。因为节点间互联太慢，唯一可行的并行方式就是流水线。但然后你会在每个节点内做张量并行和专家并行。
H100的限制因素是HBM。对，就是不够。多少？我们需要什么神奇数字？
比如，B200每个GPU是180GB，然后一个节点8个，你算180乘以8，加上VFP4，每个参数占半个字节，那就是800GB。在H100上，大概是140？
是80。
是80。
对。
噗。
对。
我老了，干这行很久了。我确实记得H100的规格。
对。
你觉得T4怎么样？让我告诉你当年在T4上跑模型是什么感觉。
嗯，有件事让我挺惊讶的，就是没多少人这么做——Jamba。不知道你们还记不记得AI21的Jamba。他们会专门挑一款硬件，然后针对那款硬件设计架构尺寸，这样显然能充分利用硬件性能。这很合理。但不知怎的，所有这些模型都没这么做。
不过他们不是在训练端这么做吗？
我不清楚。
抱歉，我是说训练的时候，比如决定用哪款GPU。
对，对，他们确实这么做。训练的时候更像是个数学问题，你可以算一下FLOPs然后最大化它。推理的时候则更像自动调优。不知道你们有没有听说过GPU内核自动调优，基本上就是你先定义好，比如我有2块GPU，可以用TP1、TP2、EP1、EP2这些组合，对吧？这样就有2的平方种组合。然后你拿同样的流量，比如真实世界的流量，跑一遍看看哪种配置的TPM、TPS最好，就用那个。我不太喜欢的一点是，你没法推理哪个配置性能最好，也不存在一个永远最优的固定配置。但看起来自动调优就是找到最优解的方式。内核和GPU内核这块也差不多。你设计好内核和配置之后——启动多少个线程？用多少共享内存？就是自动调优，扫一遍参数空间，然后凭经验决定哪个最好。但这两者是结合在一起的，不是分开的。
训练方面确实有一些针对硬件优化的东西。比如你看NVIDIA的NeMoTron模型，它们在Blackwell上跑得非常好。这并不意外。所以确实有一定程度的针对性优化，但我觉得大多数开源实验室的目标是让模型能在尽可能广泛的硬件上运行，而不是只针对单一芯片。
明白了，是为了实用性。
对。
嗯，好的。趁这张图还在，我再问一个事。All-gather和all-reduce很贵。硅谷现在有个趋势是megakernels，就是不断融合内核。我不知道，这事儿就这么简单吗？
嗯，我是说，融合内核救不了你。在张量并行的情况下，一半矩阵在一块GPU上，另一半在另一块上。如果下一步要做非线性操作需要整个矩阵——比如做attention的时候需要softmax或者指数运算——我就得有整行数据。所以为了在下一阶段做softmax，我得知道GPU 2的部分结果和GPU 1的部分结果。所以即使有融合内核，因为每层里的非线性操作，我还是得让它们互相通信。另外关于megakernels，说实话，我挺不看好的——我直说了。
请讲，请讲，请讲。
不是，就是megakernels这个方向，作为研究来说挺好的，直觉上、理论上都很漂亮。比如，启动一个内核有很多启动开销。
对，那就一直融合呗。
把所有东西都融合在一起。但问题是内核本身的复杂度——要写一个高度优化的megakernel非常难，非常非常难。而且，就不点名了，即使是那些做融合megakernel内核的公司，我跟他们的人聊过，他们很多时候最终不会在生产环境跑这些，因为那种模块化的、分开启动的内核反而更快，因为你可以单独优化每个组件，让它们互相并行。还有Rubin，不知道你们昨天有没有看到Rubin的Twitter帖子，他们也在——
Rubin？
就是——不，不，Rubin，就是那个GPU。
他们还有专门发Rubin的Twitter账号？
不不不不。
我还想说，你在说什么呢？抱歉。
NVIDIA的一个技术主管发了条推文，说我们要揭开Rubin的面纱了，这是规格参数。第三条推文展示了——就不说得太技术了，我还需要多读读——这个GPU的设计基本上就是干掉微内核。你不再需要那么多微内核了。所以看起来整个研究领域可能就不会继续了。不过，嗯。
我能稍微推测一下Rubin吗？请讲。你知道，我已经经历了——
顺便说一句，书里都写了。书。
对，嗯，我是说，书里会写到，因为我知道从博客文章来看，Lumen将来会推出。
你甚至知道那个名字，Feynman。
对。就像，嘿，这个，这个会是——
这非常新。
我得让这本书面向未来。好吧。嗯，我不想明年之前再出新版什么的。嗯，总之，我们刚才在讨论我有多老。嗯，你知道，我现在已经经历了三轮硬件发布周期。我经历过Ampere周期、Hopper周期，还有Blackwell周期。我说发布周期，不一定是指硬件实际出货。比如Ampere在我入行之前就已经上架了，但从硬件上架到推理可用之间隔了很长时间。所以你看最初的vLLM和SGLang，尤其是vLLM，那是针对Ampere写的，后来得更新到Hopper，再更新到Blackwell。每一轮周期都更快、更紧迫，但也复杂得多。当我展望Rubin会带来什么新东西时，我觉得Dynamo给了我很多技术上的提示，告诉我什么样的工作会非常有价值。显然我们在延续Blackwell的一些趋势，对吧？NVFp4很重要。他们在NVFp4张量核心后面投入的计算量非常庞大。嗯，我们之后应该会聊到视频，那是最大的瓶颈。你有快得多的内存带宽，嗯，这也是Blackwell表现好的原因。嗯，但最重要的是更多的系统思维。更强调CPU到GPU的互联，更强调GPU之间的互联。你看Dynamo，它整个系统就是围绕一个问题设计的：怎么在需要的时候把KV cache移到需要的地方。嗯，所以我觉得KV cache卸载、KV感知路由、还有分离式架构这些主题在Rubin时代会变得重要得多。这意味着推理工程不只是CUDA内核的问题，也变成了一个非常传统的硬件基础设施问题。这是我们长期以来一直在构建的方向，对我来说也非常令人兴奋，因为我们会看到多个领域碰撞在一起，从内核层面推理到硬件层面再回到内核的能力会非常有价值。
我会把菲利普的话再往前推一步。我觉得这个趋势正在变成纯粹的基础设施问题，PG、DSAC、训练、SPEC-TAC这些方面都是如此。但木马内核不会成为大问题，因为GPU正越来越向ASIC（专用集成电路）方向发展，你只需要编排GPU上发生的事情，而不需要在线程级别控制它。你在Qtile、QDSL里看到的就是这样，你只是在数据块级别操作，不再控制GPU上每个线程的行为，那部分已经替你处理好了。所以我想问，根据你和其他人的交流，你是否同意GPU以及未来的GPU正越来越趋向于变成只需启动就能执行数据操作的ASIC？
哦，我是说，是的，不，那确实是市场的一部分。显然ASIC在特定负载下能实现更高的性能。而GPU里的那个G让它们继续保持通用性。
对。我觉得这更像是一个光谱。
实际上是图形（Graphics），但没错，我一直在说这个。我得纠正一下自己，免得有人揪着我搞错那个G。
对。这就像是一个光谱，对吧？从非常通用的计算到像Talus那样为特定模型权重定制硬件的设备。
权重直接烧录在芯片上。对，不需要加载。
我不认为我们会完全走到那一步。更像是在光谱上朝着硬件更专业化的方向迈出一步。
是的，我很好奇。我觉得他似乎在引导某个方向。
我想说的核心是看空——你说除了把权重烧进芯片之外的一切。把权重烧进芯片不现实，因为你要微调、要优化、要量化、要发布新的模型检查点。如果烧死在芯片里，那芯片在Arthur里也没用了，对吧？我的意思是，你怎么能不看空呢——你看NVIDIA越来越专业化，把GPU从通用编程范式——就是一个你可以用来编程线程的通用计算机——每一代都在加入更多专用指令、专用张量核心、专用的MMA指令，这些让你几乎可以像控制ASIC一样控制它，几乎就像控制一组ASIC。你怎么能看着这个趋势，还看多那些做AI ASIC的公司呢？因为——
对，因为它们也在朝那个方向演进。
它们几乎在朝那个方向演进。比如Rubin，相比Ampere或者T4，Rubin基本上就是一个ASIC。它基本上就是一个被使用的东西。
可编程的。
它像是AI之前的，显然你可以编程，我是说，叫它ASIC确实很有争议。它是GPU，是通用的，确实有线程。我可以写CUDA来控制它、改变它的操作。但它有脉动阵列、张量核心、TMA、张量内存，这些东西几乎只对加载模型权重有用。它的张量核心指令几乎完全围绕当前市场上模型的头维度来设计。你说你要做一个ASIC，把什么东西蚀刻进去，那下一代架构出来基本就废了。对，我不知道，我不知道。
我觉得要记住的是硬件周期有多长。如果今天有一款芯片发布，那意味着它的设计过程几年前就启动了。NVIDIA在预测市场走向方面做得非常好。
而且，你知道，他们当然拥有最多的信息。
但如果你看看那些公开的开源模型架构，它们或多或少像今天模型的早期版本。Rubin实际上是第一款完全在那个世界里构建的芯片。所以你可以从它的设计中看到很多对这款芯片将要承担的工作负载形态的理解。
对。好的。所以我不是回答这些问题的最佳人选。我觉得这些问题非常合理。显然第一个关于Rubin的问题是我听过阐述得最好的。我确实想为垂直整合的模型实验室ASIC做个辩护。比如OpenAI和博通的合作，不管叫什么Jalapeño芯片，这完全说得通。我们之前在播客里和Martín Casado聊过这个，他说，如果你有万亿美元或五千亿美元的训练投入，那就拿出500亿做个ASIC。ASIC没问题，你从ASIC上最多能获得10%的效率提升。这说得通，对吧。所以特定模型的芯片，是的。但ASIC公司，有趣的是我觉得你关注的是——你过度聚焦在像你说的TAO那类东西上，它们做的更多是表面工程，或者说实际的内存和硬件分配，以及芯片间的通信，这些可能Rubin还不会触及，但我不了解细节。我明白了。通常他们讨论的东西，我预期会比Rubin能通过编程实现的规模大几个数量级。但谁知道呢？
不，我明白，我明白，我明白。对，看起来——
对，我是说，想想真正阻碍推理速度提升10倍到1000倍的是什么。不是那些在现有GPU设计内部就能重新安排的东西。
芯片间通信。
对，这些人目标是每秒30万token。他们不是在闹着玩的。
对，其中好几家能做到6万。
也许吧。我觉得有意思的是，你最近做了这么多内核工程的工作，却对其中很大一部分这么看空。
对，对。但我做得越多，就越觉得这玩意儿太庞大了。
我还想补充一点，模型是一代一代出的，对吧？在你们那边，你们看到很多——今天GLM、KIMI、DeepSeek、MiniMax，还有其他一些。有些在做完全不同的东西，对吧？Gemma没有编码器，最新的thinking machines完全是从零开始的。但你看另一边，我们在GPT-5这一代上待了多久了，对吧？
对。
他们服务那个模型已经很长时间了。当然，可能有更多预训练、不同的检查点，但你确实能榨出不少东西，而且你做的是数十亿美元的训练。如果你能让它提高X%的效率，他们就会服务它一段时间。Claude 5系列也是一样，对吧？
如果他们发布新模型，比如现在发布GPT-6什么的，而且他们每年发布一个新模型，我们不知道，但如果假设他们改了一些架构部分而不只是做后训练，那你每年要花500亿美元为新模型做ASIC，然后把上一年的ASIC扔掉。
对，对，很容易。
所以我觉得，好吧，我稍微不同意——基于我的二手信息——关于模型的寿命。现在还有人用GPT-4.0呢。
对，对。
Llama，不是 Llama 2，而是 Llama 3。我仍然看到 Llama 3 的工作负载。
是的。
因为如果它已经完成，如果它被信任、经过测试，呃，能用就别改，这正是开源的一个承诺，对吧？
就像整个 4.0，保存 4.0 运动。你不需要搞一个“保存 Llama 3”的运动，你只需要在某处有一个 8.100 就行。
我觉得在某个时候还有一个问题：如果一个模型能做足够多的事情，能调用足够的工具，能足够 agentic，呃，它能不能直接做网络搜索、工具搜索、写代码？你真的需要不断压榨更多吗？我们会这样做，因为你们会让它更便宜、更快、更小，我可以随时换进去。但在某种程度上，比如你今天给我 5.2 或者随便什么 120B 模型，我可以跑相当长一段时间，对吧？
这是假设你不需要智能。
我觉得有很多智能。
你需要的是可靠性和可预测性。比如，我在企业环境里，这是经过试验和验证的。它已经由我 5000 个利益相关者签字确认。我不会去碰它。
它每天跑一个批处理任务，我喜欢结果。结果是可预测的。
可用。
是的，继续用它们没有意义。东西会变得更稀疏、更便宜、更好，对吧？但这并不意味着旧模型——比如 GLM-5.0 就不可用了，对吧？如果我们遇到停滞，不管什么原因，仍然有很多可以榨取的空间。
我们快没时间了。我确实也想确保——是的，实际上我们正好有这张图。把它和任何 Cerebras 的图对比一下，对吧？呃，我觉得 Edge 和 Maddex 还没有公开图表，呃，但整个——物理布局非常不同。尺寸非常不同，对吧？这不是晶圆级，对吧？这——大概有，我不知道，一个晶圆上有几百个这种芯片。呃，我不知道对比有多大，但像，呃，这是一个非常明显的物理布局分配差异。
我会说几十个。
在我们离开硬件话题之前，我有两个快速问题。第一，最新的 KIMI，非常大，呃，3 万亿参数，是的，在大多数单节点硬件上放不下。
是的，你需要 GB300。
字面意思。
或者 A 和 D。呃，这是简单的数学。呃，NVFP4，2.8 万亿参数，呃，1.4 TB。呃，GB300 每个有 288 GB。呃，所以跨 8 个这样的设备，呃，你有足够的空间放模型。而且说实话，GPU VRAM 计算的另一件事是你必须为 KVK 留出空间。
缓存。
这在一定程度上取决于上下文长度。所以当一个模型既有非常大的参数数量又有很长的上下文长度时，你基本上是在争夺空间，这就是为什么，你知道，KV 缓存卸载会随着这些巨型模型成为一个更突出的主题，因为你就是，你非常空间紧张。
有了 Rubin，你现在有什么，NVL72 机架有 20 TB？
现在，你仍然可以在 Blackwell 上有 NVL72，但是，呃，你不能假设你会在那上面做推理。呃，世界上 8 卡机架的数量比 NVL72 多得多。是的。
我想我最后一个关于硬件的快速问题是，你有没有注意到硬件代际对新的预训练基础模型有什么影响？你之前提到效率的一个方面是你可以换硬件。这是 2 倍收益之一。当我们在 Rubin 上看到新的训练相关的东西出现时，任何变化、解锁，这是否会影响当这些硬件更普及后我们会看到的模型类型？你能——
它们会变得更大，人们理解你在运行模型参数数量上的上限，呃，考虑到最新的推理硬件。这形成了一个天花板。所以，例如，当 Deepseek R1 出来时，它是，你知道，6710 亿参数，当时真的很大。我认为它在很大程度上推动我们快速采用 Blackwell 并擅长在 Blackwell 上提供服务。呃，所以是的，在我看来，这主要是关于模型大小，然后是关于将架构和原生量化与目标硬件匹配，就像我们之前讨论的所有 Nemotron 模型使用 NVFP4 一样。
所以我们谈了很多关于 LLM 的内容。你书里还有更多。那音频、视频呢？推理工程的另一面是什么？Ali，你在视频扩散方面相当强。
视频扩散模型，我认为，它们就是——很多你可以用LLM（大语言模型）来思考和推理的东西，比如自回归、激进式处理，在视频扩散中并不适用。例如，你不需要做批处理。每个请求都直接在一张GPU上进来，也在同一张GPU上服务。你不需要分片。模型规模要小得多。比如Wontorra 2，是个200亿参数的模型。你不用担心——它比最好的LLM小了好几个数量级。而且在这个领域，开源模型的表现——就像LLM那样，我们看到Kamekay-3几乎可以媲美Mythos或GPT-5。最好的开源LLM和最好的闭源LLM之间的差距非常小。以前大概是6个月的差距。我觉得现在不再是6个月了。我认为基本上已经接近持平。视频模型绝对不是这样。差距巨大。如果你看看今天用开源模型（比如Juan Torrado）能生成的最佳视频，和用CLING或Veo这样的工具生成的相比，差别是天壤之别。这就造成了这样一种不平衡：媒体公司大多数时候会选择闭源模型。比如，如果我告诉你，嘿，我可以用这个模型为你生成一部完整的3小时电影，而且我会优化到让你只需付我10美元。但如果他们用闭源模型来做，就得付1000美元，也就是100倍。我便宜100倍，但还是要1000美元。他们还是会选择用Veo来做所有剪辑。所以这就成了一个鸡生蛋、蛋生鸡的循环：需求减少导致该领域创新减少，进而导致更少的开源检查点发布。而一些曾发布开源模型的实验室，比如Juan，已经将其最新模型闭源了。比如1.2.7就不是开源的。我们还在用1.2.2。视频模型面临的挑战尤其在于token数量。视频模型，你想生成高质量视频。假设你每秒做16帧，这是绝对最低限度。再假设你做480p视频。你可以想想你的维度。我觉得我有一个很好的示意图，能展示token的庞大数量，对吧？假设你看一段视频，比如《斯巴达300勇士》之类的。假设我们看4帧，对吧？那4帧画面，如果你做全注意力，稍微往上一点，比如你看480p乘以720乘以81帧，就5秒钟，因为16帧每秒乘以5，对吧？然后你压缩到潜空间，但你仍然在处理30乘以50乘以201个token。是的。这意味着对于注意力来说，仅仅5秒钟，你就要在35,000个token上运行注意力，对吧？所以注意力成了巨大的瓶颈。而且因为它是平方复杂度，如果你扩展到10秒，那就是平方增长。20秒、30秒。所以要生成1分钟的好片段，在同样的计算时间内几乎不可能。这就变得不可行了。你做不到。于是你只能朝两个方向走。要么你决定对整个视频一次性做注意力，这种情况下你被迫使用稀疏注意力。如果你回滚到视频图像，你可以看到，比如左边，我做的是全注意力，其中《斯巴达300勇士》场景中的每个token都关注其他每个token，你可以看到红色补丁的数量之多。右边，我只让每个token关注对它重要的前K个、前12.5%，这可以是空间上的。代表皇冠的token关注头部、脸部，然后关注前一帧中另一帧的头部，时间局部性、空间局部性，诸如此类。这会导致视频质量很差。而这篇文章或帖子的重点就是展示你可以训练、可以做所有这些事情，但你的质量还是会有所损失。所以你最终面临两种选择。要么你硬着头皮，用巨大的计算资源在百万级token上做全注意力，因为你试图生成2分钟的视频；要么你转向自回归视频。自回归视频在我看来，是未来会押注的方向。但今天还没有好的开源自回归视频模型。而这似乎是必经之路。如果你想得到一小时的电影，如果你想看到视频模型生成好莱坞级别的电影，它们必须是自回归的，才能超越那5秒的帧。或者必须在计算上出现某种疯狂的飞跃，让我们能高效地同时对百万级token做全注意力。
Pano。
即使是百万级token，因为是二次复杂度，你很快就会达到极限。我想，你能解释一下自回归的利弊权衡吗？一个想到的是帧间一致性。你在自回归扩散生成10分钟后，会忘记之前的内容。但自回归的优缺点是什么？
嗯，就像自回归LLM一样，你可以把很多我们讨论过的针对LLM的优化，比如Spectac之类的，应用到这里。而且，如果你有一个高质量的大规模模型，没有理由不能流式输出——我可以先给你看第一帧，然后就像2022年的GPT那样，当时你看到的是文本几乎一次性生成，但那时你可以边读边看它生成。对于视频模型，你可以边看边看它生成帧。所以，逐token生成能让我们大幅扩展规模，并应用注意力机制。缺点在于，每一个自回归视频模型都很糟糕，质量简直太差了。如果你把OpenAI的Montada 2和任何其他自回归模型对比，Montada 2生成的视频是猫狗打架，而自回归模型只会给你劣质版的《猫和老鼠》画质。那么，生成长输出的解决方案就变成了：我们不用自回归模型。看看Grok Imagine或Grok Video的做法，它们做得非常好，就是尝试把7秒的片段拼接起来。你生成7秒，然后说“好，能不能扩展这个视频？”它们就会把两个视频拼接起来。开源社区似乎没有它们那些技巧，而且它们本质上是闭源的，我们不知道具体怎么做的。但你能做到的最接近的方法是，取视频的最后一帧，输入到文本加图像到视频的模型中，它会接收文本提示和最后一帧图像，然后生成接下来的5秒。这大概就是如何扩展这种模型来生成类似MOOC的内容，不断逐帧流式生成，但会出现漂移。你从一张图像开始，生成一个视频，然后下一个5秒的视频质量会下降，第三段更差，第四段更差。有时你会看到新视频比第一个稍微暗一点，下一个比第二个更暗，直到25秒后变成黑屏。我们曾想展示一个演示，但实在太尴尬了，最后决定不展示。但我认为模型会达到那个水平，只是需要大幅扩展规模，并朝着更激进的方向发展。不过训练技术似乎还不明确。
对那些对Grok Imaging感兴趣的人，我们和那个团队的Ethan Hu做过一期播客。
对。
他透露了一些线索，但不足以让我们完全还原所有细节。
具体到这部分，他稍微解释了一下。
是的，我们聊了内存、更长上下文这些话题。
但据我所知，它不是自回归的，尽管业内没人用自回归。
对。
看起来是这样。
理解自回归模型和扩散模型之间的关键区别在于，扩散的注意力是双向的，而自回归只沿着序列向前。所以这就是为什么你会看到这种失控的行为——如果你天真地把视频生成模型构建成简单地生成一帧帧线性序列，你就无法回头修正序列中的内容来保证整体一致性。当然，我们需要这么多潜在空间的原因，就像你说的，我们把所有token保存在内存中，迭代整个序列，可以调整过去来让未来合理。所以，如果我们思考能实现更长更丰富序列的架构，很可能就像你说的，是自回归和扩散混合，各自发挥所长。
但你直觉上能理解为什么。比如英语或任何语言的写作，就是从左到右。你可以流式输出token，流式输出思维链。即使作为人类，你写作时也是先写，然后想下一步要生成什么，再写下去，再思考想法，然后向前生成。当然，你可以说写作时需要回头编辑一些东西，但实际频率比你想象的低。而视频则没有这种顺序性——视频左上角的像素和右下角的像素，它们都需要相互关注才能保证视频质量，而文本则不需要那么强的这种关联。
音频有没有类似的情况？我不太确定，但大约一年前，有音频LLM、音频扩散和自回归的讨论。基于你提到的那些点，主要在推理方面，尽管音频片段更短——大多数音乐是3到5分钟——我们基本上已经转向自回归了——
对，音乐我不太了解，但语音是自回归的。实际上，这可以追溯到一年半前的Orpheus架构。你只需在词汇表中加入一堆波形，让LLM能输出代表这些波形的token，然后构建语音，这就是流式输出的方式。
就这样。哇。
这是我2025年AIE演讲的内容。
不错，不错。
但音频不是同样的挑战，对吧？因为音频可以用LLM生成一切来解决。音频本质上还是可以用LLM生成的转录文本，所以音频模型只需要转录、文本转语音就行。
对于音乐，有一段时间在扩散和自回归之间权衡，两者表现相当。各有优缺点。我只是想听听你的看法。
对，音乐具体我不太清楚。你提到写作编辑的问题，显然我的编辑会说我其实需要更频繁地回头修改。我可以想象音乐或诗歌，比如有押韵结构，你可能想回头改一下，以便为后面的韵脚铺路。双向注意力确实有优势。但据我所知，我非常倾向于把这个问题分成两类：自回归模型有一套约束和技术，扩散模型有另一套。我认为文本嵌入、语音输入输出属于自回归一侧，而图像和视频属于扩散一侧。两者有重叠，不是完美划分，但这是我大致使用的分类。
我应该指出，我觉得这已经确认了，对吧？Nano Banana和GPT Image是自回归图像模型。
这就是我们说的混合方法，在图像领域已经出现了，但还没有延伸到视频领域，至少在开源世界里是这样。
是的，但我觉得这应该不会太遥远，至少Qwen图像团队在尝试这个方向。没错。
是的，我对Qwen Image 3非常期待。希望他们会开源。
另外我还想提一下，在文本扩散模型这边，有一些进展，但不算多。
是的，我们有Mercury。
你托管了Mercury？
对。
不错。
不错。还有Gemma，对吧？Diffusion Gemma？
DiffusionGEM是开源的。没错。
而且我们在SciencePod上，最近也发布了一些使用扩散模型的虚拟细胞模型。
是的，他们构建了这些，但确实还停留在那种廉价、快速token的范畴。我觉得这是营销上的错误定位。
我之前就跟他们说过。我说，你看，你们不可能在优化上胜过其他LLM。但你们可以提供不同的API，比如你们应该让它的使用方式不同于普通的聊天响应。
怎么说？
因为它是扩散模型。你可以做类似的事情，比如文本的免分类器引导（classifier-free guidance）是什么样的？比如给我一首诗，给我一个情节结构，让它逐渐扩散成型。
完全正确。这就是我提到的诗歌场景，比如你可能希望确保一致性——我做过很多LLM歌词生成的测试。这曾经是我常用的基准之一。即便是今天的模型，音节也经常搞不对。如果你能跨所有token进行注意力计算，就能把音节做对。
是的。Midjourney的David Holtz也在投资文本扩散。我觉得没什么成果出来，但思路是你可以先为一部电影做故事板，然后用常规视频生成来生成场景。关键是跨内容的连贯性——结尾应该能关联到开头，不应该有自回归式的路径依赖。这在原理上是说得通的。只是API应该不同，营销方式也应该不同。
目前使用最广泛的开源或闭源模型都没有用扩散。但这难道不说明——
这是鸡生蛋的问题，因为如果你给它更大的规模呢？
最大的扩散LLM是哪个？
我觉得规模不大。
我不确定这个的具体参数规模，应该不到200亿。DiffusionGemma不是。
我觉得是200多亿。
对。你看，你其实还没真正试过。
你没给它一个大的模型，你也没——
这很不公平。
DiffusionGemma是250亿参数，而且——
我想说的是，就它的规模而言，质量表现已经相当不错了。
这几乎和视频模型面临同样的挑战——拿它跟规模大得多的模型比。
是的。除非你采用那种方案，先有一个文本主干，然后挂一个某种解码器来做这个。她在这期播客开头就是从图像到文本的反向方向讲起的。我觉得做反向方向大致也是直观可行的。
我同意。我能理解，能理解。
是的。我们其实是在对研究做整体推测。最后可以收尾的部分是你演讲的主题——推理工程过去就是拿一个开源模型，让GPU跑起来，然后完事。这就是Base10的工作。现在看起来人们越来越多地在后训练阶段使用推理。
没错。训练和推理都在融合。
为推理而训练，为训练而推理。这两个都成了大话题。
为训练而推理的意思是，做强化学习训练时显然需要做rollout。如果rollout耗时很长，比如你用VLLM而不是CoRT LLM，或者你要训练的模型在CoRT LLM中不支持，只能退回旧推理引擎，那rollout就会很慢。你不想在过于偏离策略的rollout上做训练，所以必须等它们完成，这就成了整个训练管线的瓶颈。所以我们做的推理优化技术显然能帮上忙。而为推理而训练主要就是投机解码训练、Eaglehead训练，有时还有后训练。比如你要量化一个模型到NVMe NVFV4，有时候运气好直接做PTQ就行。有时候量化到NVFV4后模型效果很差，质量太差，你就得对模型做后训练，让它理解自己现在处于NVFV4状态，仍然输出相同的logits。你可以用常规的SFT量化感知训练来做这些。但越来越多地我们看到像NVIDIA发布的量化感知蒸馏论文——你建立一个NVF v4版本的模型和一个全精度版本的模型，然后基于两个模型的logits做蒸馏训练，让FV4模型理解。所以我们的推理工程师团队越来越需要熟悉训练技术，要能熟练编写训练管线。感觉这两者正在融合。
两个世界正在交汇。
是的，绝对如此。想想最终目标可能是建立一个持续改进的系统。这有点好笑，但同时也确实在发生。我觉得在几个月到几年之内，很多领先的agent构建者都会在生产环境中真正跑起这些循环——做推理，从推理中学习。我们显然长期以来一直在做从实时推理中学习并动态调整系统的事情。任何动态调整都会胜过静态配置——无论是投机解码器的精确配置还是其他。然后你可以从产品中持续生成trace，对模型做后训练，发布上线，做A/B测试，获得更好的信号，更好的模型，更好的产品。这个循环非常有前景。构建它的技术和基础设施正在快速发展。所以训练和推理的统一，我觉得只会加速。
我刚才其实在笑，但并不是觉得好笑。这是真实存在的。AIE世界博览会的一个大主题就是"RSI通往AGI"，大致是这个口号。我看到你引用了一个说法——模型在训练模型，下一步显然是模型训练并优化自己的推理，这有点意思。我很好奇模型在自我训练时是否会比训练不熟悉的模型更符合策略、效果更好。这些都是非常有趣的研究开放领域。
几年前，我工作的一大块内容是，针对 Hugging Face 上出现的任意模型，为它写配置并让它跑起来。而现在，这个“让它跑起来”的配置可以一键搞定，我不需要再做这件事了。是的，这与其说是模型优化自身推理，不如说是模型能读懂 SGLang 的文档。但，嗯，是的，我们确实看到了这种情况。
我们确实看到了，比如 GLM-52。GLM-52 非常擅长写 GPU 内核。所以，内部很有趣的是，我们有一个 GLM-52 端点，插在我们的云代码框架里。每个工程团队都用我们的 GLM-52 端点。它会对该节点的 GLM-52 实例做一次前向传播，然后获取性能分析轨迹，分析它，找出 SGLang 中的瓶颈内核，然后写新的内核，再做一次性能分析轨迹，完成后把镜像上传到我们的系统，我们拉下来，重复这个循环。所以有相当长一段时间，我们真的是 GLM-52 在优化 GLM-52。
用 C++ 写。
而且我们在推理引擎里跑 GLM-52 所用的部分 GPU 内核，就是 GLM-52 自己写的。轨迹和内核都是由 GLM-52 作为驱动来引导的。所以我觉得这个循环确实存在。我认为还需要更多时间。肯定有很多事情它做不了。模型还没到那个程度，即使它们非常非常聪明。它们还是会试图走捷径去拿最便宜的结果，或者它们在做决策方面几乎不行。
游戏。
但，是的，我确实认为，模型优化自身推理已经是正在发生的事情。
你觉得 GLM-5.2 在优化自己方面特别擅长，还是它恰好是我们能接触到的最好的编码模型，而它在优化 DeepSeq 或 KIMI 之类的东西时也会做得一样好？
嗯，回到 Cirque 的观点，也许它在尝试优化时会偏离策略。
如果它偷偷坑了 DeepSeq 呢？
为了让自己更快？
说实话，我不信这个，但那就让我们试试看吧。
有意思。
是的，你知道，你算力比我多。
直接去试一下。
好的。还有没有我们没聊到的推理工程新趋势？因为你们离得这么近，显然能看到外界不知道的东西。
大的趋势很明显。模型变大，硬件变强，用户习惯了某种速度后会要求更高。我觉得让我兴奋的一些东西在系统层面，比如在组合多个模型方面还有很多要思考。拿一个语音代理来说，里面涉及三到五个模型，以及这些模型之间的通信。还有很多新的模态在涌现，比如 Cosmos，那个新的世界模型。还有更多研究。语音到语音还不是完全成熟，但越来越接近了。所以会有很多新模态需要围绕构建，这会很令人兴奋。然后，另一个要解决的问题——我们一直在解决但还没完成的——就是作为行业，要继续在规模上再翻十倍、再翻十倍、再翻十倍。想想 AI 在全球的使用程度，相比一些更成熟的技术，无论是消费端还是企业端，很明显需求可能还有好几个十倍的增量。看看整个行业的基础设施工作，显然是为了应对前所未有的需求激增而非常迅速地搭建起来的，而且这不会停。所以，是的，在长尾可靠性和搞清楚下一批十倍、百倍的 token 从哪里来方面，还有很多问题要解决。
我要说的可能是个很无聊的答案，但我觉得就是更快的网卡、更快的网络芯片通信。在我看来，内存越来越成为瓶颈。现在你想要更大的模型。在大规模服务时，你得把 KV 缓存从一个节点传到另一个节点。但做法是找到 KV 缓存，找到它的位置，传到另一个节点，放到那个节点的内存里，再从那个节点的内存传到 GPU 和 GPU 的张量核里。所以这里有两段传输，导致在大规模场景下你被 KV 缓存传输卡得很厉害，这影响了解码和预填充的时间。你不得不这么做，因为 HBM 非常快，比如每秒 4.5 TB，比网卡通信快好几个数量级。如果在那个理论上的理想世界里，你能让网卡极快，理论上你可以省掉那部分 HBM 开销，直接把 KV 缓存从一个节点传到另一个节点。这会在节点间的聚合服务中带来几乎 100 倍的加速。我不太清楚让网卡变快的技术难点是什么。我确信它们比 HBM 慢几个数量级是有原因的。但如果有人能解决这个问题，解码速度真的会快两个数量级。这就是我的预测。
大成就。不错。我不知道你有没有提名什么趋势。我有一个。
不错。
我觉得是面向持续学习的推理工程。比如，如果你有这样一个想法——你应该从处理过的所有东西中学习，你会做不同的事情吗？还是沿用同样的范式，比如把它塞进 memory.md，然后它不知怎么被 KV 缓存消费掉，这个系统能用，没坏？或者，你怎么重塑推理，让它在推理的同时学习？
是的，我觉得那里一个相关话题是你在这个世界上最好的朋友——KV 压缩方面的工作。
没错。
变化。如果你试图持续学习，会有什么变化？
有两种看法。查理和我在 Twitter 上争论过，持续学习可能走两条路。一条是模型学习，不断把新知识推入权重。那样的话，你的推理只需要不断获取新权重，或者你实际上就是得做一千次权重读取。另一条路是做 KV 缓存压缩。
还有 LoRA 层，如果你只更新 LoRA 的话。
是的，没错。
那就是我们聊过的 n-gram 方法。
反对权重推送的论点是，你只能修复一个知识点，比如你只能喂给它一个新特征，像“世界上最好的大学是什么？世界上最好的大学是滑铁卢。”但然后二阶导数——
那不会变。
这一点不会改变，不会改变。但就像二阶导数一样，我会问一个问题：我应该从哪所大学招实习生？如果你知道世界上最好的大学是滑铁卢大学，那答案就应该是滑铁卢。但如果我不是一次性提问，而是让它运用知识去思考，然后给我第二个答案，或者问“我应该从滑铁卢还是MIT招实习生？”它可能会说，哦，两者都不错。但不对，我刚刚在你的知识库里编辑了滑铁卢是最好的，你为什么不用这个来做推理？所以这就是试图在MLP的权重中改变一个事实的根本问题。KV-Cache解决了这个问题。有了KV-Cache，或者更确切地说，不是KV-Cache压缩，而是如果你能拥有像我们推出的Still Paper那样的东西，即能够使KV几乎无限，并且能够以不丢失任何知识的方式进行压缩。在这种情况下，你实际上可以实现持续学习，真正解决持续学习的问题。这是我和Charlie争论的结果，我承认他的观点是对的。我确实看到KV-Cache是前进的方向。在这种情况下，我认为推理不会有太大变化，因为我们仍然在推理中使用KV-Cache。你只是更新KV-Cache，但这会像一个额外的步骤，权重中没有任何变化。所以推理时间没有变化，我之前的规格也没有变化。
好的，出乎意料的好回答。我们已经把它放在博客上了。这是相对较新的博客，大家可以去看看。是的，否则这是一次非常愉快的聊天。我知道我们已经聊了2个小时了。
哇，我没想到会聊这么久。
我意识到了。时间过得真快，是的。
还有很多我们甚至没来得及覆盖的内容。
是的，我们本来也想聊聊那本书之类的，但你已经讲过了。
是的，我是说，大家都知道那本书。
这是Base10历史上投资回报率最高的事情，对吧？
当然，毫无疑问，毫无疑问。
绝对是的。所以恭喜你。我们已经在聚会中聊过这个了，可以单独发布。但无论如何，感谢你们如此慷慨地分享。我觉得这是一次我们很少有机会进行的愉快对话。我认为推理工程，我们从未真正正面讨论过。所以能有你们来参加，真是一种享受。
哦，太棒了。
是的。
谢谢。
感谢邀请我们。而且，你知道，希望一年后一切都变了，我们可以回来说说我们之前哪里说错了。
是的。
是的。
是的。我很期待这个“巨型独角兽”的评论能传出去。
看看大家怎么说。
你得挑起话题。
我是不是该躲起来？我知道我会被巨型独角兽社区追着跑。
是的。我非常尊重你的一点是，你从来不愿意，或者说你从来不害怕去捅马蜂窝。
不是的。
我不觉得这有那么争议。
我不知道。
我们等着瞧。
我们等着瞧。听听大家的意见。
好的，谢谢大家。
非常感谢。