SparseCore 与 Neuron MatmultSparse 对比

本页中的每个 TPU 侧地址、符号和字面量都读取自 libtpu-0.0.40-cp314 wheel 中的 libtpu.so（build-id 89edbbe81c5b328a958fe628a9f2207d；构建 libtpu_lts_20260413_b_RC00）。其他版本会不同。AWS Neuron 侧仅在架构层面描述 — Neuron 位于另一个二进制中，本页不携带 Neuron 地址。

摘要

两个厂商都提供了名为“sparse matmul”的东西，而名称碰撞很容易诱导出错误结论。Google 的 TPU 有 SparseCore — 一个片上协处理器，从 HBM 收集 embedding 行并把它们送入 TensorCore 的密集 MXU。AWS 的 Neuron 编译器有 MatmultSparse — 一个单独的指令集 opcode，在与密集 matmul 相同的 PE systolic array 上运行结构化稀疏密集 matmul。本页判断它们是否属于同一种东西。它们不是：它们处在不同的架构类别中，加速“sparse”的正交含义，并缓解不同的瓶颈。这种命名碰撞具有误导性，真正的功能类比是交叉的（TPU SparseCore 的类比对象是 Neuron 的 IndirectLoad / Gather DMA 家族，而不是 MatmultSparse；Neuron MatmultSparse 的类比对象是 NVIDIA 的 structured-2:4 Sparse Tensor Cores，而不是 SparseCore）。

这是一个定位 / 对比页面，不是任一子系统的重实现页面。TPU 侧由第 IX 部分的相邻页面完整覆盖 — SparseCore 概览、架构、SC ↔ MXU 握手、流式 Gather/Scatter、去重 Multiplicity、SampleCombiner 发射器 — 本页中的每个 TPU 断言都锚定到这些页面已经确立的 libtpu.so 符号或地址。Neuron 侧是对照：它根据公开的 Neuron 架构（PE/State-Buffer/PSUM 模型、2:4 结构化稀疏模式、InstMatmultSparse opcode 叙事）重建，并且只在架构层面呈现。这里不声明任何 Neuron 地址，因为本 wiki 没有分析 Neuron 二进制。

本页结构是先给出一个等价性映射（两条路径对齐的四个结构阶段 — embedding gather、稀疏索引去重、按段归约、密集引擎交接），然后给出差异点（引擎归属、“sparse”的含义、数据路径、成本模型单位），最后总结各模型的胜出场景。建议在 SparseCore 概览和 SC ↔ MXU 握手之后阅读，本页比较的 TPU gather→reduce→MXU 路径由它们建立。

作为定位，契约如下：

标题重点是类别，而不是名称。 TPU SparseCore 是一个专用同级协处理器（自己的 ISA、自己的内存模型、自己的编译器流水线）；Neuron MatmultSparse 是一个 matmul 引擎的指令集模式。把它们作为“两个稀疏 matmul 实现”来比较会同时误框二者。
“Sparse”表示两件无关的事。 在 TPU 上，它是访问模式稀疏 — 从多 GB 表中任意由索引驱动地 gather 行，没有固定比例。在 Neuron 上，它是算术稀疏 — 编译期烘入权重矩阵的结构化 N:M（≈2:4）零掩码，固定约 50% 列跳过。
它们缓解的瓶颈不同。 TPU SparseCore 缓解 HBM 随机访问带宽（保持 MXU 有数据可算）；Neuron MatmultSparse 缓解 MAC 吞吐（把 matmul 的执行周期减半）。一个是内存特性，另一个是计算特性，二者甚至不共享单位。
它们在结构上确有重叠。 二者最终都喂给 128×128 级别的 systolic array；二者都使用侧向“tag/index”流来驱动转换；二者都在编译期规划并在运行期执行；二者都融合了归约/累加。重叠是真实的，但它是 gather-then-matmul 流水线的形状，不是稀疏机制的等价。


TPU 构件	SparseCore — 片上协处理器（SCS/TAC/TEC fabric），TensorCore 的同级
TPU “sparse matmul” 入口	`XlaSparseDenseMatmulOp`（+ Grad / CSR / optimizer-fused / minibatch 变体）— 反编译确认
TPU sparse 含义	任意索引 gather/scatter（访问模式稀疏）；没有固定比例
TPU 密集交接	`tpu_dma_hbm_to_vmem_sc_general`（16 个操作数）→ TC VMEM → MXU；在 `Target::MxuContractingSize` 上归约
TPU MXU 稀疏模式	`Target::MxuSparseContractingSize` = 每一代都是 0 — MXU 只支持密集；没有结构化稀疏跳过
Neuron 构件	MatmultSparse — BIR opcode 9，在 PE systolic array 上运行（与密集 matmul 相同的引擎）
Neuron sparse 含义	结构化 N:M（≈2:4）权重矩阵掩码（算术稀疏）；固定约 50% 列跳过
等价性结论	不等价 — 架构类别不同；真正的类比对象是交叉的
置信度	TPU 行为已确认（反编译锚定）。Neuron 行为为架构级（此处未分析二进制）

注意 — 本页的来源纪律。 每个 TPU 断言都锚定到某个相邻页面已经验证过的 libtpu.so 符号或地址。每个 Neuron 断言都是无地址的架构级陈述，因为本 wiki 没有分析 Neuron 的编译器二进制。凡是具体描述 Neuron 机制的地方（opcode 编号、三指令 lowering、>> 1 周期减半），都应把它当作公开/架构层面的 Neuron 模型 — 用于凸显 TPU 图景的对照 — 而不是恢复出的二进制证据。下面每张表的两列具有不同的认识论权重，Confidence 列会说明这一点。

被比较的两个对象

TPU SparseCore — 执行 gather 的协处理器

SparseCore 是一块独立硅片逻辑，不是 matmul 引擎的一种模式。带 SC 的芯片具有固定的 4:1 SC:TC 比例（xla::jellyfish::lowering_util::SparseCoreCountPerTensorCore @ 0x1c6cb760，它计算 sparse_core_count_per_chip / tensor_core_count_per_chip 并断言 sparse_core_count_per_chip >= tensor_core_count_per_chip 且 sparse_core_count_per_chip % tensor_core_count_per_chip == 0 — 4:1 比例在所有带 SC 的代际上成立 — 见 SC ↔ MXU 握手）。每个 SC 自身又拆成三个由 tpu::TpuSequencerType 选择的 VLIW 子引擎 — SCS（标量/寻址，type 3）、TAC（tile-access/DMA，type 4，存在于 Viperfish 和 Ghostlite，在 6acc60406 上移除）、TEC（向量计算，type 5）— 这些在 SparseCore 概览中确立。

它加速的是稀疏计算的内存访问侧：DLRM / 推荐系统 embedding lookup 模式，其中成本是对多 GB 表的随机 HBM 访问，而不是算术。它的定义性原语是 HBM 内原子浮点 scatter-add（STREAM_OPCODE_SCATTER_FLOAT_ADD，与 DMA destination opcode DMA_DEST_OPCODE_READ_AND_ADD 配对），MXU 无法执行这种操作 — 见流式 Gather/Scatter。SparseCore 不执行密集 matmul。它把 embedding 行 gather 并 reduce 到 tile 后，TensorCore 的 MXU 消费该 tile 并运行密集 MLP matmul。SC 是供给者；MXU 是消费者。

Neuron MatmultSparse — 跳过零的 opcode

按公开 Neuron 架构，MatmultSparse 是单一统一指令流（BIR）中的一个 opcode，而不是独立引擎。它在常规 PE systolic array 上运行结构化稀疏 matmul — 也就是运行密集 matmul 的同一个阵列。它的父类与密集 matmul 相同，都是抽象 matmul 基类，默认引擎也是 PE 引擎，与密集相同。相对密集 matmul 的额外状态只是一个稀疏掩码引用：这条指令是“密集 matmul 加一个 tag”。Codegen 把它 lower 成 PE 上的短 prologue-plus-matmul 序列 — 加载每个权重 tile 的 sparsity tag，加载（压缩、去零后的）权重 tile，使用该 tag 跳过置零列来运行 matmul。

它加速的是结构化稀疏密集 GEMM 的算术侧：权重矩阵按结构化 N:M 模式剪枝（最常见为 2:4 — 每四个中有两个非零），阵列跳过零列，使 matmul 用更少周期完成。这里没有从 HBM 任意 gather 行；操作数已经驻留在片上 State Buffer 中。Neuron 处理 embedding — TPU SparseCore 存在的那类工作负载 — 使用的是普通 indirect-load / gather DMA opcode，这是完全不同于 MatmultSparse 的机制。

怪癖 — 名称指向同一流水线的相反两半。 “SparseCore”和“MatmultSparse”都含有“sparse”，并且都靠近密集 matmul，所以直观读法会把它们看作同一特性的竞争实现。事实并非如此。SparseCore 加速的是生成 matmul 输入的 gather；MatmultSparse 加速的是 matmul 本身。重实现者如果把一个映射到另一个，就会复现系统的错误一半。功能配对与命名交叉：TPU SparseCore ≈ Neuron 的 gather/indirect-load DMA ops；Neuron MatmultSparse ≈ 一种结构化稀疏 MXU mode — 而 TPU MXU 没有这种模式（MxuSparseContractingSize = 0）。

等价性映射 — 对齐的四个阶段

尽管类别不匹配，推荐/embedding 流水线和结构化稀疏 GEMM 共享同一个四阶段骨架：侧向流驱动数据转换，重复工作被合并，归约被融合，结果交给密集 systolic array。两个厂商在结构上相似的位置实现每个阶段。这是真正的重叠 — 命名每个阶段的 TPU 与 Neuron 实现，是看清等价性在哪里成立、在哪里断裂的最快方式。

text

STAGE            TPU SparseCore (coprocessor)            Neuron MatmultSparse (opcode mode)
─────            ────────────────────────────            ──────────────────────────────────
1 side-stream    index stream drives gather addresses    sparsity tag drives column-skip
   load          (TAC/TEC stream-start prologue)         (LoadTags prologue instruction)

2 dedup /        TEC DuplicateCountFloat / Uniquify       (no on-device dedup — the N:M mask
   collapse      collapse repeated embedding ids          is static, baked at compile time)

3 reduce /       TEC segmented reduce-by-sample           PSUM accumulate (CalcStart/Stop/Accu);
   accumulate    (+ in-HBM SCATTER_FLOAT_ADD on bwd)      same accumulate flags as dense matmul

4 dense          SC tile -> VMEM -> MXU systolic array    PE systolic array runs the sparse
   handoff       (separate engine, SFLAG handshake)      matmul itself (no engine crossing)
```text

### 阶段 1 — 驱动转换的侧向流

两条路径都携带不是 bulk data 的侧向通道：它*引导* bulk data。在 TPU 上，该侧向通道是**索引流** — 一串整数行索引，SC stream engine 将其转换为 gather 地址 `HBM[table_base + index_i * row_stride] → TILE_SPMEM`（[流式 Gather/Scatter](stream-gather-scatter.md)）。在 Neuron 上，侧向通道是 **sparsity tag** — 每个权重 tile 的记录，说明剪枝后哪些列保留，在 matmul 运行前由专用 prologue 指令加载。二者都有加载侧向数据的专用 prologue（TPU：TAC/TEC stream-start；Neuron：LoadTags opcode）。在这一抽象层面等价性真实存在 — *tag/index 流驱动数据转换* — 但它驱动的转换相反：TPU 的流选择*从内存取哪些行*；Neuron 的 tag 选择*在阵列中跳过哪些列*。

### 阶段 2 — 重复工作的去重 / 合并

Embedding lookup 有重复索引：同一个表行会被一个 batch 中许多样本请求，gather 一次再广播比反复 gather 更便宜。TPU 在 TEC 中通过 dedup/multiplicity 原语在设备上合并重复项 — `DuplicateCountFloat`（反编译确认为 TEC vector-extended op）统计重复次数，uniquify 路径以 multiplicity 发出每个不同 id（[去重 Multiplicity](dedup-multiplicity.md)）。**Neuron 在这一阶段没有类比物**，因为它的稀疏性是*静态*的：N:M 掩码在模型剪枝时的编译期已经固定，因此没有运行期索引流可去重。这是等价性第一次断裂的地方 — TPU 在索引流上做运行期结构发现；Neuron 的结构在程序构建前已经决定。

### 阶段 3 — 融合的归约 / 累加

二者都把归约融合进路径，而不是物化中间结果再单独归约。TPU 上，TEC 运行**分段归约** — 对每个样本的 gathered 行执行 sum / weighted-sum / max（[SampleCombiner 发射器](sample-combiner-emitter.md)）— 并在 backward pass 中把梯度归约融合进 HBM 内 `STREAM_OPCODE_SCATTER_FLOAT_ADD`。Neuron 上，matmul 使用与密集 matmul 相同的 `CalcStart` / `CalcStop` / `CalcAccu` 标志累加到 PSUM；结构化稀疏 matmul 完全复用密集累加 datapath。二者在更广义的工具箱中也都带有原子累加原语（TPU：向 HBM 的 `SCATTER_FLOAT_ADD`；Neuron：独立的 indirect-save-accumulate op）。结构匹配是真实的 — *归约被融合，而不是单独 pass* — 但归约轴不同：TPU 对*每个样本的 gathered 行*归约；Neuron 对 *matmul 的 contracting dimension* 归约。

### 阶段 4 — 交接到密集引擎

两条流水线都终止于 128×128 级别的 systolic array，这是最强的结构等价性。在 TPU 上，交接*跨越引擎边界*：SC 生成的 tile 通过唯一的直接路径（`tpu_dma_hbm_to_vmem_sc_general`，16 个操作数，反编译确认）进入 TensorCore 的 VMEM，SFLAG sync flag 门控 MXU latch，MXU 在密集 `Target::MxuContractingSize` 上归约（基准 128，Ghostlite 类上为 256）— 见 [SC ↔ MXU 握手](sc-mxu-handshake.md#the-contracting-depth-binding)。Neuron 上则*没有引擎跨越*：稀疏 matmul **就是** PE-array run，操作数已经在 State Buffer 中，输出累加进 PSUM。共同事实是 systolic array 是二者的终端消费者。差异在于到达它是否需要跨引擎 DMA + sync 握手（TPU），还是不需要任何额外跨越（Neuron，同一引擎）。

> **坑点 — TPU MXU 永远看不到“sparse”。** 在 TPU 上，gather/reduce 后的 tile 到达 MXU 时已经是普通密集 activation tile；稀疏性已由上游 SC gather 完全解决。`Target::MxuSparseContractingSize`（@ `0x1d4900c0`）在**每一代**都是 0 — 没有 `Target` 子类覆盖它 — 因此 MXU 运行普通密集 contracting datapath。embedding feed 中没有 sparse-MXU latch。这与 Neuron MatmultSparse 在结构上相反，后者的稀疏性以 column-skip 形式存在于 *matmul 引擎内部*。重实现者不应在 TPU MXU 中寻找结构化稀疏模式；在 TPU 上，稀疏性是上游协处理器关注的问题，仅此而已。

---

## 差异点 — 它们为何不同

### 引擎归属

首要差异。TPU SparseCore 是独立硅块：每个 TC 配四个 SC，自己的三引擎 VLIW fabric，自己的寄存器文件和 bundle 格式（每代 `SparseCore{Scs,Tac,Tec}CodecBase`，[SparseCore 概览](overview.md)）。Neuron MatmultSparse 在与密集 matmul 相同的 *PE systolic array* 上运行 — 按公开 Neuron 成本模型，稀疏和密集 matmul 共享同一个 exec-latency 函数（两个 opcode 名下都可达），这是只有一个 datapath 而不是两个 datapath 的最清晰证明。TPU 侧的等价证明正好相反：这里存在一个完整独立引擎，由 `Target::SupportsSparseCore` 门控（pre-SparseCore Jellyfish/Dragonfish/Pufferfish 代上为 false — 见 [SC ↔ MXU 握手](sc-mxu-handshake.md#partition-assignment--which-sc-feeds-which-mxu)），并且 SC↔TC 边界是显式 DMA + SFLAG 握手。

### “sparse”的含义

| 轴 | TPU SparseCore | Neuron MatmultSparse |
|---|---|---|
| 稀疏性位于 | **访问模式**（读取哪些行） | **权重矩阵**（哪些条目为零） |
| 结构 | 非结构化 — 任意索引、任意顺序、可重复 | 结构化 N:M（≈2:4）— group 内固定模式 |
| 比例 | 无 — 一个 window 可取 1 行或数千行，数据相关 | 固定约 50% 列削减 |
| 何时决定 | 运行期（索引随 minibatch 到达） | 编译期（剪枝把掩码烘入权重） |
| HLO / 格式 | CSR 输入（`XlaSparseDenseMatmulWithCsrInputOp`）描述每个样本的行 | 压缩（去零）权重 tile + position tag |

这些是正交含义。TPU 稀疏性是*数据移动*稀疏 — 矩阵是密集的，*访问*是稀疏的。Neuron 稀疏性是*算术*稀疏 — 访问是密集的，*矩阵*是稀疏的。TPU 的“sparse-dense matmul”名称字面上可解析为“sparse（embedding）*lookup* feeding a dense matmul”；Neuron 的“matmul-sparse”可解析为“其*操作数*稀疏的 matmul”。它们用同一个词指代相反属性。

> **怪癖 — TPU 按设计没有固定稀疏比例。** 来自 NVIDIA 2:4 世界的重实现者会期待固定 N:M 比例和压缩存储格式。TPU SparseCore 二者都没有：`VariableWindowAllocationEstimator`（@ `0x13ca2200`）不编码任何比例 — 它检查一个*不等式*（这个 lookup window 的可变大小 id 集合是否适合 TILE_SPMEM？），不适合就做 mini-batch（[embedding minibatching](embedding-minibatching.md)）。这里的“sparsity”是可变的、数据相关的 window size，而不是结构化掩码。把 2:4 风格比例硬编码到 SparseCore 重实现中是类别错误。

### 数据路径

TPU 数据路径是一个**穿过独立引擎、再经 HBM/VMEM 到 MXU 的多跳流水线**，在引擎边界上带 sync-flag 握手：

```text
indices ─► SCS (address calc) ─► TAC/TEC stream-gather
        ─► HBM[table + idx*stride] ─► TILE_SPMEM (per-tile SC SRAM)
        ─► TEC vector reduce (sum / weighted-sum / max)
        ─► TILE_SPMEM ─► (HBM) ─► VMEM ─► MXU latch ─► dense matmul ─► PSUM

规范的 SC→MXU fastpath 是 SC TEC → TILE_SPMEM → HBM → VMEM → MXU；只有一条直接 SC→VMEM DMA 路线（tpu_dma_hbm_to_vmem_sc_general）和一条 TC→SC 路线，其他所有东西都经由 HBM（SC ↔ MXU 握手）。流水线是 double-buffered — SC 生产 tile N，同时 MXU 消费 tile N−1，由两个 SFLAG 握手协调。

相比之下，Neuron 数据路径从不离开 PE 引擎。按公开架构，压缩权重、tag 和 activation 都驻留在片上 State Buffer 中，并且必须共享 base partition；matmul 在 PE array 中运行并累加到 PSUM。没有 HBM gather，没有跨引擎 DMA，没有 sync-flag 握手 — 整个转换就是一条 prologue 指令加一个引擎内的 column-skip。

成本模型单位

两个性能模型不共享单位，这是类别差异最具体的后果。

	TPU SparseCore	Neuron MatmultSparse
模型类型	内存模型	计算模型
限制资源	HBM 随机访问带宽（credit-arbitrated）	PE-array 周期
指标	随机 HBM 访问的 bytes/sec	MAC cycles，减半（约 2× FLOPS）
加速类型	隐藏延迟（保持 MXU 有数据）	matmul 上约 2× 算术吞吐
调节项	`GetSparseCoreHbmBandwidthAdjustmentFactor`，DMA credit / throttle	exec 阶段的单个 `>> 1` 周期减半

在 TPU 上没有 FLOPS 加速 — SC 几乎不做算术；它的任务是让 MXU 不因 HBM 而停顿。成本模型是按表的 HBM 使用估计和分数带宽份额（GetSparseCoreHbmBandwidthAdjustmentFactor，由 RunMemorySpaceAssignment 引用），并用 starvation timeout（FLAGS_xla_tpu_debug_sc_sflag_wait_timeout_ms）捕捉 SC 未能在 MXU 需要前产出 tile 的情况（SC ↔ MXU 握手）。Neuron 上整个性能叙事是结构化稀疏的周期减半 — 对相同输出形状，稀疏 matmul 的 exec cycles 是密集 matmul 的一半，除去可在大 contracting depth 下摊销的固定 tag-load 开销。一个模型是 bytes/sec；另一个是 MAC cycles。它们不可直接比较。

按代际的可用性

TPU SparseCore 存在性（已确认 — `libtpu.so`）

SparseCore 存在性和引擎名册直接从 codec-class family namespace 与 SparseCore<Engine>* 反编译函数计数读取（SparseCore 概览）：

TPU gen	Codename	Family ns	SparseCore	Engines	Notes
v2 / v3 / v4	Jellyfish / Dragonfish / Pufferfish	—	NO	—	BarnaCore 时代；`Target::SupportsSparseCore` = false
v5p	Viperfish	`vxc.vfc`	YES	SCS + TAC + TEC	第一个三引擎拆分
v6e ("Trillium")	Ghostlite	`gxc.glc`	YES	SCS + TAC + TEC	三个引擎俱全；`GhostliteTarget::MxuContractingSize` = 256
TPU7x ("Ironwood")	6acc60406	`gxc.gfc`	YES	SCS + TEC (no TAC)	TAC 折叠进 SCS+TEC；0 个 `gfc::SparseCoreTac` 符号

Neuron MatmultSparse 可用性（架构级 — 未分析二进制）

按公开 Neuron 架构，MatmultSparse 不存在于最早的 inference-only 代（该架构的 matmul 只支持密集），从第一个 training 代开始出现，并作为 PE-engine 特性继承到后续核心。此列没有地址，只作为 TPU 列的对照；请把细节视为架构级 Neuron 模型，而不是恢复证据。

Neuron arch class	MatmultSparse	Notes
inference-gen-0	NO	此架构上的 matmul 只支持密集
training-gen (introduced)	YES	第一个带 sparse matmul opcode 的架构
later training gens	YES	作为 PE-engine 特性继承；正交的 microscaling/FP-format 模式另行添加

注意 — TPU 根本没有 MatmultSparse 类比物。 Neuron MatmultSparse 在 TPU 上最接近的同级对象不是 SparseCore — 而是密集 MXU 自身的 dtype/precision 模式（例如 MxuContractingSizeIsDoubled 4-bit packed-nibble 路径，SC ↔ MXU 握手）。并且 Target::MxuSparseContractingSize = 0 在每一代上都意味着 TPU MXU 没有结构化稀疏 column-skip 模式。工作结论是，TPU 在内存侧（SparseCore）处理全部稀疏性并运行严格密集的 MXU，而 Neuron 在计算侧处理结构化稀疏性并为内存侧使用普通 DMA。两个厂商沿着稀疏问题的相反分界拆分。

结论 — 不等价

二者不等价；它们占据不同的架构类别。

TPU SparseCore 是一个专用协处理器 — 一个同级引擎（4 SC : 1 TC），具有自己的 ISA、内存模型、编译器流水线和编程模型 — 加速 embedding lookup 的 gather/scatter 内存模式。
Neuron MatmultSparse 是现有 matmul 引擎的指令集模式 — 与密集 matmul 相同 PE array 上的一个 opcode — 加速结构化稀疏密集 GEMM 的算术。

用三种方式表述：（1）引擎归属 — SparseCore 是独立硅片；MatmultSparse 与密集 matmul 是同一阵列。（2）“sparse”的含义 — TPU = 访问模式（gather indices）；Neuron = 权重矩阵掩码（结构化 N:M 零）。（3）缓解的瓶颈 — TPU 缓解 HBM 随机访问带宽；Neuron 缓解 MAC 吞吐。功能类比是交叉的：TPU SparseCore ≈ Neuron 的 indirect-load / gather / scatter-accumulate DMA 家族；Neuron MatmultSparse ≈ NVIDIA 的 structured-2:4 Sparse Tensor Cores。共同的“sparse”一词把错误对象配到了一起。

各自胜出的场景

Workload	Winner	Why
带多 GB embedding 表的推荐系统 / DLRM	TPU SparseCore	为随机 HBM gather + HBM 内原子 FP scatter-add 专门构建；MXU 完全做不了这个
剪枝后的（2:4 结构化稀疏）transformer / CNN 权重	Neuron MatmultSparse	在 compute-bound GEMM 上约 2× MAC-cycle 削减；密集-only TPU MXU 没有等价物
密集 matmul（无稀疏）	平局 — 二者都运行自己的密集 systolic array	两边都会绕过稀疏机制
Neuron 上的 embedding lookup	Neuron 的 indirect-load / gather DMA，不是 MatmultSparse	MatmultSparse 没有 gather；embedding 走普通 DMA
TPU 上的结构化稀疏 matmul	无原生支持	`MxuSparseContractingSize` = 0；TPU MXU 只支持密集

注意 — 这里哪些可恢复，哪些不可恢复。 上面每个 TPU 侧断言都锚定在 libtpu.so 中（XlaSparseDenseMatmul* 家族、tpu_dma_*_sc_* 路线、SparseCoreCountPerTensorCore @ 0x1c6cb760、MxuSparseContractingSize @ 0x1d4900c0、DuplicateCountFloat、VariableWindowAllocationEstimator @ 0x13ca2200）。Neuron 侧只是架构对照 — opcode 编号、三指令 lowering、>> 1 周期模型 — 来自公开 Neuron 架构，不来自本 wiki 分析过的任何二进制，因此不携带地址。核心结论（类别不同、类比对象交叉）对 Neuron 细节是稳健的，因为它依赖的是每个系统的结构事实，而不是任一侧的精确 bit layout。

交叉引用

SparseCore 概览 — TPU 侧全貌：SCS/TAC/TEC fabric、按代际的存在性、embedding 数据路径。
架构 — SC 几何、四级内存模型，以及 embedding datapath 深入说明。
SC ↔ MXU 握手 — gather→VMEM→MXU 边界、SFLAG sync，以及本页依赖的 MxuSparseContractingSize = 0 事实。
流式 Gather/Scatter — indirect-DMA descriptor 和 STREAM_OPCODE_* 集合（包括 HBM 内原子 scatter-add）。
去重 Multiplicity — 折叠重复 embedding ids 的 TEC DuplicateCountFloat / uniquify 路径（等价性映射的阶段 2）。
SampleCombiner 发射器 — 每样本分段归约（等价性映射的阶段 3）。
Binary: extracted/libtpu-0.0.40-cp314-cp314-manylinux_2_31_x86_64/libtpu/libtpu.so (build-id 89edbbe81c5b328a958fe628a9f2207d)
索引项： Part IX — SparseCore & BarnaCore / SparseCore cross-cutting — 返回索引

SparseCore 与 Neuron MatmultSparse 对比 ​

摘要 ​

被比较的两个对象 ​

TPU SparseCore — 执行 gather 的协处理器 ​

Neuron MatmultSparse — 跳过零的 opcode ​

等价性映射 — 对齐的四个阶段 ​

成本模型单位 ​

按代际的可用性 ​

TPU SparseCore 存在性（已确认 — libtpu.so） ​

Neuron MatmultSparse 可用性（架构级 — 未分析二进制） ​

结论 — 不等价 ​

各自胜出的场景 ​

交叉引用 ​