<![CDATA[R9700 ai pro 32G 跑大模型还是很给力的，速度也不错]]>Qwen3.6 35B A3B UD Q6模型

96K上下文缓存，

67.28 token/s
微信图片_20260527213647_19_2.jpg

]]>https://lcz.me/topic/330/r9700-ai-pro-32g-跑大模型还是很给力的-速度也不错RSS for NodeSun, 31 May 2026 08:36:45 GMTWed, 27 May 2026 13:40:02 GMT60<![CDATA[Reply to R9700 ai pro 32G 跑大模型还是很给力的，速度也不错 on Fri, 29 May 2026 13:26:21 GMT]]>因为有些场景根部不需要特别严密和精准的逻辑推理， 只要能在一定范围内把一件事情定性就可以了。

有些简单推理场景下，35B A3B 和27B 达到的效果相同，但是速度差别极大。

有些本地的知识库，35B A3B 计算完只需要17.86s, 完全相同的场景用27B居然要117.06s.

体感差异巨大，所以在这种简单场景下，肯定就选35B了。

只能说各有强项，各有所用吧，根据自己的实际需要来确定用哪个模型。

]]>https://lcz.me/post/4220https://lcz.me/post/4220Fri, 29 May 2026 13:26:21 GMT<![CDATA[Reply to R9700 ai pro 32G 跑大模型还是很给力的，速度也不错 on Fri, 29 May 2026 03:41:10 GMT]]>@张老师 因为 装上跑一下就完事了。35B 我都2060 8G跑了一下。27B 稠密启动都启动不了。

]]>https://lcz.me/post/4147https://lcz.me/post/4147Fri, 29 May 2026 03:41:10 GMT<![CDATA[Reply to R9700 ai pro 32G 跑大模型还是很给力的，速度也不错 on Thu, 28 May 2026 13:52:18 GMT]]>@Terry 确实，网配不好说明了一个问题，一个人不是不努力，也不是不学习，是没有意识，1是问AI问不到点子上，2是AI回答了也不见得看明白。门槛跨不过去就放弃了。

我一直想用大模型+提示词+搜索做一个稳定的多文档生成系统，文档之间逻辑相关。业余时间搞了个软件。
听你说模型的变化会导致输出不稳定，我觉得很有道理，我也试了不同家的api出来的差别很大。所以就搞个本地27b试试水。
claude做的太好了，自己的llm+agent确实是典范，普通人有没有必要自己搞个软件接自己部署的本地API，还是直接拥抱claude和codex，但是持续给claude和codex输送最佳实践会加速自己被取代。
提个问题，希望可以做你的视频素材

]]>https://lcz.me/post/4061https://lcz.me/post/4061Thu, 28 May 2026 13:52:18 GMT<![CDATA[Reply to R9700 ai pro 32G 跑大模型还是很给力的，速度也不错 on Thu, 28 May 2026 13:23:02 GMT]]>35b没有意义，a3b可能跟4b或者9b能力差不多。写的代码基本都是无法运行的。看着生成一大堆代码，一堆错，调试能力更是没有。假装一顿调试，结果出更多bug。27b明显能力高出一截，经常是正确代码，有错也勉强能自己调式

]]>https://lcz.me/post/4059https://lcz.me/post/4059Thu, 28 May 2026 13:23:02 GMT<![CDATA[Reply to R9700 ai pro 32G 跑大模型还是很给力的，速度也不错 on Thu, 28 May 2026 13:15:55 GMT]]>

@Brian 说:

@terry 有没有必要先连 deepseek api让hermes积累一些skills，再接qwen27b，感觉27b做研究不行，看长文件也不行，特别是联网有问题，开梯子也不行。不知道是不是配置的不对。
感觉hermes不如claude cli 和 codex cli，但是接入后两个，也就打个招呼就断了，也都是用hermes 连deepseek pro配置的，不好搞，有没有什么思路提供，谢谢。

我刚刚把4份工作文件PDF 总共差不多600页
感觉也还不错 我随便叫他帮我总结
然后再抽个问题叫他找
答案也对

有了本地模型 我就完全放开全部文件都丢进去了

]]>https://lcz.me/post/4057https://lcz.me/post/4057Thu, 28 May 2026 13:15:55 GMT<![CDATA[Reply to R9700 ai pro 32G 跑大模型还是很给力的，速度也不错 on Thu, 28 May 2026 13:09:24 GMT]]>

@张老师 说:

很奇怪！视频与论坛中，老特强调了很多遍的Qwen3.6-27B要优于35B！还是有很多人喜欢35B！

因为快呗
没关系 用了自然会懂

]]>https://lcz.me/post/4055https://lcz.me/post/4055Thu, 28 May 2026 13:09:24 GMT<![CDATA[Reply to R9700 ai pro 32G 跑大模型还是很给力的，速度也不错 on Thu, 28 May 2026 13:07:48 GMT]]>很奇怪！视频与论坛中，老特强调了很多遍的Qwen3.6-27B要优于35B！还是有很多人喜欢35B！

]]>https://lcz.me/post/4054https://lcz.me/post/4054Thu, 28 May 2026 13:07:48 GMT<![CDATA[Reply to R9700 ai pro 32G 跑大模型还是很给力的，速度也不错 on Thu, 28 May 2026 12:41:02 GMT]]>@Brian
1，如果说好用Cluade肯定好用，它说提示词和上下文过度使用的典范，缺点就是贵。
2，恕我直言，99%的人只要使用Hermes+DeepSeek V4 Flash，就能完成他们99%的任务。剩下那1%是留给有大工程的人的差别环境，但如果这些人真的懂，DeepSeek V4 Pro或Qwen3.7 Max这样的国产模型也完全够用。
3，使用DeepSeek先跑一次，只是节约时间，因为它快，我测试过完全删掉Hermes，重装，让Qwen3.6 27b从零开始，它依然能跑通。
4，你连联网都配置不好，说明你对系统环境缺乏常识，终端默认不走梯子，需要你配置代理。一般的梯子比如V2Ray N，会在本地开HTTP或者Socks5代理，问下AI怎么配置。Hermes启动变量中也加入代理，防止未生效。这些东西是基本功，你要有耐心，配置不好，问题多半在你自己。
5，Hermes初始化的时候，它执行网络任务如果失败，你要明确告诉它，使用CURL而不是Web Search执行基础网络任务。如果可以的话，你申请一个谷歌 Search给它，会更好。这些在视频里我都明确讲过，谷歌的免费额度也够用了，超过了收费也很便宜。配置这些的时候，让DeepSeek上，因为它更快。Hermes不需要安装skills，我一个都没安装，都是它自己总结的。

]]>https://lcz.me/post/4047https://lcz.me/post/4047Thu, 28 May 2026 12:41:02 GMT<![CDATA[Reply to R9700 ai pro 32G 跑大模型还是很给力的，速度也不错 on Thu, 28 May 2026 10:34:09 GMT]]>@terry 有没有必要先连 deepseek api让hermes积累一些skills，再接qwen27b，感觉27b做研究不行，看长文件也不行，特别是联网有问题，开梯子也不行。不知道是不是配置的不对。
感觉hermes不如claude cli 和 codex cli，但是接入后两个，也就打个招呼就断了，也都是用hermes 连deepseek pro配置的，不好搞，有没有什么思路提供，谢谢。

]]>https://lcz.me/post/4042https://lcz.me/post/4042Thu, 28 May 2026 10:34:09 GMT<![CDATA[Reply to R9700 ai pro 32G 跑大模型还是很给力的，速度也不错 on Thu, 28 May 2026 07:11:18 GMT]]>@sospda 从模型能力来讲肯定是qwen3.6-27B更强。和35B-A3B之间是benchmark大概10%的能力差距。
对应的，相同硬件下，性能大概qwen3.6-35B-A3B的吞吐量应该是27B的三倍左右。

]]>https://lcz.me/post/4023https://lcz.me/post/4023Thu, 28 May 2026 07:11:18 GMT<![CDATA[Reply to R9700 ai pro 32G 跑大模型还是很给力的，速度也不错 on Thu, 28 May 2026 06:38:43 GMT]]>其实各种模型都装过的， 不下10种， 这个35B A3B跑下来没什么问题，比较流畅。用起来相对够用，简单数学题也都能跑。暂时留下了，其他模型也都还在试， 看哪个好用就留哪个。

]]>https://lcz.me/post/4020https://lcz.me/post/4020Thu, 28 May 2026 06:38:43 GMT<![CDATA[Reply to R9700 ai pro 32G 跑大模型还是很给力的，速度也不错 on Thu, 28 May 2026 04:27:09 GMT]]>你们为啥都喜欢装35b A3b，如果能跑，一定要上27b，速度快没啥意义，能稳定干活才是王道。还有不要执迷于Q6，B站油管都有很多主播实测过，Q6那细微提升在统计误差范围内，也就是，没啥意义。

]]>https://lcz.me/post/3989https://lcz.me/post/3989Thu, 28 May 2026 04:27:09 GMT<![CDATA[Reply to R9700 ai pro 32G 跑大模型还是很给力的，速度也不错 on Thu, 28 May 2026 03:30:05 GMT]]>llama下面，vllm配置很麻烦

]]>https://lcz.me/post/3983https://lcz.me/post/3983Thu, 28 May 2026 03:30:05 GMT<![CDATA[Reply to R9700 ai pro 32G 跑大模型还是很给力的，速度也不错 on Thu, 28 May 2026 03:10:35 GMT]]>请问咿一下这个35b是装在哪一个是llama还是vllm

]]>https://lcz.me/post/3981https://lcz.me/post/3981Thu, 28 May 2026 03:10:35 GMT<![CDATA[Reply to R9700 ai pro 32G 跑大模型还是很给力的，速度也不错 on Wed, 27 May 2026 21:33:47 GMT]]>@kop-wang 其实本地模型最大的意义就是在于Agent，就它消耗Tokens又对智力有要求。其他场景都可以使用在线API，或者网页版本开发的程序替代。所以我一直认为，一个好的本地模型必须能跑顺Hermes，OpenClaw之类的Agent，否则没什么意义。当然了，多模态模型，功能性模型另说。

]]>https://lcz.me/post/3969https://lcz.me/post/3969Wed, 27 May 2026 21:33:47 GMT<![CDATA[Reply to R9700 ai pro 32G 跑大模型还是很给力的，速度也不错 on Wed, 27 May 2026 15:31:00 GMT]]>相较于qwen3.6-27B稠密，moe的35B-A3B性价比还是不够高，当然，如果相较于过去的本地部署LLM，35B-A3B在简单场景下还是不错的。在各大benchmark中，他俩的能力相差大概10%。

另外，直接问hermes的性能是不准确的，要看类似llamabench的测试结果。如果能有prefill性能做比对就更好了

]]>https://lcz.me/post/3948https://lcz.me/post/3948Wed, 27 May 2026 15:31:00 GMT<![CDATA[Reply to R9700 ai pro 32G 跑大模型还是很给力的，速度也不错 on Wed, 27 May 2026 15:15:48 GMT]]>AMD AI Max 395+llama.cpp Vulcan后端+MTP 都可以跑到85tok/s了

]]>https://lcz.me/post/3946https://lcz.me/post/3946Wed, 27 May 2026 15:15:48 GMT<![CDATA[Reply to R9700 ai pro 32G 跑大模型还是很给力的，速度也不错 on Wed, 27 May 2026 15:03:59 GMT]]>这么好的卡，跑这个模型浪费啊

]]>https://lcz.me/post/3945https://lcz.me/post/3945Wed, 27 May 2026 15:03:59 GMT<![CDATA[Reply to R9700 ai pro 32G 跑大模型还是很给力的，速度也不错 on Wed, 27 May 2026 14:35:56 GMT]]>35A3 在实际应用中智力偏弱, 建议还是想办法优化 27B.

网上有文章说加了MTP后能 decode 够到40-50 t/s, 用 ROCm 的话, prefill 也能跑到不错.

]]>https://lcz.me/post/3942https://lcz.me/post/3942Wed, 27 May 2026 14:35:56 GMT