目录推理优化概述模型量化：FP16 到 INT4模型剪枝：结构化与非结构化知识蒸馏：大模型教小模型KV Cache 优化：PagedAttention 与共享推理引擎：vLLM、TensorRT-LLM实践建议与最佳实践摘要推理优化的目标是在精度损失可控的前提下压缩模型体积并提高服务吞吐：以 7B 模型为例，FP16 权重占用约 14GB 显存，INT4 量化后降至约 3.5GB，解码吞吐可从约 100 tokens/s 提升到 250-350 tokens/s，WikiText-2 困惑度增幅通常不超过 0.2。KV Cache 通过 PagedAttention 分页与前缀共享可将显存利用率从约 20-40% 提高到 95% 以上，推理吞吐提升 2-4 倍。本文依次讨论量化、剪枝、蒸馏、KV Cache 优化与推理引擎选型，并给出可落地的优化流程与性能测试方法。1. 推理优化概述自回归大模型在服务阶段的成本结构与训练阶段完全不同。训练看重算力吞吐，而推理阶段每个生成的 token 都依赖全部权重矩阵与注意力历史状态，成本由"权重读取带宽"和"KV Cache 显存"两个因素主导。推理优化的本质是把这两类资源按需求重新分配：降低权重精度以减少带宽压力，压缩中间状态以减少显存占用，再用更高效的调度器把 GPU 的算力填满。本章先给出推理优化的整体决策路径，再从必要性、目标、挑战三个角度建立分析框架。后续各章分别展开量化、剪枝、蒸馏、KV Cache 与推理引擎五个优化面。优化手段组合是否超过未超过未达标达标输入 7B FP16 模型显存是否满足 24GB 以下部署直接部署 FP16 基线进入优化路径FP16 解码约 100 tokens/s模型量化 INT8 或 INT4KV Cache 优化结构化剪枝或蒸馏精度损失是否超过阈值 1%回退到 INT8 或 QAT 补偿采用量化配置PagedAttention 与前缀缓存小模型替代推理引擎部署吞吐与延迟是否达标上线并监控持续采集性能数据1.1 推理优化的必要性自回归解码是典型的"带宽受限"过程。生成一个 token 需要把模型全部权重从显存搬运到计算单元，在 FP16 精度下，7B 模型每次解码要读取约 14GB 数据。以 A100 约 2TB/s 的 HBM 带宽估算，理论单 token 时间约 7ms，折算约 140 tokens/s，实际考虑调度与中间张量开销，单并发实测约 80-120 tokens/s。如果把精度降到 INT4，权重体积缩为 3.5GB，同样带宽下的理论解码速度提升到约 570 tokens/s，实测约 250-350 tokens/s，差距来自反量化与内核开销。显存约束同样成立。FP16 权重 14GB，加上 KV Cache，LLaMA-2-7B 在 4096 token 上下文下 KV Cache 约 2GB，加上激活值与框架缓冲，24GB 显卡只剩很小的余量给并发。而 INT4 量化后权重 3.5GB，同样的卡可以把并发 batch 从 2-4 提升到 16-32，服务成本按每 token 的 GPU 时间折算可下降 60-75%。以下代码用参数数量与精度档位估算权重显存和 KV Cache 显存，可直接复算不同模型规模的资源需求。# 来源：自实现 / memory_estimator.py"""按参数数量与精度估算 LLM 推理的权重显存与 KV Cache 显存。"""classMemoryEstimator:BYTES={"fp32":4,"fp16":2,"int8":1,"int4":0.5}def__init__(self,params,layers,kv_heads,head_dim,seq_len,dtype):# params 为总参数量，layers 为层数，kv_heads 为 KV 头数self.params=params self.layers=layers self.kv_heads=kv_heads self.head_dim=head_dim self.seq_len=seq_len self.dtype=dtypedefweight_memory_gb(self):# 用十进制 GB（1e9）口径，与业界 7B 权重约 14GB 的说法一致returnself.params*self.BYTES[self.dtype]/1e9defkv_cache_per_token_bytes(self):# K 与 V 各一份，单位字节return2*self.layers*self.kv_heads*self.head_dim*self.BYTES[self.dtype]defkv_cache_gb(self):returnself.kv_cache_per_token_bytes()*self.seq_len/1024**3deftotal_gb(self):returnself.weight_memory_gb()+self.kv_cache_gb()defsummary(self):return(f"dtype={self.dtype}, params={self.params/1e9:.1f}B, "f"weight={self.weight_memory_gb():.1f}GB, "f"kv_cache={self.kv_cache_gb():.2f}GB, total={self.total_gb():.2f}GB")if__name__=="__main__":# LLaMA-2-7B：32 层、32 个 KV 头、head_dim 128、2048 上下文fp16=MemoryEstimator(7e9,32,32,128,2048,"fp16")int8=MemoryEstimator(7e9,32,32,128,2048,"int8")int4=MemoryEstimator(7e9,32,32,128,2048,"int4")print(fp16.summary())print(int8.summary())print(int4.summary())print(f"FP16 到 INT4 权重显存下降{fp16.weight_memory_gb()/int4.weight_memory_gb():.1f}倍")以 7B 模型在 2048 上下文下的估算结果对比如下，其中 KV Cache 与权重同步缩放，是量化收益的直接来源。精度权重显存KV Cache（2048 token）合计单并发解码吞吐（A100 实测区间）FP1614.0GB1.0GB15.0GB80-120 tokens/sINT87.0GB0.5GB7.5GB140-200 tokens/sINT43.5GB0.25GB3.75GB250-350 tokens/s量化之外还有一条隐性必要性：长上下文服务。即使权重体积不变，KV Cache 随序列长度线性增长，seq_len 从 2048 翻到 8192，KV Cache 占用也翻 4 倍。不对 KV Cache 做分页管理或量化，多用户并发就会因显存碎片化而反复触发 OOM，这是本章引入 5.1 节 PagedAttention 的背景。1.2 推理优化的目标推理优化服务于三个可以度量的目标，它们之间经常互相冲突，需要给出优先级。第一个目标是降低端到端延迟，通常拆成首 token 延迟（TTFT，指从请求到达网络到返回第一个 token 的时间）和每 token 延迟（TPOT，指后续每个 token 的平均生成时间）。TTFT 由 prefill 阶段决定，属于计算受限；TPOT 由解码阶段决定，属于带宽受限。对 7B FP16 模型，1024 token 的 prompt 在 A100 上 prefill 约 60-100ms，而 decode 单 token 约 10-15ms。第二个目标是提高吞吐，单位是每秒生成的 token 数或每秒处理的请求数。提高吞吐的手段主要是连续批处理：让新请求在旧请求生成的间隙立即插入 GPU 计算，而不是等整个 batch 结束。vLLM 的论文报告，相比 HuggingFace Transformers 的朴素服务，其吞吐最高提升 24 倍，相比先前的批处理系统 Orca 提升 2-4 倍。第三个目标是降低单位成本，包括显存占用和单 token 成本。7B 模型 INT4 部署在 8GB 显存的显卡上即可运行，相比 24GB 显存的 FP16 部署，租用成本通常下降 40-60%。三个目标需要显式排序：交互式对话把 TTFT 放在第一位，离线批量生成把吞吐放在第一位，SLA 敏感的商业服务则优先保证 TPOT 的 p99。# 来源：自实现 / latency_stats.py"""从一批请求的完成时间计算 TTFT、TPOT 与吞吐统计量。"""classLatencyStats:def__init__(self,ttft_ms,per_token_ms,total_tokens,total_elapsed_s):self.ttft_ms=ttft_ms self.per_token_ms=per_token_ms self.total_tokens=total_tokens self.total_elapsed_s=total_elapsed_sdefthroughput_tokens_per_s(self):returnself.total_tokens/self.total_elapsed_sdefpercentile(self,values,p):ordered=sorted(values)idx=min(len(ordered)-1,int(len(ordered)*p))returnordered[idx]defreport(self):return{"TTFT_ms":self.ttft_ms,"TPOT_ms":self.per_token_ms,"throughput_tokens_per_s":round(self.throughput_tokens_per_s(),1),}defsimulate_requests(count,tokens_per_request,tokens_per_s):"""模拟并发请求按固定速率产出 token，返回逐请求统计。"""importrandom elapsed=0.0stats=[]for_inrange(count):elapsed+=random.uniform(0.2,0.8)# 调度器插入新请求的间隔ttft=random.uniform(40,90)# prefill 阶段毫秒gen_s=tokens_per_request/tokens_per_s elapsed+=gen_s tpot=gen_s/tokens_per_request*1000stats.append(LatencyStats(ttft,tpot,tokens_per_request,elapsed))returnstatsif__name__=="__main__":# 7B FP16 单卡 A100，单并发约 100 tokens/s，50 个请求各 256 tokenresults=simulate_requests(50,256,100)tpots=sorted(s.per_token_msforsinresults)p50=tpots[len(tpots)//2]print("请求数:",len(results))print("TPOT p50:",round(p50,2),"ms")print("总生成 token:",sum(s.total_tokensforsinresults))print("完成耗时:",round(results[-1].total_elapsed_s,2),"s")这里用统计函数 percentile 辅助分析延迟分布，实际压测时把每轮请求的 TTFT 与 TPOT 收集后，用同样的分位逻辑产出 p50/p99，作为 SLA 判定依据。1.3 推理优化的挑战推理优化面临的第一个挑战是精度与效率的权衡。量化和剪枝都会改变权重分布，精度损失在任务敏感型场景会直接反映为业务指标下降。以困惑度为例，LLaMA-2-7B 在 WikiText-2 上 FP16 基线约 5.68，GPTQ 论文报告的 4 位量化约 5.85，增幅约 0.17，而同样 4 位下简单的就近取整（RTN）达到约 6.29，说明量化方法的选择比位数本身更影响结果。第二个挑战是多种优化手段的叠加效应。量化、剪枝、蒸馏、KV Cache 优化并非完全正交：先剪枝再量化，剪枝留下的异常值会撑大量化范围；先量化再蒸馏，教师和学生都在低精度下训练，误差会累积。工程上通常按"量化与 KV Cache 优先，剪枝与蒸馏按需"的顺序实施，每加一步都要重新验证精度。第三个挑战是硬件适配。NVIDIA 的 TensorRT-LLM 只支持自家 GPU，vLLM 通过 ROCm 支持 AMD 但内核效率有差距，Apple 芯片需要 Metal 后端的 llama.cpp 或 MLC-LLM。同一个 INT4 权重在不同后端上的吞吐差异可能达到 30-50%，不能把 A100 上的 benchmark 数字直接搬到其他硬件。# 来源：自实现 / tradeoff_search.py"""在量化配置集合上搜索满足精度约束且吞吐最高的配置。"""classTradeoffSearch:def__init__(self,baseline_ppl,max_ppl_loss):# baseline_ppl 为 FP16 基线困惑度，max_ppl_loss 为允许的最大增幅self.baseline_ppl=baseline_ppl self.max_ppl_loss=max_ppl_loss self.candidates=[{"name":"INT8 per-channel","ppl_loss":0.05,"speedup":1.6},{"name":"INT4 group128","ppl_loss":0.20,"speedup":2.6},{"name":"INT4 AWQ","ppl_loss":0.12,"speedup":2.4},{"name":"FP8 E4M3","ppl_loss":0.03,"speedup":1.3},]deffeasible(self,cand):returncand["ppl_loss"]=self.max_ppl_lossdefbest(self):ok=[cforcinself.candidatesifself.feasible(c)]ifnotok:returnNonereturnmax(ok,key=lambdac:c["speedup"])if__name__=="__main__":search=TradeoffSearch(baseline_ppl=5.68,max_ppl_loss=0.15)feasible=[cforcinsearch.candidatesifsearch.feasible(c)]best=search.best()print("可行配置数:",len(feasible))print("最优配置:",best)挑战维度可以归纳为下表，其中的约束关系决定了后文各优化技术的适用边界。挑战典型表现缓解手段精度损失INT4 RTN 困惑度增幅约 0.61改用 GPTQ/AWQ 或 QAT 补偿手段叠加剪枝后量化范围被异常值撑大先量化后剪枝，或分步验证硬件差异同一 INT4 权重跨后端吞吐差 30-50%按目标硬件选择引擎与内核上下文增长KV Cache 随序列长度线性膨胀分页管理、前缀共享、KV 量化这四个挑战共同决定了推理优化不是一个一次性的转换动作，而是一个需要反复测量、回退、再验证的迭代过程。1.1 节给出量化收益的物理基础，1.2 节定义三个可度量的目标，本节划定约束边界，后续各章针对每条约束给出具体解法。2. 模型量化：FP16 到 INT4量化把连续的浮点权重和激活映射到离散的低比特整数，直接压缩权重体积、降低内存带宽压力，并用低精度矩阵乘内核换取吞吐。对 7B 模型，FP16 到 INT8 权重减半，到 INT4 再减半，是收益比最高的优化手段。量化的代价是精度损失，但通过对称量化、分组缩放、保护显著通道等方法，可以在困惑度增幅约 0.1-0.2 的范围内把权重压到 4 位。量化感知训练 QAT训练后量化 PTQINT8INT4 从14GB到3.5GB：大模型推理优化的终极生存指南
目录推理优化概述模型量化：FP16 到 INT4模型剪枝：结构化与非结构化知识蒸馏：大模型教小模型KV Cache 优化：PagedAttention 与共享推理引擎：vLLM、TensorRT-LLM实践建议与最佳实践摘要推理优化的目标是在精度损失可控的前提下压缩模型体积并提高服务吞吐：以 7B 模型为例，FP16 权重占用约 14GB 显存，INT4 量化后降至约 3.5GB，解码吞吐可从约 100 tokens/s 提升到 250-350 tokens/s，WikiText-2 困惑度增幅通常不超过 0.2。KV Cache 通过 PagedAttention 分页与前缀共享可将显存利用率从约 20-40% 提高到 95% 以上，推理吞吐提升 2-4 倍。本文依次讨论量化、剪枝、蒸馏、KV Cache 优化与推理引擎选型，并给出可落地的优化流程与性能测试方法。1. 推理优化概述自回归大模型在服务阶段的成本结构与训练阶段完全不同。训练看重算力吞吐，而推理阶段每个生成的 token 都依赖全部权重矩阵与注意力历史状态，成本由"权重读取带宽"和"KV Cache 显存"两个因素主导。推理优化的本质是把这两类资源按需求重新分配：降低权重精度以减少带宽压力，压缩中间状态以减少显存占用，再用更高效的调度器把 GPU 的算力填满。本章先给出推理优化的整体决策路径，再从必要性、目标、挑战三个角度建立分析框架。后续各章分别展开量化、剪枝、蒸馏、KV Cache 与推理引擎五个优化面。优化手段组合是否超过未超过未达标达标输入 7B FP16 模型显存是否满足 24GB 以下部署直接部署 FP16 基线进入优化路径FP16 解码约 100 tokens/s模型量化 INT8 或 INT4KV Cache 优化结构化剪枝或蒸馏精度损失是否超过阈值 1%回退到 INT8 或 QAT 补偿采用量化配置PagedAttention 与前缀缓存小模型替代推理引擎部署吞吐与延迟是否达标上线并监控持续采集性能数据1.1 推理优化的必要性自回归解码是典型的"带宽受限"过程。生成一个 token 需要把模型全部权重从显存搬运到计算单元，在 FP16 精度下，7B 模型每次解码要读取约 14GB 数据。以 A100 约 2TB/s 的 HBM 带宽估算，理论单 token 时间约 7ms，折算约 140 tokens/s，实际考虑调度与中间张量开销，单并发实测约 80-120 tokens/s。如果把精度降到 INT4，权重体积缩为 3.5GB，同样带宽下的理论解码速度提升到约 570 tokens/s，实测约 250-350 tokens/s，差距来自反量化与内核开销。显存约束同样成立。FP16 权重 14GB，加上 KV Cache，LLaMA-2-7B 在 4096 token 上下文下 KV Cache 约 2GB，加上激活值与框架缓冲，24GB 显卡只剩很小的余量给并发。而 INT4 量化后权重 3.5GB，同样的卡可以把并发 batch 从 2-4 提升到 16-32，服务成本按每 token 的 GPU 时间折算可下降 60-75%。以下代码用参数数量与精度档位估算权重显存和 KV Cache 显存，可直接复算不同模型规模的资源需求。# 来源：自实现 / memory_estimator.py"""按参数数量与精度估算 LLM 推理的权重显存与 KV Cache 显存。"""classMemoryEstimator:BYTES={"fp32":4,"fp16":2,"int8":1,"int4":0.5}def__init__(self,params,layers,kv_heads,head_dim,seq_len,dtype):# params 为总参数量，layers 为层数，kv_heads 为 KV 头数self.params=params self.layers=layers self.kv_heads=kv_heads self.head_dim=head_dim self.seq_len=seq_len self.dtype=dtypedefweight_memory_gb(self):# 用十进制 GB（1e9）口径，与业界 7B 权重约 14GB 的说法一致returnself.params*self.BYTES[self.dtype]/1e9defkv_cache_per_token_bytes(self):# K 与 V 各一份，单位字节return2*self.layers*self.kv_heads*self.head_dim*self.BYTES[self.dtype]defkv_cache_gb(self):returnself.kv_cache_per_token_bytes()*self.seq_len/1024**3deftotal_gb(self):returnself.weight_memory_gb()+self.kv_cache_gb()defsummary(self):return(f"dtype={self.dtype}, params={self.params/1e9:.1f}B, "f"weight={self.weight_memory_gb():.1f}GB, "f"kv_cache={self.kv_cache_gb():.2f}GB, total={self.total_gb():.2f}GB")if__name__=="__main__":# LLaMA-2-7B：32 层、32 个 KV 头、head_dim 128、2048 上下文fp16=MemoryEstimator(7e9,32,32,128,2048,"fp16")int8=MemoryEstimator(7e9,32,32,128,2048,"int8")int4=MemoryEstimator(7e9,32,32,128,2048,"int4")print(fp16.summary())print(int8.summary())print(int4.summary())print(f"FP16 到 INT4 权重显存下降{fp16.weight_memory_gb()/int4.weight_memory_gb():.1f}倍")以 7B 模型在 2048 上下文下的估算结果对比如下，其中 KV Cache 与权重同步缩放，是量化收益的直接来源。精度权重显存KV Cache（2048 token）合计单并发解码吞吐（A100 实测区间）FP1614.0GB1.0GB15.0GB80-120 tokens/sINT87.0GB0.5GB7.5GB140-200 tokens/sINT43.5GB0.25GB3.75GB250-350 tokens/s量化之外还有一条隐性必要性：长上下文服务。即使权重体积不变，KV Cache 随序列长度线性增长，seq_len 从 2048 翻到 8192，KV Cache 占用也翻 4 倍。不对 KV Cache 做分页管理或量化，多用户并发就会因显存碎片化而反复触发 OOM，这是本章引入 5.1 节 PagedAttention 的背景。1.2 推理优化的目标推理优化服务于三个可以度量的目标，它们之间经常互相冲突，需要给出优先级。第一个目标是降低端到端延迟，通常拆成首 token 延迟（TTFT，指从请求到达网络到返回第一个 token 的时间）和每 token 延迟（TPOT，指后续每个 token 的平均生成时间）。TTFT 由 prefill 阶段决定，属于计算受限；TPOT 由解码阶段决定，属于带宽受限。对 7B FP16 模型，1024 token 的 prompt 在 A100 上 prefill 约 60-100ms，而 decode 单 token 约 10-15ms。第二个目标是提高吞吐，单位是每秒生成的 token 数或每秒处理的请求数。提高吞吐的手段主要是连续批处理：让新请求在旧请求生成的间隙立即插入 GPU 计算，而不是等整个 batch 结束。vLLM 的论文报告，相比 HuggingFace Transformers 的朴素服务，其吞吐最高提升 24 倍，相比先前的批处理系统 Orca 提升 2-4 倍。第三个目标是降低单位成本，包括显存占用和单 token 成本。7B 模型 INT4 部署在 8GB 显存的显卡上即可运行，相比 24GB 显存的 FP16 部署，租用成本通常下降 40-60%。三个目标需要显式排序：交互式对话把 TTFT 放在第一位，离线批量生成把吞吐放在第一位，SLA 敏感的商业服务则优先保证 TPOT 的 p99。# 来源：自实现 / latency_stats.py"""从一批请求的完成时间计算 TTFT、TPOT 与吞吐统计量。"""classLatencyStats:def__init__(self,ttft_ms,per_token_ms,total_tokens,total_elapsed_s):self.ttft_ms=ttft_ms self.per_token_ms=per_token_ms self.total_tokens=total_tokens self.total_elapsed_s=total_elapsed_sdefthroughput_tokens_per_s(self):returnself.total_tokens/self.total_elapsed_sdefpercentile(self,values,p):ordered=sorted(values)idx=min(len(ordered)-1,int(len(ordered)*p))returnordered[idx]defreport(self):return{"TTFT_ms":self.ttft_ms,"TPOT_ms":self.per_token_ms,"throughput_tokens_per_s":round(self.throughput_tokens_per_s(),1),}defsimulate_requests(count,tokens_per_request,tokens_per_s):"""模拟并发请求按固定速率产出 token，返回逐请求统计。"""importrandom elapsed=0.0stats=[]for_inrange(count):elapsed+=random.uniform(0.2,0.8)# 调度器插入新请求的间隔ttft=random.uniform(40,90)# prefill 阶段毫秒gen_s=tokens_per_request/tokens_per_s elapsed+=gen_s tpot=gen_s/tokens_per_request*1000stats.append(LatencyStats(ttft,tpot,tokens_per_request,elapsed))returnstatsif__name__=="__main__":# 7B FP16 单卡 A100，单并发约 100 tokens/s，50 个请求各 256 tokenresults=simulate_requests(50,256,100)tpots=sorted(s.per_token_msforsinresults)p50=tpots[len(tpots)//2]print("请求数:",len(results))print("TPOT p50:",round(p50,2),"ms")print("总生成 token:",sum(s.total_tokensforsinresults))print("完成耗时:",round(results[-1].total_elapsed_s,2),"s")这里用统计函数 percentile 辅助分析延迟分布，实际压测时把每轮请求的 TTFT 与 TPOT 收集后，用同样的分位逻辑产出 p50/p99，作为 SLA 判定依据。1.3 推理优化的挑战推理优化面临的第一个挑战是精度与效率的权衡。量化和剪枝都会改变权重分布，精度损失在任务敏感型场景会直接反映为业务指标下降。以困惑度为例，LLaMA-2-7B 在 WikiText-2 上 FP16 基线约 5.68，GPTQ 论文报告的 4 位量化约 5.85，增幅约 0.17，而同样 4 位下简单的就近取整（RTN）达到约 6.29，说明量化方法的选择比位数本身更影响结果。第二个挑战是多种优化手段的叠加效应。量化、剪枝、蒸馏、KV Cache 优化并非完全正交：先剪枝再量化，剪枝留下的异常值会撑大量化范围；先量化再蒸馏，教师和学生都在低精度下训练，误差会累积。工程上通常按"量化与 KV Cache 优先，剪枝与蒸馏按需"的顺序实施，每加一步都要重新验证精度。第三个挑战是硬件适配。NVIDIA 的 TensorRT-LLM 只支持自家 GPU，vLLM 通过 ROCm 支持 AMD 但内核效率有差距，Apple 芯片需要 Metal 后端的 llama.cpp 或 MLC-LLM。同一个 INT4 权重在不同后端上的吞吐差异可能达到 30-50%，不能把 A100 上的 benchmark 数字直接搬到其他硬件。# 来源：自实现 / tradeoff_search.py"""在量化配置集合上搜索满足精度约束且吞吐最高的配置。"""classTradeoffSearch:def__init__(self,baseline_ppl,max_ppl_loss):# baseline_ppl 为 FP16 基线困惑度，max_ppl_loss 为允许的最大增幅self.baseline_ppl=baseline_ppl self.max_ppl_loss=max_ppl_loss self.candidates=[{"name":"INT8 per-channel","ppl_loss":0.05,"speedup":1.6},{"name":"INT4 group128","ppl_loss":0.20,"speedup":2.6},{"name":"INT4 AWQ","ppl_loss":0.12,"speedup":2.4},{"name":"FP8 E4M3","ppl_loss":0.03,"speedup":1.3},]deffeasible(self,cand):returncand["ppl_loss"]=self.max_ppl_lossdefbest(self):ok=[cforcinself.candidatesifself.feasible(c)]ifnotok:returnNonereturnmax(ok,key=lambdac:c["speedup"])if__name__=="__main__":search=TradeoffSearch(baseline_ppl=5.68,max_ppl_loss=0.15)feasible=[cforcinsearch.candidatesifsearch.feasible(c)]best=search.best()print("可行配置数:",len(feasible))print("最优配置:",best)挑战维度可以归纳为下表，其中的约束关系决定了后文各优化技术的适用边界。挑战典型表现缓解手段精度损失INT4 RTN 困惑度增幅约 0.61改用 GPTQ/AWQ 或 QAT 补偿手段叠加剪枝后量化范围被异常值撑大先量化后剪枝，或分步验证硬件差异同一 INT4 权重跨后端吞吐差 30-50%按目标硬件选择引擎与内核上下文增长KV Cache 随序列长度线性膨胀分页管理、前缀共享、KV 量化这四个挑战共同决定了推理优化不是一个一次性的转换动作，而是一个需要反复测量、回退、再验证的迭代过程。1.1 节给出量化收益的物理基础，1.2 节定义三个可度量的目标，本节划定约束边界，后续各章针对每条约束给出具体解法。2. 模型量化：FP16 到 INT4量化把连续的浮点权重和激活映射到离散的低比特整数，直接压缩权重体积、降低内存带宽压力，并用低精度矩阵乘内核换取吞吐。对 7B 模型，FP16 到 INT8 权重减半，到 INT4 再减半，是收益比最高的优化手段。量化的代价是精度损失，但通过对称量化、分组缩放、保护显著通道等方法，可以在困惑度增幅约 0.1-0.2 的范围内把权重压到 4 位。量化感知训练 QAT训练后量化 PTQINT8INT4