抡锤者

好的 感謝解答 我也來試一試。

請問不同profile 的馬 可以分開使用不同的模型嗎?

我是小白 請教一下。接入 Claude Code 有什麼特別嗎？ 接入Codex 的效果 會有什麼差別嗎?

@fcme

終於完成。也稍微了解你的波折。
拿到專案之後，我發給hermes使用千問27b的模型，繼續未完成的部署，然後就跑去睡了一覺，早上起來想說睡一覺，應該部署好吧。結果確實是部署成功了，但是因為模型生成的階段會生成亂碼，所以還持續的不斷在除錯，無止境的除錯，最後我忍不住把它關了，整個大約跑了將近12小時除錯100多個版本，還無法解決生成亂碼的問題。
我將strata的專案升級到0.1.44.1版本，使用Q4KXL模型，繼續除錯部署。大約花了5小時。終於除錯完成可以正常生成。接下來下指令，打開投機解碼，啟動hicache 。結果如下：

進度回報

投機解碼 — 已啟用並驗證

• DFLASH + DFlash2 draft（5 層 BF16）
• 踩到一個新坑並解決：draft 預設繼承 target 的 r4d_mxfp4 量化 → draft 權重載入鏈同樣錯亂 → warmup 直接 GPU 硬體異常（HSA 0x1016）崩潰。解法：--speculative-draft-model-quantization unquant（repo 生產配方是 AWQ target 所以沒踩到，我們是 MXFP4 target 才會觸發）
• 實測：accept len 2.4~4.3、decode 37~64 tok/s（無投機時 26.5 → 增益 ~1.4-2.4×）
• 正確性：17×23=391

HiCache — 確定無法啟用（ROCm 缺 kernel）
三層根因，全部實測：

1. kernel io-backend：需要 sgl_kernel.get_device_accessible_ptr（HIP 的 host 指標 ≠ device 指標，CUDA UVA 不需要）— 映像內 sgl-kernel 沒編這個符號，重編需 AOT ROCm 工具鏈
2. 我用 ctypes hipHostGetDevicePointer 補上後，init 通過（host pool 8.91GB 分配成功、hicache_attached=True）→ 執行期仍 HSA 崩潰：transfer_kv_direct 的 pinned-memory DMA 路徑在 RDNA4 上壞（SGLANG_RDNA4_DISABLE_STORE_CACHE=1 就是上游已知 store-cache bug 的標記）
3. direct io-backend 也一樣崩

結論：HiCache 在此 RDNA4 堆疊不可用，已從 compose 註解移除。 這是引擎/驅動層限制，非配置問題。

️ 代價：KV pool 縮水（投機解碼的 trade-off）
無投機
• KV pool: 301,936 tokens

DFLASH + BF16 draft
• KV pool: 79,008 tokens（draft 權重 1.48GB + 雙份 KV pool 擠壓）

邊界測試已按 79K 重新排程掃描點（40K/60K/70K/76K/79K/82K/90K），跑完後接 100K+ 多輪長鏈測試 — 但先講清楚：若你要 100K+ 生產上下文，投機解碼和長上下文在單卡上互斥，到時用數據決定取捨。

---

結論：目前r9700。

1. 使用vllm-radiance 推理引擎跑qwen 3.8-27b, 速度與穩定度都不錯，上下文邊界能有180k，跑長鏈任務，沒有衰退問題。
2. Paiton 9月底 200k 版本，上下文召回率，穩定只能到128k，再大的上下文就容易不穩定，簡單的意思來說，就是超過128k的上下文,邏輯比較會跑偏，長鏈任務感覺有衰減，不知是否是錯覺，感覺沒有vllm-radiance穩定順暢。
3. Paiton 10月初版本，還沒測試，聽說可以併發，速度還不錯，但是要降智3%。現在都在想辦法提升智力，正在測試Strata，之後有興趣再來測試。
   4.sglan 能開hicache 之後再來折騰。

@applejuice 说:

@Charly-Cheng 我也是新手
所以我说我做的没有那么高级

我没有把工作交给另一个专门的agent

只有一个专门处理文件主agent
我只是把sub agent 设定是用27b
然后在主agent 的soul 写好 有什么更新文件的动作吧都写好要求 丢给sub agent
主agent 自然会把subagent 需要的资料写好交给subagent
subagent把工作弄好后 主agent 再检查
基本subagent 还是主agent 的一部分
只是处理跟执行的上下文分开了

我一向来都不主张multiagent 协作
至少觉得不是我现阶段的应该用的模式

瞭解，謝謝解答。

@applejuice 说:

@Charly-Cheng 没那么神奇 就只是跑两套llm 然后hermes 设置 主agent strata 是负责检查 副agent 27b 负责动手

也不一定只有strata 可以这样做
纯属最近买了r9700 又加了ram 比较任性

500k 上下文给strata 用
工作交给dense

重申 我只是用来整理私人文件 真正的coding 工作都是claude
以前用27b 改文件死活改不好

我也有用hermes agent, 但是也只是透過telegram 給每個hermes agent 單獨下指令，想說如何讓一個hermes 驅動另一個hermes?
或是讓一個hermes agent 驅動另一個專門編程的agent?
個人是剛接觸這個區塊，有許多不懂的的地方請教。謝謝回答。

@applejuice 说:

@kos-or 我之前查了下 是用户用claude 改代码 用claude 提交
并不是官方下场

是的，確認+1。

@at-wang 说:

小白提个问题，请问未来sglang生态稳定到mac的话 买mac5max stuido 128g 还是mac5urltra 96g

主要是怕未来96g 会被内存限制 放不了更大模型
但是128g的内存带宽还差一倍
有大神帮忙推荐一下吗帮分析分析 ，谢谢

個人看法提供參考，硬件是固定不變的，看這個趨勢，除了27b這個方案，模型還是會往大的方向發展，帶寬也是模式跑的快慢，其中的硬瓶頸。
若是我個人，因為能力有限，無法買不同的設備來試，會在能力的範圍內，盡量的往高點的規格買，因為高規格向下兼容。
我現在有2台主機，原本一台有48GB,一台有32GB內存，因為要測試strata升級了內存, 一台96Gb內存，跑Q4XL不夠內存換IQ4，一台112GB內存勉強跑Q4XL。 不過看到deepseek,或是GLM系列，只能望洋興嘆，因為主板內存最多到128GB。
以上觀點，經驗提供參考。

@fcme 说:

@terry
会的，弄好了我也git一下，回馈社群！

看你的帖子,我讓27B部署不起來。天天來看下,等你等你發帖。

@applejuice 说:

@dardeaw-feng 纯属测试strata

但是这两天用strata + 27b 处理文件的确很爽
不懂是之前用法不对还是怎样
现在strata 安排 27b 工作的模式出来的成绩是不错的

請問strata 安排 27b 工作的模式，實際如何操作？