完整题目
对一个典型的13B参数大语言模型进行INT8或INT4量化后，估算其模型存储大小，并分析量化对推理延迟、吞吐量和硬件资源消耗的影响。
本文目录
核心判断
13B模型只算权重时，FP16或BF16约为260亿字节，也就是26GB十进制容量；INT8约13GB，INT4约6.5GB。换成二进制单位分别约24.2GiB、12.1GiB和6.1GiB。真实文件和显存会多出量化 scale、zero point、分组元数据、对齐与运行时缓冲，还要另外容纳激活和KV缓存，因此这些数字只能做裸权重下界。
机制与边界
量化影响取决于权重位宽、激活位宽、量化粒度、校准数据和内核。GPTQ与AWQ常见的是权重量化、激活保持较高精度；权重更小会减轻显存容量和带宽压力，特别是在解码阶段的访存瓶颈下可能提速。但如果硬件没有合适内核，反量化、打包格式转换或小 batch 调度会抵消收益。INT8并非天然几乎无损，INT4也不是固定掉点，质量要按模型、任务、组大小和校准集验证。
不能从权重缩小两倍或四倍，直接推出 batch 也扩大两倍或四倍。长上下文服务里KV缓存可能才是主要显存项，prefill还会受激活和临时张量影响。吞吐也不能承诺超过两倍，因为瓶颈可能在计算、内存、调度、网络或采样。硬件代际的支持要看具体数据类型、Tensor Core路径、推理框架和内核，不能用“某架构没有原生INT4”一句话覆盖所有实现。量化模型文件的GB和运行时峰值GiB也应分开报告。
工程验证
选一个真实服务栈，在相同模型版本、上下文长度、输出长度和并发分布下测试FP16、INT8与INT4。质量侧按任务分桶看准确率、困惑度、格式合规、长文本和高风险样本；性能侧记录模型加载后显存、KV每token增长、首token延迟、逐token延迟、请求吞吐、能耗和尾延迟。再扫 batch 与序列长度，画出容量和吞吐曲线。只有在固定质量门槛下仍有收益，才接受该量化配置；裸权重估算不能替代端到端profile。
部署还要区分预填充和逐token解码。预填充在长prompt下可能更偏计算瓶颈，解码在小batch时更偏权重带宽；同一个INT4模型在两阶段的加速比可能完全不同。权重压缩也不会自动压缩KV，除非另外采用KV量化或改变注意力头结构。多卡时，张量并行通信和每卡分片粒度也会改变收益，模型能装下只代表容量达标，不代表延迟达标。
因此性能结论必须同时注明阶段、并发、序列长度、硬件和推理框架版本。
图解
继续追问 · 3 个问题
- INT4量化常见的精度回退问题如何解决，比如GPTQ、AWQ、GGUF等方案的核心区别是什么
- 实际部署中如何确定最优的量化配置，有没有自动化搜索的方法
- 量化对长上下文场景（如32K+）的KV Cache压力缓解具体有多大收益
换一种问法，检查是否真正理解
场景切入
假设现在要把一个 13B 模型部署到显存受限的单卡环境，考虑 INT8 或 INT4。你会怎样估算容量，并在明确质量门槛下验证能否上线？
层层追问
只算裸权重时 FP16、INT8、INT4 各多大？……scale、zero point、激活、KV 和缓冲还占什么？……权重缩小为何不保证延迟或吞吐同比改善？
直球技术
请估算 13B 模型的 FP16、INT8、INT4 裸权重大小，并分析量化元数据、运行时显存、kernel 支持、质量、TTFT、TPOT 与吞吐的条件化影响。
练习口述回答 · 约4分钟（先30秒，再90秒，可继续展开）
- 30秒：给出裸权重计算与单位
- 90秒：量化格式、内核和质量
- 边界：KV、激活与吞吐不能按比例外推
- 验证：同质量门槛下做端到端profile
如果只给我三十秒，我会这样回答：13B模型只算权重时，FP16或BF16约为260亿字节，也就是26GB十进制容量；INT8约13GB，INT4约6.5GB。换成二进制单位分别约24.2GiB、12.1GiB和6.1GiB。真实文件和显存会多出量化 scale、zero point、分组元数据、对齐与运行时缓冲，还要另外容纳激活和KV缓存，因此这些数字只能做裸权重下界。
如果有九十秒，我会把机制讲清楚。量化影响取决于权重位宽、激活位宽、量化粒度、校准数据和内核。GPTQ与AWQ常见的是权重量化、激活保持较高精度；权重更小会减轻显存容量和带宽压力，特别是在解码阶段的访存瓶颈下可能提速。但如果硬件没有合适内核，反量化、打包格式转换或小 batch 调度会抵消收益。INT8并非天然几乎无损，INT4也不是固定掉点，质量要按模型、任务、组大小和校准集验证。
继续展开时，我会补上容易混淆的边界。不能从权重缩小两倍或四倍，直接推出 batch 也扩大两倍或四倍。长上下文服务里KV缓存可能才是主要显存项，prefill还会受激活和临时张量影响。吞吐也不能承诺超过两倍，因为瓶颈可能在计算、内存、调度、网络或采样。硬件代际的支持要看具体数据类型、Tensor Core路径、推理框架和内核，不能用“某架构没有原生INT4”一句话覆盖所有实现。量化模型文件的GB和运行时峰值GiB也应分开报告。
落地时我会这样验证。选一个真实服务栈，在相同模型版本、上下文长度、输出长度和并发分布下测试FP16、INT8与INT4。质量侧按任务分桶看准确率、困惑度、格式合规、长文本和高风险样本；性能侧记录模型加载后显存、KV每token增长、首token延迟、逐token延迟、请求吞吐、能耗和尾延迟。再扫 batch 与序列长度，画出容量和吞吐曲线。只有在固定质量门槛下仍有收益，才接受该量化配置；裸权重估算不能替代端到端profile。
部署还要区分预填充和逐token解码。预填充在长prompt下可能更偏计算瓶颈，解码在小batch时更偏权重带宽；同一个INT4模型在两阶段的加速比可能完全不同。权重压缩也不会自动压缩KV，除非另外采用KV量化或改变注意力头结构。多卡时，张量并行通信和每卡分片粒度也会改变收益，模型能装下只代表容量达标，不代表延迟达标。
因此性能结论必须同时注明阶段、并发、序列长度、硬件和推理框架版本。