GPU для дообучения модели или управляемая конечная точка

Выбор между выделенными GPU и управляемой конечной точкой нельзя свести к цене часа ускорителя. Команда покупает не только вычисления. Она выбирает, кто будет владеть очередью, средой обучения, контрольными точками, ключами шифрования, журналами и процедурой вывоза весов.

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

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

Частота запусков определяет, чем вы владеете

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

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

Выделенные GPU начинают выигрывать, когда эксперименты образуют непрерывный конвейер. Исследователь меняет набор данных, запускает короткую проверку, исправляет параметры, продолжает с контрольной точки и сразу ставит следующий прогон. Здесь постоянный пул сокращает задержку между идеей и результатом. Он также позволяет заранее установить библиотеки, прогреть кэши наборов данных и хранить промежуточное состояние рядом с вычислением.

Не считайте только успешные полные запуски. В журнале за последние восемь недель отметьте подготовительные прогоны, аварийные перезапуски, оценку качества, слияние адаптеров, квантование и экспорт. Эти операции занимают GPU или блокируют тот же рабочий контур. Если команда насчитала три обучения, но выполнила сорок семь связанных заданий, решение по частоте должно опираться на сорок семь.

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

Считайте занятое время, а не цену запуска

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

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

месячная_стоимость = вычисления + хранение + передача_данных + операции_платформы + труд_инженеров + стоимость_ожидания
полезная_загрузка = полезные_GPU_часы / доступные_GPU_часы
стоимость_полезного_GPU_часа = месячная_стоимость / полезные_GPU_часы

Труд инженеров нельзя ставить в ноль. В выделенном контуре кто-то обновляет драйверы, проверяет совместимость CUDA, восстанавливает узлы, настраивает планировщик, следит за заполнением дисков и расследует сбои. В управляемом варианте этот труд не исчезает: команда готовит образ, права доступа, набор данных, параметры задания и правила очистки. Однако объем и характер работы меняются.

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

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

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

Срок хранения весов задает архитектуру

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

PyTorch в руководстве по сохранению моделей различает веса модели и общую контрольную точку для продолжения обучения. Для возобновления нужны как минимум состояния модели и оптимизатора, номер эпохи и связанные параметры. Такой файл может быть заметно больше одних весов. Это не мелочь формата: если сервис сохраняет только итоговый state_dict, вы сможете запустить инференс, но не обязательно продолжите прерванное обучение с тем же состоянием оптимизатора.

Срок хранения влияет на место, шифрование, резервные копии и проверку восстановления. Артефакт нельзя считать сохраненным, пока команда не загрузила его в чистой среде и не получила ожидаемый результат. Хэш подтверждает целостность файла, но не совместимость кода, токенизатора и версии библиотек.

Для каждого запуска полезно создавать небольшой манифест рядом с весами:

run_id: ft-2026-07-014
base_model: internal-registry/model-a@sha256:...
dataset_snapshot: s3://restricted/train/v17/
code_commit: 3f92c1a
container_digest: sha256:...
precision: bf16
method: lora
checkpoint_format: safetensors
optimizer_state_exported: true
created_at_utc: 2026-07-27T14:10:00Z
retention_class: regulated-3y

Здесь важны неизменяемые идентификаторы, а не красивые имена. Ссылка latest не доказывает, на чем обучили модель. Путь к набору данных без версии не позволяет воспроизвести запуск. Образ с тегом вместо digest может незаметно измениться.

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

В управляемом сервисе проверьте, что случается после удаления задания или конечной точки. Сохраняются ли контрольные точки отдельно, кто назначает срок хранения, можно ли поставить legal hold, как удаляются копии и кто видит ключи. В выделенном контуре те же вопросы остаются у вашей команды. Собственный диск не создает политику хранения автоматически.

Экспорт артефактов нужно доказать до контракта

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

Проверяйте экспорт по четырем слоям. На уровне данных нужны итоговые веса и промежуточные контрольные точки. На уровне обучения нужны состояние оптимизатора, scheduler, случайные seed и точная конфигурация. На уровне исполнения нужны digest контейнера, версии драйвера и библиотек. На уровне происхождения нужны идентификатор базовой модели, снимок набора данных, commit кода и метрики оценки.

Сам тест можно оформить как приемочный сценарий:

1. Запустите короткое обучение на синтетическом наборе без закрытых данных и сохраните контрольную точку в середине.
2. Экспортируйте все заявленные артефакты и вычислите SHA-256 для каждого файла.
3. Удалите задание и его рабочий том, затем запросите подтверждение состояния по API или журналу.
4. В другом проекте или локальном контуре загрузите артефакты, продолжите обучение и сравните структуру метрик.
5. Зафиксируйте ручные действия, закрытые форматы и поля, которые пришлось восстанавливать по памяти.

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

Опасный вариант привязки редко выглядит как запрет на скачивание. Чаще сервис экспортирует адаптер, но не раскрывает точную ревизию базовой модели; сохраняет веса, но не состояние оптимизатора; выдает собственный пакет, который загружается только его SDK; или ограничивает скорость вывоза так, что окно миграции растягивается. Закройте каждый из этих случаев отдельным пунктом приемки.

Для закрытой модели также выясните права на производные веса. Техническая возможность экспортировать файл не заменяет договорное право использовать его в другом контуре. Лицензия базовой модели, условия поставщика и права на набор данных должны разрешать предполагаемый путь. Это юридический вопрос с техническим последствием: запрещенный или неясный экспорт уничтожает ценность переносимого формата.

Очередь входит в срок выпуска модели

Управляемая конечная точка не гарантирует мгновенный GPU. Между отправкой задания и первым шагом обучения могут стоять проверка квоты, поиск подходящего типа ускорителя, загрузка образа, монтирование данных и ожидание общей емкости. Выделенный пул тоже имеет очередь, если несколько команд делят ограниченные узлы. Разница в том, кто управляет приоритетами и кто может объяснить задержку.

Запрашивайте не абстрактную «доступность», а измеримые состояния задания. Вам нужны время приема, время постановки в очередь, причина ожидания, время назначения узла, начало подготовки, первый шаг обучения, последняя контрольная точка и завершение. Без этих отметок десятиминутный сбой обучения и шестичасовое ожидание выглядят одинаково как «job pending».

Kubernetes scheduler назначает Pod на подходящий узел с учетом ограничений и доступных ресурсов. ResourceQuota ограничивает совокупное потребление пространства имен. Эти механизмы полезны в собственном кластере, но квота не резервирует физический GPU. Команда может иметь право запросить четыре ускорителя и все равно ждать, если подходящие узлы заняты или требования по памяти, топологии и типу устройства не совпадают.

Определите два SLO. Первый ограничивает время от отправки до старта для обычного задания. Второй описывает срочный запуск, например исправление модели после проваленной проверки безопасности. Для каждого задайте размер задания, класс GPU, время суток, регион или площадку и допустимую долю нарушений. Обещание «приоритетная очередь» без этих параметров нельзя проверить.

Проверьте политику вытеснения. Может ли более приоритетное задание остановить ваше? Сохраняет ли платформа контрольную точку перед остановкой? Кто оплачивает потерянные минуты? В собственном пуле задайте те же правила между командами. Если все задания имеют высший приоритет, планировщик не получает полезного сигнала.

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

Управление сервисом не управляет экспериментом

Управляемый сервис снимает часть работы с инфраструктурой, но не отвечает за качество эксперимента. Он может поднимать узлы, перезапускать контейнер и собирать системные журналы. Команда все равно отвечает за утечки между train и validation, качество разметки, лицензию данных, гиперпараметры, критерии остановки и проверку итоговой модели.

Это различие важно при расчете штата. Платформенный инженер и ML-инженер закрывают разные риски. Покупка управляемой конечной точки может уменьшить дежурство по GPU-узлам, но не уменьшает число решений по данным и оценке. Покупка выделенных GPU не делает исследователей администраторами кластера без потери скорости работы.

Зафиксируйте границу ответственности в виде таблицы RACI или простого списка владельцев. Кто обновляет базовый образ? Кто одобряет новую библиотеку? Кто расследует зависший NCCL? Кто восстанавливает контрольную точку? Кто удаляет временную копию набора данных? Кто доказывает аудитору, какой пользователь запустил обучение? Если в строке два поставщика и ни одного ответственного человека со стороны команды, инцидент будет ходить между очередями поддержки.

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

Не покупайте выделенные GPU только ради привычного SSH. Интерактивный доступ удобен, поэтому его часто принимают за контроль. Настоящий контроль проявляется в воспроизводимом образе, политике доступа, наблюдаемой очереди, резервном восстановлении и автоматическом удалении временных данных. Терминал без этих свойств лишь ускоряет ручные ошибки.

Изоляция начинается с модели угроз

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

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

После этого проверьте конкретные границы:

• физический узел и режим разделения GPU;
• проект, пространство имен, сервисные учетные записи и права поддержки;
• входящий и исходящий сетевой трафик, DNS и доступ к реестрам;
• рабочие тома, объектное хранилище, резервные копии и ключи;
• журналы команд, параметров, путей и ошибок, где могут оказаться секреты.

Изоляция также имеет временное измерение. Что происходит с видеопамятью, локальным NVMe и кэшем образов после завершения? Когда удаляется рабочий том? Остается ли диагностический bundle? Может ли поддержка сделать снимок памяти? Ответ «данные шифруются» не закрывает эти вопросы, потому что во время обучения система должна расшифровать данные.

NIST SP 800-53 рассматривает управление доступом, защиту систем и журналирование как разные семейства контролей. Это полезная поправка к закупочному чек-листу: один механизм не заменяет остальные. Отдельный узел снижает часть риска совместного использования, но без ограниченных ролей и аудита он не объясняет, кто прочитал артефакт.

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

Сбой выявляет скрытую стоимость выбора

Представьте команду, которая запускает дообучение раз в две недели через управляемый сервис. В пятницу вечером обучение доходит до 82 процентов, узел теряется, а последняя контрольная точка сделана шесть часов назад. Сервис автоматически повторяет задание с начала, потому что пользовательский контейнер писал состояние на локальный диск. Счет вырос, выпуск сдвинулся, а формально платформа выполнила обещанный перезапуск.

Причина не в том, что управляемые сервисы ненадежны. Команда не согласовала семантику восстановления. Она проверила запуск, но не проверила потерю узла. Правильная приемка должна была принудительно остановить короткое тестовое задание, убедиться, что контрольная точка лежит во внешнем хранилище, и измерить шаг, с которого возобновилась работа.

Теперь обратный случай. Банк арендует выделенный пул ради изоляции. Один GPU начинает выдавать исправимые ошибки памяти. Планировщик продолжает назначать на узел задания, потому что метрика не связана с автоматическим cordon. Три эксперимента дают нестабильный результат, прежде чем инженер вручную исключает узел. У поставщика управляемого сервиса такая автоматика могла бы быть стандартной, а собственный контур потребовал ее спроектировать.

Оба сбоя показывают одну границу: ответственность без наблюдаемости бесполезна. Если команда владеет пулом, ей нужны телеметрия оборудования, проверка узлов, правила вывода из эксплуатации и запас емкости. Если поставщик владеет узлами, клиенту нужны события жизненного цикла задания, политика повторов, внешний checkpoint и понятная эскалация.

Проведите игровые испытания до закрытого запуска. Остановите узел, заполните диск, отзовите доступ к хранилищу, задержите назначение GPU и повредите копию контрольной точки. Цель не в том, чтобы сломать платформу всеми способами. Вы проверяете, замечает ли команда сбой, сохраняет ли данные и может ли объяснить итоговый статус без догадок.

Решение помещается в одну матрицу

Выбирайте выделенные GPU, если постоянная очередь работ держит их занятыми, задержка запуска влияет на выпуск, среда требует низкоуровневой настройки, артефакты должны годами оставаться под вашим управлением или модель угроз требует контролировать узел и управляющий контур. Это решение имеет смысл только вместе с владельцами эксплуатации и бюджетом на резервирование.

Выбирайте управляемую конечную точку, если запуски редкие или всплесковые, стандартный контейнер покрывает задачу, команда принимает проверенный механизм экспорта, а поставщик дает измеримый срок старта и нужную границу изоляции. Не называйте такой выбор компромиссом. Для небольшой ML-команды отказ от обслуживания кластера часто дает больше времени на данные и оценку.

Оцените варианты по матрице с весами от вашей системы, а не из шаблона консультанта:

• По частоте проверьте, сколько связанных GPU-заданий приходит в неделю. Выделенные GPU выгодны при устойчивом потоке, управляемая точка при паузах и всплесках.
• По артефактам проверьте экспорт полного checkpoint и манифеста. В своем пуле вы задаете формат и хранилище, в сервисе ответ зависит от API и договора.
• По очереди измерьте срок до первого шага. В своем пуле вы управляете приоритетами, в сервисе поставщик управляет емкостью.
• По изоляции выясните, кто делит узел, сеть и управление. Выделенный контур дает больше контроля при правильной архитектуре, а сильные границы сервиса требуют доказательств.
• По эксплуатации назначьте того, кто чинит драйверы и узлы. Это ваша команда или подрядчик в своем пуле и поставщик в пределах SLA в управляемом сервисе.
• По масштабу оцените, как быстро нужен редкий большой запуск. Своему пулу нужен запас или расширение, а эластичность сервиса зависит от доступной квоты.

Поставьте каждому критерию вес от 1 до 5, затем оценку варианта от 1 до 5. Рядом с каждой оценкой приложите доказательство: выдержку из договора, результат теста, метрику очереди или расчет загрузки. Число без доказательства лишь маскирует предположение.

Не позволяйте общей сумме скрыть стоп-фактор. Если закрытые веса нельзя экспортировать в требуемом формате, высокая оценка удобства не спасает сервис. Если организация не может обеспечить дежурство и замену узлов, экономия выделенного пула на бумаге не делает его рабочим вариантом.

Гибридная схема часто честнее бинарного выбора

Команде не обязательно обучать все модели в одном контуре. Короткие исследования на обезличенных или синтетических данных можно отправлять в управляемую среду, а финальное обучение с закрытым набором проводить на выделенном пуле. Можно держать небольшой постоянный пул для обычной работы и брать управляемую емкость для редких пиков. Такая схема работает, только если контейнер, формат контрольной точки и манифест одинаковы по обе стороны.

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

Для двух контуров нужен единый контракт оценки. Один набор тестов, версии промптов, пороги качества и правила публикации должны применяться независимо от места обучения. Иначе различие процедур исказит сравнение, а команда ошибочно спишет расхождение качества на GPU или сервис.

AI Router размещает open-weight модели на собственной GPU-инфраструктуре для команд, которым нужны хранение данных внутри Казахстана, низкая задержка или дообученные варианты. Это может быть одним из проверяемых контуров в матрице, но требования к экспорту, сроку хранения и изоляции все равно надо зафиксировать для конкретного проекта.

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