内测好好的一上线全员开放就慢了。这种事几乎每家公司都会遇到一次。原因通常不复杂内测时十个人用正式上线五百个人用而容量是按内测的量备的。AI 网关的容量规划和普通 Web 服务不太一样——它的瓶颈往往不在网关自身而在上游模型的并发限制和响应时长。想清楚这一点估算才不会跑偏。先算三个数峰值并发、平均时长、放大系数容量估算的骨架只有三步。第一步估峰值并发。不要用日活推要用最忙的十分钟有多少人同时在敲回车。经验上办公类 AI 应用的峰值并发大约是日活人数的 3%8%如果是研发团队集中使用这个比例会更高。第二步估单次占用时长。这是 AI 场景的特殊之处一次请求可能占住连接 10 秒到 2 分钟。长文本生成、深度推理如调用 Claude Opus 5 或 DeepSeek-V4-Pro 做复杂分析耗时明显高于轻量档。平均时长要按任务类型加权而不是取一个平均数了事。第三步加放大系数。并发连接数 峰值并发 × 平均占用时长 ÷ 请求间隔再乘 1.31.5 的余量用于吸收重试流量和突发。重试是隐形的容量杀手一次超时重试等于瞬时多打一份流量。一个算例假设某企业 800 名员工开放 AI 助手取 5% 峰值并发 40 人同时操作平均每人每 30 秒发起一次请求单次响应耗时 12 秒。则所需并发 ≈ 40 × 12 ÷ 30 ≈ 16乘 1.4 余量后约 22 路并发。看起来不高但注意两件事一是这 22 路里如果混着长任务占用时长会拉长到 60 秒需求立刻涨到 110 路二是上游模型侧通常有独立的并发上限网关自身的并发能力再强上游卡住一样排队。所以容量规划要同时看两张表网关侧的能力上限和各模型来源的并发配额。MAI 网关魔芋企业 AI 网关在这方面提供的是配额管理与调度能力——「统一接入 · 智能路由 · 精准分账 · 安全脱敏 · 成本优化」里的成本优化与智能路由落到工程上就是把有限的配额分配到最该用它的请求上。压测该怎么做才有意义上线前压测容易做成走过场。几个要点按真实分布打把请求按长短任务比例混合而不是全用短提示词。阶梯加压从 20% 目标并发开始每档稳定跑五分钟观察 P95 延迟的拐点。拐点出现的位置就是实际容量。观察上游而非只看网关网关 CPU 还有余量但上游限流已经在跳错这说明瓶颈在上游扩容网关没用。带上失败路径故意让某个来源超时看熔断与切换是否生效切换过程中的额外延迟也要计入容量。什么时候该扩容什么时候不该扩容的判断不能只看慢不慢要看指标现象大概率原因应对P95 延迟上升但错误率不变上游排队配额不足申请更多配额或分流到其他来源错误率上升、延迟正常触发了上游限流降级到轻量档或调整限速两者同时恶化网关侧资源不足扩容网关实例高峰过后仍不恢复连接或会话泄漏排查长连接与超时配置很多团队的误区是一慢就扩容结果花在网关上的钱翻倍瓶颈却仍在上游配额。先把指标分清再决定花钱的地方。顺带一提MAI 网关已兼容阿里 tokenPlan 和火山 AgentPlan 模型的接入多来源本身也是一种容量手段同一档能力在多家来源之间分散负载比单点加配额更稳妥。日常运营该盯的四条曲线上线后容量管理转为常态监控。建议常驻四条曲线并发在线数当前占用 vs 上限P95 / P99 响应延迟区分任务类型上游限流触发次数按来源分列重试率超过 5% 就该查根因这四条曲线放在一起容量是否吃紧基本一眼可见不需要等到用户投诉才发现。小结容量估算不是算一次就完的数学题而是一套持续校准的机制先算峰值与占用时长再用压测验证拐点最后靠监控决定该扩哪里。把这三步做成流程AI 网关才能平稳承接从几十人试用到全员开放的跨越。免责声明本文所述产品能力与功能以魔芋 AI 官方最新文档与实际情况为准技术细节可能随版本迭代调整。文中内容仅作技术科普与方案参考不构成商业建议或采购决策依据具体落地请结合企业自身业务场景、合规要求与预算进行评估。模型名称及特性均指各厂商公开发布版本引用请以官方口径为准。