部署到实际使用环境后，这次继续测试四个方面：框架功能与限制、Hermes Agent 实际运行、标准题集质量，以及不同思考档位的效果。最后再让模型交几份有趣的编程作业。

结论优先，跑了三天测试，没有出现死循环，未发现影响主要功能的严重 Bug，能用，够用，单卡7900XTX好用 ，我已经把自己单卡的生产环境换了这个推理框架。

一、Hipfire 框架与专属 MQ4-XTS 模型

1. 测试环境

Hipfire 是针对 AMD GPU 优化的推理框架。与常见的通用模型运行方案相比，其特色是专属 MQ4-XTS 模型格式、VMM 显存管理和 DFlash 推测解码。

这里测试的不是普通 GGUF Q4 文件，而是 Hipfire 框架与 MQ4-XTS 模型组合的整体表现。

2. 主要功能和实测情况

3. Prompt Cache

早期测试中，曾关注过 Hipfire 的前缀缓存能力。

后续生产环境验证确认，重复请求能够复用前缀 KV。在一次测试中：

这是一次特定测试的结果，不代表所有任务都能获得相同加速，也不意味着模型具备无限容量的历史 KV 存储。

4. 实际限制

KV 显存硬边界

当前单卡 24GB、MQ4-XTS、Q8 KV 配置下：

• 128K：通过
• 160K：通过
• 约 176K：OOM （Q8KV下24G显存有点捉襟见肘这是硬伤，但是实测Q4 KV会严重损失速度，只能Q8)

因此，较高的逻辑上下文配置不等于对应长度一定能够实际运行。这个边界是当前模型及显存配置的实测限制，而不是 Hipfire 框架通用的固定上限。

并发能力

已有吞吐成绩主要来自 C1 单并发、Cold Context 测试。多并发吞吐、延迟以及显存压力尚无充分验证。

量化格式与兼容性

MQ4-XTS 是这套框架的专属模型格式。普通 Q4/GGUF 量化和 MQ4-XTS 不能直接等同；此前其他四位量化路径的失败现象也不能据此归因于 MQ4-XTS。

二、部署生产环境：Hermes Agent 能不能真正干活？

完成性能测试后，将 Hipfire 27B 接入 Hermes，作为实际 Agent 的推理后端。

这部分没有停留在简单问答，而是测试文件读写、工具调用、调查分析、代码调试、多轮执行和视觉输入。

1. 基础功能验收

2. Coding / Debug

在预设问题的代码与配置调查中，模型成功定位三处缺陷。

一次 Medium 测试记录：

3. 多轮 Agent 工作流

一次完整任务的执行记录：

这一结果说明模型能够驱动 Hermes 完成多轮工具链任务，但单次成功不能等同于长期 Agent 可靠性统计。

4. 视觉能力

启用视觉组件并设置 vision_mode=auto 后：

三、模型质量：标准题集实测

本次使用五套标准题集，共 3,711 道题，考察数学、知识、科学推理及代码生成能力。测试使用本地固定题集和自定义评分脚本。

1. 题集及特点

2. 已完成成绩

测试方法说明：

• temperature = 0
• 原始输出上限 = 16,384 tokens
• GPQA/AIME 部分原始截断题选择性以 32,768 tokens 补测
• 历史全量运行缺少逐请求思考档位记录
• 使用本地题集及自定义评测脚本

因此，GPQA 和 AIME 表中的成绩含有混合输出预算，不应理解成全部题目在完全统一的 16K 上限下取得。

四、这个27B模型思考档位差别有多大？Off、Low、Medium

为了观察开启思考后的收益，又进行了两组独立测试。

1. 60 题综合推理专项

包括数学、知识、科学推理及部分代码生成题。五道代码生成题没有在这一组执行评分。

Off 到 Low 提升明显，Low 到 Medium 的正确率差距较小。

2. HumanEval 164 题完整测试

同一套 164 道编程题分别使用 Off、Low、Medium 生成，并用修正后的同一评分器执行。

Off 耗时来自服务恢复后保存完整计时记录的 143 题，正确率按完整 164 题统计。

逐题比较：

Low 比 Off 多通过 3 题，Medium 比 Low 再多通过 1 题。

Medium 的中位 completion tokens 比 Low 增加约 20%，中位耗时增加约 13%。

对于这组编程题，Low 显示出比较好的质量与耗时平衡。但独立函数生成不能代替长期 Agent 工程任务测试。

总体来看，模型质量符合一款 27B、约 4-bit 量化模型的正常预期水平。Hipfire 更突出的优势仍然是释放了7900XTX单卡推理性能并提高了实际运行效率。

五、实际案例：让 Hipfire 27B 画图、编程，做游戏

标准题集之外，还让模型生成一些可以直接在浏览器中查看和运行的作品。

这些测试更直观，也能暴露单纯选择题不容易发现的问题。

可视化 Agent 实战总结

最后使用 Hermes Agent，让 Hipfire 27B 完成四类可视化编程任务：模拟时钟、鹈鹕骑自行车、贪吃蛇游戏和动态太阳系。

每项分别请求 Off、Low、Medium 三档，共进行 12 项独立测试。

最终 12/12 项通过，成功率 100%。

这些作品均由 Hermes Agent 使用文件工具生成，并在离线 Chromium 中进行结构、视觉或功能验收。贪吃蛇的增长、计分、碰撞及重启逻辑通过测试；动态太阳系的行星运动、暂停、继续和速度调节同样通过。

需要说明，测试发送了不同的思考档位请求，但未获得实际生效档位的充分证明，因此不依据这 12 项结果判断 Off、Low、Medium 的真实性能差异。

这组结果主要说明：Hipfire 27B 已能够驱动 Hermes 完成具有一定复杂度的可视化开发任务，包括生成文件、调用工具和自主修复。

1. 鹈鹕骑自行车：SVG 与 HTML 动画

首先要求模型画一只骑自行车的鹈鹕。

静态 SVG 测试：

两个版本都具备基本的鹈鹕与自行车结构。Medium 版本增加了更完整的车架、车座、双踏板与背景元素。

以下插图从上到下分别是 思考模式 off，low，medium

随后要求模型生成动态 HTML 页面。

动画实现了车轮旋转、双腿踩踏板、车辆横向移动和鹈鹕身体轻微起伏。

Pelican on a Bicycle.html

2. SVG 模拟时钟：10:10:30

让 Hermes Agent 生成一个带 12 个数字、60 个刻度以及时分秒三根指针的模拟时钟。

三个版本均已完成渲染验收。验收标准包括刻度数量、数字位置与指针角度。

3. 贪吃蛇：从代码到可玩的游戏

接下来是经典的 Snake 游戏。

要求生成单文件 HTML，支持方向键控制、随机食物、蛇身增长、得分、碰撞判断和重新开始。

离线 Chromium 验收确认两个版本的游戏逻辑能够运行。

测试为可重复验证碰撞与计分，采用手动推进游戏步进的方法，不作为真实连续帧率测试。

snake_27b_off.html
snake_27b_low.html

4. 动态太阳系

最后一项要求生成动态太阳系页面，包含多个行星、不同轨道半径与运动速度，以及暂停和速度调节功能。

27B_Off_Solar_System.html
27B_Low_Solar_System.html
27B_Medium_Solar_System.html

注：搞笑啦，居然是思考off模式最好，图像好看，行星速度差值表现也靠谱的多。这道题上，开思考没带来更好的成品。

结语

从最初的 Prefill、Decode 性能测试，到生产环境部署、Hermes 工具调用、标准题集及实际编程作品，Hipfire 27B MQ4-XTS 在单张 RX 7900 XTX 上展现了相当完整的本地推理能力。

最有代表性的几个数字：

• 2682 t/s Prefill、169.4 t/s Decode：8K 上下文 DFlash 实测
• 160K：当前 Q8 KV 配置下的已验证长上下文长度 （据此我设的Hermes 192K 上下文， 75%压缩阈值。DSH则自用许多）
• 97.3% GSM8K、88.7% MMLU
• 93.3% / 95.1% / 95.7%：HumanEval Off / Low / Medium
• Hermes 工具调用、Coding/Debug、多轮任务和基础视觉均已通过验证

与此同时，长上下文显存边界、多并发能力、特定量化路径兼容性、服务异常及长期 Agent 稳定性仍存在明确的工程限制。

对 RX 7900 XTX 而言，Hipfire 的价值不只是某一个 Benchmark 数字，而是通过针对 gfx1100 的软件优化，让一张 24GB RDNA3 显卡在速度、模型质量和实际应用之间取得了新的平衡。