本地模型的路由策略

Tokios 允许您发布多个模型，每个模型均拥有独立的公开名称。只需修改请求中的 model 字段即可实现模型间的切换。端点地址与 API 密钥保持不变，仅需调整 model 的值即可。

路由运作原理

每个部署实例均具备唯一的公开名称。当 Tokios 接收到请求后，它会读取其中的 model 字段，定位到对应名称的部署实例，随后将其替换为该实例对应的上游模型 ID，最后经由连接器通道转发至目标端。客户端配置无需变动，仅需调整 model 数值即可。

单个连接器支持多模型运作

一个连接器即可承载多个模型。只需在 Routes 中列出各上游模型 ID，并在 Upstreams 中将其映射为对应的本地命名实例即可。

tokios-connector.json

{
  "Connector": {
    "ConnectorId": "con_...",
    "Token": "ct-...",
    "Routes": [
      { "Model": "gemma4:e4b",    "UpstreamId": "ollama" },
      { "Model": "qwen2.5-coder", "UpstreamId": "lmstudio" }
    ],
    "Upstreams": {
      "ollama":   { "BaseUrl": "http://127.0.0.1:11434/v1" },
      "lmstudio": { "BaseUrl": "http://127.0.0.1:1234/v1" }
    }
  }
}

随后在控制台内为每个模型创建独立的部署实例，为其指定专属公开名称（例如将 gemma-tunnel 对应至 gemma4:e4b，将 qwen-coder 对应至 qwen2.5-coder），所有实例均指向同一连接器。

若希望保持独立部署也可行：您可为每个模型单独配置连接器，各连接器均拥有专属的 ConnectorId/Token 及 Upstream 参数。两种方案均可实现预期效果，服务器最终仅会发送模型 ID 至通道中。

请求过程中实现模型切换

当所有部署实例均完成注册后，仅需修改请求中的 model 字段即可实现模型切换。

# Use the Gemma model
curl https://api.tokios.com/v1/chat/completions \
  -H "Authorization: Bearer sk-tok-YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "gemma-tunnel", "messages": [{"role": "user", "content": "Hello"}]}'

# Use the Qwen model
curl https://api.tokios.com/v1/chat/completions \
  -H "Authorization: Bearer sk-tok-YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "qwen-coder", "messages": [{"role": "user", "content": "Hello"}]}'

端点地址、认证头信息以及所有其他参数均保持不变。Tokios负责请求的调度工作。

在不改动客户端的前提下更换后端服务

由于客户端仅引用模型的公开名称，因此即便将模型迁移至其他硬件或后端，也无需修改任何客户端配置：只需更新部署设置（或连接器所指向的上游模型 ID），确保公开名称保持不变即可，原有请求仍能正常执行。

路由策略

当本地运行多个模型时，若所有请求都发往同一模型则会造成资源浪费。编写代码类请求无需调用 120B 推理模型，简单的分类任务也无需使用 70B 密集型模型。借助路由机制即可将请求精准分发至最适合的模型，从而依据实际工作负载优化响应速度、输出质量或成本。若所有请求都交由 1 模型处理则必然需要做出权衡：大型模型虽能胜任各类任务，但响应速度较慢且占用大量显存；小型模型响应迅速，却难以完成复杂的推理任务。而路由机制可让两者兼得：

速度：简单查询交由小型快速模型处理，复杂任务则转交大型模型执行
质量：代码编写类任务交由专门处理代码的模型，普通对话则由通用型模型应答
成本：小型模型能耗与显存占用更低，能为高负载任务预留充足资源
容错性：当主用模型处于繁忙状态或发生故障时，请求会自动转交备用模型处理

每个部署仅对应一个模型

这是最简便的方案：将每个模型分别注册为独立的 Tokios 部署实例，客户端只需修改 model 字段即可指定需要调用的模型。

tokios-connector.json

{
  "Connector": {
    "Routes": [
      { "Model": "qwen3-coder", "UpstreamId": "ollama" },
      { "Model": "gemma-tunnel", "UpstreamId": "ollama" }
    ],
    "Upstreams": {
      "ollama": { "BaseUrl": "http://127.0.0.1:11434/v1" }
    }
  }
}

您的客户端会发送带有正确 model 值的请求：

# Code task → code model
curl https://api.tokios.com/v1/chat/completions \
  -H "Authorization: Bearer sk-tok-YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "qwen3-coder", "messages": [{"role": "user", "content": "Write a Python function to sort a list"}]}'

# General chat → general model
curl https://api.tokios.com/v1/chat/completions \
  -H "Authorization: Bearer sk-tok-YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "gemma-tunnel", "messages": [{"role": "user", "content": "Summarize this article"}]}'

适用场景：当您需要部署 2 至 3 系列模型，且应用程序能自行决定调用哪个模型时，此方案最为合适。这也是最常见的起步方式。

基于任务的路由机制

依据任务类型进行路由——将编程类请求分配给擅长代码的模型，普通对话则交由通用型模型处理，复杂推理任务则分配给运算能力更强的模型。客户端或中间件层会解析请求内容并选定对应的部署方案。

任务类型	推荐的模型类别	典型的部署实例	选用理由
代码生成与重构	专用于代码处理的模型	基于 vLLM 平台运行的 Qwen3-Coder-30B 模型	该模型专为编程场景训练而成，在语法处理与逻辑构建方面表现优异
常规对话与内容摘要	混合专家架构（35B至122B）	Atlas 平台上运行的 Qwen3.5-35B-A3B 模型	处理速度迅捷；每个令牌对应3B个活跃参数
适用于复杂推理与数学运算场景	密集架构设计，参数规模达70B以上	可在 vLLM 环境中部署的 Qwen3-32B 或 70B 模型	在多步骤推理任务中表现更为出色
支持工具调用与智能体交互功能	具备工具调用能力的专用模型	运行于 vLLM 平台的 GLM-4.5-Air 模型	提供卓越的函数调用支持服务
视觉与多模态功能	多模态模型	在 vLLM 平台上运行的 Qwen3-VL	原生支持图像输入

最简单的实现方式是在应用程序代码中判断请求类型并选取对应的部署名称：

def select_model(task_type: str) -> str:
    routing = {
        "code": "qwen3-coder",
        "chat": "gemma-tunnel",
        "reasoning": "glm-4-chat",
        "vision": "qwen3-vl",
    }
    return routing.get(task_type, "gemma-tunnel")

如需实现更复杂的路由机制，可借助 LiteLLM 或 OpenRouter 这类网关，它们能依据自定义规则对请求进行分析并转发至合适的后端。

网关层面的路由机制

在客户端与 Tokios 之间部署路由代理，该代理可依据请求特征、负载状况或自定义规则决定使用哪个 Tokios 部署实例。LiteLLM 可同时对接多个 Tokios 部署实例，并依据模型别名执行路由操作：

litellm_config.yaml

model_list:
  - model_name: gpt-4  # alias
    litellm_params:
      model: openai/qwen3-coder  # Tokios deployment
      api_base: https://api.tokios.com/v1
      api_key: sk-tok-YOUR_KEY
  - model_name: gpt-4
    litellm_params:
      model: openai/gemma-tunnel  # fallback
      api_base: https://api.tokios.com/v1
      api_key: sk-tok-YOUR_KEY

router_settings:
  routing_strategy: simple-shuffle
  num_retries: 2

客户端通过别名 gpt-4 向 LiteLLM 代理发送请求，随后代理便会将请求转发至您预先设定的 Tokios 部署实例。OpenRouter 支持跨多个服务提供商的模型降级机制与负载均衡功能。您只需将 Tokios 端点添加为自定义服务提供商，随后在 OpenRouter 控制台中配置相应的路由规则即可。

降级机制链

配置一个主模型以及 1 个或更多备用模型。若主模型处于繁忙状态、离线或返回错误，请求便会转交至链中的下一个模型处理。

import requests

FALLBACK_MODELS = ["qwen3-coder", "gemma-tunnel", "qwen3-32b"]

def chat_with_fallback(prompt: str) -> str:
    for model in FALLBACK_MODELS:
        try:
            response = requests.post(
                "https://api.tokios.com/v1/chat/completions",
                headers={
                    "Authorization": "Bearer sk-tok-YOUR_KEY",
                    "Content-Type": "application/json"
                },
                json={"model": model, "messages": [{"role": "user", "content": prompt}]},
                timeout=30
            )
            response.raise_for_status()
            return response.json()["choices"][0]["message"]["content"]
        except (requests.RequestException, KeyError):
            continue
    raise RuntimeError("All models failed")

Tokios 连接器会将其状态上报给网关。一旦某个连接器离线，发往该连接器上各部署的请求均会返回 503。您的应用程序可捕获此情况并尝试向其他部署发送请求；您亦可配置类似 LiteLLM 的网关来自动执行备用模型切换。

基于成本的路由机制

将那些请求量较大且较为简单的任务分配给体积更小且成本更低的模型，而让大型模型专门处理那些对性能要求较高的任务。

请求类型	路由目标	选择理由
分类与信息提取	采用混合专家架构，同时激活 3 至 4B 个参数	响应速度极快，且每个令牌所需的计算量极低
简短内容的摘要生成	7B–14B 密集型或混合专家型	质量可靠且响应迅速
复杂的逻辑推理	32B密集架构或 122B混合专家架构	在多步骤任务中表现更出色
代码生成能力	专为代码编写优化的模型	在给定令牌数量限制下输出质量更佳

该策略能降低整体计算量与能耗，对于显存与功率受限的消费级硬件而言尤为关键。

决策矩阵

实施策略	任务复杂度	适用场景	适用场景
每次部署仅使用一个模型	较低	入门指南，支持 2 至 3 各类模型	您可自行决定在应用程序代码中调用哪个模型
基于任务的路由机制	中等	编码、对话及推理功能	针对不同类型任务需要选用不同模型
网关层面的路由设置	较高	多客户端共享同一基础设施	您希望在不修改客户端代码的前提下实现路由规则的集中化管理
备用模型链机制	中等难度	高可用性需求	您的主用模型可能会出现离线状态或超出并发处理上限的情况
基于成本优化的路由策略	中等难度	高并发且任务类型繁杂的工作负载环境	您希望通过将简单任务分配给规模较小的模型来降低计算资源消耗成本

上述各类策略互不冲突。实际生产环境中常见的做法是在网关代理层结合基于任务类型的路由机制（将代码类任务分配给代码处理专用模型）与备用模型链机制（主用模型无法响应时自动切换至备用模型）。

后续操作指引

选择本地部署的模型

对比各类模型与后端，以此决定应当部署哪些服务。

对您的部署情况进行基准测试

测定系统的吞吐量与延迟情况，从而验证在实际工作负载下所制定的路由策略是否合理。

硬件与适配

服务与连接运行时

连接客户端或应用

对比

本地模型的路由策略

路由运作原理

单个连接器支持多模型运作

请求过程中实现模型切换

在不改动客户端的前提下更换后端服务

路由策略

决策矩阵

后续操作指引

选择本地部署的模型

对您的部署情况进行基准测试

​路由运作原理

​单个连接器支持多模型运作

​请求过程中实现模型切换

​在不改动客户端的前提下更换后端服务

​路由策略

​决策矩阵

​后续操作指引

选择本地部署的模型

对您的部署情况进行基准测试

路由运作原理

单个连接器支持多模型运作

请求过程中实现模型切换

在不改动客户端的前提下更换后端服务

路由策略

决策矩阵

后续操作指引