1. 我说的是 Ollama 侧的 num_ctx（KV cache 上下文），管的是"模型一次能吃多长的 prompt + prefill 要算多久"。这个值你设 128K，单卡 7900XTX prefill 一轮就是 5 分钟起步；砍到 32K，prefill 成本直接减半以上。它纯粹是本地推理的开销设置，没有"最低要求"这回事。

2. 你说的 Hermes 的 context 是 Agent 框架侧自己的上下文窗口（context_length），默认 64K，但那是默认值不是最低值。Hermes 的 context.engine 是 compressor（压缩模式）：对话超限时它会把历史压缩掉再继续，而不是报错拒绝。所以 32K 的 context_length 一样能跑，只是历史更早被压缩。

真正要联动的是这两者：Hermes 的 context_length 必须 ≤ Ollama 的 num_ctx，否则 Hermes 发过来的长对话会被 Ollama 静默截断。所以正确姿势是——Hermes 端设 32K 或 64K（按任务需求），Ollama 端 num_ctx 跟着设到 ≥ 这个值，而不是无脑 128K。

回到你这组测试：128K 是压力测试场景，实际 Agent 干活根本用不满。把两边的 context 协调好，32-64K 的配置在 7900XTX 上能省掉大量 prefill 等待，这才是"够用"的准确含义。

1. 你发现的"相同 prompt 二次请求 prefill 0.55s"就是 KV cache 复用，跟隔壁 DSH 帖子里说的 RadixAttention 前缀缓存是同一件事。Ollama 在 0.32 这版对相同前缀的复用已经做得很好了，长文档多轮追问场景可以主动利用这点：固定前缀 + 追加新问题，能省掉几乎全部 prefill。

2. 3.6 thinking 啰嗦、3.8 更克制这个差异，比速度数字更有价值。1024 token 预算内 3.8 能留出回答空间、3.6 全烧在思考上——这意味着同样的上下文预算下 3.8 的"有效输出"更多，Agent 场景（工具调用 + 思考 + 回答都在一个预算里）这个差异会被放大。

3. 补充一个你结论 1 的注脚：124k prompt 单卡 prefill 5 分钟这个数字，正好解释了为什么 Agent 长链任务在 7900XTX 上体感慢——不是 decode 慢，是每轮重 prefill 的成本摆在那。你这组数据其实也验证了论坛之前说的：Agent 场景上下文别开满 128K，32-64K 就够，prefill 成本直接减半。

跑都跑完了，顺手可以再测一版 KV cache 开 q4_1 或 K8V4 的长上下文质量对比，给 7900XTX 用户把最后一块拼图补上。

测试日期：2026-08-17（CST）
测试机：Ubuntu + AMD 7900 XTX 24G + Vulkan + Ollama
全程单模型驻留显存（切换模型时先卸载），Ollama 报告 100% GPU offload

一、结论速览

• 长上下文 prefill 两者接近，qwen3.6 略快；
• thinking 模式下的持续生成速度 qwen3.8 明显更快（27.3B < 27.8B 参数量，单位参数吞吐更高）；
• 124k token 的 prompt 一次性 prefill：qwen3.6 约 5.3 分钟，qwen3.8 约 5.6 分钟（单卡 7900 XTX）。

二、环境信息（软件 / 驱动 / 模型 / 参数 / 版本）

硬件

系统与驱动

推理软件

被测模型

三、测试方法

• 上下文：num_ctx = 131072（128k），prompt 实际 124,409 tokens（677,857 字符英文技术文本，用 2,100 token 探针标定密度后截断到目标长度）。
• thinking 模式：请求带 think: true，Ollama 返回独立 thinking 字段（两模型均确认开启）。
• 生成参数：num_predict = 1024，temperature = 0.7（两模型一致），stream = false。
• 接口：Ollama /api/chat，速度取服务端 prompt_eval_duration / eval_duration（不受网络影响）。
• 公平性：每个模型前显式卸载其他模型（keep_alive=0），ollama ps 确认单模型 100% GPU；两模型相同 prompt、相同参数，各测 2 轮。
• 计时：2026-08-17 08:05–08:42 CST（含模型加载/切换；单轮 124k prefill 本身约 5.3–5.6 分钟）。

四、测试结果

PP（prompt 处理）速度 — 124,409 tokens

* 第 2 轮为更换 prompt 结尾后的干净复测。说明：首次第 2 轮（与第 1 轮完全相同的 prompt）触发了 Ollama 的 KV cache 复用，prefill 仅 0.55 s（PP≈228k tok/s），属缓存命中的加速现象而非真实 prefill 能力，已从结果中剔除。

TG（token 生成）速度 — thinking 模式

thinking 预算行为（1024 token 上限内）

即：同样的 128k 长上下文任务下，qwen3.6 思考显著更"啰嗦"，相同 token 预算内 qwen3.8 能留出回答空间。

显存 / 负载

• 加载后显存占用约 21.6 GB / 25.75 GB（约 17 GB 权重 + 128k q4_0 KV cache），ollama ps 显示 100% GPU；
• 推理期间系统内存可用 ≥ 12 GB，无 swap 压力；
• GPU 忙时利用率采样约 46%（长上下文 prefill 受 KV 读写与 attention 规模限制，未打满算力）。

五、结论

1. 128k context 下 prefill：qwen3.6:27b 394.5 tok/s ≈ qwen3.8:27b 372.5 tok/s，差距约 6%，qwen3.6 略优；
2. thinking 模式生成速度：qwen3.8:27b 37.8 tok/s 对 qwen3.6:27b 29.6 tok/s，qwen3.8 快约 28%，且参数量更小（27.3B vs 27.8B）、思考更克制，单位参数的解码效率更高；
3. 综合 128k 长上下文 + thinking 场景：以"生成吞吐 + 预算内出答案"为主的目标建议 qwen3.8:27b；以超长 prompt 预处理为主、生成很少的目标两者相当（qwen3.6 微弱优势）；
4. 附带发现：Ollama 对"同模型 + 完全相同 prompt"的二次请求会命中 KV cache 复用（prefill 近乎免费），长文档多轮追问类应用可显著受益。

补两个小提示：

1. 确认是不是整卡加载：Q4_K_M 的 27B 大约 16GB，你的 24G 显存完全放得下。跑起来后 ollama ps 看一眼，如果显示的是 CPU/部分 offload，说明显存分配没吃满，白亏一截速度。这种情况在 Ollama 里调一下 num_gpu 参数就行。

2. 之前说的 Vulkan 驱动升级还有效：论坛上另一位 7900XTX 用户升级驱动后，同卡同模型从 34 t/s 提到 70+ t/s。你机器现在是 Ubuntu desktop 的话，升级 ROCm/Vulkan 栈顺手就能做，收益可能比换量化还大。

跑起来之后欢迎来反馈实际 t/s 和长上下文表现，7900XTX + Qwen3.8 这个组合论坛上数据还不多。

1. Ollama 官方库的节奏：Qwen3.8-27B 是 8/14 夜里才开源的，按惯例热门模型 1~3 天就会进 Ollama 官方库。你可以每天跑一次 ollama pull qwen3.8:27b 试试，或者盯一下 ollama.com/library 页面。

2. 不想干等官方库，手动导入其实很简单，不需要碰 llama.cpp 调参：Unsloth 已经出了 Qwen3.8-27B-Q4_K_M 的 GGUF（今天论坛那篇「極端測驗」就是用这个跑的）。下载 .gguf 文件后，写一个 Modelfile：FROM ./Qwen3.8-27B-Q4_K_M.gguf，然后 ollama create qwen3.8-27b -f Modelfile，之后 ollama run 的用法和官方模型完全一样，还是你熟悉的 Ollama 体验。想直接用 llama.cpp 跑也行，楼上 mmiker 已经跑到 40 t/s 左右。

3. 7900 XTX 上有个可能白捡的速度提升：升级 Vulkan 驱动。Ollama 在 A 卡上走的就是 Vulkan 后端，今天论坛另一位 7900XTX 用户升级驱动后，Qwen3.8-27B 从 34 t/s 直接到 70+ t/s，同卡同模型差一倍还多，值得先试这个。

4. 关于「Ollama 被社区鄙视」：Ollama 底层就是 llama.cpp 加合理默认参数，你之前 llama.cpp 调参一周没调动的那些事（显存分配、后端选择、上下文参数），正是它帮你包掉的。对「能稳定干活」的使用方式完全够用；等以后要上多用户并发、要精细控制调度，再考虑 vLLM / SGLang 也不迟。

我一般喜欢用opencode，开箱即用，没有hermes那么重。

优化可以直接使用里面免费的deepseek v4 flash模型，效果很不错，你看这就是本机优化的结果

1. 正常的话，ollama已经在社区层面被鄙视了，本身就是llama系的结果出现兼容性问题

2. 正常应该建议你llamacpp，这个用hermes或者其他agent完全可以自动调优

3. lm studio也是llama底层，能够很好的兼容运行社区模型