Главные новости ИИ и GPU за день

Ministral 3 14B: поместилась модель, а длинный диалог?

Вы выбираете GPU для Ministral 3 14B Reasoning и видите обещание работы в 32 GB VRAM. Не переносите эту цифру на любой диалог. Модель Mistral AI из семейства, выпущенного 2 декабря 2025 года, принимает текст и изображения; открытые веса доступны под Apache 2.0. Это практический разбор, не новый релиз.

В карточке версии Reasoning-2512 действительно указаны 32 GB для BF16. Но для работы с большим context разработчик рекомендует два H200, а для короткого допускает один GPU. Context — объём информации в запросе и продолжении; его заявленный предел здесь — 256K tokens. «Модель загрузилась» и «весь диалог помещается» — разные проверки.

Если ваши задачи вместе с ответом укладываются в 8192 tokens, начните тест с такого лимита, а не с максимального окна. В vLLM его задаёт параметр --max-model-len. На одинаковых запросах запишите пиковую VRAM и время ответа, затем повторите с нужным числом одновременных пользователей. Это предлагаемый тест, не наш замер модели.

Так вы будете выбирать сервер под свою работу. Два H200 — рекомендация для большого context, а не универсальный минимум для этой модели; меньший лимит не гарантирует, что конкретной карты хватит.

Подбирайте GPU под модель и рабочую длину диалога, а не только под загрузку весов.

ИИ запустил четыре задачи — а сколько выполнено?

Вы попросили ИИ написать скрипт, который обрабатывает несколько файлов одновременно. В конце он сообщил: «Получено четыре результата». Не спешите считать это четырьмя успехами: ошибка тоже может оказаться элементом списка.

В Python у asyncio.gather есть режим return_exceptions=True. По официальной документации, в нём исключения собираются в общий список вместе с успешными результатами. В нашем локальном тесте три задачи вернули значения, четвёртая вызвала ValueError. В списке осталось четыре элемента, но удачных задач было три.

Попросите помощника проверить именно этот случай: Проверь обработку результатов asyncio.gather с return_exceptions=True. Добавь тест: три задачи успешны, одна вызывает ValueError. Отчёт должен показать 3 успеха и 1 ошибку с ID задачи, а не «выполнено 4». Запусти тест и покажи фактический вывод. Если запуск недоступен, скажи об этом.

Такой тест полезно добавить до обработки настоящих файлов. Отсутствие исключения ещё не доказывает правильность данных: содержание успешного ответа проверяйте отдельно.

Считайте подтверждённые успехи, а не длину списка результатов.

PyTorch: у ускорения checkpointing есть цена

Вы экономите VRAM при обучении через activation checkpointing: вместо хранения части промежуточных данных модель вычисляет их повторно. Хочется ускорить этот процесс ещё одной настройкой. Но сначала стоит проверить, не изменится ли сам расчёт.

PyTorch по умолчанию сохраняет и восстанавливает состояние генератора случайных чисел при checkpointing. Это нужно, чтобы случайные операции вроде dropout при повторном вычислении давали результат, согласованный с обычным запуском. Настройка preserve_rng_state=False убирает эту работу, но отказывается и от такой гарантии.

Если вам предложили этот флаг как «бесплатное ускорение», проверьте выбранный блок: есть ли внутри dropout или другие случайные операции? Затем сравните время шага, loss и gradients — ошибку модели и градиенты — с исходным вариантом на одинаковом batch, восстановив начальные веса и состояние генераторов перед каждым тестом. Это предлагаемый контрольный тест, а не наш замер ускорения.

Если случайность участвует в расчёте, не отключайте её сохранение только ради красивой цифры скорости. Под torch.compile этот флаг не действует: по документации состояние генератора всё равно сохраняется.

Ускорение стоит проверять вместе с тем, какой расчёт вы теперь выполняете.