AI聚合网关之三:NewAPI、LiteLLM 和自研原生 Adapter 的边界

• URL: https://mp.weixin.qq.com/s/0OV6RLdfpY33b2JXF8t01Q
• Date Saved: 2026-07-02
• Source: WeChat
• Tags: ai-engineering, dev-tools, business

Summary

本文系统性地讨论了企业级 AI Token 聚合平台中，Provider Adapter 的选型边界。核心观点：NewAPI、LiteLLM、自研 Adapter 不是互斥选择，而是分属不同责任层。

四层责任架构

1. 商业平台控制面 — 用户/租户/OEM/API Key/钱包/账本/对账/审计（自研）
2. 执行代理层 — 多 provider 执行、route alias、fallback、spend evidence（LiteLLM）
3. 通用网关 — 快速聚合、面板、额度、日志（NewAPI）
4. 原生能力接入 — provider native usage/task/media（自研 Adapter）

三种工具定位

• NewAPI — 通用 AI 网关面板，适合快速搭建、内部工具、MVP。不适合承担商业平台责任（OEM分销、多级结算、客户账本）
• LiteLLM — 多 provider 执行代理，适合平台已有控制面后接多上游。spend log 只是证据不是最终账本
• 自研原生 Adapter — 当 provider 原生字段影响计费、风控、异步任务、素材交付时必须自研

必须自研 Adapter 的信号

• 原生 usage 口径影响计费（如 Gemini usageMetadata）
• 请求不是同步响应（视频生成任务、callback）
• 响应不是 OpenAI 结构（如 Gemini inlineData）
• provider feature 需要门禁（grounding、imageSize、region）
• 需要素材转存和安全处理
• 上游凭证和回调必须隔离

决策树

1. 只是内部转发？→ NewAPI
2. 已有用户/钱包/账本？→ 执行层用 LiteLLM
3. provider 能力能被 OpenAI-compatible 准确表达？→ LiteLLM facade
4. provider 原生 usage/cache/media/task 影响计费？→ 自研 Adapter
5. 需要异步任务/callback/素材转存？→ 必须自研 Adapter + 状态机

常见五个错误

1. 把三种方案当互斥选择（实际可组合）
2. 把 OpenAI-compatible 当万能协议（cache TTL、视频任务、callback 无法统一）
3. 把代理层 spend 当客户账本（必须由平台 usage log 生成）
4. 新模型上线就承诺 full native compatibility（应按 GA/Beta/Unsupported 管理）
5. 自研 Adapter 只写 HTTP client（真正成本在凭证隔离、状态机、计费证据）

与 tenkapo.ai 的关联

文章出自 AetherSpace 团队，其架构选择与 tenkapo.ai 的”原生协议透传”理念高度一致——都认为 OpenAI-compatible 转换层（如 LiteLLM）无法覆盖所有 provider 原生语义，关键能力必须保留 native shape。