博客 / Infra / 技术参考报告

大模型推理加速的新路径：Megakernels、超级算子与 AI 驱动的算子优化

Preman · 2026年10月10日
研究领域：AI Inference Infrastructure / AI Systems / Compiler Optimization / Agentic Software Engineering

摘要

2026年9月，Inferact 与浪潮信息分别公布了针对 Kimi K3 大模型的推理优化成果。两者采用不同的计算硬件与系统架构，但体现出一个共同的技术方向：突破传统算子边界，通过跨算子融合、内存调度和计算通信协同，提高现有 AI 硬件的有效利用率。

Inferact 在16颗 Google TPU v7 芯片上，通过 Megakernel 技术将 Kimi K3 的92个 MoE 层融合到单个 Pallas 内核调用中，配合投机解码，实现了709 tokens/s 的单用户生成速度。

浪潮信息则通过128颗本土 AI 芯片组成的超节点，将 KDA、Gated MLA、MoE 等模块中的基础算子融合为超级算子，并引入 Kimi K3 智能体参与算子的自动生成和性能优化，实现了5.85毫秒的 Token 生成时延。

这些成果具有两方面的重要意义：

第一，AI 推理性能不仅取决于硬件的峰值计算能力，也取决于软件如何组织计算、存储与通信。

第二，AI 推理优化正在成为 AI 自身可以参与甚至部分自动完成的软件工程活动。

从研究角度看，后一项尤其值得关注。它可能形成一个新的技术体系：以模型生成候选优化方案，以编译器执行，以正确性测试约束，以硬件性能测量提供反馈，最终通过智能体持续改进 AI 推理软件。

本报告基于 Inferact 原始技术博客、开源实现、Kimi K3 模型资料，以及浪潮信息的技术发布材料展开分析。需要强调的是，相关性能数字目前主要来自发布方，不能直接视为独立第三方测试结论。Inferact

一、事件背景与事实核查

1.1 Kimi K3 为什么适合成为测试对象？

Kimi K3 是月之暗面于2026年7月发布的大规模混合专家模型，其主要技术参数如下。

以上参数来自月之暗面的官方模型资料。GitHub

这里有一个重要区别：Kimi K3 虽然拥有2.8万亿参数，但每次生成 Token 并不会使用全部参数。

MoE 通过稀疏专家路由，使参与实际计算的参数规模远小于总参数规模。

然而，即便采用稀疏激活，Kimi K3 仍面临巨大的权重存储、跨芯片通信和运行时调度问题。

因此，它适合用于考察超大模型推理系统的整体效率。

1.2 两家企业公布了什么成果？

数据依据双方2026年9月发布的材料。Inferact

特别注意：709 tokens/s 与171 tokens/s 不能直接比较。

原因有三：

首先，Inferact 的709 tokens/s使用了 DSpark 投机解码，而浪潮信息没有完整公开对应测试配置。

其次，两个系统的硬件数量、体系结构和并行方式不同。

最后，Inferact 的数据包含与 vLLM 基线的比较，而浪潮信息的结果主要属于自身系统性能发布。

所以，这两个案例证明的是两条推理优化路线均取得了值得研究的进展，而不是任何一方在同等条件下性能更高。

二、Megakernel：从算子优化转向整个推理过程的优化

2.1 为什么传统算子会成为性能瓶颈？

大模型的推理通常由大量独立的 Kernel（计算内核）组成。

例如，一个 Transformer 层可能涉及：

矩阵乘法、归一化、注意力计算、激活函数、专家路由、专家计算以及跨设备通信。

传统实现将这些操作分解为若干 Kernel，由运行时系统负责调度。

这种模式具有良好的模块化和可维护性，但也带来三个问题。

第一，Kernel 启动存在开销。

每个 Kernel 都需要执行相应的调度与启动过程。单次开销可能很小，但当一次推理需要执行数千个 Kernel 时，累计成本就可能变得显著。

第二，中间结果可能反复访问 HBM。

一个 Kernel 产生的中间结果可能先写回显存，再由下一个 Kernel 读入。

对于访存密集型工作负载，数据搬运的成本可能超过计算本身。

第三，Kernel 边界限制了跨阶段流水线调度。

这是 Inferact 工作中最值得注意的部分。

在传统执行方式中，下一个 Kernel 的数据搬运和当前 Kernel 的计算未必能够充分重叠。

即使使用 CUDA Graphs、异步执行和 Programmatic Dependent Launch，也需要处理 Kernel 之间的执行依赖。

Inferact 的思路是：既然跨 Kernel 调度有成本，就把多个层的计算放入同一个长时间运行的 Kernel，让程序拥有更大的调度范围。

这与传统 Kernel Fusion 相比，区别主要在于融合范围及跨层调度能力。

2.2 Megakernel 的关键不只是减少 Kernel 数量

Inferact 使用 JAX 生态中的 Pallas 编写 TPU Kernel。

在 Kimi K3 实现中，92个 MoE 层的核心解码计算被组织在单个 Pallas 调用中。

程序能够根据层索引选择相应的注意力计算，并在层与层之间安排权重预取和通信。

例如：

当第 N 层正在执行 MoE 计算时，系统便可以提前启动第 N+1 层注意力投影权重的加载。

这样，第 N+1 层开始计算时，所需数据可能已经进入芯片内部高速存储。

其核心技术包括：

真正具有研究价值的是：Megakernel 不只是将多个算子合并，而是将原本分散在多个 Kernel 中的资源调度问题，转变为一个具有全局可见性的程序优化问题。

这使开发者能够直接控制数据何时进入高速存储、何时被使用，以及何时释放相应空间。

Inferact 的实现采用16颗 TPU v7 芯片，对应32个 TensorCore，并结合张量并行与专家并行组织计算。其开源代码已经包含解码 Kernel、投机解码、模型加载、测试和服务接口。Inferact

2.3 TPU 为什么适合这样的编程方式？

博文有一句话值得修正：

“硬件没占到便宜，赢在了写法上。”

这并不完全准确。

Inferact 公布的芯片参数如下：

从峰值算力和 HBM 带宽看，GB200 略有优势。

但是，TPU v7 具有另一个重要特征：

每个 TensorCore 拥有64 MiB 的片上 VMEM，开发者可以显式管理其中的数据。

相比之下，GPU 的片上存储采用不同的层次组织方式，包括缓存、Shared Memory 和 Tensor Memory 等。

这些存储体系各有优势，但其容量、作用范围和生命周期管理方式并不相同。

Inferact 的实现恰好利用了 TPU 的大容量、显式管理的片上存储。

因此，其优势不能简单归结为“相同硬件条件下的软件胜利”。

更准确的结论是：

TPU 的存储体系结构与 Megakernel 的跨层流水线编程方式形成了良好的协同关系。

这是一个典型的 Hardware–Software Co-design（软硬件协同设计） 案例。Inferact

2.4 709 tokens/s 究竟意味着什么？

Inferact 使用了 DSpark 投机解码。

传统自回归解码通常在每轮目标模型前向计算中生成一个 Token。

投机解码则先由较小的 Draft Model 提出多个候选 Token，再使用目标模型进行并行验证。

Inferact 的实现每轮处理一个 Anchor 和七个候选位置。

在其报告的设置下，一次验证可以接受多个 Token。

因此，如果一次验证耗时约8.5毫秒，平均接受六个 Token，那么：

TPS ≈ 60.0085 ≈ 706

这与其报告的709 tokens/s 接近。

但必须注意：

709 tokens/s 并不意味着 Kimi K3 每1.4毫秒独立完成一次完整的自回归前向推理。

它是使用投机解码后计算得到的有效生成吞吐量。

而且，实际接受长度受到任务类型、生成内容与 Draft Model 准确率的影响。

例如，vLLM 团队2026年9月公布的 Kimi K3 DSpark 测试显示，不同任务上的接受长度存在显著差异，跨多个测试领域的平均接受长度约为4.11。GitHub

所以，709 tokens/s 应被理解为特定实验配置下的高性能结果，而不是所有应用都能够稳定获得的速度。

2.5 90秒编译同样值得关注

Inferact 报告，其 Megakernel 从零开始编译只需要不到90秒。

传统 TPU 大模型在包含大量 XLA 操作时，编译时间可能达到30分钟甚至更长。

产生这种差异的一个原因是：

传统编译器需要在复杂的计算图中推断操作顺序、融合方案和资源调度。

而 Megakernel 的开发者已经显式安排了大量调度细节。

这使编译器的工作范围发生变化。

不过，90秒与30分钟并非严格的同条件对照实验，不能据此宣称 Megakernel 编译普遍快20倍。

其更重要的意义是缩短开发、测试和性能调优的迭代周期。

三、浪潮信息：从算子融合走向系统级优化

与 Inferact 的跨层 Megakernel 相比，浪潮信息提出的超级算子具有不同特点。

它并不强调必须把整个模型的核心解码计算融合为单个 Kernel，而是将融合粒度主要放在 KDA、Gated MLA 和 MoE 等模块内部。

然后，进一步将算子优化与超节点的通信、内存和运行时调度结合起来。

3.1 超节点架构

根据浪潮信息2026年9月的发布材料，SD200 Ultra 具有以下架构特征：

统一编址使程序能够在一个共享的地址空间模型下访问分布式显存。

但需要强调：统一编址并不意味着远端显存具有与本地显存完全相同的访问成本。

其实际性能仍取决于互连拓扑、远端访问延迟、通信流量和并发情况。

浪潮信息希望通过对称内存及原生内存语义通信，降低数据交换和同步的成本。以上指标来自企业公开发布，仍需在明确测试条件下进行独立验证。IEI System

3.2 超级算子解决什么问题？

浪潮信息公布的优化方法主要涉及三个层次。

第一层：算子融合。

将多个基础算子组织成更大的计算单元，减少 Kernel 启动和不必要的中间结果读写。

企业报告，融合后算子数量减少到原来的约十分之一。

第二层：Tile 级流水线。

将计算数据划分为 Tile，通过异步搬运和多缓冲，使数据读取、计算和写回尽可能重叠。

第三层：计算与通信融合。

利用超节点的高速互连，减少跨设备数据交换造成的停顿。

按照浪潮信息的披露，这些优化使 Kimi K3 的综合推理效能提升三倍以上。

需要说明的是，公开材料尚不足以分离各项优化的独立贡献，也不足以判断这些性能提升在不同并发、上下文长度和任务类型下是否保持一致。IEI System

3.3 最值得关注的部分：让 K3 参与优化 K3

这个案例中，我认为最有研究价值的不是5.85毫秒，而是所谓的“超级算子智能体”。

根据浪潮信息转载的技术报道，其工作流程可以概括为：

性能分析 → 候选生成 → 编译执行 → 正确性检查 → 性能测量 → 反馈优化。

具体来说，智能体读取运行时性能数据，分析访存与计算瓶颈，提出新的算子融合、Tile 划分或流水线调度方案。

随后生成候选 Kernel。

候选程序必须经过正确性检查，才能进入性能测试阶段。

系统将测试得到的延迟、访存和资源占用等指标反馈给智能体，继续产生新的优化方案。

最终选择正确且性能更好的实现。

企业报告，闭环迭代后期还获得了约50%的性能提升。IEI System

这种方式与传统的人工性能调优有本质区别。

传统流程主要依赖专家观察 Profiling 数据，提出修改方案，然后人工编码和测量。

Agentic Kernel Optimization 则尝试将这一过程自动化。

不过，“K3优化K3”不应被理解为 K3 模型在运行中自主修改自己的神经网络权重。

公开材料描述的是一种由 K3 参与的离线软件优化流程，目标是改进执行 K3 的计算程序，而不是训练出新的 K3 模型。

这一区分十分重要。

四、这项技术是否代表新的发展方向？

我的判断是肯定的，但创新点需要准确定位。

4.1 算子融合本身并不是新技术

算子融合、循环优化、内存分块、异步流水线等技术，早已存在于编译器和高性能计算领域。

例如，FlashAttention 在2022年就通过 IO-aware 的算法设计和 Tiling，显著减少了注意力计算的 HBM 访问。arXiv

因此，不能认为2026年才发现“减少数据搬运可以提高推理速度”。

真正值得关注的是优化范围的扩大。

传统 Kernel Fusion 主要考虑相邻计算操作。

Megakernel 开始研究跨模型层的资源与执行调度。

超节点技术又将优化范围扩大到不同芯片之间的内存和通信。

可以将这一变化概括为：

局部算子优化 → 跨层程序优化 → 跨设备系统优化。

随着优化范围扩大，性能提升机会增加，但搜索空间和工程复杂度也随之增加。

因此，未来的重要问题不一定是“如何生成更大的 Kernel”。

它可能是：

怎样自动确定最合适的 Kernel 边界，以及如何在计算、存储、通信和维护成本之间取得最优平衡？

4.2 AI 自动优化 Kernel 也已有研究基础

在这方面，至少有两项工作值得作为学术参考。

KernelBench（ICML 2025）

论文题目：

KernelBench: Can LLMs Write Efficient GPU Kernels?

该研究建立了包含250项 PyTorch 工作负载的评测体系，考察大模型能否生成既正确又高效的 GPU Kernel。

其重要贡献是将程序正确性与实际加速效果结合起来评估。

论文指出，尽管前沿模型已经具备一定的 Kernel 生成能力，但其整体表现仍受到正确性和性能要求的明显限制。Proceedings of Machine Learning Research

AlphaEvolve（Google DeepMind，2025）

AlphaEvolve 使用语言模型生成候选算法，通过自动评估和迭代搜索寻找更优实现。

Google 报告了其在矩阵计算、编译器与 FlashAttention Kernel 优化中的应用成果。

其中包括对 FlashAttention 实现取得最高约32.5%的局部加速。Google DeepMind

这说明 AI 驱动的程序性能优化已经形成明确的技术方向。

浪潮信息案例的特别之处，在于尝试将这一机制引入特定超大模型与超节点推理系统的协同优化。

但从学术角度看，要判断它贡献了哪些新方法，还需要更完整的算法描述、公开实现和可复现实验。

五、值得警惕的五个技术问题

5.1 当前结果不能证明 TPU 普遍优于 GPU

709 tokens/s 与452 tokens/s 的比较，确实显示 Inferact 的 TPU Megakernel 在指定测试条件下获得约1.57倍的性能优势。

但比较双方同时改变了硬件平台与软件实现。

TPU 使用专门开发的 Megakernel，GPU 则采用 vLLM 发布的 Kimi K3 运行配置。

因此，这个结果证明的是特定端到端方案的性能优势，不能将全部差异归因于 TPU 芯片或者 Kernel Fusion。

尤其不能据此预测其他模型、其他 GPU Kernel 实现或者更大批处理规模下的性能关系。

5.2 极低并发不等于生产环境吞吐量最高

Inferact 的突出优势出现在低并发 Decode 场景。

但实际 AI PaaS 服务经常需要同时处理大量请求。

并发数量增大后，系统瓶颈可能发生转移。

例如，计算利用率可能提高，但跨设备通信、KV Cache 和调度开销也可能增加。

Inferact 在原始博客中明确指出，更高并发和不同拓扑仍属于未来需要继续研究的方向。Inferact

所以，低并发性能优势不能直接外推到整个云推理服务市场。

5.3 Token 速度不足以评价用户体验

云推理服务至少需要同时考察以下指标：

此外，对于 Agent，还需要测量整个任务的完成时间。

例如，一个智能体任务需要调用模型20次，并执行多个外部工具。

即使模型 Decode 速度提高两倍，只要时间主要消耗在工具调用、Prefill 或网络等待上，端到端任务也未必获得接近两倍的加速。

这说明 Kernel 性能、模型服务性能和 Agent 任务性能是三个不同的评价层次。

5.4 Kernel 越大，不一定越快

Megakernel 带来更大的调度自由度，也引入额外的工程约束。

包括片上存储不足、寄存器压力、编译复杂度、硬件资源竞争、动态输入和并行度不足。

一个融合程度很高的 Kernel，可能在 Batch Size 为1时表现优异，但在较大 Batch Size 下反而不如分解执行。

不同硬件架构适合的融合粒度也不同。

所以，未来的推理编译器不能简单遵循“融合越多越好”的策略。

它需要根据硬件和工作负载动态选择执行计划。

5.5 AI 生成 Kernel 的正确性并不简单

这是我认为博文讨论得不够充分的一点。

文章将 Kernel 优化描述为一种能够自动检查正确性、直接测量速度的任务。

这个理解具有合理基础，但不够完整。

例如：

浮点运算重新排序可能改变舍入结果；异步流水线可能引入数据竞争；某个 Kernel 可能在一种 Tensor Shape 下正确，却在另一种 Shape 下出现越界访问。

此外，MoE 动态路由可能造成数据分布变化，某些优化还可能只适用于有限的精度、Batch Size 或上下文长度。

因此，正确性并不是简单运行一次测试就能确定的。

从工程上看，需要对不同输入形状、数值精度、边界值、并发条件和硬件配置进行验证。

从研究角度看，还可以进一步引入形式化规格、程序分析和编译器验证技术。

这恰好构成了一个很有价值的研究问题：

如何为 AI 自动生成的高性能 Kernel 提供可验证的正确性保证？

六、建议关注的研究方向

如果将这篇博文作为技术研究的起点，我最推荐的不是直接复现 Kimi K3 的 Megakernel。

复现本身需要昂贵的硬件资源，而且已有开源代码。

更值得研究的是：

6.1 方向一：自动确定最优算子融合边界

英文题目可考虑：

Workload-Aware Kernel Fusion for Efficient LLM Inference

研究问题是：

给定计算图、硬件资源约束和工作负载，能否自动决定哪些算子需要融合，哪些算子应当保持独立？

可以将问题表示为约束优化：

min_{P, S} T(P, S | H, W)

其中：

• P 表示算子分区，即融合边界；
• S 表示调度方案；
• H 表示目标硬件；
• W 表示工作负载；
• T 表示实际执行时间。

同时受到片上存储、并行资源、数值正确性等约束。

该问题具有明确的计算机系统研究属性。

实验不需要2.8万亿参数的大模型，可以从小型 Transformer 或 MoE 模块开始。

6.2 方向二：可验证的 Agentic Kernel Optimization

这是我认为更有潜力的方向。

建议题目：

Verified Agentic Kernel Optimization: Correctness-Constrained Performance Search for AI Inference

中文可译为：

可验证的智能体驱动算子优化：面向 AI 推理的正确性约束性能搜索

研究重点并非简单让 LLM 生成 Kernel，而是建立能够提供验证证据的优化机制。

一个完整的实验系统可以采用如下架构：

这里可以结合 KernelBench 的正确性与性能评测方法。

研究创新则可以放在：

让 AI 的程序优化决策受到显式正确性约束，而不是只在测试通过后选择速度最快的版本。

例如，可以研究不同验证强度是否影响智能体找到高性能方案的效率，以及测试通过的程序是否能够可靠地推广到未见过的工作负载。

这比单纯比较两个 Coding Agent 谁写的 Kernel 更快，更容易形成具有长期价值的研究贡献。

6.3 方向三：面向异构设备的推理性能优化

英文题目：

Portable Megakernel Optimization across Heterogeneous AI Accelerators

研究目的不是要求同一份低层代码在各种设备上获得完全相同的性能。

而是寻找一种能够跨硬件表达优化意图的中间层。

例如，描述：

数据的生命周期、可融合计算区域、异步传输依赖、流水线关系，以及通信和计算的资源约束。

然后，根据目标设备的存储层次与执行模型，将这些描述转化为具体实现。

这个方向可能涉及 MLIR、编译器中间表示、自动调度和性能建模。

它的难度明显高于前两个方向，但能够与异构 AI 基础设施形成联系。

七、一个可以实际开展的小型研究项目

对于高校软件工程研究，我建议首先考虑第二个方向，并限制实验规模。

项目名称

Agentic Kernel Lab：面向 AI 推理算子的自主优化与验证实验平台

不需要购买大型 TPU 集群，也不需要部署 Kimi K3 全模型。

可以使用一台支持 CUDA 的实验服务器，配合 PyTorch、Triton 和 KernelBench。

研究对象首先选择少量具有代表性的计算模块，例如 RMSNorm、矩阵乘法与激活函数组合，以及简化的 MoE 专家计算。

建议开展四组对照实验：

每组记录计算正确性、执行延迟、编译时间、资源使用情况和优化成本。

Agent 组进一步记录候选程序数量、测试失败次数、有效优化次数，以及最终获得的性能提升。

重点不应该仅仅是 D 组能否超过 A 组。

而是回答：

1. Agent 能否稳定产生正确且有效的优化？
2. 加入系统化验证后，性能搜索效率如何变化？
3. 性能优化是否会过拟合特定输入规模？
4. 在相同搜索预算下，不同反馈策略的效果有何区别？

这样的实验规模可控，而且能够积累具有研究价值的数据。

如果实验结果较好，再增加跨算子融合与异构设备支持。

从工程实现看，完全可以采用多语言 CLI、JSONL 和独立运行时的架构，将 Agent、编译器、验证器和性能测量器设计为解耦模块。

这也使系统能够从研究原型逐步发展为通用的智能体软件工程工具。

八、对 AI PaaS 和云基础设施的影响

这些技术还会改变云服务商之间的竞争方式。

过去评价 AI 计算资源，通常强调 GPU 数量、峰值 FLOPS、HBM 容量和互连带宽。

这些指标仍然重要，但已经不足以反映用户最终获得的性能。

从 AI PaaS 角度看，真正提供给用户的资源不是单纯的加速器，而是运行在特定模型、运行时和硬件组合上的推理服务。

因此，未来可能出现更明确的三层性能优化体系。

硬件层：Hardware Optimization

解决计算能力、存储带宽、片上存储与芯片互连问题。

运行时层：Inference Runtime Optimization

解决 Kernel Fusion、计算调度、权重预取、KV Cache、批处理和通信问题。

服务层：AI PaaS Optimization

解决请求调度、模型路由、弹性伸缩、Prefill/Decode 分离、服务可用性与成本优化问题。

三个层次相互关联，但评价目标并不完全相同。

例如，Megakernel 可能显著降低单用户 Decode 延迟，却未必能够直接降低整个集群的单位 Token 成本。

反过来，AI PaaS 的请求调度优化也可能在不修改任何 Kernel 的情况下，提高整体资源利用率。

因此，对云平台而言，一个更完整的目标函数可能是：

min Cost per Successful Request

约束条件包括：

Latency_P95 ≤ L_max
Quality ≥ Q_min
Availability ≥ A_min

也就是说，云平台需要在正确性、质量、性能、可靠性与成本之间作整体优化。

从这个意义上看，Megakernel 和超级算子可以视为下一代 AI PaaS 的底层性能技术，而不是独立的云产品。

九、综合评价

9.1 技术成熟度

我对这两项工作的判断如下。

这些是基于当前公开资料的定性评价，而非独立性能测试结果。

9.2 真正值得关注的技术变化

我认为这篇博文触及了两个值得持续跟踪的变化。

一是推理程序的组织方式正在发生变化。

过去，深度学习框架通常将模型表达为计算图，再由编译器和运行时执行大量相对独立的 Kernel。

Megakernel 表明，在特定低并发推理场景中，开发者可能需要突破传统算子边界，以获得跨层的存储和执行调度能力。

这种方法并不一定替代通用推理框架，但可能成为特定模型和硬件组合下的重要优化手段。

二是推理系统的优化过程正在逐步智能体化。

程序生成、正确性检查和性能测试都能够通过工具获得明确反馈。

这使 Kernel Optimization 成为适合 Coding Agent 进行反复实验的领域。

尤其是在模型和硬件不断更新的情况下，完全依靠人工维护定制 Kernel 的成本可能越来越高。

智能体可以帮助工程师探索更大的优化空间，但其可靠性仍然依赖严格的验证和可重复的性能测量。

9.3 最终判断

这篇博文并不是在介绍一种全新的算子融合算法。

它所反映的，是 AI 推理基础设施正在出现的一个更广泛趋势：

从针对单个算子的局部优化，转向针对模型、运行时和硬件的联合优化。

而在这个过程中，AI 智能体开始成为优化工具链的一部分。

对软件工程研究而言，我尤其建议关注以下交叉领域：

Agentic Software Engineering × Compiler Optimization × Program Verification × AI Inference Infrastructure

它既具有实际工程需求，也存在明确的科学研究问题。

相较于直接研究“如何让 Kimi K3 再快一些”，研究如何使智能体可靠地生成、验证和选择高性能计算程序，可能具有更广泛的适用性。

主要参考资料

[1] Inferact. (2026, September 23). 700 TPS on Kimi K3: A Case for TPU Megakernels.
https://inferact.ai/blog/tpu-megakernels

这是最重要的第一手技术资料，包含设计思路、硬件参数和性能实验。

[2] Inferact. (2026). TPU Megakernels [Source code]. GitHub.
https://github.com/Inferact/tpu-megakernels

提供 Megakernel、DSpark、测试程序及推理服务示例，适合进一步研究实现细节。

[3] 浪潮信息. (2026年9月28日).《从提供算力到生产智能——Agent时代的AI计算系统挑战和创新》演讲实录。
https://www.ieisystem.com/about/news/23442.html

包含超节点架构、通信技术和超级算子的主要性能声明。

[4] 浪潮信息. (2026年9月30日).《“超级算子”打开新路径！元脑AI超节点：用K3优化K3，推理快了3倍》。
https://www.ieisystem.com/about/news/23445.html

这是用户所引博文的较完整转载版本，包含超级算子智能体的工作流程描述。

[5] Ouyang, A., et al. (2025). KernelBench: Can LLMs Write Efficient GPU Kernels? Proceedings of the 42nd International Conference on Machine Learning.
https://proceedings.mlr.press/v267/ouyang25a.html

适合作为智能体自动生成与优化 Kernel 的学术研究起点。

[6] Google DeepMind. (2025). AlphaEvolve: A Gemini-powered coding agent for designing advanced algorithms.
https://deepmind.google/blog/alphaevolve-a-gemini-powered-coding-agent-for-designing-advanced-algorithms/

适合参考模型生成、自动验证、性能评价与迭代搜索组成的优化体系。

[7] Dao, T., et al. (2022). FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness. NeurIPS 2022.
https://arxiv.org/abs/2205.14135

适合了解这类推理优化背后的 IO-aware Computing 与数据搬运成本问题。

报告结论 Inferact 的工作展示了跨层 Megakernel 在特定 TPU 推理负载上的显著性能潜力；浪潮信息的工作展示了算子融合、超节点架构与 AI 辅助优化相结合的技术路线。两者的共同启示，不是单纯追求更大的算子，而是让计算程序获得更广泛的资源调度能力，并逐步自动化这一复杂的优化过程。