Skip to main content
Tensor Parallelism (TP) is a model parallelism technique that splits model weights and computations across multiple GPUs, enabling efficient serving of large models that don’t fit on a single GPU.

Overview

Mini-SGLang supports distributed serving through Tensor Parallelism. By specifying the number of GPUs with the --tp flag, you can scale performance and handle larger models across multiple devices.
Tensor Parallelism is essential for serving large models (70B+ parameters) that exceed single GPU memory capacity. It also provides performance benefits through parallel computation.

How Tensor Parallelism Works

Weight Sharding

Model weights are split across GPUs. For linear layers, there are two main patterns: Column Parallel: Split output dimension
Row Parallel: Split input dimension

Communication Patterns

Tensor parallelism requires collective communication between GPUs:
  • All-Reduce: Sum tensors from all GPUs and distribute result to all GPUs
  • All-Gather: Concatenate tensors from all GPUs and distribute to all GPUs
These operations are implemented via NCCL for high-bandwidth GPU-to-GPU communication.

Architecture

One Scheduler Per GPU

In a multi-GPU setup, there is one Scheduler Worker for each GPU, referred to as a TP Rank:

Communication Flow

From /home/daytona/workspace/source/docs/structures.md:20:
  1. User sends a request to the API Server
  2. API Server forwards it to the Tokenizer
  3. Tokenizer converts text to tokens and sends them to the Scheduler (Rank 0)
  4. Scheduler (Rank 0) broadcasts the request to all other Schedulers
  5. All Schedulers schedule the request and trigger their local Engine to compute
  6. Engines communicate via NCCL to perform distributed computation
  7. Scheduler (Rank 0) collects the output token and sends it to the Detokenizer
  8. Detokenizer converts the token to text and sends it back to the API Server
  9. API Server streams the result back to the User
Only Rank 0 communicates with the tokenizer and detokenizer. Other ranks receive broadcasts from Rank 0 and participate in distributed computation.

Implementation

Distributed Communicator

Mini-SGLang provides a DistributedCommunicator abstraction:
Two implementations are supported:

PyTorch Distributed (Default)

Uses PyTorch’s built-in distributed package with NCCL backend.

PyNCCL (Optional)

Custom NCCL bindings for potentially better performance:

Layer Implementation

Mini-SGLang implements TP-aware layers in minisgl.layers:

Column Parallel Linear

Splits the output dimension:
Used in:
  • Attention QKV projections (split heads across GPUs)
  • MLP up-projection (split intermediate dimension)

Row Parallel Linear

Splits the input dimension:
Used in:
  • Attention output projection (reduce across heads)
  • MLP down-projection (reduce across intermediate)

Embedding and LM Head

Embeddings and language model heads can also be parallelized:

Performance Considerations

Communication Overhead

Tensor parallelism introduces communication overhead:
  • All-reduce: Required after row-parallel layers
  • All-gather: Required for certain operations
  • Latency: Network latency between GPUs affects performance
For best TP performance, use GPUs connected via NVLink or NVSwitch. PCIe connections have higher latency and lower bandwidth, which can bottleneck communication.

Scaling Efficiency

TP scaling efficiency depends on:
  1. Model size: Larger models amortize communication overhead better
  2. Batch size: Larger batches improve arithmetic intensity
  3. Network topology: NVLink > PCIe for inter-GPU communication
  4. Sequence length: Longer sequences increase computation vs. communication ratio

When to Use TP

Good use cases:
  • Model doesn’t fit on single GPU (e.g., 70B, 405B parameter models)
  • Low latency requirements (distribute computation)
  • GPUs connected via high-bandwidth interconnect
Alternatives to consider:
  • Pipeline Parallelism: For models that fit but need more throughput
  • Quantization: Reduce memory footprint (e.g., INT8, INT4)
  • Larger GPU: Single A100 (80GB) may be better than 2x A100 (40GB)

Configuration Examples

Small Model (Testing)

Medium Model

Large Model

Very Large Model

Custom Port

Benchmark Results

From Mini-SGLang’s online inference benchmark: Test Configuration:
  • Hardware: 4x H200 GPU, connected by NVLink
  • Model: Qwen3-32B
  • Dataset: Qwen trace, 1000 requests
Online Benchmark Tensor parallelism enables serving large models with competitive performance.

Supported Models

Mini-SGLang currently supports TP for:
  • Llama-3 series: Llama-3.1-8B, Llama-3.1-70B, Llama-3.1-405B
  • Qwen-3 series: Qwen3-0.6B, Qwen3-14B, Qwen3-32B (including MoE variants)
  • Qwen-2.5 series: All sizes
All dense model architectures in Mini-SGLang support tensor parallelism out of the box.

Troubleshooting

NCCL Errors

If you see NCCL errors:

GPU Visibility

Ensure all GPUs are visible:

Out of Memory

If OOM occurs even with TP:

Architecture

Learn about the distributed system design

Chunked Prefill

Optimize memory usage in TP deployments

Radix Cache

Efficient KV cache management for TP

References