LLM Server
业务面对的是平台模型名和统一接口，而不是某一个供应商账号。请求背后的协议适配、渠道选路、账号调度与异常切换由平台完成。
统一入口，连接多模型多渠道
平台同时提供三类对外协议入口，每类都注册带 /v1 前缀和不带前缀两个路径：
| 入口 | 协议 | 处理 |
|---|---|---|
/v1/chat/completions | OpenAI Chat | 标准链路 |
/v1/responses | OpenAI Responses | 同协议直通 / 跨协议转换 |
/v1/messages | Anthropic Messages | 同协议直通 / 跨协议转换 |
/v1/images/generations · /v1/videos/generations · /v1/audio/speech | 媒体 | 按输出模态路由 |
特色：同协议直通，不丢字段
很多网关把所有请求归一成内部格式再转出去，代价是丢字段。LLM Server 先判断客户端协议与上游渠道协议是否一致：一致就原样转发，SSE 帧、块顺序、签名、缓存标记与引用字段都不改；只有跨协议时才做字段映射。
| 客户端请求 | 上游渠道协议 | 平台行为 |
|---|---|---|
| Anthropic Messages | Anthropic | 原样直通，保留 thinking 签名与 cache_control |
| Anthropic Messages | OpenAI | 转为 OpenAI 请求，响应再转回 Anthropic 语义 |
| OpenAI Responses | Responses | 原样直通，保留 reasoning 与加密推理内容 |
| OpenAI Chat | Anthropic / Responses | 按目标协议构造，响应与流式帧转回 OpenAI 形态 |
特色：客户端模板，把编码工具接上你的渠道
Claude Code、Codex、Cursor、Cline、opencode 这类编码工具对上游有各自的请求约定。渠道可指定客户端模板，平台按目标客户端补齐协议、headers 和默认字段。
- 预设 → 目标协议映射：codex-cli→Responses、claude-code→Anthropic、gemini-cli→Gemini、cursor / cline / roo-code / opencode / workbuddy→OpenAI。渠道
protocol与client_preset不一致时按预设目标协议构造上游 payload。 - 默认字段只补不覆盖：仅当客户端未显式提供时才填入默认值，不污染调用方意图。例如 codex-cli 补齐 instructions、
text.verbosity、store=false、reasoning.effort、prompt_cache_key等。 - 思考参数按协议表达：关闭推理时省略参数而非传空值；OpenAI 删
reasoning_effort，Anthropic 用标准{"type":"disabled"}，Responses 删reasoning。 - 客户端识别：依次从 header（User-Agent）、body 的
client_type/client_preset、system 首条消息特征判定。
特色：多因子实时评分选路
不轮询、不权重随机。每个候选账号算出一个分值按分值择优。8 个维度实时打分：
| 评分维度 | 解决的实际问题 |
|---|---|
| 额度余量与限流余量 | RPM/TPM/并发用尽的账号直接零分，不浪费一次尝试 |
| 连续失败指数降权 | 失败越多权重越低（intelligent 0.8ⁿ、fast 0.7ⁿ），一次成功立即清零 |
| 窗口失败熔断 | 5 分钟内阈值 2 次触发冷却，基数/步长 15s、上限 120s，不要求连续失败 |
| 会话亲和 / 反亲和 | 同会话优先回上次成功账号命中缓存；失败过的降权，连续失败直接排除 |
| 上游模型亲和 | 复用同一上游模型保住 prompt cache，与会话亲和取较大值而非叠乘 |
| 计费模式滑动偏好 | 按次计费账号按 prompt token 量线性偏好（约 2000 token 交叉），日额度 <20% 再乘 0.3 |
| 连续成功让权 | 避免单账号被打爆，成功若干次后让位给池中其他账号 |
| 短期成功率与延迟 | 把最近真实表现纳入评分，快且稳的账号自然胜出 |
六种策略，按 API Key 分别指定
顺序 / 成员随机 / 按模型随机 / 全局随机 / 智能（默认，多因子评分）/ 快速智能（速度主导并保留少量探索）。同一套渠道池可同时服务"要最稳"和"要最快"两类业务。
特色：九种冻结模式 + 双层限流重试
- 九种冻结：账号 / 账号+模型 / 渠道 / 渠道+模型 四个对象维度 × 固定时长 / 当天 / 按周 / 按月 / 永久 五个周期，可由响应头或错误码触发。
- 非重试 4xx 也走冻结：403 命中规则当天冻结该账号，而不是每次请求都撞一次。
- 双层限流：API Key 级 RPM/RPD/TPM/并发（Redis 固定窗口 + 原子并发占用），账号级 headroom，模型级 TPM。
- 失败分类而非一律重试：参数错误原样透传不浪费候选；限流与 5xx 才切账号；已输出内容的流式不重推；账号级重试 + 模型组回退管线（visited 防环）。
- 上下文超限归一：prompt_too_long / context_length_exceeded 统一成 400，不当作可重试错误反复消耗候选。
特色：灵活自定义与多协议链路
遇到"上游接口有点怪"通常要么改中转代码要么放弃接入。平台把这些差异做成渠道配置项，不改代码：
| 可配置项 | 用途 |
|---|---|
| base URL、对话/模型列表路径 | 接入任何路径约定不同的兼容服务 |
| 认证头风格 | Bearer、x-api-key、自定义头三种风格 |
| 多协议链路（chat_protocols） | 同一渠道配多条协议行，各自协议/路径/流式形态/客户端模板；按请求协议同协议优先选行 |
| 客户端模板（可按模型覆盖） | 整体模拟某客户端，个别模型还能单独覆盖 |
| 图片/视频/语音路径与开关 | 媒体能力按上游实际情况分别启用 |
| 模型别名与白名单 | 把上游模型名映射成对外暴露名并限制范围 |
特色：四种代理模式，含节点出口
| 模式 | 行为 | 典型场景 |
|---|---|---|
network | 标准 HTTP/HTTPS 代理，支持账密注入 | 常规代理服务器 |
url_prefix | 把上游完整 URL 拼到前缀之后转发 | Cloudflare Workers 类反代 |
direct | 显式强制直连，不走任何代理 | 明确要求本机出网 |
node | 通过你自己的执行节点出网，用那台机器的 IP | 需特定地区/内网出口，又不想另买代理 |
- 按账号绑定：每个渠道账号引用代理池条目，不同账号走不同出口。
- 热更新不丢运行态：修改后原地刷新运行中的账号，限流计数、认证状态与冷却记录保留。
- 有登录态的渠道独占连接：避免多账号共用出站连接导致会话串台。
搭建方式：Cloudflare Workers
可以把一个 Cloudflare Worker 作为 url_prefix 的转发入口：Worker 接收平台拼接后的完整上游 URL，再按你的规则转发请求。适合不想维护常驻服务器、且上游允许从 Cloudflare 出口访问的场景。
- 在 Cloudflare Dashboard 打开 Workers & Pages → Create application → Create Worker，创建一个新的 Worker。
- 下载本页附带的
cloudflare-url-proxy-worker.js，把其中的 Worker 代码粘贴到编辑器并部署。 - 为 Worker 绑定一个专用域名或 routes，确认 HTTPS 地址，例如
https://proxy.example.com。不要把带真实上游密钥的 URL 写进公开代码或日志。 - 在管理端进入代理池，新增代理条目：模式选
url_prefix，URL 填 Worker 地址（不要在末尾加/），用户名和密码留空；再把条目绑定到需要经过该出口的渠道账号。 - 先用低风险渠道发起一次模型列表或测试请求，检查 Worker 日志、上游响应状态和流式响应是否完整，再投入生产流量。
代理池条目
模式：url_prefix
URL： https://proxy.example.com
用户名：留空
密码：留空特色：用量口径归一
- total = 输入 + 输出。缓存读、缓存写是输入 token 明细子集，不额外计入 total；不采信上游自报 total，一律用 prompt + completion 重算。
- 零 completion 兜底（协议无关）：usage 里 completion 为 0 但响应确有内容时，删除该 usage 让后续估算兜底；内容检测覆盖 OpenAI/Gemini/Anthropic/Responses 各类帧。
- 口径一致：管理端面板与主链路使用同一套 usage 归一逻辑，避免两处口径漂移。
特色：八类测活场景
测活不是只发一句 "hi"。平台提供八类测试场景——对话/流式/工具调用/思考/多轮/图片/视频/语音，类型列表可自定义。测试可指定模拟哪种客户端、走渠道哪条协议链路，与真实流量同源；通过自动解除该账号运行时冻结。另有定时巡检、模型列表刷新与余额探测。
特色：请求级实时记录
请求开始与结束都在同一次尝试里实时落库而非事后补写。一次客户端调用对应一个 request_id，其下每次渠道尝试单独成行并按序编号：哪个账号试过、走什么路径、成功还是失败、首 Token 多久、各类 Token 各多少，都能按 request_id 追到完整序列。PostgreSQL 是权威存储；ClickHouse 只做大字段 payload 旁路双写，失败只丢批、不影响主链路。