一家餐厅每小时能做多少道菜，不等于客人一定不用久等。大模型集群也一样：即使总体吞吐量尚未到上限，少数请求仍可能排队很久。GAUSS因此不只估算“每秒能接多少请求”，而是把工作负载分布和延迟服务级目标（SLO——运营方承诺努力达到的响应指标）一起纳入容量规划。
它把生成拆成两个资源特征不同的阶段：首 Token 时间，即用户等到第一个词要多久；逐 Token 延迟，即后续出词是否流畅。GAUSS先用校准后的延迟模型描述两个阶段，再以 Monte Carlo 模拟大量随机的请求到达和长度组合，预测两类延迟的完整分布及可持续请求率。作者认为，相比只重放一条历史流量记录，这种做法更容易覆盖少见却影响体验的尾延迟，也能推演尚未部署的工作负载、路由策略和硬件。论文摘要未披露预测误差或实际节省的容量，因此目前更值得关注的是它提出的规划框架，而非已被证明的收益数字。