来源：GitHub (★212)
URL: https://github.com/giannisanni/pulsar
精读日期：2026-09-02
模型：DeepSeek V4 Flash（AI 生成，人工未审校）
正文获取：全文

一、核心论点/事实

1. Pulsar 是一个面向超大规模 MoE 模型的 SSD 流式推理引擎，使用 Rust + CUDA 从零构建（非 C 语言 fork），核心设计是"路由专家驻留 NVMe 按 token 流式加载，决策组件常驻 VRAM"。

2. 在两张消费级 16GB GPU 上实现惊人性能：GLM 5.2 743B 达到 2 tok/s，Hy3 295B 达到 7 tok/s（持续 warm decode，n=64，temp 0）。

3. 零配置多 GPU 支持：自动测量 PCIe 带宽，将 attention 和热门专家放置在合适的设备上。

4. 支持 11 种模型架构，包括 DeepSeek4、Qwen3 35B MoE、GPT-OSS、Laguna、Ornith-397B 等，多数为首次在消费级硬件上运行。

5. Qwen3 35B MoE 混合架构验证：262k 上下文仅需 10/40 层存 KV，45k token 处 needle recall 验证通过，该深度下 decode 速度 19.6 tok/s。

6. 量化策略影响显著：Qwen3 的 Q4_K_XL 解码 51.8 tok/s，而更小的 Q3_K_XL 仅 36 tok/s（IQ3 codebook 查找开销大于 K-quant 的简单移位）。

7. 短生成序列读数偏高：Hy3 在 n=32 时 8.2 tok/s，n=64 时降至 6.0 tok/s，因 per-token SSD miss rate 尚未达到稳态。

二、方法/架构拆解

核心架构

  • 分层存储策略：路由专家（routed experts）存放在 NVMe 上按 token 流式读取；注意力层、路由器等决策组件常驻 VRAM。
  • 流行度普查（popularity census）：首个完整运行周期内构建专家访问频率统计，据此将热门专家提升至驻留层（resident tier）。
  • 多 GPU 自动放置：测量 PCIe 带宽后，将 attention 和热门专家分配到最合适的 GPU。

支持的模型架构（关键实现要点）

  • DeepSeek4：4 流超连接残差 + Sinkhorn 门控；滑动窗口上的 sink attention + 流式压缩 KV；fp8/fp4 缓存量化感知模拟；早期层 token-id 哈希路由；首次运行即输出正确结果。
  • Qwen3 35B MoE 混合架构：每 4 层中 3 层用 Gated DeltaNet 线性注意力（O(1) 循环状态），其余层用 sigmoid 门控全注意力；262k 上下文仅 10/40 层存 KV。
  • GPT-OSS：softmax 分母中的 per-head attention sink；交替滑动/全注意力；attention 投影和每个专家均有 bias；MXFP4 路由专家。
  • Laguna：每第 4 层为全窗口注意力，其余为滑动窗口 512；per-head 输出门控；按层类型区分 RoPE（全窗口层用 YaRN，滑动层用普通 RoPE）。
  • Ornith-397B：512 路 sigmoid 门控路由器 + 共享专家，Q2_K 专家量化；Gated DeltaNet 线性注意力；单张 32GB GPU 端到端运行。

测试环境与基准

  • 参考测试机：RTX 5060 Ti 16GB + RTX 4060 Ti 16GB，Ryzen 9900X，30GB RAM。
  • 基准规范：所有数字为持续 warm decode，n=64，temp 0，第二次运行起计；需 warm census 后测量。
  • 量化工具：pulsar-quant --map "_exps.=q2_k" --default q8_0（专家 Q2_K / 其余 Q8_0 混合）。

ThinkingCap-27B（首个全稠密架构）

  • 无流式、无分层——模型完整跨两张卡，每层完整栈（attention/Gated DeltaNet、KV、FFN 三元组）驻留单一 owner 卡。
  • 原生 K-quant，warp-cooperative Q4_K/Q6_K matmul 配合 q8_K 激活。
  • 残差流每 16-token chunk 跨卡两次。
  • 投机解码使用模型自身 nextn/MTP 层，深度 3 时贪心接受率 85%；验证轮次需快照循环 GDN 状态（delta-rule 状态在拒绝草稿后不可覆写）。

三、值得注意的局限/争议

作者承认的局限

  • 短生成读数虚高：n=32 时 Hy3 为 8.2 tok/s，n=64 时降至 6.0 tok/s，SSD miss rate 需时间达到稳态。
  • 部分数据未按新标准重测：标 † 的数字在 n=64 标准化前测得，且模型已删除无法重跑，实际持续速率可能略低。
  • Ornith-397B 数据不完整：†† 标注——在不同硬件（3090 + V100 32GB，128GB RAM）上仅跑过 15-token 冷普查冒烟测试，非正式基准，速率列留空。

AI 判断的潜在问题

  • 冷启动问题：流行度普查依赖首个完整运行周期，冷 census 下性能会显著偏低，实际部署中首次使用体验可能不佳。
  • SSD 寿命与延迟波动：按 token 流式读取专家对 NVMe 耐久性和延迟一致性有要求，消费级 SSD 在长时间运行下的表现未提及。
  • 量化精度风险：Q2_K 专家量化（Ornith-397B）和 MXFP4（GPT-OSS）在复杂推理任务上的质量损失未提供评测数据。
  • 可复现性存疑：性能数字依赖特定硬件组合和 warm census 状态，跨环境复现难度较大。

四、与 RRLab 研究的关联

Harness 工程

  • 分层存储调度思想可借鉴：将"热/冷"数据分离的思路可推广到评测 harness 的模型加载管理，减少显存压力。
  • 零配置多 GPU 自动放置：自动测量 PCIe 带宽并分配任务的思路，可用于 RRLab 多卡评测环境的自动化配置。

多模型协同

  • 11 种架构统一引擎：单一推理引擎支持多种 MoE/混合架构的经验，对 RRLab 构建统一评测后端有直接参考价值。
  • 投机解码 + 状态快照：GDN 状态快照机制（delta-rule 状态不可覆写）对多模型协同推理中的状态管理有启发。

模型评测

  • 基准规范意识：明确标注 warm/cold census、n 值、temp 等条件，且所有数字来自统一脚本——RRLab 评测应强化此类标准化。
  • 量化策略对速度的非直觉影响：Q4_K_XL 快于 Q3_K_XL 的发现提醒评测时需同时关注量化类型与硬件特性，而非仅看模型大小。

Agent 落地

  • 消费级硬件跑超大模型：2×16GB GPU 跑 743B 模型的能力，为 Agent 在本地/边缘设备部署大模型提供了新路径。
  • SSD 流式推理的延迟特性：短生成（n=32）比长生成（n=64）快 37%，对 Agent 短交互场景是利好，但需注意稳态性能。

AI 原生产品

  • "硬件没资格跑但能跑"的工程哲学：Pulsar 展示了通过极致工程榨取消费级硬件潜力的可能性，对 RRLab 面向开发者的工具产品定位有启发。
  • 首次运行正确性：DeepSeek4 首次运行即输出正确结果，说明工程验证流程扎实，值得 RRLab 在发布工具时借鉴。

本笔记由 DeepSeek V4 Flash 自动生成，未经人工审校。原文链接：https://github.com/giannisanni/pulsar