AI Model Aggregator
One API Across Models and Hosting Providers什么是 AI 模型聚合器？用一个 API 连接模型与托管商
An AI model aggregator combines access to multiple models and hosting providers behind a shared API, catalog and billing layer. Its value comes from normalized operations and provider choice—not from pretending every model or endpoint is identical.
AI 模型聚合器把多个模型与托管供应商的访问组合在共享 API、目录与计费层之后。其价值来自统一运营与供应商选择，而不是假设所有模型或端点完全相同。
TL;DR
The catalog may combine different model creators, hosting providers, endpoint versions, regions and commercial terms.
One authentication, request envelope, catalog, routing policy, usage view and billing relationship reduce integration work.
Model, endpoint and provider are distinct. A trace should identify all three plus version, region, policy and price unit.
The aggregator controls translation, routing, fallback, metering and sometimes billing; each function needs evidence and an exit path.
目录可组合不同模型创建者、托管供应商、端点版本、区域与商业条款。
统一认证、请求封装、目录、路由策略、用量视图与账单关系可减少集成。
模型、端点与供应商不同。调用链应识别三者以及版本、区域、策略与计价单位。
聚合器控制转换、路由、回退、计量，有时还负责计费；每项功能都需要证据与退出路径。
The aggregation flow from catalog to ledger从目录到账本的聚合流程
The aggregator ingests model and provider metadata, exposes eligible endpoints in a catalog, accepts a normalized request, selects an endpoint, translates the payload, executes the call, and records usage. Fallback may try another endpoint for the same model or a different model according to policy.
Aggregator 导入模型与 Provider 元数据，在目录中暴露合格端点，接受标准化请求、选择端点、转换 Payload、执行调用并记录用量。Fallback 可以按策略尝试同一模型的另一端点，也可以切换到不同模型。
Catalog size is not verified coverage. Two entries with the same public model name may use different snapshots, quantization, context limits, tool support, safety settings, regions, data policies, throughput, or prices. Every route needs a timestamped identity record: provider of record, model and version, endpoint, supported features, lifecycle, region, privacy policy, billing unit, and last successful conformance test.
目录规模不等于经过验证的覆盖。两个使用相同公开模型名称的条目，可能采用不同 Snapshot、Quantization、上下文限制、工具支持、安全设置、区域、数据策略、吞吐或价格。每条路由都需要带时间戳的身份记录，包括合同 Provider、模型与版本、端点、支持功能、生命周期、区域、隐私策略、计费单位与最近一次 Conformance Test 结果。
A robust aggregator retains native request IDs, usage, errors, and route evidence beside normalized data. It monitors endpoint health and lifecycle, but does not silently substitute an unapproved provider, model version, data policy, or price unit. If policy permits fallback, the response should expose the candidate set, exclusion reasons, chosen route, attempts, transformations, and final provider so operators can explain both behavior and billing.
健壮的 Aggregator 会把原生 Request ID、用量、错误与路由证据同标准化数据并存。它监控端点健康与生命周期，但不会静默替换未批准的 Provider、模型版本、数据策略或计价单位。如果策略允许 Fallback，响应应暴露候选集合、排除原因、最终路由、尝试、转换与最终 Provider，使运营人员能够解释行为与账单。
Core aggregation functions核心聚合功能
| Function功能 | Best fit最适合 | Verify before choosing选择前验证 |
|---|---|---|
| Unified API统一 API | One client contract across models and providers reduces SDK and credential sprawl.跨模型与供应商使用一个客户端契约，减少 SDK 与凭证蔓延。 | Compatibility is a tested subset; keep capability flags and native parameter escape hatches.兼容性是经测试的子集；保留能力标记与原生参数出口。 |
| Model catalog模型目录 | Searchable metadata for models, endpoints, modalities, context, parameters, regions and price.为模型、端点、模态、上下文、参数、区域与价格提供可搜索元数据。 | Catalog entries must be versioned, sourced, freshness-tagged and verified before routing.目录项必须版本化、标注来源与新鲜度，并在路由前验证。 |
| Provider routing供应商路由 | Select among eligible hosting endpoints by policy, price, latency, capacity or privacy.按策略、价格、延迟、容量或隐私在合格托管端点间选择。 | Record the eligible set, score, selected endpoint, reason and provider identity.记录合格集合、评分、所选端点、原因与供应商身份。 |
| Fallback回退 | Retry an allowed alternate endpoint after bounded, eligible failures.在有边界且符合条件的失败后重试获准备用端点。 | Define deadlines, attempts, substitutions, streams, duplicate risk, charges and final errors.定义截止时间、尝试、替换、流、重复风险、费用与最终错误。 |
| Usage and billing用量与计费 | Normalize usage, consolidate invoices and allocate cost by tenant, app, model and provider.标准化用量、合并账单，并按租户、应用、模型与供应商分配成本。 | Preserve native units, markup, credits, retries and provider receipts for reconciliation.保留原生单位、加价、Credits、重试与供应商回执供核对。 |
Model aggregation requires provenance模型聚合需要来源证据
Creator, family, exact version, release, modality, context, capabilities, license and deprecation.
Hosting provider, endpoint version, region, runtime, quantization, capacity, data policy and health.
Policy version, eligible set, scores, route reason, fallback chain, cache and guardrail results.
Native usage, normalized usage, price version, unit, markup, credits, platform fee and final receipt.
创建者、家族、具体版本、发布、模态、上下文、能力、许可与弃用。
托管供应商、端点版本、区域、运行时、量化、容量、数据策略与健康。
策略版本、合格集合、评分、路由原因、回退链、缓存与护栏结果。
原生用量、标准化用量、价格版本、单位、加价、Credits、平台费与最终回执。
Verify the aggregation contract验证聚合契约
Test aggregation at two levels. Conformance tests prove that an endpoint preserves required request, response, streaming, tool, schema, error, and usage behavior. Workload evaluations prove that the eligible routes meet the application's quality, latency, policy, and cost targets. A route should not enter production selection merely because its health check returned 200.
聚合应分两层测试。Conformance Test 证明端点保留了必需的请求、响应、Streaming、Tool、Schema、错误与用量行为；工作负载评测则证明合格路由达到应用的质量、延迟、策略与成本目标。不能仅因为 Health Check 返回 200，就让一条路由进入生产选择。
- Pin exact models and endpoints for chat, tools, structured output, streams, embeddings, image, audio, and other multimodal workloads.
- Compare aggregator and direct-provider payloads, outputs, events, finish reasons, errors, headers, usage, latency, and bills.
- Force provider failure, parameter mismatch, privacy restriction, region exclusion, quota exhaustion, model retirement, alias change, and price change.
- Verify fallback stays inside the approved capability and policy set and does not reset the parent deadline or attempt budget.
- Check catalog freshness, health-check accuracy, route provenance, BYOK behavior, data logging, invoice reconciliation, and support escalation evidence.
- Export catalog, policy, routes, usage, and traces; canary direct rollback without losing application identity or conversation state.
- 为对话、工具、结构化输出、流、Embedding、图像、音频及其他多模态负载固定准确模型和端点。
- 比较 Aggregator 与 Provider 直连的 Payload、输出、事件、Finish Reason、错误、Header、用量、延迟与账单。
- 强制 Provider 故障、参数不匹配、隐私限制、区域排除、配额耗尽、模型退役、别名变化与价格变化。
- 验证 Fallback 始终处于批准的能力与策略集合内，并且不会重置父截止时间或尝试预算。
- 检查目录新鲜度、Health Check 准确性、路由来源、BYOK 行为、数据日志、账单对账与支持升级证据。
- 导出目录、策略、路由、用量与 Trace，并灰度直连回滚，不丢失应用身份或 Conversation 状态。
Keep internal aliases above external aggregation在外部聚合之上保持内部别名
Applications request a stable internal workload alias and declare required capabilities. Your registry maps it to approved aggregator models and endpoints. The aggregator may route only within that eligible set. Store internal alias, aggregator route and native provider IDs together. This preserves portability without discarding supply flexibility.
应用请求稳定内部工作负载别名并声明所需能力；内部注册表把它映射到获批聚合模型与端点；聚合器只能在该合格集合内路由。同时存储内部别名、聚合器路由与原生供应商 ID，在保留供给灵活性的同时保持可移植性。
Production rule: aggregation is trustworthy when normalization is explicit, provenance survives routing, and billing can be reconciled to native evidence.
生产规则：当标准化显式、来源穿过路由且账单能与原生证据核对时，聚合才可信。
Model aggregation and capability aggregation differ模型聚合与能力聚合不同
A model aggregator unifies inference supply. QVeris unifies discovery and execution of external capabilities such as APIs, tools, services and live data. In an agent stack, the aggregator supplies reasoning and QVeris supplies governed action.
模型聚合器统一推理供给；QVeris 统一 API、工具、服务与实时数据等外部能力的发现和执行。在智能体技术栈中，聚合器提供推理，QVeris 提供受治理行动。
FAQ
It combines access to multiple models and often multiple hosting providers behind shared catalog, API, routing, usage and billing functions.
An aggregator emphasizes supply and catalog; a gateway emphasizes traffic control. Many products implement both.
Opaque endpoint substitution that changes capability, policy, quality or cost without sufficient evidence or approval.
把多个模型以及通常多个托管供应商的访问组合在共享目录、API、路由、用量与计费功能之后。
聚合器强调供给与目录，网关强调流量控制；许多产品同时实现两者。
不透明端点替换在证据或审批不足时改变能力、策略、质量或成本。