天下苦通用推理框架的“冗余抽象”久矣!为了保持通用性而引入的大量复杂逻辑,不仅带来了沉重的维护负担,更无形中吞噬了硬件的极致性能。
近日,达坦科技(DatenLord)、黄埔星与琶洲实验室展开深度合作,提出了能够自主构建精简定制推理引擎的MetaInfer。在当前原型实现中,合作团队创新性地采用三角色对抗式多智能体架构,在完全白板条件下,由 Agent 在多平台上自主生成了可用的精简推理引擎。
其核心代码仅 3,550行,这一成果成功证实:“按需生成式”的精简引擎,完全有能力颠覆并取代传统的巨型静态软件系统。
MetaInfer项目和文档已全部开源,欢迎关注点赞。
GitHub: https://github.com/MetaInfer/MetaInfer(“阅读原文”)
同时我们也在招募参与此项目的实习生,欢迎对推理框架优化感兴趣的同学参加,感兴趣的同学请联系小助手咨询:DatenLord\_Tech
01、通用推理框架的“死重”之痛
今天,如果你想在 4 张 A800 上跑 Qwen3-8B,最自然的选择是 vLLM 或 SGLang。它们是大超市——什么都有:几十种模型架构、十几种量化后端、多硬件适配、数千个环境变量开关。
但这种“大而全”是有代价的:
- 维护负担重:改一行公共代码,可能影响几十个模型的行为;
- 运行效率受限:动态派发、抽象层层嵌套;
- 新模型适配慢:手写数百行模型适配代码,重复造轮子。
更关键的是:你只想要一条直达目标的路径,框架却塞给你一张绕遍全城的迷宫地图。
MetaInfer 的想法很反常识:让大模型自己当编译器。你说清楚场景(“Qwen3-8B,TP=4,A800,纯 eager”),它就从知识图谱里检索出所需契约,驱动多智能体系统“定制”出一套零冗余的推理代码。
02、先有鸡还是先有蛋?人工搭一个“最小原型”
为了让智能体有经验可学,团队先在 A800 上针对 Qwen3-8B 手搓了一个极简推理引擎:原型引擎 meta0。
过程不复杂,但全是硬核工程,虽然简陋,但包含了调度器、KV Cache、张量并行、通信优化的完整经验。它成了后续知识图谱的“素材矿山”。
03、把经验写成“契约”,放进知识图谱
团队从原型引擎中提取了 11 大类结构化知识,写入 inference\_blueprint.json:
- 光有知识还不够,质量要经得起拷问。团队引入了两类独立审计子代理:
- 正确性审计:对每个契约做「文档 → 参考代码 → 实现代码」三方交叉印证;
- 完备性审计:假设原型源码已销毁,仅凭图谱尝试重建,发现缺口就回填。
经过 5 轮正确性审计 + 17 轮完备性审计,故障模式覆盖率从 40% 拉到 90+%。
04、三个AI“互撕”,bug无处藏
单 Agent 写长代码,有三个致命弱点:确认偏误(自己写的 bug 自己看不出来)、上下文遗忘(丢掉早期约束)、测试盲区(只测“我做了什么”而非“该做什么”)。
MetaInfer 的做法很“暴力”但有效:三个物理隔离的角色,彼此不信任。
- Implementer(工具 spawn):只写代码,不跑测试,提交状态永远是 SUBMITTED;
- Spec‑reviewer(独立 Shell 进程):只读代码,逐条对照蓝图契约,发现违反就打回;
- Verification(也是 Shell 隔离):只跑固定测试脚本,不看任何代理的报告,全部通过才算交付。
整个管线按物理依赖拆成 11 个 Phase,每个 Phase 必须通过前序所有 scripts/ 门禁才能继续。测试脚本本身是只读的“宪法”,Agent 无权修改。
这种设计借鉴了开源社区 superpowers 的子代理对抗协作模式。目前全部 11 个 Phase 均已通过多智能体串行审查验收,Agent 在白板条件下生成的推理框架实现了单卡与四卡张量并行推理输出字字对齐。
05、跑得通,还跑得快
为了验证生成引擎的质量,团队将 Agent 自动生成的框架(完全没有使用原型源码)与 vLLM 做了对比。
测试环境:Qwen3-8B,TP=4(A800 80GB),batch=1,temperature=0。
两个关键观察:
- 代码量缩减 99%:因为生成的是单路径引擎,没有“支持 50 种模型”带来的抽象层;
- 跟 CUDA Graph 仍有差距:生成引擎目前是纯 eager 模式,CPU dispatch 占了 494.7ms(vLLM CUDA Graph 仅 79.7ms)。这也是下一步的重点。
团队也坦诚了当前局限:知识图谱高度耦合于 Qwen3-8B + TP=4,换模型或并行策略需要重新补充; MetaInfer生成引擎经简单cpu侧调度优化,吞吐率可增至60.2tok/s,AllReduce降至29.3ms,优于vLLM eager——Agent 生成的 Python 调度层效率还不够高,MetaInfer团队已经跟进补充知识图谱
06、不完美,但欢迎社区一起填坑
项目负责人很实在:“这是我们在该领域的第一次尝试,很多地方还很简陋。提前发布是希望获得社区的早期反馈,一起把知识图谱和生成管线打磨得更通用。”
目前开源的内容已经诚意满满:
- 完整知识图谱 inference\_blueprint.json(11 大类契约)
- 多智能体协作 SOP(AGENT\_SKILL.md + CLAUDE.md)
- 28 个只读门禁脚本(确保每次生成的引擎通过功能性验收)
- 原型引擎 meta0的全部过程文档(从零到 55.7 tok/s 的迭代记录)
项目地址:
https://github.com/MetaInfer/MetaInfer
短期目标很明确:
- 性能知识图谱强化:把原型中 torch.compile、CUDA Graph 的优化经验回灌到蓝图,让生成引擎的吞吐追上原型;
- 跨模型泛化:补充 DeepSeek-V2(MLA+MoE)的知识,验证 MetaInfer 能否从“一个模型”走向“一类模型”。
长期愿景更大胆:建立一个社区共建的推理框架知识基础设施。你只需上传模型的 config.json 和一份简单的 model\_spec.yaml,系统就能自动生成专属于该模型 + 该硬件的推理引擎。Human 的角色从“精细化审查代码”降级为“提供标准化描述文件 + 审查 benchmark 结果”。
07、结语:让框架自己“长”出来
过去,写一个推理框架意味着要读通数万行通用代码,理解几十个抽象层,再手动裁剪出自己需要的路径。MetaInfer 走了一条相反的路:把工程经验沉淀为结构化知识,再让大模型按需“编译”出单路径引擎。
这条路才刚刚开始。目前的生成引擎还有很多优化空间,知识图谱也只覆盖了一个模型、一种并行策略。但至少它指出了一个可能的方向:当大模型足够强,搭建一个结构化的、可观测的演化环境,比手写一个通用框架更重要。
欢迎你来看、来用、来提 issue,更欢迎你把自己的工程经验补充到知识图谱里。
毕竟,让推理框架自己学会进化,才是最省力的方式。
项目代码与文档已全部开源,觉得有意思欢迎点个 ⭐️
GitHub: https://github.com/MetaInfer/MetaInfer
往期推荐:
vLLM 内部:高吞吐量 LLM 推理系统解剖
vLLM 内部:高吞吐量 LLM 推理系统解剖(二)
达坦科技始终致力于打造高性能AI+Cloud基础设施平台,积极推动AI应用的落地。达坦科技通过软硬件深度融合的方式,提供AI推理引擎和高性能网络,为AI应用提供弹性、便利、经济的基础设施服务,以此满足不同行业客户对AI+Cloud的需求。
公众号:达坦科技DatenLord
DatenLord官网:
https://datenlord.github.io/
知乎账号:
https://www.zhihu.com/org/da-tan-ke-ji
B站:
https://space.bilibili.com/2017027518
邮箱:info@datenlord.com
如果您有兴趣加入达坦科技Rust前沿技术交流群、硬件敏捷开发和验证方法学讨论群或AI Infra 交流群,请添加小助手微信:DatenLord\_Tech
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。