Учет потребления внутреннего ИИ: квоты, приоритеты, отчеты

Почему конфликты из-за GPU случаются чаще, чем кажется

Конфликт вокруг GPU почти всегда начинается тихо: один отдел запускает обучение модели, другой внезапно не может прогнать отчеты или обновить чат-бота, а третий видит, что время ожидания выросло в разы. Недовольны обычно те, у кого задачи привязаны к бизнес-срокам (поддержка, продажи, безопасность), и те, кто все запланировал, но не получил ресурсы в нужный день.

Дефицит GPU отличается от дефицита людей или бюджета тем, что он проявляется мгновенно и локально. Бюджет перераспределяют раз в квартал, людей нанимают месяцами. А GPU заканчиваются сегодня в 10:05, когда кто-то занял все ускорители под один эксперимент. Снаружи это выглядит как «кто-то съел ресурсы», хотя чаще причина проще: не было правил.

Ситуацию обычно ухудшают быстрые, но вредные решения: полный запрет «пока не разберемся», ручное распределение «пишите в чат, кому срочно», принцип «кто успел, того и GPU» и личные договоренности между руководителями. Они либо останавливают работу, либо превращают распределение ресурсов в личный конфликт.

Для бизнеса «справедливо» - это не «поровну», а предсказуемо и прозрачно. Когда есть учет потребления внутреннего ИИ, всем понятны лимиты департамента, приоритеты задач и причины, почему в пике кому-то придется подождать.

Представьте, что одновременно идут пилот по аналитике в финблоке, ночные отчеты для руководства и обновление модели для контакт-центра. Без правил GPU уйдут туда, где запуск длиннее и громче. С правилами команды заранее знают окна, квоты и порядок очереди, и спор превращается в планирование.

Что считать потреблением: договоримся о терминах

Чтобы учет не превратился в спор «кто съел GPU», сначала договоритесь, что именно вы называете потреблением. Иначе один отдел будет считать токены, другой - часы видеокарт, а третий - счета за хранение.

Обычно разумно фиксировать несколько слоев, потому что «дорого» бывает по разным причинам: токены (ввод и вывод), время на GPU, занятая память GPU (VRAM), хранение (датасеты, чекпоинты, логи и результаты) и сеть (трафик между сервисами, особенно в распределенных задачах).

Онлайн-инференс и пакетные задачи лучше разделять сразу.

Онлайн-инференс - чаты, подсказки оператору, поиск по документам. Там критичны задержка и доступность, поэтому лимиты чаще задают «за запрос» и добавляют защиту от всплесков.

Пакетные задачи - обучение, переиндексация, массовая генерация отчетов. Там логичнее лимиты «за минуты GPU» и правила очереди, чтобы долгие задачи не вытесняли короткие.

Отдельно проговорите общие ресурсы: одну и ту же модель, общий кластер, общий бюджет на инфраструктуру и поддержку. Если единый серверный пул обслуживает и ИИ-проекты, и другие сервисы, то «потребление ИИ» должно включать долю общих затрат.

Единицы учета выбирайте так, чтобы ими было легко управлять в правилах: за запрос (для онлайн-сервисов), за 1K или 1M токенов (удобно сравнивать команды), за минуту GPU (для пакетных задач), за гигабайт-месяц хранения (для датасетов и результатов).

Пример: юристы получают лимит по запросам и токенам на поиск по договорам, а аналитики - по минутам GPU на ночные пакетные расчеты. Тогда разговор идет в цифрах, а не в эмоциях.

Как задать квоты: департаменты, проекты и роли

Квоты проще всего вводить там, где вы уже умеете считать ответственность. Если бюджеты и результаты закреплены за департаментами (ИТ, ИБ, аналитика), начните с квоты по департаментам. Если работа идет через конкретные инициативы (например, «чат-бот для поддержки» или «распознавание документов»), удобнее выдавать квоты по проектам, а департаментам оставить роль владельцев и контролеров.

Практичный подход - двухуровневые лимиты: базовый и дополнительный. Базовый нужен, чтобы ежедневные задачи не останавливались. Дополнительный выдается по заявке, когда есть понятная цель и срок.

Обычно достаточно нескольких ролей:

• Обычный пользователь: небольшие лимиты, доступ к типовым моделям.
• Команда продукта: стабильная квота под регулярные релизы и поддержку.
• Исследовательская группа: гибкие лимиты, но с планом экспериментов и кратким отчетом по результатам.
• Администратор платформы: право перераспределять ресурсы в рамках правил.

Подрядчиков и временные команды учитывайте отдельно. Самый спокойный вариант - отдельная проектная квота с датой окончания и внутренним куратором, который отвечает за расход и закрытие доступа.

Чтобы правила работали без конфликтов, зафиксируйте простую управленческую схему: кто владелец квоты, кто утверждает перерасход и что считается обоснованием (цель, ожидаемый эффект, срок, потолок расхода).

Пример: в компании внедряют LLM для поддержки и для аналитиков. Поддержке дают фиксированную базовую квоту, чтобы не было простоев. Аналитикам разрешают запрашивать дополнительные GPU на 3-5 дней под конкретный отчет или исследование. Так заранее отделяется «обязательное» от «по заявке».

Приоритеты задач: кому и когда давать GPU в первую очередь

Если у вас общий пул GPU, спор начинается не из-за «плохих людей», а из-за отсутствия понятных правил. Приоритизация делает систему предсказуемой: всем видно, какие задачи проходят вне очереди, а какие ждут.

Удобно начать с классов обслуживания и привязать к ним очереди и ожидания по времени ответа:

• Критично: простой стоит денег или срывает сервис (например, триаж обращений в колл-центре).
• Важно: поддерживает работу команд, но терпит задержку (например, ежедневные отчеты).
• Эксперимент: исследования, прототипы, разовые тесты, обучение «на попробовать».

Дальше введите лимиты параллельности. Смысл простой: даже если у отдела большой бюджет, он не должен запускать 20 задач одновременно и занимать весь кластер. Например, для «важно» можно разрешить до 2 параллельных запусков на департамент, а для «эксперимент» - 1.

Для тяжелых обучений и пакетной обработки задайте окна (часто ночь и выходные). Так дневные «критично» получают быстрый отклик, а длинные джобы не блокируют всех.

Правила вытеснения важно прописать заранее и закрепить технически: «критично» нельзя останавливать без ручного подтверждения; «важно» можно приостановить и продолжить с чекпоинта; «эксперимент» можно прервать автоматически при перегрузе. Для каждого класса задайте SLA по времени ответа (например, 1-3 минуты для «критично»).

Пример: на серверах уровня S200 один отдел запускает обучение на 48 часов. Появляется критичный запрос - обучение уходит в паузу, а критичная задача получает GPU сразу, без «кто успел, тот и занял».

Метрики, без которых учет не работает

Метрики должны отвечать на три вопроса: что было запущено, сколько ресурсов это заняло и что получилось на выходе.

Минимальный набор метрик

Начните с небольшого набора и снимайте его одинаково для всех моделей и приложений:

• Токены: отдельно входные и выходные, с привязкой к модели и приложению.
• GPU: время использования, средняя и пиковая загрузка, занятая память (VRAM).
• Сопутствующие ресурсы: CPU, RAM, диск (I/O) и сетевой трафик.
• Внутренняя «стоимость»: условные единицы (например, 1 ед. за 1k токенов + 1 ед. за минуту GPU).
• Качество выполнения: ошибки, ретраи, отмены и таймауты.

Как читать эти цифры

Токены показывают нагрузку со стороны текста: длинные промпты и большие ответы быстро съедают лимиты, даже если GPU загружен слабо. GPU-время и VRAM помогают отличить тяжелую задачу от простой. Пики по VRAM часто объясняют, почему соседние задания внезапно падают.

Сопутствующие ресурсы важны, когда кажется, что «GPU не хватает», а на деле упираетесь в диск или сеть: модель простаивает, но сервер занят. Внутренняя «стоимость» упрощает разговор между департаментами: сравнить 200 условных единиц в день легче, чем десяток графиков. Метрики качества быстро подсвечивают сервис, который делает пять ретраев подряд и незаметно тратит половину квоты.

Как организовать сбор данных: теги, логи и уведомления

Учет работает только тогда, когда каждый запрос можно однозначно привязать к тому, кто и зачем его сделал. Самый простой способ - договориться о тегах и сделать их обязательными в точке входа: в прокси к LLM, в оркестраторе задач или в портале доступа.

Теги: что должно быть всегда

Практичный минимум:

• департамент (финансы, ИБ, разработка)
• проект или продукт
• среда (prod или test)
• владелец (человек или команда)
• тип нагрузки (инференс, обучение, пакетная обработка)

Важно, чтобы теги задавались не «вручную в чате», а автоматически: из SSO-группы, из имени ключа доступа, из пространства проекта. Тогда меньше шансов, что кто-то «забудет» поставить метку.

Логи: что хранить, что сворачивать

Храните сырой лог ровно столько, сколько нужно для разборов (например, 7-14 дней), а дальше оставляйте агрегаты. Обычно достаточно: время, пользователь или ключ, теги, модель, число токенов (вход/выход), длительность, статус, оценка GPU-времени (если есть), признак кэша.

Чтобы не получить двойной учет, заранее решите правило: если стоит прокси и включен кэш, списывайте расход один раз - по факту обращения к модели, а кэш-хиты помечайте отдельно.

Уведомления: пороги и адресаты

Пороговые алерты лучше делать простыми: 70/90/100% от квоты за период. Отправляйте их по ролям: владельцу проекта (70%), руководителю департамента и финконтролю (90%), дежурной команде инфраструктуры (100% или резкий всплеск).

Если вы только запускаете внутренний ИИ на своей серверной инфраструктуре, начните хотя бы с учета по пользователям и ключам доступа. Теги можно добавить следующим шагом, но ключи и пороги уже дадут прозрачность и снизят число конфликтов из-за «непонятно куда ушедших» GPU.

Пошаговый план внедрения квот и учета за 2-4 недели

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

Неделя 1: правила и владельцы

За 2-3 встречи зафиксируйте модель квот (по департаментам, проектам или ролям) и владельцев. Достаточно одной страницы RACI: кто утверждает квоты, кто администрирует доступ, кто получает отчеты, кто отвечает за инциденты. Сразу решите, что важнее: гарантированная доля для критичных задач или «кто первый занял GPU».

Неделя 2-3: учет и пилот

Выберите 3-5 метрик и частоту отчетов: дневной короткий статус для админов и недельный отчет для руководителей. Настройте теги и правила выдачи ключей: каждый запрос к LLM или запуск на GPU должен иметь департамент, проект и владельца. Лимиты сначала включайте в тестовой среде и проверьте приоритизацию.

Проведите пилот на 2-3 департамента и правьте правила по фактам, а не по ощущениям:

• День 1-3: RACI и модель квот
• День 4-7: метрики, отчеты, теги и доступы
• Неделя 2: тестовые лимиты и приоритеты
• Неделя 3-4: пилот и корректировки

Сразу закрепите процесс расширения квоты: кто подает запрос, какие данные нужны (цель, срок, ожидаемые токены или GPU-часы) и за сколько дней дается ответ.

Отчетность: как сделать потребление прозрачным для всех

Главный источник конфликтов - ощущение, что «кто-то съел все GPU», но никто не может показать цифры. Учет работает, только если отчеты понятны, регулярны и одинаковы для всех.

Еженедельный отчет лучше делать коротким и повторяемым. Он должен отвечать на три вопроса: кто потреблял больше всего, где есть отклонения от нормы и что будет к концу месяца, если ничего не менять. Полезно показывать не только факт, но и прогноз по тренду последних 7-14 дней.

Руководителям обычно нужен отдельный срез без технических деталей:

• суммарные GPU-часы и изменение к прошлой неделе
• топ-3 потребителя (департамент или проект) по доле ресурса
• доля приоритетных задач (prod, безопасность, критичные сроки)
• перерасход к квоте (в процентах и в часах)
• прогноз до конца месяца (норма или риск перерасхода)

Командам, наоборот, нужен «разбор полетов»: где именно случился перерасход и что можно оптимизировать. Показывайте долю обучения, инференса и экспериментов, плюс токены, время ожидания в очереди и простои GPU.

Инциденты разбирайте по журналу: кто запускал задачу, когда, на каком пуле, с каким приоритетом и зачем. Тогда спор решается таймлайном и причинами, а не эмоциями.

Исключения и аварийные режимы, чтобы бизнес не остановился

Лимиты нужны, но реальная работа всегда подбрасывает ситуации, когда критичная задача упирается в квоту. Если заранее не описать исключения, все снова скатится в ручное тушение пожара.

У исключений должен быть владелец и короткий срок жизни. «Аварийный бюджет» включается не по просьбе в чате, а по понятной процедуре: кто может разрешить, на сколько часов, какой максимум ресурсов и что попадет в отчет. Это особенно важно в период закрытия квартала, аудита, регуляторных дедлайнов и ночных инцидентов.

Хорошо работает разделение лимитов: отдельно для production (поддержка сервисов, отчетность, критичные процессы) и отдельно для экспериментов (PoC, обучение, перебор гипотез). Тогда исследования не вытесняют рабочие задачи.

Набор правил, который обычно снимает большую часть конфликтов:

• Аварийный режим включает только дежурный руководитель платформы или ИТ-ответственный, с лимитом по времени (например, 2-4 часа).
• Любая аварийная выдача фиксируется: задача, владелец, причина, сколько GPU и токенов, итог.
• На период пиков вводятся временные приоритеты (закрытие месяца, отчет для регулятора, запуск сервиса).
• Прерывание задач разрешено, если нет бизнес-ущерба: тестовые прогонки, «черновые» генерации.
• Для задач, которые нельзя прервать, обязательны чекпоинты и оценка максимальной длительности до запуска.

Пример: отдел аналитики запускает тяжелую модель в день закрытия квартала, но упирается в лимит. Вместо спора включают аварийный бюджет на 3 часа, временно повышают приоритет финансовой отчетности, а экспериментальную очередь ставят на паузу с автоматическим возобновлением ночью.

Частые ошибки при лимитах и как их избежать

Первая причина конфликтов - правила, которые никто не может объяснить. Если начать с квот «на глаз», через месяц их сложно защитить: почему одному отделу 40%, а другому 20%? Привязывайте лимиты к понятным вещам: числу активных проектов, плану работ на квартал, обязательствам по SLA, критичности бизнес-процессов.

Вторая ошибка - отсутствие владельца квоты. Когда непонятно, кто отвечает за лимит департамента и кто утверждает изменения, спор быстро становится личным. Назначьте владельца и простой процесс пересмотра: раз в месяц или по запросу с коротким обоснованием.

Отдельно больно бьет смешивание production и экспериментов в одной очереди. Разделите ресурсы хотя бы на два класса: бизнес-критичные задачи и исследования. Даже если физически это те же GPU, логика очередей и приоритетов должна быть разной.

Еще один источник ссор - отсутствие лимитов параллельности. Один активный пользователь или команда может занять все GPU просто количеством одновременных задач. Введите ограничение на параллельные запуски на пользователя и на проект, плюс верхнюю границу по «весу» задач (например, максимум N GPU одновременно).

Наконец, не сводите учет только к токенам или только к GPU-времени. Токены хорошо показывают нагрузку LLM, но не отражают тяжелые инференс-задачи. GPU-часы показывают занятость «железа», но не объясняют эффективность запросов. Нужны оба показателя, плюс время ожидания в очереди, отмены и повторные запуски.

Чеклист: что проверить перед запуском и каждую неделю

Перед запуском уберите двусмысленность. Большинство споров начинается не из-за «жадности», а из-за разных ожиданий.

Перед стартом проверьте:

• У каждого запроса и джоба есть теги: департамент, проект, владелец (конкретный человек), среда (prod или test).
• Заданы лимиты параллельности и классы приоритета, понятно поведение при превышении (очередь, отказ, понижение приоритета).
• Настроены пороги уведомлений (например, 70% и 90% квоты) и назначены ответственные.
• Есть процесс запроса допквоты: куда писать, какие данные приложить, срок ответа.
• Правила разделения prod и теста проверены на практике.

Раз в неделю делайте короткую проверку:

• Есть отчет для руководителей: потребление по департаментам, топ-проекты, отклонения от нормы.
• Сформирован список «дорогих» задач (по токенам или GPU-часам) и принято решение: оптимизировать, перенести во внепик, согласовать бюджет.
• Проверены очереди и отказы: кто и почему не получил ресурс, были ли конфликты по приоритетам.
• Сверены теги: нет ли «безымянных» задач и проектов.
• Подтверждено, что prod не страдает из-за тестов в пиковые часы.

Пример сценария: как поделить GPU между тремя отделами

Представьте один общий GPU-кластер для внутреннего ИИ и три отдела: Поддержка (чат-бот и поиск по базе знаний), Аналитика (выгрузки и отчеты), R&D (эксперименты с LLM и обучение небольших моделей). Все задачи важны, но терпимость к задержкам разная.

Сначала задайте базовые квоты, чтобы у каждого отдела была гарантированная доля, и отдельно отметьте «критичные» задачи:

• Поддержка: 40% GPU, критично - ответы в чате и индексация новых документов
• Аналитика: 30% GPU, критично - ежедневный отчет к 10:00
• R&D: 30% GPU, критично - только задачи по согласованному дедлайну

Дальше включите приоритеты внутри очереди: критичные задачи могут занимать свободные ресурсы сверх квоты, но только если они не вытесняют другие критичные задачи.

Чтобы тяжелые пакетные прогонки не «съедали» день, введите ночные окна: с 22:00 до 08:00 R&D и Аналитика получают повышенный лимит, а Поддержка сохраняет минимум для онлайн-сервиса.

Еженедельный отчет держите коротким и одинаковым для всех: GPU-часы по отделам и проектам, доля «пиков» (когда очередь росла), топ задач по стоимости (GPU-часы, токены, время ожидания), срывы SLA для критичных задач.

Квоты пересматривайте не «по ощущениям», а по данным. Если Поддержка стабильно использует 25% и нет пиков, базовую квоту можно снизить, а высвободившееся отдать Аналитике на утренний слот. Важно заранее договориться о правиле пересмотра (например, раз в месяц) и фиксировать изменения в одном общем документе.

Следующие шаги: от правил к стабильной инфраструктуре

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

Оцените фактическую и целевую нагрузку и разделите ее на два потока: регулярные задачи (чаты, классификация, поиск) и всплески (обучение, массовая обработка, эксперименты). Так проще понять, сколько GPU нужно постоянно, а сколько - как резерв.

Дальше зафиксируйте короткий регламент на 1-2 страницы: кто получает квоту, как запрашивать временный рост, что считается аварийным режимом и как расставляются приоритеты.

Практичный план на ближайшие 1-2 месяца:

• Посчитать пиковые окна и определить целевой запас мощности (например, +20-30% к среднему пику).
• Спланировать масштабирование: добавление узлов, отдельные очереди под prod и под эксперименты, резерв на инциденты.
• Настроить мониторинг и алерты по GPU, памяти, очередям и стоимости запросов в токенах.
• Согласовать обслуживание: окна работ, ответственные, процедуры отката.
• Определить поддержку: кто реагирует ночью и в выходные, и что считается критическим.

Если своих ресурсов на проектирование и внедрение не хватает, имеет смысл подключать интегратора. В Казахстане многие команды опираются на локального производителя и системного интегратора, чтобы упростить поставку и поддержку: например, GSE.kz (gse.kz) поставляет серверы, рабочие станции и делает системную интеграцию для ИИ и дата-центровой инфраструктуры, включая круглосуточную поддержку через сервисную сеть.