这项由卡内基梅隆大学与Arcadia Research Team（ART）联合开展的研究，以预印本形式于2026年6月30日发布在arXiv平台，论文编号为arXiv:2602.11688v2，分类归属于计算机网络领域（cs.NI）。
你有没有想过，当你在手机上向某个AI助手发送一条消息时，这条消息究竟跑到了地球上哪个角落的服务器上？更关键的问题是：谁来决定你的问题应该被哪台服务器处理？这个看似不起眼的"分配决策"，其实直接决定了你盯着屏幕等待的那几秒钟——长了或短了，体验天差地别。
这项研究的核心，正是为这个"分配决策"设计一套更聪明的规则。研究团队提出了一个名叫GORGO的系统，专门解决大型语言模型（也就是ChatGPT这类AI）在全球多个服务器之间分配任务时的低效问题。说白了，GORGO就是一个更精明的"调度员"，它能同时考虑网络距离远近、服务器忙闲程度、以及能不能利用已缓存的历史数据这三大因素，然后做出最优选择。
一、为什么等待AI回复的第一个字，是最难熬的？
在AI对话服务的世界里，有一个指标叫做"首字延迟"（TTFT，Time To First Token），通俗地说就是：你发出问题之后，屏幕上出现第一个回复字符所需要的时间。这段时间越短，你越觉得AI反应灵敏；这段时间一旦拉长，哪怕只是多等了两三秒，用户体验就会急剧下降，就像餐厅服务员接了单之后愣在原地迟迟不动，比上菜慢更让人着急。
首字延迟由三部分叠加而成。第一部分是网络传输时间，也就是你的请求从设备出发、跨越网络抵达服务器所需的时间——如果服务器在地球另一端，这个时间可能长达半秒甚至更久；第二部分是排队等待时间，服务器同时处理很多人的请求，如果前面排了一大堆，你就得等；第三部分是计算时间，服务器真正开始处理你的问题所花的时间，而这里有一个非常重要的优化手段叫做"前缀缓存"。
"前缀缓存"（KV-Cache）可以用一个生动的场景来理解：假设你和一个客服每次通话都要先报一遍你的账号信息和历史订单，但如果这个客服记住了你，下次你只需要说"我上次那个订单"，他立刻就能定位，不需要你重新解释。AI服务器对于多轮对话的处理也是如此——如果某台服务器之前已经处理过你的历史对话，它就把关键信息缓存起来，下次接到你的请求时，不用重新计算那些已经算过的内容，计算时间大幅缩短。对于上下文很长的对话（比如有十万个词的长文档分析），这种缓存能把计算量从十万词压缩到一万词，节省90%的计算时间。
然而问题就在这里：现实中，AI服务往往在全球多个地区部署了多台服务器（称为"副本"）。当一个新请求来了，要发给哪台服务器呢？发给有缓存记录的那台，能省计算时间，但如果那台服务器已经排满了队，或者它在地球另一端网络延迟很高，省下来的计算时间可能还不够弥补排队和网络的损耗。这三个因素像三根绳子同时拉扯，现有的系统往往只能抓住其中一两根，另一根就被忽视了。
二、现有的调度方案，各有什么短板？
在GORGO出现之前，业界通常使用几种常见的请求分配策略，每种都只盯着其中一个或两个因素。
最简单的一种叫"会话亲和性"（session affinity），它的逻辑是：只要认出你是谁（通过你消息前几百个词的特征），就每次都把你的请求发给同一台服务器。这样缓存利用率高，但完全不管那台服务器是不是已经挤满了人，更不管它离你有多远。一旦某台服务器特别"受欢迎"，大量请求涌入，所有绑定到这台服务器的用户都得苦等。
另一种叫"最少负载"（least-load），它每次都把请求发给当前最空闲的服务器，像餐厅领位员总把客人领到空桌子最多的区域。但这样做忽视了缓存——每次换一台服务器，之前积累的缓存就浪费了，服务器每次都得从头计算，计算时间反而变长。
还有一种叫"前缀缓存路由"（prefix-cache），它专门寻找与当前请求历史记录匹配度最高的服务器，最大化缓存利用率，但完全不考虑服务器当前的排队情况和网络距离。如果最佳缓存匹配的服务器在首尔，而代理服务器在美国，光网络来回就可能要消耗四五百毫秒，全部优势荡然无存。
研究团队通过实验数据展示了这些方案的局限：在他们的测试中，前缀缓存策略在某些场景下的p95首字延迟（即95%的请求中最慢的那5%所对应的等待时间）高达6784毫秒，几乎是GORGO的2.7倍。
三、GORGO是如何把三根绳子同时握住的？
GORGO的核心思路，是把三种成本用一个统一的"总分"来衡量，然后每次都把请求发给总分最低的服务器。用一个接地气的比方来说：你要在三家外卖平台上点同一道菜，一家距离近但商家很忙、评分很低；另一家距离远但商家空闲、有你的会员记录免运费；第三家中等距离中等繁忙但没有缓存优惠。GORGO就是那个帮你综合计算"总花费"（时间+等待+折扣）后告诉你选哪家的智能助手。
具体来说，GORGO把三种成本折算成同一单位，用一个加权公式来计算每台服务器的"预计首字延迟"：网络往返时间乘以一个权重系数，加上排队等待时间乘以另一个权重系数，再加上实际需要计算的token数量（已有缓存的部分不算）。这里最妙的设计是：这两个权重系数不是人工写死的固定值，而是系统自动学习和调整的参数。
学习过程采用了一种叫"进化策略"的优化方法，具体是所谓的"(1+1)进化策略"。可以把它理解为一种"微调旋钮"的过程：系统有两个旋钮（对应两个权重），每隔一段时间，系统随机把其中一个旋钮微微拧动一下，然后观察整体表现是否变好了。如果变好了，就保留这次调整；如果变差了，就撤回来。这个过程不断重复，旋钮逐渐调到最佳位置。调整幅度的大小由一个叫"步长"的参数控制，系统还会根据过去几次调整的成功率自动缩放步长——大约每5次尝试中有1次成功时，系统认为步长合适（这就是著名的"Rechenberg五分之一规则"，由德国科学家Ingo Rechenberg在1973年提出）。
在实际部署中，GORGO代理服务器部署在美国阿什本（us-ashburn），它每隔30秒向三个地区的服务器发送"探针"请求，测量网络往返时间并用指数加权移动平均做平滑处理——就像你用温度计量体温，但不是看瞬间读数，而是看过去几次测量的加权平均，避免偶发波动的干扰。同时，GORGO代理还在自己这边维护一个"前缀树"数据结构，记录每台服务器已经处理过的对话前缀，这样在路由时就能快速估算出每台服务器能节省多少计算量。
四、为了测试这套系统，他们还造了一个全新的数据集
要验证GORGO的效果，需要一批真实的、有代表性的用户请求数据。但研究团队发现，现有的公开数据集根本不适合用来测试缓存感知型路由策略。
学术界常用的两个大型对话数据集分别是LMSYS-Chat-1M和WildChat-4.8M。前者包含100万条对话，但平均每条请求只有467个词，而且没有记录是哪个用户发的，无法分析跨轮次的缓存复用情况。后者包含约320万条对话，平均每条请求约2925个词，确实记录了用户IP（哈希处理过），但跨用户的缓存复用率只有28%，用户内部的多轮复用率只有4.7%，远不足以体现长上下文场景下缓存的价值。
于是研究团队基于ART公司的真实生产流量元数据，合成生成了一个全新的数据集：ART-Chat-2.5M。这个数据集包含约252万条请求，来自约5000个用户，平均每条请求长达17964个词——是WildChat的6倍多。更关键的是，用户内部多轮对话的前缀复用率高达89.4%，整体全局复用率达到89.7%。这意味着每次用户发送新消息，有接近九成的内容在之前已经被服务器处理和缓存过，缓存的价值极其显著。
数据集以Mooncake FAST'25格式发布，每条记录包含请求时间戳、请求元数据和合成生成的对话内容。通过线性缩放请求之间的时间间隔，可以模拟不同负载强度下服务器的响应表现——时间间隔压缩，服务器就越繁忙；时间间隔拉长，服务器就越轻松。这个设计让研究团队能够在不搭建真实大规模流量的情况下，系统性地测试不同负载场景。
五、实验怎么做的，结果怎么样？
实验环境的配置相当真实：GORGO代理服务器运行在美国阿什本的一台小型CPU机器上，控制着分布在三个地区的SGLang推理引擎——分别是美国阿什本、德国法兰克福、韩国首尔，每台引擎配备两块L40S GPU，运行Qwen3.5-35B-A3B模型的FP8量化版本。三个地区到代理服务器的网络往返时间差异巨大：阿什本本地约37毫秒，法兰克福约279毫秒，首尔约456毫秒。这种差异正好体现了跨地区部署时网络延迟不可忽视的影响。
实验选取了ART-Chat-2.5M中三个30分钟的时间窗口进行测试。4月5日的窗口用于在线调参——GORGO在真实流量上实时调整权重参数；4月6日和7日的窗口用于"冻结参数"的泛化评估，即使用4月5日学到的参数值，在新的流量上直接评估效果。
调参过程在4月5日的7195条请求上进行，GORGO以滑动窗口的方式（每128条请求为一个窗口，步长32条）计算p95首字延迟作为优化目标，权重系数从初始值（wrtt=0.5，wqueue=0.1）出发，经过672个样本（第18次进化步骤）收敛到最优值（wrtt=0.276，wqueue=0.5）。这个收敛过程相当快——在大约18分钟的真实流量中就找到了稳定的参数配置。
最终结果令人印象深刻。在两个冻结参数的评估窗口中，GORGO相比会话亲和性策略，p95首字延迟改善了6.9%到15.5%，p95端到端延迟（从发送请求到收到完整回复）改善了14.3%到30.9%。与"前缀缓存"策略相比，差距更大——在4月7日的窗口中，前缀缓存的p95首字延迟高达1861毫秒，而GORGO只有1417毫秒，改善幅度接近24%；p95端到端延迟方面，前缀缓存高达12秒，GORGO只有3.36秒，差距更是悬殊。
值得关注的是调参窗口（4月5日）的表现：由于进化策略在调参过程中需要主动探索，有时会测试比当前最优更差的参数组合，因此GORGO在调参窗口的整体p95首字延迟（2514毫秒）略高于某些基线方案（比如会话亲和性的2428毫秒）。但这是调参阶段的合理代价，一旦参数收敛，泛化到新流量后性能就全面领先了。
六、连续批处理：一把双刃剑
实验过程中还发现了一个有趣的现象，研究团队把它称为"利用连续批处理的意外发现"。
现代AI服务器普遍采用一种叫"连续批处理"的技术：当服务器正在处理一批请求时，如果有新请求进来，只要还有空余的并发槽位，服务器会直接把新请求插入正在运行的批次中，而不是等当前批次全部完成再处理下一批。这样可以最大化GPU的利用率，避免等待空转。
但这个机制带来了一个副作用：当所有请求都被集中发往同一台服务器时，每个新来的请求都能立刻进入批次、复用已有缓存、只需计算很少的新内容，首字延迟极短。然而一旦并发量超过上限，服务器内存被占满，GPU和CPU之间开始频繁交换缓存数据（类似于电脑内存不够时频繁读写硬盘），端到端延迟和每个字符间的生成间隔都会急剧恶化。
在实验中，GORGO的进化策略有时会"发现"这个规律：把wqueue调到接近0，实际上等于无视服务器负载，把几乎所有请求都发往最近的阿什本服务器。在某个特定测试窗口中，这种策略让p95首字延迟比第二名低17%，但p95端到端延迟却飙升到12.49秒，其他方案通常只有3到4秒。这是一种"钻空子"的策略——牺牲整体体验换取首字速度的极端优化，并不符合实际生产需求。
研究团队把这个现象归纳为"奖励劫持"（reward hacking）：优化算法找到了一个在指定指标上表现出色但在其他指标上极差的解法。这也提示了未来改进方向：优化目标应当同时考虑首字延迟和端到端延迟，或者在约束条件中加入对服务器集中度的限制。
七、负载扫描实验：找到服务器的承受极限
为了全面理解不同负载强度对各策略的影响，研究团队还做了一组"负载扫描"实验，通过调整时间缩放系数（time_scale）来控制请求密度——系数越小，请求越密集，服务器越繁忙。
当time_scale=1.0（最高负载）时，所有策略包括GORGO都出现了服务器过载的迹象，请求开始积压排队。当time_scale=2.0时，GORGO率先"脱离饱和"，p95端到端延迟从15秒级别降到5.65秒；而会话亲和性在这个负载下仍然过载，端到端延迟高达15.50秒。当time_scale=3.0时，三种主要策略都脱离了饱和区间，GORGO的p95首字延迟（1378毫秒）和p95端到端延迟（3.25秒）均优于其他方案。
这个结果说明，GORGO的队列权重项起到了关键作用——它能感知服务器负载并适当分散请求，避免单台服务器过早陷入饱和，在相同的流量强度下维持更健康的系统状态。
八、在短文本数据集上，GORGO并不占优
为了客观评估GORGO的适用边界，研究团队也在WildChat-4.8M数据集上做了测试，结果恰恰相反：GORGO的在线调参版本p95首字延迟为1.325秒，冻结参数版本更高达1.932秒，均劣于最简单的会话亲和性策略（1.025秒）。
原因很清晰：WildChat的平均请求长度只有2925个词，缓存节省的计算量极为有限。在这种情况下，把请求路由到有缓存记录的服务器所省下的计算时间，可能还不如简单地发给最近服务器来得直接。当三种成本中的"计算成本"接近于零时，GORGO精心设计的三因素平衡就失去了意义，其他更简单的策略反而更有效率。
这个发现其实帮助研究团队界定了GORGO的使用场景：它在长上下文、高缓存复用率的工作负载下才能发挥价值。如果你的业务主要是短文本问答，用最简单的会话亲和性就够了；但如果是长文档分析、复杂多轮对话、或者企业级的长上下文处理，GORGO带来的提升才显而易见。
归根结底，这项研究告诉我们的事情并不复杂：在全球分布式AI服务中，"把请求发给哪台服务器"这个问题，远比表面看起来要复杂得多。网络距离、服务器繁忙程度、历史缓存记录，三者缺一不可，只盯着其中一个就会在另外两个地方吃亏。GORGO的贡献在于把这三件事同时纳入一个可以自动调优的框架，让系统自己从真实流量中学习最合适的权重配比，而不需要工程师凭经验手动调整。
对于普通用户来说，这项研究的直接意义是：你和AI对话时等待回复的那几秒钟，并不只是算力问题，路由调度的好坏同样关键。研究还附带发布了ART-Chat-2.5M数据集，为未来的研究者提供了更接近真实生产环境的测试基准。
当然，研究本身也坦诚地指出了局限：实验只在一个生产流量数据集、三个地区、同质GPU配置下进行，对于不同硬件组合、更多副本数量、或者完全不同的业务类型，还需要进一步验证。有兴趣深入了解的读者，可以通过arXiv论文编号2602.11688查阅完整原文，代码和数据集也已在论文中给出的GitHub页面公开。
Q&A
Q1：GORGO系统的核心优势是什么？
A：GORGO的核心优势在于同时考虑了网络延迟、服务器排队时间和前缀缓存命中率三个因素，而不是像现有方案那样只关注其中一两个。它通过进化策略自动学习三者之间的权重配比，在真实流量中持续优化，在长上下文对话场景下能将p95首字延迟降低6.9%到15.5%，端到端延迟降低14.3%到30.9%。
Q2：ART-Chat-2.5M数据集和其他公开数据集有什么区别？
A：ART-Chat-2.5M的平均请求长度达到17964个词，是WildChat-4.8M的6倍多，用户内部多轮对话前缀复用率高达89.4%。现有公开数据集如LMSYS-Chat-1M平均只有467词、WildChat平均2925词，复用率也远低于ART-Chat-2.5M，无法真实反映长上下文生产环境中缓存策略的价值。
Q3：GORGO适合所有AI服务场景吗？
A：不是。在短文本问答场景（比如WildChat这类平均不足3000词的数据集）中，GORGO的表现反而不如简单的会话亲和性策略，因为短文本场景下前缀缓存节省的计算量极小，三因素平衡的优势无从体现。GORGO主要适用于长文档分析、复杂多轮对话等长上下文、高缓存复用率的业务场景。