Как подходить к подбору моделей под 640 ГБ VRAM и 140 ТБ
Сервер с суммарными ~640 ГБ видеопамяти на GPU A100 и 140 ТБ хранилища провоцирует простое решение: залить всё, что помещается. Автор обсуждения на r/LocalLLaMA описывает ровно такую ситуацию: токен Hugging Face уже получен, в приоритете GLM 5.3 Flash (abliterated) и DS4 Flash, место на диске пока остаётся, поэтому хочется сохранить модели на будущее и заодно освоить генерацию изображений и видео (обсуждение на r/LocalLLaMA).
Полезнее другая рамка: какие классы задач закроются в ближайшие месяцы. VRAM и диск - два разных бюджета, и путать их дорого. Видеопамять решает, что запускается одновременно, с какой длиной контекста и на каких параллельных запросах. Диск решает, что просто лежит и ждёт очереди. 140 ТБ не бесконечны: чекпойнты для видео, LoRA, датасеты и результаты генерации съедают терабайты быстрее, чем ожидаешь.
Рабочая схема: держать по 1-2 модели на класс задач и не плодить десять почти одинаковых вариантов. Порядок приоритетов для такого сервера выглядит так: сначала LLM, потому что вокруг них строятся агенты, RAG и автоматизация; затем abliterated-сборки, вынесенные отдельно от рабочих сценариев; потом генерация изображений и видео; в конце вспомогательные модели (embeddings, аудио, vision), без которых LLM-сервер работает вполсилы. Дальше разберём каждый блок и критерии выбора.
Приоритет 1: LLM - GLM 5.3 Flash (abliterated), DS4 Flash и что рядом
LLM идут первыми по практической причине: это основной рабочий инструмент сервера. На нём висят диалоги, генерация кода, вызов инструментов, обработка документов, а уже вокруг подключаются эмбеддинги для поиска и векторная база.
Две модели автор уже выбрал: GLM 5.3 Flash (abliterated) и DS4 Flash. Логично закрепить за ними разные роли, чтобы набор не превратился в дубль. Одна модель становится основной рабочей: та, что чаще отвечает на реальные запросы. Вторая - резервом другого семейства или размера, чтобы сравнивать поведение на своих задачах и не оставаться без инструмента, если одна сборка разочарует. Конкретные параметры, лицензию и формат весов этих сборок проверяйте в карточках на Hugging Face: в разборе таких данных нет, а придумывать их нельзя.
Отдельная строка - abliterated-версия GLM 5.3 Flash. Её стоит держать как экспериментальную, а не как единственную рабочую модель, и не смешивать с продакшн-эндпоинтами. Причина в разделе о рисках ниже.
Третий элемент набора - модель, которая закрывает слабое место двух первых. Если основная сборка сильна в диалоге, добавьте вариант с крепким следованием инструкциям и вызовом инструментов для агентных сценариев. Как выбирать между семействами без перебора всех карточек, разобрано в материале о выборе модели для vLLM: там разобраны тип обучения, форматы safetensors и GGUF, квантование, KV-кэш и совместимость с runtime.
Запуск LLM на нескольких GPU: что это меняет для выбора моделей
Суммарные ~640 ГБ на нескольких A100 означают, что крупную модель можно держать в памяти целиком и без агрессивного сжатия. Современные inference-серверы (vLLM и аналоги) раскладывают слои и внимание по картам через tensor parallelism, а при нехватке быстрых линков между GPU используют конвейерную схему. Практический вывод: запас памяти снимает необходимость гнаться за самыми маленькими квантами, но не отменяет ограничение на одновременный запуск нескольких больших моделей.
Второе следствие касается форматов. Если модель существует в варианте, который рассчитан на запуск по частям или на конкретный сервер, его удобнее качать заранее: потом искать нужную ревизию дольше, чем выделить место сейчас. И третье: держите отдельный каталог под кэш загрузок Hugging Face (переменная HF_HOME), иначе одна и та же модель окажется на диске дважды в разных пайплайнах.
Полные веса или кванты: как выбирать при большом запасе VRAM
Когда модель помещается в память в FP16 или BF16, квантование перестаёт быть необходимостью и становится инструментом. Критерий такой: полные веса берите для моделей, которые работают каждый день и где важно поведение в мелочах, кванты - для сравнений, экспериментов и второй копии той же модели под быстрый запуск на меньшем числе карт.
Что даёт квант: меньше памяти под веса, меньше места на диске, быстрее загрузка. Цена - сдвиги в поведении на длинных цепочках рассуждений, в вызове инструментов и на редких языках. На 4-битных вариантах это заметнее, FP8 обычно ближе к оригиналу. FP8 экономит примерно половину памяти относительно FP16, но прирост скорости появляется на железе с аппаратной поддержкой этого формата; на остальных картах выигрыш ограничен меньшим объёмом файлов, которые всё равно разворачиваются в более широкий формат при загрузке.
Память под контекст считается отдельно от весов. KV-кэш растёт с длиной контекста и числом параллельных запросов, поэтому 640 ГБ не означают, что можно одновременно держать две большие модели, длинный контекст и десяток клиентов. Планируйте бюджет из трёх слагаемых: веса, KV-кэш, запас на фрагментацию памяти.
Как квантование меняет поведение модели и где проходят границы применимости, разобрано в статье о квантованных моделях и sweet spot по VRAM. При 140 ТБ диска можно позволить себе хранить и полные веса, и квант одной модели, но это осмысленно только для тех сборок, которые реально используются.
Стратегия хранения на 140 ТБ: что держать в нескольких вариантах
Большой диск выигрывает не объёмом, а структурой. Рабочая схема каталогов повторяет классы задач: /models/llm, /models/vision, /models/image, /models/video, /models/audio, /models/embeddings, плюс отдельный /models/datasets и /cache/hf под загрузки Hugging Face. Такая раскладка экономит часы, когда нужно понять, что уже скачано, а что нет.
Версионирование проще делать в имени папки: имя модели, ревизия или дата, формат весов. Тогда abliterated-версия не смешается с оригиналом, а квант не перезапишет полные веса при обновлении.
В нескольких вариантах стоит держать 1-2 модели, которые запускаются каждый день: полные веса под качественную работу и квант под быстрые эксперименты. Всё остальное храните в одном варианте. Основное место съедают чекпойнты для видео, наборы LoRA, датасеты для дообучения и результаты генерации - их лучше вынести на отдельный том и чистить по расписанию.
Правило гигиены: если модель не запускалась несколько месяцев, она освобождает место. Перед скачиванием смотрите размер файлов в карточке репозитория, а не после того, как диск заполнился. Проверка занимает минуту и экономит терабайты.
Abliterated-версии: зачем они нужны и какие риски несут
Abliterated-сборки - это модификации готовой модели, у которых ослаблен механизм отказа. В основе обычно работа с внутренним направлением, отвечающим за отказ: его приглушают, и модель реже отклоняет запросы, которые оригинал считал нежелательными. Результат зависит от конкретной сборки, метода и датасета, на котором проводилась модификация.
Что это значит на практике:
- Поведение отличается от оригинала, и не только в «запретных» темах. Модификация может задеть стиль, аккуратность в инструкциях и устойчивость к попыткам увести модель в сторону.
- Фильтры на стороне модели ослаблены, поэтому весь контроль вывода переходит к вам: нужна своя проверка контента и логирование, иначе первый же странный ответ уйдёт пользователю.
- Лицензия оригинала может ограничивать модификации и переиспользование. Условия конкретной сборки проверяйте в карточке модели и в тексте лицензии базовой модели; в разборе таких данных нет, и утверждать что-либо о лицензии GLM 5.3 Flash (abliterated) нельзя.
- Гарантий качества и безопасности нет: никто не подтверждает, что сборка сохранила способности оригинала на ваших задачах.
Практический вывод: держите abliterated-модель на отдельном эндпоинте и отдельном порту, не подключайте к сценариям с клиентскими данными и к агентам, которые вызывают инструменты и пишут код в продакшн. Для рабочих задач нужна предсказуемость, а модифицированная модель её не гарантирует. Ответственность за её вывод лежит на владельце сервера.
Генеративные модели для изображений и видео локально
Генерация изображений и видео - отдельный класс задач со своими требованиями. Диффузионным моделям нужна VRAM под сам процесс генерации, а на диске они занимают место чекпойнтами, VAE, текстовыми энкодерами, LoRA и ControlNet-моделями. На сервере с ~640 ГБ запас есть, но видео всё равно остаётся самым требовательным направлением: память расходуется на кадры и временную согласованность, а не только на один проход.
Критерии выбора для такого сервера:
- Поддержка в вашем стеке. Если планируете работать через ComfyUI или diffusers, проверьте, что формат чекпойнта грузится без конверсий и костылей.
- Лицензия. Для изображений и видео она часто ограничивает коммерческое использование и обучение на своих данных. Читайте её до скачивания, а не после первой удачной картинки.
- Требования к VRAM и разрешению. Модель, которая держит высокое разрешение без апскейлеров и танцев с тайлингом, экономит время сильнее, чем кажется.
- Экосистема. Наличие LoRA, ControlNet и регулярных обновлений важнее, чем один красивый демо-пример.
- Активность разработки. Сборка, которая не обновлялась год, скорее всего не совместима с текущими библиотеками.
Начинайте с одного рабочего пайплайна: одна модель для изображений, один способ апскейла, один формат хранения результата. Десяток чекпойнтов в первый месяц гарантированно превратится в свалку несовместимых файлов.
Аудио, embeddings и vision: что не забыть скачать
Вспомогательные модели компактнее LLM, но именно они превращают сервер в рабочий инструмент.
Embeddings. Без них не собрать RAG и поиск по своим документам. Смотрите на поддержку русского языка, размерность вектора и стоимость индексации: индекс на миллионы чанков занимает место и считается часами. Храните модель эмбеддингов и сам индекс вместе, иначе после смены версии пересчитывать придётся всё.
Аудио. Локальный запуск аудио-моделей закрывает две задачи: распознавание речи (записи встреч, интервью, лекции) и синтез. Для ASR проверяйте язык, работу с шумом и наличие диаризации, для TTS - качество на русском и задержку. Эти модели заметно меньше LLM, но требуют аккуратной работы с аудиоданными на диске.
Vision. Модели для разбора изображений и документов нужны, если планируете сканы, счета, PDF со схемами и OCR. Проверяйте качество на своих документах: общие бенчмарки плохо предсказывают поведение на реальных сканах с плохим освещением.
Принцип один: сначала сценарий (поиск по базе знаний, транскрибация, разбор документов), потом модель под него, а не наоборот.
Чек-лист: какие категории моделей закрыть на сервере
Список ниже помогает не забыть блоки и не покупать лишнее. Для каждой категории указано, что проверить до скачивания.
| Категория | Что закрывает | Что проверить |
|---|---|---|
| LLM | диалоги, код, агенты, генерация в RAG | лицензия, формат весов, поддержка в inference-сервере, длина контекста |
| Vision (VLM) | разбор изображений, сканов и документов | качество на своих файлах, память под визуальные токены |
| Image | генерация и редактирование изображений | лицензия, требования к VRAM, экосистема LoRA и ControlNet |
| Video | генерация и анимация | VRAM и время на клип, размер чекпойнта, место под результаты |
| Embeddings | поиск, RAG, кластеризация | язык, размерность, стоимость индексации |
| Аудио | распознавание и синтез речи | язык, диаризация, задержка, формат вывода |
Критерии приоритизации простые. Первое: модель, которая используется ежедневно, важнее любой самой современной, но редкой. Второе: сначала закрывается то, что нужно в этом месяце, эксперименты идут после. Третье: каждая новая модель должна отвечать на вопрос «какую задачу я сейчас не могу решить». Если ответа нет, скачивание подождёт.
GLM 5.3 Flash (abliterated) и DS4 Flash уже закрывают часть блока LLM. Чек-лист нужен, чтобы не забыть остальное: эмбеддинги для поиска, аудио для встреч, vision для документов и одну модель для изображений.
Что используют другие и как не перекачать лишнего
Вопрос «что используете вы» в сообществе задают постоянно, и ответы быстро устаревают. На r/LocalLLaMA и в карточках Hugging Face видно, как наборы практиков меняются каждые несколько месяцев: то, что было стандартом зимой, к осени часто заменяется более удобным вариантом (исходное обсуждение). Ориентироваться на чужие списки стоит как на подсказку, а не как на готовую конфигурацию: у других другое железо, другие языки и другие задачи.
Защита от перекачивания простая. Скачивайте под задачу, а не под ажиотаж вокруг релиза. Пересматривайте набор раз в квартал: что не запускалось, то удаляется. Храните полные веса только у моделей, которые действительно работают, остальное держите в квантах.
Полезно держать в голове экономику: собственный сервер оправдан не для каждой задачи, и точка перехода между своим железом и подпиской считается по конкретным сценариям. Методика расчёта разобрана в статье о локальном AI против облака.
Практический следующий шаг для такого сервера: скачать две LLM из приоритетного списка, поднять inference-сервер с нормальным KV-кэшем, прогнать свои реальные задачи и зафиксировать, что работает. После этого добавляйте эмбеддинги и RAG, затем одну модель для изображений, и только потом видео и аудио. Диск на 140 ТБ подождёт: он не портится от свободного места, а вот от свалки несовместимых чекпойнтов страдает вся дальнейшая работа.