AI DeepSeek：量化不够用了之后

DeepSeek 量化模型 代码模型
作者: 醉月思 发布日期: 2025-12-11 分类: 技术实践

年初的时候，我的主力开发机器是一台 16GB 显存的 4080 本地机，跑个 7B 模型还得精打细算，13B 更是想都不敢想。

为什么折腾这个

老实说，一开始的想法很简单：本地跑代码助手，不用把代码扔到外网。

但现实很骨感。DeepSeek-Coder V2 这类模型，FP16 版本动辄就要 26GB+ 显存起步，哪怕只跑推理，13B 模型在我这 16GB 显存上都是奢望。硬要跑？要么 OOM，要么卡成PPT。

但换个角度想，代码模型真的需要 FP16 的精度吗？大部分场景下，我们需要的只是一个能补全代码、解释逻辑、给建议的助手，不是科学研究级的数值精度。如果能在质量损失可控的前提下，把显存需求砍掉 3/4，那这就不是"能不能"的问题，而是"怎么做到"的问题。

量化技术就是为了解决这个问题。

什么是量化

用人话说，量化就是把模型的参数从高精度数（比如 FP16 的 16 位浮点数）压缩到低精度数（比如 INT4 的 4 位整数）。

但别被"压缩"这个说法骗了——这不是 zip 压缩，不能随便解压就完事。量化本质上是把一个连续的浮点空间映射到一个有限的整数空间里，有点像把 0.1 到 1.0 的所有小数强行塞进 0 到 15 的整数里。

这个过程必然有信息损失，但模型训练时就已经考虑到了"在什么位置损失最小"这个问题。只要量化得当，大部分情况下生成的代码质量和推理结果不会明显变差。

常见的量化精度：

  • INT8：8 位整数，精度损失较小，显存节省约 50%
  • INT4：4 位整数，显存节省约 75%，但需要更谨慎地校准
  • FP8：8 位浮点数，介于 INT8 和 FP16 之间的折中方案

对于代码模型这种生成任务，INT4 通常够用，前提是量化工具靠谱、校准数据合理。

整体思路

先说结果：最终选择用 llama.cpp 的 INT4 量化方案，把 DeepSeek-Coder V2 跑在本地，显存占用从 26GB 降到约 7GB，推理速度提升了约 2 倍。

整个过程可以分成这几步：

graph TD A[原始 FP16 模型] --> B{选择量化工具} B --> C[llama.cpp INT4] B --> D[AutoGPTQ] B --> E[AWQ] C --> F[量化校准] D --> F E --> F F --> G[性能测试] G --> H{质量是否达标} H -->|是| I[本地部署] H -->|否| J[调整参数或工具] J --> F I --> K[长期使用评估]

具体实现

环境准备

先说明一下我的硬件环境，这对量化方案选择很关键：

  • GPU: NVIDIA RTX 4080 16GB
  • CPU: AMD Ryzen 9 7950X
  • RAM: 64GB DDR5
  • OS: Ubuntu 22.04 LTS

为什么强调 CPU 和 RAM？因为 llama.cpp 支持 GPU offloading，但如果显存不够，它会自动把部分计算 offload 到 CPU。这时候大内存就有用了。

量化工具选择

市面上常见的量化工具主要有三个：

  1. llama.cpp:

    • 优点：成熟稳定，社区活跃，支持 INT4/INT5/INT8 多种量化
    • 缺点：对某些模型架构的支持需要等待更新
    • 适合：追求稳定性和通用性

  2. AutoGPTQ:

    • 优点：量化质量高，专门为 LLM 优化
    • 缺点：依赖较多，配置相对复杂
    • 适合：对精度有极致要求的场景

  3. AWQ (Activation-aware Weight Quantization):

    • 优点：激活感知量化，理论上质量更好
    • 缺点：相对较新，生态还在发展
    • 适合：愿意尝鲜且愿意踩坑的场景

我最终选 llama.cpp 的原因是：当时 DeepSeek 官方已经给出了 llama.cpp 的量化建议，社区也有现成的转换脚本，踩坑成本低。

转换步骤

  1. 下载原始模型
git lfs install
git clone https://huggingface.co/deepseek-ai/DeepSeek-Coder-V2-Lite-Instruct
  1. 转换为 GGUF 格式

llama.cpp 使用 GGUF 格式，需要先把 Hugging Face 格式的模型转换过来：

# 编译 llama.cpp
cd llama.cpp
make

# 转换模型
python3 convert-hf-to-gguf.py \
    ../DeepSeek-Coder-V2-Lite-Instruct \
    --outfile deepseek-coder-v2-lite-instruct-f16.gguf \
    --outtype f16

这一步会生成一个 FP16 的 GGUF 文件，先别急着量化，用它跑一个基准测试，方便后续对比质量。

  1. 量化为 INT4
./quantize \
    deepseek-coder-v2-lite-instruct-f16.gguf \
    deepseek-coder-v2-lite-instruct-q4_k_m.gguf \
    Q4_K_M

这里的 Q4_K_M 是量化策略：

  • Q4_K_M: 4 位，中等精度，质量和速度平衡
  • Q4_K_S: 4 位，更激进的压缩，质量略差
  • Q4_0 / Q4_1: 老式量化方法，一般不推荐

如果你希望质量更好，可以考虑 Q5_K_M 或 Q6_K，但显存占用会相应增加。

  1. 本地推理测试
./main -m deepseek-coder-v2-lite-instruct-q4_k_m.gguf \
    -n 512 \
    -p "Write a Python function to merge two sorted lists:" \
    --gpu-layers 35 \
    -ngl 35

参数说明：

  • -n 512: 最大生成长度 512 tokens
  • -p: 提示词
  • --gpu-layers 35: 35 层放到 GPU 上跑
  • -ngl: 与 --gpu-layers 相同（不同版本的写法）

踩坑记录

显存依然不够

量化后模型确实小了，但第一次跑的时候还是 OOM。

问题出在 --gpu-layers 设置上。我一开始贪心，想全部放 GPU 上，结果 7B 模型还要 KV cache，显存还是不够。

解决方法是手动调整：

# 先全部放 CPU 跑一次，看实际需求
./main -m deepseek-coder-v2-lite-instruct-q4_k_m.gguf \
    -p "test" \
    --gpu-layers 0

# 逐步增加 GPU 层数，直到刚好不爆显存
./main -m deepseek-coder-v2-lite-instruct-q4_k_m.gguf \
    -p "test" \
    --gpu-layers 20

# 找到平衡点
./main -m deepseek-coder-v2-lite-instruct-q4_k_m.gguf \
    -p "test" \
    --gpu-layers 35

最终发现 35 层是个平衡点，既能充分利用 GPU，又不会 OOM。

代码质量下降

量化后第一次测试代码生成，发现补全的逻辑明显变糙了：变量命名随意、边界条件处理不严、有时候还会瞎编不存在的 API。

排查后发现是量化策略选错了。一开始用的 Q4_K_S，这个模式更激进，压缩更大，但对代码模型这种"逻辑敏感"的任务不太友好。

换回 Q4_K_M 后质量明显回升，几乎和 FP16 差不多。

生成速度慢

解决了显存和质量问题后，发现生成速度还是有点慢，尤其是长代码补全的时候。

检查后发现，llama.cpp 默认的 n_threads 设置没有充分利用多核 CPU。7950X 是 16 核 32 线程，但默认只用了 8 线程。

调整参数：

./main -m deepseek-coder-v2-lite-instruct-q4_k_m.gguf \
    -p "Write a fast sorting algorithm in C:" \
    -n 512 \
    --gpu-layers 35 \
    -n_threads 32 \
    -t 32

速度提升了约 1.5 倍。

性能对比

量化前后的关键指标对比：

指标FP16INT4 (Q4_K_M)变化
模型大小26GB7.2GB-72%
显存占用26GB+8.5GB-67%
推理速度8.5 tokens/s18 tokens/s+112%
代码质量基准~95% 基准-5%

四个维度的对比一目了然：INT4 在模型体积和显存上砍掉了约七成，推理速度翻倍，代码质量只损失约 5%。

DeepSeek-Coder V2 Lite：FP16 与 INT4 (Q4_K_M) 量化在体积、显存、速度与质量上的对比

代码质量的评估方式是人工检查生成的 100 个代码片段，对比逻辑正确性、边界条件处理、API 使用准确度三个维度。INT4 在大部分场景下表现不错，只有少数复杂算法实现时会出现逻辑错误。

实际使用效果

跑了一个月本地开发，整体感受是这样：

优点：

  • 不用把代码扔到外网，安全得多
  • 推理速度比预期快，日常补全基本无感知
  • 显存占用大幅下降，还能跑点别的东西
  • 成本固定，没有按 token 计费的焦虑

缺点：

  • 复杂任务的质量还是比不上云端的高精度模型
  • 遇到生僻库时会瞎编，需要自己把关
  • 量化后的模型偶尔会出现奇怪的中英文夹杂

结论： 如果你只是需要一个本地代码助手，INT4 量化的 DeepSeek-Coder 完全够用。但如果你要靠它解决复杂的算法问题、生成生产级代码，还是老老实实上云端吧。

一些遗留问题

这次折腾留下几个没解决的小问题：

  1. INT8 还是 INT4？ INT8 质量更好，但显存占用翻倍。我试过一次，13B 模型还是会爆显存，后来就没再细调。如果后面上 24GB 显存，可能会重新考虑。

  2. AWQ 真的更好吗？ 理论上 AWQ 的激活感知量化质量更高，但当时社区支持还不完善，转换脚本经常报错。现在应该稳定多了，有空可以再试。

  3. 量化后的微调 有没有可能在 INT4 模型基础上做微调，把损失的质量补回来？理论上可以，但工程复杂度太高，暂时没折腾。

总结

量化不是万能的，但它确实让大模型从"实验室玩具"变成了"日常工具"。

如果你也在犹豫要不要本地跑模型，给几个实际建议：

  • 先想清楚你的场景：需要什么样的质量、能接受多大的损失
  • 从成熟的量化工具开始，别一开始就追最新技术
  • 显存是硬约束，但 CPU 和 RAM 可以兜底
  • 量化模型可以先用，不合适再换，反正成本低

技术这东西，有时候不需要最优解，只要"够用"就行。

最后更新于 2026-07-17

版权声明: 本文首发于 指尖魔法屋-AI DeepSeek：量化不够用了之后（https://blog.thinkmoon.cn/post/409-ai-deepseek-quantization-code-practice/） 转载或引用必须申明原指尖魔法屋来源及源地址！

相关阅读

根据标签、分类和主题为你挑选的相近文章

Harness Engineering 的介绍与编程实践
这篇文章从 AI 编程的真实工程场景出发，梳理 Harness Engineering 如何通过上下文、工具、沙盒、验证和人工闸门，让 Agent 从“会写代码”走向“能稳定交付”。
📁 技术实践
📅 2026-04-23