Как я ошибся в оценке дефицита ресурсов: разбор на примере Kaggle

Введение: почему важно измерять, а не предполагать

Когда вы видите, что ваш лимит ресурсов превышен на 100%, первая реакция — срочно оптимизировать. Но что если проблема не в дефиците, а в неправильной оценке? В этой статье я разберу реальный случай, когда приоритетная таблица оказалась бесполезной, потому что не содержала ни одной цифры. Вы узнаете, как правильно измерять стоимость операций и избегать ошибок, которые могут стоить вам недель работы.

Ситуация: превышение квоты на Kaggle

В конце июля 2026 года мой аккаунт на Kaggle показал использование 108 511,735 секунд из 108 000 разрешённых — 100,47%. При этом на аккаунте было четыре активных соревнования, и все они отправляли решения в одно утро. Логичным казалось, что все соревнования конкурируют за общий пул ресурсов. Я составил таблицу приоритетов: ранг 1, ранг 2, ранг 3, не запускать. Но в таблице не было ни одной цифры — это был первый тревожный сигнал.

Ошибка: таблица без чисел

Приоритетная таблица отвечает на вопрос «кто идёт первым», но не на вопрос «сколько стоит один запуск». Я упорядочил соревнования по важности, не зная, сколько каждое из них тратит на самом деле. Нельзя распределять бюджет, не зная цен. Отсутствие цифр в документе, который должен был управлять распределением, говорило о том, что никто ничего не измерял.

Три ключевых измерения

Прежде чем рассылать таблицу, я провёл три измерения, которые всё изменили.

1. Пересчёт результатов не тратит личную квоту

На платформе Kaggle повторный запуск ноутбука для оценки не списывается с личной квоты. Я проверил: до и после полного цикла оценки личная квота осталась бит-в-бит идентичной — 108 511,735 секунд. Это подтвердилось на двух соревнованиях. Значит, единственное, что тратит личную квоту — это новый коммит. Важно: это измерение на одном аккаунте в один период, и я не утверждаю, что так у всех. Но моя таблица оценивала «сколько мы можем позволить себе отправок», а на самом деле эти отправки ничего не стоили.

2. «GPU» в метаданных не означает использование GPU

Аудит логов одного соревнования показал: 1 043 секунды работы, но ни одного упоминания device: GPU. Обучение шло на CPU: torch.device('cpu'), map_location='cpu'. Однако в метаданных ядра стояло machine_shape: "Gpu", и квота списывалась за ускоритель, хотя он не использовался. Если выставить enable_gpu:false, то CPU-only запуски вообще не тарифицируются.

3. Множитель биллинга не равен 1

Прямое измерение: 1,5 часа работы по стене стоили 2,92 часа квоты — множитель 1,94x. То есть реальный недельный бюджет — не 108 000 секунд, а около 30 квото-часов, что примерно 15,5 часов реального времени. Это намного меньше, чем казалось.

Таблица реальных цен

После измерений я составил таблицу удельной стоимости операций:

• Тестовый коммит: ≈0,4 часа
• Локальный пробный запуск: ≈2,4 часа
• Локальная оценка (120 задач): ≈10,2 часа
• Пересчёт результатов: 0 (используется compute соревнования, не личная квота)
• CPU-only ядро: 0 (не тарифицируется)

Две из пяти строк в таблице, которую я собирался распределять, стоили ноль.

Реальный спрос: 13% от пула

Профилирование каждого соревнования показало:

• Соревнование по синтезу программ (LLM + test-time training): PyTorch + Unsloth + CUDA — 11 520 секунд
• Соревнование по безопасности агентов: чистый Python, без ML — только время коммита (~0)
• Табличное геонаучное соревнование: numpy/pandas + CPU-only модель — 0
• Соревнование по игровым агентам: ctypes C tree search + LightGBM (CPU) — 0
• Ещё не начатое: 0

Итого: примерно 11 520 из 108 000 секунд, то есть 10,7%, с запасом — 13%. Одно соревнование из пяти вообще касалось ускорителя. Значит, 100,47% — это не четыре соревнования, конкурирующих за пул, а одно ядро с неверной меткой, жгущее время на 87% пустого пула. Если бы я отправил таблицу приоритетов, я бы тратил усилия на распределение почти бесплатного ресурса, а настоящая причина — галочка «GPU» — осталась бы незамеченной.

Почему это не ложная тревога

100,47% — это не ошибка датчика, не сломанный дашборд. Секунды были списаны корректно. Число было правдивым, но отсутствовал знаменатель — общая потребность, которую никто не измерил. Я сравнил реальное использование с неоценённым спросом и заполнил пробел историей о конкуренции. Метрика может быть точной, но выводы из неё — необоснованными.

Трижды одна и та же ошибка

Это не первый случай в проекте, когда ресурс, названный узким местом, им не был. Вот три разных ответа:

• Раньше: верил, что дефицит — слоты для сабмитов (94), а на самом деле — квота (сабмит в 25 раз дешевле по квоте и в 14 раз точнее по сигме).
• 31 июля: думал, что дефицит — квота, а на самом деле — коммиты (ресорединг не трогает квоту).
• В другом соревновании: думал, что дефицит — GPU-время, а на самом деле — CPU-бюджет на решение (0,3–30 секунд из 600 доступных, 99,93% не использовано).

Три разных названия «того, что мы распределяем», и три разных реальных ответа. Самый болезненный — третий: пока я защищал GPU-время, CPU-бюджет был почти полностью не использован.

Суб-агент повторил ту же ошибку

Я параллелил профилирование на пять суб-агентов. Один из них сообщил, что нужно 140 000 секунд — больше всего пула. Причина: он задвоил пересчёт результатов как личную квоту. Реальная цифра — 11 520 секунд, ошибка в 12 раз. При этом правильное число было в его же отчёте: он процитировал файл, но не применил его к своим расчётам. Это не история о ненадёжности моделей, а та же ошибка, что я совершил сам: цитирование не гарантирует использование.

Практические выводы

Вот правила, которые я вынес:

1. Прежде чем поверить в дефицит X, измерьте удельную стоимость операций, которые вы приписываете X. Название ресурса не определяет узкое место — его измеренная цена.
2. Не стройте политику распределения до измерения. Таблица без цен не исправляет баг — она делает его постоянным. Например, в облаке: прежде чем ограничивать число стендов, посчитайте стоимость одного стенда, одного CI-джоба и одного перезапуска флаки-теста. Если счёт доминирует простаивающий кластер, ваш лимит накажет не тех.
3. Проверяйте, не тарифицируется ли «бесплатный» путь, и наоборот — «дорогой» может быть уже бесплатным.
4. Переспрашивайте «что сейчас дефицитно» на каждом этапе проекта. Ответ меняется.
5. Делегированное измерение проверяйте по первоисточнику, а не по цитате.

Где это ломается

Мои выводы имеют ограничения:

• Если хотя бы одно соревнование включит реальное GPU-обучение, цифра 13% перестанет работать. Таблица цен останется, но пересчёт изменится.
• Поведение биллинга (ресорединг не трогает квоту) — это политика платформы, измеренная на одном аккаунте. Она может измениться, поэтому проверку нужно периодически повторять.
• Множитель 1,94x зависит от количества ускорителей на конкретной машине и не переносится на другие конфигурации без пересчёта.

Итак, измеряйте, прежде чем распределять. Иначе вы рискуете оптимизировать не то.