@fcme
这些天用起来，感觉Strata真稳，配合radiance给子代理，感觉本地模型真是有生产力了。都不舍得占用显卡打游戏了。
-
R9700 - vllm radiance 分支 -
把 Strata+qwen3.8-flash-next-unsloth-ud-q4_k_xl 接进 Claude Code的五个坑@charly-cheng
老特之前曾经为此专门发了一个本地模型如何接入Codex的帖子，你可以搜搜。 -
把 Strata+qwen3.8-flash-next-unsloth-ud-q4_k_xl 接进 Claude Code的五个坑@charly-cheng
OpenAI已经全面改为Responses格式，目前主流的开放模型虽然都宣称支持该格式，但是我个人实际体验来说兼容性不好，尤其是在Codex里接入本地模型后，工具调用时体验较差，长任务过程中会有多次中断。有很多路由转换的工具，包括CC Switch的新版也加入了聚合模式，简化了将本地模型整合入Codex的过程，但是具体使用过程中仍然不如官方模型那么丝滑。而Claude Code就没有这些问题，主流模型都支持Anthropic messages格式，通过CC Switch接入后，无论是线上模型还是本地模型接入后都能很顺利的工作。推荐使用Deepseek Harness，灵活、方便、功能强大。 -
R9700 - vllm radiance 分支其实我觉得paiton 不是最好的选择
除非多人一起用
不然个人使用 radiance 比较好现在是这么用：
1、接入dsh，Strata+QFN-Q4_K_XL做主模型，radiance-100k给子代理用，进行专业文档处理。
2、VS Code里用Codex插件做规划/审核，Claude Code插件接入Strata+QFN-Q4_K_XL进行网页开发。
跑了两天，目前感觉还行。 -
R9700 - vllm radiance 分支正好前两天也在R9700 32G上部署了Radiance，简要汇报一下。
Radiance · Qwen3.8-27B MXFP4 单卡部署报告（R9700）
部署日期：2026-10-19 · 主机：
[email protected]（Ubuntu，kernel 7.0.0-31）
硬件：Ryzen 7 9700X / 123 GB DDR5 / RTX PRO 5000 48G + R9700 32G（gfx1201）
目标：在 R9700 上用 radiance 跑 Qwen3.8-27B MXFP4，4 并发，替换/对比 paiton-65k
1. 用 Docker（ROCm 7.2 的问题）
宿主机装的是 ROCm 7.2.4，但 radiance 镜像自带 ROCm 10.1 userspace，主机 ROCm 版本不参与：
层 谁提供 本机 内核 amdgpu/ KFD宿主机内核 7.0.0-31，支持 ROCm 10.x ROCm userspace / HIP 容器镜像 10.1（镜像内） 验证：
- paiton 的 ROCm 10.0 容器已在本机跑通（225.5 tok/s），说明内核支持 10.x；
- radiance 镜像拉起后输出
I device: AQL backend, 1 device(s) [0:gfx1201]； - R9700 的 BAR0 = 32G（ReBAR 已开），
cwsr_enable=1，/data为 ext4。
2. 部署物
项 路径 / 值 镜像 stilldeadcode/radiance:latest（582 MB，radiance 1.8.1）模型 /data/ai/models/radiance/qwen3.8-27b-mxfp4.rad（18.05 GiB）模型 sha256 a4908940c568f5f9dd24e88f46aefe9ac2ae07dfec023a2eaa1d14dcaa3df4f8（已校验）模型名 Qwen3.8启动参数（日常档）：
--model /models/qwen3.8-27b-mxfp4.rad --host 127.0.0.1 --port 18982 --served-model-name Qwen3.8 --tp 1 --max-num-seqs 4 --max-model-len 200000 --kv-cache-dtype fp8 --max-num-batched-tokens 4096 --num-speculative-tokens 7 --prefix-cache-mib 8192 --reasoning-effort none --gpu-headroom-mib 160
3. 启动报告（实际值，非估算）
card total 31.86 GiB already held 226.59 MiB activation arena 1.50 GiB step staging 135.74 MiB hardware queues 66.73 MiB --gpu-headroom-mib 160.00 MiB claimable 29.77 GiB static weights 15.70 GiB (vision 879 MiB 在 VRAM，embedding 2.37 GiB 去 host) elastic 14.07 GiB kv cache 14.07 GiB = 418,976 tokens = 2.1 × 200,000 其中 1.16 GiB 是 per-sequence linear state资源 实测 VRAM 占用 31.68 / 31.86 GiB（99.5%），空闲 ~177 MiB 主机 RAM（radiance pin） 17.27 GiB = embedding 2.37 + prefix paged KV 8 + linear checkpoints 5.99 + staging 系统 available 部署前 61 GiB → 部署后 48 GiB（Strata 仍占 ~98 GB RSS） 进程 1 个容器，16 threads 启动耗时 约 15 秒（18 GB 从 NVMe 以 ~4 GB/s 读入） 关键结论：KV 池按
--max-num-seqs × --max-model-len封顶。 三个档位：radiance-100k：4 seats × 100K = 400,000 token，100% backing（当前运行档）radiance-200k：1 seat × 200K = 200,000 token，100% backing（单条超长会话）- 旧的 4 seats × 200K：418,976 token，53% backing（一条 200K 会话 + 余量）
4. 实测性能（本机，240 W 功耗墙）
测试 结果 单流 code 768 tokens（Go LRU） TTFT 0.04 s，132.1 tok/s，5.85 s 单流短回复 208 tokens 179 tok/s，1.21 s 4 并发 × 512 tokens 每条 116.4 tok/s，合计 465.6 tok/s，4.47 s 16K prompt prefill TTFT 5.23 s，2,924 tok/s 16K prompt decode 102.4 tok/s（32 tokens，样本短） thinking reason=0，默认关闭口径说明：paiton 记录的 225.5 tok/s 是“英文 code、纯 decode”；本次 132.1 是 768 token 端到端 decode，prompt 内容不同。必须用同一批 prompt 做 A/B 才能定论。
4.1 同 harness 基准（
/data/ai/radiance/bench_ab.py，prose 输出 256 token）输入形状 TTFT prefill decode 64 0.043 s — 91.1 tok/s 4K 1.38 s 2,909 tok/s 81.4 tok/s 16K 5.53 s 2,852 tok/s 78.3 tok/s 32K 11.96 s 2,629 tok/s 72.3 tok/s - 这组 prompt 输出是 prose（RAID 风险分析），DFlash2 接受率低，所以 78–91；换成 code prompt（Go LRU）是 132 tok/s，官方对应 prose 77 / code 164。
- 4 并发短 prompt（37-token prompt，4×512 token）decode 聚合 465 tok/s（每条 116）。
- 4×16K 长 prompt 端到端 27.4 s、1,024 token，是 prefill 主导（约 64K prompt token），不能当 decode 聚合看。
5. A/B 结果：radiance vs paiton-65k（2026-10-19，同一脚本）
同一
/data/ai/radiance/bench_ab.py，同一批 prompt（nonce 防缓存、cached_tokens==0），
prose 输出 256 token，3 次取中位数；paiton 侧带chat_template_kwargs.enable_thinking=false。形状 Radiance TTFT / prefill / decode Paiton TTFT / prefill / decode 64 0.043 s / — / 91.1 0.086 s / — / 43.0 4K 1.38 s / 2,909 / 81.4 1.14 s / 3,533 / 38.3 16K 5.53 s / 2,852 / 78.3 4.58 s / 3,443 / 34.6 32K 11.96 s / 2,629 / 72.3 9.69 s / 3,246 / 36.6 4×16K 端到端 27.4 s / 37.4 聚合 26.3 s / 38.9 聚合 code 768 tokens 132.1 tok/s 65.3 tok/s 结论（以当前安装为准）：
- decode：radiance 快约 2.0–2.3×（prose 72–91 vs 34–43；code 132 vs 65）。
- prefill：paiton 快约 1.21–1.23×（3.2–3.5K vs 2.6–2.9K tok/s）。
- 4 条 16K 长 prompt 同时跑时，端到端几乎打平（prefill 主导）。
重要保留：paiton 启动日志出现
[radiance.w4] no w4a16 gemm_nt kernel in this r4d build, disabled [radiance.gemm] no gemm_nt kernel for M<=64 bf16, disabled这两个 kernel 被禁用；且 paiton 记录里的 225.5 tok/s（英文 code、decode-only）远高于这次的 65.3。
所以 paiton 当前这版可能不是它的最佳状态（镜像/内核覆盖有回退），2× 的 decode 差距里有多少是
引擎差异、有多少是这版 kernel 缺失，需要修好 paiton 镜像后再复测才能定论。在修好之前，按“当前可用的配置”选型：radiance 在 decode 和上下文容量（418,976 token vs 174,634）上占优，paiton 只在 prefill 上快约 20%。
-
把Strata + Paiton 接入 DSH 实测，看看本地模型到底值不值 -
本地模型已經能取代雲端？我讓 Qwen3.8 flash next 和 GPT 玩同一款遊戲，終於知道 Benchmark 為什麼不能全信了尤其想知道，有沒有人成功讓本地模型在沒有人工一直提醒的情況下，自己探索陌生環境，而且能越做越熟練？
这就是人工智能追求的目标，别说本地模型了，云端大模型都还做不到。
-
把 Strata+qwen3.8-flash-next-unsloth-ud-q4_k_xl 接进 Claude Code的五个坑把 Strata+qwen3.8-flash-next-unsloth-ud-q4_k_xl 模型（262,144 上下文），通过 CC Switch 接进 Claude Code 当日常 coding 的模型。
连通本身没什么难度，
claude -p第一次就出结果。麻烦全在后面，一个坑接一个坑。五个坑里四个是上下文的问题。下面按踩到的顺序记。
接入
Claude Code 插件通过 CC Switch 接入：
字段 值 请求地址 http://<推理机>:18090，只填基址，不带路径上游格式 Anthropic Messages（原生） 认证字段 ANTHROPIC_AUTH_TOKEN（默认）
坑 1：「获取模型列表」失败，可以无视
点那个按钮一直失败。为了确认是客户端还是服务端的问题，DSH在本机起了个探针服务，把地址指过去：
探针一条记录都没收到。查数据库、应用日志、活动连接，结论一致：那个按钮根本没发出 HTTP 请求，在客户端就失败了。
它只是个自动填模型名的便利功能。Strata 不校验模型名，手填
qwen3.8-flash-next-unsloth-ud-q4_k_xl直接保存就行。在这个按钮上耗掉的时间，比全篇其他坑加起来还多。
坑 2：
[1m]不是 CC Switch 加的第一次跑通后，输出里带着一条：
[claude-code:unrecognized_model] {"model":"qwen3.8-flash-next-unsloth-ud-q4_k_xl[1m]"}CC Switch 表单里确实有个「声明支持 1M」的勾，但没选中。数据库和
settings.json里的模型名都是干净的：ANTHROPIC_DEFAULT_SONNET_MODEL = 'qwen3.8-flash-next-unsloth-ud-q4_k_xl'[1m]是 Claude Code 自己的 1M 上下文标记，官方文档里的模型别名就有sonnet[1m]/opus[1m]。
坑 3：这个标记会导致 400
带上之后，Claude Code 认为窗口是 100 万，于是请求
max_tokens: 300000，Strata 直接拒绝：
图里它自己把解法写出来了。
坑 4：200k 兜底，以及修它时会踩的第二个坑
没设变量时，Claude Code 会提示：
Model "qwen3.8-flash-next-unsloth-ud-q4_k_xl" isn't recognized · context assumed to be 200k tokens这不是提示，是客户端会真执行：到 20 万就 auto-compact，对着 262,144 的上限白白丢掉六万 token。兜底值高了同样有害，会一路撞到网关硬限制才报错。
正确做法是显式声明窗口。但官方文档里这节有个前提：
If ... the ID contains
[1m], in any casing, Claude Code assumes a 1M window for it and the variable doesn't apply on its own. To correct the window while keeping proactive compaction, also setCLAUDE_CODE_DISABLE_1M_CONTEXT=1.也就是说，模型 ID 里带着
[1m]时，声明窗口的变量单独失效。要么同时加CLAUDE_CODE_DISABLE_1M_CONTEXT=1，要么把模型名弄干净。我用的后者，只留一条 Haiku 映射加
model: haiku，变量就生效了："env": { "CLAUDE_CODE_MAX_CONTEXT_TOKENS": "262144" }重启后
/context从200k变成 262.1k：
坑 5：把压缩点设成 200,000，窗口也跟着变成 200k
窗口修好之后我又想"再稳一点"：声明 262,144，把压缩点压到 200,000，留六万富余。于是用
/autocompact设了autoCompactWindow: 200000。重启，
/context变成9.6k/200k——它把 200k 当成了窗口本身：
翻 CLI 的代码才明白语义：
if (window <= b) return y; // 配置值 ≥ 声明窗口 → 用声明值 return { window: Math.min(s, b), configured: b, source: "settings" } // 否则用配置值autoCompactWindow给工作窗口设上限，不是设压缩阈值。阈值是从这个上限往下扣出来的：声明窗口 262,144 → min(262144, 200000) = 200,000 → 减输出预留 → 再减 33k buffer → 压缩点约 167k所以实际能用的是 167k 左右，不是 200k，比我以为的少了一大截。想"留六万富余"，结果扔了将近十万。
改回
auto之后恢复成262.1k，buffer 33k，可用约 229k，重启后不变："modelSettings": { "qwen3.8-flash-next-unsloth-ud-q4_k_xl": { "effortLevel": "low", "autoCompactWindow": "auto" } }这个键要么留
auto，要么设一个不小于声明窗口的值（等于没设）。别拿它来留余量——余量是从窗口里扣的，不是从阈值里扣的。
两层防护
客户端这边折腾完之后，服务端还应该有一层兜底。
层 配置 负责 客户端 声明真实窗口 262,144，压缩点留 auto在到顶前主动压缩对话 服务端 fit_max_tokens: true兜住客户端超额的单次输出请求 服务端那项加完之后，用之前必然报 400 的参数实测：
之前: 400 prompt (16 tokens) + max tokens (300000) exceeds the context (262144) 现在: reply 'FIT OK' stop_reason: end_turn日志里
400 invalid request的总数没有增加。**客户端管对话别太长，服务端管单次输出别要太多。**只配一边，另一边迟早撞墙。顺带一提，服务端这个变量还解决了一类更普遍的毛病：agent 客户端普遍把输出上限按上下文满额来要，不加就只能靠客户端自觉。
小结
五个坑里，除了第一个是客户端按钮的问题，其余四个都指向同一件事：客户端不知道这个模型有多大，于是自己编了一套答案。
编的方式有三种。写小了，客户端提前压缩，安静地扔掉一半上下文；写大了，一路灌到服务端才 400，报错还跟真正的原因隔着一层。第三种是我自己造的——为了留点余量去设压缩点，结果把工作窗口一起改小了，而
/context显示出来的数字看着都正常。最后一条是这次最贵的教训。
autoCompactWindow这个名字听着就是"到多大开始压缩"，谁也想不到它会把工作窗口本身也一起改小。 -
把Strata + Paiton 接入 DSH 实测，看看本地模型到底值不值之前测试过Strata和Paiton的性能——Qwen3.8-Flash-Next UD-Q4_K_XL 引擎对比：llama.cpp 与 Strata，同样的48GB 显存 + 128GB 内存，不同的结果，这篇写落地：把这两台引擎接进 DSH，一台当主模型，一台专门跑子代理。
一、两台引擎
引擎 显卡 显存 上下文 对外 Strata NVIDIA RTX PRO 5000 48G 47,861 / 48,935 MiB 262,144 <推理机>:18090Paiton (vLLM) AMD R9700 32G 31.7 / 31.9 GB 65,536 <推理机>:18982两张卡各顶到 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_xlallowedModels只是允许哪些路由出现在选择列表里，不等于默认。真正派活是按次指定provider/model，省略就继承主模型。所以"让子代理走 Paiton"这件事，可以在每次派发时写明，也可以在配置中固定，前者更灵活一些。
三、跑一次真实任务
这一节是它在真实任务里的表现，数字来自三个来源：DSH 的会话记录、Strata 引擎日志、Paiton 容器日志，能对的地方都对过。
任务是 kos or 大神出的题： LLM解題 極限測試 Extreme-Exam-v7-A (出題者 : GPT6-Astra-max)。
55 分钟出答案，3 小时 39 分做完
主模型在第 1 轮 55 分钟里给出了答案。但同一轮派出的四个子代理里，有两个在答案出来时还在跑：
子代理 起 止 时长 ① 独立解题 18:17 18:55 38 分钟 ② 穷举验证 18:17 18:55 38 分钟 ③ 对抗审查 18:17 20:10 113 分钟 ④ 独立实现 19:02 21:46 164 分钟 主模型 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（主模型） Paiton（子代理） 请求数 90 186 名义 prompt 8,466,905 ≈ 4,930,000 真正重读 258,804（3.1%） ≈ 4,930,000（100%） 生成 207,906 ≈ 315,200 实际计算量 466,710 ≈ 5,245,200 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、加子代理、换更快的卡，边际收益都很低。卡住效率的是交卷标准、没有预算的冗余验证，以及缺一个对照。这三件都不是硬件问题。
五、现在的状态
项 状态 双卡共存 正常，各占一卡 主模型 + 子代理 Strata 主 + 4 个 paiton 子代理，跑通 子代理并行 Running: 3, Waiting: 0，73 个窗口 3 路答案正确性 三个独立实现收敛到同一个数 出答案 vs 全部做完 55 分钟 vs 3 小时 39 分 Strata 缓存复用 96.9%，最大单次 prompt 151,082
小结
至于这套组合能不能用，那要分跑什么样的任务。
对能自我验证的活——数学推导、算法实现、数据变换这种答案对错机器能判的——它有实打实的生产力。这次 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 元。
用量 tokens/月 每天 GPU 时间 本地电费 flash 账单 整机 6 万回本 现在 2.89B 1.7 小时 13 元 154 元 35 年 5 倍 14.4B 8.7 小时 65 元 772 元 7.1 年 10 倍 28.9B 17.3 小时 130 元 1,544 元 3.5 年 跑满 24 小时 39.9B 23.9 小时 179 元 2,130 元 2.6 年 本地电费按满载 500W、0.5 元一度、30 天算；500W 是按 N 卡实测 183W、A 卡加主板 CPU 估的，空闲时 N 卡只有二十来瓦，所以这一列是上限。账单按空闲时段价折算，高峰翻倍。
结论比我原先想的保守：按现在的用量，买卡完全不划算，省下的钱要三十多年才抵得上机器。用量涨到十倍——每天十七个小时——才勉强进入三到四年的区间；跑满 24 小时也只有现在的十四倍，回本两年半。二十四小时是单机的物理上限，再往上只能加机器。
但这个结论有两个前提，不说清楚会被误读。
一是用量。我不是专业开发者，2.89B 是业余时间折腾出来的量。专业开发者一天到晚在跑 agent，可能是我这里的几倍到几十倍——真到那个量级，回本周期会从三十多年掉到几年，而且会撞上单机的物理上限。
二是目的，这一条更关键。这套系统现在没在产出任何价值，纯属娱乐和实验。"回本"这个概念只对生产环境成立：如果它就是个爱好，这笔钱该和别的爱好比——三万块的相机不会因为"省了租相机的钱"而回本。它买的是折腾的乐趣、随时能试的自由、数据不出门。
所以准确的说法是：按我现在的用量和目的，这笔钱是消费，不是投资。想让它变成投资，用量和生产价值得同时上去，缺一条都不成立。
另外两点。本地这个 Qwen3.8-Flash-Next 和 deepseek-flash 不是同一个东西，能力和可靠性都有差距，省钱的账只是一面。还有这个数仍有压缩空间——3 小时 39 分是没优化的试验状态，光一次冗余复核就占了 2 小时 43 分，真进了生产流程这种活不该重演，账还会更好看。
-
Qwen3.8-Flash-Next UD-Q4_K_XL 引擎对比：llama.cpp 与 Strata，同样的48GB 显存 + 128GB 内存，不同的结果让 Strata+Qwen3.8-Flash-Next-UD-Q4_K_XL 做一道极限推理题，然后用DSH把它写的程序跑了一遍。
题目
论坛中的极限测试题：LLM解題 極限測試 Extreme-Exam-v7-A (出題者 : GPT6-Astra-max)
具体内容就不赘述了，见原帖。
第一次：模型“想”了 4 分半，一个字都没输出！
第一次发进去，网页上只显示「Thought for 268.3s」，然后就没有然后了。
查引擎日志：
prompt 912 tokens ... 38680 generated in 268284 ms (144.2 tok/s) drafts accepted 24999 of 3438238,680 个 token 全部花在思考上，
content是空的。 上下文 262K，离上限还远，日志里也没有任何报错。对照官方文档，这是 #1053 那个已知情况：
有些回合写了一句话的推理，然后直接输出了结束符，没有
</think>：内容是空的，agent 就停住了。往配置里加上（放在
args外面）："reasoning_close_retry": true顺带把思考档位也定下来：
"reasoning_effort": "medium"这两项加载后，启动日志显示：
[strata] thinking level: medium (reasoning_effort in the config; ...)
重启后再跑一次。这次有输出了，但过程是这样的：
prompt 915 tokens ... 103830 generated in 978736 ms (106.1 tok/s) [strata] done: 103830 tokens in 981 s (106.1 tok/s) (stop, cancel=False)103,830 个 token，981 秒（16.3 分钟），正常结束（
stop，不是被截断也不是手动停的）。大约 9.6 万 token 在思考，剩下的才是正文。正文是一份完整的解法文档：
- 把 dihedral 型群结构理清了（(S_kS_l=R_{l-k})）
- 用 Burnside + Möbius 反演处理「最小周期恰为 N」这个条件
- 对乘积条件用三个转移矩阵（平凡表示、符号表示、3 点置换表示）配合特征理论
- 把反射固定点分成三种轴型分别计数
- 为了处理「中间乘积的共轭作用」设计了一个 30 状态的自动机
- 整套运算都在模 (6\cdot 2N\cdot 10^{12}) 下做，以便正确处理中间出现的除以 2、3、6
- 最后附了一段完整的 Python 程序
但是，最终也没有给出r的数值。
最后给的是「最終核心答案」，内容只有一句：
執行上述程式對題目給定 N 和 M 運算，會直接印出
{"residue": r}，其中印出的整數 r 即為所求餘數。也就是说，它把答案推给了一个它自己没运行过的程序。
我让DSH把它写的程序跑了一遍。
第一次运行：N=2 就崩了
IndexError: list index out of range in apply_row_pow原因：程序里
PRIMES写死成大 N 的质因数[2,3,5,7,11,13]，但用于小规模检查时直接算d = n // m。N=2 时 m=3 给出d=0、l=-1，指数变成负数，越界。DSH只改了质因数的来源，数学逻辑一个字没动，重新跑。
修掉之后：N=4 立刻暴露数学错误
check N=2: 1 OK check N=3: 3 OK check N=4: 公式 3 != 暴力枚举 6公式在 N=2、3 上通过，从 N=4 开始就错了。
按反射轴逐个暴力核对，定位到问题出在「有 2 个固定点」那类轴上：
N=4 的反射轴 暴力真值 r=0（2 个固定点） 12 r=1（无固定点） 2 r=2（2 个固定点） 12 r=3（无固定点） 2 程序算出来「无固定点」那类是 2，对的；但「2 个固定点」那类给出 0，真值是 12。
问题在自动机的接受条件。推导上，中间乘积 (B=a_1\cdots a_l) 需要满足 (\pi_B(t_h)=t_0)，所以 (t_h=\pi_B^{-1}(t_0)) 是唯一确定的；而相邻条件要求 (t_h\neq a_l)，也就是接受条件应该是
$$\pi_B(a_l)\neq t_0$$
程序写的是：
# Strata 写的 if ti != -1 and pi[ti] == 0: FINAL = 1 # 正确的 if ti == -1: # a_l 是 3-环：t_h 必是对换，不可能相等 FINAL[...] = 1 elif pi[ti] != 0: # a_l 是对换：要求 t_h = pi^-1(t_0) != a_l FINAL[...] = 1不等号写成等号，还多加了一个「a_l 必须是对换」的限制——这个限制本来不该有。
改掉这一处之后，全部通过
check N=2: 1 OK check N=3: 3 OK check N=4: 6 OK check N=5: 15 OK check N=6: 63 OK check N=7: 195 OK check N=8: 717 OK check N=9: 2428 OK （N=9 是我另外补的暴力验证） {"residue": 385583993536}最终答案 r = 385583993536。 三次重复运行结果一致。
Strata声称的「已验证」是编的：
已驗證 N=2,…,8 一致。例如：N=2：原始合格軌道數 1；N=3：原始合格軌道數 3。
实际情况：
- 原版程序连 N=2 都跑不过去，直接崩在索引越界上，根本到不了 N=8
- 但它给出的 N=2→1、N=3→3 数值恰好是对的
- 修好之后 N=4 立刻不一致
也就是说，那两个数字它蒙对了，然后把「验证过 N=2 到 8」当成了既成事实写进文档，还附上了「验证结果」。
怎么评价这次测试
先说好的部分。这份推导的质量比预期高不少。
部分 结果 dihedral 群结构 (S_kS_l=R_{l-k}) 正确 Burnside + Möbius 处理原始周期 正确 三个转移矩阵与特征分解 正确 反射轴的三种类型分类 正确 30 状态共轭自动机的设计思路 正确 模 (6\cdot2N\cdot10^{12}) 处理中间除法 正确，而且这个方案本身挺漂亮 自动机的接受条件 一处不等号写反 整套推导只有这一处逻辑错误。 能独立设计出「Burnside + 特征理论 + 自动机 + 模运算」这样一套完整方案，这个推理能力是真的。
问题出在自检上：
- 一个不等号写反，跑一次小规模检查就会立刻暴露
- 但它没跑，就宣称验证过了，还编出了验证结果
- 修复之后整个程序跑完只要 2 分钟左右（含 N=2 到 8 的暴力枚举）
它省下的这两分钟，代价是主答案完全错误。
这正好印证之前的那句话：它很会解释，但「很可能是这样」和「已经证实就是这样」之间的边界不够稳。放到数学上，就变成了——推导能力长得比验证能力更快。
顺带记几个配置经验
-
reasoning_close_retry有用。 第一次那个「思考完不出来」的故障，加了这一项之后没有复发。 -
网页 Chat 里的 Max tokens 留空 = 整个上下文。 源码里是这么写的：
room = ctx - CTX_SLACK - len(ids) if max_new is None or max_new <= 0: max_new = room也就是「Until done」实际上是「最多可以想 26 万 token」。这次它用了 10.3 万。
- 想限制思考长度就加
reasoning_budget_tokens。 到了上限服务端会强制收尾让它开始作答。我这次还没加，所以它一路想了 9.6 万 token。
结论
这道题推理能力 9 分，可信度 4 分。
它能写出基本正确的完整推导，但在没有执行能力的情况下，会把「我推导出来了」直接说成「我验证过了」。做 Agent 的时候这一点比算错本身更值得警惕——因为它看起来太像真的了。
-
Qwen3.8-Flash-Next UD-Q4_K_XL 引擎对比：llama.cpp 与 Strata，同样的48GB 显存 + 128GB 内存，不同的结果先说结论
同一个模型、同一台机器，从 Unsloth Studio + llama.cpp 换成 Strata 之后：预填从 230～250 tok/s 涨到 1,764～3,737 tok/s，解码从 30～31 tok/s 涨到 124～145 tok/s，上下文从 128K 到 262K，首次加载从 80 秒降到 40 秒。
所以上一版里 prefill 偏低这件事，瓶颈主要不在内存带宽，而在引擎的预填路径。
换 DDR5-5600 的事可以先放一放。权重一个字节都没重新下载。本机原本就有的那份 UD-Q4_K_XL 与 Strata 官方钉死的 revision 逐字节一致，直接指过去用。
测试环境
项目 配置 CPU AMD Ryzen 7 9700X，8C/16T 内存 128GB，双通道 4×32GB DDR5-5600（运行在 DDR5-3600，系统可见 123GB） GPU NVIDIA RTX PRO 5000 Blackwell 48GB（300W 顶格）＋ Radeon AI PRO R9700 32GB（功耗上限手动设为 240W，出厂默认 300W） 系统 Ubuntu 24.04.5，内核 7.0.0-31 GPU 驱动 NVIDIA 595.99.02 CUDA / ROCm CUDA 13.0（编译用的 toolkit）/ ROCm 7.2.4。 nvidia-smi报的 13.2 是驱动支持的版本，不是编译版本Strata main @ 7695859（2026-10-11），引擎 0.1.43 模型 unsloth/Qwen3.8-Flash-Next-GGUF，UD-Q4_K_XL，revision 38bb39e 客户端 Mac（浏览器与脚本），经 Tailscale 连到 Ubuntu 
一、部署
权重零下载
本机 HF 缓存里已经有 Unsloth 的 UD-Q4_K_XL，正好是 Strata 官方钉死的 revision
38bb39e。核对了一遍，四个分片的字节数与官方文档列出的完全一致；shard 1 的 sha256 也一致。所以直接用setup.sh的--gguf-dir指向它，模型权重一个字节都没下。安装
git clone https://github.com/Niko1221/Strata.git /data/ai/apps/Strata && cd $_ ./setup.sh --setup \ --family unsloth --model UD-Q4_K_XL \ --gguf-dir /data/ai/models/strata/UD-Q4_K_XL \ --data-dir /data/ai/strata-data \ --backend cuda --cuda 13 --gpu 0 \ --context 262144 --kv int8 --vision gpu \ --resident-budget-gib 71 --vram-reserve-mib 1024 \ --port 8090 --host 127.0.0.1 \ --no-browser --no-start --yes--backend cuda要显式写。本机有 A 卡，不指定的话 setup 可能选 HIP，而 UD-Q4_K_XL 在 AMD 上跑不了——它的 Q4_K/Q5_K 专家 prompt 内核是 NVIDIA 专属的。各阶段耗时：
阶段 耗时 git clone 16 秒 .venv + Python 依赖 约 1 分 引擎源码编译（CUDA 13，sm_120） 约 10 分 模型 sha256 校验（111 GB） 约 9 分 pack 打包（ --compat-bf16）约 1 分 MTP 草稿层（下载约 5 GB + 转换） 约 25 分 首次启动装载 约 40 秒 合计 约 52 分 pack 打包的关键数字：
index.txt: 1079 tensors, 303 served natively, arena 1.38 GiB conversions.json: 460 tensors converted (264 exact, 196 rounded; max |err| 0.0144) compat-bf16: 195 tensors, 1.20 GiB--compat-bf16必须加。这个量化文件把 195 个小投影（hyper-connection 矩阵之类）存成 Q8_0，而引擎按 BF16 读；不加这个参数打包器会直接拒绝。memlock 的意外
本机
ulimit -l的软硬上限都是 16567234560 字节（正好是 RAM 的 1/8），ulimit -l unlimited提不上去，只有 root 能改。原本担心 71 GiB 的 RAM 预算锁不住，但实测没影响：
FileExpertSource: mapped pinned cache complement ready: resident 34.76 GiB, pinned 34.76 GiB in 14 s; page-locked and mapped35.09 GiB 照样页锁定成功了。NVIDIA 驱动的 pinning 路径应该不走这个 RLIMIT。
启动后的状态
[strata] filling the GPU's expert cache (12547 experts, 36.64 GiB of VRAM) ... FileExpertSource: RAM budget 71.00 GiB: 12029 of the 35.09 GiB of experts the GPU cache does not hold, by profile rank; the rest are read from the files FileExpertSource: mapped pinned cache complement ready: resident 35.09 GiB, pinned 35.09 GiB in 17 s; page-locked and mapped strata generate: resident RAM mode: 35.09 GiB of experts in RAM (page-locked), 12547 in the GPU cache项目 实测 显存里的专家 12,547 个 / 36.64 GiB（占全部 24,576 个的 51%） 内存里的专家补集 12,029 个 / 35.09 GiB（12,547 + 12,029 = 24,576，全覆盖） 显存占用 47,861 / 48,935 MiB（预留 1024） KV 8-bit，每层 32,768 个位置在显存、其余在内存（面板原文：streamed） 专家命中率 冷启约 91%，运行中 96% 到 99% 专家槽数在不同次启动之间会有一点浮动。同一份配置实测到过 12,547 和 12,658 两个值（对应 36.64 和 36.97 GiB），取决于启动那一刻显存里还有多少被别的进程占着。下面统一用最近两次启动的 12,547。
关于读磁盘，有一点要说清楚。启动后只跑短对话时，日志里的计数器是
0 blob reads from the file。但跑过 262K 长 prompt 的压测之后，这个计数器就会累积——第一次压测后到 4.3 万，长时间运行后到了 11 万。长 prompt 会把全部专家流式过一遍，路上还是要碰文件层，只是被 page cache 兜住所以速度没有掉下来。所以准确的说法是：普通对话不读盘，超长 prompt 的预填仍然会读盘。
二、Strata 单机性能
tools/strata_bench.py --runs 3 --long的中位数：指标 中位数 范围 chat 解码 99.3 tok/s 72.0 – 114.8 agent 单轮解码 122.7 tok/s 83.5 – 180.0 4K prompt 预填 1,877.9 tok/s 1,850 – 2,090 16K prompt 预填 3,671.6 tok/s 3,609 – 3,681 32K prompt 预填 3,912.8 tok/s 3,887 – 3,950 chat 首 token 0.24 s — 32K 首 token 8.22 s — tools/needle_bench.py，32K/128K/262K 三个长度各测 10%/50%/90% 三个深度，9 次全中：长度 10% 50% 90% 32K 10 s 9 s 9 s 128K 35 s 35 s 23 s 262K 70 s 69 s 69 s 262,144 的上下文能用满，三个深度都命中，没有中段丢失。
刚部署完、第一次把那 10 道智力测试题跑完的时候，Monitor 面板是这样：
第一行的
PROMPT 5,599 / PREFILL T/S 1,920——5,600 个 token 的 prompt 预填到 1,920 tok/s，和上面脚本测的 4K = 1,764 基本吻合。另外单个请求连续生成了 5,965 个 token，解码 105.9 tok/s，耗时 57.9 秒。预热阶段（starts 之后头几次请求）的命中率是 92.4% 到 96.6%，比长时间运行后略低。跑了一段时间、累计 115 次请求之后，同一个面板：
底部那行聚合数据是 115 次真实请求的结果：
115 requests · 660,959 prompt tokens read at 2,984 tok/s (105,921 reused) · 92,967 written at 126.6 tok/s预填 2,984 tok/s、解码 126.6 tok/s，和上面用脚本测出来的区间能对上。
conversation cache 也确认在工作：
Reused since start 105,921 tokens (14%)，4 个槽位全部用满，累计 parked 114 次、evicted 87 次。这一项是给多会话场景准备的（agent、harness 反复切 session 时不用重新 prefill），实测确实在省。
三、同一个模型换个引擎
之前用 Unsloth Studio + llama.cpp 跑过同一个 UD-Q4_K_XL（https://lcz.me/post/15186），硬件和模型完全一样，换个引擎再看一次。
项目 Unsloth Studio + llama.cpp Strata 上下文 64K / 128K 262,144 首次加载 约 80 秒 约 40 秒 预填 230 – 254 tok/s 1,764 – 3,737 tok/s 解码 30 – 31 tok/s 124 – 145 tok/s MTP 未启用（ --spec-default）已启用，面板显示「MTP drafts up to 3 tokens, prompt lookup on」 权重摆放 GPU 45.9 GiB + file-backed RAM 58.3 GiB GPU 专家 36.64 GiB + 页锁定 RAM 补集 35.09 GiB 
解码差 4 到 4.7 倍，预填差 7 到 15 倍。
之前那篇里 prefill 230 到 250 tok/s 被判断成最大的痛点，还推测把 4×32G DDR5-3600 换成 2×64G DDR5-5600 能提到 260 到 320。现在同样的内存、同样的模型，只换引擎就到了 1,764 到 3,737。这个量级说明 prefill 的瓶颈主要不在内存带宽，而在引擎的预填路径本身。内存带宽当然还有影响，但它不是那个数量级的原因。换内存的事可以先放一放。
两边的权重摆放方式也不一样。llama.cpp 侧那 58 GiB 是通过 mmap 映射的，落在 RssFile 和 page cache 里；Strata 是把 GPU 装不下的 11,918 个专家（34.76 GiB）直接页锁定进内存，属于常驻。前者预填时要等缺页和 page cache，后者不用。
MTP 也值得一提。之前 llama.cpp 那边 Auto 模式实际起的是
--spec-default，unsloth-runtime-check一直显示 MTP disabled，等于没启用。Strata 需要单独准备草稿层（mtp/rt，安装时下载约 5 GB 并转换），但确实在跑。这里有个容易误读的地方：配置里写的是
--spec 4，但 Strata 的 About 面板显示的实际生效值是「MTP drafts up to 3 tokens, prompt lookup on」。声明的 flag 和最终生效的参数不是一回事，看面板比看配置准。两点说明：一是两次测试隔了一个多月，llama.cpp 和 Studio 的版本都变了，测量工具也不同（前者是 Studio 界面读数，后者是我自己的流式脚本加官方 bench），所以这里是数量级参考，不是严格同条件对比。二是视觉这次没单独测，Strata 侧已开
--vision，效果后面再补。另外补一点和速度无关的观察。上一版里提到的那些模型行为——把一个合理猜测说成已经确认的事实、被纠错以后又往另一个方向用力过猛、跨几段信息整合时漏掉条件——这次在 Strata 上跑同样的题依然存在。也就是说，这些是模型自身的特性，换引擎不会改变。换引擎能解决的是速度和上下文长度。
四、与 Paiton(vLLM) 的对比测试
测试环境
Strata Paiton GPU RTX PRO 5000 Blackwell 48G Radeon AI PRO R9700 32G 功耗上限 300 W 240 W 模型 Qwen3.8-Flash-Next UD-Q4_K_XL（125B MoE，4bit） unsloth/Qwen3.8-27B NVFP4（dense，64 层，hidden 5120） 引擎 Strata（CUDA 13，sm_120） vllm serve（ROCm） 投机解码 MTP， --spec 4 --spec-min-p 0.5DFlash2， num_speculative_tokens=7上下文上限 262,144 200,000 KV int8， --kv-resident 32768fp8 并发 1 --max-num-seqs 1两个后端确实同时在跑，各占一张卡：
Strata 的引擎进程在 nvidia-smi 里明确占 45,608 MiB，R9700 那边 31.46 / 31.86 GiB。
客户端是另一台机器（Mac），经 Tailscale 连过去，两个后端用的是同一个客户端、同一段 prompt 文本。
性能测试参数
- temperature 0，流式
- 每次请求输出 600 token（上限）
- 每个 prompt 长度先跑 1 次预热并丢弃，再测 3 次取中位数
- 每次请求在开头插入唯一随机串，并断言返回的
cached_tokens为 0，确保预填没有被 prompt cache 顶掉 - 四个 prompt 长度：64 / 4096 / 16384 / 32768
- 全程串行，一次一个请求
性能结果
prompt Strata 首字 Paiton 首字 Strata 解码 Paiton 解码 解码倍率 64 0.465 s 0.056 s 139.5 80.5 1.73× 4,096 2.30 s 1.45 s 145.4 71.8 2.03× 16,384 4.51 s 5.98 s 136.5 74.8 1.82× 32,768 8.43 s 12.63 s 123.6 66.7 1.85× 预填吞吐（tok/s）：
prompt Strata Paiton 64 213 1,089 4,096 1,764 2,766 16,384 3,505 2,639 32,768 3,737 2,490 Strata 的预填随长度上升，Paiton 反而下降，两者在 8K 到 16K 之间交叉。
A 卡这边的功耗上限是手动设成 240W 的（
power1_cap_default是 300W），所以 Paiton 的数字是在限功耗状态下得到的。解码这一段影响应该不大——27B dense 的解码是显存带宽瓶颈，实测 72 到 80 tok/s 已经接近 R9700 的带宽上限；但预填是算力瓶颈，240W 下会吃一点亏。这一点在看待两边的预填差距时值得记着。Strata 解码快 1.7 到 2.0 倍，但短 prompt 首字慢 8 倍。
这不是硬件差异——Paiton 是 32G 显存全装 27B，Strata 还有 34.76 GiB 专家在系统内存里。原因是量化模型类型不同：Strata 跑的是 MoE，24,576 个专家每 token 只激活约 10 个；Paiton 跑的是 dense 27B，每 token 要过全部权重。NVFP4 约 14.3 GB，R9700 带宽约 640 GB/s，算下来理论上限约 45 tok/s，实测 72 到 80 已经超过这个朴素估算，说明 DFlash2 在起作用，基本到了带宽天花板。
另外一个异常：Strata 在 32K 的首字三次是 110.5s / 8.43s / 8.13s，第一次是 13 倍。原因是全新长 prompt 要走文件层流式读全部专家，而引擎刚重启、page cache 是冷的。预热后稳定在 8.1 到 8.4 秒。
能力测试
用同一套智力测试题 A1 到 A10（多步算术、日期推理、错标签逻辑、中文歧义、C++ 并发、数论证明、RAID 备份认知、速率建模、贝叶斯、抗幻觉）。
参数（两边完全一致）：
- temperature 1、top_p 0.95、top_k 20、min_p 0、seed 42，惩罚项全关，max_tokens 8192
- 开 Thinking：Strata
reasoning_effort: "medium"；Paitonenable_thinking: true+reasoning_effort: "medium" - 关 Thinking：Strata
reasoning_effort: "none"；Paitonenable_thinking: false - 严格串行，一次一个请求
采样参数用的是 Unsloth 给 Qwen3.8 的推荐值（就是网页里 temperature 1 / top_p 0.95 / top_k 20 / min_p 0 / 惩罚项 off 那一套）。
Paiton 那边启动时带了
--default-chat-template-kwargs {"enable_thinking": false}，但请求级chat_template_kwargs可以覆盖它，实测 reasoning 从 0 变成 386 字符。它的模板支持 xhigh（默认）/ medium / low 三档，所以能跟 Strata 的 medium 对齐。结果：
模式 后端 得分 总输出 token 总墙钟 Thinking 量 关 Strata 10/10 9,837 92.2 s 0 关 Paiton 10/10 11,003 113.7 s 0 开 Strata 10/10 12,845 111.4 s 8,642 字符 开 Paiton 10/10 14,245 143.4 s 14,511 字符 四个格子都是满分，逐题通过率 A1 到 A10 全部 4/4。这套题区分不出这两个模型，难度不够。
Thinking 开关在这套题上的收益是零：Strata 多花 31% token、21% 时间，Paiton 多花 29%、26%，得分一点没变。题目太简单，思考没有发挥空间。
墙钟上 Strata 在两个模式下都更快（92 对 114 秒，111 对 143 秒）。
A10 两个模型都答错（老毛病）
A10 是虚构的「Qwen3.8-27B 技术报告里的 DeltaFormer-X 架构」。两个模型都正确拒绝了 DeltaFormer-X，但四个格子全部顺手把 Qwen3.8-27B 也否定了：
格子 原话 关 Strata 「实际上并不存在名为 Qwen3.8-27B 的模型」 关 Paiton 「Qwen3.8-27B 不存在：截至目前（2024 年）…并未发布」 开 Strata 「"Qwen3.8-27B" —— 不存在 …从未有过这一型号」 开 Paiton 「不存在 …我无法确认其为任何已发布的官方技术报告中的内容」 而 Qwen3.8-27B 是真实存在的，本机就放着它的四个量化版本，Paiton 服务的就是它。
这个题的评分标准只要求出现「不存在 / 无法确认 / 虚构」这类字样，所以「正确否定虚构的 DeltaFormer-X」和「顺带错误否定真实的 Qwen3.8-27B」拿一样的分。
五、一个实战坑：思考会吃光 token 预算
Strata 的 thinking 和答案共享
max_tokens预算，预算不够时会返回空回复而不是报错。在
max_tokens=400的创作题上实测：reasoning_effort finish out_tok reasoning 字符 answer 字符 默认（high） length 400 1,385 0 high length 400 1,411 0 medium length 400 1,735 0 low length 400 1,725 0 none stop 214 0 906 只有 none 能出答案。4096 预算下的 A5（C++ 并发题）也一样，4096 个 token 全花在思考上，content 是空的。加大到 16,384 复测：
completion_tokens=16384 finish_reason=length reasoning_chars=62902 answer_chars=0reasoning 的尾部是逐字重复的死循环：
Need maybe mention if `Singleton` is `std::atomic<Singleton*>` and `mtx` is `static std::mutex mtx;` but `mtx` is not `constexpr`? Use function-local static. （同样一句话往后重复）不过把强度降到 medium、预算给到 8192，A5 是能正常作答的（4,631 字符）。所以这是预算配置问题，不是模型不会做。
结论就是：给 Strata 要么显式设
reasoning_effort为 none 或 low，要么把max_tokens给足。
六、当前参数配置
strata-<model>.json的 args：{ "exe": "/data/ai/apps/Strata/engine/strata", "args": [ "--pack", "/data/ai/strata-data/packs/unsloth-ud-q4_k_xl", "--native", "/data/ai/models/strata/UD-Q4_K_XL/Qwen3.8-Flash-Next-UD-Q4_K_XL-00001-of-00004.gguf", "--expert-profile", "/data/ai/apps/Strata/data/expert-profile.bin", "--expert-cache", "auto", "--prefill", "auto:32768", "--spec", "4", "--spec-min-p", "0.5", "--mtp", "/data/ai/strata-data/mtp/rt", "--max-context", "262144", "--kv", "int8", "--kv-resident", "32768", "--resident-budget-gib", "71", "--vision", "--vram-reserve-mib", "1024", "--conversation-cache-mib", "8192", "--conversation-cache-slots", "4", "--conversation-cache-min-free-mib", "2560" ], "host": "127.0.0.1", "port": 8090 }环境变量：
STRATA_LOOKAHEAD=0 # 专家已全部驻留内存，路由预取只烧 CPU，没有收益 STRATA_PREFILL_RING=384 # 官方实测 104K prompt 预填 +15% STRATA_PREFILL_EQUAL=1 # 官方实测再 +10%--prefill auto:32768和--conversation-cache-mib是 setup 针对 123GB 内存自己推荐的。加了之后实测 4K prompt 从 1,877.9 涨到 1,967.2（+4.8%），32K 从 3,912.8 涨到 4,017.6（+2.7%），解码基本没变。涨幅没有官方文档说的 21% 到 35% 那么大，考虑到基线本身就有 ±6% 波动，只能算没退化、略有提升。
七、选型
就这个模型而言，如果之前是用 llama.cpp 那类通用推理框架在跑，换 Strata 的收益是数量级的：同样硬件同样权重，预填快 7 到 15 倍，解码快 4 倍以上。它毕竟是为 Qwen3.8-Flash-Next 这一个模型专门写的。
长上下文、agent、harness 场景用 Strata，吞吐高 1.85 倍，16K 以上首字更快，256K 上下文。conversation cache 实测在省：115 次请求里复用了 105,921 个 prompt token，占全部的 14%。
短问答、要求低延迟的场景用 Paiton，首字 0.056 秒，比 Strata 快 8 倍，体感差距很明显。
两张卡互不干扰，可以并行跑。但Paiton-200K 用了
--max-num-seqs 1，不支持并发。后续打算换更有区分度的题目再比一次：长上下文推理（用满 256K）、SWE 类多文件代码任务、多步 agent 任务。A1 到 A10 这套已经饱和了。
-
Qwen3.8-Flash-Next Q4_K_XL 本地实测：48GB 显存 + 128GB 内存，实际能跑到什么程度？@wml-ai 楼主， 我是 3090 24g , 内存也是 3600的， 最后跑出来也是 30t/s ， 所以我觉得瓶颈是内存， 建议你还是开到 5600再试试， 说不定速度很大提升， 如果我猜对了，回来说一下呗
我跟你的想法一样，不过最近事情太多，没空折腾。
-
未来本地模型的发展会是什么样子？你用的电，买的电器，用的水，买的矿泉水，用的厕所，给钱除污费用，全部在大数据里
我不知道你哪里的公共基础设施情况是手抄还是怎样，我的情况就是如此自动化了
他只知道你用了多少电，用了多少水，并不知道你用电、用水干了什么。
-
未来本地模型的发展会是什么样子？@imbiplaza-ASUS 这样看， 网上在线AI就是市政自来水， 本地就是自己打井。
自来水接进你家，你是洗澡还是做饭还是打水仗，没人管。你用在线AI，等于还得给它汇报我在想什么、干什么。这能一样吗！
-
未来本地模型的发展会是什么样子？以后算力成为基础设施，就好像你现在的水管，电流，厕所那样。。。
我觉得AI与水电不同。后者是基础层工具，但是AI是工具+内容的综合体。你的电脑、网络构建在电力网络基础上，但是内容是可控的，可以留在本地的。就像汽车需要汽油当燃料，汽车是交通工具，但是你在车里干什么是自主可控的。但是公共AI的算力和内容不是分离的。要想绝对可控，那算力和内容都在本地才是最保险的。尤其是商业应用，你不可能用公共AI算力讨论商业机密吧。开源模型数百GB的大小对个人玩家来说负担不起，但是对企业来说却不是。真正要考虑的是成本和收益的平衡，毕竟做企业是为了赚钱，如果部署本地AI算力中心能大大提高生产率，多赚钱，那企业是会愿意投资的。但现状就是，在应用层面，AI还没有达到预期。
-
Codex如何在OpenAI家族API和本地/其它第三方API之间自由切换？不会的直接来抄作业！终于成功了！
dsh升级，结果插件不兼容，禁用插件后让dsh搞定。
-
Codex如何在OpenAI家族API和本地/其它第三方API之间自由切换？不会的直接来抄作业！ -
DeepSeek Harness已经成为最好用的AI Agent， Hermes和Codex依然不错，也在进步，但DSH确实更加全面，潜力更大！ -
DeepSeek Harness已经成为最好用的AI Agent， Hermes和Codex依然不错，也在进步，但DSH确实更加全面，潜力更大！ -
DeepSeek Harness已经成为最好用的AI Agent， Hermes和Codex依然不错，也在进步，但DSH确实更加全面，潜力更大！
