云 API 按需
开通快、免运维，适合验证期与波动业务。为什么延迟不可控：共享资源下受网络与排队影响，高峰期波动明显。做法：设超时与降级，把云 API 放在可替换的适配层后面；边界是关键路径不宜只依赖单一区域，否则一次网络抖动就会放大成事故。
预留吞吐与专属实例
为稳定负载预留容量，能显著降低排队带来的尾部延迟。怎么做：先测峰值并发与单请求耗时，再按目标水位预留；边界是预留按容量计费，利用率低时单位成本上升，需要按业务节奏调整，不能一次签长约。
本地单机与多机
本地部署减少网络跳数，延迟可控，但受硬件与批处理策略影响。为什么容易误判：单机空载测试很快，上量后排队严重。做法：在目标并发下实测，而不是空载跑分；边界是多机推理的通信开销会抵消部分收益。
端侧小模型
把简单任务放在端侧或近端，首字几乎无等待，适合分类、纠错与格式化。怎么做：按任务复杂度分流，复杂请求再上行；边界是端侧算力与模型体积受限，效果与隐私要求要单独评估，不能直接套用服务端结论。
分层组合
小模型先答、大模型补充，或缓存直出加模型兜底，是常见组合。为什么有效：多数请求是简单重复的，分层能把平均等待压下来。边界是分层会增加一致性维护成本，回答风格要统一，否则用户会感到割裂。
适用与不适用
适合谁
- 客服、工单等对响应速度敏感的业务负责人
- 在云 API、专属实例与自建之间做取舍的架构师
- 要为大促或开学季做容量准备的运维团队
不适合谁
- 没有明确延迟目标、只要求功能可用的内部系统
- 流量极小、不足以做分层设计的业务
典型场景
某在线客服的响应在促销期明显变慢。团队先测出瓶颈在排队而非模型本身，于是把常见问题改为缓存直出、简单咨询走小模型、复杂工单才调用大模型，并为大模型调用设了超时与转人工。改造后高峰期的尾部延迟收敛，人工介入也有了明确的入口。
可执行步骤
- 先在目标并发下测出真实延迟与瓶颈位置，记录各环节的分段耗时数据
- 按请求复杂度划分三档处理路径，明确各档的分流规则与准入条件边界
- 为每一档选择部署形态，设定对应的超时、降级动作和提示文案内容
- 用灰度发布验证各档的实际体验，记录分位延迟变化与相关投诉量趋势
- 保留人工兜底入口，并统一各档回答风格，避免用户明显感到体验割裂与混乱
常见坑
- 用空载跑分来选型，上量后排队严重，实际体验与测试结论差距很大，返工时要重做架构与容量方案。
- 所有请求都走大模型，简单问题也要付出高延迟，容量被大量浪费，单位成本长期居高不下且难以彻底压降。
- 分层之后各档回答风格不一致，用户明显感到割裂，投诉随之增加，口碑与复购意愿一起下滑。
- 没有超时与转人工入口，慢请求会长时间挂起，用户只能反复刷新页面等待，最终流失到别的平台上去。
自检与验收清单
- 是否在目标并发的条件下做过端到端延迟实测记录
- 请求是否已按复杂度分档，各档的分流规则是否清晰
- 每一档是否都设置了明确的超时时间与降级动作
- 灰度发布是否覆盖业务高峰时段，是否记录了数据
- 人工兜底的入口是否明确，用户是否都容易找到并使用
常见问题
云 API 高峰期慢是正常的吗？
共享资源下高峰排队是常见现象，但可以通过限流、队列与降级把影响控制住。关键是提前测出自身峰值与云侧的分位表现，并在设计上允许切到备用路径，而不是等故障发生后再临时处理。
自建一定能压住尾部延迟吗？
不一定。自建减少网络跳数，但排队、批处理与显存管理仍会造成长尾。要看是否在目标并发下实测过、是否有容量水位与降级机制，单看空载跑分无法判断真实表现与上限。
分层会不会让回答不一致？
会，如果不统一风格与知识来源。常见做法是统一系统提示与知识库，按任务分配模型，并在返回时标注来源。分层带来的复杂度要用评测集持续验证，否则用户会感到不同入口答案差异明显。