Tokios与LiteLLM在本地大语言模型路由方面的对比

​

概述

LiteLLM是一款开源的Python代理与API网关。它位于大语言模型后端之前，负责在不同提供商的API之间进行转换，这些提供商包括OpenAI、Anthropic、Azure、Bedrock以及100多家其他厂商。此外它还提供虚拟API 密钥管理、预算监控、负载均衡以及可观测性功能，堪称强大的路由与成本管控工具。 核心区别在于：LiteLLM属于代理而非隧道。它负责协调调用端与后端之间的API流量，却无法解决让本地模型能够被互联网访问的网络连通性问题。因此用户仍需借助其他隧道工具，如Tailscale、Cloudflare或Tokios来实现远程访问。 Tokios则将隧道功能、API网关、面向用户的API 密钥以及管理控制台全部整合进1托管服务之中。该服务既负责网络层配置以确保模型可被外部访问，也负责处理认证、数据流传输以及协议转换等API层事务。

​

对比表格

​

LiteLLM的核心优势所在

• 开源项目。提供完整源代码且支持自行部署，无需依赖特定供应商。用户可随时审查、分叉及修改代码。
• 100+ 服务提供商。 您可以通过统一的 OpenAI 格式 API 将请求路由至 OpenAI、Anthropic、Azure OpenAI、AWS Bedrock、Google Vertex、Together AI 等众多服务商。
• 高级路由功能。包含加权负载均衡、基于延迟的路由机制、提供商故障时的自动切换策略，以及针对速率受限模型的冷却逻辑。
• 精细化的预算管控。可针对虚拟令牌、团队或项目设定支出上限，还能统计各模型及用户的每日费用情况。在这方面LiteLLM的功能更为完善。
• 强大的可观测性。原生兼容Langfuse、Datadog、Prometheus、Helicone及自定义回调接口，可完整记录每个请求的详细信息、令牌使用量及延迟数据。
• 精准的成本溯源。可明确掌握各团队在各类模型上的具体开支情况。对于需要跨多个云服务商进行资源调度的企业而言，这一功能至关重要。

​

Tokios 的优势所在

• 内置隧道功能。LiteLLM 仍需借助其他网络层才能让本地模型被互联网访问。Tokios 则直接集成了出站隧道功能，无需配置 cloudflared、Tailscale 或 nginx。
• 托管式服务。无需运行 Docker 容器，无需进行 Kubernetes 部署，也无需维护 Python 运行环境。Tokios 仅由一个连接器二进制程序及一个网页控制台构成。
• 自带控制台。用户可通过单一界面管理各类连接器、部署任务以及 API 密钥。LiteLLM 的管理界面则需额外设置与配置。
• 网关层面的协议转换。该隧道端点可支持 OpenAI 与 Anthropic 格式。LiteLLM 虽会将请求统一转换为 OpenAI 格式，但无法向调用端提供 Anthropic 协议支持。
• 更适配本地模型部署。若目标是“让本地的 Ollama 模型可通过 API 密钥被访问”，使用 Tokios 仅需花费 2 分钟。而 LiteLLM 则需要完成 Docker 部署、配置文件编写以及独立的隧道设置。

​

网络层面的差异

这正是两者的根本区别。LiteLLM 属于代理层，仅能连接处于同一网络或可互通网络中的调用端与后端。若模型运行在受 CGNAT 限制的家庭服务器上，LiteLLM 自身无法让该模型被互联网访问。此时需满足以下条件：

1. 需配置隧道服务（如 Cloudflare Tunnel、Tailscale Funnel 或 Tokios）以使 LiteLLM 代理可被公网访问
2. 需将 LiteLLM 置于该隧道后方以处理路由分配、令牌管理及资源配额控制
3. 还需将各类大语言模型后端部署在 LiteLLM 之后

这样的架构意味着需设置并维护 3 个层级。而 Tokios 则将 1 与 2 两个层级整合为一项托管式服务，不过它并未取代 LiteLLM 的多供应商路由功能。

​

两者结合使用

对于复杂的部署场景而言，二者能够相互补充：

• LiteLLM 部署于本地网络中，可跨多个后端进行请求路由（包括本地的 vLLM、云端的 OpenAI 以及 Azure 备用服务），同时具备成本追踪与负载均衡功能。
• Tokios 则提供面向公众的隧道端点及相应的 API 密钥，这样外部用户与编程代理便可直接访问您的 LiteLLM 代理，而无需您另行配置隧道。

在此架构下，Tokios 连接器指向的是 LiteLLM 代理而非直接连接至后端服务。调用方发送请求至 api.tokios.com 并附上 sk-tok-… 令牌后，请求经由 Tokios 隧道传至本地机器，随后由 LiteLLM 负责跨多个服务提供商的路由处理。

​

何时选用 LiteLLM

• 多云服务提供商路由需求：您需要在 OpenAI、Anthropic、Azure 及本地模型之间实现请求路由，同时设置备用方案与负载均衡机制。
• 高级成本追踪需求：您需要按团队划分预算、设置项目级支出上限并实现精细化的成本归属分析。
• 具备 DevOps 能力：您能够借助配置文件与监控工具来运行并维护 Docker 或 Kubernetes 部署环境。
• 需要广泛的服务提供商支持：您计划集成 5 及多种大型语言模型服务，并希望获得统一的 API 接口。

​

何时选用 Tokios

• 本地模型需要公共 API 接口：您的主要目标是让本地硬件上运行的模型能够通过认证机制被全球范围内的用户访问。
• 希望使用托管服务。 无需自行运行基础设施，也无需编排容器或管理 Python 运行环境。
• 需要集隧道、代理与密钥管理于一体的工具。 仅需一个工具即可处理网络配置、身份验证及数据流传输，无需像 3 那样依赖多个独立组件。
• 本地后端部署简便。 只需在 Ollama 或 vLLM 环境下运行一两个本地模型即可，无需构建多供应商路由架构。