🤖 AI

LLM-Rosetta: A Hub-and-Spoke Intermediate Representation for Cross-Provider LLM API Translation

LLM-Rosetta 是一种基于中心辐射型中间表示（IR）的开源框架，通过构建统一的语义核心模型，实现了不同大语言模型 API 之间的高效、无损双向转换，从而解决了多供应商生态中的碎片化与耦合问题。

原作者： Peng Ding

发布于 2026-04-13

📖 1 分钟阅读☕ 轻松阅读

原作者： Peng Ding

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

这篇论文介绍了一个名为 LLM-Rosetta（LLM 罗塞塔）的新工具。为了让你轻松理解，我们可以把它想象成解决“语言不通”问题的超级翻译官。

1. 背景：一个混乱的“方言”世界

想象一下，现在的 AI 大模型（比如 OpenAI 的 GPT、Anthropic 的 Claude、Google 的 Gemini）就像是一群住在不同国家的邻居。

问题：虽然他们都能听懂人话（核心逻辑一样），但每个人说话用的方言（API 格式）完全不同。
- OpenAI 说：“请给我发一个包含 messages 的包裹。”
- Anthropic 说：“请给我发一个包含 contents 的包裹，而且系统提示语要单独放。”
- Google 说：“我的包裹里全是 parts，而且格式又不一样。”
后果：如果你想开发一个能同时使用这些 AI 的应用，你就得雇佣 N 个翻译。如果有 4 个 AI 提供商，你就需要 $4 \times 3 = 12$ 种两两互译的“方言字典”。如果以后来了第 5 个、第 10 个，翻译的工作量会呈爆炸式增长（这就是论文里说的 $O(N^2)$ 问题）。

2. 核心创意：建立“世界语” (中间表示 IR)

LLM-Rosetta 的聪明之处在于，它没有试图去背所有方言之间的字典，而是发明了一种**“世界语”**（论文中称为 Intermediate Representation, IR）。

Hub-and-Spoke（轮辐式）架构：
- 想象一个巨大的中央枢纽（Hub），这里只说“世界语”。
- 所有的 AI 提供商（Spokes）都只需要学会两件事：
  1. 怎么把自家的方言翻译成“世界语”。
  2. 怎么把“世界语”翻译回自家的方言。
- 好处：如果有 100 个 AI 提供商，你只需要写 100 个翻译器，而不是 $100 \times 99$ 个。工作量从爆炸变成了线性增长。

3. 这个“世界语”长什么样？

论文发现，虽然各家 API 的“包装纸”（语法）千奇百怪，但里面的核心内容其实大同小异。LLM-Rosetta 把核心内容归纳为两类：

9 种内容块：比如纯文本、图片、音频、工具调用（让 AI 查天气）、推理过程（AI 的思考痕迹）等。
10 种流式事件：就像看直播一样，AI 是一字一句蹦出来的。这个系统能精准地处理这些“蹦字”的过程，确保不会乱序或丢字。

4. 它是如何工作的？(模块化积木)

LLM-Rosetta 不像是一个笨重的翻译机，它更像是一个乐高积木工厂。

它把翻译工作拆成了四个独立的模块（Ops）：
- 内容模块：处理文字、图片怎么变。
- 消息模块：处理谁在说话（用户、助手、系统）。
- 工具模块：处理 AI 怎么调用外部功能。
- 配置模块：处理温度、随机性等参数。
优势：如果 OpenAI 明天改了个参数，你只需要换掉“配置模块”那块积木，其他部分完全不用动。这让系统非常灵活，容易维护。

5. 它有多厉害？(实测表现)

无损翻译：它能把 OpenAI 的格式翻译成 Anthropic 的格式，再翻译回 OpenAI，内容分毫不差（就像把一杯水倒进杯子，再倒回瓶子，水没少也没变味）。
速度极快：翻译过程只需要几十微秒（百万分之一秒）。这比网络传输的时间短得多，几乎感觉不到它的存在。
流式支持：它不仅能翻译整段话，还能在 AI“打字”的过程中实时翻译，就像同声传译一样流畅。
真实应用：它已经在美国阿贡国家实验室的超级计算机项目中投入使用了，用来连接不同的 AI 模型。

6. 总结：为什么这很重要？

以前，如果你想让应用同时支持多个 AI，你得写一堆复杂的“胶水代码”，一旦某个 AI 升级，你的代码就崩了。

LLM-Rosetta 就像是一个通用的“万能插头转换器”：

不管你的电器（应用）是什么插头，也不管墙上的插座（AI 提供商）是什么形状。
只要插上这个转换器，你的电器就能在任何插座上工作。
而且，它还能让你自由地切换插座，而不用担心电器坏掉。

这篇论文证明了，虽然 AI 厂商的接口五花八门，但只要我们抓住它们共同的“灵魂”（语义核心），就能用一套简单的规则打通所有壁垒，让 AI 生态真正变得互联互通。

1. 研究背景与问题 (Problem)

随着大语言模型（LLM）提供商（如 OpenAI, Anthropic, Google 等）的迅速增加，每个提供商都暴露了专有的 API 格式。这导致了一个碎片化的生态系统，应用程序被紧密耦合到特定的供应商上。

核心痛点： $O(N^2)$ 适配问题
如果有 $N$ 个提供商，要在它们之间进行互操作，朴素的方法需要构建 $N(N-1)/2$ 个双边适配器（Bilateral Adapters）。每个适配器都需要处理请求构建、响应解析、流式事件映射和工具调用序列化。随着 API 的演变，维护这些适配器的成本极高。
现有方案的局限性
- 应用层框架 (如 LangChain)：在应用逻辑层抽象，但未提供底层的原始 API 负载转换层。
- SDK 代理 (如 LiteLLM)：通常将其他提供商的格式转换为单一提供商（通常是 OpenAI Chat Completions）的格式作为“通用语”。这种方法会丢失目标格式特有的功能（如 Anthropic 的缓存控制或 Google 的接地元数据），且无法实现真正的双向无损转换。
- 缺乏通用线格式：目前缺乏一个通用的、中立的中间格式来统一这些差异。

2. 核心方法论 (Methodology)

LLM-Rosetta 提出了一种基于**“中心 - 辐条” (Hub-and-Spoke)** 模式的中间表示（Intermediate Representation, IR）架构，将 $O(N^2)$ 的适配复杂度降低为 $O(N)$ 。

2.1 核心洞察

尽管各提供商的 API 在语法（字段命名、嵌套深度、内容编码）上存在显著差异，但它们在语义核心上是高度一致的。主要的挑战在于处理语法变异的组合表面，而非深层的语义不兼容。

2.2 中间表示 (IR) 设计

LLM-Rosetta 定义了一个供应商中立的 IR，旨在捕获所有主要提供商共享的语义核心：

9 种内容类型 (Content Parts)：包括文本、图像、音频、文件、工具调用、工具结果、推理痕迹 (Reasoning)、拒绝 (Refusal) 和引用 (Citation)。
10 种流式事件类型 (Stream Events)：涵盖流开始/结束、内容块开始/结束、文本增量、推理增量、工具调用开始/增量、完成原因及用量统计。
模块化结构：IR 包含消息、工具定义、生成配置、请求/响应等模块，支持双向转换。

2.3 Ops-Composition (操作组合) 转换器架构

为了避免单体类（Monolithic Class）带来的逻辑耦合，LLM-Rosetta 将转换逻辑分解为四个正交的模块（Ops），每个提供商的转换器由这四个模块组装而成：

ContentOps：处理原子内容单元（如图片编码、工具调用格式）的转换。
MessageOps：处理消息序列、角色映射（如 System/User/Assistant）及多轮对话结构。
ToolOps：处理工具定义和工具选择配置。
ConfigOps：处理生成参数（温度、Top-P）、推理设置和缓存配置。

这种设计使得添加新提供商只需实现特定的 Ops 模块，而无需修改 IR 或现有转换器。

2.4 流式处理与状态管理

针对各提供商 Server-Sent Events (SSE) 格式的差异（如 OpenAI 的 delta 块、Anthropic 的显式块生命周期、Google 的累积部分），LLM-Rosetta 引入了 StreamContext 状态管理器。它维护当前块索引、工具调用 ID 映射和累积缓冲区，确保即使提供商乱序发送事件，也能正确重组和转换流式数据。

3. 主要贡献 (Key Contributions)

API 差异的实证分析：证明了四大主流 LLM 提供商共享一个可被 9 种内容类型和 10 种流事件捕获的语义核心，主要难点在于语法变异的组合。
类型化的 IR 与模块化架构：提出了一个供应商中立的 IR 和 Ops-Composition 架构，实现了每个适配器开发成本与现有提供商数量无关（ $O(1)$ 增量成本）。
双向无损转换与流式支持：实现了请求和响应的双向转换（Provider $\leftrightarrow$ IR $\leftrightarrow$ Provider），支持分块级流式翻译，并提供“保留模式”（Preserve Mode）以保留特定元数据，实现无损往返。
实证评估与生产部署：通过 1,364 个测试用例验证了转换的保真度，并在 Argonne 国家实验室的 Argo-Proxy 生产环境中部署。

4. 实验结果 (Results)

4.1 转换保真度 (Round-Trip Fidelity)

测试规模：包含 1,364 个测试用例（987 个转换器级单元测试 + 377 个 IR 及逻辑测试）。
结果：在“保留模式”下，所有往返测试均实现了字段级的无损相等（Lossless Field-level Equality）。在“剥离模式”下，特定元数据被丢弃，但所有语义相关字段均被保留。
合规性：通过了 Open Responses 合规套件的所有 6 项测试。

4.2 跨提供商翻译 (Cross-Provider Translation)

测试了所有 6 种提供商对（如 OpenAI Chat $\leftrightarrow$ Anthropic, Google $\leftrightarrow$ Responses 等）。
结果：语义内容（消息文本、角色、工具参数、图像数据）在所有配对中均得到保留。
局限性：对于目标格式中不存在的功能（如 Anthropic 的缓存控制），会在转换过程中静默丢弃（并记录警告），但核心语义不受影响。

4.3 性能开销 (Performance Overhead)

延迟：转换开销极低。简单文本请求的往返转换中位数为 21-24 $\mu s$ ，复杂多轮对话约为 71-77 $\mu s$ 。95 百分位延迟低于 115 $\mu s$ 。
对比 LiteLLM：
- LiteLLM 采用单程转换（OpenAI $\to$ 目标），LLM-Rosetta 采用双程转换（OpenAI $\to$ IR $\to$ 目标）。
- 对于简单文本，LLM-Rosetta 甚至更快（24 $\mu s$ vs 28 $\mu s$ ）。
- 对于复杂场景，LLM-Rosetta 有 1.6-2.2 倍的开销，但绝对值仍在亚毫秒级（<100 $\mu s$ ），相对于网络延迟（50-500 ms）和推理延迟（100 ms+）可忽略不计。
- 优势：LLM-Rosetta 提供了 LiteLLM 不具备的双向性、供应商中立性和无损往返能力。

5. 意义与影响 (Significance)

解决互操作性难题：LLM-Rosetta 为 LLM 生态系统提供了一个通用的“罗塞塔石碑”，使得应用程序可以轻松地在不同提供商之间切换或桥接，而无需重写代码。
生产级验证：在 Argonne 国家实验室的 Argo-Proxy 中，LLM-Rosetta 替换了约 2,000 行手写映射代码，支持了 OpenAI、Anthropic 和 Google 的统一接入，证明了其在生产环境中的稳定性和可扩展性。
架构创新：提出的 Ops-Composition 模式为处理异构 API 转换提供了一种模块化、可测试且易于维护的新范式，避免了传统单体适配器的复杂性。
未来扩展性：由于大多数新兴提供商（如 Cohere, Mistral, xAI）都采用上述四种标准格式之一，LLM-Rosetta 可以立即支持它们。对于非标准格式，其 provider_extensions 机制提供了灵活的扩展空间。

总结：LLM-Rosetta 通过引入一个精心设计的中间表示（IR）和模块化转换器架构，成功将 LLM API 转换的复杂度从二次方降低为线性，实现了高效、无损且双向的跨提供商互操作性，是构建下一代多模型 LLM 应用的关键基础设施。