Hello,Gen AI
Hello,Gen AI
杂|2025-10-27|最后更新: 2025-10-27
学
type
status
date
slug
summary
tags
category
icon
password

Hello, Gen AI? Dissecting Human to Generative AI Calling

目前处于新兴阶段的AI音视频通话应用尚未有一个统一的框架与标准，该文章测量了六个不同的AI通话应用，分别来自 Instagram、Messenger、WhatsApp、ChatGPT、Gemini和Copilot，评估了其网络架构及性能。
notion image
注：本文未涉及视频通话，仅仅限于语音聊天
通过本文的测量，各个应用厂商的开发者没有采用ABR，可能是未将弱网情况下的应用表现排在较高的优先级。但这又肯定是一个必须解决的问题，尤其是涉及到视频通话聊天模型中
 

一、主要发现

1、所有六款应用的首令牌生成时间（TTFT）均超过 1 秒，最长的甚至超过 8 秒，远高于实现流畅、自然语音交互通常所需的亚秒级阈值 。测量结果表明，首令牌生成时间受多种因素共同影响，包括大型语言模型后端支持的输入模态、服务器基础设施的地理位置、应用所选择的传输模式，以及处理长查询时采用的增量推理等应用级优化措施。
2、Gemini 和 ChatGPT 的高级版本采用多模态大型语言模型，可直接处理音频输入；而其他应用则依赖传统的纯文本大型语言模型，在进行推理前需先将用户语音转换为文本，生成文本响应后，再将其转换为语音进行回复。尽管多模态大型语言模型能够通过解读原始音频数据（包括非语言线索），实现更流畅、更具表现力的交互，但与纯文本大型语言模型相比，其会增加超过 1 秒的首令牌生成时间，带来额外的处理开销。
3、在网络基础设施方面，所研究的应用在呼叫建立阶段建立的网络会话数量存在差异。Gemini 仅使用单个会话，因此获得了最短的建立时间（约 1 秒）；而 ChatGPT 的行为具有不确定性，会与同一服务器建立 4-9 个会话，导致建立时间超过 3 秒。我们还发现，所有应用的服务器主要部署在大型都市地区，这使得人口较少地区的用户面临更高的往返时间（RTT），可能会进一步增加首令牌生成时间的延迟。
4、这些应用在媒体传输方面采用了不同的设计策略，导致传输协议选择各异（详见 4.3 节）。ChatGPT、Instagram、Messenger 和 WhatsApp 采用用户数据报协议 / 实时传输协议（UDP/RTP）进行基于流的传输，在上下行链路中逐帧传输音频。相反，Copilot 采用传输控制协议（TCP）结合超文本传输协议第 2 版（HTTP/2，简称 H2），在上下行链路中实现基于批处理的传输策略，即把多个音频帧聚合后以突发方式传输。Gemini 似乎在对上行传输策略进行 A/B 测试，在基于流的传输（采用快速 UDP 互联网连接协议 / 超文本传输协议第 3 版，即 QUIC/HTTP/3）和基于批处理的传输（采用 TCP/H2）之间切换；而其下行链路则始终采用基于批处理的传输方式。
notion image
  • 批处理和流处理有何不同？
流处理的好处在于发送平滑、延迟低，但包头开销大，吞吐量可能较低。批处理好处在于统一发送，包头开销小，吞吐量高，但存在突发流量
  • 采用UDP/RTP协议的应用也同样会采用STUN技术来进行NAT穿透，同时一般一个连接对应两个流（上行与下行）
  • Instagram和Messenger在建立阶段需要和信令服务器和入口服务器建立连接，所以数量为2
  • WhatsApp会和三个入口服务器建立连接（入口服务器同时负责了STUN功能），以进行故障转移
  • ChatGPT的行为比较复杂，建立的这么多个流中，只有一个连接通过RTP传输媒体数据，存在一个上行流和三个下行流，但是只有一个下行流存在输出传输的特征，其它两个流可能是冗余的
  • Copilot的2个TCP连接，一个是用于数据遥测，一个是和服务的入口服务器建立的链接
5、这些传输模式对首令牌生成时间和带宽使用均有显著影响。例如，与基于批处理的传输方式相比，基于流的传输方式能实现更短的数据包到达间隔时间，可将首令牌生成时间减少 150-250 毫秒。相反，基于批处理的传输方式虽能让应用在下行链路中快速获取完整的生成式人工智能响应，但会导致带宽激增 —— 以 Copilot 为例，带宽峰值可达 4Mbps。另一方面，Instagram、Messenger 和 WhatsApp 等采用基于流传输的应用，带宽占用较低，通常仅为 30-60Kbps。
6、通过精心设计的查询实验，我们发现 Instagram、Messenger 和 WhatsApp 可能采用了增量推理技术，即在接收用户音频的过程中逐步对其进行处理。例如，这些应用可能在用户说话时就分步骤处理语音，而不是等到用户说完所有内容后才开始推理。测量结果显示，这种优化使得它们处理长查询时的首令牌生成时间，与处理短查询时的首令牌生成时间基本相当。相比之下，其他应用缺乏此类优化，导致处理长查询时的首令牌生成时间增加 25% 以上。
  • 注：增量推理类似于采用流水线并行的技术，边接受用户语音边进行推理，使得处理长语音输入和短语音输入的TTFT类似
7、我们的网络中断实验表明，WhatsApp 支持快速故障转移，平均切换时间为 1.2 秒，这是通过在呼叫建立阶段预先与三台服务器建立连接实现的。相反，ChatGPT、Copilot 和 Gemini 没有任何故障转移机制，当与服务器的连接中断时，应用功能就会失效。此外，所有被评估的应用均未采用自适应比特率流传输技术来应对带宽受限的情况。这一缺陷在 Copilot 上表现得尤为明显，当下行带宽低于 1.5Mbps 时，它就无法提供流畅的响应。相比之下，其他应用仅需数百 Kbps 的带宽就能稳定运行。
 

二、流量分析

notion image
ChatGPT、Instagram、Messenger 和 WhatsApp 表现出相似的双向流传输模式：上行链路或下行链路的带宽使用情况与用户说话或生成式人工智能响应的时段高度对应。在空闲时段（包括用户或生成式人工智能静音，或会话进入静音阶段），这些应用仅维持极少的背景流量。ChatGPT 是个例外，在生成式人工智能响应时，其上行链路吞吐量略有升高。我们还观察到，在静音阶段，WhatsApp 表现出两种不同的传输行为，在静音启用约 10 秒后会切换模式。 相反，无论用户是否在说话，Copilot 和 Gemini 的上行链路始终在持续传输数据。在下行链路，当生成式人工智能开始响应时，这两款应用都会出现突发性流量，随后即使生成式人工智能仍在生成响应，传输也会迅速停止。这表明，这种突发流量是由预先下载完整响应导致的，同时会并行进行播放。此外，Copilot 和 Gemini 均表现出两种不同的吞吐量模式：短响应对应低吞吐量模式，长响应对应高吞吐量模式。实验发现，两种模式的切换阈值约为响应时长 5 秒。

上行链路

  • 可以看到，采用批处理的Copilot和Gemini在GenAI阶段存在流量突发，使用的是“边下载边播放”的模式，其它四种采用的是流处理的方式，这与先前的协议分析相匹配，这一点也可以从包大小的CDF中看出
      • notion image

User Speaking阶段

  • Instagram、Messenger 和 WhatsApp 采用基于流的传输方式，其特点是数据包到达间隔时间短（<60 毫秒）且数据包小
  • Copilot 和 Gemini-T 采用基于批处理的传输方式，有证据表明，超过 60% 的数据包大小接近 1500 字节的最大传输单元（MTU）。这种批处理行为还导致数据包到达间隔时间更长，例如，Gemini-T 中超过 40% 的数据包到达间隔时间超过 300 毫秒。
  • 采用基于流传输的应用，吞吐量保持在 150Kbps 以下。后续研究发现，ChatGPT、Instagram、Messenger 和 WhatsApp 可能采用 Opus 编解码器 [109]，因此它们的吞吐量差异可能是由不同的编解码器配置导致的。
  • Gemini-T 的吞吐量甚至低于 ChatGPT，这主要是由于其数据包到达间隔时间更长，但代价是首令牌生成时间（TTFT）增加。
  • Copilot 试图维持适中的数据包到达间隔时间（100-180 毫秒），但结合其较大的数据包大小，导致上行链路吞吐量显著升高，平均超过 600Kbps，是元宇宙平台公司三款应用的 10 倍以上。（可能没有优化措施）
 

GenAI Responding阶段

在生成式人工智能响应阶段，用户处于静音状态，上行链路流量应与静音阶段（g）类似。
  • 只有 Instagram 和 Messenger 实现了这一行为：与用户说话阶段（c）相比，它们将一半数据包的到达间隔时间延长至约 360 毫秒，并减小了数据包大小（f）。
  • ChatGPT 也表现出类似的 360 毫秒数据包到达间隔时间，导致其在生成式人工智能响应阶段的上行链路吞吐量（d）约为用户说话阶段（a）的一半。
  • 相反，Copilot 和 Gemini-Q/T 在生成式人工智能响应阶段的上行链路吞吐量与用户说话阶段相当，甚至更高。由于在这两个阶段观察到的数据包到达间隔时间和数据包大小相近，这种行为可能表明，即使在用户静音时，这些应用仍在持续捕获并传输背景音频，这引发了潜在的隐私担忧。另一种可能的解释是，这些应用传输虚拟数据包以维持会话活跃，而非实际的音频内容。这一现象的根本原因有待进一步研究，以确定其是否确实存在隐私风险。
 

Mute阶段

  • 在静音阶段，ChatGPT、Instagram 和 Messenger 有效地将上行链路带宽消耗降低到 10Kbps 以下。这是通过将一半数据包的到达间隔时间延长至约 400 毫秒（h）实现的
  • 在启用静音约 10 秒后，WhatsApp 会切换到第二种传输模式，特点是持续传输 94 字节的小数据包，且数据包到达间隔时间短（80%<20 毫秒），导致上行链路带宽使用超过 35Kbps（g）。目前尚不清楚这种设计选择的合理性。
  • * 即使在静音状态下，Copilot 仍消耗超过 500Kbps 的上行链路带宽，这表明它缺乏在低活动时段降低带宽使用的优化措施
 

下行链路、通话建立时间

notion image
  • 我们观察到，基于批处理的传输方式比基于流的传输方式消耗显著更多的带宽，在 Copilot 的高吞吐量模式下，峰值吞吐量可达约 4Mbps，如图 5（a）所示。这种行为体现了 “边下载边播放” 的策略。基于批处理的传输方式的特点是数据包大（例如，Copilot/Gemini 的数据包大小分别为 1514/1292 字节），如图 5（b）所示。
  • 采用基于流传输的应用在生成式人工智能响应时的下行链路吞吐量，高于用户说话时的上行链路吞吐量。这种吞吐量的提升通过不同策略实现：Instagram 和 Messenger 提高了数据包发送速率（未展示），而 ChatGPT 增大了数据包大小。
 
这说明了Gen AI通话的特殊性：上行链路与下行链路的非对称性，下行链路由于模型生成的音频已经在服务端准备好，所以更倾向于点播模式（即下载并播放服务端的一段音频），采用批处理。在具体实现中也可以看到，即使是流处理的应用，也在增大包发送速率以及包大小，尝试向点播靠拢
  • Copilot 的呼叫建立时间最长，平均超过 4 秒。我们在 4.5 节的网络中断实验中发现，这是由于建立与服务器基础设施的网络连接需要较长时间。值得注意的是，用户发起呼叫后，Copilot 会先显示一条问候消息，然后才接受用户输入，这种行为在其他应用中未被观察到。这种设计可能是为了在系统完成初始化过程中吸引用户注意力，从而隐藏用户感知到的呼叫建立时间。
  • Gemini只需建立一个连接，耗时最短，容易理解
  • WhatsApp建立三个连接的过程是并行的，所以耗时与Instagram和Messenger类似
  • ChatGPT的行为比较复杂， 较高的延迟可能与建立的连接数较多有关
 

延迟分析

notion image
可以看到，Instagram、Messenger、WhatsApp采用了增量推理。长查询与短查询的TTFT类似
 
MCP协议学习笔记NetLLM SIGCOMM 2024
Loading...