【求助/讨论】7900 XTX 24G + Ollama 用户蹲一个 Qwen3.8-27B，大家有消息吗？

[Fan Rex]

【求助/讨论】7900 XTX 24G + Ollama 用户蹲一个 Qwen3.8-27B，大家有消息吗？

各位大佬好，
本人目前主力本地推理配置是 AMD 7900 XTX 24G，日常通过 Ollama 跑模型。最近一直在用 qwen3.6:27b，整体体验还不错，24G 显存跑 Q4_K_M 量化版刚好能塞进去，Vulkan 后端下推理速度也基本够用。

看到 Qwen3.8 系列已经官宣开源了，心里比较痒痒。想请教一下社区里有用Ollama 的朋友：

1. Ollama 官方库大概什么时候能上架 Qwen3.8-27B 的量化版本？ 按照以往经验，新模型开源后 Ollama 跟进通常需要多久？
2. 有没有大佬已经通过手动转换 GGUF 的方式在 7900 XTX 上跑通了 3.8-27B？ 如果有的话，能否分享一下转换参数或踩坑经验？
3. 相比 3.6-27B，3.8 在同尺寸下的推理性能/显存占用有没有明显变化？
   提前感谢各位指点！如果有进展我也会回来同步反馈，给后续用 A卡的兄弟们探探路。

---

当前环境参考

• GPU: AMD Radeon RX 7900 XTX 24G
• 推理框架: Ollama (latest)
• 当前模型: qwen3.6:27b (Q4_K_M)
• 后端: Vulkan
• OS: Ubuntu Desktop
• Context: 128 KB

#Qwen3.8 #Ollama #7900XTX #AMD #本地大模型 #GGUF

[ezios]

换lm studio吧

[mmiker]

llama.cpp 可以跑GGUF ，我目前能跑40t/s左右。还在研究参数。

[Fan Rex]

@ezios 为什么？

[Fan Rex]

@mmiker 用过lamma.cpp， 调参搞不定，调参调了一周，显卡一直“内耗” -- 只耗电，不做功，一个任务跑十几个小时，最后只能关掉任务。换了Ollama，后来就能正常干活，提供生产力。

[ezios]

@Fan-Rex

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

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

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

[ezios]

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

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

[Fan Rex]

@ezios lm studio现在支持qwen3.8:27b的量化版本了么？

[ezios]

支持，只要huggingface上有了，他就能跑：

[Xiaote]

@Fan-Rex 几个点帮你把信息补全：

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 也不迟。

[Fan Rex]

感谢大家，昨天晚上开始升级AI SERVER ubuntu desktop的OLLAMA + QWEN3.8:27B， ollama pull qwen3.8:27b 现在已经可用了

[Xiaote]

恭喜跑通！ollama pull 能直接拉到就说明官方库已经收录了，比我预想的还快。

补两个小提示：

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 这个组合论坛上数据还不多。

[Fan Rex]

此主題已被删除！

[Fan Rex]

qwen3.6:27b vs qwen3.8:27b 速度对比测试（128k context + thinking 模式）

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

一、结论速览

指标（128k context + thinking）	qwen3.6:27b	qwen3.8:27b	差异
PP（prefill）速度	394.5 tok/s	372.5 tok/s	qwen3.6 快约 5.9%
TG（生成）速度	29.6 tok/s	37.8 tok/s	qwen3.8 快约 27.6%

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

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

硬件

项目	型号 / 版本
CPU	AMD Ryzen 5 7500F，6 核 12 线程，最高 5077 MHz
内存	22 GiB DDR5 + 15 GiB swap
GPU	AMD Radeon RX 7900 XTX（Navi 31，cyan_skillfish），24 GB
显存	25.75 GB 可见（vram_total），测试时占用约 21.6 GB
硬盘	NVMe（840 GB）

系统与驱动

项目	版本
OS	Ubuntu 26.04 LTS（Resolute Raccoon）
内核	7.0.0-1009-oem（PREEMPT_DYNAMIC）
amdgpu 驱动	内核内置 amdgpu（随内核 7.0.0-1009-oem），firmware: cyan_skillfish
Vulkan 用户态	Mesa RADV（mesa-vulkan-drivers 26.0.3-1ubuntu1）
Vulkan Loader / API	1.4.341 / 1.4.335

推理软件

项目	值
Ollama	0.32.13（systemd 服务 ollama.service）
后端	Vulkan（OLLAMA_VULKAN=1、OLLAMA_LLM_LIBRARY=vulkan）
Flash Attention	开启（OLLAMA_FLASH_ATTENTION=1）
KV Cache 量化	q4_0（OLLAMA_KV_CACHE_TYPE=q4_0）——128k KV 因此能塞进 24G 显存
默认上下文	131072（OLLAMA_CONTEXT_LENGTH=131072）
并发	OLLAMA_NUM_PARALLEL=1、OLLAMA_MAX_LOADED_MODELS=2、OLLAMA_MAX_QUEUE=4
监听	127.0.0.1:11434

被测模型

项目	qwen3.6:27b	qwen3.8:27b
架构	qwen35	qwen35
参数量	27.8 B	27.3 B
量化	Q4_K_M（约 17 GB）	Q4_K_M（约 17 GB）
支持上下文	262144	262144
能力	completion / vision / tools / thinking	completion / vision / tools / thinking
附加	—	CLIP projector 460.73 M（视觉）
模型默认采样	temp=1, top_k=20, top_p=0.95, presence_penalty=1.5	temp=1, top_k=20, top_p=0.95, presence_penalty=0

三、测试方法

• 上下文：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

模型	第 1 轮	第 2 轮	平均
qwen3.6:27b	394.55 tok/s（315.3 s）	394.50 tok/s（315.4 s）	394.5 tok/s
qwen3.8:27b	373.62 tok/s（333.0 s）	371.37 tok/s（335.0 s）*	372.5 tok/s

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

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

模型	第 1 轮	第 2 轮	平均
qwen3.6:27b	29.63 tok/s（1024 tok，34.6 s）	29.66 tok/s（1024 tok，34.5 s）	29.6 tok/s
qwen3.8:27b	37.59 tok/s（591 tok，15.7 s）	38.02 tok/s（783 tok，20.6 s）	37.8 tok/s

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

模型	thinking 长度	最终回答
qwen3.6:27b	~4.6–4.7k 字符（两轮）	无——1024 token 全部被 thinking 消耗（回答被截断）
qwen3.8:27b	~1.0–2.3k 字符（两轮）	有——thinking + 完整回答均在预算内完成

即：同样的 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 近乎免费），长文档多轮追问类应用可显著受益。

[Xiaote]

@Fan-Rex 这组数据正是这楼缺的——7900XTX 24G + Qwen3.8-27B 的 128k 长上下文实测，感谢把环境、方法、原始数字都贴全了。几个点补充一下：

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 用户把最后一块拼图补上。

[Fan Rex]

@Xiaote 32K Context估计不够哦，因为Hermes Agent最低context要求就是64K了;

[Xiaote]

@Fan-Rex 这里有个概念要拆开，你说的"64K 最低要求"和我说"32-64K 就够"，其实讲的是两个不同的 context，不冲突：

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 等待，这才是"够用"的准确含义。