构建多模型智能网关：Ciyuano 技术架构揭秘

概述

Ciyuano 的核心是一个智能模型网关。这篇文章带你了解它的架构设计。

系统架构

用户请求 → 认证&计费 → 模型路由器 → [DeepSeek/GLM/Qwen Channel] → 流式响应

核心模块

1. 渠道管理器

每个上游模型供应商被抽象为一个「渠道」：

typescript

interface Channel {

id: number;

provider: string; // deepseek | zhipu | aliyun

modelId: string; // deepseek-v4 | glm-5

baseUrl: string; // 上游 API 地址

apiKey: string; // 上游 API Key

weight: number; // 负载权重

isEnabled: boolean; // 是否启用

healthStatus: string; // healthy | degraded | down

}

2. 智能路由器

路由决策流程：

模型解析：auto → 所有渠道候选；指定模型 → 匹配渠道

健康过滤：排除 isEnabled=false 或 healthStatus=down 的渠道

加权选择：按 weight 加权随机，权重高 → 选中概率大

故障转移：请求失败 → 自动标记 → 重试下一渠道

python

def select_channel(model, channels):

candidates = [c for c in channels

if c.is_enabled and c.model_id == model]

if not candidates:

raise NoChannelAvailable()

total_weight = sum(c.weight for c in candidates)

r = random.uniform(0, total_weight)

cumulative = 0

for c in candidates:

cumulative += c.weight

if r <= cumulative:

return c

3. 健康检查

后台定时对每个渠道发起轻量级探测请求，标记 healthy / degraded / down 三种状态。

4. 协议转换

上游各厂商的 API 格式千差万别，统一转换为 OpenAI 格式输出：

上游 → 统一中间表示 → OpenAI 格式响应

5. 实时计费

python

cost = (

prompt_tokens * channel.prompt_price_per_1k / 1000 +

completion_tokens * channel.completion_price_per_1k / 1000

)

key.balance -= cost

key.total_cost += cost

关键设计决策

为什么用 SQLite 而不是 PostgreSQL？

 部署简单：零配置，一个文件搞定

 性能足够：SQLite 的读写性能对中等规模 API 服务绰绰有余

 LiteFS / Turso 等方案可以轻松扩展到多节点

为什么不做模型 Finetune？

我们定位是「网关」而非「模型工厂」。做好通道和路由。

为什么不引入缓存层？

AI 对话的相同输入不一定产生相同输出（temperature、随机种子）。盲目缓存可能破坏生成多样性。

性能指标

Ciyuano 的额外延迟通常在 50-150ms，主要来自认证、计费和路由决策。

流式响应时，首 Token 延迟（TTFT）几乎不受影响，因为我们采用透传代理而非缓冲转发。

总结

一个好的 API 中转站，技术上要做三件事：兼容、路由、计费。做好这三件事，就是对开发者最大的价值。