过去，125B 级 MoE 模型几乎默认只属于服务器：几百 GB 显存、机架式部署、云端调用。现在，Strata 尝试把这类模型塞进一台普通游戏 PC，并且让数据不离开本机。根据一篇面向工程师与研究者的实测分析，在 RTX 5090 上，一套 125B 级、24,576 个 experts 的 MoE 模型通过 IQ3_S 量化后被实际加载并运行。这件事的重点不在于“跑起来了”这个结果，而在于它如何绕开显存不足、性能代价落在哪里，以及本地部署到底值不值。
83.6GB 权重装进 32GB 显存，靠的不是压缩魔法
从硬件条件看，这次部署并不符合直觉。模型经过 IQ3_S，约 3.5-bit 量化后，权重总量仍有 83.6GB；RTX 5090 的可用显存约为 32,607MiB，即约 31.8GiB。两者之间存在 2.6 倍差距，这不是通过常规参数调整就能填平的缺口。
Strata 的思路不是继续压缩模型，而是利用 MoE 的结构特点做资源调度。MoE 模型虽然总参数量很大，但每个 token 只会路由到少量 experts。稠密模型的算力需求通常与总参数量相关，而 MoE 的算力需求更接近激活参数量；问题在于，显存占用仍然取决于总参数量。换句话说，MoE 降低了算力门槛，却没有降低存储门槛。消费级显卡恰好呈现相反状态：算力相对富余，显存明显不足。Strata 把这种“不匹配”转成可工程化的任务：显存放不下的部分，通过分层加载、专家缓存和流式调度来处理。
实测日志显示，系统会加载 46.84GiB 的专家数据，加载速度约 0.24GiB/s，耗时约 228 秒。专家缓存自动分配约 24.52GiB 可用空间，形成 9527 个槽位，后收缩至 11784 slots / 22.36GiB。MTP draft layer 加载占用 835MiB 显存，其中 experts 部分 675，dense 部分 111。KV 缓存方面，系统在显存中保留 32768 / 131072 个 cell，每层 QSA 的 K/V 数据另有 1.55GiB 放在 pinned RAM 中。
性能关键不在“算得快”，而在“少搬运”
在显存不够的情况下，真正影响体验的是带宽和调度效率。每个 token 都可能需要调用不同专家，如果专家不在显存里，就需要从更慢的存储层搬运。Strata 的架构因此被拆成多个层级：显存中保留高频专家，其余专家放在内存或磁盘侧，KV 缓存也采用部分驻留显存、部分流式访问的方式。
这种设计的代价很直接：长上下文时速度会变慢，但能腾出更多显存给专家缓存。素材中提到，KV 使用 int8，每个 cell 占 1,056 字节，若使用 q4_0 则为 576 字节；系统只把前 32,768 个 cell 锁在显存中，超出部分走 RAM 流式，并用 1.55GiB pinned RAM 做窗口。这是一种显式取舍：牺牲部分长上下文性能，换取模型主体能跑起来。
为了降低逐 token 搬运专家的成本，系统引入了投机解码。由较小的 MTP draft layer 先预测后续若干 token，再交给大模型并行校验。这样多个 token 可以共享一次专家搬运，成本被摊薄。摊薄效果取决于预测接受率，而接受率又与文本可预测性相关，因此生成速度会随内容类型波动。这一点也说明，本地跑超大 MoE 并不存在单一固定速度，性能表现会受任务形态影响。
部署难点暴露：下载校验、环境隔离和静默失败
这篇实测最有价值的部分，不只是“能跑”，而是把部署过程中的三类真实故障摊开来看。它们都不是简单的配置错误，而是工具链假设、下载校验机制和静默失败带来的工程风险。
第一类问题来自 Python 环境。安装脚本会自动寻找 Python，而测试机上的 py -3 指向一个损坏解释器，执行简单命令时会报 ModuleNotFoundError: No module named ‘encodings’。同时宿主工具链会向子进程注入 PYTHONPATH，导致新建的 venv 继承错误模块搜索路径，pip list 显示的包甚至不属于该 venv。素材给出的处理方式是清空 PYTHONPATH 和 PYTHONHOME，并用原生 Windows 路径创建虚拟环境，避免 MSYS 风格路径导致目录未真正创建却返回 exit 0 的问题。
第二类问题来自模型下载。83.6GB 模型需要分片下载，第一次下载 28.8GB 的 shard2 时，脚本在 19.3GB 处就显示“成功完成”。原因在于下载逻辑依赖 HEAD 请求返回的 Content-Length，但 ModelScope 的 resolve 端点在 HEAD 时不返回该字段，导致校验逻辑被跳过，并写入 .done 标记。更危险的是，这个标记会被后续流程视为“该步骤已完成”。
重新下载后，文件长度正确，但全量哈希不一致：实际哈希为 8ae37d5797657c00e47cc61eefc88c5b574e7798807d7920a443115b46b2da39，预期为 316b46f3a2dbd68c900f43136ab9449f9dcc3725dfd8c794847c204bc161e113。进一步排查发现，下载器只检查了状态码，没有检查 Content-Range 的区间起点是否与本地已有偏移一致。一旦 CDN 或缓存代理返回错位的 206 内容，错误字节会被直接追加进文件。素材还记录了一次误判：通过稀疏采样检查 6 个偏移点均匹配，甚至平行扫描 200/430 个块也未发现异常，但全量哈希仍证明文件损坏。这带来的结论很明确：大文件完整性只能依赖全量哈希，采样检测无法替代。
本地部署的意义：数据不出机器，但工程门槛仍然很高
从部署流程看，Strata 需要克隆源码、建立隔离虚拟环境、执行硬件自检、选择模型源并启动服务。测试中，模型下载源被明确选择为 ModelScope，因为 HuggingFace 不可达；同时作者对 ModelScope CDN 做了并行扫描：1 连接 1.73，4 连接 4.46，8 连接 4.97，16 连接 5.26 MiB/s。虽然总速度提升，但每连接速度从 1.73 降至 0.22 MiB/s，说明瓶颈更接近每 IP 封顶，而不是服务端限速，单纯增加并行下载数并不能显著提速。
冷启动方面，专家装载 46.84GiB，速度 0.24GiB/s，耗时 228 秒；加上 GPU 专家缓存填充，到 /health 返回 loaded: true 约 3 分钟。部署完成后的基础验证包括接口是否存活、输出是否正常、坏输入是否会拖垮服务。测试请求显示服务默认不设 API key，但只监听 127.0.0.1，符合“不启用密钥就不对外暴露”的安全姿态。
对于本地大模型部署而言，Strata 这次实测的意义不在于证明消费级显卡可以取代服务器，而在于展示了一条可操作路径：通过量化、稀疏激活、专家缓存、KV 分层和投机解码，把原本依赖大容量显存的模型拆解成消费级硬件可以勉强承载的调度问题。它也让本地部署的边界更清晰：数据可以完全留在本机，但代价是更长的加载时间、更高的工程配置要求，以及对下载、校验、环境隔离等基础环节的严格依赖。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/dan-zhang-rtx-5090-pao-125b-moe-strata-ba-da-mo-xing-ben-di
