谷歌表示，其TRC包含1000个TPU2芯片，但是这一数字略有下降。四个机柜包含1024个TPU2芯片。因此，四个机柜是Google已经部署了了的TPU2芯片数量的下限。从Google I / O大会期间发布的照片中可以看到三个（业可能是四个）机柜。

　　不清楚处理器和TPU2芯片是如何通过一个机柜进行联合，以便TPU2芯片可以在超网格中跨链接有效地共享数据的。但我们几乎可以肯定，TRC不能跨越四个机柜（256个TPU2芯片）中的一个以上的单个任务。原始TPU是一个简单的协处理器，因此处理器处理所有数据流量。在这种架构中，处理器通过数据中心网络从远程存储器访问数据。

　　关于机柜模型也没有很多的描述。 TPU2芯片可以在OPA上使用远程直接存储器访问（RDMA）从处理器板上的内存中加载自己的数据吗？这好像是可以的。处理器板似乎也可能在机柜上执行相同操作，创建大型共享内存池。该共享内存池不会像Hewlett Packard Enterprise的机器共享内存系统原型中的内存池那么快，但是使用25 GB / s的链接，它的速度也不会太慢，atv，内存依旧很大，这是在两位tb范围内的（每个DIMM 16 GB，每个处理器有8个DIMM，每个板有两个处理器，64个板产生16 TB的内存）。

　　我们推测，在一个机柜上安排一个需要多个TPU2的任务看起来像这样：

　　处理器池应该有一个机柜的超网格拓扑图，哪些TPU2芯片可用于运行任务。

　　处理器组可能联合编程每个TPU2以明确地连接位于两个相连接的TPU2芯片之间的网格。

　　每个处理器板将数据和指令加载到其配对的TPU2板上的四个TPU2芯片上，包括网状互连的流量控制。

　　处理器在互连的TPU2芯片之间同步引导任务。

　　当任务完成时，处理器从TPU2芯片收集所得到的数据（该数据可能已经通过RDMA存储在全局存储器池中），并将TPU2芯片标记为可用于另一任务。

　　这种方法的优点是TPU2芯片不需要理解多任务，虚拟化或多租户——处理器的任务是处理所有跨越机柜的这些任务。

　　这也意味着如果Google曾经提供Cloud TPU实例作为其Google Cloud Platform自定义机器类型IaaS的一部分，该实例将必须包括处理器和TPU2芯片。

　　还不清楚的是，工作负载能否可以跨stamp进行缩放，并保留超级网格的低延迟和高吞吐量。虽然研究人员可能可以通过TRC访问1,024个TPU2芯片中的一些，但跨stamp进行扩展工作负载看起来仍是一个挑战。研究人员可能有能力连接多达256个TPU2芯片的集群，这足以令人印象深刻，因为云GPU连接目前正在扩展到32个互连设备（通过Microsoft的Olympus HGX-1设计）。

　　Google的第一代TPU在负载下消耗40瓦特，同时以23 TOPS的速率执行16位整数矩阵乘法。Google将TPU2的运行速度提高到45 TFLOPS，同时通过升级到16位浮点运算来提高计算复杂度。根据一个粗略的经验法则来看的话，这至少是两倍的功耗——如果除了将速度提高两倍以及转移到FP16外，什么也不做的话，TPU2必须消耗至少160瓦。散热器尺寸显示出更高的功耗，某处甚至高于200瓦特。

　　TPU2板具有位于TPU2芯片顶部的巨大散热片。它们是多年来我看到的最高的风冷散热片。它们具有内部密封环液体循环。在下图中，我们将TPU2散热片与过去几个月看到的最大的可比散热片进行相比较。

　　散热片遍历：A是四路TPU2主板侧面视图，B为双IBM Power9“Zaius”主板，C为双IBM Power8“明斯基”主板，D为双英特尔至强Facebook“优胜美地”主板，E为Nvidia P100 SMX2 模块与散热片和Facebook“Big Basin”主板

　　这些散热器的尺寸大多“每个超过200W”。很容易看出，它们比原始TPU上的40瓦散热器大得多。这些散热器填补了两个Google垂直的1.5英寸，Google外形尺寸单元空缺，因此它们几乎高达三英寸。（Google机架单元高度为1.5英寸，比行业标准1.75英寸U型高型号矮一点）。

　　这是一个很好的选择，每个TPU2芯片还有更多的内存，这有助于提高吞吐量并增加功耗。