最近后台几乎被同一个问题刷屏：Google第八代TPU训练与推理芯片的详版参数，到底出来了没有？不管是做预训练的朋友，还是做推理服务的架构师，都盯着这一代芯片的数字，因为算力、内存带宽和互联能力直接决定未来一年的模型成本曲线。我之前整理过TPU v7 Ironwood的资料，这次把第八代（按行业习惯直接称呼为V8）的路标参数、训练与推理场景里的实际用法，以及落地时容易踩的坑统一写清楚。需要先说明：文章里所有带“推演”“预估”字样的参数，是我根据Google公开技术路线、Cloud Next大会释放的信号和供应链消息整理的合理外推，不是官方最终规格，但足够用来做架构选型和成本估算。适合正在评估大规模训练集群、做推理服务改造，或者单纯想搞明白TPU迭代逻辑的工程师。

1. 先厘清代际：为什么说第八代是训推一体的分水岭

1.1 从v1到v7，TPU是怎么一步步走到今天的

Google的TPU路线图其实非常清晰，每一代解决的问题都不一样。如果不先理解这条演进主线，拿到第八代的参数表也会一头雾水。

从这个序列能看出一条明显规律：v3之前追赶训练能力，v4/v5把集群规模做起来，v6/v7开始在推理和能效上发力。到了第七代，Google其实已经把“推理芯片”这件事打磨得很成熟，但超大模型预训练用户还是觉得不够尽兴，尤其是MoE模型和长序列训练场景，大家更期待一个“训练不缩水、推理更凶猛”的版本。这就是第八代出现的逻辑。

1.2 命名口径要先统一：为什么“第八代”不等于v8的简单小改

网上对“第八代”的说法有点乱，有些人把v7 Ironwood叫成第八代，因为v5e/v5p被看作两代产品，v6e又被单独算了一代，数来数去就多出来一代。实际上按官方的版本号，v1到v7是七代，真正的第八代就是TPU v8。

我在文章里沿用这个口径。如果你看到某个文章说“第八代TPU已经发布”，多半说的是Ironwood，那个其实是第七代。真正要等的是V8：一个在单芯片算力、HBM容量、片间互联三个方面同时跨大步的训推一体芯片。官方目前没有放出终版规格，但供应链和基础设施侧的信号已经拼出了它的大致轮廓。

1.3 训推一体的分水岭到底分在哪里

训练芯片和推理芯片的优化方向经常是打架的。训练喜欢峰值算力高、互联带宽大、能做同步梯度同步，最好整集群像一台巨型计算机；推理则偏爱内存带宽高、能容纳KV Cache、单请求延迟低，对峰值算力的敏感度反而没那么高。

过去几年很多团队被迫拆成两套集群：一套A100/B200跑预训练，一套v7 Ironwood或者专用推理卡跑线上服务。第八代TPU想做的就是一套芯片打通两件事：训练时把分布式集体通信能力拉满，推理时把连续批处理和PD分离做进硬件里。这听起来像营销话术，但它确实改变了用户评估芯片的方法论——以前只看训练TFLOPS，现在要同时看INT8/FP8吞吐、HBM带宽、KV Cache容量和TPU互联拓扑。

2. 第八代TPU详版参数逐项拆解（按公开路线推演）

2.1 算力单元：FP8/FP4的峰值应该怎么理解

先说结论：第八代TPU的FP8算力大概率落在3800到4600 TOPS这个区间，BF16/FP16算力大约是其一半，也就是1900到2300 TFLOPS。这个推演依据有三条。

第一，TPU v7 Ironwood在推理任务的主打性能已经是前代的数倍，V8如果不翻倍，很难说服云客户换集群。第二，Google是FP8训练最早一批落地者，内部对低精度数值稳定性已经积累了足够经验，再往上推FP4是自然动作，但FP4不会单独作为主计算精度，而是作为稀疏加速和推理量化时的补充。第三，算力堆高的代价是功耗，第八代单芯片功耗预计会达到1400到1800W区间，这必须搭配液冷机柜，否则风冷根本压不住。

这里有个很重要的判断方法：峰值算力只是一个门面指标，真正决定训练快不快的是MFU（Model FLOPs Utilization，模型算力利用率）。拿推算的4000 TOPS来说，如果实际MFU只有45%，那么真实有效算力只有1800 TOPS。所以不要看到广告数字就激动，要看框架和互联能不能把芯片喂饱。

2.2 高带宽内存：HBM4容量与带宽的推算逻辑

推理芯片最怕的不是算力不够，而是显存不够、带宽不够。第八代TPU几乎可以确定会用HBM4，单芯片容量预计192GB到288GB，带宽预计9.6TB/s到16TB/s。

为什么敢这么推？因为v7 Ironwood已经把HBM容量和带宽堆到相当高的水位，而训练场景要求单芯片容纳更大的参数切片和优化器状态，推理场景则要求在同样的显存里塞下更长的KV Cache。两者相加，容量不往上走根本说不过去。

举个例子。一个4万亿参数的MoE模型，如果用BF16存权重，光参数就要8TB，加上梯度和Adam优化器状态，训练时大概需要48TB以上显存。如果V8单芯片192GB，那么256颗芯片刚好提供49TB，可以勉强放下；如果单芯片只有128GB，就需要把并行度切得更碎，通信开销会明显上升。所以单芯片内存容量不是拍脑袋定的，它是由目标模型规模反推出来的。

2.3 片间互联与超节点拓扑：这里才是大模型性能的胜负手

单芯片再强，互联不行也是废的。第八代TPU的ICI（Inter-Chip Interconnect，片间互联）带宽预计会从v7的级别再翻一倍，达到双向5TB/s到6.4TB/s的量级。同时，Google大概率延续OCS光交换方案，让超节点之间的拓扑可以动态重配。

为什么要强调这个？大模型训练如今都是张量并行、序列并行、专家并行一起上，每个step都要做大量all-reduce和all-to-all通信。如果互联带宽只有HBM带宽的一半，那大部分时间都在等数据搬运。第八代把ICI带宽拉高后，最直接的收益是：MoE模型的专家分发不再成为瓶颈，长序列的序列并行也能跑得更稳。

我把推演参数整理成一个表，方便你对照着看：

再强调一次：以上是推演表，不是官方DATASHEET。我做架构预研时会按这个区间去设计，但如果后面官方数据出来有出入，不要惊讶，重点看量级而不是精确数字。

3. 训练场景：超大模型并行训练的关键指标

3.1 从BF16到FP8混合精度训练，第八代意味着什么

FP8训练已经不是新鲜事，很多大模型团队已经在做。但第八代TPU真正有意思的点在于，它可能把FP8从“能用”变成“默认选项”，并且把FP4稀疏路径打通。

训练时最常用的混合精度策略是：权重和优化器状态保持BF16或FP32，前向和反向计算用FP8。这套逻辑能大幅减少显存占用，计算单元跑得更快。第八代如果能把FP8动态缩放做得足够稳，那么用户就可以把原来的BF16训练无缝切到FP8，节省的显存直接拿去买更长序列或者更大的batch。

关于FP4训练，我个人的态度比较谨慎。FP4做推理量化已经很成熟，但训练还是容易掉点。第八代即便硬件支持FP4，也不建议一开始就全用FP4训练，比较合理的路径是“BF16基座+FP8主力+FP4推理量化”，这样风险最低。

3.2 万亿参数MoE训练怎么用第八代TPU规划

拿一个真实一点的规划案例来说。假设你要训练一个4万亿参数的MoE模型，激活参数600B，也就是每次前向只算600B参数对应的计算量。

先粗算显存：4T参数，BF16权重2 + 梯度2 + Adam优化器状态8（fp32均值+方差），平均每参数12字节，一共48TB。用256颗V8芯片，每颗192GB，总显存49TB，刚好卡着线。如果模型再加长序列的激活和KV Cache，其实已经有点紧了，所以更稳妥是上到512颗芯片，留出20%以上的显存余量。

再算算力：256颗芯片、每颗4000 TOPS FP8，集群总峰值是1.02 EFLOPS。按MFU 45%折算，有效算力约0.46 EFLOPS。一个600B激活参数的MoE模型，前向和反向大约是6倍的激活参数量计算，也就是3.6T FLOPs每token。那么理论上每秒能处理大约0.46E18除以3.6E12，大约是12.7万token。这意味着一个包含1万亿token的数据集，理想状态下跑25天左右。当然，这是纯算力乐观估算，没算checkpoint、断点续训和其他开销，但足以作为规划基线。

3.3 训练百亿到千亿稠密模型的并行配置建议

不是所有人都在跑万亿MoE，更多团队还是百亿到千亿稠密模型。第八代TPU在这种场景下的并行配置我建议这样设计：张量并行TP=8或16，因为单芯片显存足够大；序列并行SP和TP绑定开启，长序列收益明显；数据并行/FSDP用于扩展规模，每batch尽量翻倍。

还有一个容易忽略的点：优化器状态是否卸载。过去显存不够时大家喜欢把Adam状态offload到CPU内存，但第八代单芯片显存如果到288GB，很多规模模型根本不需要offload。不要惯性沿用旧配置，重新算一遍显存账，能省掉大量PCIe/内存通信开销。

4. 推理场景：从KV Cache到流式推理管线

4.1 为什么推理芯片的核心指标是“内存带宽/算力比”

很多人喜欢问：第八代TPU的FP8推理TOPS这么高，每秒能出多少token？这个问题其实问错了。推理是强访存型任务，尤其是decode阶段，每生成一个token只需要做一次矩阵乘法，但要把整个模型权重和KV Cache从HBM里读一遍。所以真正决定推理吞吐的，是内存带宽和容量。

算一个简单对比。假设一个70B稠密模型，BF16权重140GB。如果HBM带宽是10TB/s，那么理论上每秒钟最多能完成约71次完整的全权重读取，也就是每秒最多生成71个token。无论算力标到多高，这个上限都卡在那里。第八代把HBM带宽提升到10TB/s以上，同时在192GB到288GB的显存里塞KV Cache，所以它敢说自己适合做长上下文推理。

4.2 PD分离与连续批处理：硬件设计如何影响软件方案

推理服务里有两种截然不同的阶段：prefill阶段要并行处理大量prompt token，计算密集；decode阶段每次只生成一个token，访存密集。这两者的最优硬件配置并不一样。

第八代TPU在推理侧的硬件设计大概率会强化对PD分离的支持：prefill阶段跑高算力，decode阶段靠高内存带宽撑吞吐。软件层面对应的就是连续批处理、chunked prefill这些成熟技术。我的建议是，如果要在V8上搭推理服务，不要再用传统的静态batch，直接上支持动态batch的推理框架，让每时每刻的算力和带宽都被尽量填满。

4.3 流式推理管线怎么搭：vLLM与JetStream的经验

目前常见的TPU推理路径有几条：Google自己的JetStream和Pax Serving，以及社区里的vLLM TPU后端。无论走哪条，核心配置参数是相通的。我提供一个参考配置思路，具体参数名以你使用的框架版本为准：

model = "llama-3.1-70b-instruct" tensor_parallel_size = 8 pipeline_parallel_size = 2 max_model_len = 131072 max_num_seqs = 128 enable_chunked_prefill = True enable_continuous_batching = True kv_cache_dtype = "fp8"

这几个参数背后的逻辑很简单：tensor_parallel_size=8是为了把70B模型的权重切到8颗芯片上，降低单芯片显存压力并提高并行带宽；enable_chunked_prefill让长prompt被切成小段，避免一次prefill占满整卡；enable_continuous_batching保证不同请求交错执行，不让某次生成卡顿。KV Cache用FP8则是在精度影响可控的前提下，把更长上下文的容量翻倍。

跑通之后一定要测三个指标：首Token延迟、解码阶段吞吐、端到端TPS。第八代TPU这种硬件，如果三者不能同时好，大概率是软件没有把PD分离和连续批处理配好，而不是硬件不行。

5. 和上一代/竞品放在一起看：参数背后的取舍逻辑

5.1 第八代TPU与TPU v7 Ironwood的参数对比

v7 Ironwood的推理能力已经很能打，但第八代的核心变化在于训练能力不再妥协。两者目前按推演口径的差异如下：

选型逻辑很直接：你如果只是做稳定在线推理，v7已经够用；如果要同时跑预训练和在线服务，等V8比买两套方案更划算。

5.2 与GPU竞品的横向对比视角

拿NVIDIA的B200/GB300这一代做参照，两边在量级上已经互不相让。GPU这边最大的优势是软件生态成熟，PyTorch代码基本无缝迁移；TPU这边则在互联和功耗比上有优势，尤其适合大规模定制集群。

但我要提醒一个现实问题：生态账面差距并不等于最终性能差距。如果你的训练框架本身就基于JAX、PaxML或者PyTorch/XLA，迁移到第八代TPU的成本远比想象中低。如果团队代码里满是自定义C++算子，那选TPU前的改造工作量会非常巨大，这种情况下即便V8理论算力更高，也未必划算。

5.3 什么场景值得等第八代TPU

我自己把场景分成三类：第一类，超大模型预训练为主，且训练框架已经拥抱XLA，这种值得等，收益最明显；第二类，在线推理和多模型复用，当前用v7或GPU都能跑，V8的HBM大容量和PD分离更友好，可以等成熟再切；第三类，小模型快速迭代，其实不需要追最新芯片，用v6e或普通GPU性价比更高。

不要因为“新”就升级。芯片选型的核心是单位成本能处理的token数，不是峰值TOPS。

6. 落地前没人写在PPT里的工程经验

6.1 集群功耗不是加电源就完事

第八代单芯片功耗如果到1400W以上，一个256芯片的超节点峰值功耗就是350kW以上，加上网络设备和制冷，轻松突破400kW。这已经不是“换个大电源”能解决的问题，而是机柜密度、液冷管路、冗余供电都要重新设计。

我的经验是：在评估芯片之前，先拿着功耗表去找机房或者云厂商确认三个问题：单机柜功率上限是多少，液冷接口是否兼容HPRI/CDU，故障时冗余制冷能不能覆盖满载。这些基础设施问题在POC阶段不解决，等设备进场再改，成本会高得吓人。

6.2 存储带宽与checkpoint：HBM再大也会被I/O拖死

大模型训练有一个隐藏瓶颈：checkpoint保存。4万亿参数的模型，每份BF16权重8TB，就算只保存单份，每30分钟保存一次，也需要4.4GB/s的持续写入带宽；如果做异步保存加上版本保留，很容易变成16GB/s以上。

很多团队用了最新芯片，但存储后端还是普通云盘，训练时GPU经常在一轮迭代结束时卡住。建议提前规划独立的高速存储空间，checkpoint先写本地NVMe，再做异步多级备份，不要让同步写盘阻塞下一轮训练。

6.3 软件迁移成本：动态shape是最大的坑

TPU和GPU最大的软件差异在于XLA编译器。XLA喜欢静态shape，所有维度在编译期定死，这样能把算子融合和通信调度优化到极致。但PyTorch动态shape代码在XLA里很容易退化成频繁重编译，性能直接崩。

迁移到第八代TPU前，先把代码里所有动态shape清理干净：固定batch size或者在关键步骤使用静态padding，避免对着token长度做动态循环。这一步做完，性能基本能提升数倍；没做完，再强的新芯片也只能跑出三成功力。

6.4 我个人的判断和一条实操建议

第八代TPU目前还没有官方终版规格，但从v7到V8的轨迹已经足够清晰：单芯片算力翻倍、HBM容量大幅提升、互联带宽继续加高、训练和推理在同一个芯片上不再互相妥协。对一个正在做大模型训练的团队来说，最值得做的不是等那一天的发布会，而是先把训练框架往XLA生态靠拢，把数据管道和checkpoint流程彻底标准化。这样芯片真正开放时，你可以直接拿云上的服务做一轮POC，而不是从零开始改代码。

我自己评估这类芯片时，习惯把重点放在三个数字上：每芯片FP8算力、HBM带宽、ICI带宽。把这三个数字列出来，很多宣传话术就看穿了。第八代TPU如果真能做到推演区间的上限，那它大概率值得等；如果只做到下限，那和v7的差距就只体现在容量和功耗上，选型时就要多问一句：训练收益是不是真的兑现了。