128GB 内存下，Qwen 本地推理方案对比

两周前，我写过一篇文章，介绍如何用 EXL3 和 TabbyAPI，在占用 40 多 GB RAM 的情况下运行 Qwen3.8-Flash-Next。此后，这台工作站的 RAM 升级到了 128 GB，最快的运行方案也随之改变。这篇指南介绍我们现在每天都在用的配置：通过 Strata 运行 Unsloth 为同一个 125B 模型制作的 5-bit UD-Q5_K_XL GGUF，在单张 RTX 5090 上提供 512K 上下文，生成速度约为每秒 79 tokens。

除非另有说明，下文所有数据都于 2026 年 10 月 15 日在我们自己的机器上测得。如果数据来自其他人，我会注明来源。

与之前的 EXL3 指南相比，发生了什么变化

之前的 EXL3 指南使用 turboderp 的 3.05 bpw 量化版本，因为 64 GB RAM 装不下更大的版本。升级到 128 GB 后，有了两条新路线：

• TabbyAPI 搭配 4.05 bpw EXL3 量化版本，并使用锁定在物理内存中的 CPU expert arena。在预留 3 GB VRAM 的情况下，服务端日志显示，解码速度约为每秒 68 tokens；处理 254K tokens 时，prefill 速度约为每秒 1,780 tokens。
• Strata 搭配 Unsloth 的 UD-Q5_K_XL。这是一个 5-bit 量化版本，其中 down projection 使用 8-bit。模型相同，但每个 expert 保留了更多位数，运行时也专门为这个模型家族构建。

在同一台机器上，Strata 调优前的解码速度与 TabbyAPI 大致相当，校准后更快；处理长 prompt 的速度约为后者的 1.8–2.4 倍，而且能运行 512K 上下文。这就是我们现在默认使用它的原因。

GPU：RTX 5090，32 GB VRAM。它还负责桌面显示，这一点后面会讲到。

CPU：Ryzen 9 9950X3D，16 核、32 线程，支持 AVX-512。

RAM：128 GB DDR5，由 4 条 32 GB 内存组成，运行速率为 5,600 MT/s。为什么没用 6,000，后面的踩坑部分会解释。

磁盘：一块 NVMe 硬盘，有足够空间容纳 158 GB 的下载文件。

操作系统：Arch Linux（Omarchy），NVIDIA 驱动 615.78，CUDA 13.4。

Strata 使用 commit 296b59d。

Strata 由一个 C++/CUDA 引擎和一个 Python 服务端组成，面向 Qwen3.8-Flash-Next 及其变体。它按三个层级读取模型：对话中最常用的 expert 放在 VRAM 中，其次放在 RAM 中，装不下的部分从 SSD 读取。运行过程中，它会在这些层级之间迁移 expert，利用模型自带的 MTP 层生成草稿 token，并提供兼容 OpenAI 和 Anthropic 的 API，以及一个带实时监控的小型 Web UI。

项目的安装文档 docs/AI_SETUP.md 是按 coding Agent 能照着执行的方式编写的。不过，我仍然建议你自己先读一遍：文档中的推荐规格主要面向配备 32–96 GB RAM 的游戏 PC，而较大的 Unsloth 量化版本在安装流程中属于单独的模型家族。

按 RAM 容量选量化版本，而不是只看位数

如果所有 expert 加上约 16 GB 的额外空间能够放进 RAM，Strata 就会把全部 expert 留在 RAM 中。如果放不下，它会在回答时从 SSD 读取剩余部分，解码速度会因此大幅下降。所以规则很简单：选择 expert 能装进 RAM、同时还能留出余量的最大量化版本。

以下依据 Strata 的模型表，以及它自己的质量指标：量化版本选出的 top token 与 Q8_0 一致的比例。

对于 128 GB RAM，UD-Q5_K_XL 是最合适的选择。在 Strata 的表格中，UD-Q6_K_XL 的得分同样是 94.6%；它的平均 KL 散度为 0.033，Q5 则为 0.038，但它还需要多占 10 GB RAM，而 128 GB 的机器没有这么多余量。Q8_0 则装不下。

下载之前，先让安装程序检查一下你的 PC：

git clone https://github.com/Niko1221/Strata.git
cd Strata
./setup.sh --check

它会输出 GPU、驱动、RAM、CPU、磁盘剩余空间，以及哪些规格能够运行。

我们执行的安装命令如下，采用非交互模式，并将模型文件放在 NVMe 硬盘上：

./setup.sh --yes --family unsloth --model UD-Q5_K_XL \
  --context 262144 --vision no --gpu 0 \
  --data-dir ~/Models/strata --port 8081 \
  --vram-reserve-mib 3072 --no-start

--family unsloth --model UD-Q5_K_XL 选择 Unsloth 的 5-bit 文件。

--context 262144 指定模型训练时的上下文长度，之后可以调大。

--vram-reserve-mib 3072 留出 3 GB VRAM。我们的桌面也用这张显卡，VRAM 完全占满时，屏幕会开始闪烁。

使用 --port 8081，是因为 8080 端口已经被我们的 GLM 配置占用，文章结尾会再讲到。默认端口是 8080。

--no-start 表示只安装、不启动服务，方便你按下文介绍的方式启动。

安装程序会在 Strata 文件夹中写入一个 JSON 配置文件 strata-unsloth-ud-q5_k_xl.json，以及一个启动脚本 run-unsloth-ud-q5_k_xl.sh。

如果下载很慢

Strata 自带的下载器在我们这里只能达到约 7 MB/s，下载 158 GB 大约要六个小时。更快的方法是：停止安装，通过 Hugging Face CLI，按安装程序固定的确切 revision 下载各个分片，将它们放进模型文件夹，再重新运行安装。安装程序会用 SHA-256 检查每个文件，并跳过已经存在的文件。

# the revision setup.py pins for Unsloth's repo
grep -n '"unsloth/Qwen3.8-Flash-Next-GGUF"' setup.py

hf download unsloth/Qwen3.8-Flash-Next-GGUF \
  --revision 38bb39ee97821de2c9009abb7e93950eec396e66 \
  --include "UD-Q5_K_XL/*" \
  --local-dir ~/Models/strata/hf-tmp

mv ~/Models/strata/hf-tmp/UD-Q5_K_XL/*.gguf ~/Models/strata/models/unsloth-UD-Q5_K_XL/

如果你自己的 setup.py 输出的 revision 与上面不同，请使用你自己的版本。

如果安装程序提示第 1 个分片“过短”

UD-Q5_K_XL 一共有六个分片，第一个分片只有元数据，没有 tensor，大小为 10.9 MB。在 commit 296b59d 中，安装程序的分片检查仍会认为它少了几个字节，即使下载正确也会停止安装。上游已有待合并的修复：PR #2505，#2632 也采用了相同思路；截至 2026 年 10 月 16 日，两者都还未合并。在其中一个合并之前，可以在本地做一处简单修改：在 setup.py 的 check_shards() 中跳过不含 tensor 的分片。

# in check_shards(), before: need = g.data_start + ...
if not g.tensors:
    continue

每次执行 git pull 后，都检查一下上游是否已经修复，避免继续保留不再需要的补丁。

绕开 shell 的内存限制启动服务

使用这个量化版本时，Strata 会锁定约 98 GB RAM。Linux 的两项默认设置可能会终止这么大的进程，或让它几乎无法正常运行：

• shell 或工具运行器处在有内存限制的 systemd scope 中。我们 Agent 的终端 scope 的 memory.max 为 4 GiB，从那里启动的模型最终大部分都会被换出到 swap。
• systemd-oomd。Omarchy 为用户的 app.slice 启用了它。当内存压力超过 50% 并持续 20 秒时，它就会终止对应的 cgroup。一个锁定了大部分 RAM 的模型，在加载时恰好就会表现成这样。

因此，我们在独立的 slice 中启动服务，不设内存上限：

systemd-run --user --scope --collect --slice=llm.slice \
  --unit="strata-$(date +%s)" -p MemoryMax=infinity \
  ./run-unsloth-ud-q5_k_xl.sh

使用 systemctl --user stop 'strata-*.scope' 停止服务。避免使用匹配范围过宽的 pkill -f：匹配模式也会命中执行它的 shell。

首次启动需要几分钟，锁定 RAM 时，桌面可能会短暂卡住。之后检查服务是否已经就绪：

curl -s http://127.0.0.1:8081/health
# {"status": "ok", "max_context": 524288, "model": "...", "loaded": true, ...}

curl -s http://127.0.0.1:8081/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "strata", "messages": [{"role": "user", "content": "Say hello in five words."}],
       "max_tokens": 64, "reasoning_effort": "none"}'

任何兼容 OpenAI 的客户端都可以使用，base URL 设为 http://127.0.0.1:8081/v1，API key 和模型名称任意填写即可。兼容 Anthropic 的客户端使用 /v1/messages。保持监听 127.0.0.1；如果要开放到网络中，还应设置 --api-key。

模型训练时的上下文长度是 262,144 tokens。Strata 可以通过 YaRN rope scaling 扩展上下文，安装程序会帮你选择方法：

./setup.sh --setup --context 524288

如果从有内存限制的 shell 中运行，请加上 --no-start，然后单独启动服务，具体见上文。安装程序会向引擎参数中加入 --max-context 524288 --rope-scaling yarn --rope-scale 2。如果使用了自定义 chat template，见下文，操作完成后要检查配置中的 tokenizer 键是否仍指向它。Strata 的文档将这一功能标为实验性，并指出 needle 测试很难区分不同缩放方法的优劣，真实的长文档问答才看得出差别。在我们的机器上，它能在 520K tokens 处找到 needle，解码速度也与 262K 上下文时相同。KV cache 使用 int8，其中 32K tokens 常驻 GPU，因此增加上下文消耗的是 RAM，而不是 VRAM。

为你的 PC 做校准

Strata 提供校准功能，会在你的硬件上测试几项引擎设置，只保留速度提升超过 3% 的改动：

./setup.sh --calibrate --no-start

不加 --no-start，校准完成后会启动服务。请先设置好 VRAM 预留量，停止服务，再运行校准；由于它会加载完整模型，运行方式也应与服务相同，即放在 llm.slice 中，不设内存上限。Strata 估计需要 15–30 分钟。我们用一个小脚本调用了相同的校准函数，也就是 setup.py 中的 calibrate_config，大约 11 分钟完成。在我们的机器上，它选择了：

--pcie-frac 0.35 --spec-min-p 0.70
--adapt-every 1 --adapt-swaps 160 --adapt-decay 0.97

--adapt-* 设置控制自适应 expert 缓存：多久在 RAM 和 VRAM 之间交换一次 expert、每步交换多少，以及历史使用计数以多快的速度衰减。--spec-min-p 0.70 会让 MTP 草稿生成器在不确定时更早停止。CPU worker 数量从 4 调到 15，没有带来差别。

校准程序会报告自己的数据，我们这里最后显示每秒 86.8 tokens，但那是它的内部测量结果。我想要一个自己能控制的结果，于是做了 A/B 测试：分别测试旧配置和新配置，每组之间都重启，两种配置各测两轮。校准前先备份配置，这样你也可以做同样的测试。

我们的测量方法是：通过客户端流式 benchmark 测试 OpenAI endpoint。每组运行八次，交替使用一段约 400 词的荷兰语 prose prompt 和一个编程 prompt，后者要求编写带测试的二分查找函数；采用 greedy decoding，输出 512 tokens，报告中位数。prefill 数据来自指定 prompt 长度下的大海捞针测试。每种长度的 needle 和填充文本都是固定的，因此后续运行可能命中前一次运行留下的部分前缀缓存：prefill 数据应视为近似值。测试时，机器上没有运行其他高负载任务。

前两行数据在当天较早时候测得，当时还没有使用下文介绍的自定义 chat template；A/B 测试中的两组都使用了它。只有同一次测试会话中的数据才适合公平比较，这也是 A/B 配对结果比前两行更重要的原因。

在约 260K tokens 的长度下，校准前后的 prefill 速度介于每秒 3,196–4,205 tokens。作为对照，TabbyAPI 使用 4.05 bpw EXL3 量化版本、同样预留 3 GB VRAM 时，服务端日志报告的解码速度约为每秒 68 tokens；同一个 needle 测试在 254K tokens 长度下，prefill 速度约为每秒 1,780 tokens。服务端日志与客户端流式解码数据的测量方式不同，因此只能认为二者接近，不能直接一一对比。

另一个参考是，Strata 文档中列出的数据：在 AMD Radeon AI PRO R9700（32 GB）上使用同一量化版本，生成故事的速度为每秒 57–60 tokens，生成代码为每秒 82 tokens。显卡和 benchmark 都不同，因此也不能直接一一对比。

速度只有在回答质量过关时才有意义。我们自己做了两项检查。

带隐藏测试的编程任务。 五个任务，每个尝试三次，在 sandbox 中运行，reasoning effort 设为 medium。Strata 搭配 UD-Q5_K_XL，15 次全部通过，480 个测试用例全部通过。TabbyAPI 搭配 EXL3 4.05 bpw，得分相同。结果表明，这些任务太简单，无法区分两个量化版本；它们的差别体现在速度和上下文上，而不是这项得分。

我们自己的工作。 这个 benchmark 包含日常工作中的九个任务，每个都有自动检查器：两个 JavaScript 编写的 Astro helper、两个在 PHP sandbox 中运行的 WordPress PHP 片段、以 JSON 输出的 SEO meta tags、LocalBusiness JSON-LD、一次 Search Console tool call、一份 Search Console quick-win 分析，以及一段荷兰语博客开头。每种设置运行两轮，满分 108 分：

思考更多并没有更好：xhigh 两次触及 token 上限，还生成了一次错误的 tool call，耗时是 medium 的 2.6 倍。Strata API 默认使用 high，所以我们的客户端会发送 "reasoning_effort": "medium"。采样方式在这个 benchmark 中也没有影响：greedy、temperature 0.7 和 temperature 1.0 都拿到 108 分，速度也相同。如果配置中没有 sampling 块，Strata 默认采用 greedy decoding。

如果需要，可以自定义 chat template

我们经常写荷兰语，而模型喜欢在荷兰语文本里夹杂英文词。在 system prompt 中加一条简短规则会有帮助。Strata 会从配置中 tokenizer 键指向的文件夹里读取并渲染 chat_template.jinja。因此，你可以新建一个文件夹，放入指向模型包中 tokenizer 文件的符号链接，再加上自己的 chat_template.jinja，然后让 tokenizer 指向这个文件夹。不要修改模型包本身的文件，以免安装或更新时覆盖你的改动，或因这些改动而出问题。

有两点需要了解。Strata 只会把 chat_template_kwargs 中的 enable_thinking 和 reasoning_effort 传给模板，因此你自己的模板变量无法按请求切换：修改模板就意味着要修改配置并重启。另外，要实际测量效果：在我们每组都重启的 A/B 测试中，这条规则让 30 个荷兰语回答中出现的英文词从 28 个降到 13 个；在我们的实际用例 benchmark 中，没有测出速度差异，分别为每秒 79.8 和 80.3 tokens。它增加了约 350 个 prompt tokens，这部分可以被 prompt 缓存消化。

剩余 RAM 才是真正的限制。 在这台机器上，Strata 运行后只剩约 4 GB RAM。一个开了很多标签页的浏览器，或第二个 Agent 进程，就足以把引擎的一部分挤进 zram。出现这种情况时，服务端日志中的解码速度会从每秒约 80 tokens 降到 40–55 tokens。可以通过 free -g、swapon --show，以及引擎进程 /proc/<pid>/status 中的 VmSwap 行检查。让它单独运行，不要同时运行另一个模型运行时、游戏或 GPU 挖矿程序。

四条 DIMM 在 EXPO 速率下不稳定。 我们的四条内存标称速率都是 6,000 MT/s，但在这个速率下，机器记录了 "Bad page state" 错误和 kernel oops，并发生崩溃。更糟的是，在那段时间写入磁盘的某次模型下载，大部分内容都损坏了。现在我们使用第二套 EXPO 配置，运行在 5,600 MT/s，并用 Hugging Face 公布的 SHA-256 校验每一个模型文件。Strata 的安装程序会校验它自己下载的文件；其他方式下载的文件，需要你自己校验。

等 VRAM 释放后再启动。 停止一个运行时后，VRAM 需要几秒钟才会释放。过早启动下一个运行时，可能无法通过 VRAM 检查，或者留给 expert 缓存的 VRAM 更少。

使用新的 prompt 测量。 Strata 会缓存 prompt 前缀。反复使用同一个长 prompt，会得到高得离谱的 prefill 数据。每次测试 prefill 时都要更换 prompt，至少更换开头。

同样这 128 GB RAM，也能通过 Project Maya 运行一个 321B 模型 GLM-5.3-Flash。Project Maya 是专门为该模型构建的 Strata fork。它的速度只有这套配置的三分之一，但模型大得多，而且能在不增加 VRAM 占用的情况下读取最多 512K tokens。我还写了一篇配套文章，介绍这套配置及其实测数据：《在单张 RTX 5090 上，通过 Project Maya 和 EXL3 本地运行 GLM-5.3-Flash（321B）》。

如果你正在决定购买什么硬件来本地运行 AI，Voltti 有一篇实用指南，讨论了企业使用场景下本地 AI 与云端 AI 之间的取舍。

如需采取进一步措施，可以考虑屏蔽此人和／或举报滥用行为。