企业官网建设流程全解析

Hermes Agent 模型量化部署：3 步把 70B 模型塞进 24GB 显卡

【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent

手头只有一张 24GB 显卡，却想跑 70B 参数的模型？Hermes Agent 把量化与剪枝做成了内置能力：模型体积压掉大半，推理速度反而提升 40% 以上。这篇文章帮你回答三件事——你的机器能跑什么、怎么起步、哪里容易翻车。

量化和剪枝，到底动了模型哪部分

打个比方：量化就像给照片调低画质再压成小文件，细节少了，但一眼还能认出画面。具体说，它是把权重从 16 位浮点降到 4 位甚至更低的整数存储，体积和计算量同步缩水。剪枝则是把网络里几乎不起作用的连接整个剪掉，剩下的骨干继续干活。

为什么压了还能用？因为大模型天生冗余，权重里很多精度属于"存着也没人用"。把冗余部分省掉，输出质量通常只掉零点几个百分点——这就是你拿 24GB 显卡跑大模型的全部底气。

先认设备，再选量化方案

别一上来就研究 FP8 这种高级货。先量量自家显存，对号入座：

两个名字先记一下：GGUF 是 llama.cpp 生态的文件格式，常见档位 Q8_0 到 Q3_K_M，体积从约 7GB 压到 3GB 出头，困惑度损失从 0.03% 到 6% 不等；AWQ 和 GPTQ 是 vLLM 生产环境常用的 4-bit 方案，压缩率约 75%。拿不准时，默认选 Q4_K_M，它是各档位里平衡得最好的一个。

从 0 到跑起来的 3 步

第 1 步，选档位。用hermes model查看当前设备支持的模型与档位，按上面表格定下方案。日常对话用 Q4_K_M 就够了；对精度敏感的场景升到 Q5_K_M，困惑度损失从 1.68% 收窄到 0.39%。

第 2 步，改配置。两条关键项：长系统提示 + few-shot 示例的场景，把前缀缓存打开，重复提示词的 KV 计算直接复用；高并发场景调大并发上限并确认连续批处理开启，请求可以中途插入，GPU 不空转。

# vLLM 引擎：AWQ 量化 + 前缀缓存 vllm serve MODEL --quantization awq --enable-prefix-caching # llama.cpp 生态：下载对应档位 GGUF 后本地加载 llama-cli -m model-Q4_K_M.gguf -c 8192

第 3 步，测效果。跑一轮基准测试，记下吞吐、延迟和显存占用三个数，再拿一小批固定问题对比一下回答质量。数据不达标就别急着上线，先回去调第 2 步的配置。

三个容易踩的坑

输出开始胡言乱语？大概率是量化压得太狠，或者校准数据太少。回到 Q4_K_M，再不行就升 Q5_K_M；如果用的是 imatrix 流程，喂一批和真实场景贴近的数据重新校准，别拿网上随便抓的语料凑数。

速度没提升多少？先别怪量化。小模型单路推理的瓶颈通常在内存带宽而不是算力，试试把--max-num-seqs调大、确认连续批处理真的生效了。吞吐翻几倍，往往靠的是把 GPU 喂满，而不是压权重。

显存还是不够？只压了权重、没管 KV 缓存，这是最常见的 OOM 来源。70B 级别的模型，KV 缓存能占到 160GB，把 vLLM 的 PagedAttention 用起来可以砍掉一半左右；再加一点 CPU swap 空间兜底，基本就稳了。

怎么确认优化真的生效

上线后盯四个数字，基本不踩雷：

• 前缀缓存命中率：70% 以上说明重复提示词在复用，低于这个数先检查系统提示是不是每次都在变；
• GPU 利用率：85% 以上说明连续批处理没白开；
• 请求延迟 P95：200ms 以内，用户侧才有体感；
• 吞吐基线：对比优化前的吞吐，连续批处理正常工作时约有 4 倍差距，差距太小说明配置没生效。

先跑起来，再谈极致

从 Q4_K_M 档位起步，用评测数据决定要不要降档，比任何玄学调参都靠谱。想往下深挖，可以从 skills/mlops/inference/llama-cpp/ 看 GGUF 量化档位背后的原理，再看 skills/mlops/inference/vllm/ 的生产级优化文档；动手前用 skills/mlops/evaluation/lm-evaluation-harness 建一条精度基线，量化到底掉了多少，心里就有数了。

【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent