在大模型推理部署中，业界逐渐形成了评估性能的“黄金三角”——TTFT（Time To First Token）、ITL（Inter-Token Latency）和TGS（Token Generation Speed）。其中，TGS直接反映了系统的吞吐能力和推理经济性，是智算网络规划与优化的核心抓手。本文将从TGS的定义出发，剖析其与网络性能的深层关联，并给出测量与优化的实践建议。
一、TGS到底是什么
TGS的全称是Token Generation Speed，即Token生成速度。在更工程化的语境中，它也被定义为 Throughput in Tokens/GPU/Second，即每张GPU每秒生成的Token数量。这个归一化的定义至关重要——它剔除了集群规模的影响，使得不同硬件配置下的推理效率可以横向对比。
TGS的计算公式并不复杂：
TGS = 总生成时间 / 生成Token数量
或者等价地，在decode阶段可以用批大小除以TPOT（Time Per Output Token）来估算：TGS = batch_size / TPOT × 1000。
但简单公式背后隐藏着关键信息：TGS综合了TTFT和ITL的影响，是系统端到端吞吐能力的全景视图。TTFT衡量用户等待第一个字的时间，ITL决定输出是否流畅，而TGS回答的是一个更根本的问题——这套系统每秒到底能服务多少Token。对于推理服务商而言，TGS直接关联到单卡营收能力。
以实际数据为例：DeepSeek-V3在H800上的Prefill TGS实测约为7839 tokens/GPU/s，Decode TGS约为2324 tokens/GPU/s。Qwen3-30B-A3B在H20上的Decode TGS约为2749。可以看到，prefill阶段和decode阶段的TGS差异巨大，这反映了两个阶段的计算特征根本不同。
二、TGS为什么受网络影响
直觉上，TGS似乎是一个GPU算力指标。但智算网络之所以成为关键变量，是因为在现代推理架构中，网络延迟和带宽已经成为TGS的硬约束。
IETF BMWG工作组正在制定的AI推理网络基准测试草案明确指出：当LLM推理部署扩展到数百甚至数千个加速器时，互联网络成为决定TTFT、ITL和聚合吞吐量（TPS）的关键瓶颈。该草案覆盖的场景包括分离式prefill/decode架构中的KV Cache传输、MoE专家并行的AllToAll通信、请求路由与负载均衡，以及突发推理流量下的拥塞管理。
具体来说，网络对TGS的影响通过几条路径传导：
三、如何测量TGS
TGS的测量需要区分prefill和decode两个阶段，因为它们的计算特征和瓶颈完全不同。
在实际推理服务中采集，核心是要区分“计算时间”和“通信/等待时间”。一个实用的方法是在推理框架（如vLLM、SGLang）中记录每个batch的decode步骤耗时，结合batch size反推TGS，同时通过NIC计数器或DCQCN的ECN标记来关联网络拥塞事件。智算中心网络的亚毫秒级监控系统可以为此提供细粒度的网络状态数据。
对于网络团队而言，更有意义的做法是建立TGS-网络指标关联视图：将TGS的时序曲线与网络延迟、丢包率、ECN标记率叠加分析。当TGS出现下降时，可以快速判断是GPU侧的计算瓶颈，还是网络侧的拥塞或丢包导致。
四、优化TGS的网络侧思路
从网络工程的角度，提升TGS的核心在于减少推理过程中的通信等待和拥塞干扰。
负载均衡与路径选择。智算网络的流量具有低熵、大象流的特点，传统的ECMP哈希容易导致链路负载不均。基于实时遥测的动态路径选择——例如利用INT（In-band Network Telemetry）采集的交换机缓冲区利用率数据——可以让KV Cache传输和AllToAll流量避开拥塞链路，降低长尾延迟。
拥塞控制的选择。RoCEv2的DCQCN是当前主流方案，但在大规模推理场景下，其对ECN阈值的敏感性可能导致吞吐波动。中兴通讯提出的GSE（全调度以太网）技术通过PKTC（报文容器）负载均衡和DGSQ拥塞控制，从根源上规避拥塞丢包。对于以TGS为优化目标的推理集群，选择或调优拥塞控制算法时，应重点关注在突发流量下TGS的稳定性，而非仅仅是峰值吞吐。
传输层优化。分离式架构中，KV Cache传输是TGS的关键路径。使用RDMA的单边操作可以减少CPU介入，但需要确保NIC的QP（Queue Pair）资源充足，避免队列深度不足导致的传输阻塞。对于超长上下文的场景，可以考虑将KV Cache分层存放——热数据留在GPU显存或主机内存，冷数据通过高速网络访问对象存储，用带宽换取显存容量，从而支撑更大的batch size，间接提升TGS。
五、TGS的边界与局限
需要清醒认识到，TGS并非万能指标。它衡量的是吞吐能力，但不直接反映用户体验。一个系统可能有很高的TGS，但TTFT很长（用户等待首字的时间久），或者ITL不稳定（输出卡顿）。在实际部署中，TGS应该与TTFT、ITL联合使用，根据业务场景加权。
此外，TGS的定义本身存在细微的语境差异。有把TGS定义为tokens/GPU/second，是一个效率指标；也有把TGS被定义为总生成时间除以生成Token数，更接近“平均每Token耗时”的倒数。后者与ITL的关系更紧密，前者与硬件效率的关系更紧密。在技术讨论中明确所指的语境，可以避免沟通歧义。
最后，TGS的绝对值高度依赖模型、精度、batch size和序列长度。跨模型的TGS对比几乎没有意义，只有在相同模型、相同硬件、相同工作负载下的TGS对比才有工程价值。
写在最后
TGS作为智算网络的核心性能指标，其价值不在于数字本身，而在于它搭建了一座从GPU计算效率到网络传输效率的度量桥梁。当TGS出现下降时，网络团队需要能够快速判断：是GPU在等网络，还是网络在等GPU。IETF正在推进的AI推理网络基准测试标准化工作，将使得TGS及其关联指标的测量走向规范化，这对于智算网络的规划、验收和日常运维都具有基础性的意义。