网络带宽瓶颈在大模型服务中经常被低估。一方面，模型权重文件动辄十几GB，分发到推理节点或边缘设备时会占用大量传输时间；另一方面，单次推理生成的token序列如果按完整JSON结构返回，响应体积可能达到数百KB甚至数MB。当并发请求上升时，出口带宽先于GPU算力被打满，用户看到的是首字延迟升高和频繁超时。解决这个问题不能只靠增加带宽，更实际的做法是在推理链路中引入模型量化与流式输出压缩：前者压缩静态权重，后者压缩动态响应。
很多团队在优化推理性能时，只关注GPU利用率和显存占用，却忽略了响应内容本身也在消耗宝贵的带宽资源。一个典型的对话式大模型服务，单次生成1000个token时，如果使用完整的JSON结构返回，每个token都携带文本、logprobs、finish_reason、索引等字段，实际网络载荷可能达到30KB到100KB。一千个并发连接同时拉取响应，出口瞬间需求就可能超过数百Mbps，甚至直接触发云服务商的带宽告警。因此，模型量化与流式输出压缩应当作为带宽治理的两个独立手段分别设计，而不是混为一谈。
一、带宽瓶颈的两个独立来源
带宽消耗可以拆成两个阶段。第一个阶段是模型权重分发。无论是冷启动时从对象存储拉取模型，还是将模型副本同步到多个推理节点，权重文件的体积都直接决定分发耗时。以7B参数的FP16模型为例，权重文件约为14GB。如果边缘机房只有1Gbps的专线，仅下载模型就需要约112秒，这还不包括多副本和版本更新带来的重复传输。第二个阶段是推理响应的持续输出。与权重分发不同，响应输出是长期、高频、小包特征的流量，单次体积不大，但并发一高就会将带宽吃满。
这两个来源的性质完全不同，因此不能期望用同一种压缩方式解决全部问题。权重分发可以通过模型量化从源头减少静态数据量，例如把FP16降到INT8，权重文件减半；降到INT4则可以压缩到原始大小的四分之一左右。响应输出则需要针对token序列的结构化冗余和文本增量进行流式压缩，确保客户端不需要等待完整响应就能开始解码。二者协同后，带宽压力才会从静态和动态两个方向同时下降。
还有一点容易忽视：即使模型已经在内存中运行，权重量化仍然能降低带宽压力。原因在于多副本部署、在线滚动更新、边缘侧缓存等场景都需要不断传输权重快照。模型量化不仅节省磁盘和显存，也让这些传输任务从分钟级下降到秒级，间接提升了服务弹性。
二、模型量化：用低精度权重换取带宽与吞吐
模型量化的核心思想是把连续浮点权重映射到低比特整数。常见方案包括对称量化和非对称量化。对称量化只使用一个缩放系数scale，将浮点权重范围对称映射到例如INT8的[-128,127]区间；非对称量化则额外引入零点zero point，使映射范围更贴合实际权重的偏置分布。量化和反量化的公式可以概括为：量化值q等于round(r除以scale)加上zero point，反量化时再用scale和zero point还原近似浮点值。由于存储索引的位宽从16位降到8位甚至4位，权重文件体积和KV cache都会明显缩小。
精度损失是量化最需要关注的问题。逐张量量化（per-tensor）对整个权重矩阵使用同一个scale，实现简单但精度下降明显；逐通道量化（per-channel）或分组量化（group-wise）可以让每组权重拥有独立scale，精度损失显著减小。更激进的INT4量化通常需要配合校准数据集，使用GPTQ或AWQ等方法在量化前后调整权重，以维持模型困惑度和下游任务表现。实际测试中，7B模型从FP16量化到INT8后，多数自然语言任务的性能损失通常可以控制在1%以内；量化到INT4时，如果采用分组策略和校准，性能损失可以控制在3%左右，但带宽收益达到四倍。
下面用Python模拟一个对称量化过程，帮助理解量化如何缩小体积。代码中原始矩阵是1024乘1024的FP32权重，量化到INT8后，存储字节数从约4.19MB下降到约1.05MB。注意实际模型量化通常不会对所有权重统一量化，而是按通道或分组计算scale，以换取更好的精度。
import numpy as np
def symmetric_quantize(weight, bits=8):
qmax = 2 ** (bits - 1) - 1
scale = np.max(np.abs(weight)) / qmax
q = np.clip(np.round(weight / scale), -qmax - 1, qmax).astype(np.int8)
dq = q.astype(np.float32) * scale
return q, scale, dq
weight = np.random.randn(1024, 1024).astype(np.float32)
q, scale, dq = symmetric_quantize(weight, bits=8)
print(f"原始字节: {weight.nbytes / (1024 ** 2):.2f} MB")
print(f"量化字节: {q.nbytes / (1024 ** 2):.2f} MB")
print(f"最大绝对误差: {np.max(np.abs(weight - dq)):.6f}")
量化后的权重虽然减少了传输体积，但推理引擎必须支持低比特矩阵乘法才能真正加速。如果硬件不支持INT4计算，权重仍会在计算前反量化到FP16，带宽收益保留，但算力收益消失。因此在部署时要分清主要目标是节省带宽还是提升计算速度。对于带宽敏感的边缘分发场景，INT4权重配合FP16激活的反量化方式仍然很有价值，因为权重文件传输量已经压缩到四分之一。
三、流式输出压缩：用增量编码降低动态响应体积
流式输出是大模型服务提升用户体验的常用手段。传统SSE（Server-Sent Events）接口会持续向客户端推送token片段，每个chunk通常是一个JSON对象，包含增量文本和少量元信息。如果每个chunk都完整携带字段名、索引、状态码等信息，实际网络载荷会比纯文本大出数倍。使用HTTP的gzip压缩虽然能降低体积，但gzip更适合压缩完整文档，流式场景下如果对每个小chunk单独压缩，压缩字典无法复用，收益非常有限。更好的办法是在应用层设计紧凑的增量编码格式。
一种常见做法是对token id序列做delta编码加varint编码。LLM推理过程中产生的token id通常是递增的整数，相邻token id的差值比原始id更集中。delta编码将每个token id替换为与前一个id的差值，再使用varint这类变长整数编码存储，可以让小差值的token只占用1个字节。对于文本内容，服务端可以只发送新增的字符串切片，客户端自行拼接。这样就能在保留流式体验的同时，大幅减少每个chunk的元数据开销。
另一个容易被忽略的环节是模型输出中的结构化字段。某些推理接口默认返回logprobs、top_k候选、token索引等完整信息。这些字段在大多数应用场景中并没有被使用，却会显著增加每个chunk的体积。建议在服务端增加输出字段裁剪配置，只保留客户端真正需要的内容。下面的代码展示了对token id进行delta编码和varint编码的效果，模拟一段token序列在压缩前后的体积变化。
def delta_encode(token_ids):
prev = 0
out = []
for tid in token_ids:
out.append(tid - prev)
prev = tid
return out
def varint_encode(n):
buf = []
while True:
b = n & 0x7F
n >>= 7
if n:
buf.append(b | 0x80)
else:
buf.append(b)
break
return bytes(buf)
ids = [100, 105, 112, 112, 200, 350]
enc = delta_encode(ids)
compressed = b''.join(varint_encode(x) for x in enc)
print(f"原始token序列按int32存储约: {len(ids) * 4} 字节")
print(f"delta+varint压缩后: {len(compressed)} 字节")
print(f"压缩后的字节流: {compressed.hex()}")
生产环境中还可以在推理网关层做分块压缩。网关先缓存一小段时间内的多个token，比如每8个token或每50毫秒聚合一次，再使用zstd或lz4等压缩算法压缩后下发。客户端收到分块后先解压再增量渲染，这样既保持了流式输出，又能让压缩器获得更大的上下文窗口。分块大小需要根据延迟目标调整，块越大压缩率越高，但客户端等待时间也会增加。
四、协同落地：从配置到避免常见误区
模型量化和流式输出压缩虽然解决的是不同侧的问题，但在推理网关上可以统一配置。权重量化通常在模型加载阶段完成，使用量化后的权重文件和校准参数启动推理引擎。流式输出压缩则在网络出口层实现，可以由API网关、反向代理或推理服务自身的序列化模块完成。一个典型的组合策略是：权重使用INT8逐通道量化保证精度，输出流启用delta编码和zstd分块压缩，同时关闭logprobs等非必要字段。这样静态分发带宽降为原来的一半以下，动态响应带宽通常可以节省60%到80%。
落地时常见几个误区。第一，把模型量化等同于响应压缩。模型量化只影响权重体积，不会改变推理生成的token数量或响应结构，因此必须单独设计输出压缩。第二，在流式响应中直接套用gzip。gzip对每个chunk独立压缩会形成大量压缩开销，并且客户端解压逻辑复杂，推荐使用zstd或者应用层紧凑编码。第三，为了极限压缩而牺牲首字延迟。流式压缩本质上有延迟与体积之间的权衡，分块缓存时间过长会让用户感觉响应变慢。最好根据实际网络RTT设置合理的缓存窗口，例如10到30毫秒。
最后，还需要监控压缩前后CPU开销。量化权重在推理时可能触发反量化算子，流式压缩也会占用额外的CPU时间。如果推理节点CPU资源紧张，可以选用更轻量的压缩级别，或者把流式压缩下放到专门的网关进程。通过量化与输出压缩的协同工作，大模型服务的带宽瓶颈被从静态和动态两个维度同时缓解，服务在低带宽或高并发场景下也能保持稳定的响应体验。