Соединение инфраструктуры и команд продукта: уроки, извлеченные из построения платформ GenAI

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

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

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

Итак, какой вид имеет этот разрыв в реальном мире, и какие стратегии могут использовать организации для согласования инфраструктуры и команд продукта для успеха GenAI?

Проблемы с несоответствием

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

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

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

Мост к успеху

Успех GenAI зависит не только от наличия прочной инфраструктуры, но и от создания тактического плана, который связывает процессы инфраструктуры и продукта. Возьмем, к примеру, идею внутренних самодостаточных API для обеспечения GPU. Для команд инфраструктуры эти API стандартизируют доступ, снижают нагрузку на билеты и обеспечивают соответствие требованиям; для команд продукта они обеспечивают быстрый и предсказуемый доступ к вычислениям без ожидания в очереди. В результате обе группы работают с одного и того же “контракта” API, удаляя узкие места и уточняя ожидания.

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

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

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

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

Наконец, никакое партнерство не может просуществовать без взаимного обязательства по безопасности и соответствию требованиям. Независимо от того, применяются ли SOC2, HIPAA, ISO или другие рамки, конкретные требования варьируются в зависимости от базы клиентов и отраслевого сектора — но ответственность является общей. И команды инфраструктуры, и команды продукта должны внутренне осознать эти обязательства, признавая, что соответствие требованиям не является простым упражнением по отметке в коробке, а основой доверия с пользователями.

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

Знающие команды

Иметь правильных людей так же важно, как и иметь правильные системы. Идеально, команды должны включать членов команд, которые уже знают свой путь вокруг GenAI, или тех, кто приходит из высокопроизводительных вычислений и гипермасштабных центров данных. То, что действительно имеет значение, — это практический опыт и уроки, которые можно получить только из построения и поддержки платформ GPU-as-a-service. Это означает понимание того, как GPU взаимодействуют друг с другом, как тесно связанные обучающие запуски ведут себя, и как чувствительны они к задержке, синхронизации и доставке данных.

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

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