一句话结论
token 集采 平台选型 = 依次回答五个决策节点：模型覆盖、用量规模、预算结构、管理主体、交付形态。答案决定使用聚合网关、自建网关，还是暂不需要集采。
决策树：五个节点
节点 1：模型覆盖
- 单一模型 + 小用量 → 直连即可，集采的聚合价值无法体现；
- ≥2 个主流模型（Astra / Claude / DeepSeek / Qwen…） → 继续评估。集采平台的核心价值即「一个 key 一张模型表」；
- 大量社区冷门模型 → 优先模型覆盖极广的通用市场（OpenRouter），再评估其缓存计费与编码场景优化。
节点 2：用量规模
| 月用量 | 结论 |
|---|---|
| < 10M token | 直连合理，集采收益有限 |
| 10–100M | 值得接入：缓存计价 + 通道比价产生可量化收益 |
| > 100M | 集采为强需求，同步评估专属通道与配额治理 |
用量决定「是否接入」，模型覆盖决定「接入哪类平台」。
节点 3：预算结构
- 按量浮动 → 选择 pay-as-you-go 按量计费，避免预付费沉淀；
- 月度总量可控 → 需用量配额与超限熔断；
- 成本按项目分摊 → 需 key 维度 / 项目维度的账单归因。
预算结构决定治理功能选型，而非价格选型。
节点 4：管理主体
- 个人 → 关注缓存计价与通道比价，治理功能从简；
- 小团队（2–10 人） → 独立 key + 配额 + 基础审计，按 key 归因用量；
- 公司/部门级 → 追加团队权限、审计日志、SLA 与故障切换承诺。
管理复杂度每提升一级，对平台治理能力的要求同步提升一级。
节点 5：交付形态
- 免运维 → 托管聚合网关，仅管理 key 与用量；
- 全链路可控 → 自建开源网关（LiteLLM / One API），自行维护高可用、缓存计费与故障切换。
判断标准：团队能否长期承担网关基础设施的维护成本。不能，则选择托管。
三种典型路径
路径 A：个人开发者
- 需求：多模型、中低用量、免运维
- 选型：托管聚合网关，单 key 接入，依赖缓存计价与通道比价降本
- 规避：自建网关、预付费沉淀、来源不明的低价通道
路径 B：编码 Agent 团队（Claude Code / Codex）
- 需求：Agent 重度调用、多模型分层、按 key 治理
- 选型：Agent 原生网关 + 独立 key + 配额告警，启用缓存计价与分层路由
- 规避：共享 key、无配额、各成员各自直连
路径 C：企业 / 部门级
- 需求：多部门成本分摊、审计合规、链路可控
- 选型：托管网关企业能力（配额/审计/SLA）或自建网关兜底
- 规避：研发各自开号报销导致的成本黑盒
评分模板
按候选平台逐项打分，权重按实际情况调整：
| 评分项 | 权重(1–3) | 候选 A | 候选 B |
|---|---|---|---|
| 模型覆盖匹配 | 3 | ||
| 缓存计费（cached_input 分项计价） | 3 | ||
| 双协议端点兼容 | 2 | ||
| 通道直连资质 | 2 | ||
| 请求级账单 | 2 | ||
| 路由质量（SLA / TTFT / 故障切换） | 2 | ||
| 折扣系数（可解释） | 2 | ||
| 团队权限 / 审计 | 1 | ||
| 合计 |
否决项：独立 key 或请求级账单任一为 0，直接排除。
常见疑问
Q：集采平台能否仅接入单一模型？ 可以，但单一模型 + 小用量下聚合与分层的价值有限，直连更合理。
Q：自建网关与托管网关的成本比较？ 仅比较单价，自建的上游成本可能略低；计入高可用、缓存、故障切换与人力后，自建几乎总是更高。低用量下托管显著占优。
Q：DeepSeek 等低价模型是否仍需集采？ 需要。低价模型同样享受缓存计价与分层路由，且混合场景下按规格分层正是集采的核心收益。
Q：Astra 上线后是否需调整接入层？ 不需要。接入层为配置层，Astra 加入路由表即可；分层路由与缓存计价在现有模型上已即时生效。
总结
token 集采 平台选型 = 五节点决策（模型覆盖、用量、预算、管理、交付形态），按典型路径匹配，以评分模板量化，以独立 key 与请求级账单为否决项。注册 TeamoRouter，按决策树与评分模板逐项核验，一个 key 覆盖 Astra / Claude / DeepSeek。