大模型与推理基础设施协同设计深度解析
以下是 1:52:00 之后，游凯超在访谈中就"模型与 Infra Co-design"话题的系统性梳理，按照你提出的五个维度组织：
一、模型与电力的比喻（相似与差异）
🏭 核心比喻框架（01:53:23）
游凯超用"发电系统"构建了三层类比：
硬件 = 自然资源（不同地方的风力、水力、光伏太阳能）
模型 = 发电机（大风车式的风力发电机、光伏发电机、机械式水力发电机）
推理引擎 = 电力系统（把模型跑在硬件上，把 token 分发到千家万户）
"这里面的 co-design 程度，其实就决定了它的发电效率。有的地方水流比较湍急，有的地方水流比较平缓，那你在这两个地方怎么样去设计你的发动机，使得你的发动机能够更好地利用这部分能量——这个就是所谓的模型和 Infra 的 co-design。"
⚡ Token 与电的核心差异（02:17:43）
"大家把 token 和电做一个类比的时候，可能会觉得电它是比较通用的，电它是可以调制的。但是 token 它是没有办法去做调制的——你没有办法说把一个 DeepSeek 模型的 token 转化为一个 Kimi 的 token，这个 token 它是带着模型的烙印的。"
这就好比：
电：统一 220 伏，所有家电按国家标准接入即可
Token：上百种发电机型号，每种发出来的电压和频率都不一样，且无法调制，只能原样送过去
"token 它比电复杂很多，它有一个异质性在这里，就是它不是像电一样的是一个 commodity，就是你拿到就可以用的状态。"
🔄 另一个关键差异（02:41:35）
"如果有一个核电厂的技术，你把核电厂发出来的电供给给一个城市用，这个城市用这个电用一辈子，他也不会研究出核电的技术。但是大模型是不一样的，每一个 token 都是带着模型的烙印的……一旦你给人用了很长一段时间之后，其实用户他自己的数据已经可以训练出一个模型了。所以模型它就不是一个能够长期的对用户进行隐藏的东西。"
这直接导出游凯超的核心 bet：开源模型最终会赢。 闭源模型无法像核电技术那样被长期保密，因为用户使用过程本身就是数据收集过程。
二、模型与推理 Infra Co-design
🎟️ 理论基础：Hardware Lottery（硬件彩票）（01:54:57）
"摩尔定律的那个黄金时代已经结束了，你没有办法再通过制程得到通用性能的提升。现在已经进入了一个专用时代……如果你的算法没有利用到这些专用的算力，你就没有抽中硬件的那个彩票，你就吃不到这个时代的红利。模型的结构决定了推理效率的一个上界。如果你的这个上界太低了，那系统工程师就无力回天了。"
Hinton 的 Capsule Network 就是反面教材——概念上 make sense，但在 GPU 上不友好，至今未获广泛应用。Transformer 则是正面典型——大量矩阵乘法完美适配 GPU 并行特性。
🏆 Co-design 的经典案例：RoPE（01:57:35）
"RoPE 流行起来的一个很重要的原因就是——随着训练长度的提升，大家需要位置编码，同时 FlashAttention 解决了训练长度的问题，所以 FlashAttention 就变成了一个训练必须的东西。在这个时候，大部分用户没有能力去修改 FlashAttention，所以大部分需要修改 Attention 内部实现的位置编码就被干掉了。而 RoPE 的好处在于，它是可以独立注入到 query 和 key 里面，是在 attention kernel 之外独立做的。所以它跟 attention kernel 是互补的，变成了一个最佳搭档。"
这是一个算法设计主动适配 Infra 约束的经典案例。
🔬 DeepSeek 的 Co-design 实践（01:59:34 — 02:00:46）
"DeepSeek 的 Infra 团队我觉得可以说是全球顶级的团队。Infra 的能力强，就能够高效实现的模型结构就更多，所以算法研究员就可以更快更充分地去探索各种选项。这里面还有一个就是，他们的算法同学其实也都是懂一部分 Infra 的。比如在 24 年年初探索 MoE 的时候，其实是 DeepSeek 的一个算法同学写出了 MoE 的比较高效的实现。"
"我觉得 DeepSeek 的这个深厚的 Infra 功底，可能是来自于他们之前做幻方量化的时候，对性能的一些极致的压榨。他们因为做量化，然后要自建机房，所以他们对机器的每一个细节都会深度控制，能够做全站的优化。"（02:11:35）
⚠️ 各干各的模式为什么没有前途（02:07:45）
回到发电类比来深化论证：
两年前：训练为主，推理开销不大，算力多于需求 → 对效率追求不极致
现在：训练和推理开销达到 1:1，推理持续增长，算力供不应求 + 高度特化
"同样是电磁发电，同样是水电，如果你的发电机直径是 10 米，你的效率可以是 80%；但如果你的发电机直径是 100 米，那你的效率只有 10%。翻译到大模型设计上就是，Infra 和算法必须是紧密结合，必须是 co-design 的。"
"这个模型团队和 Infra 团队，如果各干各的话，我觉得这个团队就完全没有前途。比如说，如果某有一个算法团队某一天异想天开说我的 attention 的 head size 能不能开到 1024——那 Infra 团队可能就晕过去了，因为这个东西在硬件上很难实现。"（02:10:52）
🧠 如何实现 Co-design：两栖人才与组织机制（02:13:14 — 02:15:10）
"算法的同学，他可能更多会想我这个东西在理论上是否 make sense，更关注下游的指标。Infra 的同学，他可能更关注的是我手头上拿到的硬件长什么样子，我能做些什么事情极致发挥各种性能。他们的出发点不太一样，养成这样的思维都需要经年累月的熏陶。"
现实可行的路径：
"当下能做的，可能是让两边团队坐在一起工作。坐在一起工作，比如说一起吃饭嘛，互相聊一聊对方关心什么话题，互相理解一下。我自己刚好是在算法那边熏陶了几年，然后在 Infra 这边也熏陶了几年。"
"可学习的那就是——算法团队要懂 Infra。"
三、与 Harness Co-design（02:26:00 — 02:28:43）
问题根源
"目前主要的一个问题是生态比较碎片化。不同的 harness 框架会带来不一样的负载特性，以及不同的模型结构又带来了不一样的推理优化需求，所以很难统一。我们现在需要的是一个 harness 和 infra 的 co-design。"
季逸超（Peak）写过博客讨论如何设计 infra 友好的 harness 框架，最核心的原则：充分利用前缀缓存（prefix cache）。
三个典型反例
反例一：自作聪明的工具调用精细化
"有些 harness 框架设计者比较自作聪明，觉得每次把工具调用的范围进行精细化可以提高模型效率。但其实工具调用总是出现在模型请求的前端，这种操作会导致每一次请求都无法重复利用前面计算的结果，对推理系统带来巨大负载。"
反例二：ChatGPT 的日期嵌入
"ChatGPT 之前在 System Prompts 里面会加入当前的日期，所以前缀缓存会在日期切换的时候统一失效。更优雅的做法是，把日期当做一个工具提供给模型，模型如果觉得这一次需要当前日期，它可以再去查询。"
反例三：精确到秒的时间戳 + 整点定时任务
"最极端的例子就是有一些 harness 框架把当前的时间嵌入到请求里面，而且精确到了秒，以及它的定时任务总是设置到整点。这就导致一到整点，推理系统就会收到一大波巨大的流量。Moonshot的同学对于这个有一个非常形象的说法就是——一群小龙虾一到整点就集体出动攻打月球。"
DeepSeek 的信号
"DeepSeek 最近完成了一轮大额的融资，它招聘的首位就是 Agent 的框架设计相关的岗位。他们在模型和 Infra 的 co-design 方面可以说是一骑绝尘，我也相信他们的 Harness 框架也能够达到和 Infra co-design 的一个高度，然后再给社区上一课。"
四、Infra 与芯片 Co-design（02:28:54 — 02:32:20）
宏观趋势
"目前的整体趋势确实就是模型的结构和芯片的架构越来越耦合了。而且主要是模型往芯片这边靠，因为芯片已经设计成那个样子了。如果你没有往芯片那边靠，你的效率就会极大的降低。"
David Patterson 图灵奖演讲的两个核心判断
摩尔定律无法延续：通用算力不再增长，唯一出路是设计领域特定芯片
矩阵乘法简单但极其有效：英伟达 20 多年的发展史证明，只要把矩阵乘法算得快，很多问题就能解决
"现在高性能的计算芯片基本上都特化成了矩阵乘法的计算单元。所以模型结构的设计也必须要尽可能往矩阵乘法这方面去靠近。"
具体案例：FP8 量化格式与 DeepSeek（02:30:47 — 02:32:12）
从 A100 到 H100（Ampere → Hopper 架构），FP8 算力比 FP16 快两倍——但用上这个加倍的算力并不容易：
全局量化成 FP8 容易损失精度
DeepSeek 是第一个大规模跑通 FP8 训练的团队
核心方法：分块量化（block quantization）+ 矩阵乘法后用向量单元做累加
"利用芯片上两部分计算单元可以同时执行的特点，做到了精度不损失情况下的计算效率的领先，所以就领先了其他竞争对手一个身位。其实这些故事都写在 DeepSeek 的技术报告里面，只是看的人多少的问题。"
五、系统与模型共同进化的具体例子
1. DeepSpark：投机解码的极致压榨（02:02:46 — 02:06:12）
自回归解码只能逐个 token 生成，投机解码的思想是一次性猜测多个 token。DeepSpark 走的是 DFlash 路线（一次猜 16 个 token），核心改进是：
"估计一下这些猜的 token 里面哪些是准确的，哪些是不准确的。大概率不准确的 token 你就不要再去验证了。"
"创新性是一回事，能不能把这个创新的想法扎实地做出来，这又是另一回事。DeepSpark 是继承了 DeepSeek 一如既往的非常扎实的 Infra 基础，把推理优化压榨到了极致。这也是一个很好的 co-design 的案例——有没有一个好的推理引擎上的实现，是决定一个投机解码算法能不能大规模使用的关键。"
2. FlashAttention：系统层面"杀死了"上百篇算法论文（02:50:51 — 02:51:24）
"当 attention 要做长上下文的扩展的时候，我们看到了有非常非常多的算法在尝试做各种近似……但是这些问题最终都是被 FlashAttention 解决了——它告诉你说一个精确的 Softmax Attention 的算法可以被高效地实现。那么之前那些研究高效 Softmax Attention 的论文就都没有用了。"
3. AutoRegressive Decoding 的逆袭（02:51:25 — 02:52:09）
"AutoRegressive 的 Decoding 一开始提出来的时候，大家说它是非常慢的，因为你只能一个一个 token 地去计算，这个效率非常低，所以它肯定没有用。但是经过这几年的发展，continuous batching 结合上 Page Attention 的技术，就把这个成本降下来了。同时还有 spec decoding，从一个个 token 的 decoding 变成一小段一小段 token 的 verification。"
4. Linear Attention 与 Chunk Parallel（02:52:10 — 02:52:36）
"Linear attention 也是有很多人在研究什么样的 linear attention 是好的。关键就是松琳他们提出来的 chunk parallel 算法——你如何分段地计算，在分段的过程中能够有一些高效的计算方法。"
总结性判断（02:52:43 — 02:53:00）
"这一系列其实都是在系统层面如何更好地支持算法。同时也就意味着有一个系统彩票的问题——你的这个算法能不能被系统高效地实现，只有被高效实现的这个算法最终才能够留下来。所以说系统是非常重要的。"
"这是一个变化非常快的时代，你需要跟硬件 co-design，你需要跟系统 co-design，你需要跟 harness co-design。co-design 能够给你的发展带来更大的空间。"
一个 Hot Take（02:36:17 — 02:37:05）
游凯超对未来的一个核心 bet：
"模型对于上下文的需求，基本上应该停留在百万上下文的级别。个别领域如生物化学可能会需要千万甚至亿级别。但是与人打交道的模型，它的上下文应该不需要再大幅增加了。长程任务的需求，都可以通过外部工具来实现——记忆模块、技能模块、subagent 模块。如果这个预测成立的话，当前的模型结构设计和 Infra 还可以在现在的范式下延续很长一段时间。"