轻量级大模型智能网关 — 一行命令部署，零数据库依赖，多厂商无缝切换。
调用大模型 API 时，你大概率遇到过这些痛点：
- 单一厂商频繁超限、限流、宕机，导致业务中断
- 多个厂商 API 格式不统一（OpenAI / Anthropic），适配成本高
- 高并发场景下缺乏自动负载分摊，靠人工切流量
- 所有请求走最贵的模型，成本居高不下
SmartSwitch（智切） 是一个部署在你和各家 LLM 之间的极薄代理层，对外暴露标准 OpenAI 接口，对内按 优先级 + 组内随机 智能选择后端通道，故障自动转移，让业务零感知切换。
| 特性 | 说明 |
|---|---|
| 🪶 轻量级 | 单一可执行文件，无数据库、无消息队列，JSON 文件驱动配置 |
| 🔗 统一接口 | 对外暴露标准 OpenAI /v1/chat/completions，对内适配 OpenAI / Anthropic 多协议 |
| ⚖️ 智能负载均衡 | 按优先级分组，高优先级优先调用；同组内随机分摊，避免热点 |
| 🛡️ 高可靠性 | 请求失败自动重试下一通道，多次失败熔断 + 定时后台探测自动恢复 |
| 💰 节省成本 | 低成本通道放高优先级，昂贵通道做兜底；流量自动向高性价比倾斜 |
# 编译（Go 1.21+）
go build -o smartswitch .
# 直接运行
./smartswitch启动后日志输出：
SmartSwitch is ready to serve # 默认监听 0.0.0.0:8080
# 非流式
curl -X POST http://localhost:8080/v1/chat/completions \
-H "Authorization: Bearer sk-smart-switch-secret" \
-H "Content-Type: application/json" \
-d '{"model":"flash-model","messages":[{"role":"user","content":"你好"}]}'
# 流式（SSE）
curl -X POST http://localhost:8080/v1/chat/completions \
-H "Authorization: Bearer sk-smart-switch-secret" \
-H "Content-Type: application/json" \
-d '{"model":"flash-model","messages":[{"role":"user","content":"你好"}],"stream":true}'你的业务代码一行不用改 — 原来指向 OpenAI 的 base_url 换成 SmartSwitch 地址即可。
SmartSwitch 采用 文件即配置 设计，新增通道或模型只需添加一个 JSON 文件，重启即时生效。
{
"server": {
"host": "0.0.0.0",
"port": 8080,
"api_key": "sk-smart-switch-secret",
"timeout_seconds": 600,
"log_file": "smartswitch.log"
},
"routing": {
"max_attempts": 3,
"retry_on_status_codes": [401, 402, 403, 404, 429, 500, 502, 503, 504]
},
"health_check": {
"default_interval_seconds": 60,
"scheduler_poll_seconds": 10
}
}定义一个 LLM 后端通道，文件名即 Provider 名称。
{
"protocol": "openai",
"base_url": "https://api.openai.com/v1",
"api_key": "sk-xxx",
"chat_path": "",
"enabled": true
}protocol 支持 openai 和 anthropic，SmartSwitch 自动完成协议转换，对调用方透明。
定义业务侧调用的模型名及其路由策略。
{
"enabled": true,
"routes": [
{ "provider": "sensenova", "real_model": "deepseek-v4-flash", "priority": 20 },
{ "provider": "sensenova", "real_model": "sensenova-6.7-flash", "priority": 20 },
{ "provider": "mimo", "real_model": "mimo-v2.5", "priority": 30 },
{ "provider": "ali", "real_model": "qwen3.7-flash", "priority": 30 }
]
}优先级越小越优先。上例中：先尝试 priority=20 的两个 sensenova 通道（组内随机选一个），都失败后才降级到 priority=30 的通道。
这就是 优先级分组 + 组内随机 策略：高优组优先承载流量，同组内随机分摊负载，天然实现"低成本通道打头阵，高成本通道做兜底"。
请求到达
│
├─ priority=10 组 ── 随机选一个 ── 成功 → 返回
│ 全部失败 ↓
├─ priority=20 组 ── 随机选一个 ── 成功 → 返回
│ 全部失败 ↓
├─ priority=30 组 ── 随机选一个 ── 成功 → 返回
│ 全部失败 ↓
└─ 503 Service Unavailable
- 高优先级优先：priority 数值越小越高优，组间严格降级
- 组内随机：同一优先级多个通道随机选择，无状态、无锁，分布均匀
- 自动去重：同一 Provider 配置了多条路由时自动跳过已尝试过的
- 可配最大重试次数：
routing.max_attempts控制全局上限
| 路径 | 方法 | 鉴权 | 说明 |
|---|---|---|---|
/health |
GET | - | 服务健康检查 |
/v1/chat/completions |
POST | Bearer | OpenAI 兼容聊天接口（支持流式） |
/v1/models |
GET | Bearer | 列出所有启用的虚拟模型 |
/admin/providers |
GET | Bearer | 查看所有 Provider 运行时状态 |
/admin/providers/:name/recover |
POST | Bearer | 手动恢复指定 Provider |
/admin/providers/recover-all |
POST | Bearer | 手动恢复所有已熔断 Provider |
/admin/providers/:name/check |
POST | Bearer | 手动触发指定 Provider 健康检查 |
请求失败
│
└─ 标记 Blocked（立即熔断）
│
└─ 定时调度器扫描（默认 10 秒）
├─ 健康检查通过 → 恢复 Healthy
└─ 健康检查失败 → 保持 Blocked，延长下次检查
整个过程对调用方透明：请求被某个已熔断的 Provider 拦截时会自动跳到下一个。
收到 SIGINT / SIGTERM 后：
- 停止接收新请求
- 等待进行中的请求完成（最长 30s）
- 持久化运行状态
- 关闭连接池
smartswitch/
├── main.go # 入口：加载配置、启动服务
├── go.mod / go.sum # Go 模块定义与依赖锁
├── config.json # 主配置（server / routing / health_check）
├── providers/ # Provider 定义（一个文件一个通道）
│ ├── sensenova.json
│ ├── mimo.json
│ ├── ali.json
│ ├── anthropic.json
│ └── nvidia.json
├── models/ # 虚拟模型定义（一个文件一个模型）
│ ├── flash-model.json
│ └── pro-model.json
└── internal/
├── config/ # 配置加载与校验
│ └── config.go
├── state/ # 状态管理与原子持久化
│ ├── types.go
│ └── manager.go
├── router/ # 虚拟模型路由（优先级分组 + 组内随机）
│ └── router.go
├── proxy/ # 代理转发与协议适配
│ ├── proxy.go
│ └── adapters/
│ ├── adapter.go # Adapter 接口 + 流式检测
│ ├── openai.go # OpenAI 协议适配器
│ └── anthropic.go # Anthropic → OpenAI 协议转换
├── health/ # 健康检查与熔断调度
│ ├── checker.go
│ └── scheduler.go
└── api/ # HTTP 接口与中间件
├── server.go
├── middleware.go
└── handlers.go
# 运行时生成文件（不提交版本控制）：
# state.json — 运行状态持久化，自动维护，原子写入
{
"routes": [
{ "provider": "free_tier", "real_model": "llama-3-free", "priority": 10 },
{ "provider": "cheap_relay", "real_model": "qwen-flash", "priority": 20 },
{ "provider": "openai", "real_model": "gpt-4o-mini", "priority": 30 }
]
}日常流量优先走免费/低价通道，只在它们都不可用时才调用付费 API，显著降低月账单。
{
"routes": [
{ "provider": "openai", "real_model": "gpt-4o", "priority": 10 },
{ "provider": "anthropic", "real_model": "claude-sonnet", "priority": 10 },
{ "provider": "deepseek", "real_model": "deepseek-chat", "priority": 20 }
]
}OpenAI 和 Anthropic 同一优先级随机分流，两边同时扛量。任一故障时 DeepSeek 接盘。
| 维度 | SmartSwitch（智切） | cc-Switch | LiteLLM |
|---|---|---|---|
| 产品定位 | 生产级服务端 LLM 网关 | 本地桌面 AI 编程工具配置管理器 | Python 生态的全功能 LLM 网关 |
| 部署方式 | 单一 Go 二进制，一行命令启动 | Electron 桌面应用，需 GUI 持续运行 | Python + Docker Compose，推荐配 PostgreSQL |
| 运行时依赖 | 零依赖（无 DB / Redis / MQ） | SQLite（本地加密存储） | Python 运行时 + 推荐 PostgreSQL + Redis |
| 资源占用 | ~10 MB 内存，极低 CPU | 桌面应用 ~200-500 MB 内存 | ~100-300 MB（含 Python 进程 + DB） |
| 接口协议 | OpenAI 兼容 API（支持流式），对内适配 OpenAI / Anthropic | 面向 Claude Code 等特定 AI 编程工具的本地代理 | OpenAI 兼容 API，支持 100+ 厂商 |
| 负载均衡 | 优先级分组 + 组内随机，成本自然倾斜 | 单供应商切换（手动或自动故障转移） | 轮询 / 加权 / 低延迟路由，策略丰富 |
| 高可用 | 自动重试 + 熔断 + 定时探测恢复，全自动 | 熔断器 + 健康监控 + 故障转移队列 | 重试 + 熔断 + fallback，依赖外部 DB 持久化 |
| 成本控制 | 优先级驱动低成本优先，天然向高性价比倾斜 | 用量统计 + 额度监控，无自动成本优化 | 预算管理 + 按 Key 限流 + 成本追踪 |
| 配置方式 | JSON 文件即配置，无需 UI，GitOps 友好 | GUI 界面管理，本地操作 | YAML 配置 + 环境变量 + Admin UI |
| 服务端场景 | ✅ 原生支持，作为中心化网关部署 | ❌ 仅本地开发机使用 | ✅ 支持，但部署复杂度较高 |
| 开发机 CLI 场景 | ✅ 专为此场景设计 | ✅ 通过 SDK 集成 | |
| 上手时间 | 1 分钟（下载 → 启动 → 调用） | 5-10 分钟（安装桌面应用 + 配置） | 15-30 分钟（Docker 环境 + 数据库 + 配置） |
- SmartSwitch：适合需要生产级服务端网关、追求极简部署、希望零成本维护的团队。
- cc-Switch：适合 AI 编程工具的本地供应商管理和一键切换，定位在开发桌面端。
- LiteLLM：适合 Python 技术栈、需要 100+ 厂商支持、需要细粒度预算和限流管理的大型项目。
三者并非完全竞争关系：cc-Switch 侧重开发桌面端，LiteLLM 是全功能重装网关，SmartSwitch 在 "生产级能力 + 极简部署" 之间取得最佳平衡。
- Go 1.21+
- net/http — HTTP 代理与 SSE 流式透传
- slog — 结构化 JSON 日志
- JSON 文件 — 配置与状态持久化（原子写入防损坏）
- 零外部运行时依赖 — 无数据库、无 Redis、无消息队列