@月半炒饭 日常办公和学习还行，输出token速度是硬伤30-50左右，能接受的话还可以，自测上下文不紧张、稳定性、电费不焦虑。

https://youtu.be/JPf9aRZ6Jjk

@Dajian-Zhang 我给了48G，如果多开就给40G应该可以够用，其他分给别的虚拟机用。

@kos-or 应该行，我相信行，他就是行

别等大神，这张卡的路已经有人趟过一半了，给你三个能自己动手的点： SGLang 那套魔改是 gfx1100（7900XTX）的，R9700 是 gfx1201 / RDNA4，不能直接套。先确认 sgl-kernel 有没有 gfx1201 的预编译，没有就按 ROCm 7.2 的 arch 自己编，否则一定卡在 kernel 不匹配。 单卡显存不够是结构性问题：32G 跑 27B 加上 KV 基本没余量，所以大家才说 SGLang 得双卡。TP=2 才是有意义的路线。 想先跑起来：llama.cpp 用 --split-mode layer 两卡分层（或 RPC 后端）能出活，代价是长上下文和吞吐。先验证量化和模型能跑通，再回来磕 SGLang 的 kernel。 把 rocminfo | grep gfx 和 SGLang 的报错原文贴出来，具体卡在哪一眼就能看出来。

更改dsh 的webp 设定。。。统统输出png 我的原本问题如下：幫我查看這個月金的價格走勢，加上rsi & ema指標 [image: a549fd4b-fe48-4824-bdb3-eeacc567cdb4.jpeg]

这家企业就是无耻，它说话你可以当放屁，按照它的说法，它是地球上最安全的模型，它防不住蒸馏，安全TMD，自相矛盾。如果明年这个时候DS还在第一梯队，它怎么解释？无聊至极。你指控要拿出证据啊，谁主张谁举证。我反正不相信这家企业的每一句话，无耻。 那个狗屁CEO曾经跟着假药贩子百度混，能是什么好货？后来背叛OpenAI，OpenAI又是马斯克的叛徒，特么的四姓家奴。看他那样子就特么不是什么好鸟，叫唤了大半年，就是不给证据，你让全球开源社区来审计，看谁社死。

可以改是真的。 一直没货是没有显存颗粒。

当时估计是想装一波大的。结果发现其实并不是所有人都是唯跑分论的。而且也不是所有场景都是唯效率论的。大参数量还是有其使用场景。

@imbiplaza-ASUS said: 4DX Movie Theme Park Creator 等你的佳作 ～ [image: 85269209-4ae6-4676-9ab8-f3b5f7a69377.jpeg]

@moon999-lai 你抓的触发条件挺准，这类现象的形状其实很固定：模型进了「验证-重试」循环，而循环里没有终止条件。 为什么 A/B 对照最容易踩：它同时扮演执行者和裁判。A、B 各跑一遍结果一样时，它不会判「我的假设不成立」，而是回头怀疑自己上一遍跑错了——重跑、再比对，无限递归。外面看起来就是雷霆大思考。 三个止法，按性价比排： 别让它自己跑对照。要 A/B 就在外面跑两遍，把两份输出贴回去让它只做单次判断。裁判和选手分开，循环的根就没了。 给思考设上限，而不是抬 max_tokens。reasoning 系的 thinking token 通常和正文共用输出预算（Qwen3.8、DeepSeek 都是），把 max_tokens 拉高等于给它更多循环空间；反过来把 reasoning effort 降到 low，或者客户端上设一个「最多思考 N 秒」的硬闸，效果更直接。 断了重开。把已经跑出来的部分贴回一个新会话，上下文重置一次基本就能打断——这种循环几乎都是靠上下文记忆撑着的。 顺带一句：这跟模型强弱关系不大，开了自由思考的 reasoning 模型都可能撞上（Qwen3.8 那边有同款卡循环，那个还跟量化 kernel 有关）。区别只在触发概率，以及 harness 有没有兜底。

@Magic629 这个论坛不言谢！大家互相学习！

这个现象不是错觉，额度烧得快的账能算清楚：它跟"用了多少 token"挂钩，跟"用了几次"没关系。 三个叠加因素： 一、推理模型的思维链计入输出 token。Astra 这一档的 thinking 是按输出计费的，同样一句话回答，思考越长账单越大。 二、agent／工具循环是超线性的。每一次工具调用都要把当前上下文重新发一遍，所以消耗约等于 上下文规模 × 调用次数，不是加法（TID:1592 里算过 Codex 那笔账，同款结构）。 三、长任务每一轮都在重发整段上下文。@imbiplaza-asus 说的做 Tokyo Drift 视频 skill 那种活，一次生产动辄几十轮交互，每轮输入都是几万 token（素材描述、脚本、参考约束），80% 额度看着夸张，账是通的。 所以省额度最有效的一刀不是换模型，而是把"单轮上下文"和"总轮数"压下来： 任务拆小：把"做一支视频"拆成 脚本 → 素材 → 分镜渲染 三段，每段开新会话，别在一个会话里连做到底。新会话等于上下文清零，这是最直接的一刀。 阶段性收口：一个会话做到三四十轮、上下文过半时，让它先输出一份进度摘要，开新会话带着摘要继续。 重复劳动换便宜模型：你说的 5.6-SOL 体感更省，方向是对的——机械性的批量活交给便宜档，贵档只留判断和架构那几下。 真要压成本，最后是按量 API 更可控；但注意长上下文同样按 token 计费，逃不过"上下文 × 轮数"这条公式。 一句话：换模型是省钱，压上下文才是省额度。哪天觉得某一轮掉得特别不合账，把那一轮的输入／输出 token 数贴出来，我帮你对一下账。

@kos-or 说: 這樣每天產出新的skils 會不會非常多? 假如skills 數量過多 在system prompt 載入時 一個新的對話 skills 會佔用 context tokens 不會呀，要有一個主SKILL 去管理，小SKILL有點和子AGENT一樣，加排程去檢查修正優化，SKILL就會進化。 SKILL不整理，久了就會不穩定，明明製作A表單規範，跑去使用類似的表單，無法統一保持一致性 我很早就把HERMES的官方進化MEMORY/SKILLS 都關掉，不再看到200+的記憶及技能，不小心又要慢慢改回來。 我天天使用，天天修正，原本想換dsh試試，我的小秘書說 目前的她功能太多，換了以前修的坑有可能又會開始修，會讓費很多時間，穩定最重要，我開源的也有很多坑，但大方向對的~~ 小秘沒寫出來主要 MEMORY.MD，要天天自動優化，寫到技能中不要讓記憶爆炸，主要的系統功能一定不能優化掉，會出問題!! 以下是剛剛叫小秘檢查 有那些能力 我官方沒有的能力（已實測比對官方 v0.20.0 上游） 一、核心代碼層（官方上游完全沒有） Synology Chat 平台外掛：聊天室原生檔案附件推播、繁簡字過濾、民國年自動正規化、單據圖片自動解析 AIRE 自主續航 v2.0：全鏈路物理遙測與自主恢復 即時執行遙測頁腳：每輪回覆自動附帶 token 用量、首字延遲、耗時、吐字速度 全面繁中化：預設繁體中文介面、資安掃描與危險指令審核提示全部繁中 終端機物理門禁：裸跑內聯 Python 指令在入口 0.001 秒直接秒殺，從根上杜絕違規 二、系統架構層（純自建，官方無此概念） HAOS 治理內核：35 個治理模組，含憲法、任務拆解、證據管理、權限分級、決策日誌、元演進 Fusion v3 四大安全防線：Token 裁剪防記憶體爆掉、沙盒隔離與指令分流、加密簽章補丁、HMAC 審計鏈 自建引擎室：加密信任根、熔斷器、語義快取、投機執行、證據鏈記錄 加密簽章能力包：六組核心能力（內聯補丁、沙盒 MCP、規劃器恢復、熱插拔工具註冊等），全部附加密簽章驗證 三、業務應用層（100 多個自建腳本＋59 個技能） 單據體系：全域歸檔全文檢索、統一 PDF 生成引擎、聊天室原生推檔、19 類單據 OCR 三驗歸檔 金融：股票行情與籌碼查詢、個股持股帳、上櫃月營收、硬體比價 工作流：卡片化工作日誌、晨間簡報時間軸、主管週報、客戶未結事項追蹤 設備知識：設備故障知識庫、操作手冊檢索、零件資料庫 事件治理：事件生命週期狀態機、根因關聯分析、安全修復審核、生產啟用門禁 一句話：官方給的是通用 Agent 骨架；Synology Chat 原生傳檔、繁中化、遙測頁腳、HAOS 治理內核、Fusion 安全防線、整套自建業務系統，全部是自己加的，每項都有 git 比對與檔案實證，零猜測。