摘要
MetaInfer1,2 想探索的核心问题，是当模型、硬件和部署目标已经确定以后，AI Infra 是否还必须按照"维护一个覆盖所有场景的通用系统"这一方式来开发。 过去的推理框架通过不断增加抽象来应对模型、硬件、量化和并行策略的快速变化，这种通用性非常重要；但对于一个已经确定的部署场景，其中大量选择实际上在程序运行之前就已经知道。MetaInfer 因此尝试把一部分过去留在 runtime 的选择提前到 generation time：由人给出需求和约束，再让 Agent 生成、验证和持续优化面向这一场景的专用实现。
随着项目推进，我们关注的问题也从"LLM 能不能写推理框架"逐渐变成了"怎样让 Agent 真正完成 AI Infra 工程"。 这意味着生成代码只是过程的一部分，更重要的是把知识、测试、Benchmark、真实硬件和失败反馈组织成一个可重复的工程闭环。目前 MetaInfer 已经从最初的专用推理框架生成实验1,3，逐渐扩展到 Kernel 优化、模型移植、性能分析等任务2；而 kernel_zoo4 则进一步尝试解决另一个问题：如何让不同 Agent 产生的 Kernel 和优化历史能够被验证、比较、保存和复用。
这篇文章想回答四个问题：为什么我们认为 AI Infra 需要另一种开发方式；MetaInfer 的核心方法是什么；目前我们已经做到了哪里；以及 kernel_zoo 为什么会成为这条路线自然延伸出来的一部分。
一、为什么做 MetaInfer：固定部署不一定需要承担全部"通用性成本"
今天推理框架越来越复杂，本质上是因为它们必须用一套系统处理越来越大的组合空间。 一个成熟的推理框架不仅要支持不同模型架构，还要处理不同 GPU、不同精度和量化方案、不同并行方式以及不同服务负载。vLLM5、SGLang6、TensorRT-LLM7 和 llama.cpp8 都在各自的设计目标下支持了大量模型与部署场景；当模型 × 硬件 × 量化 × 并行 × Kernel 继续组合时，模型抽象、Backend 抽象、算子抽象、调度器和分布式运行时的复杂度也必然随之增加。
这种复杂性并不是通用框架设计得"不够好"，而是通用框架必须为未来的不确定性付出的成本。 我们在之前的文章《为什么每次换一张卡、一个模型，都要上一整个推理框架？》9 里专门强调过这一点：vLLM、SGLang、TensorRT-LLM、llama.cpp 之所以复杂，恰恰是因为它们服务的是模型、硬件和工作负载都不断变化的现实世界。真正值得追问的并不是"要不要通用框架"，而是当部署条件已经确定以后，我们是否仍然需要支付通用性的全部代价。
固定部署和通用框架面对的其实是两个不同的问题：前者利用确定性，后者管理不确定性。 假设目标已经明确为 Qwen3-8B、确定的 GPU、固定量化格式、C++ 服务端以及 OpenAI 兼容接口，那么 KV Cache 的组织方式、模型前向路径、权重格式乃至很多算子选择都可以提前确定。我们此前的 C++ 推理框架生成工作9 就是有意把模型、硬件、量化格式和服务接口固定下来，从而让大量原本隐藏在通用 Runtime 中的选择变成显式约束。
Kernel 优化已经证明，"利用确定性换取专用优化"本身是一种非常自然的工程方法。 在针对海光 K100AI 和 DeepSeek V4 Flash 的 W8A8 GEMM 优化工作10 中，我们面对的是典型的固定小 M 推理 Shape，例如：
M = 32, N = 4096, K = 1024通用 GEMM 必须支持任意 M、N、K，还需要考虑边界处理、不同数据布局和不同硬件配置；但在固定模型的推理链路里，这些条件往往在运行之前已经知道。因此，我们可以把权重重排等工作提前到模型初始化阶段，并围绕固定 Shape 重新设计 tile、线程映射、数据通路和流水线。换句话说，这类优化的关键并不是增加更多运行时判断，而是利用部署前已经知道的信息，尽可能减少运行时需要做的选择。
MetaInfer1,2 最初的动机，就是把这种 specialization 从 Kernel 层进一步推广到整个推理系统。 与其先选择一个覆盖所有场景的 Runtime，再在运行时决定应该走哪条路径，我们想尝试反过来：先告诉系统模型、硬件、量化方式、并行策略和性能目标，再为这些已经确定的条件生成一条尽可能直接的实现路径。
Generation-time specialization 并不是 MetaInfer 独有的判断，而是在 Agentic Systems 领域已经出现的一条研究路线。 VibeServe11 同样提出，不再依赖一个通用 Runtime 覆盖所有模型、硬件和 workload，而是通过多 Agent 循环为具体场景生成 bespoke serving system。MetaInfer 和 VibeServe 在"利用 generation-time specialization 替代部分 runtime generality"这一基本判断上是相近的，但 MetaInfer 此后的工作进一步把问题扩展到了知识契约、C++/HIP 原生推理系统、Kernel 优化以及更广泛的 AI Infra Task。1,2,9
所以从一开始，MetaInfer 真正想研究的就不是：
"LLM 会不会写推理代码？"
而是：
"当部署条件已经确定以后，能不能把一部分 runtime generality 转化为 generation-time specialization？"
二、MetaInfer 怎么做：不是一次生成代码，而是让 Agent 进入可验证的工程闭环
我们很快发现，AI Infra 最困难的问题并不是生成代码，而是让生成过程遵守真实的工程约束。 在最早的 MetaInfer 实验1,3 中，我们先人工完成了 Qwen3-8B 的极简推理引擎 meta0，再从中提取调度器、KV Cache、张量并行和通信等经验，将它们整理成 11 类结构化知识，最后让 Agent 在不读取原型源码的情况下重新构建推理系统。这个实验验证了"显式知识 + Agent 可以生成推理框架"这条路线，但也让我们意识到，真正困难的工作并不在代码补全本身。
真正的 AI Infra 工程包含大量不能靠一句 Prompt 自动补齐的隐含约束。 我们在《为什么每次换一张卡、一个模型，都要上一整个推理框架？》9 中列举过一个 C++/HIP Qwen3 推理系统真正需要解决的问题：Agent 不仅要知道 Attention、RMSNorm 和 RoPE 怎么写，还需要理解硬件的编译和内存限制、GQA 如何映射到 KV Cache、GGUF 权重如何解释、Q8_0 如何反量化、prefill 与 decode 如何共享状态，以及服务能够输出文本是否真的意味着数值正确。也就是说，"生成一段看起来合理的代码"和"交付一个可运行系统"之间，还隔着完整的工程约束。
因此，MetaInfer 后来的核心设计不再是"给 Agent 一个 Prompt"，而是"给 Agent 一个受约束的工程环境"。 在后续的 C++ 推理生成工作9 中，一个任务会先明确部署约束和本轮目标，再由 Agent 生成或修改候选实现，随后进入编译、正确性验证和性能测试；如果失败，系统还需要记录失败发生在哪个阶段、产生了哪些输出、性能发生了什么变化，并把这些证据重新送入下一轮。
整个过程可以概括为：
明确部署约束
↓
规划本轮任务
↓
生成 / 修改候选实现
↓
编译与运行
↓
正确性验证
↓
性能测试
↓
分析失败和瓶颈
↓
进入下一轮在这个闭环里，最重要的并不是 Agent 的数量，而是每一步是否存在明确的输入、输出和失败边界。 如果一个 Agent 只是"写代码 → 失败 → 再试一次"，那么整个过程很容易退化成没有记忆的随机搜索；而在 MetaInfer 的工程闭环9 中，下一轮应该知道上一轮吞吐和延迟是多少、失败发生在哪个阶段、属于编译错误还是数值错误、哪些实现发生了变化，以及哪项优化造成了性能回退。只有这些失败能够被结构化地保存下来，Agent 的尝试才真正具有累积性。
Oracle 和 Benchmark 因而不是生成系统外围的辅助工具，而是 MetaInfer 方法的一部分。 早期 MetaInfer 实验1,3 曾采用相互隔离的 Implementer、Spec Reviewer 和 Verification 角色，并将部分测试脚本设计成 Agent 无法修改的验证门禁。这里的关键并不是"多用了几个 Agent"，而是让生成实现的一方不能同时重新定义"什么叫正确"；换句话说，Agent 可以修改实现，但不应该拥有随意修改验收标准的能力。
我们此前的 Kernel Benchmark12 更直接暴露了验证环境的重要性。 在使用 MetaInfer 测试 DeepSeek V4 Flash 编写海光 GPU Kernel 时，其中一道题曾出现 36.33× 和 25.23× 的异常高加速，但进一步分析发现，两个模型都通过代数恒等变换消除了原本的大 GEMM。这个结果并不是"Kernel 被优化了三十多倍"，而是 Agent 找到了绕开原始计算的另一种解法。这个案例说明，Agent 会非常积极地优化我们提供的目标，因此未来 Agent 越强，如何定义正确性、怎样设计 Benchmark、什么结果属于可接受优化，反而会越来越重要。
基于这些实践，我们现在更愿意用一句话描述 MetaInfer 的方法：
MetaInfer 不是一个 Text-to-Code 工具，而是一个 Verification-driven 的 AI Infra 工程环境。
三、MetaInfer 目前做到哪里：从"生成一个框架"走向"让 Agent 做不同类型的 AI Infra 工作"
MetaInfer 目前最重要的变化，是它已经从一个单一的推理框架生成实验逐渐演化成 AI Infra 优化工具箱。 早期《MetaInfer：让 LLM 自己写推理框架》3 主要围绕 Qwen3-8B、Contract Knowledge Base 和多 Agent 生成展开，而 MetaInfer 论文1 则进一步将其概括为 LLM-as-Compiler 的系统生成问题。随着实践增加，我们逐渐发现，"生成推理框架"更像是这套方法最完整的一个实例，而不是 MetaInfer 唯一能够承担的任务。
不同 AI Infra 问题虽然产物不同，但背后的工程闭环其实高度相似。 写推理框架需要读取知识、生成实现、验证数值并测量性能；优化 Kernel 需要生成候选、运行 correctness 和 Benchmark；模型移植则需要理解上游实现和目标环境、修改代码并持续执行回归测试。正因为这些任务都可以被表达成"Knowledge / Constraint → Agent → Oracle → Feedback"的形式，MetaInfer next-app2 才开始把不同能力组织成相对独立的 Task，而不是把所有逻辑继续写进一个越来越复杂的单体程序。
目前公开的 MetaInfer next-app2 已经把专用推理框架生成、Kernel 优化和 Model Porting 放在同一个项目愿景下。 项目当前将 purpose-built inference framework generation 作为核心方向，同时包含 AI-assisted Kernel Optimization、Model Porting，以及 C/C++、Rust 原生输出等任务；WebUI、Task Orchestrator 和 GPU Worker 则为这些任务提供统一的运行环境。换句话说，MetaInfer 正在逐渐从"一个会生成推理框架的 Agent"变成一层承载不同 AI Infra Agent Workflow 的基础设施。
我们此前围绕海光平台开展的一系列工作，也在不断给这套环境补充真实的工程经验。 DeepSeek V4 Flash Kernel 能力评测12 暴露了模型直接编写 GPU Kernel 时的正确性、性能、超时和 Benchmark loophole 问题；海光 K100AI W8A8 GEMM 优化10 积累了固定 Shape 下权重预打包、数据布局、MMAC 和流水线优化经验；MiniMax-M3 在海光 DCU 上的部署与优化系列13 则从模型结构出发，为后续部署、算子适配和性能优化建立前提。
这些工作的价值并不只在于得到某一个更快的 Kernel 或多支持一个模型，而在于把人的工程经验逐渐转化成 Agent 可以消费的资产。 工程师在真实优化过程中会逐渐知道哪些模型结构需要优先关注、哪些 Shape 更可能成为瓶颈、哪些硬件细节容易踩坑、哪些错误适合在算子级提前拦截；如果这些经验只能留在某个工程师的脑子里，那么下一次 Agent 仍然只能重新搜索。因此，MetaInfer2 希望逐步把这些经验表达成 Knowledge、Skill、Constraint、Oracle 和 Benchmark，使新的任务不是从"一个更长的 Prompt"开始，而是从一个更成熟的工程环境开始。
所以 MetaInfer 当前的演化可以概括为：
最初：
让 LLM 生成一个专用推理框架
↓
现在：
让 Agent 在可验证的闭环中完成多种 AI Infra 任务
↓
下一步：
让不同任务产生的工程经验能够被后续 Agent 继续使用而最后这个问题，正是 kernel_zoo4 出现的原因。
四、为什么还要做 kernel_zoo：一次 Agent 优化不应该在任务结束后消失
当 Agent 开始反复优化 Kernel 以后，我们遇到的新问题不再是"能不能生成"，而是"生成出来的经验放在哪里"。 假设一个 Agent 用几个小时把某个 Kernel 从 80 μs 优化到了 55 μs，那么下一次另一个 Agent 接到同一个问题时，它理应从已经验证过的 55 μs 版本继续尝试，而不是重新从 PyTorch Reference 或一个朴素实现开始。要做到这一点，系统不仅需要保存最终代码，还必须知道这个结果在哪张 GPU、什么 Shape、什么精度和什么 Benchmark 下得到，以及历史上哪些方案已经尝试过。
仅仅给 Agent 增加对话 Memory 并不能解决这个问题，因为 AI Infra 的经验最终需要跨 Agent、跨任务甚至跨机器存在。 MetaInfer2,9 已经尝试在单个 Task 内保存失败原因和性能反馈，使下一轮迭代建立在上一轮证据之上；但如果经验只停留在一次 Task 的 Workspace 中，那么任务一结束，其他 Agent 仍然无法利用这些结果。因此，我们需要一个更高层的共享状态，把"当前最好实现是什么、为什么它被接受、过去还有哪些尝试"变成能够被查询和继续优化的信息。
kernel_zoo4 就是我们对这层共享状态的一次尝试。 当前 kernel_zoo4 将自己定义为 LLM GPU Kernel 的动态排行榜和 Benchmark 平台，并采用 Git repository as database 的设计：每个 Kernel implementation 都是 Git 仓库中的一个目录，Benchmark 结果也保存在仓库中，而 git log 则天然记录了完整的历史。Runner 从服务端获取 Benchmark Task，在真实运行环境中执行 benchmark.py，再把结构化结果返回并写入对应 Kernel 的历史。
kernel_zoo4 真正想保存的并不只是 Kernel，而是一段可以验证和追溯的优化历史。 一个最终 Kernel 文件只能告诉后来的 Agent"代码是什么"，却不能单独回答"这个结果在哪张设备上测得""使用了什么 Benchmark""之前哪些实现已经失败""为什么当前版本被接受"。当代码、Benchmark 和 Git History 被放在一起以后，Agent 才有机会从单纯的"复用代码"进一步走向"复用搜索过程"。
从这个角度看，kernel_zoo4 可以被理解为 MetaInfer 生态中正在尝试建立的一层 Experience Layer。MetaInfer2 负责组织一次具体的工程过程，包括理解任务、调用 Agent、修改实现、使用真实硬件和验证结果；kernel_zoo4 则尝试把其中已经得到验证的 Kernel 和优化历史变成跨任务可以继续利用的公共经验。二者结合以后，我们希望形成的不是"AI 写一次代码，人把结果保存下来"的线性流程，而是一个能够不断积累的循环：
Deployment / Optimization Requirement
↓
MetaInfer
↓
Agent generates / modifies
↓
Correctness + Benchmark
↓
Verified implementation
↓
kernel_zoo
code + score + history
↓
下一轮 Agent 从已有结果继续如果这一层能够真正工作，多个 Agent 才可能从独立搜索逐渐变成共享经验的协作搜索。 一个新的 Agent 接到任务以后，第一步不必再问"应该从哪里开始写"，而可以先查询当前硬件和 Shape 下有哪些实现、哪一个最好、哪些方向已经被证明无效，再决定下一步实验。这个问题目前在 Kernel 上最容易定义和验证，但长期来看，我们希望类似的经验积累机制也能够延伸到更多 AI Infra 工作中。
结语：我们最终想改变的，也许不是代码，而是"人需要长期维护什么"
MetaInfer1,2 最终想探索的，并不是用 AI 再造一个新的通用推理框架，而是重新思考生成式时代 AI Infra 的开发对象。 传统软件工程中，源代码是最重要的长期资产，因此工程师需要不断设计抽象，让同一份代码能够支持更多模型、更多硬件和更长的生命周期；但如果未来 Agent 可以越来越低成本地根据约束重新生成和验证实现，那么"所有场景共享同一份实现"就不再是唯一可能的软件组织方式。
在这种开发方式下，人真正需要长期维护的东西可能会逐渐上移。 我们仍然需要源码，但相比某一个具体实现，也许更重要的是维护模型和硬件的 Specification、不可违反的 Constraint、可复用的 Knowledge 和 Skill、可靠的 Correctness Oracle、真实的 Benchmark，以及已经经过验证的历史结果。具体实现代码则由这些信息和当前部署目标共同决定，并在模型、硬件或者性能目标发生变化时重新生成。
这也是 MetaInfer 从最初"让 LLM 自己写推理框架"一路发展到今天的核心脉络。 最开始，我们通过 MetaInfer 原型和相关工作1,3 验证 AI 能否根据显式知识生成专用推理路径；随后在固定部署和 C++ 推理框架生成工作9 中，我们发现真正重要的是让 Agent 进入一个有明确边界和客观反馈的工程闭环；再往后，随着 Kernel 能力测试12、W8A8 GEMM 优化10、模型移植和性能分析等任务逐渐加入 MetaInfer2，我们又开始面对经验如何跨任务积累的问题，因此有了 kernel_zoo4 这样的尝试。
所以现在我们更愿意用下面这句话来描述 MetaInfer 想做的事情：
不是让 AI 写更多 AI Infra 代码，而是构建一个能够让 AI Infra 被持续生成、验证、优化并积累的环境。
这条路线目前还非常早，很多问题也远没有解决：怎样让知识跨模型和硬件迁移，怎样设计不容易被 Agent 利用的 Benchmark，怎样让性能经验真正跨任务复用，以及自动生成的系统怎样逐渐接近生产环境的可靠性，都还需要大量实践。
但我们认为有一件事情已经值得开始认真讨论：
当代码本身越来越容易被生成以后，AI Infra 工程师未来最重要的工作，也许不再只是维护代码，而是维护让正确代码能够不断"长出来"的知识、约束、验证和反馈系统。
参考文献
1 Zhenwen Miao, Honglin Wang, Mingheng Mi. MetaInfer: A Knowledge Only LLM Inference Engine Generator SKILL Toolbox. arXiv:2607.12875, 2026.
2 MetaInfer Project. MetaInfer --- LLM-powered AI Infra optimization toolkit. GitHub repository, next-app branch, 2026. https://github.com/MetaInfer/MetaInfer/tree/next-app
3 达坦科技 DatenLord. 《MetaInfer：让 LLM 自己写推理框架》. 微信公众号，2026 年 6 月 6 日。
4 MetaInfer Project. kernel_zoo --- Dynamic leaderboard and benchmark platform for LLM GPU kernels. GitHub repository, 2026. https://github.com/MetaInfer/kernel_zoo
5 Woosuk Kwon, Zhuohan Li, Siyuan Zhuang, et al. Efficient Memory Management for Large Language Model Serving with PagedAttention. arXiv:2309.06180, 2023.
6 Lianmin Zheng, Liangsheng Yin, Zhiqiang Xie, et al. SGLang: Efficient Execution of Structured Language Model Programs. NeurIPS, 2024.
7 NVIDIA. TensorRT-LLM. GitHub repository.
8 ggml-org. llama.cpp: LLM inference in C/C++. GitHub repository.
9 FF. 《为什么每次换一张卡、一个模型，都要上一整个推理框架？》. 达坦科技 DatenLord，2026 年 7 月 30 日。
10 FF. 《海光 K100AI：W8A8 GEMM 算子深度优化》. 达坦科技 DatenLord，2026 年 8 月 15 日。
11 Keisuke Kamahori, Shihang Li, Simon Peter, Baris Kasikci. VibeServe: Can AI Agents Build Bespoke LLM Serving Systems? arXiv:2605.06068, 2026.
12 极客幼稚园. 《使用 MetaInfer 测试 DeepSeek V4 Flash 编写海光 GPU 算子的能力》. 达坦科技 DatenLord 转载，2026 年 8 月 7 日。
13 码上算完. 《MetaInfer AI 推理优化小课堂｜MiniMax-M3 在海光 DCU 的部署与优化（一）：从 M2 到 M3 的模型结构解析》. 达坦科技 DatenLord 转载，2026 年 8 月 20 日。