Когда одна карта спит: как заставить dual RTX 3090 работать на полную мощность в LLM инференсе

Вы купили вторую RTX 3090, подключили NVLink мост, запустили Llama 3.1 70B — и увидели шокирующую картину. Первая карта загружена на 95%, вторая скромно покачивается на 15-20%. Деньги на ветер, электричество греет воздух, а скорость инференса почти не выросла.

Знакомо? Я тоже через это прошел. В теории две карты должны работать в два раза быстрее. На практике большинство фреймворков по умолчанию используют только одну GPU, а вторую держат про запас «на всякий случай». Сегодня я покажу, как заставить обе карты пахать как проклятые.

Почему вторая карта простаивает (и это не баг)

Здесь нужно понять фундаментальную разницу между двумя подходами:

Большинство локальных инструментов (Ollama, LM Studio, Text Generation WebUI) по умолчанию используют Pipeline Parallelism. И это логично — проще всего реализовать. Но если слои распределены неравномерно, одна карта становится узким местом.

Три реальных способа загрузить обе карты

Я перепробовал десятки конфигураций. Вот что действительно работает в 2026 году.

1 Tensor Parallelism в vLLM: самый быстрый способ

vLLM — это не просто еще один фреймворк. Это система, которая изначально проектировалась для эффективного распределения вычислений. Начиная с версии 0.4.0 (актуально на февраль 2026), они серьезно улучшили поддержку tensor parallelism для потребительских GPU.

# Устанавливаем последнюю версию
pip install vllm==0.4.2

# Запускаем модель с распределением по двум GPU
python -m vllm.entrypoints.openai.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.3 \
    --tensor-parallel-size 2 \
    --gpu-memory-utilization 0.95 \
    --max-model-len 8192

Ключевой параметр здесь — --tensor-parallel-size 2. Он говорит vLLM разделить матричные операции между двумя картами. Результат? Обе карты загружены на 85-95%, скорость инференса возрастает в 1.8 раза.

2 Ручное распределение слоев в Transformers

Когда автоматика не справляется, берем PyTorch и делаем все руками. Этот способ дает полный контроль, но требует понимания архитектуры модели.

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

# Загружаем модель
model_name = "meta-llama/Llama-3.1-8B"
model = AutoModelForCausalLM.from_pretrained(
    model_name,
    torch_dtype=torch.float16,
    device_map="auto"  # Пока не работает как нужно
)

# Вручную распределяем слои
num_layers = model.config.num_hidden_layers
layers_per_gpu = num_layers // 2

# Переносим первые половины слоев на GPU 0
for i in range(layers_per_gpu):
    model.model.layers[i] = model.model.layers[i].to("cuda:0")

# Вторую половину — на GPU 1
for i in range(layers_per_gpu, num_layers):
    model.model.layers[i] = model.model.layers[i].to("cuda:1")

# Входной и выходной слои тоже распределяем
model.model.embed_tokens = model.model.embed_tokens.to("cuda:0")
model.lm_head = model.lm_head.to("cuda:1")

Сложность в том, что нужно знать архитектуру конкретной модели. Для Llama это работает, для Qwen или Yi — придется адаптировать.

3 LM Studio с активацией dual-GPU

LM Studio в версии 0.3.1 (февраль 2026) наконец-то получила нормальную поддержку multi-GPU. Но настройка спрятана глубоко.

Шаги:

1. Запускаем LM Studio
2. В Settings → Advanced находим "GPU Offload Layers"
3. Ставим галочку "Use Multiple GPUs"
4. В "GPU Layer Distribution" выбираем "Auto-balance"
5. Для больших моделей (70B+) включаем "Enable NVLink Optimizations"

Проблема LM Studio в том, что она не показывает реальную загрузку карт. Чтобы проверить, что все работает, открываем терминал:

# Следим за утилизацией GPU
watch -n 0.5 nvidia-smi

# Или более подробно
nvidia-smi dmon -s pu -c 1000

Почему NVLink все еще важен (даже с правильным распределением)

Вы можете правильно распределить слои модели, но если карты общаются через PCIe — производительность упрется в пропускную способность. Вот цифры для RTX 3090:

Без NVLink карты тратят время на ожидание данных друг от друга. Особенно это заметно в tensor parallelism, где матрицы постоянно синхронизируются.

Проверяем, работает ли NVLink:

nvidia-smi nvlink --status

# Должно показать что-то вроде:
# GPU 0: Tesla V100-SXM2-32GB
#         Link 0: 25.781250 GB/s
# GPU 1: Tesla V100-SXM2-32GB
#         Link 0: 25.781250 GB/s

Если видите нули — NVLink не работает. Возможные причины: неправильно установлен мост, устаревшие драйверы, или материнская плата не поддерживает SLI/NVLink.

Пять ошибок, которые убивают производительность

Я наступил на все эти грабли. Сохраните себе.

• Ошибка 1: Неравномерное распределение слоев. Если на одну карту попало 40 слоев, а на другую 20 — первая будет узким местом. Всегда проверяйте nvidia-smi во время работы.
• Ошибка 2: Игнорирование теплового дросселинга. Две RTX 3090 вплотную нагревают друг друга до 85-90°C. При такой температуре карты автоматически снижают частоту. Решение — агрессивная вентиляция или водяное охлаждение.
• Ошибка 3: Запуск через WSL2 на Windows. Прямой доступ к NVLink в WSL2 работает через раз. Если серьезно работаете с LLM — ставьте Linux.
• Ошибка 4: Недостаток оперативной памяти. Когда VRAM забита, система начинает использовать swap. Для dual RTX 3090 нужно минимум 64GB RAM, лучше 128GB.
• Ошибка 5: Использование разных моделей карт. Две RTX 3090 от разных производителей могут иметь разную частоту памяти. NVLink синхронизируется по минимальной частоте.

Конкретные цифры: что получаем на практике

Я протестировал три конфигурации на модели Llama 3.1 70B (4-битное квантование):

Разница между «просто двумя картами» и правильно настроенной системой — 52% прироста производительности. Это не линейное удвоение, но близко к максимально возможному для pipeline parallelism.

Что делать, если ничего не помогает

Бывает, что конкретная модель или фреймворк отказываются работать с двумя картами. В этом случае есть обходной путь — запускать две независимые модели.

Сценарий: у вас есть API-сервер, который обрабатывает запросы к LLM. Вместо одной большой модели на двух картах запускаем две средних модели — по одной на каждую карту. Запросы распределяются между ними.

# Пример на FastAPI
from fastapi import FastAPI
import torch
from transformers import pipeline
import asyncio

app = FastAPI()

# Загружаем модель на первую карту
pipe1 = pipeline("text-generation", 
                 model="mistralai/Mistral-7B-Instruct-v0.3",
                 device=0,  # GPU 0
                 torch_dtype=torch.float16)

# Загружаем ту же модель на вторую карту
pipe2 = pipeline("text-generation",
                 model="mistralai/Mistral-7B-Instruct-v0.3",
                 device=1,  # GPU 1
                 torch_dtype=torch.float16)

# Простой балансировщик нагрузки
current_gpu = 0

def get_next_pipe():
    global current_gpu
    if current_gpu == 0:
        current_gpu = 1
        return pipe1
    else:
        current_gpu = 0
        return pipe2

@app.post("/generate")
async def generate_text(prompt: str):
    pipe = get_next_pipe()
    result = pipe(prompt, max_length=512)
    return {"text": result[0]["generated_text"]}

Это не ускорит обработку одного запроса, но позволит обрабатывать два запроса параллельно. Для чат-ботов и API-сервисов такой подход часто эффективнее.

А что насчет 4 карт или больше?

С двумя RTX 3090 все относительно просто. Когда карт становится 4 или 8, как в моей сборке на 8 карт, проблемы множатся.

Основные сложности:

• PCIe lanes делятся между картами (x8/x8/x8/x8 вместо x16/x16)
• Проблемы с питанием (две RTX 3090 потребляют до 700W под нагрузкой)
• Тепловой пакет — 8 карт выделяют 2.5-3kW тепла
• Сложность балансировки нагрузки между 4+ устройствами

Для серьезных multi-GPU установок смотрите в сторону профессиональных решений вроде NVIDIA DGX или серверных материнских плат с правильной PCIe топологией.

Проверка результатов: как понять, что все работает

После настройки запустите этот скрипт для диагностики:

import torch
import time

print(f"PyTorch version: {torch.__version__}")
print(f"CUDA available: {torch.cuda.is_available()}")
print(f"CUDA version: {torch.version.cuda}")
print(f"Number of GPUs: {torch.cuda.device_count()}")

# Проверяем NVLink
for i in range(torch.cuda.device_count()):
    for j in range(i+1, torch.cuda.device_count()):
        can_access = torch.cuda.can_device_access_peer(i, j)
        print(f"GPU {i} can access GPU {j}: {can_access}")

# Тест производительности
if torch.cuda.device_count() >= 2:
    size = 10000
    a = torch.randn(size, size, device='cuda:0')
    b = torch.randn(size, size, device='cuda:1')
    
    start = time.time()
    # Переносим тензор с GPU1 на GPU0 через NVLink/PCIe
    b_on_0 = b.to('cuda:0')
    result = torch.mm(a, b_on_0)
    elapsed = time.time() - start
    
    print(f"\nMatrix multiplication test (10000x10000):")
    print(f"Time: {elapsed:.3f} seconds")
    print(f"Bandwidth estimate: {(size*size*4*2)/elapsed/1e9:.2f} GB/s")

Ожидаемая пропускная способность при работе NVLink — 80-100 GB/s. Если видите 20-30 GB/s — карты общаются через PCIe.

Будущее multi-GPU: что нас ждет в 2026-2027

Проблема idle-карт постепенно решается на уровне фреймворков. Вот что уже появляется:

• vLLM 0.5 (анонсирована на Q1 2026) — обещают автоматическую балансировку нагрузки между гетерогенными GPU (разные модели карт)
• PyTorch 2.4 — улучшенная поддержка unified memory с NVLink
• NVIDIA Blackwell — новые архитектуры с лучшей масштабируемостью
• AMD ROCm 6.0 — догоняет CUDA в multi-GPU сценариях

Но пока эти технологии не стали mainstream, придется настраивать все вручную. Главное — не бояться экспериментировать. Начинайте с vLLM и tensor parallelism, проверяйте загрузку карт, и не забывайте про охлаждение.

И помните: две правильно настроенные RTX 3090 с NVLink работают почти как одна RTX 6000 Ada, но стоят в три раза дешевле. Разница только в драйверах и гарантии. А гарантия в мире AI-энтузиастов — это первый сгоревший блок питания.