If LiteLLM answers “which model should respond?”, QVeris answers “which verified capability should the agent call?”
如果 LiteLLM 回答的是 “该调用哪个模型？”，QVeris 回答的是 “Agent 该调用哪个已验证能力？”
Why This Comparison Gets Misread
为什么这个对比容易被误读
Most “vs” searches assume two products compete for the same slot. That is not the right mental model here. LiteLLM provides a Python SDK and a self-hostable Proxy Server for model traffic. Its current official documentation covers OpenAI-format access across providers, provider adapters, retry and fallback routing, load balancing, virtual keys, per-project spend tracking, budgets, rate limits, caching, guardrails, and observability callbacks.
大多数 “vs” 搜索都默认两个产品在争同一个位置，但这里不能这样理解。LiteLLM 为模型流量提供 Python SDK 与可自托管 Proxy Server。其当前官方文档覆盖跨供应商的 OpenAI 格式访问、Provider Adapter、重试与 Fallback 路由、负载均衡、Virtual Key、按 Project 统计支出、预算、限流、缓存、Guardrail 与可观测性 Callback。
QVeris starts from a different question. Once an agent has a goal, it may need current market data, a filing, an external calculation, a document parser, search, or another real-world capability. QVeris lets the agent Discover candidates, Inspect their parameters, provider context, success rate, latency and billing information when available, then Call the selected capability and receive structured results.
QVeris 从另一个问题开始：当 Agent 有了目标，它可能需要当前市场数据、财报文件、外部计算、文档解析、搜索或其他真实世界能力。QVeris 让 Agent 先 Discover 候选，再 Inspect 参数、供应商上下文、成功率、延迟与可用计费信息，最后 Call 所选能力并获得结构化结果。
LiteLLM can expose model tools and even route MCP or agent traffic in newer configurations, but that does not erase the architectural distinction. Model inference, capability discovery, external credentials, live-data freshness and action idempotency still require explicit owners. Compare the concrete workload and control boundary instead of treating every feature named “tool” or “gateway” as equivalent.
LiteLLM 在较新的配置中也可以暴露模型工具，甚至路由 MCP 或 Agent 流量，但这并不会消除架构区别。模型推理、能力发现、外部凭证、实时数据新鲜度和动作幂等仍需明确负责人。应比较具体工作负载与控制边界，而不是把所有名为“Tool”或“Gateway”的功能都视为同一种能力。
Two Layers, Two Jobs
两层架构，两种职责
A model gateway and a capability routing layer can sit side by side. Share the workflow trace and tenant context, but keep model credentials, external-service credentials, retry budgets and action IDs separate.
模型网关和能力路由层可以并排存在。双方可共享工作流 Trace 与租户上下文，但模型凭证、外部服务凭证、重试预算与 Action ID 应彼此独立。
Where Each Product Fits
每个产品适合放在哪里
Name the bottleneck and the owner. If the problem is consistent model access, provider normalization, self-hosted traffic control, or spend policy, start with LiteLLM. If the problem is finding and executing a real-world capability with inspectable schema and evidence, start with QVeris.
先明确瓶颈与负责人。如果问题是统一模型接入、供应商适配、自托管流量控制或支出策略，从 LiteLLM 开始；如果问题是发现并执行带可检查 Schema 与证据的真实世界能力，从 QVeris 开始。
Use LiteLLM when the problem is model access
问题是模型接入时，用 LiteLLM
LiteLLM is the relevant layer when your team needs an OpenAI-format proxy or Python SDK, self-hosted control, provider configuration, virtual keys, budgets, rate limits, load balancing, and model fallback. Verify each endpoint and feature because normalization does not make provider behavior identical.
当团队需要 OpenAI 格式 Proxy 或 Python SDK、自托管控制、Provider 配置、Virtual Key、预算、限流、负载均衡和模型 Fallback 时，LiteLLM 是相关层。仍要逐端点验证功能，因为标准化并不会让供应商行为完全相同。
- Unified model API and adapters统一模型 API 与 Adapter
- Self-hosted gateway and spend controls自托管 Gateway 与支出控制
- LiteLLM official documentationLiteLLM 官方文档
Use QVeris when the problem is real-world capability
问题是真实世界能力时，用 QVeris
QVeris is the relevant layer when agents need discoverable live data, tools, documents, market intelligence, or external actions with inspectable parameters, provider context, execution evidence and structured outputs.
当 Agent 需要可发现的实时数据、工具、文档、市场情报或外部动作，并要求可检查参数、供应商上下文、执行证据与结构化输出时，QVeris 是相关层。
- Discover, Inspect, CallDiscover、Inspect、Call
- Capability evidence and structured results能力证据与结构化结果
- QVeris official documentationQVeris 官方文档
A Production Agent Workflow
一个生产级 Agent 工作流
A realistic agent does not only produce text. It reasons, asks for data, checks schemas, calls tools, and returns a structured result. That is where the two layers become complementary.
真实的 Agent 不只是生成文本。它会推理、请求数据、检查 schema、调用工具，并返回结构化结果。这时两层会自然互补。
Decision Map
决策地图
Choose by the system responsibility you need to own. A single workflow can legitimately use both products without asking either one to impersonate the other layer.
应根据需要承担的系统职责选择。同一工作流完全可以同时使用两者，而不必让任一产品冒充另一层。
| If your agent needs...如果 Agent 需要…… | Better layer更合适的层 | Why原因 |
|---|---|---|
| Multi-provider model normalization and routing多供应商模型标准化与路由 | LiteLLM | This is model-provider access, adapter, and traffic control.这属于模型供应商接入、Adapter 与流量控制。 |
| Self-hosted keys, budgets, and model traffic policy自托管 Key、预算与模型流量策略 | LiteLLM | The Proxy Server runs inside your infrastructure boundary.Proxy Server 可运行在你的基础设施边界内。 |
| Live data, verified tools, or document actions实时数据、已验证工具或文档动作 | QVeris | This requires capability discovery, inspection, and execution.这需要能力发现、检查与执行。 |
| Production agent workflows using models and external systems同时使用模型与外部系统的生产 Agent 工作流 | Both两者 | Models reason; governed capabilities provide current evidence and actions.模型负责推理，治理化能力提供当前证据与动作。 |
Frequently Asked Questions
常见问题
Not directly. LiteLLM is a model gateway. QVeris is a capability routing layer.
不是直接替代。LiteLLM 是模型网关，QVeris 是能力路由层。
Yes. LiteLLM routes model calls, while QVeris routes calls to tools, data, and services.
可以。LiteLLM 路由模型调用，QVeris 路由工具、数据和服务调用。
Usually yes, if you care about provider control, fallback, budgets, or model routing.
通常需要，尤其当你关心供应商控制、fallback、预算或模型路由时。
Add it when your agent needs current data, verified execution, or external capabilities.
当 Agent 需要当前数据、已验证执行或外部能力时，就该加 QVeris。
Model routing chooses an LLM provider. Capability routing chooses the tool, data source, or service an agent should call.
模型路由选择 LLM 供应商；能力路由选择 Agent 应该调用的工具、数据源或服务。
QVeris focuses on capability execution and structured results. It is designed to work beside your model layer.
QVeris 关注能力执行和结构化结果，设计上是和模型层并排工作。
What to Validate Before You Combine Them
组合使用前要验证什么
Do not stop at a successful demo. Write down which layer owns each failure and what evidence must survive the request. This prevents a model retry from accidentally repeating an external action, or a capability failure from being hidden inside a generic model error.
不要把 Demo 跑通当作完成。应明确每类故障由哪一层负责，以及请求结束后必须保留哪些证据。这样可以避免模型重试意外重复外部动作，也能防止能力调用失败被笼统的模型错误掩盖。