F
硬件：Ubuntu Desktop + AMD 7900XTX 24G + ROCm + Ollama + Qwen3.8:27b Dense
单任务没有问题。主要场景：
多任务时会出现：
例子：
期望：有 FIFO 队列机制，睡前丢多个 Goal 进去，睡醒直接看结果。
请问有什么解决方案？
测试环境：内网 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，于是做了一组公平对比。
两道长链推理题，统一参数发送：
三组配置：
| 编号 | 模型 | thinking 模式 | 说明 |
|---|---|---|---|
| A | qwen3.8:27b | medium | 服务端默认注入 |
| B | qwen3.6:27b | medium | 同等级，对比模型质量 |
| C | qwen3.6:27b | default | 不传 reasoning_effort，模型自然 thinking |
| 配置 | 过桥题 | 正文输出 | 思考长度 | 耗时 | 正确？ |
|---|---|---|---|---|---|
| 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 的问题如出一辙。
| 配置 | 任务 | 耗时 | 正文 | 思考 | 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 | 持平 |
过桥题 62s vs 113s（快 1.8x），逻辑题 19s vs 87s（快 4.5x）。简单任务上差距最大——3.6 不管题目难易都重度思考，3.8 会自适应：难题 5831 字符思考，简单题仅 413 字符。
3.8 总用 3423 token，3.6 用 5837。3.6 在逻辑题上花了 2532 token，其中 5397 字符是英文思考过程——对"统计答错人数"这种题来说严重过度推理。
两道题两个模型都答对了。3.8 的过桥答案带了下界证明（数学严谨），3.6 的带了两种策略公式对比。都是好答案。
这是最关键的发现：给 3.6 显式设 reasoning_effort=medium 会导致 thinking 吞掉全部 token 预算，正文输出为零。3.6 只能用 default（不加 effort 字段），但那样又慢又费 token。
主力模型用
qwen3.8:27b+think=medium。
reasoning_effort: medium 是当前最优配置如果还有客户端在用 qwen3.6:27b，改成 qwen3.8:27b 即可——速度翻倍，质量不变。
补充：Ollama 的 thinking 等级合法值为 low / medium / high / max / true / false。OpenAI 兼容端点的 reasoning_effort 会被自动映射为对应等级；客户端自带的值优先于服务端默认值。
今天做同一个任务，分别用两个模型跑了一下：
任务内容：更新Github Repo readme.md，要求架构图、数据流图、类图、流程图各一张（Mermaid），正文中文、图中英文
| 模型 | 结果 |
|---|---|
| Qwen3.8:27b |  ️ 跑了 ~25min，没出结果（后被我停止） |
| Qwen3.6:27b |  13min 完成 |
两个模型参数量都是 27B，差距挺明显的。3.8 在复杂文档生成 + Mermaid 多图表这种任务上似乎不太稳，偶尔“空转/内耗”，3.6 反而更靠谱。
两天用下来总体感受
1 复杂长链路，3.8逻辑会逻辑链路断裂，导致"内耗" -- 只费电，不做功
2 速度方面3.6明显更快，不是pp/token generation测试速度，而是总体任务速度，同一个任务，同样的输入，3.6快100%甚至更多。
3 复杂图像识别方面，3.8好很多。 “3.6 + 路由 + 3B的小图像识别模型”也可以解决问题，结果几乎一致
4 有人说3.8代码能力强，可是代码能力基于逻辑能力，逻辑都不理解，代码能力从何谈起？ 问题都找不到，怎么改？
总体来说：local 3.8 qwen 实用性表示怀疑。
群里有没有跑过类似对比的？大家感觉 3.8 相对 3.6 的提升在哪类任务上比较明显？欢迎点评、讨论
️ 硬件与软件环境最近搭建了一套纯本地的 AI 编程/规划工作流，配置如下：
理想工作流目前尝试采用 "Plan-Review-Execute" 的分阶段模式：
这套流程在理论上很完美，但在实际落地时遇到了两个非常搞心态的问题，希望能得到社区大佬的指点。
问题一：Codex 的 Memory 按钮频繁被自动关掉在使用 Codex 进行 Plan 构思和多轮修改时，我发现 Memory 功能经常被自动禁用。
问题二：Hermes 执行复杂任务时"静默死亡"当 Plan 审核通过，切换到 Hermes 进入 Goal 执行模式后，经常遇到以下情况：
求助方向num_ctx、或更换更稳定的 Agent 后端？）感谢各位！
测试日期：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% |
| 项目 | 型号 / 版本 |
|---|---|
| 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 探针标定密度后截断到目标长度）。think: true，Ollama 返回独立 thinking 字段（两模型均确认开启）。num_predict = 1024，temperature = 0.7（两模型一致），stream = false。/api/chat，速度取服务端 prompt_eval_duration / eval_duration（不受网络影响）。keep_alive=0），ollama ps 确认单模型 100% GPU；两模型相同 prompt、相同参数，各测 2 轮。| 模型 | 第 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 能力，已从结果中剔除。
| 模型 | 第 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 长度 | 最终回答 |
|---|---|---|
| qwen3.6:27b | ~4.6–4.7k 字符（两轮） | 无——1024 token 全部被 thinking 消耗（回答被截断） |
| qwen3.8:27b | ~1.0–2.3k 字符（两轮） | 有——thinking + 完整回答均在预算内完成 |
即：同样的 128k 长上下文任务下，qwen3.6 思考显著更"啰嗦"，相同 token 预算内 qwen3.8 能留出回答空间。
ollama ps 显示 100% GPU；各位大佬好，
本人目前主力本地推理配置是 AMD 7900 XTX 24G，日常通过 Ollama 跑模型。最近一直在用 qwen3.6:27b，整体体验还不错，24G 显存跑 Q4_K_M 量化版刚好能塞进去，Vulkan 后端下推理速度也基本够用。
看到 Qwen3.8 系列已经官宣开源了，心里比较痒痒。想请教一下社区里有用Ollama 的朋友：
当前环境参考
- 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
另请教：qwen3.6:27B 默认开启thinking，这会导致使用体验降低，因为thinking过程中，Hermes/codex界面几分钟或者几十分钟无输出，用户以为卡死了;
举例：C盘满了，我让Local LLM清理磁盘垃圾，他花了2个小时，垃圾一个也没少，除了费电，我不知道它在干什么。
为了解决这个问题，有两个方案：
1 牺牲部分回复质量，关闭thinking模式;
2 想办法让thinking的过程也显示在Agent中，改善体验，并不改善执行速度;
请问大家一半怎么选？
我的个人感受：本地LLM 的智商天然跟云端没有可比性，对于本地模型，thinking 不 thinking 没明显的区别。 大家的看法呢？
一、硬件
二、软件 推理引擎: llama.cpp (Vulkan 后端)
为什么选 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
四、测速方式
测试分为两组：
数据来源：
网络测试：
五、测速结果
六、总结