Tensor Parallelism

Tensor parallelism is a model-parallel technique that splits the individual weight matrices inside a layer across multiple GPUs, so each device stores and multiplies only a slice of the layer rather than the whole thing. Where the model is too large for one accelerator's memory or too slow on one device, tensor parallelism divides each matmul — the dominant operation in a transformer — into shards computed in parallel, then recombines the partial results with a collective communication step before the next layer runs.

It shards the matmul, not the model's layers. A layer computes Y = X·W. Tensor parallelism cuts the weight matrix W into pieces — by columns or by rows — and hands each piece to a different GPU. Every GPU multiplies the same input by its own shard, producing a partial slice of the output. Because the work is divided within a single operation, all participating GPUs run the same layer at the same time on different data columns, which is why it is called intra-layer parallelism, in contrast to pipeline parallelism that assigns whole layers to different devices.

The unavoidable cost is a collective every layer. Splitting W means no single GPU holds the full output, so the shards must be stitched back together — an all-reduce (for row splits) or all-gather (for column splits) — on every forward pass and again on every backward pass. That collective moves activation-sized data between all GPUs in the group, and it sits on the critical path: the next layer cannot start until the recombination finishes. As the group grows, per-GPU compute shrinks toward 1/N but the communication share climbs, so the interconnect, not the math, sets the ceiling.

Tensor parallelismPipeline parallelism
Splitsweights within a layerwhole layers into stages
Granularityintra-layerinter-layer
Communicationall-reduce/all-gather per layeractivations at stage boundaries
Frequencyevery layer, fwd + bwdbetween stages
Best domainfast NVLink islandacross nodes tolerable
Tensor parallelism — split one layer's weight matrix across GPUs, then all-reduce One matmul Y = X·W, W sharded by columns activations X × W₁ GPU 0 W₂ GPU 1 = Y₁ | Y₂ (each GPU holds half the output) all-reduce / all-gather to recombine before next layer The trade: more GPUs cut per-GPU work but add comm tensor-parallel GPUs (N) →1248compute / GPUcomm / layer Each GPU stores and computes only its shard of the layer's weights — so a layer too big for one GPU's memory now fits. But every sharded matmul needs a collective (all-reduce/all-gather) each forward and backward pass to stitch partial results. So tensor parallelism is kept inside a fast NVLink domain; crossing slow links makes the collective the bottleneck.

It only pays off inside a fast interconnect domain. Because a collective fires on every sharded layer, tensor parallelism is bandwidth- and latency-bound and is normally confined to the GPUs wired together by a high-speed scale-up fabric such as NVLink within a single server. Push it across slower links between nodes and the all-reduce dominates, erasing the compute speedup. In practice large models combine it with the others: tensor parallelism inside a node, pipeline parallelism across nodes, and data parallelism across replicas — each chosen to match the bandwidth available at that level.

Read tensor parallelism through a quant lens rather than a 'just add GPUs' lens: the useful compute per GPU falls as 1/N, but the collective moves activation-sized bytes every layer, so the speedup holds only while interconnect bandwidth keeps the all-reduce shorter than the compute it overlaps. The design question is the ratio of matmul FLOPs to bytes-per-collective at a given N — which is exactly why tensor parallelism lives inside an NVLink island and stops at its edge, where the communication term overtakes the compute term.

Take tensor parallelism further

Ask the copilot about this term, or have our engineers assess it against your process.