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。下面这条路径可以直接照抄。动手前先看你的环境项目最低要求影响什么GPU单卡 ≥16GBA10 / 3090 / 4090fp8 量化模型 KV cache 能不能装下驱动与 CUDACUDA 12.1驱动 530fp8 权重和 KV cache 都需要新栈vLLM0.6.x 以上量化参数、kv-cache-dtype 透传Hermes Agent0.16.0 以上hermes model端点配置、/usage统计Python3.11Hermes 运行时依赖只做向量检索侧量化Qdrant 分支的话GPU 可以完全不要这条路径照样成立。按路径走配置 → 验证 → 调优第一步先跑通 fp16 基线别急着量化没有基线后面的加速就只是感觉不是数据。用原始精度把模型拉起来vllm serve meta-llama/Llama-3.1-8B-Instruct \ --tensor-parallel-size 1 \ --max-model-len 8192确认服务活着记下基线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 8192B. 显存实在不够比如 16G 想跑 13B换 int4 量化 checkpointAWQ / GPTQ 均可vLLM 会自动识别不要手动指定--quantizationC. RAG 链路里向量库爆内存Qdrant 侧开标量量化quantization_config ScalarQuantization( typescalar, quantile0.99, always_ramTrue ) 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 指到新端点验证整条链路切换模型hermes model选 custom endpointbase_url 填http://localhost:8000/v1。验证链路hermes doctor预期输出doctor 的端点检查全绿然后在真实会话里跑几轮对话/usage能正常统计 token没有缓存失效告警。桌面端里模型切换和会话管理都在这个界面完成端点配置和 CLI 完全一致。如果这一步卡住了现象单轮正常多轮后开始乱码或空回复两个常见原因int4 模型 长上下文导致 KV cache 溢出或量化后工具调用的 JSON 解析变脆。先用 fp8 跑同一批请求做二分——fp8 恢复就是量化损失问题工具调用密集的任务就别硬上 int4。压测与调参别只看能跑链路通了不等于达标先跑一轮 200 条批量请求对比 P50 / P99vllm bench serve --model meta-llama/Llama-3.1-8B-Instruct \ --num-prompts 200 --max-concurrency 16三个可调参数各自影响不同指标参数影响什么推荐起始值--max-model-len长会话成功率 ↔ KV 显存先 8192显存稳了再提 16384--kv-cache-dtypeKV cache 显存占用fp8显存约减半精度损失可忽略quantileQdrant 标量量化向量召回率 ↔ 内存0.99仍紧张再降到 0.95A10 实测参考值200 条请求下 P50 延迟 850ms → 430ms吞吐 18 → 41 tokens/sP99 从 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
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。下面这条路径可以直接照抄。动手前先看你的环境项目最低要求影响什么GPU单卡 ≥16GBA10 / 3090 / 4090fp8 量化模型 KV cache 能不能装下驱动与 CUDACUDA 12.1驱动 530fp8 权重和 KV cache 都需要新栈vLLM0.6.x 以上量化参数、kv-cache-dtype 透传Hermes Agent0.16.0 以上hermes model端点配置、/usage统计Python3.11Hermes 运行时依赖只做向量检索侧量化Qdrant 分支的话GPU 可以完全不要这条路径照样成立。按路径走配置 → 验证 → 调优第一步先跑通 fp16 基线别急着量化没有基线后面的加速就只是感觉不是数据。用原始精度把模型拉起来vllm serve meta-llama/Llama-3.1-8B-Instruct \ --tensor-parallel-size 1 \ --max-model-len 8192确认服务活着记下基线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 8192B. 显存实在不够比如 16G 想跑 13B换 int4 量化 checkpointAWQ / GPTQ 均可vLLM 会自动识别不要手动指定--quantizationC. RAG 链路里向量库爆内存Qdrant 侧开标量量化quantization_config ScalarQuantization( typescalar, quantile0.99, always_ramTrue ) 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 指到新端点验证整条链路切换模型hermes model选 custom endpointbase_url 填http://localhost:8000/v1。验证链路hermes doctor预期输出doctor 的端点检查全绿然后在真实会话里跑几轮对话/usage能正常统计 token没有缓存失效告警。桌面端里模型切换和会话管理都在这个界面完成端点配置和 CLI 完全一致。如果这一步卡住了现象单轮正常多轮后开始乱码或空回复两个常见原因int4 模型 长上下文导致 KV cache 溢出或量化后工具调用的 JSON 解析变脆。先用 fp8 跑同一批请求做二分——fp8 恢复就是量化损失问题工具调用密集的任务就别硬上 int4。压测与调参别只看能跑链路通了不等于达标先跑一轮 200 条批量请求对比 P50 / P99vllm bench serve --model meta-llama/Llama-3.1-8B-Instruct \ --num-prompts 200 --max-concurrency 16三个可调参数各自影响不同指标参数影响什么推荐起始值--max-model-len长会话成功率 ↔ KV 显存先 8192显存稳了再提 16384--kv-cache-dtypeKV cache 显存占用fp8显存约减半精度损失可忽略quantileQdrant 标量量化向量召回率 ↔ 内存0.99仍紧张再降到 0.95A10 实测参考值200 条请求下 P50 延迟 850ms → 430ms吞吐 18 → 41 tokens/sP99 从 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
