在深度学习工程实践中，一个经常被忽视却极其致命的问题是网络带宽瓶颈。训练好的模型动辄几GB甚至几十GB，而在跨机房部署、边缘设备分发、云端模型热更新等场景下，网络带宽往往是整个链路中最慢的一环。哪怕GPU推理速度再快，模型传不下来、加载不进去，服务一样起不来。本文围绕两个核心手段展开：模型量化与流式压缩，讲清楚它们各自的原理、适用场景以及如何组合使用。
为什么模型传输会成为带宽瓶颈
先看一组直观的数据。一个典型的BERT-Large模型，FP32精度下参数量约3.4亿，权重文件大约1.3GB；而一个7B级别的大语言模型，FP16权重就要14GB左右。如果部署链路的带宽是100Mbps（这在跨地域专线里已经不算差），传完14GB需要接近20分钟。对于需要频繁迭代、灰度发布、多节点分发的业务来说，这个时间成本完全无法接受。
带宽瓶颈的危害不止是慢。第一个连带问题是内存峰值：传统做法是先把完整模型文件下载到本地磁盘，再从磁盘加载到内存，这个过程中磁盘IO和内存分配都会出现双倍占用。第二个问题是失败重传成本高：14GB传到90%时网络抖动一下，如果没有断点续传机制，全部重来。第三个问题是启动延迟：冷启动服务必须等模型完全就绪才能对外提供服务，传输时间直接转化为服务不可用时间。
解决思路无非两个方向：一是让要传的东西变小，这就是量化与压缩的战场；二是让传输和加载并行起来，不必等全部数据到位，这就是流式加载的价值。两者结合，才能真正把带宽瓶颈的影响压到最低。
模型量化：从FP32到INT8甚至INT4
量化的本质是用更少的比特表示同一个数值。FP32用32个比特表示一个数，INT8只用8个，INT4只用4个。单纯从存储角度看，一个权重从FP32换成INT8，体积直接缩小到四分之一；换成INT4则缩小到八分之一。对7B模型来说，FP16的14GB经过INT4量化后大约只剩3.5GB，传输时间同步缩短到原来的四分之一，这是任何压缩算法都难以单独达到的压缩比。
量化分为两大类。第一类是训练后量化（PTQ，Post-Training Quantization），模型训练完成后直接对权重做数值映射，不需要重新训练，成本低、上手快，适合大多数部署场景。第二类是量化感知训练（QAT，Quantization-Aware Training），在训练过程中就模拟量化带来的精度损失，让模型学会适应低精度表示，精度更好但需要训练资源和数据。工程上一般优先尝试PTQ，精度不达标再考虑QAT。
来看一个基于PyTorch的INT8 PTQ示例，感受一下量化代码的实际形态：
import torch
from torch.quantization import quantize_dynamic
# 加载训练好的FP32模型
model = torch.load("bert_large_fp32.pth", map_location="cpu")
model.eval()
# 动态量化：对Linear层权重做INT8映射
quantized_model = quantize_dynamic(
model,
{torch.nn.Linear},
dtype=torch.qint8
)
# 对比权重体积
torch.save(model.state_dict(), "fp32.pth")
torch.save(quantized_model.state_dict(), "int8.pth")
# fp32.pth约1.3GB，int8.pth约330MB
量化的主要代价是精度损失。INT8量化在大多数任务上损失可以控制在1%以内，基本无感；INT4则会明显吃掉精度，尤其是对数值敏感的输出层和embedding层。实践中有几个经验：关键层保持高精度（混合精度量化）、使用per-channel量化代替per-tensor量化、量化前做好权重分布分析，都能有效缓解精度下降。
流式压缩与渐进式加载的配合
量化解决的是数据体积问题，但如果仍然采用“下载完再加载”的模式，总耗时并没有根本改善，只是线性缩短。流式压缩的思路是把模型文件切块，边传输、边解压、边加载，让网络传输、CPU解压、GPU初始化三个阶段流水线化，总耗时趋近于最慢的那个阶段而不是三者之和。
具体实现上，通常把模型权重按tensor维度切块，每一块独立压缩（可以选用LZ4、Zstd等快速压缩算法，量化后的权重压缩比通常还能再挤出10%到30%），并附加校验信息。接收端收到一个块就解压一个块，直接调用对应的加载接口把权重填进预先分配好的模型骨架中。由于模型结构在传输开始前就已经通过元数据同步，骨架可以提前构建，权重到达即可就位。
下面是一个简化的分块流式传输伪代码，展示服务端的处理逻辑：
import zstandard as zstd
import hashlib
CHUNK_SIZE = 4 * 1024 * 1024 # 每块4MB
def stream_model(weight_path, send_fn):
# 先发送元数据：tensor名称、形状、数据类型
meta = build_tensor_meta(weight_path)
send_fn(json.dumps(meta).encode())
cctx = zstd.ZstdCompressor(level=3)
with open(weight_path, "rb") as f:
while True:
raw = f.read(CHUNK_SIZE)
if not raw:
break
compressed = cctx.compress(raw)
# 附带校验和，接收端可验证完整性
checksum = hashlib.md5(compressed).hexdigest()
send_fn(len(compressed).to_bytes(4, "big"))
send_fn(compressed)
send_fn(checksum.encode())
渐进式加载还有一个隐藏优势：服务可以分级就绪。模型的关键层（比如embedding和前几层）加载完成后，服务就能以降级模式对外提供部分能力，剩余层在后台继续加载。对于大语言模型这类分层堆叠的结构，这种方式能把服务可用时间大幅提前，用户感知到的冷启动延迟显著下降。
量化加流式压缩的组合实践
两个技术并不是互斥的，最佳实践是把它们串成一条流水线：训练完成的模型先做INT8或INT4量化，量化后的权重做分块压缩，然后通过流式协议分发到各节点，接收端边解压边加载。以一个14GB的FP16大模型为例，INT4量化后约3.5GB，Zstd压缩后约2.8GB，在100Mbps链路上传输时间从20分钟压缩到4分钟左右；如果加载流水线做得好，服务就绪时间还能进一步缩短，因为最后几个块的加载可以和前面的推理预热重叠。
落地时有几个注意点值得强调。第一，量化一定要在压缩之前做，量化让权重分布变得规整，压缩算法的效率反而更高，顺序颠倒收益打折。第二，分块大小要权衡：块太小，协议开销和压缩效率下降；块太大，流水线并行度不够，一般4MB到16MB是比较稳妥的区间。第三，一定要做端到端的精度回归测试，量化的精度损失和传输的偶发损坏都需要在上线前验证，校验失败要有自动重传单个块的机制，避免整文件重来。
最后提醒一点，如果场景允许，把量化模型缓存在边缘节点或CDN上，配合按需拉取的分层缓存策略，可以把带宽瓶颈的影响再降一个量级。技术方案没有银弹，但量化加流式压缩这对组合，确实是当前工程实践中性价比最高的带宽优化路径。