Internal Wiki

主题

每代比较矩阵 ​

此页面上的每个每代常量都是从 libtpu-0.0.40-cp314 轮中的 libtpu.so 中精确字节解码的(构建 libtpu_lts_20260413_b_RC00，BuildID md5 89edbbe81c5b328a958fe628a9f2207d)。二进制文件并未被剥离——每个访问器都是一个经过分解的 C++ 名称； .text / .rodata / .lrodata 映射 VMA == 文件偏移量，.data.rel.ro 映射 VMA − 0x200000 == 文件偏移量。其他版本会有所不同。

摘要 ​

本附录是 libtpu.so 所了解的每一代 TPU 的单一主表 — jellyfish (v2)、dragonfish (v3)、pufferfish (v4, + v4 lite)、viperfish (v5p, + v5e lite)、ghostlite (v6e)、6acc60406 (v7) — 重新实现者需要在每个恢复的硬件常量上并排建模一代：捆绑字节大小、通道/子通道/块几何结构、MXU / XLU / IAR 执行单元计数和尺寸、每层内存容量(VMEM、 SMEM、SFLAG、CMEM、HBM)、成本模型三重奏(LatencyTable / CycleTable / Performance 子类)、本地 DMA 带宽、ICI/PCIe 带宽、加速器核心类型(BarnaCore 与 SparseCore，带有 SCS/TAC/TEC 定序器拆分)以及三个独立版本序号。每列的深度推导都位于专用的成本/ISA/目标页面上；该页面是这些页面指向的跨代索引。

三个事实使得合并值得在一页上进行。首先，几乎每个芯片的几何常量都来自同一个源——嵌入式 <codename>_chip_parts.binarypb 原型，由 TpuChipParts::DefaultsForVersion (0x20b1b040) 选择并在启动时具体化到运行时 Target / TpuTopology 对象中——因此整个矩阵锚定到一个加载路径，而不是分散的 C++ 文字。其次，每代“看起来”的两个常数实际上是稳定的(每代 lane_count = 128、sublane_count = 8、iar_count = 2)；真正的每代 ISA 几何旋钮是 mxu_count (1→2→4→4→2→2) 和 xlu_count (1→1→2→3→2→2)。第三，成本模型在硅架构接缝处将 6 个版本折叠到 5 个类边界上：v2 和 v3 共享一个 LatencyTable 类(仅通过 DeviceIdentifiers 比较分为 PerformanceJf/PerformanceDf)，而 v6e 和 v7 在不同的包装类后面共享 GhostlitePerformance。下面的矩阵使这些合并变得明确。

对于导航，合约是：

  • 主矩阵每代一行，标题常数作为列，每行携带一个置信度。这是规范查找；其余的维基链接在这里。
  • 分组详细表，然后按子系统(几何结构、计算单元、内存层、成本模型类、互连和 BarnaCore↔SparseCore 枢轴)拆分矩阵，因为没有单个 30 列表是可读的。
  • 标注 标记陷阱：在运行时通过字符串比较决定的 Viperfish std/lite 变体分割、v7 6acc60406 丢弃 TAC 序列器、仅 v4 的 CMEM 层以及此构建真正无法确认的单元。
版本轴(内部)tpu::TpuVersion 0..5 — TpuVersionToString @ 0x20b3a480，表 off_22011BF0(6 点)
每芯片几何源<codename>_chip_parts.binarypb → TpuChipParts::DefaultsForVersion @ 0x20b1b040 → FromProto
几何缓存tpu::TpuTopology ctor@0x20acee60(车道→+0x198，副车道→+0x1a0)；通过 Target[+0x3b8] 读取
ISA 几何源VectorIsa 子消息 (mxu/xlu/iar) → Target+0x4ac/+0x4b0/+0x4a8
成本模型工厂LatencyTable::Create @ 0x1c89fba0(版本索引)； CycleTable::Create @ 0x1c89cc00(目标键控)
信心已确认(字节锚定)，除非单元格或标注另有说明

主每代矩阵 ​

每代一行，按 tpu::TpuVersion 顺序。单元格是每个芯片(单张量节点)的标题值；精简版和全芯片增量位于下面的分组表中。 置信度列适用于整行的二元锚定单元格。

一代TpuVer编解码器捆绑包巷×子块/瓷砖MXU(计数×几何)XLUIARVMEMSMEMSFLAGCMEM加速核心成本三重奏
水母 v20jxc41 B128×8161 × 128²1216 MiB16 KiB1 KiB—BarnaCore ×2JF / Jf / PerformanceJf
龙鱼 v31jxc41 B128×8162 × 128²1216 MiB16 KiB1 KiB—BarnaCore ×2JF / Jf / PerformanceDf
河豚 v42pxc / pfc51 B128×8164 × 128²2216 MiB1 MiB2 KiB128 MiBBarnaCore ×4PF / Pf / PufferfishPerformance
Viperfish v5p3vxc / vfc64 B128×8164 × 128²3264 MiB1 MiB2 KiB—SparseCore ×4VF / Vf / ViperfishPerformance
Ghostlite v6e4gxc / glc64 B128×8162 × 256²22128 MiB1 MiB2 KiB—SparseCore ×2GL / Glc / GhostlitePerformance
6acc60406 v75gxc / gfc64 B128×8162 × 256²2264 MiB1 MiB16 KiB—SparseCore ×2Gf / Gfc / GhostlitePerformance

注意 — v7 6acc60406 blob 在此版本中提供(单芯片 tensornode 和 2 芯片全芯片变体)，因此其内存/ISA 常量直接从原始线字节解码。 v2–v6e blob 也嵌入在此版本中(总共 9 个 chip_parts.binarypb blob，在 .rodata 中的 0xbdf29a0.. 中连续)，因此旧一代的车道/子车道/MXU/内存值同样是原始来源的，而不是推断的 - chip_parts HBM/VMEM/SMEM/SFLAG 字节、MXU VectorIsa 和每代频率都是可实现的。成本模型类别选择(LatencyTable/CycleTable/Performance)完全由 TpuVersion 序号通过上述两个工厂决定。

明白了 — lane_count (128)、sublane_count (8) 和 iar_count (2) 不会随一代一起成长。预计通道宽度在 v5/v7 处加宽(如 HBM 时钟和 VMEM 所做的那样)的重新实现者会对每个图块循环进行错误建模。当原型省略字段时，车道/子车道增长是 TpuTopology ctor (0x20acee60) 安装为 128/8 的“持续后备”；每个 blob 还显式地携带 128/8，因此两条路径一致。唯一的每代 VectorIsa 增量是 mxu_count 和 xlu_count。

几何 — 车道/子车道/块 ​

转置/平铺几何体是缓存在 TpuTopology 上的 chip_parts 属性，通过 Target 访问器读取。整个矩阵在各代之间的数值相同，因为每个 blob 的 TensorCore VectorIsa 报告 lane_count = 128，sublane_count = 8。

常数配件值(所有世代)源码
LaneCountTarget::LaneCount @ 0x1d60f400128*(Target[+0x3b8] + 0x198) ← VectorIsa.lane_count
SublaneCountTarget::SublaneCount @ 0x1d60f3008*(Target[+0x3b8] + 0x1a0) ← VectorIsa.sublane_count
ChunksPerTileTarget::ChunksPerTile @ 0x1d60f2c016LaneCount / SublaneCount(idiv，32位快速路径)
Tile 元素计数TpuTopology[+0x1a8]1024LaneCount × SublaneCount(构造函数@0x20acf2e8)

写入路径明确：平台 has-TensorCore 字节 (topo[+0x80]) 上的 TpuTopology 构造函数 (0x20acee60) 门，读取 CoreParts(TENSOR_CORE).SequencerParts(0).vector_isa()，检查矩阵单元 has-bit，然后存储 LaneCount ← vector_isa[+0x0] (@0x20acf2bc) 和 SublaneCount ← vector_isa[+0x4] (@0x20acf2c6)，硬编码的 128/8 后备位于@0x20acf2cc/@0x20acf2dc。然后，Target::Init (0x1d60fc20) 将 TpuTopology* 安装在 Target[+0x3b8] (mov [rcx+0x3b8],rdi) 处。

注意 — 车道/子车道几何形状 不是 由 tpu::TpuChipConfig::Create (0x20ae98e0) 编写。 TpuChipConfig::Create 通过 kChipConfigAliases 平面图 (0x2200b8b0) 解析配置别名并构建驱动程序端内存/队列布局；它不接触LaneCount/SublaneCount。几何图形是 TpuChipParts/TpuTopology 属性，由 MXU VectorIsa 中的 TpuTopology ctor 编写。 MaximumNumberOfChunks 中的 cfg 是 TpuTopology 对象(Target[+0x3b8])，而不是单独的配置结构。

注意 — 哪一代读取哪个 kChipConfigAliases 条目。 kChipConfigAliases (0x2200b8b0) 不是由运行时探测的设备字符串键入的；它是一个静态 gtl::flat_map<tpu::TpuVersionAndVariant, MapView<string_view, string_view>>，恰好有 四个 内联条目，由 TpuVersion 序数 {2, 3, 4, 5} 键入 - 每个条目都有变体 "default"(版本字段是每个 48 字节条目 +0x0 的文字字节： 02/03/04/05，在.data.rel.ro中字节确认)。 TpuChipConfig::Create(TpuVersion, string_view variant) (0x20ae98e0) 查找与 gtl::flat_map::find (0x20afd7c0) 的配对并返回该版本的别名子映射。四个子地图的别名词汇为 default、legacy、megacore、megachip、megachip_tccontrol(.rodata string_views at 0x84f7d8c/0x84be65c/0x86a44a9/0x85c5f87/0x861b61d)。 v4 和 v5 条目(TpuVersion 4 和 5)共享一个 MapView 支持(两个条目 +0x28 都重新定位到 0x2200b9b0)，因此这两代通过相同的子映射解析别名。因此，消费者分割是完全静态的并且按 TpuVersion 进行；每个类型擦除的 MapView 中的确切键→值对是唯一的残差。 [置信度：对于 4 条目版本键控结构、变体 = "default" 键、别名词汇表和 v4/v5 共享子映射，为高 — 所有字节均从 .data.rel.ro/.rodata + find 调用站点读取； MEDIUM 表示内部对方向。请参阅 TpuVersion ↔ 代号矩阵 用于序号→代号绑定。] 因此，

MaximumNumberOfChunks(VxposeMode, n) (0x1d60f200) 是完全数字的，并且在各代中都是相同的(ElementCount 表 0xb53c830 = {1,2,4,1,2})：B32 → 16，CompressedB16 → 8， CompressedB8 → 4、SegmentedB32 → n/8、SegmentedB16 → n/16。

计算单元 — MXU / XLU / IAR ​

这三个计数来自 TensorCore VectorIsa 子消息(TpuSequencerPartsProto 字段 5)，从每个 blob 的线字节逐字段渲染。每代仅 mxu_count 和 xlu_count 有所不同； iar_count 到处都是 2。

TpuVer代mxu_count (f5)xlu_count (f6)iar_count (f7)MXU 收缩压暗淡FLOPS-衍生MXU
0水母v2112128×1281 × 128²
1龙鱼v3212128×1282 × 128²
2河豚 v4422128×1284 × 128²
3Viperfish v5p432128×1284 × 128²
4Ghostlite v6e222256×2562 × 256²(覆盖)
56acc60406 v7222256×2562 × 256²(覆盖)

每代的 VectorIsa 线流是一个 11 字节 varint 块 10 80 01 (lane=128) · 18 08 (sublane=8) · 28 <m> (mxu) · 30 <x> (xlu) · 38 02(iar)；标签 0x20(issue_latency_cycle_count，字段 4)从不存在(请参阅下面的 GOTCHA)。所有三个计数均达到运行时 Target：Target::Init (0x1d60fc20) 将 vector_isa()+0xc 读取为一个 QWORD 打包 {mxu_count, xlu_count} → Target+0x4ac/+0x4b0，且 vector_isa()+0x14 = iar_count → Target+0x4a8。 Target+0x4ac (mxu_count) 由 SDC 检查器 MXU 序列注入器 (mov eax,[rax+0x4ac] @ 0x144fca07) 消耗；这不是一片死地。

v6e/v7 下降到 mxu_count = 2(从 v4/v5 的 4)通过 GhostliteTarget C++ 将收缩/非收缩矩阵维度覆盖为 256(相对于基数 128)进行补偿：v6e/v7 使用 2 × 256×256 v4/v5 使用 4 × 128×128 的脉动阵列，产生可比较的每周期峰值 MAC。 256×256 覆盖是 C++ 访问器文字，因此为 HIGH 而不是 CERTAIN — 原始 lane_count 保持为 128。

注意 — 对于 v2/v3/v4，FLOPS 交叉验证同时引脚 mxu_count 和 TensorCore 时钟：峰值 BF16 = 2 × mxu_count × 128² × freq_MHz·1e6 在 1 % 内重现 C++ FlopsPerSecond 文字(v2 1·700 MHz → 22.9 T vs 22.8 T；v3 2·940 MHz → 61.6 T 与 61.4 T；v4 4·1050 MHz → 137.6 T 与 137 T)。 v5p/v6e/v7 峰值使用 256² 覆盖加上每个数据类型的降低精度梯形图，因此简单的 128² 公式不再适用。

明白了 — issue_latency_cycle_count(VectorIsa 字段 4)在每个嵌入的 blob 中都不存在(原始默认值 0)。重新实现者不得**从 chip_parts 读取 MXU/VPU 问题延迟；真正的每代问题延迟存在于成本模型 Performance 网格中，通过 CycleTable::GetCyclesForThroughput(每代 vtable 插槽 +0x10)进行查询。 chip_parts 字段存在于架构中，但从未在此版本中填充。

内存层 ​

每个芯片(单张量节点)容量。 VMEM、SMEM、SFLAG、HBM为chip_parts Memory/SharedMemory子消息； CMEM 是 SharedMemory[CMEM] 的上一代产品。 MemBanks 列是 C++ 梯形访问器(每个内存空间的存储体计数)。

等级v2 JFv3 DFv4 PF(标准/精简版)v5p VF(标准/精简版)v6e GLv7 6acc(模具/完整)
HBM(总计)16 GiB32 GiB32 GiB / 8 GiB96 GiB / 16 GiB31.5 GiB95 GiB / 190 GiB
HBM字1024 B1024 B512 B32 B / 512 B32 B32 B
HBM时钟1400兆赫1800兆赫2400兆赫3600 / 3200 MHz6400兆赫7200兆赫
HBM 黑白/堆栈0.317 TB/s0.430 TB/s0.982 / 0.492 TB/s2.350 / 0.738 TB/s1.638 TB/s3.686 TB/s
VMEM / TC16 MiB16 MiB16 MiB64 / 128 MiB128 MiB64 MiB
VMEM字512 B512 B512 B512 B512 B512 B
SMEM(TC)16 KiB16 KiB1 MiB1 MiB1 MiB1 MiB
SFLAG (TC)1 KiB1 KiB2 KiB2 KiB2 KiB16 KiB
CMEM——128 MiB———
IMEM bundle_count655366553665536655366553665536
寄存器 SREG/VREG/PREG/VMREG32/32/15/832/32/15/832/32/15/832/64/14/1632/64/14/1632/64/14/16
DMA颗粒1024 B1024 B512 B32 B / 512 B32 B32 B
max_single_host_dma8 MiB16 MiB2 GiB128 GiB64 GiB32 GiB

MemBanks 梯形图(C++ 访问器；每个 MemorySpace 的存储体计数，从 FATAL-vs-return 结构解码)：

MemBanks(space)v2/v3 (JellyfishTarget @ 0x1d48fc80)v4(PufferfishTarget @ 0x1d493900)v5p (ViperfishTarget @ 0x1d4999c0)v6e/v7 (GhostliteTarget @ 0x1d4969c0)
VMEM(空间3)8163232
CMEM(空间4)致命32致命致命
SMEM(空格5)2888

QUIRK — CMEM 仅在 Pufferfish (v4) 上是一流的。 PufferfishTarget::MemBanks 是接受内存空间 4 的单个梯形图 — 它计算 idx = space − 3 并为空间 3/4/5 索引 3 条目表 {16, 32, 8} (0xb5305c8)，因此 CMEM (4) 返回 32 个库。其他每一代的 MemBanks 要么测试 space == 3 || space == 5 和 FATAL(水母/龙鱼、@0x1d48fc80)，要么将空格 4 从其有效范围中排除。这是双重编码的：v4 也是 chip_parts 携带 SharedMemory[CMEM](128 MiB、1050 MHz、2.151 TB/s)的唯一一代，也是唯一具有 CMEM 本地 DMA 带宽行的一代。对于除 v4 之外的每个代，重新实现者在 CMEM 上都必须是 FATAL。

注意 — 寄存器文件在 v5p 处变宽，而不是逐渐变宽：v2/v3/v4 TensorCore 携带 SREG 32 / VREG 32 / PREG 15 / VMREG 8； v5p/v6e/v7 携带 SREG 32 / VREG 64 / PREG 14 / VMREG 16 (VREG 加倍，VMREG 加倍，PREG 下降 1)。 VMEM 也不会单调增长 — 单 TensorCore lite/v6e 芯片每核心的 VMEM 数量(v5e/v6e 上为 128 MiB)比双核 v7 (64 MiB) 多，因为 VMEM 是按 TensorCore 计算的，并且 lite 芯片具有更少的核心来共享芯片区域。

成本模型三重奏 ​

每一代都会选择一个 LatencyTable 子类(边缘/延迟模型)、一个 CycleTable 子类(吞吐量模型)和一个 Performance 后端(数字网格)。选择是通过两个不同的工厂机制按 TpuVersion 顺序进行的； 6 个版本折叠到 5 个类别边界。

TpuVer代LatencyTable 子类LT尺寸LT 虚拟表CycleTable 子类Performance 后端
0水母v2LatencyTableJellyfish0x580x21c202d0JfCycleTablePerformanceJf (isa)
1龙鱼v3LatencyTableJellyfish0x580x21c202d0JfCycleTablePerformanceDf (isa)
2河豚 v4LatencyTablePufferfish0x1e00x21c20320PfCycleTablePufferfishPerformance
3Viperfish v5pLatencyTableViperfish0x1e00x21c203f0VfCycleTableViperfishPerformance
4Ghostlite v6eLatencyTableGhostlite0x1e00x21c20698GlcCycleTableGhostlitePerformance
56acc60406 v7(匿名-ns gf LatencyTable)0x1e00x21c20920GfcCycleTableGhostlitePerformance(共享)

两个工厂：

  • LatencyTable::Create(TpuVersion) (0x1c89fba0) 是直接版本-索引 InlinedVector 注册表 (registry @ 0x225799f8)：签名检查 version >= 0，边界检查version < registry->size()，SOO 缓冲区选择，条目步长 0x20，工厂指针位于 [entry+0x18]，然后是 call。注册表由来自 5 个 TU (latency_table_{jf,pf,vf,gl,gf}.cc) 的静态初始化时的 6 个 Register() 调用填充 - jf.cc 将 v0 和 v1 注册到 LatencyTableJellyfish 上。
  • CycleTable::Create(Target const&) (0x1c89cc00) 是并行但不同的机制：在 Target[+0x398] = 上键入的 FunctionRegistry(互斥锁保护的 FlatHashMap、0x225799e8) TpuVersion。六个注册，JfCycleTable 同时服务 v2 和 v3。

QUIRK — v2-vs-v3 分割在 LatencyTable 或 CycleTable 类中不 — 两个版本都实例化 LatencyTableJellyfish(插槽 0 和 1)和 JfCycleTable。实际的 JF→DF 成本增量来自 Performance::CreateTensorCore (0x1d4927e0)，它将 DeviceIdentifiers 与 kJellyfishIdentifiers (0xbdf3c0c) → PerformanceJf，否则 kDragonfishIdentifiers (0xbdf3c18) → PerformanceDf。同样，v6e 和 v7 在不同的 LatencyTable/CycleTable 包装类后面共享 GhostlitePerformance — 这正是它们的 VectorIsa 字节相同的原因 (mxu=2/xlu=2/iar=2) 及其三角估计比赛。重新实现者对每代成本进行建模必须在硅架构接缝上进行划分，而不是在 6 路版本枚举上进行划分。

注意 — v7 (Gfc) LatencyTable 是 latency_table_gf.cc 中的匿名命名空间类型 — 没有命名的 typeinfo 符号，因此其精确的 C++ 类名是不可恢复的(因此为 HIGH，而不是 CERTAIN)。其vtable(0x21c20920)、ctor(0x1c8b9520)、VectorRawHazardCycles = 7(0x1c8b9c80)、GhostlitePerformance委托均已确认；只有源类名未知。

互连 — ICI / PCIe / 本地 DMA 带宽 ​

ICI 和 PCIe 带宽是 C++ Target 访问器文字(每个都返回立即的 IEEE-754 双精度)。本地片上 DMA 带宽矩阵按代号 LocalDmaBandwidth* 覆盖；基本 Target 访问器返回 0(使用默认成本模型)。

公制v2 JFv3 DFv4 PFv5p VFv6e GL
IciGigabytesPerSecond123.8164.089.6186.7186.7
PcieUnidirectionalBytesPerSecond16 GB/s16 GB/s16 GB/s16 GB/s32 GB/s
FLOPS BF16(每个芯片)22.8 T61.4 T137 T197 T918 T
超越数/秒(每个 TC)717 G963 G537.75 G1.536 T1.792 T

本地 DMA 带宽(GB/s，C++ 文字；选定的行 — 完整矩阵位于深层页面上)。基Target::LocalDmaBandwidth*返回0；每个代号子类都会用直接双精度数覆盖活动单元格。

源 → 目标v3 DFv4 PFv5p VF(标准)v5e VF-litev6e GL
HBM → VMEM42348111988221285
VMEM → HBM423111112248281432
HBM → SMEM—34555655
VMEM → CMEM—1121———
CMEM → VMEM—2339———
SPMEM → HBM——587.4(587.4)588

明白了 — Viperfish 在带宽访问器内有一个 运行时 std/lite 分支。 ViperfishTarget::LocalDmaBandwidthHbmToVmem (0x1d49a380) 加载变体字节，检查 variant != 4 → 返回标准值 0x4092B80000000000 (1198.0)，然后将变体字符串 dword 与 0x65746C6C ("ltil" Little-endian = 的尾部) "lite") 并为 lite die 返回 0x4089B00000000000 (822.0)。因此，一种 C++ 方法同时服务于 v5p(std，返回 1198)和 v5e(viperfish_lite，返回 822)；重新实现者不能将 v5p 和 v5e 视为单独的 Target 子类 - 它们是具有字符串比较分支的一个类。 Jellyfish (v2) 不会覆盖这些内容，因此所有 LocalDmaBandwidth* 返回基数 0。

加速器核心 — BarnaCore ↔ SparseCore Pivot ​

嵌入/重复数据删除加速器在 v5p 处更改类型。 v2/v3/v4搭载BARNA_CORE核心(前SparseCore引擎)； v5p/v6e/v7 搭载 SPARSE_CORE 内核。 lite 芯片(pufferfish_lite、viperfish_lite)两者都不发货——它们是仅 TensorCore 的单核芯片。

TpuVer代Accel核心型计数/芯片(标准)测序仪TEC VectorIsa 车道×子
0水母v2BARNA_CORE2BC_SEQ + 16× BC_ADDR1×8 (BC_ADDR)
1龙鱼v3BARNA_CORE2BC_SEQ + 16× BC_ADDR1×8 (BC_ADDR)
2河豚 v4BARNA_CORE4BC_SEQ + 16× BC_ADDR1×8 (BC_ADDR)
3Viperfish v5pSPARSE_CORE4SC_SEQ + 16× SC_TAC + 16× SC_TEC8×1 (SC_TEC)
4Ghostlite v6eSPARSE_CORE2SC_SEQ + 16× SC_TAC + 16× SC_TEC8×1 (SC_TEC)
56acc60406 v7SPARSE_CORE2(模具)/4(完整)SC_SEQ + 16× SC_TEC(无 TAC)16×1 (SC_TEC)

运行时 tpu::TpuSequencerType 枚举为 SC_SEQ = 4、SC_TILE_ACCESS_CORE (TAC) = 5、SC_TILE_EXECUTE_CORE (TEC) = 6(在 BarnaCore 端，BC_SEQ = 2、BC_ADDR = 3) — TpuSequencerTypeToString 表编号用于确定每个引擎资源数组的大小。编解码器/ISA 页面使用的 编解码器模板参数 编号相差一位(编解码器形式省略了 INVALID 插槽)：{SCS=3, TAC=4, TEC=5}(和 BARNA=1/BARNA_ADDR=2)。仅使用 +1 交叉两个编号；参见 getSequencerType。非 TensorCore 定序器不携带矩阵单元，因此它们的 VectorIsa 仅是通道/子通道 - SC_TEC 向量宽度是 BC_ADDR 地址遍历器几何的转置模拟。

QUIRK — Trillium (v6e / ghostlite) 搭载 SCS + TAC + TEC，但最新一代放弃了 TAC 定序器：v7 (6acc60406) chip_parts 搭载 SC_SEQ + 16× SC_TEC 且无 SC_TILE_ACCESS_CORE_SEQ。 SC_TEC 矢量宽度也从 8 通道 (v5p/v6e) 翻倍到 16 通道 (v7) — 当瓦片访问定序器折叠起来时，瓦片执行宽度增加。枚举 SparseCore 定序器类型的重新实现器不得假定 v5p/v6e {SEQ、TAC、TEC} 三元组适用于 v7。

注意 — (缺失数据单元) BarnaCore 详细的子消息几何结构(BarnaCoreFsm freg/smem 偏移量、重复数据删除/地址映射大小)不在这里走动；该表报告了每个 BarnaCore 定序器/内存的存在和 TEC/BC 矢量几何形状，但 BarnaCore Core 子消息内部仍未解码。同样，v5p/v6e/v7 降低精度 FLOPS 梯形图 (1×/2×/4×) 的确切 MatmulDataFormat 枚举 → dtype-name 绑定是从加倍模式推断出来的，而不是每个索引的字节固定。标记为“—”的单元格在该代中确实不存在(例如 v2-v4 的 SparseCore 行，除 v4 之外的每个代的 CMEM 行)，并非未知。

版本序号 — 三个独立轴 ​

一代在三个轴上佩戴三个整数序数，这些轴不共享编号。上述矩阵是基于内部tpu::TpuVersion；该表将其绑定到其他两个表，因此页面永远不会用另一个轴的序数来索引一个轴。

一代tpu::TpuVersion(内部)TpuVersionProto(电线)xprof::DeviceType(分析器)
水母v2013
龙鱼v3125
河豚 v4237
Viperfish v5p3410
Ghostlite v6e4513
6acc60406 v75612

TpuVersionToString (0x20b3a480) version >= 6 上的 FATAL 并对 6 指针表 off_22011BF0 进行索引，其重定位目标为代号文字 jellyfish … 6acc60406。原始序号始终为 internal + 1(blob 的 field-1 版本)。 DeviceType 是一个 稀疏 分析器轴 (DeviceTypeFromDeviceIdentifiers @ 0xf6993a0)，其中包括作为其自己的序数的 lite 变体 (Puffylite = 8，Viperlite = 11) — 它不能从 TpuVersion 进行算术推导。

明白了 — DeviceType 序数超出了 TpuVersion 顶端的顺序：Ghostlite (v6e) 是 DeviceType 13 但 6acc60406 (v7) 是 DeviceType 12。假设 DeviceType 随着世代的增加而增加的重新实现者将交换 v6e 和 v7。始终通过此表进行翻译，切勿通过向一个序数添加常量来进行翻译。

交叉引用 ​

主矩阵的每一列都有一个深页，拥有其派生：