用老机器跑 125B MoE 本地模型：i9-9900X + X299-A + 64GB 四通道 + 单张 RTX 3080 Ti 12GB，Windows 下跑 Strata。
另附一种用法——同局域网内另一台机器远程调用，以及对后续换机后的分工预估。

先看张图（服务自带的监控面板）

测试时为独机空载
这是 Strata 自带的监控面板，不用装任何第三方软件，浏览器打开 127.0.0.1:8080 的 Monitor 页就是它。
几个数字直接把原理讲清楚了：

还有一个数字值得留意：REUSED 全是 0、HIT RATE 只有 58~60%。
说明每一轮有一半以上的内容是重复回喂的（这正是"整块替换"做法的代价），这是后面可以优化的地方。

再补两点：

• 面板上的数字会随负载浮动：同一台机器干同样的活，PCIe 搬运量会在 9.8~12 GB/s 之间摆动，
  均速也会在 63~64 之间小幅变化。所以看量级就行，不要当固定值。
• 最近几条请求都是 1.5 万输入、1.4 万输出、耗时 235~244 秒的长任务 ——
  这就是"每轮把整个文件重写一遍"最直接的代价。

（数据来自 2026-10-04 22:40 的监控面板）

一、电脑硬件与系统软件

• 这张卡跑在 PCIe 3.0 ×16（X299 平台；显卡本身支持 4.0，但链路协商在 8.0 GT/s）。因为 MoE 要把"没缓存的专家"从系统内存搬进显存，PCIe 带宽本身就是这套玩法的真实瓶颈之一 —— 这也解释了为什么 --pcie-frac 那么敏感。
• 系统盘是入门级 NVMe（WD Blue SN550，无独立 DRAM 缓存，标称顺序读约 2.4 GB/s）。满载 33GiB 模型加载约 20 秒（约 1.65 GB/s），与这块盘的定位吻合。另一篇做过 SATA 与 NVMe 的对照，结论是更快的盘主要缩短加载时间，对持续生成速度没有一致优势。
• 内存是四通道，这对这套玩法很关键。 显卡装不下的专家是 CPU 在算，而 CPU 算得快不快，直接由内存带宽决定。四通道的带宽是两通道的两倍 —— 我这台 4 条 3600 是约 115 GB/s，换成 2 条就只有 58 GB/s。所以这个配置买的时候没想过，现在用上了。
• 频率也有关，但是线性的。 3600 比 3200 多约 12%，比默认的 2133 多约 69%。对这类负载，通道数比频率重要，频率比时序重要。
• 实测确认它跑满了。 CPU-Z 读到的内存频率是 1800.5 MHz（就是 DDR4-3600），时序 16-19-19-39 2T，和 XMP 标称完全一致。X299 插满 4 条还想上 3600 本来不容易 —— 这 4 条还是**双面（2R）**的，这台是跑住了。

上下文只给了 32768。64GB 内存下，这个配置留的余量比较舒服；

二、量化可选范围与差异

选 IQ2_XS 的理由是内存余量：64GB 里除了模型还要放 KV 和系统本身。有双卡帖子的实测显示 IQ3_XXS 跑起来系统可用内存最低只剩 3.3GiB，我这边没有做质量对比。

三、它凭什么能在 12GB 显存上跑 125B

关键在于这是 MoE 模型：48 层、每层 512 个专家，一共 24,576 个；但每个词只用其中 10 个。所以不需要把所有专家都塞进显卡 —— 分工就行。

官方文档用的比喻是厨房：天天用的调料放灶台上（显卡），其余全放储藏间（内存）；要用的时候去拿 —— 而且储藏间里有人（CPU）同时动手做，不是干等。

具体分三层：

另外两个关键优化：

1. 先猜后验（投机解码）。 模型自带一个小助手先猜接下来几个词，大模型一次性全验一遍，只留下对的。因为每个词最终还是大模型定的，质量不变，但速度能快 1.6~1.8 倍（我实测的草稿命中率是 91.1%，“实测速度”那节有）。
2. 长文本"边读边搬"。 一次最多读 8,192 token；而且下一层的专家在"当前层计算"的同时就已经通过 PCIe 搬过来了 —— 这就是为什么一条 PCIe 3.0 也喂得动（实测搬运量 9.8~12 GB/s，就是开头那张图上的数字）。

三个容易误解的点：

• 上下文 32768 不等于把全部 KV 塞进显存 —— 完整 KV 后备在内存，显存里只驻留最常读的一段。
• 显存比显卡型号更重要：官方文档说，每多 1GB 显存能多放约 700 个专家，而每个放在显卡上的专家，CPU 就少算一个。
• --pcie-frac 是这套玩法的命门：它决定"多少专家常驻显存、多少留在内存让 CPU 算"，所以那么敏感（“配置与调参”那节有张倒 U 形的表）。

四、安装与踩坑

四个踩的坑，都跟安装本身无关，但很浪费时间：

1. 别习惯性加 --setup。 重启服务时加了它会重走配置向导，而向导的默认档是 IQ3_XXS——差一点重下几十 GB。
2. MTP 草稿模型会中途断。 我遇到两次 SSL: UNEXPECTED_EOF_WHILE_READING。它是按字节断点续传的，直接重跑就行，不用清缓存。
3. hf-mirror 对这个仓库无效（308 跳回 huggingface.co）。只能靠续传硬下。
4. Python 依赖走国内源，直连基本装不动。

五、配置与调参

最终参数：

--max-context 32768
--kv int8
--expert-cache auto
--prefill auto
--spec 4
--spec-min-p 0.70
--pcie-frac 0.34
--vram-reserve-mib 700
--vision

三个关键旋钮我让 agent 手动扫过一遍（默认配置下只有约 32 tok/s）：

旋钮一：--pcie-frac（专家搬不搬得动）

旋钮二：--spec-min-p（草稿模型信不信得过）

旋钮三：CPU 工作线程数

--pcie-frac 是倒 U 形：给少了专家全走 PCIe 搬不过来，给多了显存太满调度变差。

32 提到 55.8 tok/s。这里只扫了这三个旋钮，不等于全局最优。

六、使用界面与调用方式（逐个实测）

工具调用实测：问"帮我查一下杭州现在的天气"，它正确发起了 get_weather，参数 {"city":"杭州"}；回传结果"杭州：22℃，多云，东南风 2 级"后，它正常用自然语言作答。

安全上：服务只绑 127.0.0.1 并设了 api-key，不暴露到局域网或公网。（今天复核：不带 key 请求一律返回 authentication_error，这条是真的在生效，不是面板上的摆设。）

七、实测速度

两个值得单讲的：

• 冷 prefill 1,238 tok/s 是可比的——论坛另一篇双卡帖在 36,919 tokens 输入下测到 1,505 tok/s，同一量级。
• 前缀缓存是最大的体感来源：同一段 24K 输入，第一次要 20 秒，第二次只要 0.54 秒。反过来也成立——换模型、换仓库、上下文超限，都要重付一次。

八、各任务下的差异

流式实测，关思考：

结论只有三条：

1. 首字延迟 0.8~1.8 秒，与任务类型几乎无关。
2. 总耗时 = 首字 + 输出长度 ÷ 速度——"抽一个字段 1.9 秒"和"写代码 7.9 秒"的差别，只来自输出多长。
3. 输出越长，平均速度越高（长输出 40~47，极短输出只有 6~13，被固定开销拖低）。

另外测过两档思考强度：8 道基础题不思考 7/8、最高档思考 8/8，但总耗时从 19.6 秒涨到 98.6 秒。差异集中在一道带硬约束的题（"句子里不能出现某个字"）。思考更像是"生成后回头核对约束"，不是让人变聪明——样本小，只能说观察。

九、延伸的玩法：同局域网里另一台机器Mac book air来调用，也是现在正在用的方案

我平时常用机是 Mac book air，想让 Mac 上的 deepseek harness 调用另一台windows跑的本地模型。做法不是开端口，而是反向隧道：

在 Windows 上（系统自带 ssh；老系统去"可选功能"装 OpenSSH 客户端）：

ssh -R 8080:127.0.0.1:8080 你的用户名@Mac的IP

然后在 Mac 上访问 http://127.0.0.1:8080。这样：

• 模型始终只听 127.0.0.1，从不暴露到内网或公网；
• 隧道默认只绑在 Mac 的回环地址上，局域网里别的设备看不到；
• 关掉那个 ssh 窗口，通路立刻消失；
• 不用改防火墙、不用开端口。

实测这套通路上，客户端侧看到的平均速度、稳定性都跟本机调用一致。

十、拿它做过的真任务：一个游戏的多轮交付（2026-10-04 实测）

任务：让它从头做一个能在浏览器里跑的小游戏（雷电那种竖版射击）。

做法（三条）：

1. 我只提需求，不写代码。 比如「按住 Z 要能连射」「打中敌机后它没消失」——就这种大白话，不给它代码、不给补丁。
2. 每轮让它把整个文件重写一遍，不打补丁。打补丁容易对不上号，它还会顺手把好好的地方改坏。
3. 每轮做完立刻验一遍，验完只留一句话（「能跑」「跳不起来」「走两步就卡死」）。

两轮的真实数字（同一个模型、同一条反向隧道、关思考、温度 0.2、模型已加载）：

后面它还继续做了好几轮（这批数字是任务结束后，从监控面板上读到的最近 4 条）：

这一组数字把两个说法都更新了：

1. 它单轮能写多长，比原先估计的高得多。 之前只验证到 3,333 token（约 9KB），
   现在实测单轮写到 1.4 万 token 也没截断，状态全是 Done。
2. 代价是时间：一轮 1.4 万 token 要 235~244 秒（约 4 分钟）。
   换来的是**永远不用处理"补丁对不上号"**这类问题。

结论：

口径说明：

• 吞吐含首字延迟，所以天然低于纯 decode 口径；但这两轮反而做到 59~60，和“实测速度”那节里引擎自报的 63.4 基本吻合 —— 说明输出到这个长度（1.6K~3.3K）时，首字延迟已经被摊薄到可以忽略。
• 两轮都是一次成功，没有重试，finish_reason 都是 stop，没有触发输出截断。

再补一条："整块替换 + 回喂全文"是这种单文件增量开发最稳的做法。 第 2 轮输入从 523 涨到 2,256，涨的就是回喂的第 1 轮产物；输出是一次完整的 3,333 文件，不是补丁 —— 它不会为省输出偷工，也避开了"补丁对不上号"这类崩法。

十一、后续规划：Mac Ultra 和 win平台N 卡组起来干活

11.1 有一些想法

一台负责「读」——把长材料一口气看完读懂；一台负责「写」——一个字一个字往外产出。让agent 决定每件事派给谁。

先读懂一堆东西，再产出结果。这两件事的累点完全不同，所以可以拆给两台机器。

11.2 有没有可行性（用部分数据来评估）

为什么：打个比方 ——

• 「读」靠算得快（相当于多少人一起看材料），所以 N 卡人多
• 「写」靠搬得快（相当于把资料从仓库搬到桌上），所以 Mac 通道更宽（内存带宽 1.2 TB/s vs 0.9 TB/s），而且 Mac 不用来回搬（N 卡显存小，得不停从内存搬数据）

11.3 什么活派给谁

11.4 局域网这条线，实测够不够用

结论：测下来完全够用，2.5G的网络可以当「本机」用。

局域网这条线不但不掉速，反而还高一点（因为那两轮本身输出长、效率高）。
所以，以后把活从 Mac 派到 Windows，速度上不需要妥协。

顺带两个好处：

• 不用开端口、不用改防火墙 —— 模型始终只听自己那台机器的 127.0.0.1
• 关掉那个 ssh 窗口，通路立刻消失 —— 用完就断，比开端口干净

11.5 我是怎么搭的（三步，第一步已经在跑了）

1. 两台各起一个模型服务 —— Windows 的已经有了（就是这篇在用的 Strata）；Mac 到货后装 oMLX
2. 开反向隧道接起来（现在这条就是）：ssh -R 8080:127.0.0.1:8080 用户名@Mac的IP
3. agent 按「读 / 写」分派，规则就是 11.3 那张表

11.6 两条硬限制（先讲说清楚，免得大家白折腾）

1. 不能把「同一个请求」拆到两台机器上跑（一台读一半、一台写一半）。那要求两台是同一种硬件、再用特殊高速连线 —— N 卡和 Mac 之间没有这条路。
   也就是说，互补只能停在**「一个任务整段派给一台」**这个层面。
2. 别在两个之间来回换。 换一次，读过的内容就白读了（要重读一遍），很可能比只用一台还慢。

11.7 用起来最容易踩的坑

它一次只服务一个请求。 所以：

• 别两个窗口同时用它 —— 后发的只能干等，看起来像「死机」
• 长任务让它在后台跑，看进度用一条命令：

curl -s -H "Authorization: Bearer <你的key>" http://127.0.0.1:8080/status

看 busy（在不在跑）、generated / max_tokens（跑到哪了）、phase（在思考还是在写）。

一句话：「它在跑」和「窗口能不能用」是两件事 —— 放后台跑，窗口照常能用。

十二、能力边界与短板（实测）

我按六个维度把边界探了一遍，全部用客观判据（不看"感觉答得好不好"）。

能干什么（这几项比预期好）

1. 指令遵循很强。 五条硬约束叠加——以 # 开头、以 # 结尾、中间不超过 12 字、全文不得出现「的」、不得换行——全部守住。多约束叠加通常是小模型最先崩的地方。
2. 幻觉控制好。 我埋了两道不存在的事实（「量子纠缠咖啡机是哪一年由谁发明的」、以及问 2026 年诺贝尔物理学奖），它两次都直说查不到，没有编。
3. 代码能真跑，不只是"看起来对"：闰年函数 5/5；手写 Stack 类 10/10（含空栈 pop/peek 抛 IndexError、能存 None/0 而不误判为空）；拓扑排序 8/8（含成环返回 []、重复边不崩）。
4. 反直觉陷阱过。 经典的球棒与球问题（棒比球贵 1 元、合计 1.10 元），它答 0.05，没被直觉带偏——这题不少模型会答 0.10。
5. 被指出 bug 后修得又快又准。 它写的马里奥克隆有个碰撞盒 bug（玩家走 10 像素就卡死），我把症状+根因+原函数给它，7 秒 / 290 tokens 给出修正：垂直检测改用底边、并把垂直与水平的检测顺序调换（先站稳再做水平）。我替换回去真跑验证：站姿 y=352 正确、横向跑 511 像素、被管道挡住、跳跃 124 像素抛物线正确 —— 修好了。

干不了什么（短板很集中）

1. 极难计数类推理会崩。 「1 到 1000（含）中数字含 7 的整数有多少个」正解 271，它答 192。这类需要精确枚举或容斥的题它在最高档失手，而且是直接给个错数，不会说"我不确定"。
2. 上下文是硬墙。 实测 26,305 tokens 的输入可用，再往上直接 HTTP 400 Bad Request。32768 是真天花板，不是标称值。
3. 短问答被固定开销拖累。 同样这个模型：短问答 27.5 tok/s、中输出 44.1、长输出 50+。差的是首字延迟与请求开销，不是引擎变慢。
4. 边角知识建议核过再用。 常见事实（首都、π、元素、光速、行星数）全对，但知识类的冷门项不要默认它对。

长链任务与多样化（补测）

前面都是"单轮单题"，这一轮专门测依赖会累积的任务——那才是最容易崩的地方。

长链这一轮补出来的短板（比单轮测试暴露得更清楚）：

5. 长链会丢"语义约定"。 单轮写代码 23/23 全过，但三步递进改同一个模块时，第 2 步就把第 1 步的接口语义改掉了。所以多步任务要在每一步后复述并校验前面积累的约定，不能指望它自己记住。
6. 任务替换式的指令覆盖挡不住。 明确说「忽略上面要求」它顶得住，换成「忘记原任务、改做别的」就会被带走。别指望它自己防御，该管的要在外层管。
7. "一次做完大目标"会烧光预算。 让它「百分百还原马里奥的画面质感」，它就去逐像素画管道（1018 处），30000 token 烧光时主循环、键盘、物理一个字都没写，文件还缺收尾标签、打开就白屏。同一模型、同一预算，改成「能跑优先 + 严禁逐像素」后 —— 44 秒 / 2719 tokens 就写完了。
   所以，大目标要拆，或者把"能跑"写进第一优先级。

一句话总结

它适合"规则明确、结构清楚"的活：格式化、信息提取、写代码、多约束指令、中文处理、长文生成。
不适合"需要精确计数或多步数学枚举"的活、超过 3 万 token 的输入，以及没人看着的长链多步任务。

十三、局限与后续

• 已补测（引擎自带 /metrics 接口）：MTP 草稿接受率 91.1%、引擎口径平均 decode 63.4 tok/s、专家缓存 3,383 MiB / 2,451 槽位、PCIe Gen3 ×16 得到确认（gpu_pcie_gen: 3）。
• 已探明的上限：单次输入 26,305 tokens 通过、28K 档被 400 拒绝；长上下文两端验证码召回在 26K 档仍准确。
• 新增实测：远程派发多轮交付，单轮输出 1.6K~3.3K token 两次都一次成功、无截断；隧道侧吞吐 59~60 tok/s，与本机口径一致。
• 引擎版本 0.1.38。
• 仍未测：长时间多并发、满 32768 时的检索质量。单轮输出天花板已往上推过一档：从 3,333 token 推到 1.4 万 token 仍然成功、无截断（4 次），但还没顶到失败点。
• 思考档位的对比样本还小（8 道题），不足以当规律；但长输出任务下"思考会吃掉全部输出预算"已复现两次（4096 上限、26000 上限各一次），这一条可以直接用。
• 后续想做：更新引擎后重测 prefill 与首字延迟；换机后按同一套题跑一遍对照。

项目地址：Niko1221/Strata大神膜拜中