Toonflow 里怎么配置模型供应商折扣渠道，倍率、模型映射和分组该按什么顺序设？

在 Toonflow 配置模型供应商折扣渠道，正确顺序是先把上游计费口径和真实模型名核清，再建渠道并完成模型映射，随后按采购成本倒推渠道倍率，最后用分组、令牌范围、优先级和回退策略控制调用；只使用单一官方直连、或拿不到上游计费口径与模型清单的账号，不应把折扣渠道放进正式候选池。这个顺序的关键在于，折扣不是给账号打一个全局折扣，而是让某一条渠道具备独立计价和独立可见范围，任何一步缺失都可能出现“接入了便宜上游，账面仍按原价结算”或“请求落到更贵模型”的结果。 折扣渠道不是全局开关，而是绑定在渠道上的计价参数与可见范围。Toonflow 的计费以渠道倍率为基础，一次调用走哪条渠道，就按哪条渠道的价格记账，因此“接入便宜上游”和“按便宜价格结算”是两件事。只新增渠道而不改倍率，账面上仍然是原价；只改倍率而没有把请求真正路由到该渠道，同样不会产生折扣。配置前要把渠道当成一条独立供应链来管理，明确它的上游、模型、价格、并发、稳定性和可调用对象，再决定是否让它参与正式流量。 第一步不是建渠道，而是把上游计费口径问清楚。输入输出是否分开计价、是否按次计费、缓存命中是否减免、有没有阶梯价与最低消费，都会影响本地倍率的倒推方式。口径没确认就设倍率，本地折扣价和上游账单必然对不上，跑量越大越难追溯，最后只能靠人工补差。更稳妥的做法是让上游提供可核对的账单样例或计费说明，把输入、输出、缓存、失败重试分别列清，再进入 Toonflow 的渠道配置。 新建渠道要填三类信息：渠道类型是否走 OpenAI 兼容协议、上游 Base URL 与密钥、该渠道支持的模型清单。Base URL 最常见的问题是路径前缀，兼容协议一般要写到 /v1 这一层；路径写浅了返回 404，密钥填错返回 401，两者排查方向完全不同。模型清单也要与上游实际能力同步，清单里写了但上游没开的模型，会在调用时表现为模型不存在；上游已开但清单没写的模型，则不会进入路由候选。先把这三类信息做成可复核的记录，再保存渠道，能减少后续反复改配置。 模型映射决定请求发出去时用的是哪个真实模型名。把对外暴露的名称映射到上游实际模型后，映射错误会出现两种结果：上游返回模型不存在，或者请求落到另一个更贵的模型上，折扣瞬间变成溢价，而且日志里往往看不出来。配置时要逐个模型核对映射关系，尤其是同名模型的不同版本、带日期后缀的版本和上下文长度不同的版本，不能只看名称相似。映射完成后要用一条最小请求验证返回内容与模型标识，确认请求没有在中间层被改写到其他模型。 倍率要按采购成本倒推，不能照抄别人的数值。倍率是本地计价的乘数，低于成本线时用量越大亏得越多；高于成本线太多，又会让折扣渠道失去价格意义。稳妥做法是先给小额额度跑通链路，拿一次真实上游账单反算单价，再把倍率固定，并用少量请求确认它确实生效。反算时要区分输入与输出、缓存与非缓存、成功与失败，不能只用总金额除以总次数。若上游存在阶梯价或最低消费，还要按预计月用量分档测算，避免小流量测试时看着便宜、正式放量后成本抬升。 分组决定谁可以用这条折扣渠道。把折扣渠道放进独立分组、只对指定令牌开放，可以避免高价值业务被误路由到稳定性较弱的上游；不隔离分组时所有请求共享同一候选池，一旦折扣上游限流，影响面会扩散到整站。分组不是越细越好，而是按业务重要性和成本敏感度划分：核心链路留在官方直连或稳定渠道，成本敏感、可重试的业务才进入折扣分组，测试令牌单独一组，避免测试流量污染正式账单。 路由参数决定折扣渠道在什么时候被调用。优先级高、权重大，请求就优先走它；折扣上游的并发和稳定性通常弱于官方直连，更稳的配法是压低优先级、只做分流或备用，同时设好重试次数与超时，避免一次超时拖垮整条链路。重试要有边界，不能对限流和超时无限重试，否则一次上游抖动会放大成本；回退目标要明确，主渠道失败后回到哪条稳定渠道、哪些错误码允许回退、哪些错误码直接返回，都应在配置阶段定好。 配置完成后先做连通性验证，再做并发验证。逐个模型发一条最小请求，确认返回正常且 token 消耗与预期一致；再用接近真实业务的并发压一轮，看 429 和超时比例，这一步能提前暴露上游的实际承载能力，比上线后被动救火便宜得多。连通性验证关注的是“能不能用、模型对不对、计费参数是否生效”，并发验证关注的是“高峰能不能扛、限流后如何回退”。两项都通过，再给正式令牌放量；任一项不通过，先降权或留在测试分组。 上线后按渠道维度看日志，是判断折扣渠道值不值得留的唯一依据。重点看成功率、首字延迟、单位请求消耗三项，任何一项明显劣化，都说明这条渠道的价格优势已经被稳定性问题和重试成本吃掉，应当降权或下线。日志还要能区分请求落在哪条渠道、命中了哪个映射、实际消耗多少 token，否则看到总账单变化也无法定位原因。对折扣渠道要设置观察期，观察期内只承接可回退流量，不承接不可中断的核心任务。 对账节奏建议固定到周。把本地按渠道统计的消耗与上游账单逐条比对，持续出现差异通常来自倍率设置、缓存计费、模型映射三处，而不是统计误差；找到差异源之后要回写配置，而不是每次都手工调账。对账时要把失败重试、限流重试和缓存命中单独列出，这些项目最容易在上游账单与本地统计之间形成差额。若差异来自上游口径变化，应暂停放量并重新测算倍率，不能沿用旧倍率继续跑。 折扣渠道多来自转售或代理，数据留存、密钥安全和服务等级都要单独评估。需要官方 SLA 的核心链路不适合把折扣渠道作为唯一依赖，只能做旁路分流；上游协议中明确禁止转售的，接入本身就带合规风险，这类渠道即使便宜也不该进候选池。渠道密钥要按最小权限管理，能单独吊销就单独吊销；请求日志中避免留存敏感内容，跨境或第三方转售场景还要确认数据流向。几类高频故障可以直接对照现象定位：模型不存在查映射与清单同步，401 查密钥与路径，429 查并发与权重分配，倍率不生效则先确认请求是否真的落在目标渠道。把这几条做成上线检查表，比事后翻日志快得多，也能让后续新增折扣渠道时少走弯路。