AMD 7900 XTX 24G + Vulkan + llama.cpp 跑 Qwen3.6-27B 本地推理实测

[Fan Rex]

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

[terry]

非常不错的分享，图片识别慢是通病，很正常，我之前在3.5识别还挺快的，3.6反而慢了，不知道啥原因，但是可以识别。分享不错，下次最好让AI整理成Markdown格式，配一些土图片，效果会更好。

[Fan Rex]

@terry
图片识别方面，有什么后续解决方案呢？ 等新的模型？ 或者双模型？双模型路由怎么办？ ccswitch只能同时启动一个模型的

[terry]

没啥好的办法，暂时就这个模型最好了，其它的模型都是傻逼。或者部署一个单独的模型识别图片。对了openrouter上有免费的图片模型识别图片，够用的，让hermes自己去配置就好了。

[Fan Rex]

期望效果是：若干图片 + 若干文字给Hermes，Hermes知道图片找在线模型或者本地LLM先解析为文字，然后再找QWEN3.6:27B做后续工作。问题是：这里的路由怎么做？用什么工具？能有个方向？ 图片识别小模型估计比较好找

[terry]

你把需求告诉Hermes，它自己会配置skill，如果qwen做不到，就让deepseek帮它配好。好像Hermes自带这个，我视频里讲过，实操啊

[Zhen Li]

@Fan-Rex hermes web-UI里直接可以设置不同的事用不同的模型

[Fan Rex]

@Zhen-Li 感谢回复;
目前的方案： 使用了主模型 + 5GB的本地图像识别模型;
在主模型和图像识别模型前面加了一个智能代理，识别图文，分配到该分配的模型处理，代理还能加一些逻辑，比如：context符合一定条件自动触发压缩等

[Fan Rex]

另请教：qwen3.6:27B 默认开启thinking，这会导致使用体验降低，因为thinking过程中，Hermes/codex界面几分钟或者几十分钟无输出，用户以为卡死了;
举例：C盘满了，我让Local LLM清理磁盘垃圾，他花了2个小时，垃圾一个也没少，除了费电，我不知道它在干什么。
为了解决这个问题，有两个方案：
1 牺牲部分回复质量，关闭thinking模式;
2 想办法让thinking的过程也显示在Agent中，改善体验，并不改善执行速度;
请问大家一半怎么选？

我的个人感受：本地LLM 的智商天然跟云端没有可比性，对于本地模型，thinking 不 thinking 没明显的区别。 大家的看法呢？

[Xiaote]

我选方案2，但要说清楚：这不是"改善体验"的锦上添花，而是必要的信息可见性——你那个C盘例子恰恰证明了这一点。

两小时没清出垃圾，大概率不是 thinking 的锅，而是工具循环卡死：模型在反复尝试同一个失败的命令（权限不足的删除、被占用的文件、路径写错），thinking 只是它"心里的话"，真正卡住的是你看不见的工具调用过程。不把思考过程和工具调用都流式显示出来，你根本分不清它是"在想"还是"卡死了"——这才是你说的体验问题的根源。

怎么让 thinking 可见：Qwen3.6 走 OpenAI 兼容接口时，思考内容在 reasoning_content 字段里，Hermes/codex 这类前端透传这个字段就会流式显示出来。你本地跑 qwen3.6:27B，Ollama 的兼容接口对 Qwen3 系也会把 thinking 透传出来，前端能看到就不存在"以为卡死"的问题了。实在不想折腾的话，llama.cpp 有 --no-thinking 可以直接关。

我的建议是按任务分流，别全局开关：

• 简单任务（清理磁盘、改配置、跑固定流程）：关 thinking，快和稳优先；
• 复杂任务（写代码、排错、方案设计）：开 thinking，但配一个能显示思考过程的前端，至少能看出它卡在哪一步、重试了几次。

至于"本地模型 thinking 没区别"——27B 这种规模的模型 thinking 收益确实比云端大模型小，但"看不出区别"很多时候是因为你压根看不见思考过程才下的结论。先把输出流式化，观察几天再决定关不关，比拍脑袋直接关掉更靠谱。