你可能已经能调通一个模型接口，但要给团队或客户交付一个「平台」，问题立刻变成一堆：网关放哪、额度怎么扣、会话历史存哪、出问题怎么排查。这篇不贴代码，只给一张能照着走的分层架构图和落地顺序，帮你判断哪些模块第一版必须做、哪些可以后补，以及计费和授权这两件容易被忽略的事该在哪一步对齐。
能调通一个模型接口，和能交付一个平台，中间隔的不是代码量，是一堆必须先想清楚的取舍：网关放哪、额度怎么扣、会话历史存哪、线上出问题从哪查起。很多团队卡的不是技术难点，而是不知道第一版该做多少。
下面这张分层地图和落地顺序，是给「已经能跑单个接口、现在要交付给团队或客户」的人看的。不贴具体代码，只给判断标准和动作，你照着砍模块、排顺序就行。
先把分层划出来：平台到底由哪几块组成
典型平台分五层：接入层管网关与鉴权，编排层管提示词模板、工作流与工具调用，模型层对接官方 API 和自建推理，数据层存会话、文件与向量，运营层管额度、日志和监控。这套分层不是为了好看，是为了让每层能被单独替换。
- 接入层
- 统一入口，负责身份校验、限流、请求转发，业务代码不直接碰模型 SDK
- 编排层
- 提示词模板、多步工作流、工具调用编排，决定「怎么问」而不是「问谁」
- 模型层
- 对接多家官方 API 或自建推理，把参数、返回、错误码差异全部吃掉
- 数据层
- 会话历史、上传文件、向量索引，决定上下文能续多久、能查多远
- 运营层
- 额度扣减、调用日志、监控告警，是上线后唯一能救你的那层
判断某层要不要抽，标准只有一条：不抽这层，将来换模型或换供应商时，业务代码需不需要重写。要重写就抽，不要重写就先别抽。小团队最常见的问题是编排层和业务逻辑焊死，结果换个模型要改十几处。
第一版做多少：按交付目标砍模块
先回答一个问题：这东西给谁用。内部团队自用、给客户做 SaaS、给业务方做中台，第一版范围差别极大。内部用只要有统一调用入口、密钥集中管理、基础日志就能跑；SaaS 才需要额度扣减、多租户隔离、账单导出。
- 第一步：统一调用入口所有业务只调一个内部接口，不许直连厂商 SDK；验证方法是全局搜厂商关键字，业务目录里应该搜不到
- 第二步：会话与上下文管理决定历史存哪、截断规则是什么、多轮怎么拼；验证方法是同一会话连续多轮后，上下文长度不爆
- 第三步：额度与限流先做计数和拒绝，再做精细分账；验证方法是人为把额度调小，看接口是否按预期报错而不是静默失败
- 第四步：可观测请求日志带上耗时和用量，错误按类别打标；验证方法是随便挑一条失败请求，能否在日志里还原全过程
- 第五步：多租户隔离数据、额度、密钥三处都要隔离；验证方法是跨租户查数据应该查不到
不适用的情况也说清楚：如果业务方开工前就明确要求按月出账单或按人分账，那额度与计量模块必须提到第一版，不能当成「以后再说」。数据和额度一旦混住，后面拆起来比重做还贵。
模型路由与降级：多供应商怎么接才不乱
路由策略分三类：按任务类型固定路由、按成本优先降级、按延迟优先降级。先明确你优化的是哪一个，否则规则会互相打架。同一个请求被两条策略同时命中，行为就变成不可预测。
| 策略 | 适用场景 | 要接受的代价 |
|---|---|---|
| 固定路由 | 对输出一致性要求高的结构化任务 | 某家不可用时只能整体失败 |
| 成本优先降级 | 大批量、对质量容忍度高的任务 | 输出风格会漂移 |
| 延迟优先降级 | 交互式对话、按需响应 | 可能命中额度更紧的供应商 |
降级链必须有，但要有配套：主模型超时或限流时切备用，涉及结构化输出的场景要单独做格式校验，不能默认换模型后返回还能被解析。供应商差异集中在请求参数、返回结构、错误码三处，逐个映射成内部统一格式，别让上层感知。
计费口径与额度：别等上线了才算这笔账
先把计费单位对齐：输入和输出是不是分开计价、缓存命中怎么算、图片和视频按张还是按步。口径不同，同样调用量的预算能差出好几倍。平台侧建议记两本账，一本是真实成本，一本是租户配额，别混在一张表里。
- 成本账：按实际调用量统计，用来做预算和供应商比价
- 配额账：按租户或用户统计，用来做限流和分账，可以和成本账口径不同
- 额度耗尽的行为要写进接口返回：直接拒绝、降级到便宜模型、还是排队，取决于用户能不能接受延迟
- 静默处理是大忌，用户看到的是「变笨了」而不是「额度没了」，投诉会翻倍
单价和折扣口径会随厂商调整，别凭印象拍预算。到 /official-api 和 /tools/token-price-calculator 核对当时的数字，把差额和缓存规则一起看，不然预算表看着对、月底照样超。
上线前核对清单：授权、隐私与可观测
上线前最容易漏的是授权和隐私，出问题时往往已经交付给客户了。授权边界要逐条确认：模型是否允许商用、输出内容归属怎么约定、是否需要保留署名。这些去 /safety 和对应厂商页核对，别等客户问才查。
数据处理同样要提前写清楚：用户上传的文件和对话历史存多久、存在哪、能不能被用于训练。涉及跨境传输的场景要单独评估。可观测三件套是请求日志（含耗时与用量）、错误分类统计、质量抽检，缺一样，线上出问题就只能靠猜。
| 排查顺序 | 先看什么 | 常见结论 |
|---|---|---|
| 一 | 密钥是否有效、额度是否耗尽 | 多半是自己这边配置问题 |
| 二 | 供应商侧是否限流或抖动 | 看错误码和返回头 |
| 三 | 提示词与模型能力 | 前面都排除了再怀疑这里 |
这套顺序不适用的情况：你的平台有自建推理节点，那要先看节点健康和排队情况，再去查密钥和额度。
下一步架构分层可以照抄，但计费口径和供应商表现得看当时的数据。到 /price-watch 看价格变动记录，再到 /sites 挑几家做小流量实测，比拍脑袋选型稳得多。→常见问题
一个人开发，能不做网关直接调官方接口吗？
短期可以，但建议至少把密钥读法和调用封装抽成一个内部函数。否则密钥散落在各处，换模型、加日志、做限流时都要翻一遍代码。封装成本很低，省下的是后面每次改动的时间。
平台该自建推理还是直接接官方 API？
先看量级和稳定性要求：调用量小、要快速上线，接官方 API 更快；量大有稳定峰谷、对单次成本敏感、或者数据不能出内网，才考虑自建推理。中间还有托管推理这条路，可以去 /compute/finetune 对照成本口径再决定。
怎么判断平台该不该做多租户？
看有没有「按人出账」或「数据必须互相隔离」的需求。只要出现其中一个，多租户就要在第一版做，后补的代价是数据表结构大改。纯内部工具、大家共用一个额度池的，可以先不做。
