为什么我们做了AIMA：一个用AI管理AI推理的开源项目

反复帮人装模型

2025年开始，不少硬件厂商和客户找过来，说对我们的模型管理平台感兴趣。

原因很直接：界面好用，以模型为中心，点一下就能跑起来，门槛低。有些客户愿意付费让我们帮他们也部署一套。

但那个平台最初是为特定硬件设计的。NVIDIA的卡、华为的昇腾、海光的DCU、AMD的ROCm，每种硬件的驱动、设备挂载、环境变量、安全上下文全都不一样。每适配一种新硬件都要写大量代码，痛苦得很。

更痛苦的是后面。客户隔三差五来找我们：帮我把最新的模型适配一下，帮我把引擎升级一下。无论平台卖多少钱，最后还是要不断投人工去维护。

我开始想：大家到底为什么需要这样一个平台？绕来绕去，答案总是回到同一个地方——TCO，总拥有成本。

三个月蒸发一半

AI的迭代速度太快了。

三个月内能冒出十个以上的新模型。花几十万买一台AI服务器，调好了，跑着当前最好的模型。不动它。三个月后，新模型比最初那个强差不多一倍。设备价值直接腰斩。

再加上推理引擎的进展——vLLM、SGLang、llama.cpp每个版本都在榨取更多性能——差距还会拉大。六个月不升级，跟业内最佳水平比，可能只剩三成左右的价值。

硬件没坏，但价值在跌。

我们之前那个平台，开箱即用没问题，一旦要导入最新的模型、适配引擎变化，软件就跟不上了。新东西还没出来，你不知道它长什么样，引擎会不会调整API，硬件驱动会不会突然更新。没办法向未来兼容。

中庸的代价

有人会说：Ollama、LM Studio不是挺好的吗？一行命令或一个APP，模型下载就能用。

我的看法是，这是过去时代里的一种无奈选择。

想降低TCO，很多时候不得不同时降低设备的实际性能。为了更兼容、更易用，这些工具做了大量中庸的预设。比如Ollama，一键启动没问题。但你想调推理引擎的高级参数，想上更多并发？会遇到卡点。

一个vLLM的推理引擎有几十个高级参数。有些参数开和不开之间差50%的性能。不同版本行为还不一样，不同模型最优值也不同。你没有在真实硬件上跑过一遍，根本不知道什么情况。

降低TCO和维持SOTA性能，在这些方案里是冲突的。

AIMA想解决什么

AIMA想做的事情说起来很简单：让设备在各种场景下尽可能跑出SOTA性能，同时把TCO压到接近硬件本身加电费。

做起来当然不简单。这是一个四维的最优解问题——硬件、推理引擎、模型、应用，四个维度都在快速变化，排列组合极其复杂。

AIMA的做法是把自己做成一个薄的基础设施层。一个Go二进制，跨平台编译，零CGO依赖，装上就能用。

# 检测硬件
aima hal detect
 
# 初始化基础设施
sudo aima init
 
# 部署模型（自动匹配引擎和配置）
aima deploy apply --model qwen3.5-35b-a3b

三条命令，从裸机到模型推理跑通。背后发生了什么？AIMA检测到你的GPU型号和显存，从YAML知识库里匹配到最优的引擎和参数配置，生成K3S Pod声明，拉起推理服务。整个过程不需要你知道该用vLLM还是llama.cpp，不需要你手动配置CUDA路径或者ROCm设备挂载。

目前已经跑通的硬件包括NVIDIA RTX 4060/4090/GB10、AMD Radeon 8060S和Ryzen AI MAX+ 395、华为昇腾910B、海光BW150 DCU、Apple M4。引擎方面支持vLLM、llama.cpp、SGLang、Ollama。

知识，不是代码

AIMA的做法是：知识胜于代码。

传统做法，每支持一种新硬件或新引擎，就写一堆if-else分支。AIMA不这么干。硬件特征、引擎参数、模型配置，全部定义在YAML文件里。Go代码只做数值比较和通用渲染，不包含厂商分支。

支持一个新引擎？写一份YAML。支持一个新模型？也是写YAML。80%的能力扩展不需要重新编译。

知识库里的内容长这样：每个模型有多个variant，每个variant标注了适用的GPU架构、最低显存要求、推理引擎类型、具体的启动参数。AIMA的ConfigResolver根据你当前的硬件状态，自动匹配到最合适的那个variant。如果你的RTX 4060只有8GB显存，它会跳过需要16GB的vLLM方案，自动落到llama.cpp的GGUF方案。

这些过去散落在各种论坛帖子、GitHub issue、个人笔记里的碎片知识，现在有了一个统一的结构化表达。谁都可以贡献一份YAML，谁都可以复用别人验证过的配置。

57个MCP工具

AIMA暴露了57个MCP工具，覆盖硬件检测、模型管理、引擎管理、部署、知识库、基准测试、集群管理等所有功能。

为什么这件事重要？因为MCP是AI Agent操作外部工具的标准协议。把所有功能都做成MCP工具，意味着任何MCP Client——Claude Code、GPT、自己写的Agent——都可以直接操控这台设备上的一切。

CLI是MCP工具的薄包装，不包含任何额外逻辑。人用CLI，Agent用MCP，走的是完全相同的代码路径。

名字里"Managed by AI"说的就是这个。AIMA内部没有塞一个大模型在跑，而是把自己变成了AI Agent可以直接操控的基础设施。Agent检测硬件、查知识库、部署模型、跑benchmark、看结果、调配置，整个循环转起来不需要人参与。

渐进智能

AIMA有一个我觉得挺有意思的设计：不是所有场景都有AI可用，所以做了五档渐进智能。

最底下是L0。YAML知识库的默认值，编译时就嵌入在Go二进制里。没网、没AI、什么都没有，L0也能给你一个能用的推理服务。不会是最优的，但能兜底。

往上L1，人可以通过CLI手动覆盖参数。再往上L2，基于历史基准测试的黄金配置——这台硬件上跑过的最优参数组合，从benchmark数据里沉淀下来，下次直接复用。

到L3a，设备本身的算力够强的话，内置的Go Agent可以用本地模型做简单的工具调用循环，自己做一些决策。最高的L3b，接入外部的强力Agent（比如Claude），可以做复杂的调优、排障、探索。

每层独立可用。从L0往上，逐层递增，逐层覆盖。拿到一台新设备，哪怕从L0开始用，随着知识积累和网络接入，它能自己往上走。

这里面有一个设计叫"探索即知识"：Agent每次做的探索——调参、排障、部署尝试——都会产出结构化的Knowledge Note，写回知识库。其他设备的Agent可以直接复用这些知识，跳过已知的失败路径，从最优起点开始。

用的设备多了，沉淀的知识就多，后来的设备就好用。这个循环的投入是token和闲时算力，产出是越来越厚的知识库。

局域网即集群

还有一个我觉得值得提的：Fleet管理。

AIMA用mDNS做局域网自动发现。你在办公室放了五台不同硬件的AI设备，不需要配置IP，不需要注册中心，它们自己就能互相发现。

# 发现局域网里的AIMA设备
aima discover
 
# 远程执行工具
aima fleet exec <device-id> hardware.detect
aima fleet exec <device-id> deploy.list

每台设备暴露的都是同一套MCP工具，远程和本地走同样的路径。对Agent来说，管一台和管一群没什么区别。

少写代码

最后说说设计哲学。

AIMA的Go代码有几条硬约束：不为引擎类型写代码分支，不为硬件厂商写代码分支。引擎行为、模型元数据、硬件的容器访问配置，都在YAML里。

容器的生命周期K3S管，GPU显存的切分HAMi管。AIMA做的事很窄：从知识生成Pod YAML，kubectl apply，查询状态。

代码少了，AI理解项目就容易，改东西也不烧那么多token。当AI越来越强，尽可能少的代码反而成了优势——AI能更流畅地参与到这个项目里来。

开源

AIMA在GitHub上开源，Apache 2.0协议。一个Go二进制，跨平台编译，拿来就能用。

我们还会配套一个AIMA Service，设备遇到问题可以远程解决。两者加在一起，目标是把AI推理设备的TCO压到接近硬件加电费加一点token钱。