打算给团队搭一个能调各家大模型的应用平台，最容易犯的错是先挑模型、再补架构。等业务接进来才发现：换一家模型要改业务代码，额度烧超了没人预警，出问题只能整站停。这篇按设计顺序讲四道关，每关给能照着做的判断标准和动作，最后附一份上线前的自查清单。
打算给团队搭一个能调各家大模型的应用平台，最常见的走法是这样的：先花一周对比榜单，挑一个看起来最能打的模型，接进业务里跑通，再回头想架构。等第二个业务方进来、想换一家更便宜的接口、或者某个接口突然开始超时，才发现业务代码里到处写着具体厂商的名字，换一次要改十几个文件。这不是选型失误，是顺序错了。
平台这件事，说到底是在业务和模型之间垫一层。垫得好，模型随便换，业务不用动；垫得不好，平台本身就是最大的技术债。下面按设计的先后顺序讲四道关，每关给一个能当场验证的判断标准，最后附一份上线前照着过的清单。别急着装东西，先把标准定下来。
先说顺序：为什么不能先挑模型
模型这个东西变化太快了。今天便宜的明天可能涨价，今天能用的明天可能限速收紧，今天的主力模型过阵子就下线。如果业务逻辑绑在一个具体模型上，那每一次上游变动都会变成你的需求。所以平台设计的第一约束不是模型强弱，是「业务改一次需求要动几处代码」。这个数字越大，后面越难收场。
具体要先划清三个边界：谁负责调模型、谁负责算钱、谁负责兜底失败。这三件事听起来像废话，但很多团队是混着来的——业务方自己引 SDK 调接口、自己看后台账单、接口挂了就自己加重试。等到月底对账对不上、高峰期集体超时，就开始互相甩锅。把这三件事各归一个模块管，是后面所有讨论的前提。
这里有个很常见的误判：一上来就对比各家榜单和价格，看到某个接口便宜就定了，结果它限速很严，业务高峰全靠重试硬扛，重试又放大并发，最后把对方接口打到限流，整条链路雪崩。便宜不是错，错在没先确认它在你的峰值场景下撑不撑得住。
- 判断标准一：把模型当成可替换的零件，凡是业务代码里出现具体厂商名的位置，都算设计缺陷，数一数有多少处
- 判断标准二：换一家模型，从决定到上线需要几个人几天，超过一个人的半天就要重新看架构
- 判断标准三：调用失败时，业务方需不需要知道背后是哪家厂商挂了，需要知道就说明兜底没做在平台里
接入层：把厂商差异收敛在一个地方
接入层要干的事很朴素：业务只认「发消息、要结果」这两个动作，具体走哪家、用什么参数，由平台内部的路由决定。听起来简单，麻烦在细节。各家对多模态请求的字段名、尺寸限制、返回结构都不一样，图片、音频、视频这几类尤其乱。这些差异如果不在这里抹平，就会以「每个业务各自适配」的形式摊到整个团队。
我建议在接入层沉淀一张映射表，把每家的请求字段、返回字段、错误码、超时行为列清楚。新增一家厂商时，你只需要往这张表里加一行，再加一个适配器，而不是去翻业务代码。这张表本身就是平台的资产，谁接手都能看懂。
- 先定内部接口用两个动作描述所有调用：提交一次生成请求、查询一次结果。参数里只出现业务语义，比如内容类型、长度上限、是否需要结构化输出，不出现任何厂商特有字段
- 再写适配器每家厂商一个适配器，负责把内部请求翻译成对方格式、把对方返回翻译回内部结构、把对方的错误码归一到统一错误类型
- 最后加路由路由按业务线、内容类型、成本档位决定走哪家，路由规则放配置里，改规则不发版
- 验证方式新增一家厂商，数一下改了几个文件。超过两个就说明收敛不到位，先回去重构再接新模型
顺带说一句，团队里对底层术语理解不一致的时候，先对齐定义比翻各家文档快。比如上下文窗口、温度这类概念，各家叫法和取值范围不一样，站内词典有基础概念对照，可以去 /ai-dict/category/basics 查一遍再讨论，省掉很多鸡同鸭讲。
计费口径：按量、按次、按套餐，账要能对上
计费这块最容易出的问题是口径混着比。按 token 算、按请求次算、按月订阅打包额度，这三种单位的数字放在一起没有任何可比性。你在 A 家看到每百万 token 多少，在 B 家看到每次调用多少，直接乘一下调用量做预算，出来的数一定是错的，因为输入和输出的计价往往不一样，缓存命中与否也可能不同价。
平台侧至少要能按三个维度出账：业务线、模型、调用类型。缺任何一个，月底你都回答不了「钱花在哪条业务上」这个问题。这不是财务洁癖，是资源分配的依据——哪条业务在烧钱、烧得值不值，得有数才能谈。
| 计费口径 | 适合的场景 | 平台要额外做的 |
|---|---|---|
| 按 token 用量 | 调用量大、输入输出长度差异明显的业务 | 分别统计输入输出，按模型归档 |
| 按请求次数 | 请求短、频次高、结果长度稳定的场景 | 按业务线计次，防止重试被重复计数 |
| 按月订阅额度 | 用量平稳、可预估的长期业务 | 跟踪额度消耗进度，提前预警 |
| 混合计价 | 厂商对不同能力分开收费 | 拆到能力维度，别混在一个总账里 |
换算的时候别拿宣传页上的单价直接乘。先用站内的价格与用量换算工具跑一遍实际调用结构，再去 /price-watch 核对当时的数字，各家调价频繁，写死在文档里的价格过两周就过期了。
什么情况下不用做这么细：内部试验期、单人使用、调用量极小的场景，精细出账的成本高于收益，先用一个总量上限兜住就行。等业务方多起来、有人开始问「为什么我们这条线费用涨了」，再补维度也不迟。
限流与降级：出问题的时候平台得顶住
每家接口都有并发和频率上限，这个上限可能写在文档里，也可能没写清楚但实际存在。平台的责任是在入口做排队或削峰，而不是把失败原样抛给业务方。业务方看到的是一个失败，用户看到的是转圈，这两者之间的差距就是平台该填的坑。
降级链路要提前排好，不能等出事再想。顺序大概是这样：主模型超时，切备用模型；备用也挂，返回缓存结果或者一个明确的失败提示；两者都做不到，至少给用户一句人话，而不是让页面一直转。降级的关键是「提前」，因为出事那一刻没人有空设计。
判断标准很直接：模拟一次主接口不可用，看业务能不能在几秒内给出可用结果。做不到，说明降级只写在文档里，没写进代码。这个演练建议每月做一次，手动断开主接口就行，不用真等故障。
监控盯两个数就够了：失败率和首字延迟。前者反映接口是否可用，后者反映用户感受。两个都掉才算真故障，只有一个掉通常是局部问题，别急着全站告警。告警阈值按业务能忍的程度定，不按行业惯例定。
数据边界：哪些内容不能出内网
数据这块要先分类再选路。公开资料、内部文档、用户个人信息，这三类数据的出网权限应该完全不同。公开资料走公有接口问题不大，内部文档要看合同和合规要求，用户个人信息基本不该出内网。分类不做，后面所有讨论都是空谈。
平台侧要有一个开关，能在不改业务代码的前提下，把某类请求强制路由到本地或私有部署的模型。这个开关的价值在于：合规要求变化时，你改的是配置，不是业务。没有这个开关，一旦某类数据被要求不能出网，你能做的只有整站换方案。
判断标准：能不能按租户或业务线单独关掉出网。只能整站关，说明粒度太粗，实际用起来会卡住——一条业务线有合规要求，其他线跟着停，没人会接受。
具体条款不用自己从零写。站内安全与合规分区有术语和口径对照，先去 /guides 找到对应分区，把「敏感数据」「出网」「留存」这几个词的定义对齐，再谈实现。定义不一致，实现一定跑偏。
上线前照着过一遍的清单
四道关都过一遍之后，上线前还有一组动作要做。这些动作不是走形式，每一个都能暴露你架构里的真实缺口。建议找个下午，拉上负责业务和负责平台的人一起过，当场记录结果，别写成「已完成」糊弄过去。
- 接入层：把「换一家模型需要改哪些文件」实际跑一遍，数出真实数量，别凭印象估
- 计费：随机抽三条业务线，看后台能不能拉出各自的用量和费用明细，拉不出来就是维度没打通
- 降级：手动断开主接口，记录业务返回时间和提示文案，自己看一眼能不能接受
- 数据：列出所有会出网的请求类型，逐条确认有对应的开关和责任人，没责任人的标红
- 监控：确认失败率和首字延迟两个指标都在看板上，且有人负责响应告警
清单过完，大概会暴露几个问题。正常，这说明清单有用。把它们排个优先级，先修影响面最大的那个，别一次全改。平台是长出来的，不是一次设计完的。
平台设计的好坏，不看上线那天多顺，看换模型、涨流量、出故障这三个时刻有多从容。下一步：把选型放进真实数据里看四道关定完，接下来才是挑具体厂商和接口。别只看宣传页，到站内的中转站可信度检测和价格追踪页面，按你实际的调用结构核对当时的数字和稳定性记录，再决定接哪家。→
常见问题
团队只有三五个人，也要做这么完整的接入层吗？
不用按大厂规格铺。最少保留两件事：一处统一的调用入口，一份记着各家参数差异的配置表。业务量小的时候路由可以写死，但别让厂商名散落在业务代码里，否则换模型那天就是通宵。
平台自己算费用，和厂商账单老是对不上怎么办？
先确认口径：输入输出是否分开计价、重试的请求算不算、流式返回的截断怎么记。把这几项和厂商文档逐条对齐，误差通常来自重试和缓存命中。对不上的部分宁可留一点余量，别按理论值卡死预算。
降级切到备用模型，效果变差用户能接受吗？
要看场景。客服问答和内部工具能接受，涉及合同、财务结论的场景不建议自动降级，宁可明确报错让人来处理。降级方案要按业务分级，不是所有请求都走同一套。
多模态能力什么时候接进平台比较合适？
等业务明确要用图片或音频时再接，别为了平台「完整」提前铺。多模态的字段差异和限额比纯文本复杂得多，没有真实需求时接进来只会增加维护面。接之前先到站内平台目录看各家支持范围。
模型价格一直在变，平台设计要为此留什么口子？
把模型标识和计费参数都做成配置，别写进代码常量。价格变动时只改配置，不动业务。定期看一次站内的价格变动记录，比等到账单出来才反应要从容得多。
