双卡RTX3090 + 256G内存 用Strata 跑orcarouter的QFN IQ4_XS 100t/s 256k 10月8日 冲150T/S
-
Strata 引擎深度拆解：125B MoE 跑进 2×3090 + EPYC，TG 80-130 t/s 的账本与架构笔记
硬件：EPYC 7B13 (64C/128T, Zen3) + 2×RTX 3090 24G + 247G DDR4-2133 八通道 + NVMe
模型：Qwen3.8-Flash-Next-Uncensored IQ4_XS（orcarouter 无审查微调，97.5G GGUF）
引擎：Strata v0.1.38（Niko1221/Strata）
实测体感：限制250W 及 1570MHZ核心，温度可压到60度以下，三风扇无噪音。TG 稳定 90-120 t/s，长文写作 80 t/s 左右，262K 满上下文，视觉可用10月8日升级后加参数: 150 t/s 是真的，而且日志里最高冲到 175.9 t/s。拉了全部引擎日志和 /metrics，归因分析如下：
你的 150+ 从哪来（三层叠加）
① 主因：pipeline-windows 2 生效了（双卡不再轮流干等）
0.1.39/0.1.40.1 时代层切分是“严格接力”——卡0算完传给卡1，每步有半个周期两张卡之一在空转（fork 作者实测“每张卡每步闲置过半”）。现在 --pipeline-windows 2 让卡0在卡1验证当前窗口时就开始算下一窗，空转时间被吃掉。你日志里整段稳态在 104-136 t/s 区间（旧基线 71-99），长答 9473 tok 跑出 124.6 t/s——这个稳态抬升就是流水线的贡献，+25~30%。② 助推：热点会话的专家缓存命中 94-97%
你 150+ 的那几段（160.5/160.4/165.2/175.9）全部是 2 秒短段 + 94%+ 命中 + PCIe 传导只占 2-3.5%——热会话里专家几乎全在双卡缓存里，miss 极少，流水线不用等 PCIe 搬运，MTP 猜测链也顺。命中率低的段落（88.4% 那条只有 106.7 t/s）反证了这个相关性。③ 波峰：MTP 接受率好的短段
短段（100-240 tok）样本小，若草稿层连中，单窗口提交多 token，瞬时速度就高——175.9 那条是典型的“波峰读数”。整段 MTP 接受率目前 68.5%，中规中矩。- 写“短段峰值 150-176，长答稳态 112-125”，别只报峰值——175.9 是 240 tok/4s 的短段，长文读者会自己复现不出来然后回帖质疑
- 对照基线：同机 IQ4_XS 旧版 71-99 t/s → +40~70%（比 fork 作者 IQ3_S 的 +50% 还好，可能因为你的 24G×2 显存缓存余量更大）
- 配置写清楚：0.1.40.3 + --pipeline-windows 2 --adapt-async 1 + IQ4_XS + 262K + 会话驻留缓存 64G/16 slots——尤其提 0.1.40.3 起 fork 能力已全进官方 main，不需要再装 fork
“更快的卡放最后（跑 output head + draft）”在 0.1.40 已是自动行为（server 按 SM×clock 自己排卡），你的双 3090 同型号无此差异——这也是你复现干净的加分项。
10月8日,速度已经很满意 了,后续就是打磨质量了(3D鹈鹕骑车用了8分钟写成,增加细节另花10分钟) :
打开后要等几十秒加载three.js
pelican.html一、先看账本：每一 GB 去了哪
显存账本（每卡 24G，几乎满配）
去向 大小 说明 专家缓存（热点专家） ~17.3 GiB/卡 6931/24576 个专家常驻 VRAM，随对话自适应换血 注意力/DeltaNet/QSA/KV 常驻窗 ~5 GiB/卡 KV 只驻留最近 32K（--kv-resident），更早的流式 MTP 草稿头 ~213 MiB 10.6 万 token 词表的投机草稿层 视觉编码器预留 ~1.4 GiB mmproj 投影 + ViT 激活 剩余 ~458 MiB 安全垫 双卡分工是层切分流水线（0-22 层 / 23-47 层），不是张量并行——不需要 NVLink/P2P，PCIe 3.0 x16 老平台一样跑。
内存账本（247G，进程 RSS 实测 ~97G）
去向 大小 说明 全部专家权重（pinned） ~61 GiB VRAM 装不下的 1.7 万个专家，CPU 在位计算 PLE n-gram 表（--ple-io ram 锁页） ~28.8 GiB 51B 参数的 lookup 表，锁进 RAM 免 SSD 抖动 KV 流式区（262K ctx） ~3.6 GiB 13.7KB/token，超 VRAM 窗口的部分 MTP 权重 + 运行时 + 杂项 ~4 GiB 关键认知：free 命令显示的 used 不含 PLE 锁页（mmap 页计入 Cached），看进程 RSS 才是真话。别被 70G 的假象骗了。
CPU 账本（64 物理核）
去向 核数 说明 专家池 worker 63 默认 = 全部物理核 - 宿主线程，decode 时每核吃满 99.9% 宿主循环 1 token 调度 + GPU 提交 SMT 兄弟线程 64 空闲（AVX2 内核吃满物理核就够了，开 SMT 反而抢带宽） "只用到一半 CPU"是 top 的错觉：物理核 64 个全在烧，SMT 线程闲着。如果能升级AVX-512的CPU，内核可以更快，但 Zen3 只有 AVX2——Engine 自带 iq_avx2.cpp 多 token 内核（实测 down 4.4 GB/s vs ggml 3.2，3-token 窗口 282us vs 414us），AVX2 用户不亏。
启动账本
冷启动 35 秒完成 61G 专家加载（~27 GiB/s，八通道 DDR4-2133 的理论带宽约 120GB/s，单线程顺序读能跑到 1/4 理论值已经很扎实）。
二、架构拆解：为什么它能"魔法打败魔法"
Flash-Next 是 125B 总参 / 6B 激活的 MoE：48 层 × 512 专家，每 token 只激活 10 个。这个结构就是为 Strata 量身定做的——激活稀疏性让"专家分家"成为可能：
1. 四级存储瀑布（核心思想：厨房台面与 pantry）
VRAM → 每 token 必经之路：注意力/DeltaNet/KV/草稿头 + 热点专家缓存（自适应学习你的对话习惯，命中率爬到 97-99%） RAM → 全部专家 pin 住。VRAM 没有的专家，CPU 就地计算——GPU 和 CPU 并行，互不等待 SSD → 28.8G PLE n-gram 表。每 token 只读几行（我们的环境 用 --ple-io ram 锁进内存后归零）每生成一个词：草稿头先猜 3-5 个 token → 一次前向验证全部 → 平均 2.4-3.2 token/步落袋。MTP 接受率实测 70-96%（代码类任务更高），这就是 80-100 t/s 的直接来源。
2. 双卡流水线而非张量并行
CUDA0 算 0-22 层，CUDA1 算 23-47 层，一个 verify window 只有一次卡间握手。对比 vLLM 的 TP=2：不需要 NCCL allreduce 高速互联，不需要双卡同频，两张卡各自干自己的层——这就是为什么 3090 这种 PCIe 老卡也能高效组队。
3. KV streaming：上下文免费扩容
VRAM 只留最近 32K 的 KV，历史部分放 pinned RAM 按需流式读。代价是 RAM ~13.7KB/token（262K 才 3.6G），换来的是显存让给专家缓存。官方数据：262K 上下文下这个设计让 Q2_0 从 50.9 提速到 62.6 t/s。 如果有需要还可用Yarn扩展到512K或 1M。
4. 自适应专家缓存
引擎按 expert profile（预训练统计的热度排名）初始摆放，运行中按你的实际对话持续换血——中文对话热起来的专家和写代码热起来的专家是两批人。实测命中率从 92.7% 爬到 99.2%，命中即免 CPU，这就是为什么跑得越久越快。
5. 为什么"感觉不到瓶颈"
decode 时的关键路径是：GPU 算缓存专家（~13ms）‖ CPU 算未命中专家（~75ms）‖（偶发）SSD 读 PLE 行。三条路并行，最长的那条决定速度。PLE 锁内存后，CPU 专家计算成为唯一长杆——而这正好吃满你的 CPU。
三、搭建路径（可复现）
硬件清单
- CPU：EPYC 7B13（谷歌定制，64C，Zen3）——CPU 越多 CPU-专家路径越快，核就是显存外的第二"算力池"
- 内存：247G DDR4-2133 八通道——容量 > 频率，八通道带宽是专家加载速度的保证
- GPU：2×3090 24G（不需要 NVLink！层切分不吃 P2P）
- 盘：NVMe（放 GGUF + PLE 表；PLE 锁内存后 SSD 只在启动时被读）
软件步骤
- 编译引擎（CUDA 12.9 + GCC15 的坑：必须 CUDAHOSTCXX/CMAKE_CUDA_HOST_COMPILER 双指定 g++-14）：
cmake -B build -DSTRATA_ENABLE_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=86 ... cmake --build build -j 48-
模型三条件（任何微调版能不能上，看这三条）：
- GGUF arch = qwen4exp（官方 GSQ-RCO 系或其微调）
- 每层专家不被分片切开（跨片要先 merge）
- 小投影转 BF16（第三方量化用
tools/iq_pack.py --compat-bf16打包，专家权重不动） - 格式兼容性别信文档，直接跑
./build/native_expert_parity <shard1> 0 2——0 failures 就能上（IQ4_XS 就是这么实测出来的，官方文档还说没验证）
-
打包 + 配置：
iq_pack.py生成 pack（index/dense/tokenizer，约 1.5G），配置 JSON 指定 pack/native/ple-gguf/MTP/层切分 -
服务：
python3 -m serve.server --engine strata --config xxx.json --port 8025，自带 Web Chat/Monitor/OpenAI API/Anthropic API/视觉（mmproj + strata-vision helper） -
三个必开参数：
--kv-resident 32768（KV streaming，长上下文提速 + 显存让位）--ple-io ram（PLE 表锁内存，decode 尾延迟稳）不开占用70G内存，开了占用105G左右--layer-split auto（双卡自动切层）
-
上下文三档热切换（本机的做法）：131K / 262K 原生 / 512K YaRN（--rope-scaling yarn --rope-scale 2.0），一个脚本管三档配置，切换时同步 new-api 元数据
踩坑速查
https://huggingface.co/orcarouter/Qwen3.8-Flash-Next-Uncensored-GGUF/tree/main 模型下载地址，考虑到CPU性能，我下载的是IQ4_XS，相对IQ3，质量稍好。
- hf 下载 >50G 文件报 hf_xet → aria2c 直拉 resolve 链接
- gated repo 要 HF 授权 + token，hf-mirror 对 lfs.oid 打码 → 手动 SHA256 不可用，用 hf 幂等重跑验证完整性
- new-api 建渠道要三件套：channels + abilities + models（缺 abilities 503，缺 models 前端上下文显示错）
- omp/pi 接本地模型：纯文本模型必须声明
input: ["text"]，否则 agent 会发图卡死 - 编程，HEMMES要在 NEW API中间层配好采样参数，否则容易出现疯狂思考几十分钟，产出却少得可怜的怪象：
模式 temperature top_p top_k min_p presence_penalty repetition_penalty 思考模式（规划/复杂任务） 1.0 0.95 20 0.0 0.0 1.0 Instruct 模式（日常对话/直答） 0.7 0.80 20 0.0 1.5 1.0 - 思考循环治理：
reasoning_effort（none/low/medium/high）+reasoning_budget_tokens硬预算，服务端 shared-settings 全局注入
四、它为什么是"本地模型之王"
不是单点快，是整个账本没有浪费：
- 显存 24G X2 → 只放热的东西，命中率 90% +
- 内存 110G → 全部专家 + PLE，一分不闲
- CPU 64 核 → 未命中专家的就地计算，每核吃满
- SSD → 只在启动时发力
- 模型侧 → MoE 稀疏激活 + MTP 自投机 + QSA 稀疏注意力，每一层架构都在为"消费级硬件"让路
别的方案在"怎么把模型塞进显存"上卷，Strata 在"怎么让整个 PC 变成一台异构推理机"上卷。它不是把服务器模型硬塞进桌面，而是把桌面变成了一台小服务器。
缺点也说清楚：不支持 AVX-512 的 CPU 少一档内核速度（AVX2 补齐了大半）；层切分流水线让单卡用户少一半专家缓存；量化到 IQ4_XS 后数学类推理略逊满血。但对本地部署的真实负载——agent 编码、长文档、日常对话——这些短板都不在关键路径上。
以上全部数据来自本机实测（2026-10），引擎与模型均开源可复现。欢迎交流不同硬件下的账本。
IQ4_XS 带视觉 正在编程过程中：
IQ3_S 速度还要更快一些
希望作者抓紧迭代，加入103G的UD_IQ4_XS，KLD和PPL可以进一步优化！
这个作者简直是天才。以前用27B还担心烧坏显卡，现在闭眼限240-250W，显卡，CPU，内存一起发力，长时间开着写程序，显卡温度也不会升高！质量还有保证。本地LLM跑中长程任务 时代真的要来了！
-
-
大哥有没有遇到重复问题？
-
直接回答：有人跑，而且就是你这个组合（双 3090 + Strata + unsloth UD-Q4_K_XL），数据非常完整。 ① 权威实测（Strata 官方 issue #498，已被作者合并进 v0.1.37）： 配置：2x RTX 3090 + EPYC 7453（AVX2）+ 165GB RAM + Linux，UD-Q4_K_XL（111GB 下载），262K ctx，int8 KV： | 指标 | 单卡（setup 默认） | 双卡 split | |-------------------|--------------------|-------------------| | Decode @4K | 31.7 t/s | 64-78 t/s（翻倍） | | Decode @128K | ~30 t/s | 55.4 t/s | | Prefill @128K | — | 2,192 t/s | | expert cache 命中 | ~80% | 91-94% | RAM 占用实测：RSS ~95GiB，最低可用 68GiB/165——很吃系统内存，但这正是你的强项。 ② 更猛的（issue #642，今天还在活跃）：Hardin22 的 DualGPU fork PR 栈，用户 adambenhassen 在 2x3090 Linux 上跑出 decode 128-140 t/s、99K prompt prefill 3,052 t/s（比官方 0.1.39 快 50%）。已知坑：pipeline+async 组合在双 3090 长请求下会 stall，作者正在修。 ③ 官方进度：0.1.37 起 setup 在 ≥135GB RAM + 双卡时直接提供 UD-Q4_K_XL split 选项，不用再手动改 JSON。128GB 机器才需要 UNSLOTH_RAM_LEFT_GB=0 绕过（有人 2x5060Ti 跑通 35-45 t/s）。 对你的意义： - 256GB >> 135GB 门槛，零绕过，装好 setup 就能选 - 预期对齐 #498：64-78 t/s decode + Q4 精度（对比单卡 Q3_K_XL 的 38-61 t/s，双卡 Q4 更快还更准） - 等一个变数：#498 用的是 EPYC 7453（3.35GHz boost），你 7B13 2.25/3.5GHz，CPU 算 experts 的速度会打折扣——但你有 128 线程，可玩 --pool-workers 调优，而且 Strata 也吃 AVX512（7B13 是 Zen4 有 AVX-512，7453 是 Zen3 没有，这一项你反而占优）双卡，大内存，再继续等等，现在抄不如等 大神们把 框架作业写完整了再抄！
模型格式方面，咱们双卡128G+内存， 上UD Q4 XL 应该都可以。但是我个人想要swift 1.5的UD Q4 XL. 不想用unsloth那个官方的 UD Q4 XL. 再等一星期看有没有人制作出SWIFT 1.5的对应格式。
-
-
-
，
T terry 固定了此主题
-
-
Strata 引擎深度拆解：125B MoE 跑进 2×3090 + EPYC，TG 80-130 t/s 的账本与架构笔记
硬件：EPYC 7B13 (64C/128T, Zen3) + 2×RTX 3090 24G + 247G DDR4-2133 八通道 + NVMe
模型：Qwen3.8-Flash-Next-Uncensored IQ4_XS（orcarouter 无审查微调，97.5G GGUF）
引擎：Strata v0.1.38（Niko1221/Strata）
实测体感：限制250W 及 1570MHZ核心，温度可压到60度以下，三风扇无噪音。TG 稳定 90-120 t/s，长文写作 80 t/s 左右，262K 满上下文，视觉可用10月8日升级后加参数: 150 t/s 是真的，而且日志里最高冲到 175.9 t/s。拉了全部引擎日志和 /metrics，归因分析如下：
你的 150+ 从哪来（三层叠加）
① 主因：pipeline-windows 2 生效了（双卡不再轮流干等）
0.1.39/0.1.40.1 时代层切分是“严格接力”——卡0算完传给卡1，每步有半个周期两张卡之一在空转（fork 作者实测“每张卡每步闲置过半”）。现在 --pipeline-windows 2 让卡0在卡1验证当前窗口时就开始算下一窗，空转时间被吃掉。你日志里整段稳态在 104-136 t/s 区间（旧基线 71-99），长答 9473 tok 跑出 124.6 t/s——这个稳态抬升就是流水线的贡献，+25~30%。② 助推：热点会话的专家缓存命中 94-97%
你 150+ 的那几段（160.5/160.4/165.2/175.9）全部是 2 秒短段 + 94%+ 命中 + PCIe 传导只占 2-3.5%——热会话里专家几乎全在双卡缓存里，miss 极少，流水线不用等 PCIe 搬运，MTP 猜测链也顺。命中率低的段落（88.4% 那条只有 106.7 t/s）反证了这个相关性。③ 波峰：MTP 接受率好的短段
短段（100-240 tok）样本小，若草稿层连中，单窗口提交多 token，瞬时速度就高——175.9 那条是典型的“波峰读数”。整段 MTP 接受率目前 68.5%，中规中矩。- 写“短段峰值 150-176，长答稳态 112-125”，别只报峰值——175.9 是 240 tok/4s 的短段，长文读者会自己复现不出来然后回帖质疑
- 对照基线：同机 IQ4_XS 旧版 71-99 t/s → +40~70%（比 fork 作者 IQ3_S 的 +50% 还好，可能因为你的 24G×2 显存缓存余量更大）
- 配置写清楚：0.1.40.3 + --pipeline-windows 2 --adapt-async 1 + IQ4_XS + 262K + 会话驻留缓存 64G/16 slots——尤其提 0.1.40.3 起 fork 能力已全进官方 main，不需要再装 fork
“更快的卡放最后（跑 output head + draft）”在 0.1.40 已是自动行为（server 按 SM×clock 自己排卡），你的双 3090 同型号无此差异——这也是你复现干净的加分项。
10月8日,速度已经很满意 了,后续就是打磨质量了(3D鹈鹕骑车用了8分钟写成,增加细节另花10分钟) :
打开后要等几十秒加载three.js
pelican.html一、先看账本：每一 GB 去了哪
显存账本（每卡 24G，几乎满配）
去向 大小 说明 专家缓存（热点专家） ~17.3 GiB/卡 6931/24576 个专家常驻 VRAM，随对话自适应换血 注意力/DeltaNet/QSA/KV 常驻窗 ~5 GiB/卡 KV 只驻留最近 32K（--kv-resident），更早的流式 MTP 草稿头 ~213 MiB 10.6 万 token 词表的投机草稿层 视觉编码器预留 ~1.4 GiB mmproj 投影 + ViT 激活 剩余 ~458 MiB 安全垫 双卡分工是层切分流水线（0-22 层 / 23-47 层），不是张量并行——不需要 NVLink/P2P，PCIe 3.0 x16 老平台一样跑。
内存账本（247G，进程 RSS 实测 ~97G）
去向 大小 说明 全部专家权重（pinned） ~61 GiB VRAM 装不下的 1.7 万个专家，CPU 在位计算 PLE n-gram 表（--ple-io ram 锁页） ~28.8 GiB 51B 参数的 lookup 表，锁进 RAM 免 SSD 抖动 KV 流式区（262K ctx） ~3.6 GiB 13.7KB/token，超 VRAM 窗口的部分 MTP 权重 + 运行时 + 杂项 ~4 GiB 关键认知：free 命令显示的 used 不含 PLE 锁页（mmap 页计入 Cached），看进程 RSS 才是真话。别被 70G 的假象骗了。
CPU 账本（64 物理核）
去向 核数 说明 专家池 worker 63 默认 = 全部物理核 - 宿主线程，decode 时每核吃满 99.9% 宿主循环 1 token 调度 + GPU 提交 SMT 兄弟线程 64 空闲（AVX2 内核吃满物理核就够了，开 SMT 反而抢带宽） "只用到一半 CPU"是 top 的错觉：物理核 64 个全在烧，SMT 线程闲着。如果能升级AVX-512的CPU，内核可以更快，但 Zen3 只有 AVX2——Engine 自带 iq_avx2.cpp 多 token 内核（实测 down 4.4 GB/s vs ggml 3.2，3-token 窗口 282us vs 414us），AVX2 用户不亏。
启动账本
冷启动 35 秒完成 61G 专家加载（~27 GiB/s，八通道 DDR4-2133 的理论带宽约 120GB/s，单线程顺序读能跑到 1/4 理论值已经很扎实）。
二、架构拆解：为什么它能"魔法打败魔法"
Flash-Next 是 125B 总参 / 6B 激活的 MoE：48 层 × 512 专家，每 token 只激活 10 个。这个结构就是为 Strata 量身定做的——激活稀疏性让"专家分家"成为可能：
1. 四级存储瀑布（核心思想：厨房台面与 pantry）
VRAM → 每 token 必经之路：注意力/DeltaNet/KV/草稿头 + 热点专家缓存（自适应学习你的对话习惯，命中率爬到 97-99%） RAM → 全部专家 pin 住。VRAM 没有的专家，CPU 就地计算——GPU 和 CPU 并行，互不等待 SSD → 28.8G PLE n-gram 表。每 token 只读几行（我们的环境 用 --ple-io ram 锁进内存后归零）每生成一个词：草稿头先猜 3-5 个 token → 一次前向验证全部 → 平均 2.4-3.2 token/步落袋。MTP 接受率实测 70-96%（代码类任务更高），这就是 80-100 t/s 的直接来源。
2. 双卡流水线而非张量并行
CUDA0 算 0-22 层，CUDA1 算 23-47 层，一个 verify window 只有一次卡间握手。对比 vLLM 的 TP=2：不需要 NCCL allreduce 高速互联，不需要双卡同频，两张卡各自干自己的层——这就是为什么 3090 这种 PCIe 老卡也能高效组队。
3. KV streaming：上下文免费扩容
VRAM 只留最近 32K 的 KV，历史部分放 pinned RAM 按需流式读。代价是 RAM ~13.7KB/token（262K 才 3.6G），换来的是显存让给专家缓存。官方数据：262K 上下文下这个设计让 Q2_0 从 50.9 提速到 62.6 t/s。 如果有需要还可用Yarn扩展到512K或 1M。
4. 自适应专家缓存
引擎按 expert profile（预训练统计的热度排名）初始摆放，运行中按你的实际对话持续换血——中文对话热起来的专家和写代码热起来的专家是两批人。实测命中率从 92.7% 爬到 99.2%，命中即免 CPU，这就是为什么跑得越久越快。
5. 为什么"感觉不到瓶颈"
decode 时的关键路径是：GPU 算缓存专家（~13ms）‖ CPU 算未命中专家（~75ms）‖（偶发）SSD 读 PLE 行。三条路并行，最长的那条决定速度。PLE 锁内存后，CPU 专家计算成为唯一长杆——而这正好吃满你的 CPU。
三、搭建路径（可复现）
硬件清单
- CPU：EPYC 7B13（谷歌定制，64C，Zen3）——CPU 越多 CPU-专家路径越快，核就是显存外的第二"算力池"
- 内存：247G DDR4-2133 八通道——容量 > 频率，八通道带宽是专家加载速度的保证
- GPU：2×3090 24G（不需要 NVLink！层切分不吃 P2P）
- 盘：NVMe（放 GGUF + PLE 表；PLE 锁内存后 SSD 只在启动时被读）
软件步骤
- 编译引擎（CUDA 12.9 + GCC15 的坑：必须 CUDAHOSTCXX/CMAKE_CUDA_HOST_COMPILER 双指定 g++-14）：
cmake -B build -DSTRATA_ENABLE_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=86 ... cmake --build build -j 48-
模型三条件（任何微调版能不能上，看这三条）：
- GGUF arch = qwen4exp（官方 GSQ-RCO 系或其微调）
- 每层专家不被分片切开（跨片要先 merge）
- 小投影转 BF16（第三方量化用
tools/iq_pack.py --compat-bf16打包，专家权重不动） - 格式兼容性别信文档，直接跑
./build/native_expert_parity <shard1> 0 2——0 failures 就能上（IQ4_XS 就是这么实测出来的，官方文档还说没验证）
-
打包 + 配置：
iq_pack.py生成 pack（index/dense/tokenizer，约 1.5G），配置 JSON 指定 pack/native/ple-gguf/MTP/层切分 -
服务：
python3 -m serve.server --engine strata --config xxx.json --port 8025，自带 Web Chat/Monitor/OpenAI API/Anthropic API/视觉（mmproj + strata-vision helper） -
三个必开参数：
--kv-resident 32768（KV streaming，长上下文提速 + 显存让位）--ple-io ram（PLE 表锁内存，decode 尾延迟稳）不开占用70G内存，开了占用105G左右--layer-split auto（双卡自动切层）
-
上下文三档热切换（本机的做法）：131K / 262K 原生 / 512K YaRN（--rope-scaling yarn --rope-scale 2.0），一个脚本管三档配置，切换时同步 new-api 元数据
踩坑速查
https://huggingface.co/orcarouter/Qwen3.8-Flash-Next-Uncensored-GGUF/tree/main 模型下载地址，考虑到CPU性能，我下载的是IQ4_XS，相对IQ3，质量稍好。
- hf 下载 >50G 文件报 hf_xet → aria2c 直拉 resolve 链接
- gated repo 要 HF 授权 + token，hf-mirror 对 lfs.oid 打码 → 手动 SHA256 不可用，用 hf 幂等重跑验证完整性
- new-api 建渠道要三件套：channels + abilities + models（缺 abilities 503，缺 models 前端上下文显示错）
- omp/pi 接本地模型：纯文本模型必须声明
input: ["text"]，否则 agent 会发图卡死 - 编程，HEMMES要在 NEW API中间层配好采样参数，否则容易出现疯狂思考几十分钟，产出却少得可怜的怪象：
模式 temperature top_p top_k min_p presence_penalty repetition_penalty 思考模式（规划/复杂任务） 1.0 0.95 20 0.0 0.0 1.0 Instruct 模式（日常对话/直答） 0.7 0.80 20 0.0 1.5 1.0 - 思考循环治理：
reasoning_effort（none/low/medium/high）+reasoning_budget_tokens硬预算，服务端 shared-settings 全局注入
四、它为什么是"本地模型之王"
不是单点快，是整个账本没有浪费：
- 显存 24G X2 → 只放热的东西，命中率 90% +
- 内存 110G → 全部专家 + PLE，一分不闲
- CPU 64 核 → 未命中专家的就地计算，每核吃满
- SSD → 只在启动时发力
- 模型侧 → MoE 稀疏激活 + MTP 自投机 + QSA 稀疏注意力，每一层架构都在为"消费级硬件"让路
别的方案在"怎么把模型塞进显存"上卷，Strata 在"怎么让整个 PC 变成一台异构推理机"上卷。它不是把服务器模型硬塞进桌面，而是把桌面变成了一台小服务器。
缺点也说清楚：不支持 AVX-512 的 CPU 少一档内核速度（AVX2 补齐了大半）；层切分流水线让单卡用户少一半专家缓存；量化到 IQ4_XS 后数学类推理略逊满血。但对本地部署的真实负载——agent 编码、长文档、日常对话——这些短板都不在关键路径上。
以上全部数据来自本机实测（2026-10），引擎与模型均开源可复现。欢迎交流不同硬件下的账本。
IQ4_XS 带视觉 正在编程过程中：
IQ3_S 速度还要更快一些
希望作者抓紧迭代，加入103G的UD_IQ4_XS，KLD和PPL可以进一步优化！
这个作者简直是天才。以前用27B还担心烧坏显卡，现在闭眼限240-250W，显卡，CPU，内存一起发力，长时间开着写程序，显卡温度也不会升高！质量还有保证。本地LLM跑中长程任务 时代真的要来了！
-
-
-
-
-
-
-
试了一下， 叹息CPU不如楼主啊
-
Strata 三层架构（VRAM/RAM/NVMe）如何"突破"旧经验——调研与分析 (10月9日凌晨补充）
日期：2026-10-08 ｜ 前置：《MoE卸载比例公式-验证报告-1008.md》
0. 结论先行
Strata 没有推翻"容量定比例、带宽定速度"公式，而是把公式的两个静态前提全部动态化了，再把三个引擎级的加速因子叠加上去。旧框架（llama.cpp -ot / vLLM / SGLang）各自只做对了其中一件，Strata 是第一个把四件事叠满的引擎：
# 机制 llama.cpp -ot vLLM/SGLang Strata 1 专家自适应热缓存（VRAM 放"最常用"而非"固定哪层"） ✗（静态分层） ✗（专家须全进显存） ✓ 99% 命中 2 CPU 与 GPU 并行计算（串行和 → max） ✗（串行） ✗ ✓ 3 MTP 投机解码放大有效带宽 ✗（MoE 场景难开） △ ✓ 2.4-3.2 tok/验证窗 4 NVMe 只放查找表不放权重 △（mmap 权重，热路径碰盘） △ ✓ PLE 表 ~3MB/s 毫无压力 1. 逐条解释（对应用户的三层描述）
"显存放专家" = 自适应专家热缓存
24576 个专家每 token 只激活 10 个 → 工作集极小且有时间局部性。Strata 把 VRAM 当自适应缓存（对话中持续学习哪些专家最热），实测命中 92.7%→99.1% 爬升。缓存命中 = 专家根本不用从 RAM 搬，也不用 CPU 算。这正是公式里的 h 项——旧框架把它当预测问题（PreScope 等论文 94%），Strata 用"实测统计+在线换入换出"做到了 99%。
关键句（HOW_IT_WORKS 原文）："More VRAM matters more than a faster GPU: every extra GB holds ~700 more experts"——显存容量直接兑换命中率，显卡算力反而次要。"RAM 放一部分专家" = CPU 原地计算 + 与 GPU 重叠
全部 24576 专家 pinned 在 RAM；显存没缓存的专家由 CPU 原地计算（AVX2/AVX-512 多 token 内核），且"at the same time as the graphics card, so neither waits for the other"。
——这把我上轮公式的串行和变成了 max()，正是 Fiddler prefill 公式的 decode 版落地。这解释了本机实测：EPYC 64 核 CPU 段算冷专家与 3090 GPU 段并行，decode 128-176 t/s。
CPU 段为什么快得动？两个原因：① 命中 99% 后 CPU 只算 1% 的冷专家；② MTP 让每步验证窗平均携带 2.4-3.2 个 token，CPU 内存带宽的有效压力被除以 2.4-3.2。"NVMe 做资料柜" = 查找表下沉，不是权重下沉
NVMe 上放的是 28.8G PLE n-gram 查找表（MTP 草稿的素材库），lookup-only、每 token 读几行 ≈ 3MB/s——NVMe 带宽 7GB/s 根本碰不到天花板。
纠偏（0928 调研已定，Strata 设计再次印证）：如果把专家权重放 NVMe 热路径（内存 136GB/s vs NVMe 7GB/s 差 20 倍）必然爆炸；NVMe 的正确定位只有三种——多检查点仓库、加速冷加载、lookup-only 小 IO 表。Strata 选了第三种，"资料柜"比喻精确。2. 为什么说"突破旧经验"——三个旧框架各自缺什么
- llama.cpp -ot exps=CPU：静态分层（哪些层上卡要人拍）、CPU/GPU 串行、无 MoE MTP、无热缓存。FATE（llama-moe-cache，500 行补丁）给 llama.cpp 补了热缓存+预取，实测 12G 卡跑 120G 模型达原生 2 倍速——证明缺的正是这一块。
- vLLM/SGLang：架构假设专家全进显存（TP 语义下专家被 sharding），显存不够直接不可行；SGLang HiCache 分层的是 KV cache 不是专家权重——解决的是长上下文，不是大专家池。
- club-3090 moecache fork（leloch 未合入主线）：给 llama.cpp 加专家缓存，DeepSeek-V4-Flash 284B 在 2×3090 +29% decode——同类思路的独立印证，"for MoE, the cheap upgrade is RAM, not VRAM"。
3. Strata 崛起时间线（调研确认）
- 2026-09-29 前后：Niko1221 开源（C++/CUDA，双击安装）
- 10 月初：媒体 "Strata goes viral"——125B(6B active) 跑 12G 游戏卡 + 32-64G RAM；社区复现帖（lcz 2027/2098/2156、castlen3 功耗帖：整机功耗风扇噪音优于密集 27B 全速）
- 10 月上旬：Hardin22/DualGPU PR 栈全部进 main（#859/#876/#905/#910），双卡层切流水线 +12%
- 本机 1008：v0.1.40.3 + pipeline-windows 2 → 长会话 150-176 t/s 历史新高
4. 对 P100 副机问题的回扣（重要落点）
️ Strata 硬性要求 compute capability ≥ 8.0（RTX 30 / 对应 AMD 代）——P100 (sm_60) 跑不了 Strata。
P100 副机的可行路径退回：- 公式原样适用（贪心塞满 + 串行两段）→ 30B-A3B Q3_K_M 全显存 ~55 tok/s
- 想在 llama.cpp 系吃到"专家缓存"红利：FATE/club-3090 类 fork 需确认 sm_60 兼容性（未验证，sm60 补丁生态存在但 FATE 用了 CUDA graph/stream 特性，Pascal 支持存疑）——后续可单独调研
- club-3090 口诀对 P100 同样成立："cheap upgrade is RAM, not VRAM"——64G 内存正是这台副机的核心资产
5. 信源
- github.com/Niko1221/Strata docs/HOW_IT_WORKS.md + MULTI_GPU.md
（架构原文） - github.com/ongunm/llama-moe-cache (FATE) （llama.cpp 专家缓存实证）
- club-3090 discussion #951 （284B +29% moecache 实测）
- CBS E 路 8 条（含 viral 报道 2 条）、F 路 0（lcz 站内账本已本地持有）
- 本机现役实测：strata-serving skill（99% 命中/128-176 t/s/MTP 70-74%）
qwen 3.8 27B+sglang ( KLD和PPL数据非常好） 用 10分钟写出的鹈鹕骑自行车：
下面这个是strata + qwen 3.8 flash 用10分钟写出来的，但是颜色错误，让它改回正常颜色又用了15分钟。。。 细节比27B要强一些。
升级1.40之后一次性可以写成功：
-
-
-
-
本帖参与讨论人数已达 10+，入选热议，作者 +3 积分奖励，感谢分享！
