#668.AI领域的下一个百倍增长：推理、网络与自我优化模型

目录

• 长查询的缓存、预填充与解码 [00:00:00 - 00:10:00]
• 视觉模型改造与开源组件组合 [00:10:00 - 00:20:00]
• 模型支持、量化与生产级 API [00:20:00 - 00:30:00]
• 量化与投机解码带来的性能跃升 [00:30:00 - 00:40:00]
• 张量并行、专家并行与网络互联 [00:40:00 - 00:50:00]
• Mega Kernels 与推理基础设施化 [00:50:00 - 01:00:00]
• 硬件代际与视频扩散推理 [01:00:00 - 01:10:00]
• 视频、音频模型的推理路径 [01:10:00 - 01:20:00]
• 训练与推理闭环、模型自我优化 [01:20:00 - 01:30:00]
• 网络、KV 缓存与持续学习 [01:30:00 - 01:36:35]

长查询的缓存、预填充与解码

欢迎收听跨国串门计划,这是一档专注于让中文听众无

swyx：欢迎收听跨国串门计划,这是一档专注于让中文听众无障碍欣赏全球优质外语播客的节目。通过先进的AI生文克隆技术,我们不仅将内容翻译成中文,还完美保留了原主持人和嘉宾的独特声音,为您呈现全球顶尖的AI财经。健康与科技领域精品内容,我是主播一凯,一位热衷于AI领域的产品经理。很荣幸能为您搭建这座跨越语言障碍的桥梁，接下来让我为您简单介绍本期我们克隆的这档节目，本期我们克隆的是知名AI工程播客Latent Space的一期深度对谈，主持人swyx与Baseten的资深推理工程师Philip Kiely和Ali Taha一起，聊了聊推理工程这个AI底层环节的实战内幕，这期内容更新于2026年8月，围绕新模型发布后如何从能跑变成跑得快又稳展开，涉及量化投机解码草稿模型并行这些硬核话题，也聊到了模型自我优化这类前沿趋势，那我们就一起来听听这期完整的对话 GLM5.2写GPU内核非常非常厉害，我们内部觉得特别有意思，我们有一个GLM5.2的接口，接近了我们的Claude Code框架里，所以每个工程团队都在用我们的GLM5.2 它会在节点上的GLM5.2实例上做一次前向传播，然后拿到性能分析跟踪，自己分析，找出SGLang里的瓶颈内核，然后写新的内核，再跑一次性能分析跟踪，等它跑完了，会把镜像上传到我们的系统里，我们就能拉下来重复这个循环，我们推理引擎里跑GLM5.2用的有些GPU内核，就是GLM5.2自己写的，在进入今天这期节目之前，我有一件小事想跟听众朋友们说，谢谢你们，如果不是你们选择点进来收听我们内容，我们不可能给你们带来，你们这么想要的AI工程，科学和娱乐内容，几乎每天都有人来找我们谈赞助，但幸运的是，有足够多的你们真的订阅了我们，让我们能不带广告的一直做下去，我们也想保持这样，但我只想请你们帮一个忙，你们能做的最有利，完全免费的一件事，就是点一下订阅按钮，这是我对你们唯一的请求，这对我和我团队里的每个人来说都意义重大，我们每周都那么努力的把这些内容带给你们，如果你们订阅了，我保证我们会一直努力把节目做得更好，现在我们开始吧，好今天我们请到了Philip 老朋友了写过《推理工程》这本书，也在Baseten工作，还有我们之前一起做过的《试》 以及阿力欢迎，欢迎，很高兴见面，滑铁卢实习生，滑铁卢实习生，一直都是，你什么时候开始用滑铁卢实习生这个，作为昵称，哦，我觉得改名大概是在三月中旬，我看到这个昵称空着的时候，我就想，我必须把它抢下来，问题是 [00:02:42]

Philip Kiely：Ali工作太出色了，他当不了太久实习生，所以我们得想想，谁来接这个昵称，把火炬传下去，哦，好，可以这样，你就把它传给下一个滑铁卢的，另一个滑铁卢实习生 [00:03:06]

swyx：不是Brad 实习生，实习生，你得从滑铁卢找个实习生来，对我们得从滑铁卢找个实习生，他们有这个传统，但这个人可以来自Baseten 所以只要是Baseten 从滑铁卢招的人，就有滑铁卢这个头衔，他们得打败你，没错，就像打副本打到一半，要么你拿到他，要么你就出局了，你还应该办一个盛大的毕业典礼，把昵称正式换掉，就比如说，我是说你们显然很擅长搞仪式，你看我们那本书的发布办得很成功，但在聊这些之前，我想先问你们一个有趣的问题，好你是资深推理工程师，当我发一个长查询，比如20万Token进Baseten的推理服务，会发生什么，查询经过GPU 模型路由负载均衡，整个过程是怎样的，这些我们平时根本不会想的东西都是什么，具体到长查询，我第一件要问的是 [00:04:13]

Philip Kiely：你之前给我发过这个查询吗，或者至少发过其中一部分，我真心希望发过，因为这样对我来说容易得多，对你来说也便宜得多，所以我们要看的第一件事，是某种缓存感知路由，我们会看，我们大概有多个实例，多个副本在跑你访问的那个模型，我们要把这个请求发给一个，第一有可用可用的推理 worker的，第二最好已经有缓存输入的地方，这样至少能跳过这20万Token里一部分的预填充，如果你发20万Token 那很可能是编程或者多轮agent之类的场景，这种场景你通常会期望有缓存，如果没有我们就得发给预填充Worker 我们至少在部分模型上做了分离式预填充和解码，所以你会有一组GPU专门处理输入，生成KV缓存给你第一个Token 然后那个结果会传给另一组GPU 由他们来跑解码，我们会迭代的生成这些token 我们可能还会在前面放一个，某种投机解码的草稿模型，我假设你在做编程，因为这样我们的草稿模型，它假设你在做编程，就会有很高的草稿token接受率，如果我猜错了，你其实是让我总结每一本哈利波特，那就会慢一些，然后我们把输出流式传给你，记账收费大概收你几分钱，然后说还想再发一个吗，只不过Baseten是按几分钱来收的，对我们收费，我假设我们说的是公共模型API 如果你是搭一个专用部署，那当然就不是几分钱了，对我是说，我最初跟Baseten聊的时候 [00:05:12]

swyx：一个关键区别就是，其实想要极大规模的用户，只需要按整台机器租，因为接下来怎么把机器跑满，就是你自己的事了，而且很多时候，如果你每小时推几百万token 按小时付费 [00:06:03]

Philip Kiely：会比按token付费便宜得多，对确实，我觉得我们越来越多的看到，按token付费的API需求很大，因为大家都想试试开源模型，等他们找到一个真正粘住的使用场景，就会转到专用部署，那什么时候该切换过去，他们的最佳实践是什么，有几个原因

swyx：对可靠性，这是个大头，对吧，比如他们有一个非常特定的使用场景，想让你专门为他们训练点什么，比如他们想要自己的投机解码器，针对他们自己的流量 SpecDeck就是投机解码，投机解码，对比如抱歉，具体说如果你有一个巨大的模型，对吧，这个模型每一轮，每一次前向传播都只能生成一个token 所以我们就在模型上面挂一个这种小寄生层，这个模型只需要做预测，它做三次非常快的自回归前向传播，它会预测出三个特定的token 然后你对整个原始模型，做一次前向传播，看看这些预测对不对，然后你接受它们或者拒绝它们，这个草稿模型是针对特定流量的，所以如果你，比如像Philip说的，你在总结哈利波特的书，我可以专门用哈利波特的书，来训练那个草稿模型，我可以保证每次都能接受那三个token 这样的话，我就提高了你的解码速度，但如果你要共享一个端点，我就没法给你提供这个，因为我完全不知道你是在做哈利波特，做编程还是做英文，我们不知道，另外书里提到，他们很在意一个特定预值，好像是第四章，你还记得吗，对你能做的事情是，你可以设置特定的P处理大小，特定的并行策略 [00:07:34]

Philip Kiely：如果你想在吞吐量和延迟之间做优化，你可以比如，也许NVFP4量化过不了你的基准测试，你想用更高精度跑模型，你也可以这么做，想拥有自己端点，有一堆理由，当然最大的一个就是，你不用再正好，要服务自己用户的时候，去应付别人，往端点上砸的，逐 token基准测试流量，对我觉得有一个

swyx：很经典的路径，基本上就是Viva在问的，当你在浏览器里，输入Google的时候，会发生什么工具调用，是不是就是生成 JSON那么简单，还是说背后，有更复杂的机制，我们有些客户，他们有自己的，后训练模型，所以他们要求的工具调用，不只是那种解析文件，或者查天器的简单场景，而是非常定制化的东西，你必须针对这个做后训练，如果模型的后训练做得不好，或者后训练之后为了推理速度，做的量化影响了效果，模型在读 JSON文件和工具调用的时候，就会很吃力，但这并不需要单独的沙箱，不是说他会用工具调用来逃逸沙箱，或者需要被隔离，他就是一个普通的专用部署就行，工具调用越来越大的挑战在于，公司想要特定的工具调用行为，而这本身是非常难训练的东西，因为你面对的是大量的JSON输出，如果他没有以非常特定的方式，闭合请求的结尾，你就会得到一个，已经完成了工具调用和思考的模型，结果就是，他没有看到工具返回的结果，而是在解码过程中 [00:09:15]

Philip Kiely：直接幻觉出了一个结果，这似乎是工具调用最难的环节，而不是沙箱的问题，对这是训练测的挑战，而在推理测，你可以做一些工作，来限定可能的输出范围，我们其实在差不多两年前，就发布了这个问题的解决方案，基本思路就是构建一个状态机，用它来约束输出到特定格式，这就是结构化输出问题，如果你还记得当时，对有特定的文法，对 GBNF 当时有这个东西，对

视觉模型改造与开源组件组合

对

Philip Kiely：对，所以这就像那种老派的提示词，比如确保只返回JSON 只返回JSON [00:09:59]

swyx：不然我奶奶会死那种 BNF文法，当时OpenAI发布过一个东西，就是说如果你想约束输出，就写BNF文法，在我们的推理系统里，就是一个指定的输出格式 [00:10:07]

Philip Kiely：你能得到保证，输出会按照那个格式结构化，把它应用到工具调用上，可以帮助减少问题，当然你仍然可能调用错误的工具，或者不调用工具，它解决不了确定性的问题，但至少它解决了工具调用内部的输出结构化问题，而MCP只是工具的另一种形式，对吧，对没错，那里没有什么特别的东西，我经常跟人解释的一点是 LM实际上没有能力做任何事情，它只能提出行动建议，然后如果这些建议以某种方式格式化

swyx：并应用到一个知道如何处理它们的系统上，行动才会发生，对有趣的一部分是，这个问题在工具调用之外，也有解决方案，比如在智能体循环里，如果输出不正确，或者推理式的工具调用出了问题，模型就会想，我不知道该怎么办，让我再试一次，试几次之后可能就成功了，关于你说的训练问题，有时候在小模型上更难，所以当你从大模型换成小模型时，输出质量不会完全一样，对吧，对，我想说在我们继续深入推理工程之前，我本来预期会有东西取代JSON 因为JSON很难流式输出，因为JSON必须完整，必须有开辟括号等等，所以在流式传输的过程中，很难解析或验证，人们发明了各种替代方案，我忘了其中一些的名字，基本上就是类似TOMO 类似YAML的东西，但JSON似乎仍然是主流 JSON输出其实没那么长 [00:11:53]

Philip Kiely：对吧，我的意思是，你确实可以有很长的，因为工具调用力也包含参数，也许对于某个工具，你可能会传一个很长的参数，但我的印象是，一般的工具调用token数量相对较少，对吧，所以我预计投机解码，对JSON这种格式化的东西，通常表现不错，这样解码步骤会很快流失的价值，就没那么大了，但也许我错了 [00:12:04]

swyx：你还受限于软件，或者说模型要集成的那个系统，如果软件是用JSON来做工具调用的，或者你的客户说，我们的软件就是这样工作的，工具接口就是JSON 你可以要求他们改软件，然后说这样对模型更好，但如果训练得当，应该不会有太大差别，而且如果输出更多Token 可能还更赚钱，这取决于你的商业模式，真的要看情况，但我要说，作为一个对AI生成内容，很有经验的写作者，我确实会尝试从文本，转向JSON 文本，就是那种非常长的JSON 对吧，每个字段里都有大段文字，因为我想让它结构化，对吧，我希望你先做事实陈述，然后给观点再做要点总结，要有日期，有实体引用，有参考来源，所有这些，总之，我觉得真正深入实验，结构化输出的人，必须得关心这些，但咱们还是往上一层看看吧，在开始录音之前，你其实提到了一件很酷的事，就是当一个新模型提供商，发布新模型时，背后有大量的工程工作，推理工程要做，对吧，咱们就拿GLM 5.2 Kimi K3来说，我之前以为，尤其是像GLM 5.1 再到5.2这种，你们之前已经支持过他们了，工作量会那么大吗，工作量很大，对，好吧，所以你看，很多人，你们这些人，对吧，每当有新模型发布，大家就急着说 Hugging Face支持这个了 Firework支持这个了 Baseten支持这个了，我就想，对当然支持了，但背后到底要做什么，我觉得这不仅仅是支持而已，对吧，对消费者来说好处很大，我记得是Kimi K2.5 或者GLM 5.2 最新的那个，当时有一场推理速度竞赛，对吧，有的提供上每秒90个token 第二天我们就到了，每秒150个，这个其实是我用GLM 5.2 调起来的 [00:14:17]

Philip Kiely：我写了一篇推文，大概有50万浏览量 Baseten排第一，对，或者说够活跃，对，这让大家都特别兴奋，想着，我们怎么才能把基准测试，再往上推一推，而且支持这个模型，和支持这个模型，是有区别的，前者是我能让这个模型，产出token 后者是我能基于这个模型，提供一个生产级API 做到能让模型产出token这一步，其实不难，因为一般来说，开源推理引擎，像VLMSG 这些维护者，甚至经常能提前拿到权重，或者做模型的人，会合并PR来确保支持，所以大多数情况下，你基本上用标准开源技术站，就能跑起来，不会太费劲，真正的挑战在于，每家推理公司，都有自己的专有技术站，有些开源组件，有些是自研的，而且对任何一个新模型来说，总会有一些新东西，有时候你运气好，比如K2.5到2.6就挺相似的，对如果我没记错的话，那纯粹是持续后训练，就算是那种情况，还是有事情要做，你得重新做量化工作，这些模型发布时，一般都不是NVFP4格式的，而我们希望，它们变成NVFP4 以获得最佳的Blackwell兼容性，所以我们要执行量化，还要校准量化，确保不会造成，模型智能上的任何退化，然后我们还得训练投机解码器，就像我们之前聊过的，一般来说我们的模型API显然有ZDR 也就是零数据保留，所以我们并不确切知道用户发来的流量是什么样的，但我们知道什么受欢迎，知道编程用量很受欢迎，知道agent类用量很受欢迎，所以我们可以拿到能代表这类流量的公开数据集，然后训练通用的投机解码器，现在的投机解码器，你需要用基础模型本身来训练，因为你要从模型在这些特定提示上跑推理时拿到隐藏状态，那就是你用来训练投机解码器的训练数据，所以有这个过程需要真实的模型权重，然后当然还有搭建背后所有基础设施，加载所有东西，做测试的过程，而且当新模型有更新的架构时，我觉得显然DeepSeek的模型通常是最有挑战性的，因为他们每一代都有最多新颖的架构设计，但每个新模型都有点新东西，我是说 KimiK2有，抱歉 GLM5.2有，希书，对，就是DSA 这是从DeepSeek那边来的，对对，而且你知道我们，所以你可以直接复制粘贴，对吧，我不知道这是怎么运作的，所以我们得在我们的运行室里为它构建支持，你说的对，这真的很有意思，这些开源实验是互相借鉴的方式，比如GLM5.2没有视觉能力，所以我们团队有个叫黑里的人，如果我们能看一下的话，他基本上是把Kimi的视觉编码器，嫁接到了GLM5.2上，完整训练了投影器，完全正确，所以你想编码器这部分，是负责看图像，把它变成潜在信息的部分，然后还有投影器，它有点像空间上没问题，然后还有投影器，它把信息映射到模型本身，再就是模型权重，你不想动模型权重，因为为了给它视觉能力，你有可能让它在别的方面变笨，所以Haley一开始只加了投影器，那只有几百万个参数，对，然后你能展示一下训练过程吗，它那种突然学会的方式，非常非常有意思，也许，也许阿力，你来接着讲吧，你比我更懂这个 [00:17:56]

swyx：对你可以看到，他训练这个模型的方式，真的非常非常酷，一开始，他只是用这样的方式训练，这里有一张山的图片，你能描述一下，这座山里有什么吗，然后这就导致了第一次，第一次学习损失，你看这里，我们想教他的，只是翻译编码后的信息，他已经拿了KimiK的编码器，他已经拿了图像，对冻结的，冻结的，冻结的冻结的，带适配器，所以理解能力，大脑是冻结的，眼睛也是冻结的，我们只是想把眼睛和大脑连接起来，对吧，就是投影器，然后你拿到token 他就说，你能描述一下这张图里有什么吗，然后他就说，这是一座山，或者是一个人，或者是一个人类，诸如此类，但这并没有带来完整的理解，所以他改了方法，让每张图片都关联一个问答数据集，比如这张图里有没有一个白人男性，这张图的左上角有没有鸟，这张图里有没有科学家，诸如此类，他必须正确回答这些问题，而且不只是训练他描述图片，还要能回答问题，回答一个问题，再回答一个问题，就这样持续的一问一答，你可以看到那种突然学会的现象，这真的很不可思议，把一个视觉能力改装进一个大语言模型，居然能学到这种程度，而且即使是他表现不好的图片，比如你给他一张斯蒂芬，霍金的照片，问这是谁，他可能答不上来，但他会说，这是阿尔伯特·爱因斯坦，他仍然明白这是一位科学家，是一位男性，有一些重要成就诸如此类，所以这真的非常非常酷，对我们之前讲过Howtian 他是Lava论文的作者，那篇论文之前就做过类似的事，我觉得对任何没做过，视觉工作的人来说 [00:19:10]

模型支持、量化与生产级 API

视觉工作的人来说

swyx：视觉工作的人来说，那都是非常基础性的工作，还有Clip和Metaclip也一样 [00:19:59]

Philip Kiely：从单纯的图像描述，到基于图片构建问题，性能能提升多少，对对对，对但这件事最让人兴奋的是，如果你看这样一个模型，当然这稍微更像一个研究项目，你知道它在MMLW Pro上，拿到了56% 我觉得所以还不算最前沿，但如果你运行这个模型，你的GLM5.2质量没有任何损失，如果没有图像输入，它的行为和以前完全一样，而且最终在推理代码里，你根本就不会包含另一部分，对吧，对，我的意思是如果没有图像输入，你直接跳过编码器就行，好，只是确认一下，这对整体推理端影响大吗，你并没有增加太多东西，你只是加了一个很小的视觉编码器，这些通常都不到实意参数，对我的意思是，视觉编码器之间的标准化程度稍微低一些，所以知识矩阵可能会稀疏一点，但总体来说，对它是整个系统里一个相当小的组件，而且最终你从这个系统里得到的是，突然之间你有了Kimi的视觉 GLM的权重和DeepSeq的注意力，全都在一个模型里，我觉得开源的力量和美妙之处，很大程度上就在于，你可以把所有这些不同的组件组合在一起 [00:20:58]

swyx：形成一个比任何单独一个都更好的系统，以前人们说你会做弗兰肯斯坦式合并，就是从每个模型里取一些层拼起来，现在还有人这么做吗，回到你之前提到的，当一个模型刚出来时，比如GLM 5.2或Minimax M3 支持它需要做很多工作，有时候你确实需要，确实需要换掉一些东西，比如 minimax M3的头部，用的是全注意力，用全注意力的话，你会得到一个，非常离谱的瓶颈检查器，因为你要为三个token 做自回归生成，而且你要对所有序列里的token 做onfade计算，你的kv缓存会非常大，因为它不是吸输的，不是top k 所以我们发现更好的做法是，好，我们要把这个层换掉，换成另一个模型里，用gqa的层，比如然后只要训练得当，你就能让它达到同样的接受率，所以从其他模型改装层是完全可行的，而且实际上非常必要，如果一个层效率太低，训练就成了挑战，就是怎么确保你把它训练好，这又回到你之前说的，训练和推理之间的紧密联系，也就是说，你需要非常好的训练，才能实现快速的推理，我觉得这一点越来越成为事实，对，在支持这一侧还有什么别的吗，你说的是让它完全达到生产就绪，对我觉得还有一个问题就是 [00:22:16]

Philip Kiely：我们确实能把模型测到相当充分的程度，但我们是急着把它推出去的，然后你看到一大堆其他人来测，就会冒出各种有意思的结果 GLM之前就出过一个事，我们有几次模式崩溃，就是某些提示词，某些温度下，它会一遍又一遍的输出同一个token 一旦你把接口暴露给真实世界，喂进来的东西种类就多太多了，你才能发现这些问题，然后去修补，所以这不是一个发布当天就完事的过程，之后第一周，第一个月，只要模型还火着，你就得一边修bug 一边继续在性能上突破极限

swyx：你是说你不希望你的模型输出一堆SSSS 顺便问一下，那上面有循环检测吗，这种事还是经常发生，挺意外的，我们在接口里做了处理，如果模型连续输出同一个token四次以上，我们就中断这次生成，说抱歉，这个得重试一下，或者说重新处理这个请求，因为我们知道，连续四次同一个token 那基本就是崩了，对，那有没有办法选择退出，万一我真想要那个效果呢，有，其实有的，我记得我们有办法处理这个，我不太确定具体怎么弄，我觉得在某些模型里，比如他们要输出一个表格，你想象一下，他们想画12个破址号，再12个破址号，对我觉得这种情况是有办法让它发生的，我记得我们只对某些Token 做这个检测，会排除掉某些特殊字符，对，所以我们只对某些Token做，比如S在GL5.2里是最常见的，哦，我记得是 DeepSeek V4也是，就是那种循环问题，比如，对有什么特别的吗，没有，就是，它好像就是那一个Token 对，而且只在温度为0的时候，还是其他温度也会 0.9或者别的温度，它照样会崩，那挺奇怪的，对吧，说实话，这是个推理问题，是个软件问题，很多时候，你跑的镜像，比如英伟达，会发布一个镜像，如果我们把他们最新GLM镜像的改动，合到我们的技术站里，就会发现这个问题被修掉了，或者很多时候，这个问题只会在某个推理引擎里出现，比如你用的是某个引擎，但如果你换到VLM 就不会这样，所以这看起来是一个非常非确定性的软件问题，而不是模型本身的问题，不是神众的问题，我们不会说这是量化的问题，我们PDQ做错了，对吧，但那样说不通，因为同样的权重换一个推理引擎，就不会浮现这个问题，有时候是后端用的内核，有那种非常隐蔽的，偶尔出现的静态条件，如果你把这个模型放在某个集群上托管，永远不会出这个问题，天哪，天哪，但放在另一个集群上，就会原因是那个集群里节点间传输KV缓存，用的互联比另一个集群慢，所以那个静态就被暴露出来了，而另一个集群不会，于是最后你就只能这样，行这个模型不能放在这个集群上，我们放到另一个集群去，因为那个集群会暴露这个问题，但最后又会变成，那到底是软件的问题，模型权重的问题，还是硬件的问题，有个问题就是温度设为0 也仍然不是确定性的，对吧，主要是因为硬件，即使温度为0 同一个模型，你也不一定每次都能得到相同的输出，但静态条件那个我挺意外的，因为我以为PyTorch是个计算图，至少能保证按正确的顺序执行，他们不是那样做的，我不是说一定会有问题，但你有像PDL优化这种东西，你可以在前一个内核结束之前，就启动下一个内核，而你是想这么做的，就是流水线并行，对没错，但你不是干净利落的切分，你会让执行有一点重叠，不过我觉得很有可能内核本身，就是那个本该在某个时间点运行的块，那个内核自己就有静态条件，比如缺了一个barrier 通常如果你在设计内核时，想让它非常快，又没有做充分的测试，就可能出现某些线程，在别的线程写入之前，就去读寄存器里的数据，因为你的barrier不对，或者同步逻辑不对，但确实测试本身在大多数情况下，都非常非常难，而且没有像Rust那样的借用检查器，如果你想要内存安全的话，听起来是个类似的问题，对，但你是在CUDA里干活，因为达GPU 就是这样，你只需要一个更高级的语言，比如Modular 也许那就是Modular想做的事，我也不确定，那你怎么看待保持模型质量这件事，你讲了所有这些步骤，要做量化，训练自己的投机解码器，跑在不同的硬件上，再看看其他模型提供商，你在消费端掀起了推理速度竞赛，那保持质量一致靠的是什么 [00:26:56]

Philip Kiely：当然你可以跑基准测试，但你怎么确定量化到什么程度，标准是什么，实际要做什么，质量方面有几件事，大多数推理优化是无损的，比如KV缓存，你只是重新计算，或者避免重复计算相同的值，投机解码，当然如果草稿token是错的，它会被拒绝，主要的有损优化就是量化，而这真的归结为几点，第一数据格式，第二你选择量化模型的哪些部分，哪些层，第三对量化后的权重做大量校准，确保你保留了所有的离群值，不过还有一些别的技巧，一个重要的就是长上下文，因为你一开始问的就是，如果我发一个20万token的请求会怎样，显然输入序列很长时，你需要存储更多信息，需要处理更多token 所以即使一个模型有某个长度的上下文，作为推理提供商，你也可以选择构建一个上下文更短的API 当然也提供完整长度的，因为如果用户不需要完整的百万token上下文，你可以给他们更好的性能，我不知道这算不算严格意义上的模型质量，我对质量的理解是，我们在多大程度上忠实的服务原始模型，如果你想象一个模型的黄金实现，它完全按照模型设计的方式运行，那质量就是我们离100%保真度有多近，当然你也可以从训练的角度，想质量怎么把自己推到100%以上，但当我纯粹想推理优化时，就是在更快的同时，尽可能贴近100%保真度，而且我们内部的标准肯定是，你不应该能分辨出我们的API 和官方API之间的区别，我觉得Kimi在供应商基准测试这块做得特别好，对他们发布了真正的供应商基准测试 [00:29:14]

swyx：因为他们指责了一些人亚马逊，有个提供商在Kimi的基准测试上表现不太好，所以他会反映出来，这是很久以前的事了吧，不大概三四五个月前，这个也发生在我不记得是哪个模型了，但他们撤下了好几个，然后他们开始做了一整张图表，可能是Kimi供应商验证器，对，因为你会很生气，对吧，如果我是消费者，我用的是亚马逊的端点，我用了Kimi 然后我想，天哪这好差，我不会说，亚马逊量化模型的方式有问题

量化与投机解码带来的性能跃升

亚马逊量化模型的方式有问题

swyx：亚马逊量化模型的方式有问题，我会说 Kimi很烂，对吧，所以看起来就是这样，对他们在乎，他们在乎，这倒也是合理的，对，这可能是个很蠢的问题，但我就确认一下，量化之后有没有可能变好 [00:29:59]

Philip Kiely：量化是不是永远只会更差，哦，严格来说不是，量化是有损的，量化是一种有损实现，速度会提升，它确实有改进，显然，比如 [00:30:16]

swyx：我一直在找逆缩放定律，这是我从诺姆布朗那里学到的，就是那些通常朝一个方向起作用的东西，有时候他们会，严格来说

Philip Kiely：当你跑基准测试的时候，因为这些模型是非确定性的，有时候你的NVFP4量化结果，会比原来的高两个基点，对确实，它就在误差范围内，所以我一直说在误差范围内，我后来不这么说了，因为大家都以为我的意思是，在某个误差范围内，我们勉强踩在最差的那一边，所以我们在说的是，但确实，有时候它就是会给出更高的输出分数，但就像阿里说的，那是噪声，据我所知，你并不一定能让结果变得更好，你只是在尽量，让保真度贴近原始模型的100% 说到这点，我们在NEPI上做过研究

swyx：我不知道你能不能翻到那条推文，我们发过一篇研究，是Joshua做的，我记得是一条推文，讲我们量化的GLM5.2 比英伟达的好20% 基本上我们在这两个月的研究里，发现的是量化是有损的，你再把数据从16位压缩到4位，比如所以你显然会丢失一些信息，你要做的就是尽量把损失降到最低，所以当我说我要量化这个模型的时候，我的任务就变成了，怎么找到可以量化的层，怎么找到不能量化的层，比如图像模型，我不会量化调制层，也不会量化输出投影，因为这两个输出投影是用户看到的东西，调制层是模型看到或理解的东西，对没错，所以关于他那篇论文，你有我猜他没有，对那篇论文很长，我不知道能不能找到，如果有可搜索的部分，可能就在那个帖子里，可能就在帖子里，但基本上长话短说就是，量化模型更多的部分，确实有可能让结果更好，比如我有一个模型量化了第150层，另一个模型只量化了第1和第2层，那么量化了更多信息的那个模型，有可能表现更好，因为量化误差相互抵消了 Joshua在他的数学证明里，他有一个验证器，证明了你可以预测哪些层的量化误差，会相互抵消，然后你选择去量化那些层，所以做这种数学量化的结果是，你最终得到的模型，比其他提供商多量化了20% 所以你获得了20%更多的吞吐，因为有更多层在跑NVFP4 而且你的质量比别的量化版本更好，因为你选择量化的那些层误差相互抵消了，一层偏右，一层偏左，一层偏右，你最终的logis分布和原始模型的分布更接近，所以你的保证度更高，我们证明这一点用的是KL散度，我们不只在基准测试上打分，我们计算了量化模型，和原始全精度模型的logits分布之间的KL散度，我们证明了用这个技术，如果你的模型在下一个token选择上的概率分布，和原始模型更一致，你就更可能保持原始模型的本色，所以在这之前，业绩似乎认为量化的越多就越差，因为你引入的损失越多，这不完全对，不一定，所以它不会让结果变好，但可以让误差抵消，我觉得可能就是这个，不过这让我想到了简直，你可以减掉某些层，但很有意思，我不知道这居然能写成一篇完整的论文，有个好玩的事，这篇论文原本有72页，然后我们觉得不能就这么发出去，所以现在它变成了425页，那还是有39页，非常扎实，我们聊了评测这些，那在提速方面能做到什么程度，我觉得这可能是大家最关心的事，也是你文章里写到的，官方API是每秒70个token 你把它推到了90 这是常态吗，做推理最酷的地方在于 [00:34:04]

Philip Kiely：我觉得推理会是一个，值得长期做工程的地方，原因是，如果你看看那些高度优化的领域，比如金融，你在金融行业，你衡量自己提升了多少适用基点，比如我提升了五个基点，也就是1%的1% 那已经是天大的新闻了，因为一切都优化到极致了，当我们发布优化成果的时候，是20% 是100% 是200% 所以老实说，前面应该还有很长的路要走，当研究人员开始发论文，说自己在某件事上提诉了1%的时候，你就能知道推理基本上已经被做透了

swyx：顺便说一句，因为我本身是金融背景，在70年代，那就是当时的利润率，你做量化金融研究的时候，能找到这种机会，而现在就是20% 百分之几十这种，对，现在这些已经变得很小了，感兴趣的朋友可以去看看 Andrew Lowe的论文，他有一个很有意思的图示，量化统计套利分布，从70年代那种20%的差异

Philip Kiely：一路收窄到今天几乎为零，非常酷，完全正确，我们现在就处在同类事情的起点上，不过基准测试很难做，这点我想任何人都会告诉你，给各家服务商的速度做基准测试也很难，因为涉及的变量太多了，你用什么硬件系统上负载多大，提示词的具体性质，输入输出的序列是什么样的，诸如此类，但总的来说，当你把这些改进叠加起来，你看到的是倍数级的提升，最常见的指标当然是TPS 也就是每秒Token数，这其实是我们行业里起的很差的名字，因为实际上有两种每秒token数，一种是吞吐量意义上的每秒token数，另一种是延迟意义上的，对，比如从GPU里出来的总每秒token数，那是吞吐量指标，大多数人关心的只是作为延迟指标的每秒token数，这个我们应该叫ITL 也就是token间延迟，但我们没这么叫，总之你可以想象一个标准的API 没做太多优化跑一个一万亿参数的模型，在合理的流量特征下，大概在每秒30到50个token这个区间，我们通常的目标是把它推到10倍，但也不一定发布当天就做到，而是通过叠加足够的优化，比如你有三个优化，每个都能让性能翻倍，叠起来就是八倍收益，这就是我们在这个领域里工作的数量级，我们追求的是大幅提速，而不是从70提到90 你是说你们已经做到了，这么说吧，假设一个合理的基线，是每秒30或40个token 你可以做到它的10倍，比如在GLM5.2上，如果你不量化，甚至跑在hopper上，只用现成的推理引擎，不做特别的优化，没有投机解码器，没有KV路由之类的额外配置，没有分离式部署，那你大概就是每秒30到40这个水平，你觉得这个基线合理吗，对，要做到10倍左右，你要做很多取舍，如果我们跑到每秒300 400个token这个区间，显然你用的是最好的硬件，有优化过的投机解码器，量化工作全部做完了，缓存命中率很高 P大小比较小，并行配置是针对延迟和吞吐做了调优的，但这是可以做到的，所以你去Artificial Analysis或者OpenRouter上看，最差的服务商到最好的服务商之间的差距，往往就能达到这个量级 10倍当然是非常激进的，通常可能更多是4到6倍的提升，但正是这种性能让我们特别兴奋 [00:38:04]

swyx：能拿到这么大的收益，而不是从70个Token提到90个，这也跟硬件有关，比如你在一台H100节点上提供服务，然后你把模型切分到4台B200节点上，你当然可以通过堆更多硬件来提速，但如果把硬件和GPU数量都归一化到完全一样的话，那就是另一回事了，对那大概就是2到4倍的提升，取决于推理优化做的怎么样

Philip Kiely：所以一部分看车是什么，一部分看司机是谁，如果把2到4倍拆开来看，比如在B200上跑GLM5.2 单节点对吧，为了榨出最后那点性能

swyx：投入的成本和收益怎么权衡，大家应该怎么想这件事，投机解码加量化，投机解码加量化，那大概占了95% 那能带来多大提升，对普通人来说做起来有多容易，比如现在我想把GLM5.2的权重，放到一台B200节点上跑，找到现成的投机解码器，或者已经量化好的模型有多容易

Philip Kiely：需要做多少工作，如果你要自己从头做，那工作量相当大，但放到今天来做，已经有人把成果发布出来了，你直接就能拿到NVFP4的权重，也能直接拿到投机解码器，对如果我们想想，我们叠加的那些翻倍提升，从BF16到NVFP4 其实不算正好二倍，对吧，我觉得从16位到8位，大概是30%到40%的提升，再从8位到4位，再乘一个30%到40% 所以加起来不完全是二倍，但差不多接近二倍，投机解码大概又是二倍，再加上分离式预填充和解码，如果你有足够的硬件，能跑足够的流量，又是差不多二倍 [00:39:14]

张量并行、专家并行与网络互联

又是差不多二倍

Philip Kiely：又是差不多二倍，然后再加上一个更好的运行时，带来的百分之十几的提升，就是背后有最新的内核之类的，大概就是这么叠加起来的，所以构建其中每一项，比如量化权重，对真正懂行的人来说，是几小时到几天的工作量，构建投机解码器，也是几小时到几天，分离式部署，也是几小时到几天，不过一旦你有了这些，就都好了，一旦你打好了，对，第一次把分离式部署跑通，当然是非常难的，但编辑上的实现成本就低多了，如果你只是拿现成的，比如你是个普通用户，手里有一台B200节点 [00:39:59]

swyx：想知道怎么自己托管，你不需要自己量化模型，总会有人发不开源的量化checkpoint 就算没人发，英伟达也会推一个出来，通常推理服务商，也会训练好他们自己的投机解码器，你不需要自己训练，直接用他们的就行，对比如KimiGal M5.2自带MTP 对，多token预测，对，如果我搞错了，你可以帮我纠正一下，对如果我们说错了，你确实该纠正，但他们的多token预测，可以用来做自投机解码，这个我其实不太确定，我对书里的说法有七八成把握，但可以让人去查一下，不过用它来讲清楚，这个故事很有用，不只是普通用户，比如一家公司，想从无服务器推理切换过来，想租一些GPU自己部署，这些就是你为了，比直接放在VR后面快得多，而要走的步骤，我一直在等有人提到Dynamo [00:40:42]

Philip Kiely：我觉得那才是你应该，拿来当基准去对比的东西，我觉得Dynamo 与其说是一个开箱即用的系统，不如说是一个，用来搭建的开发者工具包，所以当我们说做KV感知路由，做KV卸载，做预填充解码分离的时候 Dynamo本质上顺便说一句 Dynamo是英伟达的开源库，那部分我们和Kyle已经聊过了，好，那你的听众应该知道，它支持各种不同的推理框架，而且它其实是多硬件兼容的，这点挺有意思，但它只是个路由器，不是优化层，对，它做的就是Dynamo 擅长的是，它是一个在集群里，在硬件之间搬运信息的库，比如你的KV缓存在一个地方，需要挪到另一个地方 Dynamo会协调Nixo帮你搬过去，这不意味着你开箱即用，比如PIP install Dynamo 就能获得巨大的性能提升，它更像一个开发者工具包，对我会说它自带一组默认配置，你可以自己替换掉，确实如果整个行业都把这些部署方式，标准化的铺开，那它确实可以算一个可信的基准，但我们拿它跟实际环境里看到的情况做了对比 [00:42:30]

swyx：我确实想再多聊一点PD分离式，玉田冲和解码，因为那大概是排在量化和投机解码之后的第三大话题，不过在你的书里，我正想翻一下这本书，对，比如522节讲Medusa 523节讲Ego 对 524节讲 55节应该是讲，分离式玉田冲和解码，不我只是想多停留一下，聊聊其他的，比如你选择收录什么，选择不收录什么，因为我觉得还有好多其他技术，对，这些技术现在还相关吗，因为我觉得他们大概是一年半前出来的 Medusa挺老的了，对 Medusa是挺老的，但它收进书里，是因为它是个好的基线，就是你应该知道的东西

Philip Kiely：就像我读那篇论文的时候，我就想，这太有道理了，对，所以写这本书的时候，我有几个目标，一个是给人们提供理解，整个领域所需的基本词汇，另一个是，让他们对每种技术的工作原理，有一些直观理解，就像我在AI工程师演讲里提到的，那算是这本书的，第一个公开补充，投机解码这个领域的发展速度，比其他所有领域都快得多，所以对，即使在我写书的时候 Medusa我也更多是，把它当做帮助人们，理解这个领域，如何演进的工具，而不是最新的技术，现在当然有了 D-Flash D-Spark 还有比Ego更新的技术，不过Ego现在依然非常常用，投机套投机，对，投机解码，套投机解码，你能，这基本上是一篇 [00:43:42]

swyx：Tree Down的论文，它基本上就是在做，投机解码，对，投机解码做投机解码，这其实就是另一篇论文，对这是最重要的解释，而且看起来它确实拿到了不小的速度提升，但训练的复杂度也很高，至少在我们看来，这几乎跟训练生成对抗网络一样复杂，这是一个非常微妙的平衡，很多时候就差那么一点点，但没错，这本质上就是在投机解码之上，再做投机解码，确实如此，我们看到了这篇论文，挺有意思的，对吧，我甚至没想到它会这么难训练，对，我直觉上会觉得，好，那就训练一个投机解码器呗，而且这说得通，投机解码的整个思路就是，它有点像iPhone的自动联想输入，但用在普通模型上，对吧，你先生成三个token 然后说，好，对它们做预填充，这样，你就为原始模型，省下了那三次生成，现在你的投机解码器，在做三次自回归生成，那为什么不干脆，用一个更小的模型呢，我想问的另一个问题是，投机模型的大小是多少，比如说GLM的，对，大概10亿token 10亿参数，比如minimax的，对，对就一层，大概是原模型的六十分之一，对，其实我觉得，我们回办公室之后，应该写篇论文，投机套投机套投机解码，不，这确实看起来，怎么说呢，什么时候是个头，但另一方面，如果你能训练投机套投机解码，比如说，如果你能有一个小模型，能准确预测中间那个投机模型，会预测什么，而那个投机模型又能预测原始目标模型会预测什么，那为什么不直接用那个最小的模型呢，对吧，对这跟路由问题是相关的，对没错，对，投机模型的一个实际限制是，你必须在跑大模型的同一套硬件上跑一个小模型 [00:45:30]

Philip Kiely：这里面天然就存在编排和资源竞争的问题，这也是投机解码整体上的一个约束，草稿token的生成要消耗资源管理，他们还要增加软件复杂度，所以如果你搞无限地归的投机模型，你不仅在训练过程中，在推理引擎的实际实现里，也会增加相当多的复杂度，我正想说，我好奇能不能做类似的蒸馏和剪织 [00:46:22]

swyx：你知道这是同一回事，它就是个模型，我们能不能把很多权重蒸馏掉，把投机模型量化一下，不过这超出我的领域了，我想问的另一个问题是，这些都是针对大型服务器工作负载的，对吧，这些有多少能应用到，比如说我有一台MacBook 我想高效的跑Gemma是类似的问题，但不完全一样吧，差别挺大的

Philip Kiely：几周前我跟Salo在他的博客上聊过，数据中心和生产工作负载的推理工程，跟本地AI的推理工程，区别在于我们一开始的约束和目标就根本不同，本地AI的问题是，我怎么把这个模型塞进我的硬件，然后让它更聪明一点，而数据中心推理的问题是，我怎么加载这个模型，然后让它更快，显然我们也关心更聪明，他们也关心更快，但本地AI的推理工程生态，我觉得其实有很多，值得我们数据中心领域学习的地方，他们在各种量化技术上很擅长，包括动态量化这些，我们在剪纸，蒸馏，层移除这些方面，基本都不碰，层移除的影响没那么大，对，其实没人做剪纸，对，但他们确实在做，这挺让人意外的，对吧，但只是为了把东西塞进笔记本里，对，对，所以这是个挺有意思的领域，倒不是说他们的技术，对我们数据中心来说也适用，因为我们显然有不同的资源，和不同的目标，更多的是那个过程，以及那个领域的开放性，是值得佩服的，对就像你说的，某些优化 [00:48:09]

swyx：比如TurboQuant 你肯定听说过，它在X上引起了巨大的轰动，我们在Twitter上做了深入的探讨，它是什么，怎么工作的，为什么好或者不好，然后它就火了，被实现在本地设备上，因为你的内存带宽太慢了，比如在MacBook上，但试试把同样的东西，放到英伟达GPU的B200上 TurboQuant就不会被英伟达采用，英伟达明确表示，这不是一个好的优化，我们亲眼见过在Kernel内部做反量化，量化的开销 TurboQuant Kernel消耗的时间，实际上比它省下的时间要慢得多，因为在B200上，你有大约3.5TB每秒的带宽，你不需要那么大幅度的减少存储，你不需要做FP4KV缓存，你不需要用那些有更好的优化可以做，但在边缘设备上，这极其重要，极其有用，所以看起来是不同的优化方向，但它们又都独特的组合在一起，比如你想量化模型，你想做投机解码，比如某些公共潜队，原理，对完全正确，完全正确 [00:49:23]

Philip Kiely：他们还在模型并行上，做了很多工作，尤其是在eGoTop下，你有一些Spark机器，用以太网DGX Spark连在一起，对这就是Excel Labs 对你有一堆Mac mini堆叠在一起，有一件事我觉得，我们俩都得面对，虽然他们面对的更多，就是机器之间的互联，这就是为什么我们经常做张量并行，那是你用全部8块GPU 把模型切分到上面

Mega Kernels 与推理基础设施化

把模型切分到上面

Philip Kiely：把模型切分到上面，张量并行不太适合本地AI 因为它假设有非常高带宽的互联，比如Nemlink [00:49:59]

swyx：而它们可能被迫做流水线并行，我们除非做某种多节点推理，否则永远不会用，既然你提到了，我其实不确定我们会不会讲这个，但让我们简单解释一下，张量并行和专家并行 [00:50:08]

Philip Kiely：因为你有很多漂亮的图，对，就是想展示你的图，对，感谢Baseten设计团队的Luke 做了这些漂亮的图，在进入这个之前，还有一个区别是，我们经常谈论，混合专家模型的激活参数，对，本地推理的人来说，这很重要，因为如果你的P大小是1 你只激活那么多参数，当我们做，对，我本来想在扩散模型那部分，讲这个，对，对，当我们处理一个MOE模型，并把它托管成API时，我们假设所有参数都会被激活，因为你要取你的批次，你会碰到所有东西，好所以大体上，张量并行适用于任何模型，专家并行只适用于MOE模型，实际上今天所有模型都是MOE模型，至少所有大到值得跨多块 GPU并行化的模型都是，所以细微差别现在没那么重要了，专家并行的思路是把整个专家放在一块GPU上，通常专家数量比GPU多，所以你可能每块GPU放N个专家，比如每块GPU8个专家之类的，然后你在每块GPU上复制router router非常小，然后通过在专家之间移动生成过程，每个专家都在一块GPU内部，他们不竞争资源，你大幅提升了吞吐能力 GPU到GPU的连接就没那么重要了，因为通信量不大，张量并行要求你能做全收集，全规约这类操作，所以你基本上把模型完全切分到各GPU上，然后每一步你都要合并每块GPU的结果，这就是为什么互联很重要，当然这是一个非常粗略的概括，有很多地方并不准确，但一般来说张量并行对延迟有帮助，在很多情况下，你会在模型的不同部分组合，使用这两种并行 [00:52:09]

swyx：而不是只选一种，你想补充点什么吗，在一个模型里，它们不是互斥的，你会做张量并行，也会做专家并行，流水线并行用的比较少，在我看来，我们从来不用VPN 对

Philip Kiely：你唯一需要做流水线并行的情况，就是把不同层拆开，一半层放在一块硬件上，另一半放在另一块上，就是当你被迫做多节点推理的时候，因为模型太大，你不得不这样，比如说假设你因为某种原因，在H100上做部署，然后你要把一个万亿参数的模型放上去，你就必须用多个H100节点，因为节点之间的互联太慢了，唯一可行的并行方式就是流水线，但每个节点内部，你还会做专家并行和张亮并行

swyx：那H100的限制因素是HBM吗，对就是显存不够，多少，我们需要记住的关键数字是什么，比如B200是每张GPU180GB 然后一个节点8张卡，就是180乘以8 NVFP4的话，每个参数占半个字节，所以那是800GB H100上大概是140 [00:53:08]

Philip Kiely：是80 是80 对，对，我老了，干这行很久了，我还真记得H100的时代，对不是，所以有一件事 T4 我跟你说说

swyx：当年在T4上跑模型是什么感觉，有一件事让我挺惊讶的，就是没多少人用Jamba 不知道你们还记不记得 AI21的Jamba 他们会专门挑一块硬件，然后针对那块硬件设计架构维度，这样显然能把硬件跑满，这很合理，但好像现在这些模型都没人这么干，但训练那边不是这么做的吗，我不知道，什么抱歉，训练那边，你是说决定用哪块GPU 对，训练那边确实会训练，更像是一个数学问题，你可以跑一下计算，看看浮点运算量，然后最大化它，推理这边更像是自动调优，就是GPU内核自动调优，基本上就是你定义一下，比如我两块GPU 我可以做TP1 TP2 1P1 1P2 对吧，这样你就有大概2的平方种组合，然后你就拿同样的流量去试，用真实的生产流量，看看哪个配置给你最好的TPM TPS你就用那个，我不太喜欢的一点是，你没法推理出哪个配置性能最好，也不存在一个永远最优的固定配置，但看起来自动调优就是找到最优解的方式 GPU内核也是差不多的道理，你设计好内核，设计好配置，启动多少个线程，用多少共享内存，你就自动调优，在旁边扫一遍参数空间 [00:54:42]

Philip Kiely：经验上那个最好就用哪个，但这些东西是组合在一起的，不是分开独立的，训练里确实有一些是针对硬件优化的，比如你看英伟达的Nemotron模型，它们在Blackwell上跑得非常好，这并不意外，所以确实有一定程度的针对性，但我觉得大多数开源实验室的目标，是让模型能在尽可能多的硬件上跑，而不是只针对单一芯片，明白了，为了通用性，对 [00:55:06]

swyx：好趁这张图还在，我再问一个全收集，全硅，约很贵，硅谷现在有个趋势，叫Mega Kernels 就是把内核不断融合，我不太确定，真有这么简单吗，我是说融合内核救不了你，比如这里做张量并行，一半矩阵在GPU上，另一半在另一块GPU上，如果下一步要做非线性操作，我需要整个矩阵，比如做注意力的时候，我需要Softmax 需要做指数运算，我得有整行数据，所以我得知道GPU2的部分结果，和GPU1的部分结果，才能在下一阶段做Softmax 所以即使我有融合内核，因为每一步里面的非线性，我也必须让它们互相通信，另外关于Mega Kernels 说实话我挺不看好的，我只说请讲请讲，不是，就是Mega Kernels 它是个不错的研究方向，理论上看起来也很漂亮，比如你会想，启动一个内核有很多启动开销，对，那就一直融合呗，把所有东西都融合在一起，但是内核本身的复杂度很高，写一个高度优化的Mega Kernel非常难，真的非常非常难，而且不点名了，就算那些做融合Mega Kernel的公司，我跟他们的人聊过，他们很多时候最后也不会在生产环境里跑这些，因为那些模块化内核启动起来反而更快，你可以单独优化每个组件，还能让他们互相并行，还有Rubens 不知道你们昨天有没有看到Rubens的推特帖子，他们也在 Rubens 什么，不是不是，就是那个GPU Rubin才有专门的推特账号，不不不，我还想你在说什么呢，抱歉，英伟达的一位技术负责人发了条推特说，我们要揭开Rubin的面纱了，这是规格，第三条推文展示了，不往太技术里说了，我还得再仔细读读，但这个GPU的设计方式，基本上把我的内核给干掉了，你不再需要那么多我的内核了，所以看起来整个研究领域，可能就不会继续下去了 [00:57:21]

Philip Kiely：不过对，我能对Rubin瞎猜一下吗，请讲，你知道，我现在已经经历过了，顺便说一句，书里也写了他们，对，不过，对，书里写他们的意思是，我从那篇播客文章里知道 Reuben将来会推出，你甚至把那个名字都说出来了 Find Man 对，就像是在说，这个会是，这已经非常过时了，我是在努力让这东西面向未来，行了吧，我可不想明年之前再发心的，总之，我们刚才在聊我有多老，你看，我已经经历了三轮硬件发布周期，我经历过Ampere发布周期 Hopper发布周期，还有Blackwell发布周期，我说发布周期，不一定是指硬件真正出货，比如Ampere在我入行之前，就已经大规模部署了，但硬件从部署到能用于推理，中间隔了很长时间，所以你看最初的VLM和Sclang 尤其是VLM 那是针对Ampere写的，后来得为Hopper更新，再为Blackwell更新，每一轮周期节奏都更快，更紧迫，但也复杂的多，当我往前看看 Rubin会带来什么新东西时，我觉得Dynamo 给了我很多技术上的线索，告诉我哪类工作会非常有价值，显然我们还在延续 Blackwell的一些趋势，对吧 NVFP4很重要，他们为NVFP4张量，核心投入的算力非常庞大，我们后面应该会聊到视频，那是最大的瓶颈，内存带宽会快得多，这也是Blackwell之所以出色的原因，但最大的变化是更强调系统思维，更强调CPU到GPU的互联，更强调GPU之间的互联，你看Dynamo 它整个系统就是围绕一个问题设计的，怎么把KV缓存及时送到该去的地方，所以我觉得KV缓存卸载 KV感知路由，分离式架构这些主题，在Rubin时代会重要得多，这意味着推理工程，不只是CUDA内核的问题，也成了非常传统的，硬件基础设施问题，这是我们长期以来，一直在积累的方向，这让我很兴奋，因为我们会看到多个领域碰撞，从内核层面一路推理，到硬件层面再回来 [00:59:18]

swyx：这种能力会非常有价值，我想把Philip说的再往前推一步，我觉得趋势是它正在变成，纯粹的基础设施问题

硬件代际与视频扩散推理

纯粹的基础设施问题

swyx：纯粹的基础设施问题，像预填充，解码分离，训练，投机解码这些问题，但GPU内核不会是大问题，因为GPU正在越来越像ASIC 你只是在编排GPU上发生什么，而不是在逐线程控制它，你看QTile QDSL 你只是在数据Tile的层面工作，不在控制GPU上每个线程做什么，那部分已经替你处理好了，所以我想问，你同不同意GPU和未来的GPU 正越来越趋向于变成ASIC 只需要启动，然后他们自己完成数据运算，基于你和其他人的交流，哦我是说对，不那确实是市场的一部分，对，显然ASIC在他们自己的工作负载上，能带来高得多的性能，对，而GPU里的那个G 让他们继续保持很强的通用性，对，我觉得这里有个光谱，其实是Graphics 但没错，我老这么说，我得纠正自己，免得你揪着我G拼错了，对，这就像一条光谱，对吧，从非常通用的计算 [01:00:51]

Philip Kiely：一直到像TELUS那样，硬件是为特定一组模型权重打造的，权重直接烧进芯片，对，不用加载，我不会说我们正在完全走到那一步，更像是沿着光谱

swyx：朝硬件更专业化的方向迈了一步，对，我很好奇，我感觉它在往某个方向引，我想我的重点是，对烧权重进芯片之外的一切持悲观态度，把权重烧进芯片，实际上行不通，因为你想微调，想优化，想量化，想发布模型的新checkpoint 如果烧尽芯片，芯片一两个月就没用了，对吧，我想说的是，你怎么能看着英伟达越来越专业化，却不对那些做AI ASIC的公司保持乐观，你看英伟达把GPU从通用编程范式，就是一台你可以用来编程现成的通用计算机，每一代都在加入更多专用指令，专用张量核心，专用的UMA指令，这些让你几乎可以像控制ASIC一样控制它，像控制一组ASIC 你怎么能看着这个趋势，还对那些做AI ASIC的公司保持乐观，从某种意义上说，从某种意义上说，对因为他们确实在往那个方向演进，几乎就是在往那个方向演进，像Rubin跟Ampere或者T4比 Rubin基本上就是个ASIC 它基本上就是个被拿来用的东西，可编成ASIC 对有点像你当然可以编程，当然可以，我说它是ASIC可能有点争议，它确实是GPU 确实是通用的，确实有现成，我可以写CUDA去控制它，改变它的操作，但它有Solid阵列，张量核心 MMA张量内存，它有这些东西，几乎只对加载模型权重有用，它有张量核心指令，几乎完全是照着今天市场上，现有模型的头维度来设计的，你说你要搞个ASIC 要把什么东西时刻进去，那下一代架构一出来，它基本就废了，对我也不知道，真不知道，我觉得要记住的是，硬件周期有多长 [01:02:07]

Philip Kiely：所以如果今天有一块芯片出来，那意味着它的设计流程，是好几年前就启动了，英伟达在预测市场走向这件事上，做得非常好，而且你知道，他们掌握的信息肯定是最多的，那当然，但如果你去看，现在公开的开源模型架构，跟今天这些模型的早期版本差不多 Rubin其实是第一块，完全在那个世界里造出来的芯片，所以你能从它的设计方式里，看到很多对这块芯片，将要承担的工作负载形态的理解，对，好所以我不是回答那些问题的最佳人选

swyx：我觉得这些问题问得非常公允，而且显然是我听过的，关于Rubin的提问里，被阐述得最清楚的，第一个，但我确实要为垂直整合的模型实验室ASIC做个辩护，比如OpenAI和博通合作的随便叫什么Shalapino 当然那块芯片完全说得通，我们之前在播客里跟Martin Cassado聊过，他说你看如果你有1万亿美元或者5000亿美元的训练投入，那就拿其中500亿去做ASIC 没问题，你从ASIC上拿不到超过10%的效率提升，但这也说得通，对吧，所以针对特定模型的芯片可以，但AC公司有意思的是，我觉得你特别关注，超级关注你说的那些Tile之类的东西，他们其实在做更多表面工程，或者说实际的内存和硬件分配，还有芯片之间的通信，这些可能Rubin还不会触及，但具体细节我不清楚，明白，他们通常谈论的东西，我预期会有比Rubin 能通过编程实现的，更大的数量级提升，但谁知道呢，不，我明白，我明白，我明白，对，看起来，对，我是说，你想一想，实现十倍到一千倍，更快推理的真正障碍是什么，不是那些在现有GPU设计，内部就能重新安排的东西，芯片兼通信，对，这些人目标是每秒30万token 他们可不是闹着玩的 [01:04:30]

Philip Kiely：那可能得编成一些ASIC了，也许吧，我觉得有意思的是，你最近做了这么多内核工程的工作，却对其中大部分这么悲观，对，我做的越多，就越觉得它没那么大 [01:05:16]

swyx：我还想补充一点，模型一代一代再出，对吧，我觉得在你们那边，你们看到很多，今天GLM Kimi DeepSeek MiniMax 还有其他一堆，有些在做完全不同的东西，对吧 Gemma 没有编码器，最新的Thinking Machines 全是从头搞的，但你看另一边，我们在GPD5这一代上，待了多久了，对吧，对，他们那个模型，已经服务挺长时间了，当然，可能还有更多预训练，有不同版本的检查点，但说实话，你能榨出不少东西来，你花了几十亿美元做一次训练

Philip Kiely：如果能让它效率提升百分之几，它们就能服务很久 Cloud5系列不也一样吗，如果它们发布新模型，比如现在发布GPT-6什么的，而且每年都发一个新模型，我们虽然不知道，但假设它们改了一些架构，不只是做后训练，那你每年要花500亿美元，每一年都为一个新模型造一块新ASIC 然后把上一年的ASIC扔掉，对，轻松 [01:06:10]

swyx：所以我觉得，我稍微有点不同意，基于我那些二手信息，关于模型的寿命，现在还有人用4.0呢，对，对，对拉玛，不是拉玛2 是拉玛3 我还能看到拉玛3的工作负载

Philip Kiely：对，因为如果它够用，如果它被信任，就别动它，如果它好用，这正是开源的一个承诺，对吧，整个SAVE 4.0运动，你根本不需要搞什么 SAVE 拉玛3运动，你只要在某个地方

swyx：放一台8100就行，我觉得到某个时候还有个问题，如果一个模型能做足够多的事，能调用足够多的工具，有足够的agent能力，那它是不是就能自己网络搜索，工具搜索，写代码，你真的还需要继续压榨更多吗，我们会继续，因为你们会把它做得又便宜又快又小，我可以随时换进去，但在某种程度上，你今天给我5.2或者随便什么120B的模型，我能用挺长时间，对吧，这是假设你不需要更强的智能，我觉得有很多，你需要的是可靠性和可预测性，我在企业里，这东西是经过验证的，是我那5000个利益相关方签字批准的，我不会去碰它，他每天跑一个批处理任务，我喜欢这个结果，结果可预测，对一直用他们确实没道理，东西会变得更稀疏，更便宜更好，对，但这不意味着旧模型，比如GM5.0就不能用了，对吧，如果我们遇到瓶颈，不管什么原因，还是有很多可以炸出来的，我们快没时间了，我确实还想确认一下，对正好我们有这张图，拿它跟任何Cerebrus的图比一下，对吧，我觉得Baseten和MEDEX还没公开过图表，但完整的布局非常不一样，尺寸也非常不一样，这不是晶圆级的，对吧，这上面大概，我不知道一块晶圆上能有几百个这种，我不知道对比有多大，但确实这是一个非常不一样的物理空间分配，我猜几十个吧，几十个，在离开硬件这个话题之前，我有两个小问题，第一个最新的Kimi体量非常大，三万亿参数，对，单节点上大多数硬件都放不下，对，你需要GB300 你需要GB300或者AND [01:08:53]

Philip Kiely：这就是个简单的数学问题 NVFP四格式下 2.8万亿参数，就是1.4TB GB300每张卡有288GB显存，所以8张卡加起来，就够放这个模型了，而且说实话，做GPU显存计算的时候，你还得给KV缓存留出空间，这在一定程度上取决于上下纹长度，所以当一个模型参数规模很大，上下纹又很长的时候，你就是在跟空间较劲，这也是为什么KV缓存卸载在这些大模型上，会变成一个更受关注的话题，因为空间实在太紧张了，到了Rubin这一代 NVL72整机架有20TB显存了，对吧，对，不过Blackwell上也有NVL72 但你不能假设推理一定跑在那上面，世界上八卡机架的数量比NVL72多得多，对，我最后一个关于硬件的小问题是，你有没有注意到硬件代际 [01:09:49]

视频、音频模型的推理路径

你有没有注意到硬件代际

Philip Kiely：你有没有注意到硬件代际，对新的预训练基础模型有什么影响 [01:09:58]

swyx：你之前提到效率提升的一个手段是换硬件，那是二倍收益的来源之一，当我们看到Rubenson训练方面，有新东西出来日志上有什么变化吗，这会影响到这些硬件更普及之后 [01:10:03]

Philip Kiely：我们会看到什么样的模型吗，你能，模型会变得更大，人们会理解在最新的推理硬件上，你能跑多大参数量的模型是有天花板的，这个天花板就决定了模型规模，比如DeepSeek R1出来的时候，是6710亿参数，当时已经非常大了，我觉得它很大程度上，推动了我们快速采用Blackwell 并且把在Blackwell上，做推理服务这件事做好，所以对我来说，这主要就是模型规模的问题，然后是让架构和原生量化方式，去匹配目标硬件，就像我们聊到的，比如所有Nimotron模型

swyx：都用NVFP4 我们聊了很多大语言模型，对处理还有更多内容，音频视频，推理工程的另一面是什么，阿力你在视频扩散这块挺深入的，视频扩散模型，它们的形态跟大语言模型很不一样，很多你用来思考大语言模型的东西，比如自回归，在视频扩散里是不成立的，比如说你不做P处理，每个请求进来就在一张GPU上处理，一张GPU服务一个请求，你不需要做分片，模型也小得多，比如1.2.2就是个200亿参数的模型，你不需要担心那些，它比最好的大语言模型小了好几个数量级，而且这个领域里，开源模型和闭源模型的差距，跟大语言模型不一样，大语言模型这边 Kimi K3已经几乎能跟Methos 或者GPT 5.5比肩了，最好的开源大语言模型，和最好的闭源大语言模型之间，差距非常小，以前可能差6个月，我觉得现在连6个月都不到了，基本上已经没什么差距了，但视频模型绝对不是这样，差距巨大，如果你看看今天能用开源模型，比如One 2.2生成的最好视频，跟Clean或者Vio比，那真是天壤之别，这就造成了一个落差媒体，公司大多数时候会选择闭源模型，比如我告诉你，我能用这个模型帮你生成一部三小时的电影，而且我会优化到让你只付10美元，但如果他们用闭源模型做，得付1000美元，我便宜了100倍，但他们还是会选择用Vio和Clean来做所有剪辑，所以这就是一个先有鸡还是先有蛋的循环，需求少导致领域创新少，导致开源checkpoint发布的少，有些之前发布开源模型的实验室，最新的模型也避原了，比如1R2.7就不是开源的，我们还停留在2.2 视频模型尤其难的地方在于token的数量，视频模型，你想生成高质量的视频，假设你做到16帧每秒，这是绝对的上限，然后假设你做4K视频，你可以想想你的分辨率，我记得有个图能展示Token的惊人数量，比如就看一部电影，像斯巴达三百勇士那样的，假设我们只看四帧，这四帧如果你做全注意力，稍微往上算一下五秒钟的视频，就是4K乘以720再乘以81帧，因为16帧每秒乘以5秒，然后你把它压缩到前空间，但你仍然是在处理30乘以50乘以21的Token 对，也就是说光是五秒钟的注意力计算，就要跑在三万五千个Token上，对吧，所以注意力就成了一个巨大的瓶颈，而且因为它是欧文飞，如果你把它延长到10秒，那就是平方级的增长 20秒30秒都是这样，所以想生成一段一分钟的好过场动画，在同样的计算时间内几乎是不可能的，就是变得不可行，你根本做不到，于是你就只能往两个方向走，要么你决定一次性对整个视频做注意力，那你就被迫用系数注意力，如果你往回翻到那个视频图像的版本，你可以看到左边是，比如说我做的是全注意力，斯巴达300那个场景里的每一个token 都要跟其他每一个token做注意力，你能看到那一大片红色的区域，右边我只让每个token 只关注对它重要的top k 也就是前12.5% 可以是空间上的，比如说代表皇冠的token 会去关注头部脸部，然后是另一帧里的头部，前一帧里的头部，时间局部性，空间局部性，诸如此类，这样做的结果就是视频质量很差，这篇文章的核心就是想说明，你可以训练可以做所有这些事情，但质量上你还是会损失一点，所以最后你只能二选一，要么咬咬牙，用巨大的算力，对100万个token做全注意力，因为你想生成两分钟的视频，要么就转向自回归视频，在我看来自回归视频，就是未来压住的方向，但现在市面上还没有好的开源，自回归视频模型，如果你想得到一小时的电影，如果你想看到视频模型，生成好莱坞级别的电影，那它们就必须是自回归的，才能突破5秒的帧数限制，或者算力必须出现某种，疯狂的大跃进，让我们能高效的同时，对几百万个token做全注意力，就算是100万个token 那也是平方级的，你很快就会撞到天花板，我想问一下，你能讲讲自回归的优缺点和权衡吗，我想到的一个是针尖一致性，自回归扩散生成到10分钟的时候，你会忘记前面的内容，但它的优缺点到底是什么，就像自回归LM一样，你可以把很多我们之前讨论过的，针对LM的优化手段用上去，比如投机解码技术之类的，而且如果你有一个质量非常高的大规模模型，我完全可以把输出流式的展示给你，我可以先给你看第一帧，然后就像2023年的GPT那样，以前它是一下子把整段文本吐出来，但那时候你可以一边读一边看它生成，视频模型也是一样，你可以一边看一边等它生成，它逐帧的生成画面，所以猪token的生成方式，能让我们大幅扩展规模，把注意力机制用上去，缺点就是，每一个自回归视频模型都很烂，质量就是很差，如果你把任何一个开源模型，比如1.2 跟其他自回归模型比一下，你能看到 1.2生成的视频，就像猫和狗在打架，自回归模型给你的，就是劣化版的猫和老鼠画质，我也不知道怎么说，所以生成长视频的解决方案，就变成了，好，我们不用自回归模型，你看看GrokImagine或者GrokVideo做的一些事情，他们做得非常好，就是尝试把7秒的片段拼接起来，你先生成7秒，然后说好能不能把这段视频延长，他们就会把两段视频拼在一起，开源这边似乎没有他们那些技巧，而且从定义上讲，他们是避远的，我们不知道他们具体在做什么，你能做到的最接近的办法，就是取视频的最后一帧，把它喂给一个文本加图像生成视频的模型，它会接受文本提示，再接受最后一帧的图像，然后让它生成接下来的5秒，这大概就是你用这种模型，去生成一部电影的方式，你只是不断的逐帧流时生成，但你会遇到飘移，你从一张图像开始生成一段视频，然后下一段5秒的视频质量就更低一些，第三段就更低，第四段更低，有时候你会看到这样的情况，新生成的视频比第一段稍微暗一点点，然后下一段比第二段更暗，一直到25秒的时候，你得到的是黑屏，就是这样，我们本来想做一个演示来展示这个效果，但那个演示实在太尴尬了，我们最后决定不放了，但我觉得模型最终会走到那一步的，在我看来，他们只需要大幅扩展规模，并且转向自回归，但训练技术这方面，目前似乎还不清晰，对感兴趣Grok Imagine的朋友，我们之前跟那个团队的Ethan 做过一期播客，对，他透露了一点点线索，但不多，不足以让我们完整还原所有东西，具体到这部分，他稍微讲了一点，对我看到了，我们聊了记忆，更常上下文那些东西，但据我所知，它不是自回归的 [01:17:13]

Philip Kiely：虽然现在业内没人做自回归，对，看起来确实是这样，理解自回归模型和扩散模型的关键区别在于，扩散模型的注意力是双向的，而自回归模型只能沿着序列向前看，所以你会看到那种跑偏的行为，如果你只是天真的把视频生成模型，做成简单生成一帧帧线性序列，那你就没法回头去修改序列里的东西，来保证整体一致性，而视频模型之所以需要那么多潜空间，就像你说的，我们把所有token都放在内存里，在整个序列上反复迭代，你可以调整过去，好让未来说得通，所以如果我们要想达到那种，更长更丰富的序列，架构上很可能就像你说的，是自回归和扩散的混合

swyx：两者协同工作，各干各擅长的部分，但你凭直觉就能理解，为什么比如英语，或者说任何语言的写作，就是从左到右，你可以流式输出token 可以流式输出思维链，哪怕作为人类，你写作的时候也是先写，然后想下一步要生成什么，再写下去，边想边往前生成，当然你可以说，写作过程中，你需要回头改一些东西，但你需要这么做的频率，比你想象的要低，而视频就不一样了，它没有这种顺序性，视频左上角的像素和右下角的像素，它们几乎需要同等的互相注意，才能决定视频质量，而文本就不太需要这样，音频有没有类似的对照，我不太确定，但大约一年前有个说法，音频LOM有扩散和自回归两条路线，而且基于你提到的那些点，主要是在推理测，虽然音频片段更短 [01:18:44]

Philip Kiely：大多数音乐也就三到五分钟，我们基本上已经全面转向自回归了，对音乐我不太懂，但语音是自回归的，实际上这可以追溯到一年半前的Orpheus架构，你只要把一堆波形加进词汇表 LM就能输出代表这些波形的token 然后你就能构建语音，这就是流式输出的方式，就这么简单 [01:19:36]

训练与推理闭环、模型自我优化

就这么简单

Philip Kiely：就这么简单，哇这就是我2025年AIE演讲的内容，不错不错，但音频不是同样的挑战，对吧因为音频用LM生成一切就解决了 [01:19:59]

swyx：音频本质上还是一份可以用LM生成的文本稿，你的音频模型只需要做文本转语音就行，音乐方面曾经有一段时间在扩散和自回归之间做权衡，两者水平相当 [01:20:12]

Philip Kiely：可能各有各的优缺点，我就是想问问你有没有什么看法，对音乐具体的情况我不太了解，关于你说的编辑写作的时候，显然我的编辑会告诉我，其实需要更频繁的回头修改，我能想象音乐或者诗歌，比如你有押韵方案，你可能想回头改一处，好让后面想用的韵脚更容易安排，这种时候能双向注意确实有优势，但据我所知，我倾向于把这个推理问题分成两类，自回归模型有一套自己的约束和技术，扩散模型有另一套，我把文本语音输入输出归到自回归这一侧，图像和视频归到扩散那一侧，两者之间有重叠，不是完美的划分，但这是我大致用的分类方式，我得指出一点，这应该是确认过的吧 NanoBanana和GPT Image是自回归图像模型，这就是我们说的混合方法，但在图像领域，它还没延伸到视频领域，至少在开源社区里还没有，对但我猜那不会太远 [01:21:17]

swyx：如果这在图像上可行，至少Quinn Image那帮人正在尝试，对对我很期待Quinn Image 3 希望他们会开源，然后我还想提一下，在文本扩散这边也有一些动静

Philip Kiely：但不算多，对我们有Mercury 你们托管Mercury 对，不错，还有Gemma 对吧 Diffusion Gemma Diffusion Gemma是开源的，对

swyx：然后还有，我们在科学播客那边，也一直在发布一些虚拟细胞模型，用的也是扩散，对，他们确实做了，不过肯定还属于那种，廉价快速token的范畴，对，我们正在尝试，我觉得这是错误的营销方式，我之前就跟他们说过，我说你看，你不可能打败其他LM会做的那些优化，但你可以提供不同的API 比如你应该能把它用的跟聊天响应不一样，聊天响应，对，怎么说，因为它是扩散模型，因为你可以做那种无上下文，引导在扩散里是什么样，对文本来说

Philip Kiely：比如给我一首诗，给我一个情节结构，让它扩散成型，完全正确，所以这就是我提到的，比如诗歌，你可能想确保一致性，我写过很多LM14行诗，那曾经是我常用的基准测试之一，即使是现在的模型也一样，对，对他们就是数不对英杰，但如果你能关注到所有不同的token 你就能把英杰数对 [01:22:35]

swyx：对而且Mid Journey的David Holtz 当时也在投文本扩散，我觉得没出什么成果，但思路是，你可以先给一部电影做分镜，然后用正常的视频生成去生成场景，但那种跨内容的连贯性，就是结尾应该呼应开头，不应该有这种自回归的路径依赖，这个想法原则上是有道理的，只是API应该不一样，营销也应该不一样，现在使用最广泛的开源或闭源模型，没有一个用扩散，但这难道不恰恰说明，这就是先有机还是先有弹的问题，因为如果你给它更多规模呢 [01:23:00]

Philip Kiely：最大的扩散语言模型是哪个，我觉得它不算大，我不知道这个的参数数量，但是，大概不到200亿 Diffusion Gemma Boswent 我觉得是200多亿

swyx：对而且其实你还没真正试过，你没给它一个大的，而且你也没，所以这么说很不公平 Diffusion Gemma是250亿，而且这正是我想说的，就它的规模来说，它在质量上表现相当不错，这几乎和视频模型面临的挑战一样，要拥有同样的规模，就像你在拿它和规模大得多的模型比较，对除非你采用那种做法，你有一个文本主干，然后你知道，你给它拼上一个，某种解码器之类的东西，来做那个，他在这期播客，开头讲的就是这个，不过是反方向，从图像到文本，对，而且我觉得，大致上可以直观的推断，反方向也能做，我同意，我明白，我明白，我明白，对，我们这是在泛泛的推测，研究趋势，对，最后我们可以聊一个话题，就是你演讲的主题，拿一个开源模型，让GPU跑起来，然后就这样，这就是Baseten的工作，现在看起来，人们越来越多的，在后训练阶段使用推理，是的，训练和推理，对，训练服务于推理，推理服务于训练，这两块现在都成了大话题，推理服务于训练，意思就是说，显然你在做强化学习训练的时候，需要做rollout 所以如果你的rollout 花的时间太长，比如你用的是VLM 而不是LLM 或者你想训练的模型，在LLM里不支持，只能退回老的推理引擎，那rollout就会很慢，你又不希望拿太偏离策略的rollout 去做训练，所以只能等他们，这样一来，整个训练管线就被卡住了，所以我们做推理优化用的那些技术，在这里也能帮上忙，而训练服务于推理，主要就落在投机解码训练 Ego head训练，有时候还有后训练上，比如说，你想量化一个模型，把它压到NVFP4 有时候运气好，直接做PTQ就行，有时候压到NVFP4之后，模型表现很糟，质量太差，那就得对模型做后训练，让他明白自己现在跑在NVFP4上，还能输出同样的logits 这个可以用普通的SFT 量化感知训练这些方法来做，但我们现在越来越多看到，像英伟达发的量化，或蒸馏论文那样的做法，你建立一个NVFP4版本的模型，再建立一个全精度版本的模型，然后基于两个模型的logits 做蒸馏训练，让NVFP4的模型学会，所以现在我们团队里，做推理的工程师，越来越多的熟悉训练技术，会写训练管线，感觉这两块在某种意义上正在融合，是在走向合一，对绝对，你想最终目标可能是搞一个 [01:25:40]

Philip Kiely：持续改进的系统，对说起来有点好笑，但它确实在发生，我觉得几个月到一两年之内，很多头部agent的开发者都会把这些循环，真正跑进生产环境，做推理从推理里学习，我们当然很久以来就在做这种事了，在推理实时进行式学习动态调整系统，任何动态调整都会胜过静态配置，不管是你的具体配置，你的投机解码器还是那类东西，然后你可以拿产品里产生的trace 持续后训练模型发布出去，做AVB测试，拿到更好的信号，得到更好的模型，做出更好的产品，这个循环真的很有前景，支撑它的技术和基础设施，也在快速成熟，所以训练和推理的融合，我觉得只会越来越快，我刚才其实在笑，但并不是觉得好笑，而是觉得这事是真的 [01:26:28]

swyx：AAI世界博览会的一个大主题，就是我们有RSI通向通用人工智能 差不多是那个口号，对我是说我们确实有，我看到你提到参数高尔夫，我们有模型在训练模型，下一步显然就是模型训练，优化自己的推理，这有点好笑，我在想模型会不会在训练自己这件事上，比训练他们不熟悉的模型，更在策略上更擅长 [01:27:22]

Philip Kiely：这些都是很有意思的开放研究领域，我几年前工作的一大部分，就是给Hugging Face上冒出来的任意模型写配置，把它跑起来，现在这种跑起来的配置已经可以一次搞定了，所以我已经不用再做这个了，对不过那倒不完全是模型优化自己的推理，更像是模型能读懂SGLine的文档，但对差不多，我们确实看到了，比如GLM5.2 GLM5.2鞋

swyx：GPU内核非常非常强，所以很有意思的是，我们内部有一个GLM5.2的端点，接近了我们的Claude Code框架里，团队里每个工程师，都在用我们的GLM5.2 它会在节点上对GLM5.2实力，做一次前向传播，然后拿到性能分析trace 分析它，找出SGLang里的瓶颈内核，然后写出新的内核，我们再跑一次性能分析trace 等它跑完了，它会把镜像上传到我们的系统里，我们拉下来重复这个循环，所以有相当一段时间，我们真的是GLM5.2 在写很厉害的东西，在GLM5.2上，我们推理引擎里跑在 GLM5.2上的一些GPU内核，就是GLM5.2自己写的，整个trace和内核，都是由GLM5.2作为驱动来引导的，所以我觉得，我确实看到这个循环已经存在了，我觉得还需要更多时间，它肯定还有很多做不了的事，模型还没到那一步，哪怕他们已经非常非常聪明，他们还是会试图用暴力尝试的方式，去找最省事的路径，或者说他们几乎不太擅长做决策，但对，我确实觉得模型优化自己的推理，已经是正在发生的事了，你觉得GLM5.2是在自我优化方面特别强 [01:29:06]

Philip Kiely：还是它恰好是我们能拿到的，最好的编程模型，如果让他去优化DeepSeek 或者Kimi之类的，他也能做的一样，好吗，说到Circus的观点，如果他去优化另一个模型

swyx：可能就会有点偏离策略了，真的会伤害DeepSeek吗，我是说让他去优化他自己，不，为什么，我不这么认为，对，但就是咱们直接试试就知道了，有意思，对，就是你算力比我多

网络、KV 缓存与持续学习

就是你算力比我多

swyx：就是你算力比我多，直接去跑一下试试，对，推理工程方面，还有哪些我们没聊到的新趋势，因为你们离得最近，肯定能看到一些外界还不知道的东西，大的趋势很明显 [01:29:58]

Philip Kiely：模型越来越大，硬件越来越强，用户习惯了某个速度之后，就会要求更快，我觉得让我兴奋的是系统层面的东西，我们还有很多关于，如何把多个模型组合在一起的问题要想，比如一个语音agent 里面涉及三到五个模型，还有这些模型之间的通信，还有很多新的模态要出来，比如cosmos 那个新的世界模型，还有更多研究，语音到语音还没有完全成熟，但越来越接近了，会有很多新的模态可以围绕去构建，这会很令人兴奋，然后对，我觉得另一个要解决的问题，也是我们解决很久了，但还没做完的，就是整个行业要继续以，十倍再十倍再十倍的规模去运转，想想AI在全球的使用程度，跟一些更成熟的技术比，无论是消费端还是企业端，很明显需求还能再涨好几个十倍，看看全行业的基础设施工作，显然是为了应对前所未有的需求激增，而非常迅速的搭建起来的，而且这还不会停，所以对还有很多问题要解决，比如高可靠性，还有搞清楚下一个十倍一百倍的token从哪里来 [01:31:04]

swyx：我要说一个可能很无聊的答案，但我觉得答案就是更快的网络芯片通信，在我看来内存越来越成为瓶颈，你想要更大的模型，现在做大规模推理服务的时候，你得把KV缓存从一个节点传到另一个节点，但做法是你找到KV缓存，找到它在哪，然后传到另一个节点，放到那个节点的内存里，再从那个节点的内存传到GPU里，传到GPU的张量核心上，所以这里有个两阶段的传输，导致你在大规模KV缓存传输上非常受限，这会影响解码和预填充的时间，你不得不这么做，因为HBM非常快，大概4.5泰比特每秒，比网卡通信速度快了好几个数量级，如果你能在理论上，这个理想状态下拥有极快的网络，理论上你就可以省掉HBM这一步，直接把KV缓存从一个节点传到另一个节点，这会在节点间的聚合推力服务上，带来接近100倍的速度提升，我不太了解让网卡变快的技术难点，我确信有原因让他们比HBM慢了好几个数量级，但如果有人能解决这个问题，解码速度真的会快两个数量级，这就是我的看法，大芯片，酷，我不知道你有没有要提名的东西，趋势方面，我来说一个，好，我觉得是面向持续学习的推理工程，比如，如果你抱着一个想法，说你应该从你处理过的所有东西里学习，你会不会做不一样的事，还是沿用同样的方式，就是把它塞进memory.md 然后他不知怎么就被KV缓存消费了，这个系统能用，没坏，还是说你怎么重塑推理，让他在推理的同时学习，对，我觉得这方面一个相关的话题是 [01:32:21]

Philip Kiely：你在这个世界上能找到的最好的基金，做的是KV压缩的工作，没错，那什么会改变，什么会改变，如果你想持续学习的话，有两种观点 [01:33:08]

swyx：我和查理之前在推特上争论过，持续学习可能走两条路，一条是模型自己学习，不断把新知识写进权重里，这种情况下推理时，就得不断去取最新的权重，对，就是字面意义上不断去读写权重，另一条路是做KV缓存压缩，如果只更新LORA的话，那还有个LORA层，对没错，这就是我们之前聊过的 Ingram方法，反对把知识写进权重的理由是，你只能修正一跳知识，就是说你只能为给他一个新事实，比如世界上最好的大学是哪所，世界上最好的大学是华铁卢，但第二层推倒就不行了，那是不会变的，不会变，但第二层推倒的问题，比如我应该从哪所大学招实习生，如果你知道世界上最好的大学是华铁卢，那答案就应该是华铁卢，但如果我不是一次性问这个问题，而是让他用已有知识去思考，再给我第二个答案，或者问，我应该从滑铁卢还是MIT招实习生，他可能会说，哦都挺好的，但不对，我明明刚在你的知识库里编辑了滑铁卢是最好的，你为什么不用这个去做推理，所以这就试图在MLP里改一个事实的根本问题 KV缓存压缩能解决这个问题，有了KV缓存或者说，不一定是KV缓存压缩，而是如果你能做到像我们提出的Steel论文那样，让你的KV几乎无限，并且能用一种不丢失任何知识的方式去压缩，那样的话你就能真正做持续学习，真正解决持续学习的问题，这就是我和查理争论的结论，但我承认他的观点是对的，我也确实认为KV缓存是未来的方向，那样的话我觉得推理本身不会有太大变化，因为推理时我们本来就在用KV缓存，你只是去更新KV缓存，但那是额外的一步，权重没有任何变化，所以推理时间没有变化，我之前说的那些也没有变化，好出乎意料，答得非常好，我们把它发在播客上了，是最近的一篇，大家可以去看看，对，除此之外，这次聊天非常愉快，我知道我们已经聊了两个小时了，哇，时间过得真快，还有好多没聊到，对，我们本来还想聊聊那本书什么的，不过书你已经聊过了，对，那本书大家都知道，对，贝森历史上投资回报率最高的事，对吧，就这一个小时来说，毫无疑问，毫无疑问，绝对的，那恭喜你们，我们之前在自己的聚会上，也聊过这个，可以单独发出来，不过还是要感谢，你们这么慷慨的分享，我觉得这是段，很难得的有趣对话推理工程这块，我们之前真的没怎么深入聊过，所以你们能来，真的很荣幸，太棒了，对谢谢，谢谢你们邀请我们，希望一年后一切都变了，我们能回来聊聊，我们当初哪里说错了，对，我很期待这个Mega Kernels的说法传出去之后，看看大家怎么说 [01:36:02]

Philip Kiely：我们得开始了，我要不要躲起来，我知道Mega Kernels社区肯定要来找我麻烦，对有一点我特别佩服你，就是你从来不怕捅马蜂窝，其实还好，我觉得没那么有争议，我也不知道，走着瞧吧

swyx：走着瞧，好谢谢各位，不太感谢你们了