一、两台引擎

两张卡各顶到 98% 附近，长期共存互不影响。Paiton 在 Docker 里，靠 --device /dev/kfd --device /dev/dri 吃 AMD 卡。

Paiton 的参数里有一条：

--served-model-name  Qwen3.8
--max-model-len      65536
--max-num-seqs       8
--enable-auto-tool-choice --tool-call-parser qwen3_coder
--no-enable-prefix-caching

最后一条关掉了前缀缓存，日志里 Prefix cache hit rate 长期是 0.0%，每轮都要重读全部历史。Strata 那边同一时段的复用率是 93%～99.9%。

拿 Paiton 当子代理，是因为子代理上下文短、任务独立，不是因为它在长对话里划算。让它做主模型会很难受。

二、DSH

配置在 ~/.dsh/profiles/desktop/cordis.patch.yml。

凭据单独放，~/.dsh/.credentials.yaml：

refs:
  STRATA_API_KEY: <key>
  PAITON_API_KEY: <key>

两个 provider：

      strata:
        displayName: Strata
        api: openai-completions
        baseURL: http://<推理机>:18090/v1
        apiKeyEnv: STRATA_API_KEY
        models:
          - id: qwen3.8-flash-next-unsloth-ud-q4_k_xl
            contextWindow: 262144
            maxTokens: 65536
            input: [text, image]
      paiton:
        displayName: paiton-65K
        api: openai-completions
        baseURL: http://<推理机>:18982/v1
        apiKeyEnv: PAITON_API_KEY
        models:
          - id: Qwen3.8
            contextWindow: 65536
            maxTokens: 16384

子代理要另外开白名单：

- id: subagent-model-selection-settings
  config:
    enabled: true
    allowedModels:
      - provider: paiton
        model: Qwen3.8
      - provider: strata
        model: qwen3.8-flash-next-unsloth-ud-q4_k_xl

allowedModels 只是允许哪些路由出现在选择列表里，不等于默认。真正派活是按次指定 provider / model，省略就继承主模型。所以"让子代理走 Paiton"这件事，可以在每次派发时写明，也可以在配置中固定，前者更灵活一些。

三、跑一次真实任务

这一节是它在真实任务里的表现，数字来自三个来源：DSH 的会话记录、Strata 引擎日志、Paiton 容器日志，能对的地方都对过。

任务是 kos or 大神出的题： LLM解題 極限測試 Extreme-Exam-v7-A (出題者 : GPT6-Astra-max)。

55 分钟出答案，3 小时 39 分做完

主模型在第 1 轮 55 分钟里给出了答案。但同一轮派出的四个子代理里，有两个在答案出来时还在跑：

主模型 19:03 交卷，③ 又跑了 67 分钟，④ 又跑了 161 分钟。会话总跨度 3 小时 39 分，其中两小时四十三分是 ④ 一个人在后台干活。

模型自己报告的"端到端约 45 分钟"，只算上了它自己那一轮。

三个实现收敛到同一个数

子代理 ④ 是"独立实现"，折腾到 21:44 才跑通：

[ok] b(1..6) match known values
[ok] C(4)=6   [ok] C(6)=63   [ok] C(8)=717
[ok] C(30)=3202559936373493
[info] large-N computation took 60.01s
FINAL_R = 385583993536

和主模型算的结果一致。它还多验了一个之前没验过的量：C(30) 的精确值。

两边的账

Strata 名义上处理的 prompt 更多，但 96.9% 来自缓存；Paiton 没有前缀缓存，四百九十万全部重算。实际计算量差了十一倍，和我一开始的预想正好相反——不是主模型扛大头，是子代理。

并发

310 个采样窗口里，73 个是 3 路同时解码，221 个是 2 路以上，排队峰值只有 1。三个子代理是同一秒发出去的，日志证明它们真在同时算。

Strata 逐请求的中位解码是 92.3 tok/s（p10 74.8，p90 111.6），预填中位 226 tok/s。Paiton 聚合生成峰值 292.8 tok/s，预填峰值 5,744 tok/s——原始预填比 Strata 快，但它每轮都从零算，这个优势被缓存抵掉了。

一次压缩失败

三次自动压缩里，一次报 summarization produced no text summary content，摘要请求没产出内容。会话继续了，但那一次等于没压缩。

四、跑完之后

端到端是通的，并行也是真的，日志摆在那里，这个不用怀疑。

这次真正值钱的是上下文隔离。子代理在 65K 上限里各烧各的，主模型在最大 151,082 token 的上下文里继续工作，复用率 96.9%。子代理的脏活一点没污染主上下文。这一点比快多少 tok/s 重要得多。

但"交卷"和"做完"不是一回事。主模型 19:03 给出答案时，还有两个子代理在跑。主模型把"我算完了"当成了"任务完成了"，没把仍在后台进行的工作交代出来，人看到的现象就是任务一直不结束。

冗余验证的代价也被低估了。子代理 ④ 用两小时四十三分独立重写了一份实现，结论和主模型一模一样。它先写出来的版本跑不完——13,824 个除数各做一次 30×30 矩阵幂，纯 Python 要几十亿次运算。后来子代理 ④ 跑了一遍性能分析（Python 自带的 cProfile，能按函数统计耗时），定位到瓶颈就在这里，重写那一段之后才压到 60 秒。会自我纠错是好事，但为一个已有答案的结果再烧三小时，收益几乎为零。

八个槽位只用了三个。任务拆不出八个互相独立的子任务，配置的余量也就只是余量。

还有一点得说清楚：这次没有对照组。同样这道题，之前只靠 Strata 单模型（加上我手动修它的 bug）也得出了一模一样的答案。所以这次证明的是跑得通、并行真、结果对，没证明多子代理比单模型更好更快更省。要证明这件事，得同一道题跑两遍对照，这次没做。

算一下就很清楚：

机械计算：    1 秒
出答案：     55 分钟
全部做完：  3 小时 39 分

开 parallel、加子代理、换更快的卡，边际收益都很低。卡住效率的是交卷标准、没有预算的冗余验证，以及缺一个对照。这三件都不是硬件问题。

五、现在的状态

小结

至于这套组合能不能用，那要分跑什么样的任务。

对能自我验证的活——数学推导、算法实现、数据变换这种答案对错机器能判的——它有实打实的生产力。这次 55 分钟拿到一个由三条独立路径互相印证的答案，全程本地，没有 API 费用。以前要么自己写几小时，要么花钱调云模型。

优点集中在三处。上下文隔离：子代理各烧各的 65K，主模型在十五万 token 里继续，互不污染。不抢卡：子代理在 AMD、主模型在 N 卡，这是双卡唯一真正兑现的地方。还有一个我原本没预期的——子代理扛得住反复试错，有一个重写了三小时，最后真跑通了。

短板同样清楚。Paiton 没有前缀缓存，每轮从零读 prompt，长任务不划算；65K 一过就得回落到 Strata，而 Strata 和主模型共用一张卡、还只能串行，优势当场抵消。更麻烦的是子代理会跑偏：那次三小时的重写，主模型中途并不知道该不该喊停，人看到的就是任务一直不结束。

至于省不省钱，得先分清两边是怎么计费的，它们根本不是一回事。

本地是按时间花钱：满载 500W，一小时两毛五电费（0.5 元一度）。这段时间产出多少 token、跑得快还是慢，跟账单无关。

DeepSeek 是按 token 花钱：flash 空闲时段缓存命中输入 0.02 元/百万，未命中 1 元，输出 4 元；高峰时段翻倍。跑多久不影响账单，处理多少 token 才影响。高峰是工作日 9:00-12:00 和 14:00-18:00，其余时段和周末按空闲价。

我 9 月的真实账单：9,424 次请求，2.89B tokens，154.36 元。平均每请求 30 万 tokens，均价 0.053 元/百万——只比缓存命中价 0.02 高一点。

这个均价说明了一件事：两亿九千万 tokens 里，真正按未命中价和输出价算的只有八千万左右，其余全部命中了缓存，命中率约 97%。

而缓存命中是这套账里最关键的数字。同样 2.89B tokens，全部命中的话账单是 58 元；全部未命中，是 2,888 元。差五十倍。

换成本地呢？本地不吃缓存价，只吃时间。按这次实测的真实计算速率（未命中加输出，每小时 1.56M tokens），9 月那八千多万的实际计算量，大约需要每月 52 个 GPU 小时，折合每天 1.7 小时，电费 13 元。

本地电费按满载 500W、0.5 元一度、30 天算；500W 是按 N 卡实测 183W、A 卡加主板 CPU 估的，空闲时 N 卡只有二十来瓦，所以这一列是上限。账单按空闲时段价折算，高峰翻倍。

结论比我原先想的保守：按现在的用量，买卡完全不划算，省下的钱要三十多年才抵得上机器。用量涨到十倍——每天十七个小时——才勉强进入三到四年的区间；跑满 24 小时也只有现在的十四倍，回本两年半。二十四小时是单机的物理上限，再往上只能加机器。

但这个结论有两个前提，不说清楚会被误读。

一是用量。我不是专业开发者，2.89B 是业余时间折腾出来的量。专业开发者一天到晚在跑 agent，可能是我这里的几倍到几十倍——真到那个量级，回本周期会从三十多年掉到几年，而且会撞上单机的物理上限。

二是目的，这一条更关键。这套系统现在没在产出任何价值，纯属娱乐和实验。"回本"这个概念只对生产环境成立：如果它就是个爱好，这笔钱该和别的爱好比——三万块的相机不会因为"省了租相机的钱"而回本。它买的是折腾的乐趣、随时能试的自由、数据不出门。

所以准确的说法是：按我现在的用量和目的，这笔钱是消费，不是投资。想让它变成投资，用量和生产价值得同时上去，缺一条都不成立。

另外两点。本地这个 Qwen3.8-Flash-Next 和 deepseek-flash 不是同一个东西，能力和可靠性都有差距，省钱的账只是一面。还有这个数仍有压缩空间——3 小时 39 分是没优化的试验状态，光一次冗余复核就占了 2 小时 43 分，真进了生产流程这种活不该重演，账还会更好看。