抡锤者

@Botio-Kuo

主要是之前有遇到一次比較有點歷史的Project A跟Project B在用2個不同版本的Webpack, Hermes自己沒跟到Markdown然後用Global的NPM去下載Webpack然後導致撞車

Agent.md每次都會讀到, API的模型幾乎九成時間都能跟隨Global跟Project, 但是27B只能說大約七成吧

Container內部應該自帶.hermes, 用Container只需要掛載相關的文件夾就可以

至於權限跟通訊的話, 基本上熟悉之後就還好

@Botio-Kuo

首先兩者沒有衝突, Hermes處理本地文件不代表任由Hermes亂生成代碼/文件, Skill.md跟Memory.md變髒就更需要Hermes跟用戶自己定期追蹤和更新, 我自己甚至用Git + 每個星期六日的Cron Job要求Hermes報告這兩個文件更新了什麼

Container本質上就是個懶人包, 適合很多實驗性質的玩法, 玩爛直接弄個新的出來就可以, 對於什麼都不想煩的人開個新Container提供一個Mounting Point要求Hermes把重要的東西放進去就可以

Project一多的話, 隔離化就很重要了, 尤其是我的Hermes現在基本上都在管理迷你電腦上大約6個服務, 每個Root裏面都有一個Markdown, 但是我能做就是儘量提供資訊, 不代表模型會用正確的方法來做

我有針對重要的Project特別設立Agent.md, 不過這不代表27B的模型能聰明到Global跟Project的Agent.md都能跟著做

偶爾幾次我看見它只用了10%上下的上下文就無視掉我在專案上Agent.md部分的規矩了, 天知道它在我沒留意的地方無視掉多少東西

我知道AI寫Code需要步驟阿, 不然我也不用花時間用TDD跟SDD來進行開發阿

我是用27B來進行驅動, 不是DSv4 Flash

@terry

就算加個100％甚至150%其實跟Luna的成本也差不多

用Artificial Analysis弄的

@terry

偶然在Reddit上看到的, 沒有5.6 Luna的話應該也很正常, 畢竟這個是列出每家最強的模型

其實Deepseek加100%估計也還是很便宜

原圖網址

一般情況下5090／5090D + 64GB RAM估計就能本地運行了

我之前簡單玩, 10秒 + Upscale 2X + 0.87MP 大約需要350秒左右

要特意用自家東西的時候已經要打上一個大問號了

@Botio-Kuo

注重本地環境的乾淨阿

Hermes有一件事我蠻討厭的是它很常突破自己的Harness, 我明明已經幫它設立好虛擬的Python跟NPM/Yarn環境, 但是只要我一忘記沒提它就跑去使用Global的Python跟Yarn

理論上API跟自己的搭建27B的分別在於是否能一步到位達成目的而已

一個目的定義清楚 + 切分得好的話, 27B花多點時間也能做到

API貴就貴在你是否願意為這個時間付費

理論上hermes的soul和memory越精簡越好

目前hermes基本上就是全部不管是不是重要的東西都加進去

就連應該歸屬在Skills或者Plugin裏面的東西都加進memory了, 也難怪越用越卡, 因為加入太多不相關或弱相關的東西

@g-yang

我目前跑在hermes上的Brainstorming以及Writing-plans基本上都是簡化Superpowers而來的

一般人(尤其非編程人員) 基本就是移除有關TDD (Test-Driven Development), 變成單純SDD (Specification-Driven Development), 應該就能看得懂

基本上是推薦每個人都拿一份這個, 再用大廠API來按照自己需求進行更改

有一點編程底子可以修改成多顯示一點代碼, 反之亦然

極度推薦在Hermes Root (~/.hermes)創立一個tmp, 把規範, 計劃以及執行過程用不同路徑分類好, 之後hermes有需求的時候就方便自己提取markdown

看完舉個爪, + 1

這個應用方法個人理解是在Harness上面再叠上一個Hard Limit, 沒Token就不允許執行任何有關Coding相關的東西, 這是一個解決方法

我個人用了一個蠢人方法, 在SOUL.MD裏面寫明除了自己提供了一個CLI可以直接執行之外, 統一使用一個叫Brainstorming的Skill

然後這個Skill其實就是我在編程工作跟GPT和Claude對話的模板, 主要是拿來寫規範, 規範搞好之後寫計劃

所以基本上我每次跟自己Hermes的對話其實就是提取意圖後, 一步步地寫好準備要運行的Code Snippet

對我來說這是個Rubber Duck Debugging過程, 對於模型來說其實等於它自己規範好邊界, 什麼需要碰, 什麼不可以碰

是很繁瑣的步驟, 但是勝在寫出來的每一個工序都是Atomic, Agent運行起來比較難出錯

@imbiplaza-ASUS said:
看看Samsung, Hynix, Micron, CXMT and TSMC 有没有大力扩厂的消息？现在才来扩厂，真正投产也是3，4年后的事情了

沒, 消極得很

@stxpnet

![b1f90612-8ec0-4cd8-bcd7-b9e17e88712e-image.jpeg] 大神们制作 模板时候应该是用F16模型 + 大容量显卡制作的，质量好很多。

對, 目前大多數普遍模型都是用FP32跟FP16再壓縮到FP8或者FP4 (無論MXFP4或NVFP4), 然後模板則沿用FP16

以KLD來說, 理論上要FP8是首推, 其次是混合量化, 最後才是統一量化

我很期待未來會有小模型在訓練的時候使用QAT (Quantization-Aware Training, 量化感知訓練)

@stxpnet

我知道他是三進制, 所以我才單純拿BPW來作解釋, 沒單純說是二進制

而且我也說錯了一點, Tenary Bonsai的BPW是1.7, 普通Bonsai才是1.2 BPW, 不過1.7 BPW其實也在IQ1_XXS附近 (1.6 BPW), IQ2_XXS已經是2.xBPW了

Q6 K Quant大約在6.6 BPW了

不論模型怎麼量化, 模型的基本面知識在27B跟9B對比下永遠都是27B優勝, 這個打從模型出世的時候就決定了

而且智商密度不代表Tool Call成功率和用戶對結果的滿意度吧

我在之前也有評測過不同BPW (單純量化跟混合量化) 對於Tool Call的影響

結果就是越低BPW效果越差, 主要都是體現在狀態修正,和遵循結構規範 (Structured Output) 方面, 偏偏這兩個對於Tool Call就是很關鍵的因數

@terry

有自定義當然是好事, 蠻喜歡Slate

看習慣了白色突然來個彩色來了點驚嚇教育

@stxpnet

權重跟KV Cache的BPW是兩件事阿, 模型權重精度過低基本上Cache精度多高也沒用

模板 (如果我沒理解錯意思應該是Chat template)只是提供了呼叫工具的架構

沒記錯Tenary Bonsai的27B量化已經把模型權重精度壓到1.2還是1.3 BPW, 這個基本上應該等於IQ1的程度了

就連單純壓縮 (W4A4的NVFP4) 的4.2x的BPW和混合壓縮 (NVFP4 + FP16, 我自己在用的PrimsaSCOUT) 的5.3 BPW在呼叫Tool Call的時候也偶爾遇到問題, 不覺得IQ1會好到哪裏去

Llama.cpp在真實情況下基本上都是推薦最低Q4或者IQ3 XS (IQ3採用混合壓縮所以應該在3.3 BPW左右)

甚至Reddit在編程上直接推薦FP8起跳

MCN個人感覺就是個喧嘩東西

一個很經典的例子就是YT在2006左右上很火熱的Machinima, 當時基本上大型頻道都會加入, 結果後來爆出的醜聞例如內部團隊的管理不善, 創作者沒有應得的支援和抽成過高才導致沒落

@kos-or

Hermes的Harness (Soul.md和Memory.md)很重要,尤其對於小模型來說

Soul.md負責固定模型的回答風格, 行為習慣, 尤其是運用Skill上的簡單思路, 例如無論如何都必須要寫好一個執行計劃才執行

Memory.md則是在運用所有Skill的一個通用框架, 例如Source Of Truth路徑, Skill的運用規則, 即棄文件要放在哪裡

我自己是習慣要求Hermes自己更新Memory.md的時候跟我說一下