Что на самом деле нужно моделям в изолированном контуре?

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

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

Воздушный зазор требует управляемой границы потоков данных

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

Начните с четырёх потоков: входные данные, выходные данные, поставка программного обеспечения и администрирование. Нарисуйте каждый источник и получателя. Укажите протокол, используемую учётную запись, ответственного за разрешение и сохраняемые доказательства. Схема с надписью «офлайн-кластер» почти ничего не говорит аудитору. Запись «подписанный пакет релиза поступает через станцию T1 после согласования двумя сотрудниками» описывает контроль, который инженеры могут реализовать и испытать.

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

NIST SP 800-53 рассматривает защиту носителей, их транспортировку, защиту границ, управление конфигурацией и аудит как отдельные группы мер. Такое разделение полезно. Удаление маршрута не отвечает на вопросы о том, кто переносит обновление, как сканируют носитель, проверяет ли его принимающая сторона и чем администраторы подтверждают изменение. Для воздушного зазора все эти меры должны работать вместе.

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

Модель угроз определяет, что должно остаться внутри

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

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

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

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

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

Оборудование рассчитывают по нагрузке, а не по карточке модели

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

Первая оценка размера весов проста:

weight_bytes ~= parameter_count * bits_per_weight / 8
required_vram = weights + kv_cache + activations + runtime_workspace + safety_margin

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

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

Оперативная память CPU и хранилище тоже важны. Может понадобиться место для текущих и предыдущих весов, распакованной промежуточной копии, слоёв контейнеров, кешей движков, наборов оценки и журналов аудита. Если для отката приходится удалять единственную заведомо исправную модель, хранилище рассчитали неверно. Быстрое локальное хранилище сокращает перезапуск, а медленное общее хранилище может одновременно вернуть все узлы и заставить их ждать на одном узком месте.

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

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

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

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

Не рассчитывайте, что инференс на CPU станет полезным аварийным режимом. Маленькая модель может продолжить работу, но задержка и пропускная способность памяти способны сорвать все цели основной нагрузки. Измерьте и назовите режим честно: ограниченная работа, только пакетное восстановление или полное отсутствие резерва. Так же оценивайте смешанный парк ускорителей. Разным устройствам могут понадобиться разные движки, что усложнит планирование и резерв сильнее, чем обещает скидка при покупке.

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

Весам нужны контроль хранения, лицензия и воспроизводимая идентичность

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

Используйте неизменяемые дайджесты, а не переменные имена вроде latest или простую метку модели. Open Container Initiative Image Specification требует указывать в дескрипторе дайджест содержимого и размер и советует проверять полученные байты до использования. Принцип действует и при передаче весов обычными файлами. Подписанный манифест должен перечислять каждый артефакт с SHA-256, числом байтов, источником, проверенной лицензией и заявкой на согласование.

Минимальный пакет можно проверить инструментами, которые есть почти в любой контролируемой среде сборки:

$ sha256sum -c SHA256SUMS
weights/model-00001-of-00004.safetensors: OK
weights/model-00002-of-00004.safetensors: OK
weights/model-00003-of-00004.safetensors: OK
weights/model-00004-of-00004.safetensors: OK
config/tokenizer.json: OK
images/inference-server.oci.tar: OK

$ sha256sum SHA256SUMS
4b7f...a921  SHA256SUMS

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

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

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

Путь обновления входит в производственную систему

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

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

Документация Red Hat для отключённых сред OpenShift рассматривает зеркалирование и офлайн-обновления как постоянную эксплуатационную работу, а не как приём установки. Такой подход верен и за пределами OpenShift. Зеркалируйте нужные репозитории, храните метаданные релизов и отрабатывайте обновление с откатом без публичной инфраструктуры. Если менеджер пакетов незаметно обращается к внешнему индексу при пересборке, пакет передачи неполон.

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

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

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

Офлайн-эксплуатации нужны собственные зависимости

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

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

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

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

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

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

Закрытые модели жёстко ограничивают возможности

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

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

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

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

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

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

Облачные и изолированные расходы устроены по-разному

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

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

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

Простое сравнение раскрывает предположения:

closed_annual_cost = annualized_hardware + facilities + licenses + operations + transfer_and_assurance
hosted_annual_cost = request_volume * blended_request_cost + connectivity + operations + assurance
cost_per_success = total_cost / accepted_task_outputs

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

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

Решение нужно принимать по доказательствам, а не по названию

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

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

До покупки разберите отказы. Что произойдёт при отказе GPU, потере доступа администратором, повреждении внутреннего реестра, истечении сертификата, серьёзной деградации модели или объявлении опасной уязвимости? Назовите допустимое время восстановления и уполномоченных людей. Если ответ требует снова подключить кластер, включите такое исключение в бюджет и согласуйте сейчас либо измените зависимость.

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

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