智能工作流并发上来先守住哪条线把大模型接进单据、客服或审核流程后请求数不再是唯一的压力指标。同样数量的请求输入长度、输出上限、工具调用和供应商配额都可能不同。系统在高峰时失控常见原因不是某一处限流器写错而是入口、队列、worker 和外部模型之间没有统一的容量边界。第一步是画出请求会经过的路径上传或提交、预处理、模型调用、规则校验、人工复核、落库。每一段要有可接受的等待时间和队列容量。容量不是越大越好无界内存队列只是把拒绝延后到进程内存耗尽时发生。队列满时应明确选择立即拒绝、延后处理、仅接收高优先级任务或退回不依赖模型的流程。限流要同时看请求和工作量供应商可能按请求数、输入或输出 token、并发连接以及不同模型分别限制。业务侧也有自己的成本和公平性要求。入口可以根据已知输入和输出上限做保守估算但字符数不能准确换算 token尤其是多语言文本、图片和工具上下文。估算是调度信号不应被当成计费事实。实际用量返回后应当把它记录到任务账本中用于调整后续预算和报警。为了避免某个租户占满全部能力限额至少分为全局、租户和单任务三层。重要的是拒绝响应要可操作告诉客户端是稍后重试、进入队列还是需要缩小输入不要把所有情况都伪装成普通 500 错误。type Admission struct { EstimatedUnits int64 Priority string } func decide(admission Admission, available int64, queueFull bool) string { if admission.EstimatedUnits available { return queue_or_reject } if queueFull admission.Priority ! high { return reject } return accept }这个例子没有实现令牌桶也没有替代供应商返回的限流信息。生产实现还要考虑并发安全、时钟、额度刷新、任务取消和多实例共享状态。把决策和执行拆开至少能让拒绝原因更容易测试和观察。异步队列要有状态和幂等性对于不要求立刻完成的单据处理提交接口可以先校验基础字段并创建任务再由 worker 按容量拉取。客户端拿到任务 ID 后查询状态或订阅事件。这样能够吸收短时波动但前提是任务有清楚的生命周期例如queued、running、succeeded、failed、cancelled而不是只留下“正在处理”。重试同样要沿着状态机设计。网络超时不等于模型没有执行写入业务系统的操作也可能已经成功。对每次提交使用幂等键保存外部调用标识重试前查询已有结果必要时由人工处理不确定状态。只有确认可安全重试的故障才使用指数退避和随机抖动权限错误、输入校验错误通常不应重试。降级要保持业务语义诚实模型不可用时很多流程可以退回规则校验、人工队列或稍后处理。但降级结果必须让用户和后续系统知道其依据变了。例如“已完成智能核验”和“已完成基础字段校验等待复核”是不同状态不能用同一个成功标记混过去。对于高风险决策降级到更保守的结果往往比自动放行更合适。预处理阶段也值得单独限额。大图片、压缩包或视频解码可能在模型调用前就耗掉大量内存和 CPU应限制文件类型和大小把重计算放到受控 worker并为任务设置整个链路的截止时间。用压测结果指导阈值压测应模拟输入长度分布、真实的外部错误比例、重复提交和 worker 慢启动而不是只发送同一种小请求。观察排队时间、拒绝率、端到端延迟、实际 token 用量、内存和重试次数并按租户与工作流版本拆分。若某次提示词更新让平均输入变长单看请求数可能完全看不出容量正在下降。并发增长前最该守住的是准入边界系统要知道哪些请求可以立即开始、哪些需要等待、哪些必须被拒绝或转交。队列、限流和降级围绕这条边界协作才能避免一次上游波动扩散成整条工作流的故障。
尧图网络