安装
EN中文
OmniLLM

Field Manual
Issue 01 · Rust Runtime

AI-native production library

面向 provider-neutral LLM 的 Rust 现场手册。

OmniLLM 为 Rust 团队提供一个统一运行时,覆盖 canonical generation、provider 原生 primitive API、协议转换、多 Key 负载均衡、限流、熔断、安全回放测试与 lock-free 预算追踪。

Usage Guide

从 canonical path 开始。

OmniLLM 默认路径刻意保持保守:一个类型化生成请求、一个 gateway、多个 provider 后端。应用代码围绕 LlmRequest 与 LlmResponse,运行时处理运维问题。

安装

添加 crate,配置 endpoint,并为每个 key 设置 label,方便生产环境理解 pool status。

请求

除非确实需要 raw provider payload,否则业务代码保持在 LlmRequest、Message、RequestItem 与 LlmResponse。

保护

让运行时接管 key selection、RPM pressure、timeout、circuit state、cancellation 与 budget reservation。

验证

使用 replay fixture 与 conversion report,让 provider 行为在发布前可审查。

默认非流式生成使用 Gateway::call;canonical streaming 使用 Gateway::stream。当产品需要 provider-neutral generation,而不是手写每个 provider adapter 时,这是首选入口。

gateway.rscanonical generation
let gateway = GatewayBuilder::new(ProviderEndpoint::openai_responses())
    .add_key(KeyConfig::new("sk-key-1", "prod-1").rpm_limit(500))
    .budget_limit_usd(50.0)
    .request_timeout(Duration::from_secs(45))
    .build()?;

let response = gateway.call(request, CancellationToken::new()).await?;

Architecture

两种模式,共用一套预算账本。

OmniLLM 提供规范化 canonical 模式与显式 primitive 模式。前者让生成行为可移植,后者为无法自然映射到单一生成 schema 的 provider API 保留原始请求与响应。

规范化应用契约;当 provider API 本身就是产品时,保留 provider 契约。OmniLLM protocol posture
Canonical ResponsesGateway::call 与 Gateway::stream 使用 LlmRequest、LlmResponse、LlmStreamEvent 做 provider-neutral generation。
Provider Primitiveprimitive_call、primitive_stream、primitive_realtime 为 Images、Audio、Realtime、Count Tokens、Gemini Live 与兼容包装器保留原生 payload。
共享预算账本两种模式都通过 BudgetTracker 结算,原始 provider usage 也参与预留与结算。
共享保护机制两种模式共享 key pool、RPM protection、timeout model 与 circuit state,不引入第二套执行栈。

Runtime Profiles

端点名称描述 wire shape。

运行时配置使用 EndpointProtocol;底层解析、发射与转码使用 ProviderProtocol。ClaudeMessages、GeminiGenerateContent 这类名称描述的是 wire shape,而不是营销偏好。

官方端点当 OmniLLM 需要从 host 或 prefix 推导标准 upstream path 时,使用官方端点变体。
兼容端点当上游 wrapper 已经暴露完整请求 URL 时,使用 *_compat 变体。
Wire formats在 OpenAI、Anthropic、Gemini 与兼容请求形态之间转换 raw API body 时使用 WireFormat。
Transport profileEndpointProtocol 选择运行时请求形态,应用代码仍保留 typed OmniLLM surface。
图 1. EndpointProtocol 选择运行时 profile;WireFormat 与 ProviderProtocol 描述转换和传输边界。

Native APIs

Primitive mode 保留 provider 原生 API。

Primitive 调用是显式增量能力。它适用于那些 provider 原生 API 契约就是产品行为一部分的场景。 PrimitiveRequest, primitive_call, primitive_stream, 以及 primitive_realtime 保持 primitive path 的增量语义,而不是把原始 provider API 强行塞进 canonical generation conversion。

primitive.rsraw provider payload
let request = PrimitiveRequest::json(
    ProviderPrimitiveKind::ImagesGenerate,
    serde_json::json!({
        "model": "gpt-image-1",
        "prompt": "A blueprint-style gateway diagram"
    }),
);

let raw = gateway.primitive_call(request, CancellationToken::new()).await?;

Conversion

损耗要报告,不能隐藏。

Transcoding 会通过 ConversionReport<T> 返回显式 bridge metadata。调用方可以检查 bridged、lossy 与 loss_reasons,而不是猜测哪些 provider-specific 字段被丢弃。

bridged

请求跨过了 provider format,而不是停留在 native shape。

lossy

至少有一个字段无法安全表示到目标 wire shape。

loss_reasons

可读原因让测试断言与运维日志可行动。

emit_transport_request

在分发前把 typed request 变成可检查的 method、path、headers 与 body。

transcode.rsbridge metadata
let report = transcode_api_request(
    WireFormat::OpenAiChatCompletions,
    WireFormat::OpenAiResponses,
    raw_chat,
)?;

assert!(report.bridged);
assert!(!report.lossy);
for reason in report.loss_reasons {
    tracing::warn!(%reason, "provider bridge dropped data");
}

API Reference

API surface 按使用意图分层。

把 API 当成多层结构来读:先用稳定的应用契约,再选择任务对应的 endpoint family;只有当原始 provider 契约本身很重要时才进入 primitive mode,并且每条调用路径都保留 transport、replay 与运维信号。

应用契约LlmRequest、Message、RequestItem、LlmResponse 与 LlmStreamEvent 让生成行为跨 provider wire format 保持可移植。
Gateway runtimeGatewayBuilder、ProviderEndpoint、KeyConfig、Gateway::call 与 Gateway::stream 把端点选择和 key pool、限流、timeout、cancellation、budget settlement 绑定在一起。
端点家族EmbeddingRequest、图像生成、音频转写、语音与 rerank request family 为文本生成之外的任务提供类型化 API。
Primitive APIsPrimitiveRequest 搭配 primitive_call、primitive_stream、primitive_realtime 保留原始 provider JSON、SSE、realtime 或 media payload。
Bridge 与 transportWireFormat、EndpointProtocol、ProviderProtocol、ConversionReport 与 emit_transport_request 让转换和 HTTP 发射可检查。
运维与测试pool_status、budget_remaining_usd、ReplayFixture、sanitizer helpers 与 OmniLLM error classes 让生产行为可审查。
Layer 01

Canonical generation contract

当业务代码需要 provider-neutral generation 与稳定响应处理时,使用这一层。

  • LlmRequest 承载 messages、model options、tools 与 provider-neutral generation intent。
  • Message、MessageRole、RequestItem 让聊天内容保持类型化,而不是到处传 raw JSON。
  • Gateway::call 返回非流式生成的 LlmResponse。
  • Gateway::stream 返回 canonical streaming 的 LlmStreamEvent。
Layer 02

Gateway construction and runtime policy

在发送第一条请求前,用这一层把 endpoint choice 绑定到运维控制。

  • GatewayBuilder 选择 ProviderEndpoint,并连接 key pools、budgets、retry posture 与 request timeout。
  • KeyConfig 为 key 设置 label、RPM limit,让 pool status 对运维可读。
  • CancellationToken 出现在每条调用路径,包括 streaming 与 primitive calls。
  • BudgetTracker 执行 pre-reserve 与 settlement,不引入第二套预算系统。
Layer 03

Typed non-generation endpoint families

当任务仍足够通用、值得抽象为 typed OmniLLM request family 时,使用这一层。

  • EmbeddingRequest 与 EmbeddingResponse 覆盖向量生成和 OpenAI-compatible embeddings emission。
  • 图像生成请求族让 media workload 共享 gateway key、timeout 与 budget controls。
  • 音频转写和语音请求族让媒体端点保持在同一套 runtime posture 中。
  • Rerank request family 表达检索排序,而不是把它伪装成文本生成。
Layer 04

Provider primitive APIs

当 provider API shape 本身就是产品契约、不能被规范化掉时,使用这一层。

  • PrimitiveRequest 承载 provider-native request payload,不经过 LlmRequest 或 ApiRequest conversion。
  • primitive_call 处理 images、audio、token counting、metadata 等一次性 provider-native API。
  • primitive_stream 在 canonical stream events 会丢细节时保留 provider-native SSE events。
  • primitive_realtime 面向 OpenAI Realtime 与 Gemini Live 这类 realtime transport。
Layer 05

Protocol bridge and transport emission

当你需要在 dispatch 前检查、测试或报告准确 wire shape 时,使用这一层。

  • EndpointProtocol 描述 runtime endpoint behavior;ProviderProtocol 描述低层 provider wire shape。
  • WireFormat 明确 transcode 的 source body format 与 target body format。
  • ConversionReport<T> 报告 bridged、lossy、loss_reasons,不隐藏降级行为。
  • emit_transport_request 暴露 method、path、headers、body,方便测试断言发射出的请求。
Layer 06

Operational and replay surfaces

用这一层把 gateway 行为转化成服务可观测行为。

  • pool_status 报告 key availability、limiter pressure、inflight work 与 circuit state。
  • budget_remaining_usd 展示 reservation 与 settlement 之后的剩余预算。
  • ReplayFixture 搭配 sanitizer helpers 生成安全 request/response fixture,用于 protocol regression tests。
  • NoAvailableKey、BudgetExceeded、Protocol(...) 区分 pool、spend 与 conversion failure。

Registry

Provider 覆盖按能力声明。

Provider 支持以端点能力与 primitive 能力表达,而不是宣称完整 SDK parity。这样 registry 能更准确地描述 transport shape、request path、response preservation 与 settlement 行为。

OpenAI / Azure OpenAICanonical Responses、Chat Completions 兼容、embeddings、images、audio、realtime primitives 与 OpenAI-compatible wrapper。
Anthropic ClaudeMessages wire shape、canonical generation bridge、tool/message conversion 与 primitive extension point。
Gemini / Vertex AIGenerateContent profile、Gemini-family wire conversion、Vertex-style deployment posture 与 Live API primitive scope。
Bedrock用于云上模型家族的 provider registry 集成与 runtime routing hook。
Compatible providers为已经暴露 OpenAI-shaped URL 或 provider-native proxy path 的 wrapper 提供明确 compat endpoint。

Testing

Fixture 要既有用又安全。

Record/replay 测试需要可审查且不泄露密钥的工件。OmniLLM 提供 ReplayFixture、sanitize_transport_request、sanitize_transport_response 与 sanitize_json_value 来支持安全 fixture 工作流。

  1. 只在受控集成运行中记录真实 transport request 与 response。
  2. 脱敏 auth header、query token、JSON secret,以及大体积 binary/base64 字段。
  3. 把 fixture diff 当成 API contract 审查,而不是不透明 snapshot。
  4. 修改 protocol bridge 或 provider profile 前,先用 deterministic fixture replay。
replay.rssanitized fixture
let sanitized = sanitize_transport_request(recorded_request);
let fixture = ReplayFixture::from_transport(sanitized, response);
fixture.write_json("tests/fixtures/openai_responses.basic.json")?;

Operations

运行时状态应当出现在接口里。

生产服务可以检查 gateway.pool_status() 与 gateway.budget_remaining_usd()。这些接口暴露 Key 可用性、inflight token pressure、RPM pressure、circuit state,以及预留与结算后的剩余预算。

pool_status()展示 key availability、limiter pressure、circuit state,以及当前 pool 是否还能接收更多工作。
budget_remaining_usd()报告 reservation 与 settlement 后的剩余预算,让运维看到真实 spend pressure。
NoAvailableKey表示 pool exhaustion、cooldown 或 circuit-open,而不是 provider protocol failure。
BudgetExceeded表示 spend policy 在分发前或结算过程中阻止了请求。
Protocol(...)表示 bridge、parsing、emission 或 provider wire-shape mismatch。

信号请求失败时,OmniLLM-specific errors 会告诉运维问题属于 pool availability、spend policy 还是 protocol conversion。

Production

上线前,先明确运行契约。

运行时提供基础能力,但生产可用性来自把预算、取消、回放与 provider 行为显式放进服务边界。

  1. 优先为可移植生成选择 canonical protocol,再决定是否进入 provider primitive。
  2. 为每个生产 Key 配置明确 label、RPM 限制、冷却行为与预算假设。
  3. 所有 gateway 路径都使用 CancellationToken 与 request timeout,包括 primitive 和 stream。
  4. 把 ConversionReport 纳入协议转码验收标准,不要默认所有字段都能无损桥接。
  5. 回放夹具必须先脱敏 auth header、query secret 与大体积二进制字段。
  6. 上线前把 pool_status、budget_remaining_usd 与 OmniLLM 错误类别暴露给运维。

AI-native Project

Skill 会教 agent 使用真实库边界。

内置 OmniLLM Skill 给 coding agent 仓库级信号,而不是泛泛的 Rust SDK 猜测。它围绕 GatewayBuilder、ProviderEndpoint、EndpointProtocol、WireFormat、ReplayFixture、primitive calls 与 OmniLLM runtime errors 调优。

  1. 把 Skill 安装到 Claude Code、Codex、OpenCode 或兼容 Claude Skill 的运行器。
  2. 让 agent 协助 gateway setup、endpoint selection、protocol transcoding、replay fixture generation 或 OmniLLM error debugging。
  3. 用真实 examples、tests、endpoint profiles、conversion reports 与 runtime surfaces 校验回答。
install.shruntime + skill
# Codex / Claude Code / OpenCode
npx @vercel-labs/skills install github:aiomni/omnillm/skill

# Rust runtime
cargo add omnillm
OL

关于这份手册。 这份 Field Manual 把 OmniLLM 的运行时、协议桥接、provider primitive 支持、回放夹具、文档与内置 Skill 汇总成一个面向 Rust 团队的生产接入入口。