企业官网建设流程全解析

Hermes Agent 量化部署：3 个开关把推理延迟砍半

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

在 Hermes Agent 里挂本地模型，fp16 一加载就能跑，但单轮回复 800ms 起步、显存也吃满。做量化部署加推理加速后，A10 上单轮延迟从 850ms 降到 430ms，显存从 17GB 降到 9.5GB。下面这条路径可以直接照抄。

动手前先看你的环境

只做向量检索侧量化（Qdrant 分支）的话，GPU 可以完全不要，这条路径照样成立。

按路径走：配置 → 验证 → 调优

第一步：先跑通 fp16 基线，别急着量化

没有基线，后面的"加速"就只是感觉，不是数据。

1. 用原始精度把模型拉起来：

vllm serve meta-llama/Llama-3.1-8B-Instruct \ --tensor-parallel-size 1 \ --max-model-len 8192

2. 确认服务活着，记下基线：

curl -s localhost:8000/v1/models # 应返回 Llama-3.1-8B-Instruct

预期输出：启动日志出现Uvicorn running，/v1/models返回模型名；此时手动发几条请求，把单轮延迟记下来（本文基线为 A10 实测约 850ms）。

如果这一步卡住了

Connection refused一般是两种情况：模型还在加载（等启动日志走完再试），或者端口不是默认的 8000。

第二步：按显存压力挑量化方案

如果你的场景是 A，选方案 1；如果是 B 或 C，往下走。

• A. 显存偏紧、精度优先：权重上 fp8，只加一个参数

vllm serve meta-llama/Llama-3.1-8B-Instruct \ --quantization fp8 \ --max-model-len 8192

• B. 显存实在不够（比如 16G 想跑 13B）：换 int4 量化 checkpoint（AWQ / GPTQ 均可），vLLM 会自动识别，不要手动指定--quantization
• C. RAG 链路里向量库爆内存：Qdrant 侧开标量量化

quantization_config = ScalarQuantization( type="scalar", quantile=0.99, always_ram=True ) search_params = {"quantization": {"rescore": True}} # 重评分，防止召回漂移

• D. 手里有剪枝过的模型：直接指到剪枝 checkpoint 即可，剪枝和量化是正交的，可以叠加用

验证：vLLM 启动日志里应看到 fp8 权重加载；nvidia-smi显存占用从约 17GB 降到 9.5GB 左右（A10 实测）。

如果这一步卡住了

现象：日志显示量化已加载，但显存几乎没降

原因是 KV cache 没量化，长上下文把省下来的显存又吃回去了。在同一条启动命令上加--kv-cache-dtype fp8，显存大约再降一档，精度损失基本可忽略。

另一种高频错误：给 int4 checkpoint 手动加--quantization fp8，结果要么报错要么输出乱码。int4 checkpoint 就让它自动识别，别抢着指定。

第三步：把 Hermes Agent 指到新端点，验证整条链路

1. 切换模型：

hermes model

选 custom endpoint，base_url 填http://localhost:8000/v1。

2. 验证链路：

hermes doctor

预期输出：doctor 的端点检查全绿；然后在真实会话里跑几轮对话，/usage能正常统计 token，没有缓存失效告警。

桌面端里模型切换和会话管理都在这个界面完成，端点配置和 CLI 完全一致。

如果这一步卡住了

现象：单轮正常，多轮后开始乱码或空回复

两个常见原因：int4 模型 + 长上下文导致 KV cache 溢出，或量化后工具调用的 JSON 解析变脆。先用 fp8 跑同一批请求做二分——fp8 恢复就是量化损失问题，工具调用密集的任务就别硬上 int4。

压测与调参：别只看"能跑"

链路通了不等于达标，先跑一轮 200 条批量请求，对比 P50 / P99：

vllm bench serve --model meta-llama/Llama-3.1-8B-Instruct \ --num-prompts 200 --max-concurrency 16

三个可调参数，各自影响不同指标：

A10 实测参考值：200 条请求下 P50 延迟 850ms → 430ms，吞吐 18 → 41 tokens/s，P99 从 1.9s 降到 1.1s。如果 P99 降得比 P50 少，先查--max-model-len是不是太小导致截断重试。

踩坑记录 ⚠️

坑 1

现象：显存明明降了，但 Hermes 里测的延迟和之前一样

原因：起了两个 vLLM 实例，base_url 还指向旧的 fp16 服务，新端点根本没被访问。解法：hermes doctor核对实际端点，curl确认返回的模型名，再杀旧进程。

坑 2

现象：单条测试都对，上线后同一问题答案"翻转"了

这就是"翻转率"问题——量化的微小扰动在推理链上会被放大。解法：别拿单条 case 判断，准备 50 题的固定评测集，翻转率控制在 5% 以内再上线，超了就从 int4 退到 fp8。

坑 3

现象：Qdrant 开标量量化后，检索召回掉了 10% 以上

原因：量化检索本身有误差，没开重评分。解法：把search_params里的rescore打开（同第二步 C 分支的配置块）；召回恢复后如果还想压内存，再动quantile。

想查更细的配置字段和版本兼容性，看仓库 README.md 里 Documentation 一节的完整配置文档；有报错先去 Issues 搜一轮，社区入口在 README 的 Community 小节。

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