# 内存不够SSD凑：台式机跑百B大模型 今天上午翻 Hacker News 的 Show HN 新帖区，捞到了一个相当“离经叛道”的项目：**不升级内存、不改模型权重，直接把 436GB 的专家权重放在 NVMe 固态硬盘上按需流式读取，在 32GB 内存 + 一张 RTX 5080 的普通台式机上跑百B级 MoE 模型**。这个思路目前国内社区几乎没人讨论。除此之外，本周还有一个给 Claude Code 做“X光透视”的记账神器、一个自托管党必看的大版本更新，以及几个值得收藏的小工具。全部免费开源，看完就能上手。 --- ## 一、MoE-Direct：你的内存不再是模型大小的上限 **链接**：https://github.com/tmxkzm1925-max/MoE-Direct **价格**：免费，MIT 开源（基于 llama.cpp，MIT） **平台**：目前仅 Windows x64 + NVIDIA CUDA（Linux/macOS 在路线图上） ### 它到底做了什么 MoE 模型（Mixture of Experts，混合专家）有个天然特性：每个 token 只激活少数几个专家，比如 Qwen3.5-122B 有 256 个专家但每个 token 只用 top-8。这意味着**绝大部分权重在任意时刻都是“沉睡”的**——那为什么非要把它们全塞进内存？ MoE-Direct 的答案：把专家权重留在 NVMe 上，路由器决定激活谁，就从硬盘按需读取谁。根据 README 的描述，它**不做重新量化、不改路由逻辑、不修改权重**，甚至每个专家字节都会与原始 GGUF 做 SHA-256 校验——保证输出和“正常加载”是同一个模型。 ### 实测数据（参考机：32GB 内存 + RTX 5080 + Gen5 NVMe） | 模型 | 硬盘上的专家数据 | 实测表现 | 官方评级 | | --- | --- | --- | --- | | Qwen3.5-122B Q4_K_M | 72.8 GB | 5.59–5.69 tok/s 持续解码，比同一二进制走普通 mmap 快约 2.3 倍 | OFFICIAL（过了发布门禁） | | gpt-oss-120b MXFP4 | 61 GB | 12/12 条贪婪解码响应与原版逐 token 一致 | OFFICIAL | | Kimi K2.6（1T 级混合量化） | 436 GB | 1.03 tok/s，输出连贯，服务端约 19 秒就绪 | PROBE（性能门禁未过） | 最大的模型约为内存的 **13 倍**。演示视频里全程开着任务管理器，系统内存始终低于 32GB。 ```mermaid flowchart TD A[你的 GGUF 模型文件
专家权重 61GB ~ 436GB] --> B[一次性 Repack
重排专家布局 + SHA-256 校验] B --> C[推理请求到来] C --> D{Router 决定
本 token 激活哪些专家?} D --> E[仅从 NVMe 流式读取
被激活的专家权重] E --> F[GPU 计算
系统内存始终 < 32GB] F --> G{还有下一个 token?} G -->|是, 复用前缀缓存| D G -->|否| H[输出结果] ``` ### 上手只要三步 1. 从 Releases 下载运行时 zip 和 `SHA256SUMS.txt`，右键属性勾选“解除锁定”后解压（README 给了一段一键校验哈希的 PowerShell）； 2. 按 `docs/models.md` 的指定版本下载对应 GGUF 全部分片，放到 `<盘符>:\moe-models\` 下，双击 `Start-MoeDirect.cmd` 选模型； 3. 批准一次性 repack（会先显示磁盘占用和时间，实测 122B 模型约 18 分钟内完成），然后用任何 OpenAI 兼容客户端连上它打印的地址即可。 另外 v0.3 起支持“虚拟 repack”：不复制数据、只写一个约 6MB 的清单文件，直接从你现有的 GGUF 里读专家，磁盘零额外占用。 ### 泼点冷水（作者自己写的） - **仅限 MoE 模型**，稠密模型无收益；模型装得进内存的也用不着它； - **不是一键安装的成品**，是“hands-on preview”，坑都写在文档里而不是藏起来； - 1.03 tok/s 的 Kimi K2.6 只能算“能跑通”，作者明确标注不要围绕它做交互式规划； - Windows SmartScreen 会告警（构建未签名），需自行校验哈希。 ### 为什么值得关注 + 国内对比 国内玩本地模型的默认路径是 Ollama / LM Studio / llama.cpp，共同前提是“模型体积 ≤ 内存+显存”，超了就只能换小模型或上多卡。MoE-Direct 把约束从“内存容量”改写成“**SSD 顺序读取速度**”——而 2TB NVMe 的价格还不到 64GB 内存的一半。对国内想本地跑 Qwen3.5-122B 这类开源 MoE 又不想掏钱堆内存/组多卡的用户，这是一条全新的、可验证的路线（所有数字附测量协议，Qwen3.5-122B 是官方参考验证级别）。 **适用人群**：想本地部署开源 MoE 大模型但预算有限的独立开发者、隐私敏感场景（数据不出本机）、以及想研究推理 IO 优化的工程师。需要 Windows + N 卡，纯 Mac 用户暂时无缘。 --- ## 二、seedeep：给 Claude Code 的账单装一台 X 光机 **链接**：https://github.com/duqaxxX/seedeep **安装**：`npm i -g seedeep && seedeep`（或直接下免运行时的单文件二进制） **价格**：免费，MIT 开源 每个重度 Claude Code 用户都有一笔糊涂账：一个 turn 里到底发生了什么？多少 token 花在了重复读上下文上？subagent 各跑了什么模型、烧了多少钱？终端只给你一个转圈的光标。seedeep 的思路很聪明——**Claude Code 本来就会把会话日志写到磁盘，它直接 tail 这些日志，实时重建整个 turn**：上下文窗口涨到哪了、每次 API 调用的延迟和 token 拆分、每次工具调用的结果、每个 subagent 挂在谁名下、跑在哪个模型上。**只读、无代理、无守护进程，会话内容不出你的机器**。 几个终端永远不会告诉你的事，它都能抓出来： - **失败的 API 调用会静默终止 turn**（登录过期、额度上限、服务过载），终端看起来一切正常，最后一行就是错误本身——seedeep 直接把标签页标红、菜单栏图标变红； - **权限确认对话框不写日志**，“停在等你批准”和“还在思考”在终端里一模一样——seedeep 读 Claude Code 的实时状态，第一时间变黄并告诉你它在等哪条命令的批准； - **subagent 花费在终端不可见**，而它的实时树把每个 subagent 的上下文填充、真实模型、返回给主会话的原话全部展开。 最狠的是作者附了自己的测量数据：2026-08-25 对一台机器上 770 个会话文件、34,724 次 API 调用的统计——**98% 的被处理 token 是缓存读取，输出只占 0.3%**；按实际成本加权后，**反复重读的旧上下文占账单的 71%**。换句话说：你以为你在为“AI 生成”付费，其实大头在为“AI 复习”付费。这个测量脚本开在 `docs/features.md`，可以跑自己的会话验证。 另一个细节很戳痛点：turn 结束时会跑 7 个确定性检查（无 LLM 参与）给这次 turn 的浪费打分，每条都引用 Claude Code 官方文档作为依据。在 Claude Code 里执行 `seedeep install-command` 还能装一个 `/seedeep` 命令，直接报告当前会话花了多少钱。 **国内对比**：国内用户统计用量常见两条路——抓包代理网关（配置麻烦，之前介绍过的 API 网关方案属于此类）或者粗糙地 grep 日志。seedeep 走的是第三条路：不拦截任何流量，直接读官方自己写好的日志，零风险零侵入。对被“额度 10 分钟烧光”困扰的 Claude Code 重度用户，这是目前最省心的可视化方案。 **适用人群**：所有 Claude Code / 订阅制编码 Agent 的重度用户，尤其是想知道“钱到底花哪了”的团队负责人。 --- ## 三、vLLM v0.28.0：自托管党的情报藏在 release notes 里 **链接**：https://github.com/vllm-project/vllm/releases **价格**：免费开源（Apache 2.0） **热度**：5 小时前上了 HN 首页（84 分） vLLM 是国内外自托管推理的事实标准之一，所以版本更新本身不算新闻。**信息差在 release notes 的细节里**——它是一份“海外推理基础设施在认真对待哪些开源模型”的晴雨表： - 本版 **584 个提交来自 270 位贡献者**（76 位新人），其中最大的一块是 **Kimi-K3 性能专项**：Decode Context Parallel 支持、融合 FlashKDA 解码/预填充内核、自适应投机 token 预算带来约 60% 的 DSpark TTFT 改善、共享专家分片每个 GPU 省约 17GiB 显存，还上了 AMD ROCm。一个模型在同一版本里获得这种全栈优化力度，说明它已经被海外大规模部署场景当成“主力选手”； - **DeepSeek V4** 的稀疏 MLA 打通了普通解码、MTP 和 DSpark 投机解码全链路； - **分层 KV cache 卸载**新增磁盘层，配合 MoE-Direct 那篇的思路看很有意思——推理引擎整体正在往“显存/内存/SSD 分层”演进； - 默认值变化：`max_num_batched_tokens` 从 8192 提到 16384，Mamba 模型默认开启前缀缓存。 **升级前注意两个 breaking change**：bitsandbytes 支持迁出了主仓库（改为树外插件），Transformers 升到 5.15.0，生产环境建议先在 staging 验证再升。 **适用人群**：自己部署开源模型做服务的后端/平台工程师。 --- ## 四、快讯：3 个刚冒头的小东西 都来自今天早上的 Show HN 新帖区，太新所以只有标题级信息（在 news.ycombinator.com/shownew 搜标题即可找到原帖）： - **Documentation.ai.md**——号称“给 AI agent 看的文档标准，不是给人看的”。继 llms.txt 之后，“如何让仓库对 Agent 可读”正在成为独立赛道，国内讨论还很少； - **SSH Ache**——开源桌面 SSH 客户端，集成了 SFTP、隧道和 **MCP**。SSH 客户端加 MCP 意味着你的服务器会话可以直接暴露给你的编码 Agent，运维方向值得盯； - **Stop That Shit**（github.com/lennney）——名字很粗俗，功能很精准：拦截编码 Agent 擅自增删 Markdown 标题的 `#` 号。这个痛点大到有人专门做了个工具，本身就是条新闻。 顺带一提，HN 首页今天还有 197 分的 StemDeck（本地免费音乐分轨工具），再次印证“音频处理全面本地化”的赛道热度，此前已介绍过同类工具，不赘述。 --- ## 信息差总结 | 你以为的 | 实际情况 | | --- | --- | | 本地跑大模型必须“内存 ≥ 模型体积” | MoE-Direct 把专家权重留在 NVMe 按需流式读取，32GB 内存实测跑起 72.8GB 的 Qwen3.5-122B（5.6+ tok/s），上限取决于 SSD 速度 | | Claude Code 的钱花在“生成”上 | 据作者对 3.4 万次 API 调用的测量，按成本加权 71% 花在重复读取旧上下文，输出仅占 0.3% | | 会话卡住只能干等 | 8 成的“静默失败”（API 报错、等你批准权限）终端不提示，seedeep 这类日志透视工具能实时标红 | | 版本更新没什么可看 | vLLM 的 release notes 是判断“哪些开源模型被海外生产环境认真对待”的最快情报源 | ## 行动指南 1. **今天就能做**：如果你有一台 Windows + N 卡 + NVMe 的机器，去 MoE-Direct 仓库下载 runtime，选 `Qwen3.5-122B-A10B Q4_K_M`（官方参考验证级别）跑通第一条命令； 2. **5 分钟**：在常用开发机上 `npm i -g seedeep && seedeep`，让它陪你跑半天 Claude Code，然后看 Home 页的浪费分布——大概率会让你重新规划 subagent 用法； 3. **本周**：自托管 vLLM 的团队，在 staging 跑一遍 v0.28.0，重点测试 Kimi-K3/DeepSeek V4 相关路径和新的默认参数对现有业务的影响。 ## 参考来源 1. MoE-Direct（GitHub）：https://github.com/tmxkzm1925-max/MoE-Direct 2. seedeep（GitHub）：https://github.com/duqaxxX/seedeep 3. vLLM v0.28.0 Release Notes：https://github.com/vllm-project/vllm/releases 4. Hacker News Show HN 新帖区（2026-08-30 采集）：https://news.ycombinator.com/shownew 5. Hacker News 首页（2026-08-30 采集）：https://news.ycombinator.com/ --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护。 > 聚焦5G/6G核心网、3GPP标准、AI工具实战。知识星球「51学通信」提供深度技术答疑和行业洞察。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。