高强度业务，需要的是有边界的持续运行，而不是无限制地同时执行。
先描述负载的真实形态
同样是一百个任务，短文本请求、代码构建和视频生成的资源需求并不相同。记录任务类型、输入大小、持续时间、峰值时段和失败后的影响。
将交互式任务与批量任务分开评估。前者关注等待时间，后者更关注总体完成率和单位成本；不能用单一响应速度判断整个系统。
为每层资源设置上限
模型接口需要遵守速率、并发和额度限制；运行环境需要控制 CPU、内存、磁盘与网络；应用还要限制队列长度和单任务执行时间。
媒体任务可能单独计费，并有不同的任务状态与查询周期。没有明确预算和退出条件的后台循环，会放大故障和成本。
设计超时、退避与隔离
对于暂时性错误，可以在有限次数内延迟重试；认证错误、参数错误或余额问题则应先修正原因。不要对所有失败采用同一种重试策略。
把任务按类型或优先级隔离，避免一个长任务拖住全部用户。可能产生费用的提交必须考虑重复执行风险，先核实任务状态再决定重发。
用实际测试建立容量基线
从少量任务开始逐步增加负载，记录完成时间分布、成功率、费用和资源峰值。检查系统在异常条件下能否停止、恢复和保留正确结果。
不仅测正常路径，也测试网络中断、依赖不可用和磁盘不足。性能数据应注明运行条件，不能把某次演示表现直接推广到所有项目。
采购资源之前确认服务规则
确认额度重置周期、超额计费、失败计费、并发限制、可用区域和支持方式。套餐规格只说明部分资源，不是无限吞吐或不中断运行的保证。
需要服务等级、专用资源或特别的数据处理要求时，应先进行技术评估与书面确认。本页提供设计方法，不承诺具体容量或运行时长。