GLM-5.3-Flash 跑在 TPU v6e 的可行性评估（2026-09-02）¶

范围：zai-org/GLM-5.3-Flash 在 TPU v6e（Trillium）上的推理服务；量化目标 int8；技术栈候选 torch_tpu 与 torchtpu-vllm。

标注约定：【核实】 = 直接读代码 / HF 官方 config / safetensors header / GitHub API 得到的事实，可复现；【分析】 = roofline 或工程推算，无任何真机对点。

数据来源：2026-09-02 实时拉取的 config.json、model.safetensors.index.json，以及全部 62 个 shard 的 safetensors header（76,108 个张量的 dtype 与 shape 逐个读出）。参数与显存表格不是从 model card 抄的，是重算的。

1. 结论¶

可行。显存装得下，int8 的选择是对的，长上下文特性恰好补上 v6e 单芯 HBM 小的短板。主要不确定性不在硬件，在两个缺失的 kernel 和一个至今没在任何平台稳定下来的上游模型定义。


最小可行拓扑	v6e-16（int8 方案 20.3 GB/芯，剩 14.1 GB）。v6e-8 装不下
生产基线	v6e-32
量化路线	分两步：先 MoE int8（现成的 runtime requantize 通道），再评估 KDA/MLA 投影
关键路径	DSA lightning indexer kernel（TPU 侧完全空白）
到「跑通 + 首批性能数字」	【分析】8–14 周，按下限读
技术栈修正	`torchtpu-vllm` 已归档，应改用 `vllm-project/tpu-inference`

六条主要判断：

int8 不是优化项，是 v6e 上唯一正确的目标。 v6e 的 MXU 原生只有 bf16 / int8 / int4， fp8 没有算力优势。GLM-5.3-Flash 出厂即 FP8 block-128×128：在 v6e 上反量化成 bf16 等于白扔一半算力并且把权重从 328 GB 撑到 646 GB；requantize 成 int8 则 字节数不变、算力翻倍。详见 §3。
显存可行域清楚：int8 全量方案 325 GB → v6e-16 起步、v6e-32 为生产基线； v6e-8 需要 40.7 GB/芯，装不下。详见 §4.1。
长上下文特性对 v6e 异常友好：45 层里 34 层是 KDA 线性注意力（状态与上下文长度无关， fp32 仅 136 MiB/序列），11 层 NoPE-MLA 的 KV 只有 11,264 B/token，1M 上下文单序列 11.0 GiB。是 Kimi K3（55,296 B/token）的五分之一。详见 §4.2。
缺口只有两个 kernel + 一层模型定义。 KDA ✅、MoE int8 GMM ✅、MLA ✅ 都有现成实现；缺 ① DSA lightning indexer + top-2048 稀疏注意力、② mHC（流形约束超连接），以及 ③ Glm5NextForConditionalGeneration 的模型定义。详见 §6、§7。
google-pytorch/torchtpu-vllm 已于 2026-07-16 归档（【核实】GitHub API archived: true，最后合入的 PR #434 就是主动设的合并冻结）。其 kernel 资产已迁入 vllm-project/tpu-inference 并继续演进。新项目不应再从 torchtpu-vllm 起步。
上游成熟度是最大的现实风险，而且在 GPU 侧就已暴露。 vLLM 主干至今没有 GLM-5.3-Flash，支持还在 PR #53906（open）；08-29 至 09-02 五天内新开的相关 bug 就有十几个，涵盖 KDA kernel 非法内存访问、MHC kernel、sparse-MLA 几何、hybrid KV 页对齐、MTP 与 DCP 冲突。 在 NVIDIA 上都还在冒烟的模型，TPU 侧要按「跟着上游一起收敛」估工，不能按「移植一个已稳定的模型」估。

2. 模型解剖【核实】¶

2.1 权重构成¶

321.342 B 参数 / 305.78 GiB checkpoint（FP8 314.397 B + BF16 6.926 B + F32 0.0003 B）。与 HF API 的 safetensors 统计、vLLM recipe 的 "roughly 306 GiB" 三方吻合。

组	参数 (B)	ckpt GiB	dtype	说明
MoE routed experts	304.424	283.57	FP8	288 专家 × 43 层（含 MTP），占总参数 94.7%
MTP 层（第 45 层）	7.433	6.98	FP8+BF16	1 层 draft，自带完整 MoE + MLA
attn — KDA（34 层）	4.683	8.72	BF16	q/k/v/o 全 bf16，checkpoint 里没量化
attn — MLA（11 层）	1.292	1.38	FP8+BF16	q_a/q_b/kv_a/o 为 FP8，`kv_b_proj` 为 BF16
embed + lm_head	1.269	2.36	BF16	`tie_word_embeddings=false`，双份
MoE shared experts	1.057	0.98	FP8	每稀疏层 1 个
vision tower	0.564	1.05	BF16	24 层 ViT + merger
dense MLP（层 0–2）	0.453	0.42	FP8	`first_k_dense_replace=3`
DSA indexer	0.082	0.15	BF16	11 层 lightning indexer
router / mHC / norm	0.085	0.16	BF16+F32

两处 model card 会误导的地方：

官方说「45 层」，checkpoint 里是 46 层（0–44 主干 + 第 45 层 MTP）。第 45 层是完整的 MLA + MoE 层，权重 6.98 GiB —— 不加载它就等于放弃 MTP 投机解码。
官方说「18B 激活」，按 config 逐层重算（不含 MTP / vision / embedding 查表）是 16.716 B，含 embedding 查表 17.35 B。roofline 应该用 16.7B。

2.2 架构¶

维度	值	对 v6e 移植的意义
层结构	45 层 = 34 KDA + 11 DSA-MLA，`full_attn_layers = [3,7,11,…,43]`（严格每 4 层一个）	规整的 4 层一块，天然适合 `scan` 折图
KDA	64 头 × head_dim 128；conv k=4（q/k/v 各一路）；低秩衰减门 `f_a(4096→128)→f_b(128→8192)` 为逐通道；`b_proj(4096→64)` 逐头 beta；`A_log[64]`、`dt_bias[8192]`、`gate_lower_bound=-5.0`	与 Kimi KDA 同构，tokamax 接口逐字段对得上（§6.1）
MLA	NoPE（`qk_rope_head_dim=0`）；`q_lora=1536` / `kv_lora=512`；64 头；`qk_head_dim=256`、`v_head_dim=256`（不是 DeepSeek 的 192/128）	absorbed 后 KV 仅 512 元素/token/层；但几何与 DeepSeek 不同，现成 kernel 要重调 block size
DSA	lightning indexer 32 头 × 128 维；`index_topk=2048`；`index_kpool=4` + `kpool_compress` + `always_select_tail`	TPU 侧完全空白，最大的 kernel 缺口
MoE	288 routed top-8 + 1 shared；`moe_intermediate=2048`；`noaux_tc` + sigmoid + `norm_topk_prob` + `routed_scaling_factor=2.5`；`n_group = topk_group = 1`（无分组路由）	路由逻辑简单；2048/16 = 128 对齐 MXU lane，TP=16 是 sharding 甜点
mHC	`mhc=true`，`hc_mult=4`，`hc_sinkhorn_iters=20`；每层 `hc_{attn,ffn}_fn[24,16384]` + `base[24]` + `scale[3]`	残差流宽度 → 4×4096 = 16384；每层每 token 20 次 Sinkhorn 迭代（4×4 小矩阵）。参数量可忽略，但形状小、串行、VPU-bound，是典型 TPU 反模式
MTP	`num_nextn_predict_layers=1`，`index_share_for_mtp_iteration=true`	GPU 侧推荐 `num_speculative_tokens=5`
多模态	24 层 ViT（hidden 1024，patch 14，image 448，temporal_patch 2，spatial_merge 2）+ merger	可先做纯文本
上下文	`max_position_embeddings = 1,048,576`	见 §4.2

3. 为什么必须是 int8【核实】¶

两个独立来源互相印证：

来源	v6e	v7x
`vllm-project/tpu-inference` 官方支持矩阵	`int8, int4, bf16`	`fp8_e4m3fn, fp8_e5m2, bf16`
JAX `pallas/mosaic/tpu_info.py`	bf16 9.20e14、fp8 9.20e14、int8 1.84e15、int4 3.68e15	int8 0、fp8 4.60e15

读法：v6e 上 fp8 与 bf16 同速（说明是转换/模拟，不是原生 MXU 通路），只有 int8 是 2×； v7x 正好相反，int8 干脆是 0。

推论：v6e 与 v7x 的量化方案不可复用。这份 int8 工作不为 v7x 铺路，是一次性投入；反过来，v7x 上攒的 FP8 / MXFP4 经验在 v6e 上也帮不上忙。

3.1 这条通路已经有人铺过¶

tpu-inference（及归档的 torchtpu-vllm）里有一整套 FP8 checkpoint → 运行时 requantize 机制，而且就是为 block-128×128 的 FP8 写的：

layers/vllm/quantization/fp8.py 的模块 docstring 明写目标是 Qwen/Qwen3-Coder-480B-A35B-Instruct-FP8，"FP8 e4m3fn weights with block-wise scales (weight_block_size: [128, 128])" —— 与 GLM-5.3-Flash 的 quantization_config 完全同格式。
开关：MOE_REQUANTIZE_WEIGHT_DTYPE / MOE_REQUANTIZE_BLOCK_SIZE（MoE）， REQUANTIZE_WEIGHT_DTYPE / REQUANTIZE_BLOCK_SIZE + ENABLE_QUANTIZED_MATMUL_KERNEL（dense linear）。 _MOE_REQUANT_WEIGHT_DTYPES 明确包含 "int8": torch.int8。
kernels/megablox/gmm_v2.py 按硬件自动选激活量化 dtype：

if tpu_info.int8_ops_per_second > 0:
    if not is_rhs_float:
        lhs_q_dtype = jnp.int8.dtype

→ 在 v6e 上、权重 requant 成 int8 之后，激活自动也走 int8，形成真正的 W8A8（block 512）。 - 上游 CI 里这套开关是活的：.buildkite/benchmark/cases/daily/deepseek.json 在 v7x-8 上跑 DeepSeek-R1 用的就是 MOE_REQUANTIZE_BLOCK_SIZE=512 + MOE_REQUANTIZE_WEIGHT_DTYPE=fp4。 把 fp4 换成 int8、机器换成 v6e，就是我们要的配置。

3.2 三个附带条件¶

tpu-inference 的 v6e 量化矩阵里，INT8 W8A8 / compressed-tensor 的 Correctness 与 Performance 都是「❓ Untested」。机制有，验证没有。
requantize 在加载时于 host 上完成（FP8 → float32 → int8）。321B 参数走这条路，加载耗时与 host DRAM 峰值要单独工程化（v6e 8 芯 host 有 1440 GB DRAM，容量够）。
KDA 的 q/k/v/o 在 checkpoint 里是 BF16、不带 scale（4.683 B 参数 / 8.72 GiB）。要做成 int8 得自己 PTQ 标定，不能靠 requantize 通道白拿 —— 这是分两步走的原因。

4. 显存与拓扑¶

4.1 四种方案的落点【分析】¶

v6e 每芯按 tpu_info 的 34.4 GB 计；「OOM」判据取 >80% 占用；已含 0.6% 的 scale/元数据余量。

方案	权重总量	v6e-8	v6e-16	v6e-32	v6e-64
A：反量化成 bf16	646.5 GB	OOM	OOM（40.4 GB/芯）	20.2，剩 14.2	10.1，剩 24.3
B：MoE int8 + 其余 bf16	331.7 GB	OOM（41.5）	20.7，剩 13.7	10.4，剩 24.0	5.2，剩 29.2
C：全量 int8	325.3 GB	OOM（40.7）	20.3，剩 14.1	10.2，剩 24.2	5.1，剩 29.3
D：MoE int4(awq) + 其余 int8	169.6 GB	21.2，剩 13.2	10.6，剩 23.8	5.3，剩 29.1	2.6，剩 31.7

v6e-16 最小可行，v6e-32 为生产基线。 v6e-16 剩 14 GB/芯 × 16 = 224 GB 给 KV、编译临时与激活，够用但不宽裕；考虑 mHC 把残差流拓宽 4 倍、以及 prefill chunk 的临时开销， v6e-32 才能同时兼顾长上下文与并发。
v6e-8 无论如何装不下 → 必须过 multi-host。而 tpu-inference 的 v6e feature 矩阵里 「multi-host」是「❓ Untested」（【核实】）。这是容易被低估的一项。
方案 D 值得单独立项、但不作主线。 v6e 原生支持 int4（3.68e15 OPS），社区已有 cyankiwi/GLM-5.3-Flash-AWQ-INT4、wtdcode/GLM-5.3-Flash-AWQ-W4A16 两个 compressed-tensors 权重，官方矩阵也列了 INT4 W4A16 / awq。它能把模型压回单 host v6e-8，代价是精度风险和一条没验证过的通路；W4A16 在大 batch 下算力也不占便宜。

4.2 每序列状态：这是本模型的结构性优势【核实】¶

项	大小	备注
MLA latent KV（bf16）	11,264 B/token	11 层 × 512 元素；1M ctx = 11.00 GiB/序列
MLA latent KV（fp8）	5,632 B/token	1M ctx = 5.50 GiB/序列
DSA indexer key（fp8, kpool=4）	352 B/token	1M ctx = 0.34 GiB/序列
KDA recurrent state（fp32）	136.0 MiB/序列，与上下文无关	34 层 × 64 头 × 128 × 128；TP=16 时 8.50 MiB/芯/序列
KDA recurrent state（bf16）	68.0 MiB/序列	数值稳定性未评估

在 v6e-32（剩 24 GB/芯 × 32 = 775 GB）上：

128 并发 × 128K 上下文：KV 177 GiB + KDA 状态 17 GiB ≈ 194 GiB，占余量 25%。宽松。
8 并发 × 1M 上下文：KV 88 GiB + 状态 1.1 GiB ≈ 89 GiB。宽松。

对比 Kimi K3：K3 在 v7x-16 上兑现不了 1M context，是因为 55 KB/token。 GLM-5.3-Flash 只有 11 KB/token，且 34/45 的层完全不吃上下文 —— 「用 v6e 这种小 HBM 芯片跑超长上下文」在这个模型上第一次讲得通。

5. Roofline【分析 · 零真机对点】¶

5.1 decode¶

int8 权重，v6e 每芯 1.64 TB/s：

拓扑	batch=1（只搬命中的 8+1 个专家）	大 batch（288 专家全热）
v6e-16	16.7 GB，理论 0.64 ms/步 → @50% 带宽效率 785 步/s	317 GB，12.1 ms/步 → 41 步/s
v6e-32	0.32 ms → 1570 步/s	6.05 ms → 83 步/s
v6e-64	0.16 ms → 3139 步/s	3.02 ms → 165 步/s

两列都不能直接信，原因相反：

batch=1 一列被严重高估。 它只算 HBM 搬运，没算 collective。46 层 × 每层至少 2 次 all-reduce（mHC 让残差流是 16384 宽，不是 4096）→ ≥92 次 collective/步。 K3 项目在 v7x 上实测小消息 a2a 的 per-call 固定开销是 9.88 µs （【核实，但那是 v7x 不是 v6e】）；按同量级估，光固定开销就 ~0.9 ms/步， 已超过 0.64 ms 的带宽下界。 → batch=1 decode 大概率是 collective 延迟 bound，不是带宽 bound。这是第一优先要实测的量。
大 batch 一列被低估了收益。 41 步/s 是单序列出词速率；batch=256 时聚合吞吐 ~10K token/s，叠加 MTP（GPU 侧推荐 5 个投机 token）还能再放大。

5.2 prefill¶

每 token 2 × 16.7 B = 33.4 GFLOP（不含注意力）：

拓扑	int8 峰值	MFU 30%	bf16 对照
v6e-16	29.4 POPS	264 K token/s	132 K token/s
v6e-32	58.9 POPS	528 K token/s	264 K token/s

按上限读，不是预期值。 30% MFU 对 grouped-matmul MoE 是乐观的（288 专家 top-8 的 gather/scatter、路由、padding 都吃在这里），真实值估计 8–15%，即 v6e-32 上 140–260 K token/s 量级。即便如此，prefill 也不是瓶颈。

5.3 DSA 的隐藏成本：indexer 是 O(N) 的¶

DSA 的卖点是主注意力被 index_topk=2048 封顶，但选出这 2048 个 key 的 lightning indexer 本身是 O(N)（下表已按 index_kpool=4 的 4× 压缩折算）：

上下文	稀疏注意力	lightning indexer	indexer 占 MoE FLOP
8 K	1.48 GFLOP/token	0.18 GFLOP/token	0.6%
32 K	1.48	0.74	2.2%
128 K	1.48	2.95	8.8%
1 M	1.48	23.62	70.7%

1M 上下文下，indexer 的算力开销接近整个 MoE 的 3/4。 它是 32 头 × 128 维的窄矩阵对全历史打分，还要跟一个 top-2048 排序 —— 内存密集、形状窄，是这套架构里最难写好的 TPU kernel。

「GLM-5.3-Flash 长上下文很省」这句话在显存上成立，在算力上只到 128K 左右成立。

6. 生态盘点（2026-09-02 逐个核实）¶

仓库	状态【核实】	意义
`google-pytorch/torchtpu-vllm`	已归档（`archived: true`）。最后合入的 PR #434 是主动设的 2026-07-16 合并冻结	⚠️ 代码可读可 fork，但没有上游了
`vllm-project/tpu-inference`	公开、活跃、422 star。kernel 目录与 torchtpu-vllm 逐个同名（`gdn` / `megablox` / `mla` / `quantized_matmul` / `fused_moe` / `causal_conv1d` / `ragged_paged_attention` / `sparse_core`）且已继续演进（gdn → v1/v2/v3+reference，mla → v2，新增 `structured_sparse_matmul`、`experimental/deepseek_v4`）	判断：torchtpu-vllm 的 kernel 资产已迁入此处。这是唯一该走的服务栈
`google-pytorch/torch_tpu`	活跃（google3 Copybara 镜像）。定位是 PyTorch 的 TPU ATen 后端：自定义 ATen kernel + 编译缓存 + `torch.compile` + 分布式训练，示例为 Llama / Qwen / ResNet / DLRM	不是服务引擎。无连续批处理 / paged KV / 调度器。正确用法是做数值对拍基准
`openxla/tokamax`	main 已包含 `_src/ops/experimental/kda`（fwd 57 KB + bwd 60 KB + CP utils + 测试）和 `experimental/mla`（91 KB TPU Pallas kernel）。tpu-inference 已 `tokamax==0.0.13` 直接依赖	✅ 相对 K3 报告时期的最大变化：当时 KDA「不在 main、只在未合入的 PR #1103」，现已在 main（PR #1103 仍 open，说明走内部通路落地）
`vllm-project/vllm`	v0.28.0（08-26）。registry 里没有 `Glm5NextForConditionalGeneration`；支持在 PR #53906（open）；官方 recipe 要求 "vLLM 0.29.0+" 且 "use a Docker image before the integration is included in the public repo"	⚠️ 模型定义本身还没落地
`google-pytorch/sglang-torchtpu`	已废弃（迁往 `sgl-project-dev`）	排除

6.1 KDA：参数级对得上，这是最强的一条【核实】¶

tokamax main 的 kimi_delta_attention 签名与 GLM-5.3-Flash 的 checkpoint 张量逐条对应：

tokamax 参数	GLM-5.3-Flash 张量
`gate: Float[Array, "H B T K"]`（逐通道）	`f_a_proj[128,4096]` → `f_b_proj[8192,128]`，8192 = 64×128	✅
`beta: Float[Array, "H B T"]`（逐头逐 token）	`b_proj[64,4096]`	✅
`a_log: Float[Array, "H"]`	`A_log[64]`	✅
`delta_time_bias: Float[Array, "H*K"]`	`dt_bias[8192]`	✅
`lower_bound: float`	`gate_lower_bound = -5.0`	✅
`use_qk_l2norm` / `segment_ids` / `context_parallel_metadata`	KDA 标配 / varlen 连续批处理 / CP	✅

没有一个参数需要改 kernel。

6.2 其余三条代码事实【核实】¶

KDA decode 现成，但默认路径是错的。 kernels/gdn/v2/gdn_decode_kernel.py 的 g: [T, H_v, K] 是逐通道衰减，融合 conv1d + 状态索引 + A_log/dt_bias 门控，正是 KDA 的单步形态。而 kernels/gdn/v3（layers/common/gdn_attention.py 当前默认走的融合 prefill+decode kernel）的 gating_log: [1, 1, num_v_heads] 只支持逐头标量衰减（Qwen3-Next 的 GDN），不支持 KDA。 → 接线要走 v2 + tokamax，不能复用 v3 的现成路径。这是个具体的、容易踩的坑。
MoE int8 现成。 megablox/gmm_v2.py 原生 int8 rhs + 自动 int8 lhs（§3.1）。 288 专家、moe_intermediate=2048、无分组路由；TP=16 时每 rank 128 维对齐 MXU lane， EP=16 时每 rank 18 个专家。sharding 无难点。
MLA 有 kernel，接线要重做。 tokamax experimental/mla 与 tpu-inference kernels/mla/v2 都在，但 GLM 的几何是 qk=256 / v=256 / NoPE，与 DeepSeek 的 192(128+64 rope)/128 不同。 K3 项目的教训是「kernel 在 ≠ 上游接着」——当时 kernels/mla/v1 是没人 import 的死代码， k3serve 自己接了一串七个 issue 才通。这里要按「重新接线 + 重调 block size」预算。

7. 缺口清单与工作量【分析】¶

#	缺口	上游现状	需要做的事	量级
G1	模型定义 `Glm5NextForConditionalGeneration`	vLLM 主干无，PR #53906 open	拉 PR 的 PyTorch 定义 → 在 tpu-inference 走 `MODEL_IMPL_TYPE=vllm`（torchax 路径）	1–2 周（跟着上游漂）
G2	DSA indexer + top-2048	TPU 侧完全空白	新写 Pallas kernel：32 头×128 打分（O(N)）+ kpool 压缩 + top-k 选择 + gather 式 paged MLA	2–4 周，最大单项
G3	mHC（Sinkhorn 20 迭代 + 4× 宽残差）	无（GPU 侧是专门的 TileLang kernel，且在冒烟）	先写 XLA 参考版跑通，再判断是否要 kernel；4× 残差流对 all-reduce 载荷与激活显存的影响要实测	1–2 周 + 未知调优
G4	KDA 接线	kernel 齐，但 gdn/v3 默认路径不支持逐通道	接线 + 数值对拍 + 绕开 v3	1–2 周
G5	MLA(256/256/NoPE) 接线	kernel 在，几何不同，历史上是死代码	接线 + block size 重调	1–2 周
G6	int8 requantize 端到端	机制齐全，v6e 上 Untested	打通 `MOE_REQUANTIZE_WEIGHT_DTYPE=int8` + 对 `zai-org/GLM-5.3-Flash-BF16` 精度对拍 + 加载工程化	1–2 周
G7	v6e multi-host	v6e feature 矩阵 Untested	v6e-16/32 起必须过	1–2 周（风险高）
G8	MTP 投机解码（第 45 层）	tpu-inference 有 Eagle3/Ngram/DFlash，无 MTP-for-GLM	可延后，但它是吞吐的主要放大器	1–2 周（P1）
G9	vision tower	tpu-inference 有 Qwen2.5-VL 通路	纯文本先上，多模态单独排期	1–2 周（P2）

G1–G7 并行推进，到「纯文本单配置跑通 + 首批性能数字」约 8–14 周，串行关键路径在 G2。到「可谈 SLO 的生产服务」再加 4–8 周。

关于工期的诚实提醒

K3 报告初版估 27–47 天，八天实测后被证伪 —— 时间没花在预估的 kernel 上，全花在没立项的地方：整模型编译可行性、多 host 数据摆放、加载工程、一批「v6e 绿、v7x 才现形」的平台差异。这次同样应按「系统集成与测量占大头」来读，上面的数字是下限。

8. 风险登记¶

#	项	等级	说明
1	DSA indexer kernel 从零写	高	唯一没有任何 TPU 先例的部件；且 1M 上下文下它吃 70% 的 MoE 算力（§5.3），写不好会直接毁掉长上下文卖点
2	上游模型定义还没落地	高	PR #53906 仍 open；GPU 侧五天内新开十几个 bug（KDA 非法内存访问、MHC kernel、sparse-MLA、hybrid KV 页对齐把 attention block 撑到 7808 token、MTP+DCP 崩）。跟着一个还在冒烟的上游做移植，返工不可避免
3	torchtpu-vllm 已归档	中	预设技术栈之一没有上游了。缓解：改用 `vllm-project/tpu-inference`；并向 TorchTPU 团队确认是否有内部延续分支（本报告只能看到公开信息）
4	v6e multi-host 未验证	中	v6e-8 装不下 → 必须 multi-host → 而它在官方矩阵里是 ❓
5	mHC 是 TPU 反模式	中	4×4 矩阵 20 次 Sinkhorn × 46 层 × 每 token：FLOP 可忽略但形状小、串行，很可能成为 VPU 瓶颈。GPU 侧为它专门写 TileLang kernel 这件事本身就是信号
6	321B 参数的 load-time requantize	中	FP8→f32→int8 在 host 上做。K3 的 vLLM 线加载曾是小时级（JAX 线优化后 10.6 分钟）。不是可行性问题，是迭代效率问题
7	int8 精度未评估	中	v6e 的 INT8 W8A8 在官方矩阵里 Correctness ❓。MoE 专家做 W8A8 的精度风险高于 dense；`routed_scaling_factor=2.5` 与 sigmoid 路由对量化误差的敏感度未知
8	KDA 投影是 BF16、无 scale	低	4.683 B 参数要 int8 得自己 PTQ 标定。可先跳过（方案 B）
9	v6e 与 v7x 量化方案不可复用	低（但要讲清楚）	int8 只在 v6e 有意义（v7x `int8_ops = 0`）。这份工作不为 v7x 铺路
10	tokamax KDA API 漂移	低	已进 main（比 K3 时期好），但 PR #1103 仍 open 说明双轨；依赖仍应钉 commit

9. 建议¶

9.1 技术选型¶

服务栈用 vllm-project/tpu-inference，不要用已归档的 torchtpu-vllm，也不要指望 torch_tpu 单独当服务引擎。torch_tpu 的正确用法是做数值对拍基准 （transformers + torch_tpu 逐层对回 HF）—— 这在 K3 项目里被证明是最有价值的辅助线。
模型实现走 MODEL_IMPL_TYPE=vllm（torchax 路径），直接吃 PR #53906 的 PyTorch 定义，避免自己维护一份 JAX 模型；kernel 用 tpu-inference 的 gdn/v2 + tokamax kda / mla 通过 custom op 注入。
量化按 B → C 两步走：先方案 B（MOE_REQUANTIZE_WEIGHT_DTYPE=int8、 MOE_REQUANTIZE_BLOCK_SIZE=512，KDA/MLA 投影留 bf16）跑通并测精度，再决定是否对 KDA 投影做 PTQ 进方案 C。不要一上来就全量 int8。

9.2 里程碑（按信息价值排序，不按方便程度）¶

M	目标	为什么排这个位置
M0	v6e-4/v6e-8 上用裁层 config（如 4 层 = 3 KDA + 1 DSA-MLA + MoE）跑通 forward，逐层对回 HF	用最低成本把 G2/G3/G4/G5 四个缺口全部暴露。不要先去搞 321B 的加载
M1	单独把 DSA indexer kernel 做出来并对拍	关键路径上唯一从零的部件，越早知道它多难越好
M2	mHC 的 XLA 参考实现 + profile	判断「要不要专门写 kernel」这个分叉，只需要一次 profile
M3	v6e-16 上真权重加载 + int8 requantize + 出 token	「可行」在服务线上闭环
M4	首批端到端数字：batch=1 decode 单步延迟（验证 §5.1 的 collective 猜想）、prefill 吞吐、128K/1M 下 indexer 开销占比	§5 全是分析值，一个真机对点都没有。这是当前信息价值最高的测量
M5	MTP + 多模态	吞吐放大与功能补齐，都不在可行性关键路径上

9.3 三个应该现在就去确认的外部事实¶

torchtpu-vllm 归档后是否有内部延续分支 —— 向 TorchTPU 团队确认。本报告只能看到公开信息。
v6e-16 / v6e-32 的实际供给与排队时间 —— K3 项目实测 GKE 上 v7x 排队 19h51m、租期 7 天；容量提前期必须算进任何时间表。
vLLM PR #53906 的合入时间表 —— 若短期内合入，G1 成本会显著下降。

本报告基于 2026-09-02 的公开代码与 HF 官方权重元数据。模型事实来自 62 个 shard 的 safetensors header 逐张量统计（76,108 个张量）；上游代码声明逐条核实到文件与行为；硬件常数取自 JAX tpu_info 与 Cloud TPU v6e 官方文档，两者一致。所有性能数字（§5）均为 roofline 分析值，没有任何真机对点。 工期估算按未验证处理。