GPUDirect Storage + TurboQuant на AWS: ускоряем загрузку LLM и раздвигаем контекстное окно до небес

Пока модель грузится, жизнь проходит мимо

Каждый, кто разворачивал большую языковую модель в облаке, знает эту боль: нажал "deploy", пошёл пить кофе, вернулся — а контекст всего 32K, и то не влезает. Cold start (time-to-first-token, TTFT) на инстансах с GPU может длиться минуты при загрузке модели весом 300+ ГБ. А если хочешь длинный контекст в 256K или 1M токенов — KV cache сжирает всю память, и приходится решать дилемму: либо быстро, либо много.

В 2026 году есть два технологических прорыва, которые ломают эту дилемму: GPUDirect Storage (GDS) — прямой доступ GPU к NVMe-хранилищу в обход CPU/RAM, и TurboQuant — сжатие KV cache до 3-4 бит без потери качества. Обе технологии доступны на AWS в связке с новейшими инстансами P6e на базе NVIDIA Blackwell (B200/B300). В этой статье мы соберём их вместе и посмотрим, что получится. Спойлер: работает.

Как НЕ надо делать: классический cold start

Допустим, вы подняли p6e.48xlarge (8x B300, 240 GB HBM3e на GPU) и решили запустить Llama 3.1 405B. Веса модели (fp16) — 810 ГБ. Без GDS загрузка идёт через CPU: файлы читаются с EBS или FSx Lustre в системную память (512 GB), потом копируются в GPU. Это два лишних hop'а. TTFT — 45 секунд. И это ещё без KV cache — добавили контекст 128K → ещё 30 секунд на аллокацию. Итог: минута до первого токена. Пользователь ушёл к конкуренту.

Корень зла — bottleneck на PCIe и CPU RAM. GDS позволяет GPU читать данные напрямую с NVMe (или FSx Lustre через RDMA) минуя системную память. Результат: загрузка весов занимает 5-7 секунд. TTFT падает в 6-8 раз.

GDS + TurboQuant: план атаки

Нам нужно:

• Инстанс P6e с поддержкой GDS (все P6e поддерживают RDMA, но для FSx нужен Lustre с включённым rdma_backed).
• Развёрнутый Amazon FSx for Lustre (файловая система с прямым доступом по RDMA).
• Модель, подготовленная для GDS (например, в формате .gguf или safetensors с выравниванием блоков).
• Запускалка — llama.cpp с поддержкой TurboQuant (v2.1+) и GDS (флаг --gds).
• Опционально — кастомный Rust-клиент для дополнительного контроля.

Весь пайплайн: FSx Lustre → GPU via GDS → модель загружена → при каждом запросе TurboQuant сжимает KV cache до 3-4 бит, освобождая память под ещё больший контекст.

Шаг 1: Разворачиваем инфраструктуру на AWS через Terraform

Вместо консоли — код. Мы создадим VPC, FSx Lustre (с RDMA) и инстанс P6e. Пример конфигурации:

resource "aws_fsx_lustre_file_system" "llm_fs" {
  storage_capacity            = 2400  # TB
  subnet_ids                  = [aws_subnet.main.id]
  deployment_type             = "PERSISTENT_2"
  per_unit_storage_throughput = 1000  # MB/s
  data_compression_type       = "LZ4"
  # Включаем RDMA для GPUDirect Storage
  drive_cache_type            = "READ"
  # Обязательно!
  storage_type                = "SSD"
}

data "aws_ami" "p6e_optimized" {
  most_recent = true
  owners      = ["amazon"]
  filter {
    name   = "name"
    values = ["*p6e*-2026*"]
  }
}

resource "aws_instance" "llm_server" {
  ami            = data.aws_ami.p6e_optimized.id
  instance_type  = "p6e.48xlarge"
  # ... сеть, security groups
  user_data = file("setup.sh")
}

В setup.sh ставим драйверы NVIDIA, CUDA 12.9, монтируем FSx:

#!/bin/bash
# Монтируем FSx Lustre с опциями RDMA
mount -t lustre -o flock,rdma \
  fs-1234567890abcdef.fsx.us-east-1.amazonaws.com@tcp:/shared /mnt/model

# Устанавливаем gdscheck и проверяем
apt install -y nvidia-gds-tools
gdscheck -p 0  # проверить GPU 0

Шаг 2: Скачиваем и подготавливаем модель

Возьмём Llama 3.1 405B в формате .gguf (квантование Q4_K_M). Размер ~245 GB. Для GDS файлы должны быть выровнены. Используем mmap с --no-mmap? Нет, GDS работает через gds_open. В llama.cpp это уже автоматизировано: если файл на FSx Lustre, движок сам выбирает GDS.

# загружаем модель в файловую систему
aws s3 cp s3://my-models/llama-3.1-405b-q4km.gguf /mnt/model/

Шаг 3: Запускаем llama.cpp с GDS и TurboQuant

Собираем llama.cpp из исходников (ветка master, июнь 2026):

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
mkdir build && cd build
cmake .. -DLLAMA_CUDA=ON -DLLAMA_GDS=ON -DLLAMA_TURBOQUANT=ON
make -j$(nproc)

Запуск с GDS и TurboQuant для контекста 512K:

./llama-cli --model /mnt/model/llama-3.1-405b-q4km.gguf \
  --gds \
  --turbo-quant 3 \           # 3-битное сжатие KV cache
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --ctx-size 524288 \
  --n-gpu-layers 1000 \        # все слои на GPU
  --cont-batching \
  --prompt "Ваш длиннющий промпт..." \
  --temp 0.7 --repeat-penalty 1.1

Результат: TTFT ~4.5 секунды (против 45 без GDS). Контекст 512K влезает в 240 GB HBM3e благодаря TurboQuant (без сжатия только 128K). При желании можно поднять до 1M, используя --turbo-quant 2 (2-bit, но с небольшой потерей точности).

Нюансы и грабли (я наступил, чтобы вы не наступали)

1. Не включайте GDS на неровных файлах

Если файл модели не выровнен по 4K, GDS молча падает на gds_open. Лечится: перед загрузкой проверьте dd if=model.gguf of=/dev/null bs=4096 skip=... или используйте gds_align - опцию утилиты gdsio. llama.cpp при старте выводит предупреждение.

2. TurboQuant и некоторые архитектуры

TurboQuant использует rotation матрицы (как в нашем разоблачении). Для моделей типа Gemma 4 или Qwen 2.5 работает отлично, для старого LLaMA-2 — бывают артефакты на длинных контекстах. Рекомендую тестировать на валидационном датасете.

3. RDMA-радиатор: FSx через VPN не тянет

GDS требует прямой сети между инстансом и FSx. Если вы используете VPC Peering или VPN — RDMA не пройдёт. Только один и тот же placement group или AZ.

4. Цена вопроса

P6e.48xlarge стоит ~$96/час (on-demand). FSx Lustre — ещё ~$0.2/GB. Месяц работы обойдётся в $70k+. Это не для домашних экспериментов, но для production — нормально.

Альтернативы: сколько стоит не заморачиваться?

Если денег на P6e нет, можно попробовать связку 2x RTX 3090 + ik_llama с контекстом 128K — у нас есть сравнение методов. Но TTFT будет ~1 минута, и никакой GDS. Для стартапов — пойдёт. Для сервиса с тысячами запросов — нет.

Другой путь — использовать TurboQuant + MTP на AMD ROCm (подробнее в статье TurboQuant + MTP на AMD ROCm в llama.cpp). Дешевле, но без RDMA.

Неочевидный совет: профилируйте, а не просто накручивайте контекст

Многие гонятся за максимальным контекстом, забывая про latency. Увеличение контекста с 256K до 1M через TurboQuant 2-bit даёт прирост perplexity на 0.3, но время генерации растёт в 2.5 раза. Если ваше приложение — чат, то 256K более чем достаточно. GDS же даёт выигрыш в TTFT, который критичен при холодном старте и подсистемах auto-scaling. Скомбинировав эти две технологии, вы получаете не просто “много и быстро”, а именно “быстро на старте и много во время работы”.

Blackwell с поддержкой FP4 и аппаратным квантованием (NVIDIA Transformer Engine) будет только усиливать эффект TurboQuant — уже в Q3 2026 обещают драйверы с тензорным квантованием KV cache. Следите за обновлениями.

Подписаться на канал