一、四十个任务堆到一起以后运营同事在后台一次提了四十个生成任务其中十二个挂在网页版模型上剩下二十八个走标准接口。我们当时用的是一个统一的线程池池子里八个 worker 抢任务。这一批跑完用了五十二分钟比预估的二十五分钟多出一倍多日志里能看到大量网页版任务排在接口任务前面占着 worker而接口任务本身只要十几秒就能返回。比慢更麻烦的是网页版任务之间会互相打断。有两个任务几乎同时开始各自拉起一个浏览器实例去开对话页结果两个实例都在登录态校验上失败任务双双报错重试之后有一次又成功了。线程池的并发度是八但网页版模型真正能承受的并发只有一池子里多出来的那七个 worker 对它毫无意义反而成了事故来源也让重试策略变得难以判断。这一批里耗时最长的一个网页版任务跑了六分十秒最短的只用了三十一秒波动接近十二倍。接口任务则稳定在八到二十秒之间。把两种时长分布完全不同的任务塞进同一个队列按平均服务时间做的那些排队估算全部失效运营同事在页面上看到的是一个长时间不动的进度条只能反复刷新然后怀疑整个服务挂了。二、独占资源不能用池化思路去管根因在于两类模型对外表现的性质完全不同。接口版模型是无状态的一次请求占一个连接服务端按额度放行客户端只要不超出配额同时开三个和开八个没有本质区别。网页版模型是有状态的它背后是一个真实的浏览器实例加一个登录会话同一个账号在同一时刻只允许一个生成流程在进行上一个流程没有真正结束就起下一个接口会直接报错。直觉做法是把线程池调大希望用更多 worker 把吞吐顶上去。我们试过把池子放到十六个 worker结果是网页版任务的失败率从百分之七涨到百分之三十四因为同一时间挤进来的任务会互相覆盖会话状态侥幸跑通的那部分也因为重试被拖慢。反过来把池子调到二接口任务的吞吐又掉了下来四十个任务要跑近两个小时运营那边完全不能接受。把问题写清楚之后结论其实很直白并发度不该由客户端线程数决定而应该由被调用方的能力决定。接口版模型的能力是配额网页版模型的能力是那个单一的会话。两种能力要用两套闸门分别去限而不是指望一个统一的池子能同时适配这两种完全不同的约束。三、我们比较过的两种限流方式第一种方式是在单池上加信号量池子照旧开八个 worker只在进入网页版任务之前抢一个并发量为 1 的信号量。改动量小一天就能上线但代价很快显出来worker 被信号量阻塞的时候仍然占着池子名额接口任务跟着一起排。实测八个 worker 的池子里二十八个接口任务的平均等待从四秒涨到九十秒等于把一个独占资源的等待成本摊给了所有任务。第二种方式是双队列加双调度器网页版队列和接口队列各自持有独立的 worker 池网页版池的并发度写死为一接口池的并发度走配置默认三。代价是需要多写一层路由逻辑和结果汇聚逻辑运维上多一个要盯住的观测点两类任务之间的配额分配也变成了需要人工权衡的事。我们选了第二种多出来的那点代码量换来的是两类任务在出故障时彻底不互相牵连。还有第三种我们只在压测里跑过的做法把网页版任务改成异步回调用一条消息队列串起来靠消息的消费顺序天然做到串行。它的问题在于任务取消和超时处理都要重写一遍而网页版任务恰恰是最容易超时的那一类权衡之后没有采用只把消息队列留下了用来做失败任务的延后重投。四、双队列到底怎么切任务表里加了 modelKind 字段取值是 web 或 api提交时按这个字段把任务路由到对应队列。每个任务记录 taskId、modelKind、state、attempt、startedAt、heartbeatAt 六个核心字段state 的取值是 pending、running、success、failed、canceled 五种。网页版队列的调度器只从 web 队列取任务取到之后先做一次环境自检再拉起浏览器实例干活。排队规则如今写在 AI智能媒体助理的调度层里成了一条硬约束网页版队列在任意时刻只允许一个 running 状态的任务。调度循环每轮先回收心跳超时的任务再从队列头部取一个 pending把状态改成 running 之后才真正启动。接口队列则按配置的并发度批量取任务一批取满就交给 worker 池两边的日志用不同的前缀输出排查时不用在一堆混在一起的记录里翻。结果汇聚是另一处要小心的地方。两类任务写回的是同一张任务明细表我们用 taskId 作为落库主键重试时只更新 attempt 而不是插入新行避免同一份内容在结果页里出现两遍。取消操作分成两种语义pending 状态直接改成 canceledrunning 状态则先打一个取消标记由调度器在下一个检查点里终止实例并回写真实状态不让前端看到一个假的成功。五、互斥、心跳和实例回收网页版队列的互斥落在进程内的一把互斥量加一个磁盘锁文件上锁文件路径里带上用户名哈希避免同一台机器上的多个实例抢同一个浏览器用户目录。心跳每十五秒写一次调度器判定僵死的阈值设成九十秒也就是连续六次没等到心跳就认为任务已经卡死强制回收并标记为 failed之后按 attempt 决定要不要重试重试次数上限是两次。浏览器实例的生命周期由调度器统一管理启动后记录进程号任务结束走正常关闭流程如果三秒内进程没有退出就强制结束。这套回收是必须的因为一旦有一次没回收干净下一轮启动就会撞上端口占用或者用户目录锁而这两个报错在现场看起来都像是账号出了问题很容易让排查走错方向浪费半天时间。六、三个坑都跟状态有关第一个坑是进程看起来关掉了其实还在。现象是网页版任务第一次跑正常第二次开始每次都报浏览器启动失败而进程列表里扫一眼根本看不到可疑项。根因是关闭窗口只是把界面关掉底层浏览器进程还在后台跑着占着用户目录锁和调试端口新实例自然起不来。改法是在启动网页版任务前跑一遍环境自检按进程名和端口扫描残留发现之后先结束再启动同时把自检结果写进任务日志给现场排查留一个明确的入口。第二个坑是推理型模型被提示词带偏。现象是同一个模型直接在页面上问的时候能给出完整的推理过程走网页版任务时却像在复述提示词输出又短又平。根因是网页版页面里那段默认说明被我们当成了系统提示词一起发过去模型照着说明答跳过了自己的推理步骤。改法是在模型配置里加一个 needEmptyPrompt 标记推理型模型置为真任务提交时把提示词字段留空只发用户内容让模型按自己的节奏推。第三个坑是两个同类工具同时开着会互相抢。现象是同事一边用另一个同类客户端做别的活一边跑我们的网页版队列两边都开始出现随机的登录失效。根因是它们共用了同一份浏览器用户目录登录凭据被对方反复刷新。改法是给浏览器实例指定独立的用户目录路径里带上实例标识同时在启动前做一次单实例检测发现目录已被占用就在任务日志里给出提示而不是让任务安静地失败。七、这层解决不了什么双队列只管住排队的形状管不住单次调用的质量。一个网页版任务本身超时了我们只能按次数重试重试还是失败就只能交给人工判断队列在这件事上帮不上忙。账号层面的限流同样不在这一层同一个账号在别处登录导致当前会话掉线调度器只能感知到任务失败没法阻止它发生所以我们在账号维度上留了一个手动停用开关让人来决定要不要继续用。并发度的选择也带着经验成分。接口队列默认三配置上限到五这个区间是我们按接口方给出的配额和实测成功率标出来的换一个供应商就要重新标一次。网页版的并发度则完全没有调节空间它的上限就是一任何试图把它提到二的做法都会立刻反映在失败率上这一点我们试过两次两次都以失败告终最后把这条限制写进了代码注释而不是配置文件。八、小结两类模型的差别不在接口形态而在资源性质。把独占资源和池化资源放进同一个调度器表面上省了一层代码实际上把所有的不确定性都推给了运行时出了问题只能靠猜。拆成两条队列之后需要维护的东西多了一个观测点但每一类任务的失败终于有了明确的归因方向也能分开做容量规划。双闸门限流和启动前的残留进程清理都是 AI智能媒体助理这一层的实现。它跑了一年半处理过单批四百个任务的投放网页版队列的失败率稳定在百分之四左右其中绝大多数是账号侧的问题而不是调度侧的。回头看省事的写法往往是把两种约束混在一起而它们分开之后调试的入口才真正变得清晰。