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

Ватты GPU — ещё не расход всего сервера

Факт: NVIDIA определяет Average/Instantaneous Power Draw в nvidia-smi как мощность всей платы GPU, а не сервера из розетки. Складывать показания GPU и считать их полным энергопотреблением узла — ошибка: за пределами такого измерения остаются CPU, RAM, накопители, вентиляторы и потери блоков питания.

Зачем: сравнение GPU по watts без общей границы измерения может исказить расчёт стоимости inference.

Три шага: 1. На своём узле посмотрите nvidia-smi -q -d POWER -l 1. Запишите название поля и GPU: Average Power Draw — среднее за последнюю секунду, Instantaneous — последнее измерение. Завершить просмотр: Ctrl+C. Недоступное N/A не заменяйте нулём. 2. Для всего сервера снимайте энергию на его входе через подходящий metered PDU или счётчик. Учтите все линии питания этого узла; не включайте соседние серверы. Сохраните начальное и конечное показания kWh и время теста. 3. Выполните одинаковый набор запросов на сравниваемых конфигурациях: те же модель, precision, context, concurrency и критерии качества. Сравните затраченные kWh на успешно выполненный набор и latency, а не только мгновенные watts GPU.

Ловушка: частый опрос среднего значения не превращает его в измерение пиков. Такой тест полезен для стоимости работы, но не заменяет инженерный расчёт питания и охлаждения. Average Power Draw поддерживается на Ampere, кроме GA100, и более новых GPU; доступность полей зависит от устройства.

Сайт проекта: https://verum-ai.uz

Gemma 3n E4B: «4B» — не весь объём модели

Google выпустила полную Gemma 3n 26.06.2025. Это разбор deployment, не новинка дня. E2B/E4B имеют Base и Instruct-варианты; принимают текст, изображения, видео и аудио, отвечают текстом. Context — 32K, открытые веса — по условиям Gemma.

Факт: у google/gemma-3n-E4B-it около 8B параметров, а E означает effective. Память уровня 4B достигается специальным размещением параметров, включая вынос Per-Layer Embeddings (PLE) с ускорителя. Имя E4B само по себе не включает такую оптимизацию в вашем runtime.

Зачем: выбирать GPU по «4B × размер числа» рискованно: можно недооценить загрузку весов, KV cache и мультимодальные компоненты.

Три шага: 1. Зафиксируйте точный checkpoint, версию runtime, dtype/quantization и нужные входы: только текст или также звук/изображения. 2. Проверьте в документации выбранного backend поддержку PLE offload/caching и фактическое размещение модулей. Не считайте обычный device_map="auto" доказательством специализированной PLE-оптимизации. 3. На целевой конфигурации измерьте peak VRAM, host RAM и latency сначала после загрузки, затем на реальном context и concurrency. GPU выбирайте по этому тесту с запасом, а не по названию модели.

Ловушка: offload не удаляет параметры — нагрузка перемещается за пределы VRAM. Эти замеры относятся к inference, не к fine-tuning. Универсального минимума VRAM для любого runtime здесь не обещаем.

Сайт проекта: https://verum-ai.uz

ИИ выгрузил CSV — это ещё не безопасный файл

Факт: CSV не хранит тип «текстовая ячейка». Excel или LibreOffice Calc могут принять значение, начинающееся с =, за формулу. Кавычки CSV сами по себе этого не запрещают. Если ИИ включил в отчёт комментарии клиентов или данные из веба, вместе с ними может попасть и formula injection.

Что сделать: 1. До открытия в spreadsheet попросите ИИ с инструментом чтения разобрать CSV как данные. Укажите encoding и delimiter; оригинал не менять. Нужен отчёт «строка → столбец → подозрительное начало», а не просто «файл безопасен». 2. Проверяйте начало каждой разобранной ячейки: = + - @, tab, CR/LF и полноширинные аналоги знаков. Это сигналы для проверки, не доказательство атаки: отрицательные числа тоже могут попасть в список. 3. Согласуйте способ текстового импорта для нужной программы. Сначала проверьте его на отдельном безобидном примере =1+1: значение должно остаться текстом, а не вычислиться. Повторите проверку после сохранения и повторного открытия; подозрительный оригинал для теста не используйте.

Готовый prompt: Проверь CSV на formula injection без запуска формул и открытия в spreadsheet. Разбери файл CSV-парсером, перечисли координаты подозрительных ячеек и причины. Ничего не исправляй автоматически. Предложи способ текстового импорта под [программа и версия] и отдельный безвредный тест.

Ловушка: универсальной очистки CSV для всех программ нет. По OWASP, Excel при сохранении и повторном открытии может убрать защитные кавычки/escape-символы. «Добавили апостроф» — не гарантия.

Источник: https://community.owasp.org/attacks/CSV_Injection Сайт Verum-AI: https://verum-ai.uz

CUDA OOM: сохраните историю, а не только число GiB

Факт: PyTorch умеет сохранять memory snapshot с историей выделений и stack traces. В visualizer событие OOM можно сопоставить с состоянием allocator в момент ошибки. Это полезнее одного показания «VRAM занята»: видно, откуда появились блоки памяти.

Три шага: 1. Выделите короткий воспроизводимый фрагмент inference или training. Сохраните версии PyTorch/CUDA, batch size и длину входа. Включайте запись до проблемного участка, а не после OOM. 2. Вставьте обёртку ниже в тестовый скрипт. Замените run_your_code() своей функцией. finally пытается сохранить snapshot и при исключении. Если сохранение прошло успешно, исходный OOM продолжит распространяться: import torch m = torch.cuda.memory m._record_memory_history() try: run_your_code() finally: m._dump_snapshot("oom_snapshot.pickle") m._record_memory_history(enabled=None) 3. Откройте https://pytorch.org/memory_viz и перетащите свой snapshot. В Allocator State History выберите OOM, изучите занятые и свободные блоки и stack traces. Исправляйте найденную причину, затем повторите тот же тест. По документации visualizer работает локально в браузере и не загружает snapshot на сервер.

Ограничение: snapshot видит память allocator PyTorch, не всю VRAM: например, часть выделений NCCL остаётся вне него. API с подчёркиванием проверяйте для своей версии; пример основан на документации PyTorch 2.8. При аварийном завершении процесса finally может не выполниться. Snapshot содержит пути и stack traces — не публикуйте его без проверки.

Сайт проекта: https://verum-ai.uz

Qwen3.6-27B: не заставляйте агента рассуждать заново

Qwen/Alibaba выпустила модель 22.04.2026: dense 27B, открытые weights Apache 2.0; текст, изображения и видео → текст. Native context — 262 144 tokens. Это практический разбор, не новинка дня.

Факт: Qwen3.6 обучена использовать reasoning из прошлых сообщений. Параметр preserve_thinking сохраняет эти блоки в chat template; по умолчанию остаётся thinking только для последнего пользовательского запроса. В многошаговом coding это может сократить повторные рассуждения, но не гарантирует ускорение.

Как применить: 1. Для self-hosted API возьмите runtime с поддержкой модели: model card рекомендует vLLM ≥0.19.0 или SGLang ≥0.5.10. 2. Возвращайте в историю assistant messages вместе с reasoning_content, а не только финальный текст. Флаг не восстановит удалённую историю. 3. В OpenAI Python SDK передайте: extra_body={"chat_template_kwargs":{"preserve_thinking":True}} 4. Сравните один coding-сценарий с флагом и без: успешность тестов, общее число tokens, latency и peak VRAM.

GPU: наша оценка только весов языковой части в BF16 без quantization — около 54 GB. Vision, KV cache и runtime требуют памяти сверх этого; это не минимальное требование к GPU. Более длинная история тоже расходует context и память.

Ограничение: настройка относится именно к этой модели и совместимому API. Официальные 77,2 на SWE-bench Verified — оценка разработчика, не обещание результата на вашем репозитории.

На https://verum-ai.uz представлены GPU и открытые модели; наличие именно этого checkpoint уточняйте отдельно. Источники: https://huggingface.co/Qwen/Qwen3.6-27B https://qwen.ai/blog?id=qwen3.6-27b

ИИ нашёл «последние 10 заказов»? LIMIT не сортирует

Факт: в PostgreSQL LIMIT 10 ограничивает число строк, но не выбирает самые свежие. Без ORDER BY порядок не гарантирован. Даже сортировка только по дате оставляет неоднозначность, если даты совпадают. Так правдоподобный ответ ИИ может опираться не на те заказы.

Три шага: 1. Определите, что значит «последние»: время создания или изменения. В примере это created_at; id — уникальный ключ заказа. 2. Попросите ИИ задать полный порядок и обработку пустых дат. Для PostgreSQL: SELECT id, created_at FROM orders ORDER BY created_at DESC NULLS LAST, id DESC LIMIT 10; При одинаковой дате выше будет больший id. Строки без даты идут в конец, а не считаются самыми свежими. 3. До отчёта проверьте запрос на тестовых данных: совпадающие даты, NULL и вставка строк не по времени. Сверьте конкретные ID с заранее заданным ожидаемым списком, а не только число строк.

Готовый prompt: Проверь SQL для «последних 10 заказов» в PostgreSQL. Свежесть — created_at; id уникален. Задай однозначный ORDER BY, NULL в конце. Добавь тесты с одинаковыми датами, NULL и перемешанной вставкой. Выполни их и покажи ожидаемые и фактические ID; если запуска нет, скажи прямо. Production не меняй.

Ограничение: это порядок для текущего набора данных, а не замороженный снимок. Новые записи могут сдвинуть страницы с OFFSET. После JOIN проверьте, остаётся ли id уникальным в результате.

Verum AI: https://verum-ai.uz

torch.compile: первый запрос — не скорость всей работы

Факт: torch.compile тратит время на компиляцию при первых выполнениях модели, затем по возможности использует готовый код. Поэтому один медленный первый запрос не доказывает, что GPU или compiled-модель медленнее eager. Но исключать старт из стоимости короткой задачи тоже нельзя.

Три шага: 1. Зафиксируйте модель и weights, GPU, версии PyTorch/CUDA, dtype, batch и размеры входа. Сравнивайте eager и compiled на одинаковых данных; проверьте совпадение результатов с подходящим численным допуском. 2. Отдельно запишите время первого выполнения и серию после прогрева до стабильных задержек. Для wall-clock замера CUDA-вызова выполните torch.cuda.synchronize() до запуска таймера и после вычисления, перед его остановкой. Отмечайте, был ли compile cache уже заполнен: новый процесс не обязательно означает холодный cache. 3. Сравните медиану прогретых вызовов и полное время вашей реальной серии, включая старт. Для постоянно работающего сервера важен steady state; для разового задания — окупилась ли компиляция до его завершения.

Ловушка: новые размеры входа могут вызвать recompilation. Прогрев на одном shape не гарантирует ту же задержку на другом. Ускорение из tutorial — не обещание для вашей модели; не покупайте GPU по одному замеру.

Сайт проекта: https://verum-ai.uz

Voxtral Realtime: меньше задержка — не всегда лучше текст

Mistral AI выпустила Voxtral Mini 4B Realtime 2602 04.02.2026: потоковая речь → текст, открытые BF16 weights, Apache 2.0; API имеет статус GA. Это не batch-модель Mini Transcribe V2 и не обычный чат-бот.

Факт: transcription delay даёт модели время услышать продолжение речи. В тестах разработчика на FLEURS средний WER при 480 ms — 8,72%, при 960 ms — 7,70%: ниже лучше. Не спешите покупать GPU, если ошибки вызваны слишком коротким ожиданием.

Как применить: 1. Для локального vLLM начните с рекомендованных 480 ms и temperature=0.0. Model card указывает одну GPU с ≥16 GB памяти для BF16; это не гарантия вместимости нескольких одновременных потоков. 2. На копии конфигурации модели измените в tekken.json "transcription_delay_ms": 480 на 960 и перезапустите service. Проверьте оба режима на одних обезличенных записях с ручной расшифровкой. Сравните WER, имена и числа. 3. Замерьте задержку от речи до текста и peak VRAM при нужном числе потоков. Для коротких сессий отдельно проверьте уменьшение --max-model-len: default 131072 рассчитан примерно на 3 часа, а меньший лимит сокращает память под заранее рассчитанные RoPE frequencies.

Ловушка: 480 ms — не обещание полной задержки приложения: есть сеть, очередь и вычисления. Среди 13 заявленных языков есть русский, но нет узбекского; качество на нём требует отдельного теста. Сайт проекта: https://verum-ai.uz

PDF для ИИ: чёрный прямоугольник — ещё не удаление

Факт: Adobe разделяет redaction — удаление выбранного текста и изображений — и sanitization: очистку скрытых данных, включая metadata и встроенное содержимое. Просто закрыть реквизиты фигурой недостаточно: исходное содержимое может остаться в PDF и попасть в обработку ИИ.

Перед загрузкой — три шага: 1. Сделайте локальную копию. В Acrobat Pro откройте All tools → Redact a PDF → Redact text and images. Отметьте ненужные для задачи ФИО, счета, подписи и другие секреты во всех местах, не только на первой странице. 2. Нажмите Apply, включите удаление скрытой информации (sanitize) и сохраните под новым именем. Одной разметки областей мало: изменения нужно применить и сохранить. Оригинал оставьте в защищённом хранилище. 3. Заново откройте именно итоговый файл. Визуально проверьте страницы; локально попробуйте поиск и копирование удалённых фрагментов. Проверьте metadata и вложения. Внешнему ИИ передавайте только проверенную копию и только если это разрешено правилами вашей организации.

Ловушка: нулевой результат поиска не доказывает безопасность: в скане может не быть текстового слоя, а человека иногда можно узнать по оставшемуся контексту. Просьба «не учитывай личные данные» не отменяет их передачу. Применённое и сохранённое redaction необратимо; инструмент в этом примере — Acrobat Pro.

Сайт проекта: https://verum-ai.uz

T.Limit падает — GPU не обязательно остывает

Факт: в nvidia-smi показатель T.Limit — запас в градусах до максимальной рабочей температуры, а не температура самого GPU. Чем меньше запас, тем ближе тепловой предел. По NVIDIA, при 0 °C или ниже GPU может корректировать частоты из-за нагрева.

Почему важно: правило «меньше градусов — лучше» здесь перевёрнуто. Перепутав T.Limit с GPU Current Temp, можно пропустить тепловое ограничение во время inference.

Три шага: 1. Посмотрите доступные датчики: nvidia-smi -q -d TEMPERATURE Разделяйте абсолютную температуру GPU Current Temp и относительный запас GPU T.Limit Temp. Если T.Limit поддерживается, некоторые температурные пороги тоже показаны относительно него. 2. Во время обычной нагрузки следите за температурой и причинами ограничения частот: nvidia-smi -q -d TEMPERATURE,PERFORMANCE -l 2 Это опрос каждые две секунды; остановка — Ctrl+C. Сопоставляйте падение запаса с SW Thermal Slowdown / HW Thermal Slowdown и задержкой запросов. 3. Если запас приближается к нулю и thermal slowdown активен, проверьте охлаждение по инструкции сервера: температуру входящего воздуха, airflow и состояние вентиляторов. После исправления повторите тот же workload, не меняя batch и power limit.

Ловушка: T.Limit есть не у всех GPU. N/A — отсутствие поддерживаемого показания, не нулевая температура. Один снимок не доказывает причину торможения; ноль здесь не означает немедленное отключение.

Сайт проекта: https://verum-ai.uz

Qwen3-TTS: один голос — не обрабатывайте образец заново

Qwen (Alibaba Cloud) выпустила семейство 22.01.2026. Здесь — Qwen3-TTS-12Hz-0.6B-Base: открытые weights, Apache 2.0, текст + образец голоса → речь. Это существующая speech LM, не новость дня и не обычный чат-бот; у семейства есть и 1.7B-версии.

Факт: SDK позволяет один раз извлечь признаки эталонного голоса через create_voice_clone_prompt и использовать их для следующих реплик. Так не приходится повторять подготовку одного образца при каждом запросе; генерация самой речи всё равно выполняется.

Три шага: 1. Возьмите запись своего голоса или голоса с явным разрешением владельца и её точную расшифровку. Загрузите именно Base через qwen-tts; в официальном примере — CUDA и BF16. 2. На загруженной модели создайте prompt один раз: p = model.create_voice_clone_prompt(ref_audio="ref.wav", ref_text=transcript, x_vector_only_mode=False) Для каждой новой реплики передавайте его: wavs, sr = model.generate_voice_clone(text=line, language="Russian", voice_clone_prompt=p) 3. На одинаковых репликах сравните время после прогрева и peak VRAM с повторной обработкой ref_audio. Подбирайте GPU по реальным длинам и concurrency, не только по «0.6B». Это inference, не fine-tuning.

Ограничения: x_vector_only_mode=True убирает требование расшифровки, но может ухудшить сходство голоса. Русский входит в 10 заявленных языков, узбекский — нет. Минимальная VRAM и единый лимит text context в model card не указаны. WER 1.32 на Seed-TTS test-en — результат разработчика, не гарантия для ваших записей. Храните voice prompt как чувствительные данные.

Сайт проекта: https://verum-ai.uz

ИИ считает GitHub issues — не прибавил ли он PR?

Факт: GitHub REST endpoint GET /repos/{owner}/{repo}/issues возвращает и issues, и pull requests. PR распознаётся по наличию ключа pull_request. Если ИИ просто посчитал элементы ответа, отчёт об открытых задачах может оказаться завышенным.

Три шага 1. Зафиксируйте охват: конкретный repository и state=open для открытых задач. Не подменяйте этот показатель числом задач, созданных за неделю. 2. Заберите все страницы по Link: rel="next". Затем оставьте записи, у которых нет ключа pull_request. Наличие ключа важнее слов «PR» или «bug» в заголовке. 3. Уберите повторения по id, посчитайте результат кодом и сохраните ссылки на включённые issues. Отдельно покажите, сколько PR исключено, и время проверки. При недоступной странице отметьте неполноту, а не выдавайте итог за полный.

Готовый prompt Посчитай открытые issues без PR в OWNER/REPO через GitHub REST API. Пройди все страницы, исключи записи с ключом pull_request, дедуплицируй по id. Верни число, ссылки на issues, число исключённых PR и время проверки. Не изменяй repository. Если данные неполные или API недоступен — сообщи, итог не придумывай.

Ограничение: issue — не обязательно ошибка: это может быть идея или вопрос. Для отчёта о bugs задайте отдельное правило, например конкретный label; его отсутствие не доказывает отсутствие дефектов.

Сайт проекта: https://verum-ai.uz

Checkpointing: проверка прошла — gradients верны?

Факт: в PyTorch activation checkpointing с use_reentrant=False параметр determinism_check="default" сравнивает shape, dtype и device пересчитанных tensors с сохранёнными. Он не сравнивает их численные значения.

Зачем: экономия VRAM при fine-tuning не должна незаметно менять обучение. Если пересчёт блока зависит от изменившейся глобальной переменной, одинаковые размеры tensors ещё не означают одинаковые gradients.

Три шага 1. Сделайте короткий эталонный forward + backward без checkpointing. Сохраните loss и gradients; optimizer step пока не выполняйте. 2. Повторите с checkpointing на тех же weights и batch, при одинаковых dtype и режиме модели. Перед каждым прогоном восстановите одинаковое RNG state и очистите gradients. 3. Сравните loss и gradients каждого обучаемого параметра через torch.testing.assert_close. Отдельно проверьте совпадение случаев grad is None; допуски задайте под свою precision. Лишь затем сравнивайте peak VRAM и время шага.

Ловушка: debug=True добавляет трассы операций в сообщения об ошибках, а не проверку чисел. Один удачный batch — не гарантия для всех входов. Это проверка корректности training, не способ уменьшить веса модели.

Сайт проекта: https://verum-ai.uz

ИИ перевёл время — или только сменил подпись?

Факт: в Python dt.astimezone(tz) переводит время в другой timezone, сохраняя тот же момент. dt.replace(tzinfo=tz) лишь меняет сведения о timezone, не пересчитывая часы. Подмена одного другим может отнести событие к неверному дню отчёта.

Три шага 1. До обработки файла задайте timezone источника и отчёта. Если у исходного времени нет offset и его пояс неизвестен, не позволяйте ИИ угадывать его по настройкам сервера. 2. Для уже определённого момента используйте local = dt.astimezone(target_tz). Учебный пример: 2026-10-03T00:30:00+00:00 → 2026-10-03T05:30:00+05:00. Через replace получилось бы 00:30:00+05:00 — это другой момент. 3. Проверьте, что dt.timestamp() == local.timestamp(). Добавьте тест около полуночи, где меняется дата; группируйте по дню уже после перевода в timezone отчёта.

Готовый prompt Проверь перевод времени в Python-отчёте. Сохраняй момент через astimezone, не подменяй его replace(tzinfo=...). Неизвестный timezone пометь как проблему. Покажи тест равенства timestamp и тест перехода даты. Исходный файл не меняй.

Ловушка: для naive datetime astimezone предполагает timezone системы. replace допустим, чтобы назначить заведомо известный пояс локальным часам, но не для перевода между поясами. Фиксированный offset в примере не заменяет правила регионов с DST.

Сайт проекта: https://verum-ai.uz

DDP: копите gradients, а не лишние обмены

Факт: в PyTorch ddp.no_sync() временно отключает синхронизацию gradients между DDP-процессами. Они накапливаются локально и синхронизируются при первом forward + backward вне этого context. Внутрь нужно поместить и forward, и backward: обернуть только backward недостаточно.

Зачем: при gradient accumulation не обязательно обмениваться gradients после каждого microbatch. Это может сократить коммуникационные затраты multi-GPU training, если именно обмен ограничивает скорость.

Применение — 3 шага: 1. Для одного optimizer step подготовьте K одинаковых по размеру microbatches на каждом rank. В начале окна вызовите optimizer.zero_grad(). Если loss — среднее по одинаковому числу элементов, делите каждый loss на K. 2. Для первых K−1 microbatches выполняйте forward и backward внутри with ddp.no_sync():. Последний forward + backward — вне блока, затем один optimizer.step(). Не обнуляйте gradients между microbatches; границы окна должны совпадать на всех ranks. 3. Сравните с накоплением без no_sync: одинаковые данные, effective batch и optimizer. Проверьте близость gradients и время полного optimizer step после прогрева — не только одного microbatch.

Ловушка: при разном числе valid tokens простое деление на K может неверно взвесить loss. no_sync не делит веса модели между GPU и не гарантирует ускорения. Это приём для DDP training, не inference. Сайт проекта: https://verum-ai.uz

Ссылка на ChatGPT не находится в поиске — значит, приватная?

Факт: OpenAI пишет: страницы shared links не предназначены для индексации поисковиками, но это не делает ссылку приватной. Получатель с доступом может переслать её дальше. Отсутствие в поиске — не проверка прав доступа.

Три шага перед отправкой клиенту:

1. Подготовьте отдельную версию результата для передачи, без внутренней переписки. Удалите секреты и ненужные персональные данные до загрузки в ИИ; замените имена и реквизиты условными обозначениями.

2. В окне Share проверьте фактически включённое содержимое: не только последний ответ, но и историю, изображения, файлы, если они доступны в вашем варианте sharing. Откройте готовую ссылку в отдельной сессии с правами предполагаемого получателя.

3. Если нужен доступ строго по списку людей, передайте проверенный результат через разрешённое хранилище с такими правами. Не считайте «ссылку знают только свои» ограничением доступа.

Готовый prompt для уже очищенного текста: Подготовь версию для внешнего получателя. Не добавляй сведения из других сообщений. Отметь фрагменты, по которым можно узнать людей или организацию, и предложи обезличенные замены. Не называй результат гарантированно анонимным. Ничего не отправляй.

Ловушка: состав shared content и доступ зависят от account/workspace и типа ссылки. Не переносите правила личного ChatGPT на Enterprise. Проверка ИИ не заменяет ручную проверку конфиденциальности.

Сайт проекта: https://verum-ai.uz

DDP: shuffle=True, а порядок данных повторяется?

Факт: PyTorch DistributedSampler без вызова set_epoch(epoch) использует один и тот же порядок в каждой эпохе, даже при shuffle=True. Несколько GPU не исправляют логику подачи данных: обучение идёт, но ожидаемого нового перемешивания нет.

Три шага 1. В каждом процессе DDP используйте DistributedSampler с shuffle=True. Значение seed должно быть одинаковым для всех ranks. Передайте sampler в DataLoader; у самого DataLoader задайте shuffle=False.

2. В начале каждой эпохи, до создания iterator и до цикла по batches, вызовите: for epoch in range(start_epoch, n_epochs): sampler.set_epoch(epoch) for batch in loader: train_step(batch) Это фрагмент уже настроенного DDP training loop, не полный запуск.

3. На небольшом тестовом dataset запишите последовательности sample IDs по каждому rank для двух эпох. Проверьте, что номер epoch передан всем процессам; при возобновлении обучения продолжайте сохранённую нумерацию эпох.

Ограничение: при shuffle=False этот вызов не включает перемешивание. Sampler предполагает dataset постоянного размера и стабильное соответствие индексов данным. Это исправление порядка, не обещание ускорения GPU или роста качества.

Сайт проекта: https://verum-ai.uz

DeepSeek-OCR 2: слова распознаны, а таблица исчезла?

Это открытая vision-language модель DeepSeek для «изображение + prompt → текст», Apache 2.0. Работа опубликована 28.01.2026: не релиз сегодняшнего дня.

Факт: официальный пример разделяет два режима: Free OCR. — без layout, а <|grounding|>Convert the document to markdown. — для документа с разметкой. Если дальше нужны строки и столбцы таблицы, сначала проверьте prompt, а не меняйте GPU.

Три шага: 1. Возьмите одну страницу с таблицей и двумя колонками. Для структурированного извлечения используйте точную строку Python: prompt = "<image>\n<|grounding|>Convert the document to markdown. " Для сравнения: prompt = "<image>\nFree OCR. ". Здесь \n — перевод строки. 2. Не меняйте изображение и настройки между прогонами. В примере разработчика: base_size=1024, image_size=768, crop_mode=True. Сверьте порядок колонок и принадлежность каждой суммы своей строке, а не только наличие слов. 3. До пакетной обработки замерьте время и peak VRAM на целевых страницах при batch=1. Пример использует NVIDIA GPU и BF16; README не задаёт универсальный минимум VRAM. Не выдавайте размер weights за требования всего inference.

Ограничение: правильный prompt не гарантирует правильные ячейки. Суммы и объединённые ячейки проверяйте по оригиналу. Это инструкция по применению, не наш benchmark.

Verum AI: https://verum-ai.uz

ИИ написал LEFT JOIN — куда исчезли клиенты?

Факт: в SQL условие WHERE o.status = 'paid' после LEFT JOIN убирает строки без подходящего заказа. Если нужны все клиенты, а рядом только оплаченные заказы, фильтр статуса должен участвовать в ON. Иначе отчёт незаметно теряет клиентов.

Три шага 1. Зафиксируйте смысл: «все клиенты, включая тех, у кого нет оплаченных заказов». Это не то же самое, что «только клиенты с оплатами». 2. Попросите ИИ построить запрос так: SELECT c.id, o.id AS order_id FROM customers c LEFT JOIN orders o ON o.customer_id = c.id AND o.status = 'paid'; 3. Проверьте три случая: клиент без заказов, только с неоплаченным заказом и с оплаченным. Все должны остаться; у первых двух order_id будет NULL. Затем добавьте клиенту второй оплаченный заказ: две строки для него здесь нормальны.

Готовый prompt Проверь SQL: нужны все customers и только orders со status='paid'. Не теряй клиентов без подходящего заказа. Проверь фильтры ON/WHERE и четыре теста: нет заказов, только unpaid, один paid, два paid. Покажи ожидаемые строки; базу не меняй.

Ловушка: добавление OR o.id IS NULL в WHERE не спасает клиента, у которого есть только неоплаченные заказы. И не переносите все фильтры в ON механически: сначала определите нужный результат. Один клиент — не обязательно одна строка.

Сайт проекта: https://verum-ai.uz

MIG: соседняя память свободна, а у вас CUDA OOM?

Факт: NVIDIA MIG выделяет каждому GPU Instance (GI) собственные ресурсы памяти с ограниченной ёмкостью и bandwidth. Свободная VRAM другого GI не становится автоматически доступной вашей задаче. Поэтому при выборе GPU важен выделенный профиль, а не только объём всей карты.

Три шага 1. В среде запуска выполните nvidia-smi -L. Запишите MIG UUID и имя профиля; сопоставьте их с выделенным устройством. Если контейнер скрывает эти сведения, запросите их у администратора. 2. Проверьте доступную память именно своего устройства и запустите типичный inference с нужными context и batch size. Учтите не только веса, но и KV cache и временные buffers. Успешная загрузка модели ещё не гарантирует, что запрос поместится. 3. Если памяти не хватает, сначала уменьшите context или batch size. Если это нарушает требования задачи, запросите больший GI либо целую GPU. Не ждите, что простой соседней секции увеличит ваш лимит.

Важно: GI и Compute Instance (CI) — не одно и то же. Несколько CI внутри одного GI делят его память; считать каждый CI отдельным запасом VRAM нельзя. Изменение MIG-разбиения согласуйте с администратором, не выполняйте его на работающем сервере вслепую.

Сайт проекта: https://verum-ai.uz