Skip to main content
Multi-node distributed training enables you to scale fine-tuning across multiple machines, allowing you to train larger models faster or handle massive datasets that don’t fit on a single machine.

Overview

Multi-node training distributes the workload across multiple servers, each with multiple GPUs:
  • Scale to larger models: Train Qwen-72B or larger on multiple machines
  • Faster training: Reduce training time through data parallelism
  • Handle large datasets: Distribute data across nodes
  • Cost efficiency: Use available cluster resources effectively
Multi-node training works with all fine-tuning methods: full-parameter, LoRA, and Q-LoRA.

Architecture

Single Node vs Multi-node

Prerequisites

Hardware Requirements

  • Network: High-speed interconnect required
    • Recommended: InfiniBand (100+ Gbps) or RoCE
    • Minimum: 10GbE Ethernet (performance degradation expected)
  • GPUs: Same GPU types across all nodes for best results
  • Storage: Shared filesystem (NFS) or synchronized data on each node

Software Requirements

Network Configuration

1

Ensure SSH Connectivity

All nodes must be able to SSH to each other without password:
2

Configure Firewall

Open required ports:
3

Verify Network Speed

Test inter-node bandwidth:

Multi-node Configuration

Environment Variables

Each node needs these environment variables set:
int
required
Total number of nodes (machines) in the training cluster.
int
required
Rank of current node. Master node is 0, workers are 1, 2, 3, …
string
required
IP address or hostname of the master node (rank 0).
int
required
Port for communication between nodes (default: 6001).
int
required
Number of GPUs on each node. Must be the same across all nodes.

Multi-node LoRA Training

Training Script

The finetune_lora_ds.sh script supports multi-node training:
finetune/finetune_lora_ds.sh

Launch Multi-node Training

1

Prepare Data on All Nodes

Ensure training data is accessible on all nodes:Option 1: Shared filesystem (NFS)
Option 2: Copy to each node
2

Configure Master Node (Rank 0)

On the master node:
3

Configure Worker Nodes (Rank 1, 2, ...)

On worker node 1:
4

Monitor Training

Only the master node (rank 0) will print training logs:
Check all nodes are participating:

Multi-node Full-Parameter Training

Configuration

ZeRO Stage Selection

Important: DeepSpeed ZeRO-3 requires high inter-node bandwidth and significantly reduces training speed in multi-node setups.
ZeRO-2 (Recommended for multi-node):
  • Shards optimizer states and gradients
  • Lower communication overhead
  • Better multi-node performance
  • Use: finetune/ds_config_zero2.json
ZeRO-3 (Only for high-bandwidth interconnect):
  • Shards model parameters, gradients, and optimizer states
  • Maximum memory efficiency
  • High communication requirements (InfiniBand recommended)
  • Use: finetune/ds_config_zero3.json

Multi-node Q-LoRA Training

Q-LoRA with multi-node can train Qwen-72B on 4x single-GPU nodes (24GB each), whereas LoRA would require 80GB GPUs.

Performance Benchmarks

Qwen-7B LoRA Multi-node Performance

Setup: 2 nodes, 2x A100-80GB per node
From README line 798-799: Multi-node training results show LoRA (multinode) configuration.

Scaling Efficiency

Scaling efficiency decreases with more nodes due to communication overhead. Best efficiency with high-bandwidth interconnect.

Troubleshooting

Symptoms: Workers hang at initialization, no training startsDebug steps:
  1. Verify master IP is correct:
  1. Test connectivity from workers:
  1. Check firewall:
  1. Verify NODE_RANK is unique per node:
Possible causes:
  1. Low network bandwidth:
  1. Using ZeRO-3 (not recommended for multi-node):
  1. Network congestion:
  • Ensure dedicated network for training
  • Disable other network-intensive tasks
  1. Small batch size:
Symptoms: Different loss values reported, training unstableSolutions:
  1. Ensure same data on all nodes:
  1. Same random seed:
  1. Synchronized model loading:
  • Use shared checkpoint directory
  • Or ensure same model downloaded on all nodes
  1. Check NCCL errors in logs:
Issue: NCCL timeout or NCCL communication failedSolutions:
  1. Increase timeout:
  1. Check network configuration:
  1. Use correct NCCL backend:
Cause: Uneven data distribution or node configurationSolutions:
  1. Ensure same GPU types across nodes
  2. Verify same number of GPUs per node
  3. Balance data distribution:
  1. Reduce batch size:

Best Practices

Network Optimization

Optimize inter-node communication:

Data Management

Shared filesystem (recommended):
  • Use NFS or distributed filesystem (e.g., CephFS)
  • Single source of truth for data and checkpoints
  • Automatic synchronization
Replicated data (alternative):
  • Copy data to local storage on each node
  • Faster I/O (no network overhead)
  • Must manually synchronize updates

Checkpoint Strategy

Only the master node (rank 0) saves checkpoints. Worker nodes will wait during checkpoint saving.

Monitoring Multi-node Training

On master node:
On worker nodes:

Advanced: Launching with Job Schedulers

SLURM

slurm_train.sh
Submit job:

PBS/Torque

pbs_train.sh

Performance Tuning

Optimal Batch Size

Adjust for best throughput:
Target effective batch size of 64-256 for LoRA fine-tuning. Adjust gradient accumulation to balance memory and throughput.

Communication Optimization

Cost Optimization

Use Spot/Preemptible Instances

Mix Node Types

Not recommended: Mixing different GPU types can cause:
  • Load imbalance
  • Synchronization issues
  • Reduced performance
If necessary, group same GPU types together.

Next Steps

LoRA Fine-tuning

Understand LoRA for efficient multi-node training

Data Preparation

Prepare data for distributed training