输入很长、输出很长、人很多，是三种不同压力

还是同一类A/B摘要任务。左边把原始记录加长，只要求一句结论；中间输入很短，却要求长篇分析；右边是更多独立请求同时到达。三种情况都可能让体验变慢，但增加的工作不同：长输入增加prefill计算和状态；长输出增加顺序decode轮次并增长缓存；高并发还增加排队、批次和容量压力。

现在看同一设备上的时间轴。绿色decode已经在工作，中间加入一段长prefill；如果这段工作占用共享资源，正在出字的请求就可能等一等。图里没有给任何固定毫秒，它只说明不同阶段可能竞争资源，用户感受到的停顿需要沿这条时间关系排查。

一种进一步的安排是把prefill和decode放到不同资源上。左边完成已知输入计算，把K/V等必要状态交给右边，右边再继续生成。这样可以分别配置资源，但中间这条交接不是免费的：要传输状态，还要安排模型驻留和调度协调。所以分开两栏只是一个候选设计，是否更好要测量整体代价。

因此要同时看三个结果：用户等第一字多久，之后每一步出字多快，以及整个系统能完成多少请求。是否分开阶段，要结合输入输出长度、请求量、设备和互联条件。课堂留下的是一条判断路径：先定位哪一段工作增加，再选择组织方式。这个服务系统还会用来生成训练所需的候选，下一页把这条连接补回来。