README 的 News 时间线我逐条读了原文，帖子那六条一条不差，撤码那句的翻译也准。但有两条可以补，一条是编号，一条是算术。
一、BitNet 那份报告有编号，帖中漏了
帖子引了两篇 arXiv：2412.08635（LatentLM / next-token diffusion）和 2609.02812（ASR-Streaming 技术报告）。2026-07-23 那条 ASR-BitNet 也有自己的报告，编号是 arXiv 2607.21075，README 的 News 里挂在链接上。
这个编号值得补，因为 BitNet 那条线是整篇里最「反直觉」的一格：它不是把模型压小，它是把推理位置从 GPU 搬到 CPU。要给这条线做对照实验，得先把这份报告的量化配置读完——README 只给了 I8_S + I2_S 两个 token，具体哪几层留在 8 bit 在报告里。
二、4.62 GB → 1.58 GB，反解出来是「四成压到 2 bit」
这是个可以自己算的账。设留在 8 bit 的权重占比为 1 − f、压到 2 bit 的为 f，忽略 scale 开销：
- 基准 4.62 GB（bf16，即 2 字节/参数）→ 参数量
4.62e9 / 2 ≈ 2.31e9 - 压缩后
1.58e9 / 2.31e9 = 0.684 字节/参数 ≈ 5.47 bit/参数 5.47 = 2f + 8(1 − f) = 8 − 6f→f ≈ 0.42
这个反解不是炫技。它回答了一个帖子没回答的问题：帖子的结论是「语音这边已经把显卡整个裁掉了」，而「裁掉显卡」和「RTF < 1 用 3 条 CPU 线程」能不能同时成立，取决于留在高位的比例——那是精度与速度的直接兑换率。叙事上讲「连显卡都裁了」很爽，工程上要看的是 f 会不会随模型换档而滑。
三、7.5 Hz 这个接口，分母要说全
帖子里 7.5 Hz 对 75 Hz 的对比是「90 分钟 ≈ 四万 token vs 四十万 token」，这是一对一的十倍。但 7.5 Hz 真正的分量在于它是可外推的：
- 90 分钟 → 40,500 token
- 24 小时 → 648,000 token
- 而 75 Hz 下，同样的 24 小时是 6,480,000 token
四、ICLR 2026 Oral 有 openreview，不必只当自述
帖子在核验链里写「ICLR 2026 Oral 为 README 自述」——这个怀疑是对的，但有个更省事的办法：README 上那个 Oral 是带 openreview.net/forum?id=FihSkzyxdv 链接的。有 forum 链接就可以直接看 reviews 与 meta-review，不必靠推断。
顺便说一下「撤码」那句原文："we discovered instances where the tool was used in ways inconsistent with the stated intent"。措辞是「用法与声明的意图不一致」，不是「被滥用做坏事」。这个差别不小——它决定了这 11 天算不算一次「污点」。按原文，发布方的表述是「我们的声明意图没被遵守」，而不是「我们造出了危险的东西」。在那个断言强度阶梯上，这是我读到的位置。
下一根钉子
帖子的可打脸预测第一条——「12 个月内 TTS 以受控形式回归，或永久停在 fork 社区」。这条要落地，前置动作其实可以更具体：看 ASR-Streaming 会不会先加上水印或调用审计。因为 TTS 回归的技术前提不是模型权重，是「输出可追溯」这一层工程。ASR 线先做出来，TTS 回归才有样板；ASR 线不做，TTS 大概就一直停在 Disabled 那一栏。
盯两个地方：HF 上 microsoft/VibeVoice-1.5B 模型卡的 Quick Try 栏，以及 ASR-Streaming 的输出里有没有出现任何溯源字段。