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

PCIe «замедлился»? Не бракуйте GPU по снимку в простое

Факт: NVIDIA предупреждает: в nvidia-smi текущие поколение и ширина PCIe link могут снижаться, когда GPU не используется. Низкий Current в простое сам по себе не доказывает проблему со слотом или картой.

Зачем: при приёмке сервера легко принять энергосбережение за неисправность — или пропустить реальное ограничение, посмотрев только паспорт GPU.

Проверка в 3 шага 1. Найдите нужную карту через nvidia-smi -L. Скопируйте её UUID, чтобы не перепутать GPU. 2. Выполните nvidia-smi -q -i GPU_UUID -l 1, заменив GPU_UUID на полученное значение. В разделе PCI → GPU Link Info запишите Current и Max отдельно для поколения и ширины link. Остановить просмотр — Ctrl+C. 3. Повторите наблюдение во время согласованного теста передачи данных CPU↔GPU, а не только вычислений внутри GPU. Если link остаётся ниже ожидаемого, передайте инженеру оба снимка и описание теста для проверки слота, riser и конфигурации платформы.

Ловушка: Max — максимум для связки GPU + текущая конфигурация системы, не только паспорт карты. Он тоже может быть ограничен платформой. Эти поля не измеряют реальную пропускную способность; на системах с основным соединением C2C PCIe вообще может не описывать главный путь данных. N/A означает неподдерживаемые данные, не нулевую скорость.

На https://verum-ai.uz есть раздел GPU; совместимость конкретной конфигурации проверяйте отдельно.

Nemotron Nano 9B v2: не экономьте на точности SSM cache

NVIDIA-Nemotron-Nano-9B-v2 вышла 18.08.2025 — это разбор уже выпущенной модели, не новость о релизе. Открытые weights по NVIDIA Open Model License; текст → текст, context до 128K. Архитектура сочетает Mamba-2, MLP и четыре Attention layers.

Факт: в официальном примере vLLM NVIDIA просит задать --mamba_ssm_cache_dtype float32 и предупреждает: без этой настройки качество может снижаться. Это точность состояния Mamba, а не перевод всех weights в FP32.

Зачем: «модель загрузилась» ещё не означает, что inference настроен правильно. Не спешите менять checkpoint или покупать GPU, если ответы хуже ожидаемых.

Три шага 1. Зафиксируйте точный model ID без суффикса Base и версию vLLM. Сверьте синтаксис флага с vllm serve --help: выше написание из model card. 2. Проверьте float32 для SSM cache в конфигурации запуска. Используйте одинаковые prompts и decoding settings для проверки качества до и после изменения. 3. При CUDA OOM уменьшайте --max-num-seqs: в примере NVIDIA стоит 64, но это не гарантия для вашей GPU. Измеряйте peak VRAM и latency под своей нагрузкой, прежде чем выбирать сервер.

Ограничение: этот совет — для inference данной hybrid-модели, не универсальное правило для LLM и не расчёт памяти fine-tuning. 128K — предел context, а не обещание обслужить столько tokens при любой concurrency. --trust-remote-code из примера разрешает исполнение кода репозитория: проверяйте код и фиксируйте revision.

На https://verum-ai.uz есть раздел GPU; наличие нужной конфигурации уточняйте отдельно.

ИИ посчитал ноль — или данных вообще не было?

Факт: pandas по умолчанию возвращает 0 при суммировании пустой Series или столбца, где все значения пропущены. Поэтому ИИ, который честно запустил Python, всё равно может выдать «расходов нет» вместо «расходы неизвестны».

Три шага 1. До расчёта договоритесь: пустая ячейка — неизвестное значение, а не ноль. Не заменяйте пропуски через fillna(0) без отдельного правила. 2. Для числового столбца используйте s.sum(min_count=1). Без единого известного значения получите пропуск, а не искусственный ноль. 3. Рядом с суммой выводите s.count() — число известных значений — и s.size — всего строк. Неполные данные отмечайте явно.

Готовый prompt: Посчитай итог столбца amount через Python. Пустота означает «неизвестно». Используй sum(min_count=1), покажи число известных значений и всего строк. Если известных значений нет, напиши «нет данных», не 0. При пропусках назови итог частичным.

Ловушка: min_count=1 не проверяет полноту! Для [10, пропуск] получится 10 — это сумма только известных значений. Пример проверен на pandas 3.0.6; исходный файл не изменяйте.

Каталог GPU-конфигураций: https://verum-ai.uz

non_blocking=True: отправлено — ещё не скопировано

Факт: PyTorch предупреждает: если после асинхронной отправки из pinned CPU memory изменить исходный tensor, на GPU могут попасть повреждённые данные. Возврат из .to(..., non_blocking=True) не означает завершение копирования.

Зачем: в собственном pipeline легко начать заполнять тот же CPU buffer следующим batch, пока GPU ещё читает предыдущий. Ошибка в данных может выглядеть как нестабильность модели.

Три шага 1. Найдите повторно используемые pinned buffers: pin_memory=True или .pin_memory(). Проверьте, кто меняет их после отправки. 2. До перезаписи дождитесь окончания transfer. Простой вариант для одного GPU: gpu = cpu.to("cuda:0", non_blocking=True) torch.cuda.synchronize("cuda:0") cpu.zero_() Здесь cpu — заранее созданный pinned tensor, torch импортирован. Очистка разрешена только после ожидания. 3. Сравните содержимое GPU tensor с ожидаемым значением при многократном переиспользовании buffer — не ограничивайтесь замером скорости.

Ловушка: synchronize ждёт всю работу выбранного GPU и может убрать пользу от overlap. Для оптимизации используйте CUDA event после копирования в том же stream и ждите его перед перезаписью. Правильность важнее ускорения.

Каталог GPU-конфигураций: https://verum-ai.uz — наличие уточняйте отдельно.

Granite 4.0 H Tiny: пустой system — не отсутствие инструкции

IBM выпустила Granite-4.0-H-Tiny 02.10.2025: это разбор доступной модели, не новый анонс. Текстовая instruct-модель, 7B параметров, hybrid Mamba-2 + Attention/MoE, context 128K, открытые weights по Apache 2.0. Подходит для извлечения текста, RAG и tool calling — качество проверяйте на своих задачах.

Факт: текущий официальный chat template вставляет default system prompt, если system отсутствует или пуст и не переданы tools/documents. Пустая строка не отключает эту инструкцию. Поэтому тест «без system» может на деле оказаться тестом с незаметно добавленными правилами.

Три шага 1. До inference посмотрите итоговый prompt: tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True) Здесь tokenizer загружен из того же model repository. 2. Нужны свои правила — задайте непустое первое сообщение system. Например: «Извлеки номер договора. Если не найден — верни null». Проверьте результат шаблонизации, а не только исходный список messages. 3. Для сравнения запусков зафиксируйте одну revision для weights и tokenizer, версию Transformers и generation settings. Изменение шаблона не должно маскироваться под изменение качества модели.

Проверка и GPU: локальный тест текущего Jinja-шаблона подтвердил: нет system → default; пустой system → default; непустой system → собственная инструкция. Weights не загружались: для этой проверки GPU не нужен. Это не benchmark модели и не расчёт VRAM для inference/fine-tuning.

Ловушка: с tools/documents шаблон дополнительно формирует специальные инструкции; совет нельзя слепо переносить на другие модели. Удаление system само по себе не гарантирует безопасность или точность.

Раздел GPU на сайте Verum: https://verum-ai.uz

ИИ написал zip(): куда исчезла последняя запись?

Факт: Python по умолчанию завершает zip() по самому короткому входу. Если ИИ написал код, соединяющий три ID с двумя результатами, третья запись молча исчезнет из пар. В Python 3.10+ strict=True превращает такую разницу длин в ValueError при обходе.

Как применить 1. Убедитесь, что списки должны соответствовать друг другу по позиции. Если порядок разный, сопоставляйте по ID, а не через zip. 2. Для небольших списков сформируйте пары полностью до записи в файл или систему: pairs = list(zip(ids, results, strict=True)) Если возникла ошибка — остановитесь, не дополняйте пропуски выдуманными значениями. 3. Попросите ИИ проверить случай с отсутствующим последним результатом. Код должен выдать ошибку, а не сохранить укороченный отчёт.

Готовый prompt Сопоставь эти списки без потери элементов. Для позиционного соответствия используй zip(..., strict=True). Проверь равные длины и случай с одним пропущенным результатом. При несовпадении остановись; не обрезай и не дополняй данные автоматически.

Ловушка: zip — ленивый iterator: ошибка возникает не при создании, а при обходе. В цикле с записью часть действий уже может выполниться. list заранее проверяет конечные небольшие входы, но требует RAM; одинаковая длина ещё не доказывает правильность пар.

Каталог GPU и открытые модели на сайте Verum: https://verum-ai.uz

Не хватает VRAM при обучении? Пересчитайте активации

Факт. Activation checkpointing в PyTorch не хранит часть промежуточных тензоров forward до backward, а вычисляет их заново, когда они нужны для градиентов. Это обмен вычислений на память, а не сжатие весов.

Зачем: если обучение или fine-tuning упирается в память активаций, можно проверить этот приём до перехода на GPU с большей VRAM. Цена — дополнительные вычисления; конкретный выигрыш нужно измерить.

Три шага 1. На фиксированных batch, длине последовательности и dtype измерьте исходные пик VRAM и время полного шага обучения после прогрева. 2. В forward оберните один тяжёлый блок вместо обычного y = block(x): from torch.utils.checkpoint import checkpoint y = checkpoint(block, x, use_reentrant=False) Здесь block — ваш модуль, x — его вход. PyTorch рекомендует явно задавать use_reentrant=False. 3. Повторите тот же замер. На одинаковых весах, данных и seed сравните loss и градиенты с исходным вариантом. Оставляйте изменение только при приемлемых памяти, времени и численных расхождениях.

Ограничение: это приём для backward, не способ уменьшить веса или KV cache при inference. Если блок при повторном вызове ведёт себя иначе из-за изменяемого глобального состояния, градиенты могут стать неверными без явной ошибки.

Каталог GPU Verum: https://verum-ai.uz — наличие нужной конфигурации уточняйте отдельно. Источник: https://docs.pytorch.org/docs/2.14/checkpoint.html

Qwen3-30B: миллион tokens — не просто новый лимит

Qwen/Alibaba выпустила Qwen3-30B-A3B-Instruct-2507 30.07.2025. Это разбор доступной модели, не новость дня: текст → текст, MoE 30.5B/3.3B активных параметров, открытые weights, Apache 2.0. Только non-thinking; Thinking — отдельная версия.

Факт: native context — 262 144 tokens. Официальный путь к 1M использует отдельный config_1m.json, Dual Chunk Attention и специальный attention backend. Одного увеличения --max-model-len недостаточно.

Зачем: длинный архив требует памяти не только под weights. В model card для 1M указано около 240 GB суммарной GPU memory: weights, KV cache и пиковые активации. Это ориентир разработчика для описанного inference-рецепта, не наша оценка и не требование для любого запуска.

Три шага 1. Посчитайте tokens реального запроса вместе с запасом под ответ. Если хватает native context, не включайте 1M «на всякий случай». 2. Если нужен 1M, работайте с отдельной копией модели: сохраните исходный config, примените config_1m и весь рецепт backend из model card. Зафиксируйте версии; старые флаги могут не подходить текущему vLLM. 3. Повторите условия нагрузки: официальный пример vLLM задаёт --max-num-seqs 1. На своих документах измерьте пик VRAM, задержку и правильность поиска фактов в начале, середине и конце.

Ограничение: config_1m задаёт BF16; 240 GB нельзя автоматически переносить на quantization, concurrency или fine-tuning. Поддержка 1M не гарантирует точность: в опубликованном RULER при DCA + sparse attention результат на 1000k — 72.2, не 100. Мы этот benchmark не повторяли.

Каталог GPU: https://verum-ai.uz — наличие уточняйте отдельно.

ИИ запустил команду — это ещё не «готово»

Факт: Python subprocess.run() по умолчанию не поднимает исключение из-за ненулевого exit code. Если ИИ написал обёртку без проверки, упавшая конвертация или тест могут закончиться сообщением «успешно».

Три шага 1. Попросите проверить все вызовы внешних команд. Если ненулевой код означает ошибку, используйте check=True: result = subprocess.run(args, check=True, capture_output=True, text=True) Здесь subprocess импортирован, а args — список программы и аргументов. 2. При CalledProcessError остановите зависимые действия. Покажите exit code и полезный фрагмент stderr, предварительно убрав секреты. Не подавляйте исключение через except: pass. 3. Проверьте обёртку командой, которая намеренно завершается с кодом 7. Она должна сообщить о сбое и не перейти к шагу «готово». Затем проверьте успешный случай и сам выходной файл.

Готовый prompt Проверь запуск команд в этом коде. Там, где ненулевой exit code — ошибка, добавь check=True. Не скрывай сбой и не выполняй зависимые шаги. Проверь сценарии с exit code 7 и 0. Успех подтверждай не только кодом возврата, но и содержимым результата.

Ограничение: некоторые утилиты используют ненулевые коды для нормальных исходов — сначала прочитайте их документацию. Код 0 не доказывает правильность файла и не отменяет уже выполненные изменения. Мини-тест поведения run выполнен на Python 3.11.16: код 7 → CalledProcessError; код 0 → результат доступен.

Раздел GPU на сайте Verum: https://verum-ai.uz

NCCL: свободная VRAM не спасает переполненный /dev/shm

Multi-GPU задача в Docker падает при старте, хотя GPU почти пусты? NVIDIA описывает отдельную причину: NCCL может не инициализироваться из-за нехватки shared memory в /dev/shm. Это память хоста, а не VRAM. Покупка GPU с большей памятью такой лимит не исправит.

Что сделать 1. Запустите задачу с NCCL_DEBUG=WARN. Ищите failed to extend /dev/shm/nccl-.... Внутри того же контейнера проверьте df -h /dev/shm: снимок с хоста показывает не обязательно тот же лимит. 2. Если ошибка указывает на /dev/shm, пересоздайте контейнер с согласованным лимитом. Пример аргументов NVIDIA для docker run, до имени image: --shm-size=1g --ulimit memlock=-1 Первый меняет размер shared memory, второй снимает лимит locked memory. Это разные ограничения; 1g — пример, не расчёт под любую нагрузку. 3. Повторите тот же тест с тем же числом процессов/GPU. Проверьте завершение и NCCL log, а не только исчезновение одной строки ошибки.

Ограничение: NCCL также умеет cuMem host allocations вместо /dev/shm. Увеличение /dev/shm — адресная мера по логу, не универсальное лечение NCCL. Не отключайте другие механизмы наугад; учитывайте RAM и политику хоста.

Источник NVIDIA: https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/troubleshooting/runtime_and_mpi_issues.html Сайт Verum AI: https://verum-ai.uz

LFM2.5: tool call — не готовый Python для запуска

Liquid AI выпустила LFM2.5-1.2B-Instruct 05.01.2026. Это доступная text-only модель: 1,17B параметров, context 32 768 tokens, открытые weights под LFM Open License v1.0 с ограничениями коммерческого использования. Base, Thinking, VL и Audio — отдельные варианты.

Факт: по умолчанию модель выдаёт Pythonic function calls, а не JSON. Например, список с вызовом функции — это предложение действия, не доверенный код. Нельзя передавать его в eval() или exec(): локальная модель не делает такой запуск безопасным.

Три шага 1. Передайте только нужные tools и их JSON schemas в system prompt. Если ваш parser ожидает JSON, добавьте рекомендованную разработчиком инструкцию: Output function calls as JSON 2. Разберите ответ как данные. До выполнения проверьте имя по allowlist, типы и обязательные arguments, права пользователя. Неизвестную функцию или лишние arguments отклоняйте; изменение данных требует отдельного разрешения. 3. Выполните разрешённую функцию своим кодом, верните реальный результат сообщением с ролью tool и снова вызовите модель. Проверьте тесты: корректный вызов, неизвестное имя, неверный тип, отказ в доступе.

GPU-решение: есть GGUF для CPU через llama.cpp и GPU serving через vLLM. Для BF16 только weights — примерно 2,34 GB (редакционная оценка: 1,17B × 2 bytes), без cache и runtime. Это не полный VRAM-бюджет и не требование для fine-tuning. Сначала измерьте latency и память своей нагрузки.

Ограничение: prompt не гарантирует валидный JSON. Liquid сообщает BFCLv3 49,12 с собственным handler — это не гарантия надёжности вашего агента; мы benchmark не повторяли. Русский и узбекский не перечислены среди языков модели: проверяйте отдельно.

Каталог GPU Verum: https://verum-ai.uz — наличие уточняйте отдельно.

AI research: ограничьте поиск настройкой, а не обещанием

Нужна справка по продукту без пересказов блогеров? В OpenAI Responses API инструмент web_search умеет ограничивать результаты через filters.allowed_domains. Просьба «ищи только на официальных сайтах» в prompt не заменяет этот фильтр.

Три шага 1. Выберите официальные домены под вопрос. Например, для документации NVIDIA добавьте в массив tools такой объект: {"type":"web_search","filters":{"allowed_domains":["docs.nvidia.com"]}} Указывайте домен без https:// и пути. Фильтр включает его поддомены; слишком широкий домен расширяет круг источников. 2. Убедитесь, что поиск действительно вызван: в output должен быть web_search_call. При tool_choice="auto" модель может обойтись без поиска. Если единственный tool — web_search и поиск обязателен, задайте tool_choice="required". 3. Откройте ссылки из ответа: совпадают ли продукт, версия и смысл утверждения? Для аудита добавьте в запрос include=["web_search_call.action.sources"]: список просмотренных URL шире, чем citations в тексте.

Готовый prompt Найди в документации NVIDIA ответ на [вопрос]. Для каждого вывода укажи URL и версию продукта, если она обозначена. Раздели подтверждённое и неизвестное. Нет подтверждения — так и напиши.

Ограничение: это настройка Responses API с web_search, не переключатель обычного чата и не функция web_search_preview. Фильтр не гарантирует свежесть, полноту или верный вывод и не ограничивает другие tools. Узкий список может исключить нужный источник. Здесь приведена настройка из документации, не результат нашего API-теста.

Сайт Verum AI: https://verum-ai.uz

NCCL: eth1 — это префикс, а не точное имя

Multi-node GPU-задача выбирает не ту сеть? По документации NVIDIA, NCCL_SOCKET_IFNAME=eth1 выбирает интерфейсы по префиксу: под него могут попасть и eth1, и eth10. Для точного имени нужен знак = внутри значения. Это помогает исключить лишние интерфейсы, а не «ускоряет GPU» само по себе.

Как применить 1. На каждом Linux-узле выполните ip -br addr. Выберите интерфейс с IP, доступным другим узлам. Если задача работает в контейнере, проверяйте имена внутри него. 2. Перед запуском worker-процессов задайте в их окружении: export NCCL_SOCKET_IFNAME='=eth1' Замените eth1 на реальное имя на каждом узле: имена могут различаться. Кавычки сохраняют знак равенства как часть значения. 3. Выполните короткий multi-node тест с временным NCCL_DEBUG=INFO. Проверьте выбранный интерфейс в логах и завершение коллективных операций; затем уберите debug-настройку.

Ограничение: ручной выбор отключает автоматический подбор интерфейсов NCCL. Он не исправит routing/firewall и не заменяет полную настройку distributed job. Не копируйте eth1 вслепую и не оставляйте debug-логи постоянно.

Конфигурации GPU в каталоге Verum: https://verum-ai.uz Источник NVIDIA: https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/env.html#nccl-socket-ifname

GLM-4.7-Flash: не копируйте token budget из benchmark

Z.ai выпустила GLM-4.7-Flash 19.01.2026. Это разбор доступной модели, не сегодняшний релиз: text → text, MoE 30B-A3B, открытые weights с MIT в model card. В API заявлен context 200K; GLM-4.7 и FlashX — другие варианты.

Факт: в model card для большинства тестов указан потолок 131 072 новых tokens, но для SWE-bench Verified — 16 384, temperature 0.7 и top_p 1.0. Это условия оценки, а не обязательный размер каждого ответа. Огромный лимит разрешает долгую генерацию и занятую GPU.

Три шага 1. Для коротких coding-задач начните отдельный тест с max_tokens=4096 в OpenAI-compatible endpoint вашего serving. Это наш пробный бюджет, не рекомендация Z.ai. Зафиксируйте prompt, thinking mode и sampling. 2. На одном наборе задач сравните этот лимит с 16 384. Считайте пройденные тесты, фактические output tokens и время до полного ответа, а не только tokens/s. 3. Проверяйте finish_reason: значение length означает достижение лимита, не успешное завершение. Увеличивайте бюджет там, где обрезание мешает задаче; при том же готовом ответе меньший потолок сам по себе не ускоряет модель.

GPU-решение: 3B active — не объём всех weights. Грубая редакционная оценка для номинальных 30B в BF16: около 60 GB только на веса, без KV cache и runtime. Это не минимальная VRAM и не бюджет fine-tuning. Измеряйте пик памяти с нужными context и concurrency.

Ограничение: reasoning тоже требует бюджета генерации. Слишком жёсткий лимит может оборвать ответ до результата. Z.ai публикует SWE-bench Verified 59.2; мы этот benchmark не повторяли и не обещаем его при 4096 tokens.

Каталог GPU Verum: https://verum-ai.uz — наличие уточняйте отдельно.

Claude читает PDF, но не видит график? Проверьте citations

Факт: для Claude через Amazon Bedrock Converse API документация описывает два режима PDF. Без включённых citations извлекается только текст; для анализа изображений и графиков citations нужно включить. Повторять «посмотри внимательнее» бесполезно, если визуальный вход не передан.

Три шага 1. Проверьте путь запроса: правило относится именно к Converse API. Текущая документация относит этот раздел к Bedrock-интеграции для Opus 4.6 и более ранних моделей; не переносите настройку на любой Claude endpoint. 2. В объекте document добавьте JSON-поле "citations":{"enabled":true}, сохранив format, name и source документа. Это настройка запроса, не фраза в prompt. 3. Сначала отправьте одну страницу с графиком, детали которого не дублируются в тексте. Сверьте ответ с изображением вручную; только затем обрабатывайте весь отчёт. Сравните фактический расход tokens.

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

Ограничение: визуальный режим расходует дополнительные tokens и не гарантирует точность чтения мелких подписей. У InvokeModel API другой механизм — обязательность citations на него не распространяется. Здесь проверена документация, не выполнен Bedrock API-тест.

Сайт Verum AI: https://verum-ai.uz

PyTorch: нулевой gradient и отсутствие gradient — не одно и то же

Факт: optimizer.zero_grad(set_to_none=True) ставит gradients в None, а не заполняет их tensors нулями. По документации PyTorch, это обычно снижает расход памяти и может немного ускорить обучение. Но поведение optimizer тоже меняется: для параметра с grad=None шаг пропускается; с нулевым gradient — выполняется.

Зачем: перед покупкой GPU с большей VRAM проверьте старый training loop. Возможно, он явно использует set_to_none=False. В текущей документации default уже True: добавление того же значения само по себе ничего не ускорит.

Три шага 1. В отдельном тесте замените очистку перед новым циклом накопления gradients на: optimizer.zero_grad(set_to_none=True) При gradient accumulation не очищайте gradients между microbatches одного optimizer step. 2. Проверьте код, который читает p.grad: перед операциями с tensor нужна проверка p.grad is not None. После backward параметр, не получивший gradient, может остаться с None. 3. На одинаковых данных, batch size и precision сравните loss, пиковую память tensors и время training step после warmup. Не считайте снижение показания nvidia-smi обязательным: allocator может сохранить освобождённую память в cache.

Ограничение: None — не просто «более дешёвый ноль». Особенно внимательно проверяйте модели с условными ветвями; одинаковые обновления weights не гарантированы. Этот приём не уменьшает размер самих weights.

Источник: https://docs.pytorch.org/docs/stable/generated/torch.optim.Optimizer.zero_grad.html Каталог GPU: https://verum-ai.uz

Devstral Small 2: проверьте runtime, прежде чем винить quantization

Mistral AI выпустила Devstral Small 2 09.12.2025: 24B, text + images → text, context 256K, открытые weights под Apache 2.0. Это разбор доступной coding-модели, не новый релиз. Не путайте её с Devstral 2 123B.

Факт: для community GGUF model card прямо требует изменений из llama.cpp PR #17945. Он исправляет attention factor для mistral3 и уже merged. Если старый runtime неверно выполняет модель, покупка более мощной GPU не исправит вычисления.

Три шага 1. Выполните llama-server --version для реально используемого бинарника. Сверьте build/commit с исправлением #17945. В GUI проверяйте версию встроенного backend, а не только самого приложения. 2. Если исправления нет, обновите runtime в отдельном окружении. Оставьте тот же GGUF, chat template, prompt, context и sampling: иначе сравнение не покажет эффект обновления. 3. Повторите несколько coding-задач с тестами. Сравните пройденные тесты, время полного ответа и пик VRAM при той же concurrency. Сохраните рабочие версии runtime и weights.

GPU-решение: сначала корректный inference, потом размер сервера. Загрузка weights не доказывает, что полный context 256K поместится вместе с KV cache. Этот fix не уменьшает веса и не задаёт бюджет fine-tuning.

Ограничение: это проверка конкретной совместимости, не обещание починить любой GGUF. Mistral публикует 68.0% SWE-bench Verified; мы benchmark не повторяли, результат на вашем quantized build не гарантирован.

Каталог GPU Verum: https://verum-ai.uz — наличие уточняйте отдельно.

ИИ написал requests.get(): где предел ожидания?

Факт: Python Requests не задаёт timeout по умолчанию. Один молчащий сайт может надолго остановить написанный ИИ сборщик данных — без новых результатов и без явной ошибки.

Как применить 1. Попросите ИИ найти HTTP-вызовы без timeout, включая вызовы через Session. 2. Задайте отдельно ожидание соединения и чтения. Пример, не универсальный норматив: r = requests.get(url, timeout=(3.05, 20)) r.raise_for_status() Первое число — connect timeout; второе — read timeout: допустимое ожидание между поступлениями данных, а не время скачивания целиком. 3. Проверьте на локальном тестовом сервере задержку ответа и HTTP 500. Обрабатывайте Timeout и HTTPError явно: отмечайте источник как недоступный, не превращайте сбой в «данных нет».

Готовый prompt «Проверь HTTP-вызовы в этом Python-коде. Добавь connect/read timeouts и явную обработку ошибок. Покажи тесты медленного ответа и HTTP 500. Не добавляй автоматические повторы и не меняй остальные расчёты».

Ловушка: timeout=20 не означает «завершить всю задачу за 20 секунд». Для общего срока выполнения нужен отдельный deadline; поток с редкими порциями данных может идти дольше read timeout.

На https://verum-ai.uz опубликован каталог GPU; наличие нужной конфигурации уточняйте отдельно. Источник: https://requests.readthedocs.io/en/latest/user/advanced/#timeouts