最近后台几乎被同一个问题刷屏Google第八代TPU训练与推理芯片的详版参数到底出来了没有不管是做预训练的朋友还是做推理服务的架构师都盯着这一代芯片的数字因为算力、内存带宽和互联能力直接决定未来一年的模型成本曲线。我之前整理过TPU v7 Ironwood的资料这次把第八代按行业习惯直接称呼为V8的路标参数、训练与推理场景里的实际用法以及落地时容易踩的坑统一写清楚。需要先说明文章里所有带“推演”“预估”字样的参数是我根据Google公开技术路线、Cloud Next大会释放的信号和供应链消息整理的合理外推不是官方最终规格但足够用来做架构选型和成本估算。适合正在评估大规模训练集群、做推理服务改造或者单纯想搞明白TPU迭代逻辑的工程师。1. 先厘清代际为什么说第八代是训推一体的分水岭1.1 从v1到v7TPU是怎么一步步走到今天的Google的TPU路线图其实非常清晰每一代解决的问题都不一样。如果不先理解这条演进主线拿到第八代的参数表也会一头雾水。代际发布时间定位与核心变化TPU v12015年专攻推理矩阵乘固定shape不能训练TPU v22017年引入BF16补齐训练能力开始支持大集群TPU v32018年提高训练性能和互联带宽水冷进入机柜TPU v42021年引入稀疏化和光交换互联集群拓扑从固定变动态TPU v5e/v5p2023年一个主打成本和均衡一个主打高性能预训练TPU v6eTrillium2024年能效大幅提升训练推理均衡成为主流云上选择TPU v7Ironwood2025年推理优先单芯片吞吐惊人但训练场景不够“全能”从这个序列能看出一条明显规律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区间这必须搭配液冷机柜否则风冷根本压不住。这里有个很重要的判断方法峰值算力只是一个门面指标真正决定训练快不快的是MFUModel 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的ICIInter-Chip Interconnect片间互联带宽预计会从v7的级别再翻一倍达到双向5TB/s到6.4TB/s的量级。同时Google大概率延续OCS光交换方案让超节点之间的拓扑可以动态重配。为什么要强调这个大模型训练如今都是张量并行、序列并行、专家并行一起上每个step都要做大量all-reduce和all-to-all通信。如果互联带宽只有HBM带宽的一半那大部分时间都在等数据搬运。第八代把ICI带宽拉高后最直接的收益是MoE模型的专家分发不再成为瓶颈长序列的序列并行也能跑得更稳。我把推演参数整理成一个表方便你对照着看参数项推演区间主要判断依据制程3nm级别改进版N3P量级v7已使用先进制程V8跟进改进节点FP8算力3800–4600 TOPS在v7推理峰值基础上继续翻倍BF16/FP16算力1900–2300 TFLOPS通常为FP8的一半FP4稀疏算力7000 TOPS推算稀疏加速从v4开始就是TPU传统优势HBM容量192–288GB每芯片为万亿参数训练和长上下文推理留空间HBM带宽9.6–16TB/s每芯片对标HBM4代际提升幅度ICI带宽5–6.4TB/s双向每芯片超节点内全互联拓扑所需单芯片功耗1400–1800W训练推理双高负载液冷是刚需超节点形态256–512 TPU为一个大组延续v6/v7的pod级互联方案再强调一次以上是推演表不是官方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优化器状态8fp32均值方差平均每参数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在这种场景下的并行配置我建议这样设计张量并行TP8或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_size8是为了把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的推理能力已经很能打但第八代的核心变化在于训练能力不再妥协。两者目前按推演口径的差异如下指标TPU v7 Ironwood已发布TPU v8推演主要定位推理优先兼顾轻量训练训推一体重训练和重推理都能扛FP8算力量级高但面向服务吞吐优化继续提升目标翻倍HBM容量面向KV Cache和单请求低延迟面向训练优化器长上下文双需求互联拓扑适合数据并行和专家并行强化all-to-all适配大规模MoE训练功耗设计推理负载功耗曲线更平训练峰值更高液冷设计更强选型逻辑很直接你如果只是做稳定在线推理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 存储带宽与checkpointHBM再大也会被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的差距就只体现在容量和功耗上选型时就要多问一句训练收益是不是真的兑现了。 
长河君 · 2026/10/28 17:16:28 · 阅读 1.2k 第八代TPU训推一体芯片：参数推演、架构选型与落地避坑指南
最近后台几乎被同一个问题刷屏Google第八代TPU训练与推理芯片的详版参数到底出来了没有不管是做预训练的朋友还是做推理服务的架构师都盯着这一代芯片的数字因为算力、内存带宽和互联能力直接决定未来一年的模型成本曲线。我之前整理过TPU v7 Ironwood的资料这次把第八代按行业习惯直接称呼为V8的路标参数、训练与推理场景里的实际用法以及落地时容易踩的坑统一写清楚。需要先说明文章里所有带“推演”“预估”字样的参数是我根据Google公开技术路线、Cloud Next大会释放的信号和供应链消息整理的合理外推不是官方最终规格但足够用来做架构选型和成本估算。适合正在评估大规模训练集群、做推理服务改造或者单纯想搞明白TPU迭代逻辑的工程师。1. 先厘清代际为什么说第八代是训推一体的分水岭1.1 从v1到v7TPU是怎么一步步走到今天的Google的TPU路线图其实非常清晰每一代解决的问题都不一样。如果不先理解这条演进主线拿到第八代的参数表也会一头雾水。代际发布时间定位与核心变化TPU v12015年专攻推理矩阵乘固定shape不能训练TPU v22017年引入BF16补齐训练能力开始支持大集群TPU v32018年提高训练性能和互联带宽水冷进入机柜TPU v42021年引入稀疏化和光交换互联集群拓扑从固定变动态TPU v5e/v5p2023年一个主打成本和均衡一个主打高性能预训练TPU v6eTrillium2024年能效大幅提升训练推理均衡成为主流云上选择TPU v7Ironwood2025年推理优先单芯片吞吐惊人但训练场景不够“全能”从这个序列能看出一条明显规律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区间这必须搭配液冷机柜否则风冷根本压不住。这里有个很重要的判断方法峰值算力只是一个门面指标真正决定训练快不快的是MFUModel 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的ICIInter-Chip Interconnect片间互联带宽预计会从v7的级别再翻一倍达到双向5TB/s到6.4TB/s的量级。同时Google大概率延续OCS光交换方案让超节点之间的拓扑可以动态重配。为什么要强调这个大模型训练如今都是张量并行、序列并行、专家并行一起上每个step都要做大量all-reduce和all-to-all通信。如果互联带宽只有HBM带宽的一半那大部分时间都在等数据搬运。第八代把ICI带宽拉高后最直接的收益是MoE模型的专家分发不再成为瓶颈长序列的序列并行也能跑得更稳。我把推演参数整理成一个表方便你对照着看参数项推演区间主要判断依据制程3nm级别改进版N3P量级v7已使用先进制程V8跟进改进节点FP8算力3800–4600 TOPS在v7推理峰值基础上继续翻倍BF16/FP16算力1900–2300 TFLOPS通常为FP8的一半FP4稀疏算力7000 TOPS推算稀疏加速从v4开始就是TPU传统优势HBM容量192–288GB每芯片为万亿参数训练和长上下文推理留空间HBM带宽9.6–16TB/s每芯片对标HBM4代际提升幅度ICI带宽5–6.4TB/s双向每芯片超节点内全互联拓扑所需单芯片功耗1400–1800W训练推理双高负载液冷是刚需超节点形态256–512 TPU为一个大组延续v6/v7的pod级互联方案再强调一次以上是推演表不是官方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优化器状态8fp32均值方差平均每参数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在这种场景下的并行配置我建议这样设计张量并行TP8或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_size8是为了把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的推理能力已经很能打但第八代的核心变化在于训练能力不再妥协。两者目前按推演口径的差异如下指标TPU v7 Ironwood已发布TPU v8推演主要定位推理优先兼顾轻量训练训推一体重训练和重推理都能扛FP8算力量级高但面向服务吞吐优化继续提升目标翻倍HBM容量面向KV Cache和单请求低延迟面向训练优化器长上下文双需求互联拓扑适合数据并行和专家并行强化all-to-all适配大规模MoE训练功耗设计推理负载功耗曲线更平训练峰值更高液冷设计更强选型逻辑很直接你如果只是做稳定在线推理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 存储带宽与checkpointHBM再大也会被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的差距就只体现在容量和功耗上选型时就要多问一句训练收益是不是真的兑现了。