抡锤者

简而言之：Fish Speech 1.5 + 真实参考音色（可以直接让hermes去youtube和bilibili去扒，选自己喜欢的，没有bgm的，最好是那种纯聊天的视频）

关键配置：
"chunk_length": 400,
"temperature": 0.7,
"top_p": 0.8,
"repetition_penalty": 1.1,

参考音色控制在15秒以内（超过20秒会过拟合，起反效果）

推理精度：FP32（~3.5GB VRAM；也可以 --half FP16 ~1.74GB）

最终性能：RTX 3070 ，0.32倍时间消耗（生成1分钟的音频，大概需要18~20秒）

推荐hermes PUA话术：
1、hermes，帮我安装fish speech1.5当作你的TTS工具
2、把(一个bilibili网址)这个视频的人的音色当作参考音色，截取最清晰的12秒
3、设置参数：如上
4、生成X个种子样例，我听听看选择哪个种子效果。
5、ok，就选x种子吧，以后回复语音的时候你要进行口语化润色。
6、把整个目前敲定的TTS流程记下来。以后我发语音给你，你就要语音回复我。

1、目前成本最低的是本地自建openViking。
2、向量数据库可以解决memery长度限制2200字符的瓶颈。
3、因为目前Hermes Agent有session_search和memery，几乎不会主动调用向量数据库检索。
4、openViking的remember相关代码有逻辑bug，每次告诉你记住了其实压根没记（Debug给我整力竭了，还在思考要不要费力提PR，我看Github已经攒了5k的PR了……）

所以：
如果你有一些数据记录、索引的需求。那么可以用，openViking好用且轻量。
如果没有，只是希望辅助Hermes做记忆，千万别用。

如果是必须localLLM且用Claude Code工具，qwen3.6-27B，大于Q4的量化、且开满256K上下文是唯一的选择。

因为Claude Code的提示词比较多，逻辑比较绕。用运行参数太少的moe模型很容易忘事。Claude Code的调用机制也没有针对极小参数的运行做优化。所以会导致很长时间的空转和纠错。

确定用Qwen3.6-27B之后，可选项就很少了。
1、买显存>=32GB的N卡的台式机。（超预算）
2、买显存>=32GB的A卡的台式机。
3、买M5 MAX 128GB内存的MacBook Pro 16寸（超预算）
4、等M5 Ultra的 Mac Studio。（超预算）

这三者各有利弊。
1、32GB显存开Q5+256K上下文有点紧张。
2、A卡的性能不如N卡，R9700的prefill不过千，decode大概在30+不到40。（对应的5090可以做到prefill 3000+，decode 75+）
3、prefill太慢，大概700t/s（数据来自极客湾实测）只能选择16英寸版本，14寸版本散热规模不够，容易撞墙。
4、目前还没上市。但可预计的prefill性能也不会有太大提升。

PRO 6000如果只聊单线程prefill和decode性能，只是和5090相当。
PRO 6000的优势主要在于ECC认证的显存、官方静音涡轮卡（MAX-Q版本）以及多出来的64GB显存。

所以公式很简单，如果你认为64GB ECC认证显存的价值>40000人民币，或者你想玩静音阵列（比如MAX-Q * 3）跑deepseek v4 flash，你就可以买。
否则就不买。

这里有几个原因。
1、96GB显存，其实跑不下大的Moe模型。122B的Q5量化就爆了。
2、对于小模型，96GB显存又过于overkill。
3、多个模型服务跑在一张显卡上，目前没有一个最佳实践做资源隔离。会降低效率。（因为你一定是用Agent来驱动LLM，所以必然是多个模型同时运行）。

确实，目前能如此垂直的信息源，除了reddit的localllm分区之外，就是这里了。

我自觉也是比较幸运，能在信息和能力比较完备的情况下，经历机缘巧合，亲身经历一个新赛道的BBS的起步。

感谢时代，感谢Copilot的数次涨价撕毁合同（如果不是github不做人，我也不会研究localLLM、开源Agent），感谢锤哥。

1、如何远程控制linux主机：SSH
2、“帮我把主力机叫醒（开机）”这个需要远程开机设备，核心原理就是利用有线网口的lan唤醒功能。
3、“帮我看看主力机现在卡不卡？” “主力机如果不忙”，这个需要你定具体的“忙”、“卡”的策略。然后通过ssh获取Linux的资源占用就好。
4、现在做不到，目前的Provider Routing只支持几个有限的策略。

@yang-tae 故意输入多一点提示词，比如粘一个文章，跑一下，主要看Prompt速度，如果Prompt速度不能在500以上，连Hermes的体验就会很差了。

因为hermes会频繁对LLM发起调用，每一次都要走prefill，所以对于输入速度要求比较高。

hermes有很多系统提示词，冷启动的第一次请求，提示词输入在5k左右这个量级。如果是500t/s的输入速度，就要罚站10秒钟。你可以想象，Hermes每跑一行命令，都要罚站10秒。

没太搞懂这个“精神分裂”的原理
1、对于memery和User.md的修改是实时的。他判断需要修改，就会实时修改。
2、不同渠道、相同渠道的不同聊天框，都是完全不同的两个session，他们分别有各自的sessionID，只要你知道sessionID，即便是不同渠道你可以随时调取回来。session的内容也是实时记录的。

你认为的分裂，是指他们的聊天记录不互通？理论上不会出现这个问题。
tool、skill等工具的初始化明确说了是要重启hermes主进程才会生效的。

1、openClaw和Hermes是否有完全一致的MCP、Skills、Tool、记忆配置？
2、可以尝试用终端执行hermes命令，然后通过观察他终端的过程指令来区分哪个步骤是错误的。然后从而区分是模型能力问题，还是缺少工具，还是其他。

用的是最新出的windows native版本？目前这个版本还在early beta，所以肯定会有这样那样的问题。
从这个报错信息来看，应该是他这个安装脚本写的就有语法错误。多了逗号。

btw：基本上所有hermes生态相关的东西，都跟linux强相关，所以目前来看，研究他的windows安装脚本，弊大于利。
当然，如果楼主还是想继续的话，可以手动编辑一下这个脚本，删掉上面报错的两行逗号，就类似这样：

[string]$Branch = "main"

[string]$HermesHome = "$env:LOCALAPPDATA\hermes"

然后再试试。

@Henry-Chiu 我个人的经验是，如果不知道该从何入手，最好的方式就是抄作业，先用一个大神的环境先跑起来，然后使用的过程中再根据自己的实际情况再逐步微调。这样相对而言成功率高一些，仅供参考。

具体可以直接让chatGPT推荐一下操作步骤，或者在本论坛，reddit的localLLM找下看看。

这个输入（prefill）速度还是不对，290t/s太慢了，参考https://api-inference.huggingface.co/Qwen/Qwen3.6-27B-FP8/discussions/11

这个帖子，他的prefill速度能到4000，虽然他是48GB的魔改版，但是也不会有这么大的差异。

@菠菜多 是这样的，而且即便是有本地算力的朋友，也可以利用在线API高prefill、decode的性能，先跑通自己需要的工作流以及需求。固定skill之后，利用本地算力再介入负责执行。

这样既能高效的搭建工作流，又可以保障实际运行时的隐私与信息安全。

LocalLLM的优势是能提供稳定的基座算力，跟头部在线API比，无论是智力、上下文长度、还是性能，还是有不小的差距。

我预测，支持开源自部署的模型，一定会一直维持现在这种接近顶级模型85%~90%左右的能力。无论过高还是过低，开源模型这个产业逻辑都成立不了。

还有一点值得补充，Coding这个场景，算是对于量化比较敏感的场景。有个对于量化质量的专用参数：Mean KL Divergence。可以理解为量化后的模型和全尺寸模型的“差异”
根据unsloth的数据，Qwen3.6系列的量化失真，大概是下图中绿色的点：

可以理解为，Q2量化和Q6量化之间，插了一个数量级的差异。

当然，严谨来讲，这个“差异”也不完全是往坏的差异。就跟你买彩票，你输错了号码也一样能中奖。
但是从控制变量，生产环境的稳定性的角度，还是要以贴近全量模型为目标。

然后就是hermes相当于是给外界暴露一个一个攻击入口，比如他的message gateway，如果hermes有什么漏洞，攻击者有可能会拿到wsl的root权限，从而打开攻击你整台机器的大门。

当然，这就不是hermes本身的执行问题了，是系统安全问题。

壕~

工作站版个人用确实合适。
唯一需要担心的就是接口融化的问题。
我看很多人都是功耗限450W运行的。

台湾同胞有500W也烧了的案例。

另，小特在这个贴子的回复引用的论据有诸多硬伤，可以忽略。

相比较方案1、2来讲，方案2更靠谱。

mac体系的文生图效率超低（同样分辨率的图片，生成时间大概是同价格N卡的10倍）96GB内存也是非常尴尬，论跑小模型，性能被同价格显卡吊打，论跑大Moe模型，内存不够。

如果说抛去必须LocalLLM的理念不谈，方案3其实最合理。你可以通过在线API先挖掘你的需求和工作方式，等真正出于成本、法规限制（比如你需要NSFW图片、或者一些名人的梗图）、工作流稳定性等考量，再去考虑localLLM，其实是更负责任的选择。

@Henry-Chiu 主要关注下上下文窗口和kv量化的配置。

ollama这个工具我很长时间不用了，目前主要以llama.cpp为主。
个人实测，在llama.cpp下，开满了256K的话，Q4_K_M，VRAM占用应该是28GB左右。

使用参数如下：
--ctx-size 262144
--flash-attn on
--cache-type-k q8_0
--cache-type-v q8_0
--temp 0.6
--top-p 0.95
--top-k 20 \

@Henry-Chiu 如果是windows环境的话，wsl2是一个非常便于上手的选择。而且wsl2环境和windows环境的文件等可以灵活共享。

不用担心命令行环境的问题，只要按照wsl2的教程一步步来，是没有任何门槛的。
so，why not

如果遇到什么困惑的问题，或者和hermes官方wsl教程有不一致的地方，可以问问openAI的思考模式或者deepseek的专家模式试试看。
就直接把错误，或者屏幕上的信息复制给他就好。openAI更方便，直接截图都可以。