引言：LLM Chatbots在不稳定网络下的挑战
经常使用gpt的朋友们会发现，当网络连接不稳定时，chatgpt生成的信息（token）在传输过程中可能会丢失或延迟，导致屏幕输出的响应文本中断，需要等待或者刷新才能继续显示文本，影响整体的交互流畅性。
为了解决这一问题，本文提出了一种新的传输层方案------Chatterbox，旨在改善LLM Chatbots在不稳定网络下的token流式传输体验。即，本文是一篇计算机网络方向的文章，从网络协议的角度针对token的流式传输特点提出了一个新的网络协议，加强LLM响应的流畅程度，具有较好的工程价值。
论文标题：Chatterbox: Robust Transport for LLM Token Streaming under Unstable Network
研究机构：University of Chicago
论文链接 ：arxiv.org/pdf/2401.12...
LLM Chatbot的实时交互问题
1. LLM Chatbot的实时交互
Large Language Models (LLMs) 如ChatGPT自2023年问世以来，其在各种Chatbot服务中的应用变得越来越流行。这些服务利用LLM模型接收用户提示，并实时返回响应，以提供信息回答用户问题或提供情感支持。在LLM Chatbot的token流式传输管道中，token（部分或完整的词）是在云数据中心逐个生成的 ，然后通过广域网发送到客户端设备。为了提供实时流式体验，如上图所示，最新生成的token会在生成后立即发送给用户，而不是等到所有token生成完毕。这种实时交互的流畅性对于用户体验至关重要，任何传输过程中的间歇性停顿都可能严重影响交互的顺畅性，并损害用户体验。
2. 不稳定网络下现有系统的性能退化
在不稳定的网络环境下，如果某些数据包丢失或在网络中严重延迟 ，客户端将需要等待发送方重新传输这些数据包。这可能导致token流式传输停顿，因为所有后续的token都需要等待前面的token到达接收器后才能被渲染。当用户在信号弱或干扰频繁的地方使用LLM Chatbot服务时，他们可能会遭受间歇性的网络连接问题。
通过对ChatGPT Streaming API等应用的性能测试，作者发现不稳定的网络会大幅增加流式传输的停顿。现有的应用借鉴了TCP，依赖于重传机制来处理数据包丢失，导致了长时间的停顿。此外，即使后续包含新token的数据包可能早于重传数据包到达，但由于丢失的token阻塞了新token的渲染，没有更多新token能够被渲染。
Chatterbox方案的提出
1. Chatterbox的设计初衷
为了解决不稳定网络下的token流式传输问题 ，本文提出了一种新颖的传输层方案，名为Chatterbox。Chatterbox的设计初衷是提供一种平滑的token流式体验，并在各种网络条件下将Chatbot转变为更加流利的交流者。
Chatterbox的关键思想是让客户端可以独立渲染每个接收到的数据包 。原本每个数据包中只有生成的token，Chatterbox的每个数据包不仅包含新生成的token，还包含足够的渲染新token的信息。因此，即使在不稳定的网络环境下，每个到达的新token都能够被客户端渲染，而不会被之前丢失的token阻塞。
2. Chatterbox如何减少交互中的停顿
Chatterbox通过在包含新生成token的数据包中加入未确认的token（即已发送但尚未被接收器确认的token），来减少客户端token流式传输中的停顿。这种机制大大减少了因重传而引起的停顿，尤其是在网络往返时间（RTT）较长的不稳定网络中。
这里大家可能对于其工作原理还没能理解，接下来将进行详细说明。
Chatterbox的工作原理
1. Chatterbox的包处理机制详解
Chatterbox核心思想是在发送新生成的token时，同时将尚未被接收端确认（ACK）的token（称为"unacked tokens"）包含在下一个出站数据包中。这样，每个接收到的数据包都包含了足够的信息来独立渲染其中的新令牌，从而避免了因丢失数据包而导致的渲染阻塞问题。
Chatterbox的数据包准备机制使得，对于每个到达的新token，客户端都能够将这个新token之前的token加载出来，并且不会被任何先前丢失的token阻塞。这种机制在网络往返时间（RTT）可能较长的不稳定网络中，可以大大减少因重传引起的停顿。
2. Chatterbox的发送和接收流程
如上图所示，在发送流程中，Chatterbox的server维护一个未确认token缓冲区，其中包含所有已发送但尚未收到ACK的token。每当生成新token并准备发送时，server会访问此缓冲区，并将尽可能多的未确认token与新token一起放入数据包中，以准备新令牌的渲染。client端的逻辑相对简单。接收到数据包后，它会提取数据包内的token，如果所有先前的token都已到达，则渲染这些token，并向发送端发送ACK。
实验设计与模拟网络条件
1. 实验设置和参数
实验通过模拟不同的网络条件来测试Chatterbox的性能。实验使用了一个两状态的马尔可夫模型来模拟不稳定的网络条件，如无线连接。在这个模型中，有两种状态：丢包状态和良好状态。每种状态持续100毫秒，丢包状态下有90%的概率丢包，而良好状态下不会丢包。通过调整状态转换概率p和q，可以模拟不同类型的网络条件。默认情况下，p=0.9，q=0.5，平均每1000毫秒良好连接后会有200毫秒的不良连接，这导致了与实际观察到的类似的15%的丢包率。
2. 实验中使用的评价指标
实验主要报告了两个指标：冗余率和停顿比率。
冗余率是指除了原始token之外发送的额外数据量（包括重传）。
停顿比率是指客户端在停顿时间超过200毫秒时等待token渲染的时间量。理想的方法应该优先减少停顿比率，其次才是尽量降低冗余率。 通过这些评价指标，研究人员能够量化Chatterbox在减少客户端感知到的停顿和发送的总数据量方面的性能。
Chatterbox的性能评估
1. 展示Chatterbox在不同RTT下的性能
Chatterbox在不同的往返时间（RTT）下的性能表现是通过模拟不稳定网络条件下的测试来评估的。在设置了400毫秒和100毫秒的RTT条件下，Chatterbox与传统TCP方法相比，能够显著减少客户端的等待时间。具体来说，当RTT为400毫秒时，Chatterbox能够将停顿比率（stall ratio）降低71.0%，与数据包复制方法相比，能够降低31.6%。而在100毫秒RTT的情况下，Chatterbox将停顿比率降低了60.0%，与数据包复制方法相比，降低了31.3%。这些结果表明，Chatterbox在处理不稳定网络条件下的传输问题时，能够有效减少因重传引起的停顿。
2. 分析Chatterbox在不同丢包模式下的表现
在不同的丢包模式下，Chatterbox的表现也得到了评估。通过调整Markov模型中的参数p和q，模拟了不同的网络丢包情况。在p设置为0.5，q设置为0.5的情况下，网络更频繁地进入丢包状态。尽管所有方法的停顿比率都有所增加，但Chatterbox相比于基线方法显示出更显著的改进。当p设置为0.9，q设置为0.8时，每个丢包周期持续的时间比默认情况更长。尽管Chatterbox的性能仍然优于其他基线方法，但其改进幅度有所减少，这可能是由于长时间的RTT和丢包时间导致不是所有未确认的数据包都能包含在新的数据包中，从而影响了Chatterbox的性能。
真实网络环境下的Chatterbox测试
1. 描述真实网络测试平台的搭建
为了评估Chatterbox在真实网络环境下的性能，研究团队构建了一个测试平台。他们使用了一台Macbook 2023 M2笔记本电脑，通过连接到iPhone 11的热点，使用Mint LTE服务在北美进行测试。测试过程中，手机放置在办公室内，测试人员在办公室外部（30米范围内）行走。同时，在笔记本电脑上运行自动化的bash脚本，重复启动30个GPT API会话，并记录了数据包到达情况和令牌到达时间。
2. 讨论Chatterbox在真实网络环境下的性能
在真实网络环境下的测试中，Chatterbox展现出了比基线方法更好的性能。在400毫秒RTT的条件下，Chatterbox能够比TCP方法减少27.4%的停顿比率，与数据包复制方法相比，减少了18.0%。此外，它还减少了40.4%的延迟token（生成后超过400毫秒的延迟）比例，提供了更实时的响应，而无需对计算进行修改。这些实验结果证明了Chatterbox在真实世界的数据包丢失模式下的实用性。
总结
Chatterbox是一个针对LLM Chatbot的传输层方案，它通过在每个发出的数据包中包含新生成的token以及当前未被确认的token，从而确保每个数据包在接收时都包含足够的信息进行独立渲染，避免了因丢包导致的渲染停顿。模拟不同网络条件下的实验表明，Chatterbox相比于常见的ChatGPT Streaming API使用的TCP方法，能够将停顿比率降低71.0%，并且相比于简单的数据包复制方案，降低了31.6%，同时发送的总数据量更少。