构建多模型智能网关：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. 智能路由器

路由决策流程：

1. 模型解析：auto → 所有渠道候选；指定模型 → 匹配渠道
2. 健康过滤：排除 isEnabled=false 或 healthStatus=down 的渠道
3. 加权选择：按 weight 加权随机，权重高 → 选中概率大
4. 故障转移：请求失败 → 自动标记 → 重试下一渠道

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 中转站，技术上要做三件事：兼容、路由、计费。做好这三件事，就是对开发者最大的价值。