端侧7B INT4量化实战：
把14.2GB压到3.9GB，
在8GB板上跑通33 tokens/s

01 为什么必须是INT4：先把显存账算清楚

7B参数量在FP16下是 7×10⁹ × 2 byte ≈ 14GB，还没算KV cache和运行时。8GB板子连权重都装不下，谈何推理。INT4把每权重量化到0.5 byte，理论体积 ≈ 3.5GB，加上量化元数据（scale/zero-point，group_size=128）实际落在 3.8–4.1GB。

更关键的是KV cache：上下文2048时，Qwen2-7B的KV约为 2 × 32层 × 2048 × 4096 × 2byte ≈ 0.42GB（FP16），INT4权重+FP16 KV的混合部署，峰值 4.6GB，刚好卡进RK3588 8GB的可控区间。同样上下文若用INT8权重（7.1GB）+KV，峰值直奔 7.8GB，系统余量归零，稍有波动就OOM。

02 量化选型实测：GPTQ vs AWQ vs GGUF，谁更稳

我们在同一校准集（C4 256条 + WikiText2 256条，seqlen 2048，seed 42）下，对同一份Qwen2-7B-Instruct做三条INT4路径，group_size统一128，其他保持官方默认。

• AWQ精度最好，但依赖CUDA kernel，RK3588 CPU/NPU路径无加速，速度反而不如GGUF；适合Jetson Orin系列。
• GGUF Q4_K_M精度与AWQ几乎打平（PPL差0.04），且llama.cpp生态对ARM/RKNN最友好，端侧通用首选。
• GPTQ已非首选：在Qwen2上PPL掉点最明显，且新版llama.cpp对GPTQ支持一般。
• Q4_0不要碰：体积只小0.13GB，PPL多掉0.17，MMLU多掉1.5pp，性价比极差。

03 复现路径：从HuggingFace到RK3588的5步流水线

所有命令均可一键复现，关键参数已锁定。校准集、随机种子、commit hash见文末证据包。

# 0. 环境：Python 3.10 · CUDA 12.1(可选) · llama.cpp b3523 · RKNN-Toolkit2 2.1
git clone https://github.com/ggerganov/llama.cpp && cd llama.cpp && make -j8

# 1. 下载权重（示例：Qwen2-7B-Instruct）
huggingface-cli download Qwen/Qwen2-7B-Instruct --local-dir ./qwen2-7b-fp16

# 2. FP16 → GGUF（先转FP16 GGUF，再量化，避免直接量化HF）
python convert_hf_to_gguf.py ./qwen2-7b-fp16 --outfile qwen2-7b-f16.gguf

# 3. 校准量化：Q4_K_M（group-wise, k-quants）
./llama-quantize qwen2-7b-f16.gguf qwen2-7b-q4_k_m.gguf Q4_K_M
# 可选：AWQ路径
# python -m awq.entry --model_path ./qwen2-7b-fp16 --w_bit 4 --q_group_size 128 --run_awq --dump_awq awq_cache

# 4. 验精度（WikiText2, seqlen 2048, 5次平均）
./llama-perplexity -m qwen2-7b-q4_k_m.gguf -f wiki.test.raw --ctx-size 2048 --batch-size 512

# 5. 端侧推理：RK3588（llama.cpp + OpenBLAS，4线程最佳）
./llama-cli -m qwen2-7b-q4_k_m.gguf -p "介绍一下边缘计算与端侧大模型的关系" \
  -n 256 -c 2048 --threads 4 --ctx-size 2048 --temp 0.2 \
  --repeat-penalty 1.1 2>&1 | tee rk3588_q4km.log

llama_print_timings:        load time =    1842.31 ms
llama_print_timings:      sample time =       0.12 ms /    256 runs
llama_print_timings:       prompt eval time =    1823.44 ms /   518 tokens (284.07 tok/s)
llama_print_timings:        eval time =    7712.85 ms /   256 runs (33.19 tok/s)
llama_print_timings:       total time =    9536.29 ms
--- power: 12.02V * 0.815A = 9.79W (AVG) · peak RSS 4.58 GB · temp 62°C ---
huayun-bench: 5 runs avg 33.2 tok/s (32.8, 33.4, 33.1, 33.5, 33.2) · TTFT 680±18ms

04 端侧实测：在同一块板上，速度与功耗的真实对比

同一块RK3588 8GB开发板（固件1.1.5，governor=performance，风扇主动散热，室温25℃），同一份prompt（512 token输入，生成256 token，temp 0），每组5次取平均。

读数说明：RK3588是8GB端侧的甜点—— tok/s是RPi5的4倍，功耗仅高38%，且NPU/CPU混合调度后仍可保持40℃温差内的稳定输出；Orin Nano靠CUDA更快，但成本与功耗同步上一个台阶，适合对TTFT要求＜600ms的场景。

05 精度损失到底多大：不只看PPL

PPL是底线，业务是上限。我们在真实业务prompt（设备告警摘要、工单生成、知识问答三类，各200条）上做盲测与自动评测。

结论很清晰：日常对话与摘要类任务，INT4几乎无感（-2pp以内）；数学与强推理是重灾区（-5.6pp）。如果你的端侧场景以“理解+生成+摘要”为主，INT4可直接商用；若以“复杂计算/代码生成”为主，建议保留云端FP16链路，端侧做初筛。

掉点不是均匀的——INT4最先丢的是“需要多步符号推理”的能力，最后丢的是“语言流畅度”。先测你的任务，再定量化策略。

06 避坑清单：我们踩过的4个深坑

07 什么时候不该用INT4

INT4不是银弹。我们给出三条红线：

• 红线1：PPL敏感型——金融/医疗等对幻觉零容忍的场景，+0.31的PPL可能已越界，建议INT8或FP16，端侧只做缓存。
• 红线2：长推理链——GSM8K掉5.6pp的信号很明确，复杂CoT請走云端。
• 红线3：上下文>8k且不可裁剪——先解决KV，再谈权重量化，否则本末倒置。

除此之外，8GB端侧上7B，INT4是当前唯一能同时满足“装得下、跑得快、掉点可接受、功耗不过热”的解。我们已在华云边缘网关（RK3588 8GB）上将该方案固化为标准镜像，支持OTA下发与云端FP16双轨回退。