Как выбрать LLM под 128 ГБ VRAM: сравнение моделей для обработки длинных техдокументов

Проблема: когда 50 страниц документа — это не проблема, а катастрофа

У вас есть 128 ГБ VRAM. Восемь RTX 5070 Ti. Вы победили в железной лотерее — или потратили на это бюджет небольшого отдела. Теперь нужно загрузить эту память чем-то полезным.

Задача: обработка технической документации по 50+ страниц. Не просто "прочитать и сделать summary", а полноценная работа — поиск противоречий между разделами, извлечение спецификаций, сравнение версий, ответы на вопросы по конкретным параметрам из середины документа.

Контекст в 64k токенов — это примерно 40-50 страниц текста. 128k — уже 80-100. Звучит здорово, пока не попробуешь запустить это на реальной модели.

Почему 128 ГБ VRAM — это не роскошь, а необходимость

Возьмем Qwen2.5-32B-Instruct в формате FP16. Вес модели: примерно 64 ГБ. Плюс overhead на KV-кэш для длинного контекста. Плюс буферы для vLLM. Плюс место под входные данные.

Для контекста в 128k токенов KV-кэш съедает дополнительные 10-15 ГБ. Теперь вы понимаете, почему ваши 128 ГБ VRAM — это не излишество, а рабочая необходимость.

Но самая большая ловушка ждет дальше. Вы загрузили модель. Она работает. Вы подаете на вход 50-страничный PDF. И тут начинается самое интересное.

Qwen3-32B vs GPT-OSS:120B — битва титанов, которая всех разочарует

Давайте сразу расставим точки над i. GPT-OSS:120B — это монстр. Не модель, а архитектурный комплекс. Она требует минимум 240 ГБ VRAM в FP16. На ваших 128 ГБ она просто не влезет.

Qwen3-32B — другая история. Она влезает в 64 ГБ в FP16. На 128 ГБ VRAM можно запустить две копии параллельно. Или одну с огромным контекстом.

Но вот что бесит: Qwen3-32B официально поддерживает контекст в 128k токенов. На практике после 64k она начинает забывать, о чем говорилось в начале документа. Проверено на технических спецификациях — модель путает параметры из разных разделов.

Сюрприз: Llama 3.1 70B в 4-битном формате работает лучше гигантов

Вот где начинается интересное. Llama 3.1 70B в формате AWQ или GPTQ занимает около 35 ГБ VRAM. На ваших 128 ГБ можно запустить три таких модели параллельно.

Но главное не это. В тестах на технической документации (я брал спецификации Kubernetes, документацию AWS и мануалы по оборудованию Cisco) Llama 3.1 70B показала лучшую "долгую память". После 80k токенов она все еще помнила параметры из первых разделов.

Почему? Архитектура. Llama 3.1 использует улучшенные механизмы внимания для длинного контекста. Qwen3-32B теоретически мощнее, но ее реализация длинного контекста сыровата.

1Шаг первый: определяем реальные требования

Прежде чем выбирать модель, ответьте на три вопроса:

• Насколько критична точность чисел? Если вы работаете с финансовыми отчетами или инженерными расчетами — FP16 или минимум 8-бит.
• Нужен ли параллельный инференс? Если у вас несколько пользователей, лучше запустить две Llama 3.1 70B (4-бит), чем одну Qwen3-32B (FP16).
• Что важнее: скорость или качество? GPT-OSS:120B даже в 4-битном формате будет генерировать 2-3 токена в секунду. Это мучительно медленно для диалога.

2Шаг второй: тестируем на реальных документах

Не верьте бенчмаркам. Возьмите свой самый сложный 50-страничный техдокумент и сделайте тест:

# Пример теста для проверки "длинной памяти"
document = load_pdf("specification.pdf")  # 50 страниц
questions = [
    "Какое значение параметра X указано в разделе 3.2?",
    "Как формула из раздела 2.1 соотносится с таблицей в приложении C?",
    "Есть ли противоречие между требованиями в разделах 4.5 и 5.2?"
]

for question in questions:
    prompt = f"""Документ:
{document}

Вопрос: {question}

Ответ должен быть точным и ссылаться на конкретные места в документе."""
    
    response = query_llm(prompt, model="llama-3.1-70b")
    print(f"Вопрос: {question}")
    print(f"Ответ: {response[:200]}...")
    print("---")

Если модель путает разделы или придумывает несуществующие параметры — она не подходит для вашей задачи.

3Шаг третий: настройка vLLM для максимальной эффективности

vLLM — это must-have для работы с большими моделями. Но его настройка требует понимания, как он использует память.

# Запуск Llama 3.1 70B в 4-битном формате на нескольких GPU
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3.1-70B-Instruct \
  --quantization awq \
  --tensor-parallel-size 4 \
  --gpu-memory-utilization 0.95 \
  --max-model-len 131072 \
  --enforce-eager  # Важно для стабильности с длинным контекстом

Ключевые параметры:

• --tensor-parallel-size 4 — распределяем модель на 4 GPU из 8. Остальные 4 GPU можно использовать для других моделей.
• --gpu-memory-utilization 0.95 — используем почти всю память, но оставляем 5% на системные нужды.
• --max-model-len 131072 — включаем поддержку 128k контекста.
• --enforce-eager — отключаем некоторые оптимизации для стабильности с очень длинным контекстом.

Распределение моделей по 8 GPU: схема для максимальной утилизации

У вас 8×RTX 5070 Ti по 16 ГБ каждая. 128 ГБ суммарно. Самый эффективный способ использования:

Третий вариант выглядит безумием, но представьте: у вас веб-сервис, который обрабатывает запросы от 8 пользователей одновременно. Каждый получает свою модель. Задержки минимальны.

Ошибки, которые сломают вашу систему

1. Забыть про системную память. vLLM при длинном контексте использует RAM для swap. Если у вас 128 ГБ VRAM, но только 64 ГБ RAM — система начнет свопиться на диск после 64k контекста.

2. Игнорировать температурный режим. 8 GPU в одной системе — это 1500+ ватт тепловыделения. Без proper cooling ваши карты будут троттлить уже через 10 минут работы под нагрузкой.

3. Использовать неправильную версию CUDA. Для RTX 5070 Ti нужна CUDA 12.4+. vLLM может требовать конкретные версии torch. Если собрать несовместимый стек — получите ошибки памяти или падения.

Что делать, если нужна точность FP16, но модель не влезает?

Есть dirty hack, который работает. Используйте комбинацию tensor parallelism и pipeline parallelism.

# Пример конфигурации для Qwen3-32B на 4 GPU с FP16
# Мы разбиваем модель на 4 части (tensor parallel)
# Но также используем pipeline parallel для распределения слоев

# В vLLM это делается через:
# --tensor-parallel-size 2  # 2 GPU для tensor parallel
# --pipeline-parallel-size 2  # Еще 2 GPU для pipeline parallel
# Итого: 4 GPU

# На оставшихся 4 GPU можно запустить вторую такую же конфигурацию
# Или одну большую модель с другим распределением

Это сложнее в настройке, но позволяет загружать модели, которые формально не влезают в память.

Практический выбор: что я поставил бы на свою ферму

Если бы сегодня собирал систему под задачу "обработка технической документации 50+ страниц" на 8×RTX 5070 Ti:

1. Основная рабочая лошадь: Llama 3.1 70B Instruct (AWQ 4-бит). Занимает 35 ГБ, запускается на 4 GPU, оставляет место для других задач.
2. Для сверхточных вычислений: Qwen3-32B-Instruct (FP16) на оставшихся 4 GPU. Когда нужна максимальная точность чисел.
3. Резерв: DeepSeek-V2.5 16B (FP16) на 2 GPU для быстрых операций. Иногда не нужна вся мощь 70B модели.

И самое главное — я бы настроил автоматическое переключение между моделями в зависимости от типа документа. PDF с таблицами чисел → Qwen3-32B. Текстовый мануал → Llama 3.1 70B. Быстрый поиск по оглавлению → DeepSeek-V2.5.

Финальный совет: не гонитесь за максимальным контекстом

128k токенов — это круто звучит в маркетинге. На практике даже 64k достаточно для 98% технических документов. Вместо того чтобы пытаться запихнуть весь документ в контекст, лучше:

• Разбивать документ на логические разделы
• Использовать RAG для поиска релевантных частей
• Работать с документом по частям

Ваши 128 ГБ VRAM — это огромная мощь. Но используйте ее с умом. Запустить одну гигантскую модель на весь контекст — это как использовать грузовик для поездки в магазин за хлебом. Иногда лучше несколько маленьких машин, каждая для своей задачи.

И помните: через год появятся модели, которые сделают сегодняшние 70B-гиганты выглядеть игрушками. Ваша ферма должна быть готова к апгрейду. Не закупайте железо "впритык" под текущие модели. Всегда оставляйте запас.