qwen3.8:27b vs qwen3.6:27b — Thinking 模式实测对比

测试环境：内网 AI 服务器（Ubuntu + AMD 7900 XTX 24G + ROCm 7.x + Ollama 0.32.13）
调用方式：OpenAI 兼容接口，max_tokens=6000，非流式
测试时间：2026-08-19

背景

qwen3.8:27b 默认 thinking = max，慢到令人发指（简单问题也要等 3-5 分钟）。给请求注入 reasoning_effort: medium 后明显改善。但有人还在用 qwen3.6:27b，于是做了一组公平对比。

测试设计

两道长链推理题，统一参数发送：

• 过桥题：四人过桥（1/2/5/10 分钟），求最短总时间及方案（经典优化题，答案 17 分钟）
• 逻辑题：5 人 5 题答对关系，求哪题答错人数最多（多约束推理，答案：第 1 题，B/C/E）

三组配置：

编号	模型	thinking 模式	说明
A	qwen3.8:27b	medium	服务端默认注入
B	qwen3.6:27b	medium	同等级，对比模型质量
C	qwen3.6:27b	default	不传 reasoning_effort，模型自然 thinking

结果

第一轮（max_tokens=3000）

配置	过桥题	正文输出	思考长度	耗时	正确？
A: 3.8+medium	推理得 17 分钟	119 字（截断）	3842 字	63s	正文被 max_tokens 截断
B: 3.6+medium	—	0 字	7867 字	100s	全部 token 被思考吃光
3.6+default	17 分钟	885 字	5856 字	85s	正确

3.6 + medium 直接坏掉：3000 token 全被 thinking 消耗，正文输出 0 字符。和 3.8 + max 的问题如出一辙。

第二轮（max_tokens=6000，只测两个可用配置）

配置	任务	耗时	正文	思考	Token	正确？
3.8+medium	过桥	61.8s	994 字	5831 字	2646	17 分钟
3.6+default	过桥	112.9s	1346 字	5897 字	3305	17 分钟
3.8+medium	逻辑	19.3s	564 字	413 字	777	第1题 BCE
3.6+default	逻辑	86.5s	634 字	5397 字	2532	第1题 BCE

汇总

指标	3.8 + medium	3.6 + default	倍率
总耗时	81.1s	199.4s	3.8 快 2.5x
总 token	3423	5837	3.8 省 1.7x
逻辑题思考长度	413 字	5397 字	3.8 少 13x
两题正确率	2/2	2/2	持平

分析

1. 速度：3.8 碾压

过桥题 62s vs 113s（快 1.8x），逻辑题 19s vs 87s（快 4.5x）。简单任务上差距最大——3.6 不管题目难易都重度思考，3.8 会自适应：难题 5831 字符思考，简单题仅 413 字符。

2. Token 效率：3.8 省三倍

3.8 总用 3423 token，3.6 用 5837。3.6 在逻辑题上花了 2532 token，其中 5397 字符是英文思考过程——对"统计答错人数"这种题来说严重过度推理。

3. 质量：打平

两道题两个模型都答对了。3.8 的过桥答案带了下界证明（数学严谨），3.6 的带了两种策略公式对比。都是好答案。

4. 3.6 + medium 不可用

这是最关键的发现：给 3.6 显式设 reasoning_effort=medium 会导致 thinking 吞掉全部 token 预算，正文输出为零。3.6 只能用 default（不加 effort 字段），但那样又慢又费 token。

结论

主力模型用 qwen3.8:27b + think=medium。

• 速度快 2.5 倍
• Token 省 1.7 倍
• 答题质量相同
• 3.8 会根据任务难度自适应思考量，3.6 不会
• 服务端注入 reasoning_effort: medium 是当前最优配置

如果还有客户端在用 qwen3.6:27b，改成 qwen3.8:27b 即可——速度翻倍，质量不变。

---

补充：Ollama 的 thinking 等级合法值为 low / medium / high / max / true / false。OpenAI 兼容端点的 reasoning_effort 会被自动映射为对应等级；客户端自带的值优先于服务端默认值。

[求助] 7900XTX + Qwen3.8:27b 本地工作流踩坑：Codex Memory 自动关闭 & Hermes 复杂任务中途截断

️ 硬件与软件环境

最近搭建了一套纯本地的 AI 编程/规划工作流，配置如下：

• GPU: AMD Radeon RX 7900 XTX (24GB VRAM)
• 推理后端: Ollama
• 模型: Qwen3.8:27b
• 前端/UI: ccswitch
• Agent 框架: Hermes / Codex

理想工作流

目前尝试采用 "Plan-Review-Execute" 的分阶段模式：

1. 构思阶段：使用 Codex 清洗需求、划分 Plan/Goal，生成 Markdown 计划文档。
2. 人工审核：反复修改 Plan 直到满意。
3. 执行阶段：切换至 Goal 模式，让 Agent 按计划逐步实施。

这套流程在理论上很完美，但在实际落地时遇到了两个非常搞心态的问题，希望能得到社区大佬的指点。

问题一：Codex 的 Memory 按钮频繁被自动关掉

在使用 Codex 进行 Plan 构思和多轮修改时，我发现 Memory 功能经常被自动禁用。

• 导致上下文丢失，Agent 忘记之前确认过的约束条件或已修改的计划细节。
• 每次都要手动重新开启，且不确定之前的记忆是否真的被持久化了。
• 疑问：这是 ccswitch 的 Bug，还是 Ollama/Qwen3.8 在特定 token 长度下触发了某种保护机制？有没有办法强制锁定 Memory 状态？

问题二：Hermes 执行复杂任务时"静默死亡"

当 Plan 审核通过，切换到 Hermes 进入 Goal 执行模式后，经常遇到以下情况：

• 任务执行到一半（有时是 30%，有时是 70%）突然自动终止。
• 没有任何报错信息，没有 crash log，UI 上显示正常结束。
• 除了浪费时间和电费，什么产出都没有，只能从头再来或手动接续。
• 疑问：这是否是 24GB 显存在长上下文执行时的 OOM 软崩溃？还是 Hermes 对 Qwen3.8:27b 的 stop token 解析有问题？或者是 ccswitch 的超时设置过短？

求助方向

1. 是否有同样使用 7900 XTX + Ollama + Qwen3.8 组合的朋友遇到过类似情况？
2. 针对 Codex Memory 自动关闭，有无配置层面的解决方案？
3. 针对 Hermes 中途截断，如何排查根因？（例如：如何开启详细日志、调整 num_ctx、或更换更稳定的 Agent 后端？）
4. 对于 "Plan → Review → Execute" 这种本地工作流，是否有更成熟的工具链推荐？

感谢各位！

一、硬件

• CPU: AMD Ryzen 5 7500F (6核12线程, 5.08GHz, AVX-512)
• GPU: AMD Radeon RX 7900 XTX (Navi 31, 24GB GDDR6) 蓝宝石 PULSE
• 内存: 24GB DDR5
• 存储: 1TB NVMe SSD 系统: Ubuntu 26.04 LTS, Kernel 7.0
• 网络: 有线网 + ZeroTier VPN (MTU 2800)

二、软件 推理引擎: llama.cpp (Vulkan 后端)

• GPU 驱动: Vulkan RADV (Mesa 26.0.3, Vulkan 1.4.335)
• 模型: Qwen3.6-27B-Q4_K_M (16GB, 273亿参数)
• 多模态: mmproj-Qwen3.6-27B-f16.gguf (885MB)

为什么选 Vulkan RADV 而不是 ROCm？ 系统自带 mesa-vulkan-drivers，零额外配置，编译时加 -DGGML_VULKAN=on 就行。对于推理来说性能足够，省去了 ROCm 的折腾。

三、启动参数
llama-server --host 0.0.0.0 --port 8080 -m Qwen3.6-27B-Q4_K_M.gguf --mmproj mmproj-Qwen3.6-27B-f16.gguf --no-mmproj-offload -ngl 999 -c 262144 -b 512 -ub 512 -fa auto -ctk q4_0 -ctv q4_0 --spec-type draft-mtp --spec-draft-n-max 2 --jinja --reasoning-preserve

参数说明： -ngl 999: 所有模型层 offload 到 GPU -c 262144: 上下文窗口 262K tokens -b 512 / -ub 512: 批处理大小 -fa auto: Flash Attention，减少显存占用 -ctk q4_0: Key Cache 4-bit 量化 -ctv q4_0: Value Cache 4-bit 量化 --spec-type draft-mtp: MTP 推测解码 (Multi-Token Prediction) --spec-draft-n-max 2: 每步推测 2 个 token --no-mmproj-offload: 视觉编码器放 CPU 省显存 --jinja: Jinja 模板，适配 Qwen 格式 --reasoning-preserve: 保留推理链标记

显存占用： 模型权重 ~16.0 GB + KV Cache ~2.5 GB + 引擎 ~1.5 GB + 系统 ~1.0 GB 实际使用 23.3 GB / 24.0 GB，剩余 0.7 GB

四、测速方式

• 测速题目：生成1000字解释TCP/IP协议 Prompt: 61 tokens，max_tokens: 2048，temperature: 0.7

测试分为两组：

• 非流式请求 — 端到端完整生成，读取 llama.cpp 内置 timings
• 流式请求 — 逐 token 记录时间戳，测量 TTFT 和生成间隔分布

数据来源：

• 推理速度取自 llama.cpp 内部计时（排除 HTTP/网络开销）
• 流式数据通过 Python 逐 chunk 解析 time.time() 差值
• 长上下文 prefill 数据来自 server log
• GPU 温度/显存从 sysfs hwmon 读取

网络测试：

• Loopback TCP 吞吐量测试（10MB 数据）
• Ping 网关延迟测试（10 次）
• 内存带宽测试（Python array 读写 256MB）

五、测速结果

• 【非流式请求 — 完整生成 2048 tokens】 （llama.cpp 内置计时） Prompt tokens: 61 Output tokens: 2048 输出字符数: 5419 总耗时: 31.16s
• Prompt 阶段: 478.7ms (127 tok/s) Generation 阶段: 28.23s (72.5 tok/s, 13.8ms/tok) 总生成速度: 65.7 tok/s 推测解码: 1718 个 draft 生成, 1188 个被接受 (69% 接受率)
• 【流式请求 — 完整生成 2044 tokens】 TTFT (首 token): 425ms 总耗时: 29.10s 总生成速度: 71.3 tok/s 平均间隔: 14.0ms/tok
• 【长上下文 Prefill — server log】 Prefill 速度: 842 tok/s (2560 tokens, 3.04秒) 835 tok/s (4096 tokens, 4.90秒) 809 tok/s (8192 tokens, 10.13秒)
• 【短测试 — server log】 短 Prefill: 63 tok/s (12 tokens, 冷启动) 短 Generation: 91 tok/s (30 tokens, 330ms) 短 TTFT: 190ms 短 MTP 接受率: 100% (19/19 accepted, mean len 2.90)
• 【GPU 状态】（测速完成后） 温度: Edge 68°C / Junction 74°C / Memory 82°C 显存: 23.3 GB / 24.0 GB
• 【网络测试】 Loopback TCP: 55.3 MB/s Ping 网关: 0.54ms 平均，0% 丢包（0.40-0.82ms） 内存写入带宽: 26.4 GB/s 内存读取带宽: 28.8 GB/s

六、总结

• 7900 XTX 24GB + Vulkan RADV + llama.cpp + Qwen3.6-27B：
• 完整生成 66 tok/s，流式输出 71 tok/s，14ms/tok 流畅度足够
• 长上下文 Prefill 840+ tok/s（2560+ tokens 批量）
• MTP 推测解码 69% 接受率，显著加速生成
• 24GB 显存占用 23.3GB（97%），模型权重全部 offload 到 GPU, 系统内存显示 ~15GB 占用为 mmap 映射，实际物理可用 ~7GB
• 性价比较高的本地大模型方案

目前测试发现的问题：图片识别吃力，耗时久，请问有人遇到过类似现象？如何解决？

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