LLM API 网关工具：AxonHub
Nite 收录于 软件推荐最近我在 linux.do 里陆续收集了不少公益中转站。站点一多，就会碰到一个很现实的问题：我想把它们统一聚合起来，对外只暴露一个接口，再按需路由到不同的公益站去用。
这个需求不复杂，找工具时还是踩了点坑。试了一圈后，我最后留下的是 AxonHub。如果你也有类似需求，可以看看它。
1. 我的需求很简单
我需要的并不是什么特别复杂的企业级网关，而是一个够轻，处理多上游差异也灵活的聚合层：
- 对外统一一个接口
- 后面可以接多个不同的公益站
- 同一个模型名可以映射到不同站点里的真实模型名
- 最好还能方便地看日志和排查路由细节
看起来像是随便找个 API 网关就能做，真用起来还是细节决定体验。
2. 为什么我没有继续用 LiteLLM
我一开始先试了 LiteLLM。
LiteLLM 本身功能不差，生态也比较成熟，但对我来说它有两个明显问题：
第一，它是 Python 写的，整体偏重。我只是想做一个公益站聚合和简单路由，却要带上一套更重的运行时和依赖，心理负担会比较大。
第二，实际跑起来的响应也没到我满意的程度。对于这种本来就夹在客户端和上游之间的中间层，我更希望它尽量轻、尽量快，而不是自己先吃掉一截性能。
所以 LiteLLM 虽然能用，但不是我想要的那种“挂上就省心”的方案。
3. 为什么 New API 也不太适合我
后来我又试了 New API。
New API 的问题不在于不能多渠道，而在于它不太适合我现在这个场景：同一个对外模型名，需要映射到不同的上游模型名。
举个很典型的例子：
- 公益站 A 里的模型名叫
gpt-5.3 - 公益站 B 里的同一个模型，名字却叫
openai/gpt-5.3
对我来说，最理想的状态是：无论请求最终落到哪个公益站，对外都只写一个统一模型名。这样客户端配置更简单，脚本也不用跟着不同站点反复改。
这一点正好是 AxonHub 处理得比较舒服的地方。
4. AxonHub 为什么让我留下来了
AxonHub 最让我满意的地方，是它很贴合“多上游聚合 + 模型名映射”这个需求。
I. 模型映射处理得很顺手
我可以对外统一暴露一个模型名称，再把它分别映射到不同公益站各自使用的真实模型名。
这看起来只是一个小功能，但对聚合使用很关键。只要上游一多，命名风格不统一几乎是必然的。如果网关层不能把这件事处理好，后面维护起来只会越来越乱。
AxonHub 把这个问题解决得很直接。
II. 响应速度很快
这是我切过去之后感知最明显的一点。
作为中间层服务，AxonHub 给我的感觉就是够轻。转发和路由都很干脆，没有那种“又套了一层，所以慢半拍”的拖沓感。日常调用时，这点差别很明显。
III. 添加渠道方便
我手上的公益站来源比较杂，经常会增删调整。
如果每次加一个站、换一个站都要折腾半天配置，这个聚合器本身就成了负担。AxonHub 在这方面比较顺手，新增渠道和调整路由都轻松一些，适合我这种会不断收集和试用不同公益站的用法。
IV. WebUI 对排查问题很友好
另一个我很喜欢的地方是它的 WebUI。
AxonHub 可以在 WebUI 里实时看到请求日志和路由细节，这对排查问题很有帮助。比如某次请求到底走了哪个渠道、为什么命中了这个路由，基本都能很直观地看出来。上游返回了什么，也能直接看到。
这种可观测性对聚合服务很重要。不然一旦某个上游抽风，或者模型映射写错，排查成本会很高。规则没命中的情况也一样。
5. 它更适合哪类人
如果你的使用场景和我差不多，AxonHub 会比较合适：
- 手里有多个公益中转站或者多个上游 API
- 希望对外只保留一个统一入口
- 希望统一模型名称，不想让客户端感知各家站点的命名差异
- 想快速查看请求日志和具体路由过程
- 不想为了一个聚合层引入太重、太慢的方案
如果你最近也在折腾多个公益站的聚合，或者正好卡在模型名称映射上，可以看看 AxonHub：https://github.com/looplj/axonhub。对我来说，它是目前这类需求里用得最顺手的一套。