Введение
AI Ускорители конкурируют в кремниевой архитектуре, памяти, сетях, упаковке, системах, компиляторах, библиотеках, платформах, оркестрации и поддержке разработчиков. Публичные заявки описывают конкуренцию на основе производительности, энергоэффективности, интеграции, простоты использования, оптимизации рабочей нагрузки, экосистем программного обеспечения, дорожных карт и поставок [6-16]. Правила тестирования MLCommons показывают, почему для сравнения требуются определенные модели, сценарии, ограничения точности, описания систем и статус доступности [1-5]. Одна пиковая спецификация не может охватить эту операционную систему.
Таким образом, проблема транзакции является экономической и технической. Покупатель должен знать, какие рабочие нагрузки может выполнять цель, с какой задержкой и пропускной способностью, с какой точностью, мощностью, памятью и инженерными затратами, а также могут ли эти результаты быть воспроизведены клиентами. Он также должен знать, поддерживает ли стек программного обеспечения новые модели, могут ли клиенты мигрировать с существующих платформ, можно ли масштабировать развертывание между кластерами и сможет ли бизнес реализовать свой план, несмотря на ограничения поставок и капитала.
Этот документ предназначен для стратегических покупателей, частных инвесторов, групп корпоративного развития, учредителей, кредиторов и инвестиционных комитетов. Он обеспечивает систему проверки, оценки, условий сделок и интеграции. Он не предоставляет инженерные, юридические, налоговые, бухгалтерские, нормативные или инвестиционные консультации. Каждая транзакция требует текущей специализированной проверки продуктов, контрактов, эталонов, исходного кода, интеллектуальной собственности, договоренностей о поставках, безопасности, экспортного контроля и свидетельств клиентов.
1 Определите периметр приобретения, прежде чем устанавливать цену на платформу
Цель ускорителя может владеть архитектурой процессора, чипсетами, интерфейсами памяти, платами, системами, технологией компилятора, ядрами, программным обеспечением времени выполнения, инструментами обслуживания моделей или вертикальными приложениями. Юридическое лицо может контролировать только часть продукта, который используют клиенты. Покупатель должен составить карту всей системы, определив при этом активы и обязательства, которые перейдут при закрытии сделки.
Карта активов должна объединять патенты, файлы дизайна, среды проверки, встроенное ПО, компиляторы, библиотеки, интеграцию моделей, сценарии тестирования, телеметрию, контракты с клиентами, облачные изображения, соглашения о поставках и обученные команды. У каждого актива должен быть владелец, редакция, зависимость и свидетельство использования. Демонстрация производительности может показать потенциал. Оно должно отличаться от воспроизводимого развертывания клиентской системы с ограниченной экономикой.
Периметр приобретения также должен отличать продукты от услуг. Инженерная поддержка, преобразование моделей, оптимизация ядра и помощь в развертывании могут ускорить внедрение, скрывая при этом пробелы в программном обеспечении. Доход, зависящий от индивидуального проектирования, имеет различную долговечность и рентабельность по сравнению с доходом, полученным за счет стабильной платформы. Модель должна определять трудозатраты, инструменты и работу с учетом требований заказчика, необходимые для каждого применения материала.
Предлагаемая архитектура усердия; ценность зависит от перехода от контролируемой технологии к приемлемой экономике клиента.
| Слой ценности | Заявленный актив | Минимум доказательств | Основной транзакционный риск |
|---|---|---|---|
| архитектура | дизайн процессора, памяти и межсоединений | контролируемая конструкция, история проверок, измеренный уровень кремния и карта владения | преимущество в тесте зависит от невыпущенной конфигурации |
| программное обеспечение | компилятор, среда выполнения, ядра и библиотеки | контроль исходного кода, история выпусков, тестовое покрытие и поддержка рабочих нагрузок | эффективность клиента зависит от ручной оптимизации |
| системы | платы, стойки, сеть, охлаждение и оркестровка | квалифицированная спецификация, записи телеметрии и поддержки | узкие места компонентов стирают преимущество на уровне чипа |
| принятие | Победы в дизайне, доступность облака и производственное использование | договоры, свидетельства использования, принятия и продления | оценки учитываются как повторяющийся спрос |
| экономика | цена, нагрузка на обслуживание, маржа и денежные средства | счет, стоимость, кредиты, часы поддержки и получение | Доходы от аппаратного обеспечения скрывают нерентабельную работу по обеспечению поддержки |
Предлагаемая структура проверки; технические претензии должны быть согласованы с контролируемыми репозиториями и записями клиентов.
2. Сравните рабочие нагрузки клиентов, а не пиковые характеристики.
Пиковые операции в секунду описывают теоретическую скорость при определенной точности и условиях. Ценность для клиента зависит от рабочей нагрузки, модели, размера пакета, длины последовательности, целевой точности, требований к задержке, параллелизма, объема памяти и конфигурации программного обеспечения. Поэтому эталонный тест следует рассматривать как контролируемый эксперимент, а не как универсальное утверждение о ценности продукта.
MLCommons разделяет типы систем, категории доступности, эталонные модели и сценарии развертывания [1-5]. Его документация описывает проверку точности, отслеживание задержек, генерацию нагрузки и анализ результатов. Эти элементы управления представляют собой полезную модель проверки. Покупатель должен сохранить полное описание системы, код тестирования, флаги компилятора, версию модели, данные, границы мощности, журналы запуска и проверки результатов для каждого заявленного преимущества.
План тестирования должен включать репрезентативные рабочие нагрузки клиентов. Обучение, пакетный вывод, интерактивный вывод, поиск, рекомендации, видение и научные вычисления могут нагружать различные ресурсы. Производительность может меняться в зависимости от размера модели, разреженности, точности, пропускной способности памяти, схемы связи и запрошенного уровня обслуживания. Цель, которая возглавляет одну рабочую нагрузку, может оставаться коммерчески ценной, но оценка должна соответствовать соответствующей адресуемой рабочей нагрузке, а не экстраполироваться на весь рынок AI.
Воспроизводимость эталонных показателей является вопросом управления. Покупатель должен повторно подать претензии по материалам контролируемых систем, сравнить оптимизированные поставщиком и портативные реализации и проверить чувствительность к версиям программного обеспечения. Он должен документировать прогрев, кэширование, квантование, пакетирование и исключенные сбои. Результаты должны быть представлены в виде диапазона с условиями, необходимыми для их воспроизведения.
Происхождение эталонного показателя должно распространяться на лежащие в его основе модели и данные. Группа проверки должна зафиксировать, являются ли веса общедоступными, лицензированными или контролируемыми клиентами; была ли модифицирована модель; какие тесты на точность или качество были применены; и включена ли работа по предварительной или постобработке в измеренный интервал. Он должен сохранять образы контейнеров, манифесты зависимостей, встроенное ПО, драйверы, версии компилятора и конфигурацию машины. Результат, который невозможно воссоздать после планового обновления программного обеспечения, является слабым доказательством транзакции. Покупатель также должен протестировать нейтральную реализацию, если это возможно. Код, настроенный поставщиком, может продемонстрировать достижимую производительность платформы, в то время как портативная реализация может показать инженерную нагрузку, необходимую для ее достижения. Оба взгляда имеют значение, поскольку экономика клиентов зависит от пути от обычного развертывания к оптимизированному производству.
3 Восстановление производительности под нагрузкой и с течением времени
AI Обслуживающие системы работают по кривой. Высокий уровень параллелизма может улучшить совокупную пропускную способность, одновременно увеличивая задержку для каждого пользователя. Низкая задержка может потребовать недостаточного использования мощности. Длинные подсказки, большие модели, этапы поиска и переменные выходные данные могут изменить баланс. MLCommons Endpoints описывает измерение пропускной способности, интерактивности, времени получения первого токена и параллелизма. [3]. Модель транзакции должна связать эту кривую с уровнем обслуживания клиентов и реализованной ценой.
Руководство предполагает, что показательная система выполняет 118 тысяч эквивалентных задач в час в рабочей точке с высокой пропускной способностью. Он предполагает сокращение на 15 % набора моделей клиентов, дальнейшее сокращение на 11 % обязательств по задержке, 8 % для операционной доступности и 6 % для программного обеспечения и накладных расходов на данные. Итоговая товарная пропускная способность составляет примерно 76 тысяч эквивалентных задач в час. Эти предположения демонстрируют метод и не описывают идентифицированную компанию.
Объемы и коэффициенты конверсии представляют собой допущения руководства, используемые исключительно для демонстрации метода.
| Состояние доказательств | Требуемые доказательства | Процедура оценки | Обычное преувеличение |
|---|---|---|---|
| спецификация | опубликованная архитектура и поддерживаемая точность | только технический контекст | пиковая скорость рассматривается как пропускная способность приложения |
| лабораторный прогон | контролируемая система, код, журналы и точность | свидетельства протестированной конфигурации | выбранный прогон рассматривается как нормальное производство |
| воспроизводимый эталон | независимый повтор по соответствующим сценариям | диапазон производительности в зависимости от рабочей нагрузки | одна модель, применяемая на целевом рынке |
| пилотный клиент | целевая рабочая нагрузка, уровень обслуживания и операционный рекорд | вариант программы после оставшейся работы | подтверждение концепции засчитывается как повторное использование |
| принятая продукция | использование по контракту, телеметрия, выставление счетов и сбор | подтвержденная операционная стоимость | зарезервированная мощность рассматривается как потребленный спрос |
Предлагаемая классификация; покупатель должен использовать целевые рабочие нагрузки, системы и уровни обслуживания.
Покупатель должен проверить деградацию по мере старения системы и развития программного обеспечения. Архитектура новых моделей может выявить неподдерживаемые операторы, ограничения памяти или накладные расходы на связь. Обновления драйверов и платформы могут повысить производительность, одновременно создавая риск регрессии. Таким образом, доказательства эффективности должны быть датированы, иметь версии и связаны с дорожной картой продукта.
Эксплуатационная доступность должна включать обслуживание, сбои, ошибки развертывания и восстановление. Система с высокой эталонной скоростью может привести к снижению экономической эффективности, когда использование прерывается или требования к поддержке высоки. Модель должна согласовывать запланированные мощности, успешные рабочие места, оплачиваемые единицы, кредиты на услуги и сборы.
4 Цена за доллар, за ватт и за стойку
Клиенты покупают полезную работу в рамках ограничений. Производительность на доллар зависит от цены приобретения или аренды. Производительность на ватт отражает стоимость энергии и доступность электроэнергии. Производительность на стойку учитывает плотность размещения, сеть и охлаждение. Каждая мера может изменить предпочтительную платформу. Покупатель должен определить, какое ограничение регулирует каждый потребительский сегмент и местоположение.
Граница затрат должна включать ускорители, процессоры, память, сеть, хранилище, шасси, преобразование энергии, охлаждение, программное обеспечение, поддержку и миграцию. Более дешевый чип может привести к увеличению стоимости системы, если для него требуется больше узлов, инженерных решений или сетей. Дорогая платформа может обеспечить высокую экономическую выгоду для клиентов, если ее использование, покрытие программного обеспечения и время развертывания превосходны. Оценка должна основываться на общих экономических показателях поставленной продукции, а не на прейскурантной цене компонентов.
| Элемент | Центральный корпус | Обратный случай | Фокус усердия |
|---|---|---|---|
| реализованный доход от платформы | USD 46,000 | USD 39,000 | продолжительность контракта, использование и сброс цен |
| стоимость кремния, памяти и платы | USD 20,500 | USD 22,800 | доходность, распределение, сочетание и гарантия |
| сети, программное обеспечение и поддержка | USD 9,200 | USD 12,700 | системный контент, лицензии и инженерная нагрузка |
| пособие на миграцию и развертывание | USD 3,300 | USD 5,800 | преобразование модели, настройка и приемка заказчиком |
| взнос до фиксированных затрат | USD 13,000 | отрицательный USD 2,300 | устойчивое использование и интенсивность обслуживания |
Все значения являются предположениями руководства в расчете на годовой эквивалент развернутого ускорителя и демонстрируют только метод.
Мощность следует измерять на соответствующей границе. Мощность чипа, мощность платы, мощность сервера и мощность объекта — это разные меры. Охлаждение, сетевое подключение и простоя могут существенно повлиять на стоимость. Покупатель должен изучить измеренные показания и рабочую точку, в которой они были записаны. Также следует проверить, зависят ли улучшения производительности от агрессивных настроек электропитания, которые клиенты не могут поддерживать.
Ограничения на объектах могут создать стратегическую ценность. Ускоритель, который выполняет более приемлемую работу в рамках существующей мощности, может отложить капиталовложение в центры обработки данных. Это значение зависит от воспроизводимости рабочей нагрузки, доступности и интеграции системы. Он частично принадлежит клиенту или покупателю и не должен автоматически капитализироваться в самостоятельную стоимость объекта.
5 Зрелость составителя стоимости и охват программного обеспечения как операционные активы
NVIDIA описывает CUDA и широкий набор библиотек, фреймворков, SDK и API как часть своего технологического стека [6-10]. AMD описывает ROCm, поддержку клиентов и расширяющееся портфолио центров обработки данных [11-14]. OpenXLA, LLVM, ONNX и основные платформы иллюстрируют важность инфраструктуры компилятора, представления модели и переносимости [21-25]. Эти источники показывают размеры ценности программного обеспечения. Они не доказывают одинаковой зрелости на разных платформах.
Тщательная работа компилятора должна охватывать интерфейсы, промежуточные представления, оптимизацию графов, генерацию кода, выбор ядра, отладку, профилирование, числовую корректность и аппаратное планирование. Покупатель должен просмотреть поддерживаемые операторы, охват модели, периодичность выпусков, историю регрессов и время, необходимое для внедрения новых архитектур. Он должен определить, какая производительность достигается за счет возможности многократного использования компилятора, а какая — за счет ручной настройки клиента.
Программное обеспечение включает в себя документацию, установку, облачные образы, контейнеры, оркестрацию, обновления безопасности, возможность наблюдения и поддержку. Принятие разработчиками должно быть подтверждено активным использованием продукции, выпусками, решением проблем, качеством участников и удержанием клиентов. Количество загрузок, репозитории и активность сообщества могут предоставить контекст. Их не следует рассматривать как повторяющуюся экономическую теорию без доказательств со стороны потребителей.
Предлагаемая цепочка доказательств; каждый слой должен быть проверен на портативность, воспроизводимость и возможность использования заказчиком.
Зрелость программного обеспечения должна учитываться при оценке через измеримые экономические эффекты. Это может сократить время развертывания, использования, конверсии клиентов, затрат на поддержку и продление. Модель должна избегать широкой надбавки к платформе, не подкрепленной фактическими данными программы. Он должен связать каждую возможность программного обеспечения с группой клиентов, оставшимися инвестициями и наблюдаемыми результатами.
При проверке исходного кода необходимо изучить архитектуру, удобство сопровождения, тестирование, безопасность, автоматизацию выпуска и обязательства третьих сторон. Покупатель должен определить код, который принадлежит ему, имеет разрешительную или ограничительную лицензию, предоставляется клиентом или зависит от конфиденциальных интерфейсов. Воспроизводимость сборки следует проверять в чистой среде. Критически важные компоненты должны иметь имена сопровождающих, историю проверок и планы восстановления. Технический долг может быть экономически существенным, когда каждая новая модель или чип требует обширного ручного вмешательства. При оценке следует отличать восстановительные работы, необходимые для поддержания текущего дохода, от произвольных инвестиций, направленных на расширение платформы. Участие открытого исходного кода может способствовать принятию и набору персонала, одновременно создавая обязательства по соблюдению требований, раскрытию информации и управлению, которые требуют отдельного рассмотрения.
6. Оцените стоимость миграции, прежде чем предполагать конверсию клиента
Миграция предполагает нечто большее, чем просто перекомпиляцию кода. Клиентам может потребоваться преобразовать модели, заменить неподдерживаемые операции, перенастроить ядра, изменить точность, проверить точность, перестроить контейнеры, изменить планировщики, переобучить команды и перепроектировать мониторинг. Им также может потребоваться дублировать инфраструктуру во время перехода. Покупатель должен измерять это бремя рабочей нагрузкой и клиентом.
План миграции должен начинаться с инвентаризации моделей, платформ, пользовательских операторов, конвейеров данных, обслуживающих систем, средств управления безопасностью и уровней обслуживания. Каждый предмет должен получить оценку переносимости, план исправления, ответственного владельца, тестовые и приемочные ворота. Модель затрат должна включать проектирование заказчика, целевую поддержку, отложенное использование и параллельную работу.
Стоимость перехода может способствовать удержанию клиентов, одновременно ограничивая рост. У цели могут быть сильные клиенты, потому что она решает важную проблему или потому, что уход обходится дорого. Покупатель должен отличать преимущество продукта от зависимости. Следует также оценить, повлияет ли приобретение владельцем платформы на доверие клиентов, их нейтральность или готовность разделить рабочую нагрузку.
Миграционные стимулы следует рассматривать как стоимость приобретения, когда они необходимы для достижения успеха в бизнесе. Бесплатное проектирование, кредиты, скидки на оборудование и гарантии мощности могут ускорить внедрение и одновременно снизить цену реализации. Мост доходов должен показывать общую сумму заказов, льготы, принятое использование и собранные денежные средства.
Миграционный потенциал следует моделировать как систему ограниченной доставки. Инженеры-специалисты, доступ к моделям клиентов, средам проверки и производственным окнам могут ограничить количество программ, которые могут выполняться одновременно. Таким образом, большой конвейер может медленно конвертироваться, даже если клиенты проявляют интерес. Покупатель должен оценить время разработки, затраченное время, циклы приемки и интенсивность поддержки в зависимости от типа рабочей нагрузки. Он должен определить инструменты многократного использования и обучение, которые снизят затраты на последующий переход. Прогноз должен ограничивать конверсию продемонстрированной производительностью до тех пор, пока не станет доступным финансирование, автоматизация или поддержка партнеров. Такой подход предотвращает превращение воронки продаж в доход быстрее, чем цель может быть технически доставлена и клиенты могут принять ее с операционной точки зрения.
7 побед в тестировании, концентрация клиентов и качество использования
Победа в проекте ускорителя может означать техническую оценку, статус утвержденного поставщика, зарезервированную мощность, первоначальное развертывание или гарантированный объем. Словарь осмотрительности должен устанавливать определенные требования к доказательствам для каждого состояния. Пресс-релиз или меморандум о взаимопонимании могут поддержать стратегический контекст. Их не следует оценивать как денежные средства по контракту.
Покупатель должен сверить записи конвейера с контрактами, заказами, данными телеметрии, счетами-фактурами, кредитами и сборами. В нем должны быть указаны организация клиента, рабочая нагрузка, версия продукта, место развертывания, уровень обслуживания, цена, минимальные обязательства, права на отмену и условия приемки. Прогнозируемый объем должен быть отделен от установленной, доступной, потребляемой и оплачиваемой мощности.
Концентрацию следует измерять по клиентам, рабочим нагрузкам, облачным каналам, системным партнерам и общим экономическим родителям. Несколько программ могут зависеть от одного гиперскейлера или одного семейства моделей. Клиент также может получить преимущества за счет квалификации, финансирования мощностей или вклада в программное обеспечение. Оценка должна проверять потерю, задержку или пересмотр стоимости каждого существенного отношения.
| Состояние программы | Доказательство | Процедура оценки | Требуемая защита |
|---|---|---|---|
| оценка | план тестирования, доступ к системе и ответственные команды | ограниченная стоимость опциона | предел затрат и дата принятия решения |
| технический отбор | письменный выбор и оставшиеся условия | вариант программы после стоимости миграции | объективные ворота принятия |
| развертывание | установленная система, телеметрия и план поддержки | вероятностно-взвешенная операционная стоимость | обязательства по пропускной способности и обслуживанию |
| принятое использование | соблюдение уровня обслуживания, выставление счетов и сбор платежей | подтвержденная стоимость денежного потока | контроль продления и ценообразования |
| масштабное обновление | повторяющееся использование в разные периоды или рабочие нагрузки | устойчивая потребительская ценность после теста на концентрацию | план непрерывности и смены контроля |
Предлагаемая структура; вероятности и периоды конверсии требуют конкретных целевых доказательств.
Качество использования имеет значение. Развертывание может выполняться ниже запланированного использования из-за задержки моделей, данных или требований клиентов. Он может работать с высокой загрузкой и низкой рентабельностью, поскольку затраты на поддержку и электроэнергию занижены. Инвестиционный комитет должен получать экономические данные на уровне потребителя, а не единый показатель установленной мощности.
8 Изготовление карт, память, упаковка и сетевые зависимости
Производительность ускорителя зависит от изготовления, упаковки, HBM, подложек, сети, системной интеграции и подачи энергии. Спецификации Open Compute Project иллюстрируют модульный ускоритель и системные интерфейсы. [26]. Стандарты UCIe, памяти и межсоединений обеспечивают дополнительный контекст [27-29]. Публичная информация о литейном производстве и упаковке описывает продолжающиеся инвестиции и техническую сложность [30-32]. Дорожная карта цели должна быть проверена на предмет соответствия этим зависимостям.
Покупатель должен проверить соглашения о пластинах, распределение упаковки, поставку памяти, производство платы, квалификацию компонентов, контроль изменений, приоритет, цены, минимальную закупку, гарантию и статус вторичного источника. Имя поставщика в плане не определяет доступную мощность. Модель должна использовать исполненные права, датированную готовность и продемонстрированную доходность.
Сеть и связь могут стать узким местом системы по мере масштабирования кластеров. План тестирования должен измерять коллективные операции, перегрузку, восстановление после сбоев и масштабирование рабочей нагрузки. Преимущество на уровне чипа может исчезнуть, когда возрастут затраты на программное обеспечение или фабрику. Поэтому оценка должна включать производительность на уровне системы и капитал, необходимый для обещанной конфигурации.
Обязательства по поставкам могут создавать как ценность, так и ответственность. Предоплаты и обязательства «бери или плати» могут обеспечить мощность, потребляя при этом ликвидность, если спрос изменится. Мощности, финансируемые клиентами, могут снизить потребности в капитале, одновременно создавая условия приоритета, возврата или эксклюзивности. Покупатель должен показать каждое обязательство по продукту, периоду, контрагенту и последствиям смены контроля.
9. Цените дорожную карту как последовательность доказательств
Дорожные карты акселератора охватывают архитектуру, моделирование, вывод на ленту, первую микросхему, ввод в эксплуатацию, внедрение программного обеспечения, квалификацию системы и принятие заказчиками. Каждые ворота имеют разную вероятность, оставшуюся стоимость и время. Слайд с дорожной картой не должен получить полную операционную ценность до тех пор, пока доказательства не подтвердят конверсию.
Покупатель должен поддерживать единую интегрированную дорожную карту аппаратного и программного обеспечения. Поставка микросхем без готовности компилятора, фреймворка и системы может привести к задержке доходов. Программное обеспечение может развиваться после запуска и улучшать производительность. В прогнозе должна быть указана версия, необходимая для каждой клиентской программы, и ресурсы, необходимые для ее реализации.
Ценность дорожной карты можно смоделировать как набор опций программы. Каждый вариант должен иметь определенный продукт, рабочую нагрузку, группу клиентов, ожидаемые денежные средства, вероятность, оставшиеся инвестиции и самую раннюю дату принятия решения. Общие затраты и зависимости должны быть распределены один раз. Модель должна предотвратить появление одних и тех же будущих возможностей как в терминальном росте, так и в стоимости отдельных опционов.
Конечная стоимость должна отражать способность производить последовательные продукты, а не одно благоприятное поколение. Покупатель должен оценить повторное использование архитектуры, непрерывность работы команды, активы проверки, переносимость программного обеспечения, доступ поставщиков и доверие клиентов. Быстрый ритм может поддержать ценность, если предыдущие ворота были достигнуты с контролируемыми затратами и качеством.
10. Постройте оценку на основе принятой экономики рабочей нагрузки
Самостоятельную оценку следует начинать с денежных потоков на уровне клиентов. Доход должен определяться принятыми развертываниями, потребленными или заключенными по контракту единицами, реализованной ценой и продлением. Затраты должны включать в себя кремний, память, системы, программное обеспечение, поддержку, миграцию, гарантию, капитальный и оборотный капитал. Анализ сценариев должен сочетать в себе производительность, использование, цену, мощность и сроки реализации дорожной карты.
Руководство предполагает наличие пяти принятых когорт клиентов с текущей стоимостью USD 890 million, четырех вариантов масштабируемого развертывания стоимостью USD 430 million, четырех технических вариантов стоимостью USD 220 million и четырех вариантов дорожной карты стоимостью USD 180 million. Затем он вычитает USD 190 million для концентрации клиентов, USD 120 million для поддержки миграции и USD 270 million из оставшегося капитала дорожной карты. Допуск на платформу в размере USD 540 million дает предполагаемую стоимость отдельного предприятия в размере USD 1.68 billion. Все суммы являются предположениями руководства.
Все суммы представляют собой предположения руководства в USD миллионах и не описывают идентифицированную компанию.
| Состояние программы | когорты | Иллюстративная вероятность | Средняя приведенная стоимость на когорту | Вероятностно-взвешенное значение |
|---|---|---|---|---|
| принятое использование | 5 | 100% | USD 178m | USD 890m |
| масштабированное развертывание | 4 | 80% | USD 134m | USD 430m |
| технический отбор | 4 | 50% | USD 110m | USD 220m |
| вариант дорожной карты | 4 | 25% | USD 180m | USD 180m |
| валовая стоимость программы | 17 | смешанный | смешанный | USD 1,720m |
Значения и вероятности являются управленческими предположениями только для демонстрации метода.
Рыночные мультипликаторы могут обеспечить проверку разумности после установления сопоставимости. Качество доходов, аппаратное обеспечение, зрелость программного обеспечения, валовая прибыль, капиталоемкость, концентрация клиентов и риски дорожной карты существенно различаются в разных компаниях-акселераторах. Множитель платформы не следует применять только потому, что в цели используется терминология AI.
Модель должна отделять самостоятельную ценность от ценности, специфичной для покупателя. Распространение, доступ к поставкам, охват облачных технологий, системная интеграция и оптимизация программного обеспечения могут создать синергию. Их ценность зависит от ресурсов покупателя, стоимости внедрения, реакции клиента и ограничений конкуренции. Продавец не должен получать полную оплату за синергию, которую может произвести только покупатель.
Анализ финансирования должен отражать волатильность и потребности платформы в капитале. Кредитная емкость должна основываться на повторяющемся, принятом денежном потоке после обязательств по поставкам, гарантии, поддержке и инвестициям в дорожную карту. Отставание, резервирование и прогнозы клиентов должны классифицироваться по праву на принудительное исполнение и отмену. Кредитору может потребоваться ликвидность для ликвидаций, запасов, депозитов мощности и миграции клиентов до получения дохода. Обратной стороной должны быть сочетание задержки развертывания, более низкой реализованной цены, более высоких затрат на поддержку и продолжения расходов на дорожную карту, поскольку эти факторы давления могут возникать одновременно. Финансирование приобретения должно включать в себя запас по соглашению и финансирование плана интеграции, а не предполагать, что заголовок EBITDA подлежит немедленному распространению.
11. Обеспечьте синергию с учетом потребностей покупателей с помощью подотчетных планов доставки.
Синергия может возникнуть за счет закупок, распределения упаковки, создания сетей, облачного распространения, интеграции программного обеспечения, доступа клиентов и снижения дублирующих затрат. Каждая инициатива должна иметь исходную точку, владельца, ресурсы, сроки, зависимость и измеримый денежный результат. Такой ярлык, как влияние экосистемы, недостаточен для оценки.
Техническую синергию следует проверять посредством определенных рабочих нагрузок. Объединение целевого ускорителя с компилятором покупателя, межсетевым соединением или системой может улучшить производительность, использование или время развертывания. Модель должна включать стоимость интеграции и риск того, что клиенты откажутся от закрытой или измененной платформы. Результаты следует сопоставлять с базовым уровнем подписания.
Синергия доходов требует подтверждения со стороны клиентов. Канал покупателя может расширить доступ, создавая при этом конфликты с клиентами, конкурирующими с покупателем. Модель должна идентифицировать клиентов, предложения, циклы продаж, поддержку миграции и возможности. Значительное процентное повышение должно оставаться вне основного сценария, если оно не поддерживается программными планами.
Синергия затрат должна сохранить критически важные возможности. Удаление дублированного проектирования без понимания компилятора, проверки, поддержки и зависимостей клиентов может повредить платформу. В плане интеграции следует отличать устранимые корпоративные затраты от работы над продуктом, необходимой для дорожной карты и надежности.
12. Выберите структуру транзакции, соответствующую сроку доказательства.
Полное приобретение может поддержать интегрированные решения по продуктам и дистрибуции, одновременно концентрируя дорожную карту и риски клиентов при закрытии сделки. Поэтапное приобретение может связать право собственности и вознаграждение с микросхемами, программным обеспечением или шлюзами для клиентов. Миноритарные инвестиции могут обеспечить права на обучение и коммерческие права, сохраняя при этом нейтралитет. Совместное предприятие может объединять взаимодополняющие активы, одновременно усложняя управление. Лицензионное соглашение или соглашение о поставке могут обеспечить доступ без приобретения компании.
| Структура | Соответствующие доказательства указывают | Контроль покупателя | Основная защита | Основное ограничение |
|---|---|---|---|---|
| полное приобретение | приемлемое использование, долгосрочные права и план интеграции | высокий | условия, возмещение, удержание и заветы | предварительное ознакомление с дорожной картой и концентрация |
| поэтапное приобретение | мощная технология с сохранением клиентских или программных шлюзов | высокий после вех | этап рассмотрения и звоните или ставьте механиков | Будущее ценообразование и сложность управления |
| миноритарные инвестиции | разработка платформы с обучающей ценностью | ограниченный | права на информацию, согласие и участие | ограниченная власть над капиталом и исполнением |
| совместное предприятие | дополнительные кремниевые, программные или дистрибутивные активы | общий | правила вклада, поля, финансирования и тупика | разделение полномочий и риск утечки IP-адресов |
| лицензия или договор поставки | необходимость доступа с обоснованием ограниченного владения | договорной | объем, уровни обслуживания, непрерывность и аудит | поставщик остается ответственным за исполнение |
Предлагаемая структура принятия решений; юридические, налоговые, бухгалтерские и нормативные последствия требуют консультации специалиста.
Условное вознаграждение может устранить неопределенность, если показатель поддается измерению и обеспечивается контроль со стороны покупателя. Соответствующие параметры могут включать в себя воспроизводимость тестов, покрытие компилятора, приемлемое развертывание, использование, валовую прибыль или реализацию дорожной карты. В соглашении должны быть определены конфигурация, доказательства, период измерения, изменения клиентов, капитальные обязательства, учет, аудит и разрешение споров.
Руководство должно защитить актив до того, как он получит полный контроль. Права на информацию, обязательства по финансированию, решения по дорожной карте, использование интеллектуальной собственности, нейтральность к клиентам и транзакции со связанными сторонами должны соответствовать структуре. Покупатель должен избегать получения конфиденциальной информации о клиентах, выходящей за рамки его законных прав.
13 Адресная конкуренция, функциональная совместимость и нейтральность платформ
В Руководящих принципах США по слияниям обсуждаются транзакции, включающие платформы, дополнения, функциональную совместимость и доступ к ресурсам [37-39]. Приобретение акселератора может повлиять на разработчиков, поставщиков облачных услуг, клиентов, системных партнеров и конкурирующее оборудование. Покупатель должен определить, где цель поддерживает многоплатформенное использование и может ли транзакция изменить стимулы для сохранения этой поддержки.
При анализе конкуренции следует изучить определение рынка, альтернативы для клиентов, стоимость перехода, сроки реализации дорожной карты, доступ к поставкам, инструменты и данные для разработчиков. Небольшая текущая база доходов не устраняет перспективных проблем, когда цель может снизить зависимость от установленной платформы. Анализ должен проводиться квалифицированным юристом с использованием действующего законодательства и фактов.
Средства правовой защиты или обязательства могут повлиять на стоимость. Требования, касающиеся совместимости, лицензирования, разделения информации, поставок, потребительской нейтральности или недискриминации, могут ограничивать запланированную интеграцию или синергию. Оценка должна учитывать стоимость, задержку и стратегический эффект заслуживающих доверия результатов, а не рассматривать одобрение как бинарное событие.
Нейтральность платформы сама по себе может быть преимуществом. Клиенты могут оценить компилятор, уровень оркестрации или инструмент модели, поскольку он поддерживает несколько ускорителей. Приобретение одним поставщиком оборудования может ослабить это предложение. Покупатель должен проверить удержание клиентов и партнеров и сохранить управление там, где нейтральность поддерживает денежный поток.
Контроль данных, безопасности и экспорта может формировать периметр интеграции. Рабочие нагрузки клиента могут содержать конфиденциальные модели, методы обучения, персональные данные или регулируемую информацию. Артефакты эталонного тестирования и телеметрия могут быть ограничены по контракту. Репозитории исходных кодов могут содержать контролируемую техническую информацию, криптографические материалы или сторонний код. Покупатель должен указать, где хранятся эти активы, кто может получить к ним доступ, как они пересекают границы и какие разрешения применяются. Планы интеграции должны сохранять доступ с наименьшими привилегиями, ведение журнала, сегрегацию и реагирование на инциденты. Любая запланированная передача команд, инструментов или технологий должна быть проверена на предмет соответствия действующим правилам экспорта и санкций. Затраты и задержки, возникающие из-за необходимого контроля, включены в модель транзакции и план закрытия.
14 Согласование капитальных затрат, оборотного капитала и обязательств по поддержке
Разработка ускорителя требует проектирования, проверки, внедрения, программного обеспечения, систем, инвентаря, квалификации и поддержки. Покупателю следует разделить техническое обслуживание, план действий, дискреционный рост и инвестиции, финансируемые клиентом. Объявленный капитал должен быть сверен с заказами на закупку, контрактами, этапами, платежами и полезной продукцией.
Риск запасов может возрасти во время смены поколений. Чипы, платы и системы могут стать менее ценными при перемещении программного обеспечения, графиков работы клиентов или новых продуктов. Группа проверки должна классифицировать инвентарь по версиям, клиентам, квалификации, возможности восстановления и правам на отмену. Обязательства по закупкам и депозиты поставщиков должны проверяться в условиях центрального и понижающегося спроса.
Оборотный капитал должен включать дебиторскую задолженность, кредиты, гарантии, обязательства по поддержке, предоплаты и резервирование мощностей. Отгрузка оборудования не всегда означает окончательную приемку. Модель денежных потоков должна отражать установку, приемку, использование, кредиты на обслуживание и сбор средств.
Капитализированные затраты на программное обеспечение и разработку требуют бухгалтерского учета. Покупатель должен согласовать экономическую жизнь с ритмичностью выпуска продукции и ее использованием потребителями. Учет закупок должен идентифицировать приобретенную технологию, отношения с клиентами, контракты и деловую репутацию, используя действующие стандарты [43-47]. Учетные классификации не заменяют операционную оценку.
15 Защитите доверие клиентов и непрерывность разработки посредством интеграции
Интеграция должна сохранить дорожные карты, качество выпускаемой продукции, конфиденциальность клиентов, безопасность, права на поставку и подотчетные решения. Клиенты могут беспокоиться, что стратегический покупатель отдаст предпочтение своим собственным продуктам, изменит цены, уменьшит мобильность или получит доступ к конфиденциальным рабочим нагрузкам. Коммуникация должна обеспечивать непрерывность, поддержку, совместимость и управление с использованием обязательств, которые может выполнить объединенная компания.
Риск ключевых лиц выходит за рамки руководителей. Архитектура, проверка, компилятор, ядро, фреймворк, поддержка и знания клиентов могут выполняться небольшими командами. Удержание должно быть связано с ролью, полномочиями, дорожной картой и передачей знаний. Документация должна включать проектные решения, историю исходного кода, системы сборки, эталонные артефакты, тестовое покрытие и известные дефекты.
| Рабочий поток | Требуемые доказательства | Контроль в первый день | Итоги первой сотни дней |
|---|---|---|---|
| клиенты | контракты, рабочие нагрузки, уровни обслуживания и карта коммуникаций | названный владелец отношений и протокол конфиденциальности | проверенный базовый план программы и план хранения |
| инженерия | архитектура, исходный код, выпуски, дефекты и дорожная карта | защищенные команды, репозитории и полномочия выпуска | интегрированная дорожная карта с финансируемыми воротами |
| ориентиры | конфигурации, код, логи, точность и границы мощности | замороженные определения и независимый план повторного запуска | воспроизводимая информационная панель производительности, релевантная для клиента |
| поставлять | пластина, упаковка, память, системы и обязательства по закупкам | ответственный владелец для каждой критической зависимости | продленные права и проверенный план действий в чрезвычайных ситуациях |
| ценить | Модель подписания, стоимость миграции, синергия и финансирование интеграции | один контролируемый базовый план и журнал изменений | отчет об измеренном приемлемом использовании, затратах и чистой синергии |
Предлагаемый план контроля; сроки должны быть адаптированы к одобрению сделок и обязательствам клиентов.
Последовательность интеграции должна учитывать риски клиента и релиза. Немедленные изменения в компиляторе, драйверах, репозиториях, системах сборки или телеметрии могут привести к регрессии. Покупатель должен определить, какие системы могут измениться в первый же день, какие требуют контролируемого тестирования, а какие должны оставаться отдельными до тех пор, пока продукт или клиент не поступят на рынок.
16. Используйте модель управления «подпись-принятое развертывание»
Интервал между подписанием и принятием использования клиентом может привести к существенному изменению стоимости. Графики выпуска продукции, выпуски программного обеспечения, результаты тестов, распределение поставок и программы для клиентов продолжают меняться. Модель контроля должна охватывать финальный этап проверки, включая закрытие, интеграцию и, по крайней мере, первый проверяемый цикл принятых развертываний и сборов.
Модель должна начинаться с замороженного базового уровня подписания. В нем должна быть указана каждая программа, рабочая нагрузка, конфигурация, контрольный показатель, уровень обслуживания, цена, маршрут поставок, необходимый персонал, капитал и прогнозируемые денежные средства. Изменения следует фиксировать по сравнению с базовым уровнем. Регресс программного обеспечения, отложенное прекращение производства, сокращение поставок, изменение дизайна для клиентов или сброс цен могут повлиять на стоимость еще до того, как она появится в отчетных доходах.
Временные соглашения должны защищать материальные активы и программы, сохраняя при этом законную оперативную ответственность. Продавец должен поддерживать команды, репозитории исходного кода, контроль выпуска, права на поставку, отношения с клиентами и обычный капитал. Существенные гранты на интеллектуальную собственность, эксклюзивность, изменения в дорожной карте, аннулирование или незапланированные обязательства могут потребовать согласия в соответствии с применимым законодательством и согласованными пороговыми значениями.
Готовность к закрытию должна включать проверенный доступ к репозиториям, системам сборки, ключам подписи, контрольным артефактам, системам поддержки, контактам с поставщиками и эскалации с клиентами. Покупатель должен знать, какие учетные данные и данные можно передавать, какие требуют согласия, а какие должны оставаться изолированными. У каждой неразрешенной зависимости должен быть владелец и дата действия.
17 Перевести результаты проверки в цену, условия и действия по интеграции
Усердие создает ценность, когда результаты меняют решение. Каждый существенный результат следует классифицировать как корректировку цен, структурную статью, условие закрытия, договорную защиту, интеграционное действие или контролируемый риск. Классификация должна определять доказательства, финансовые риски, сроки, владельца и решение.
Корректировка цен может касаться более слабого приемлемого использования, неподдерживаемой производительности, затрат на миграцию или необходимого капитала. Заключительное условие может касаться одобрения клиента, согласия на поставку или финансирования. Заявление, возмещение или условное депонирование могут решить проблему выявленного риска. Ковенант может сохранить команды, хранилища, дисциплину выпуска или снабжение. Действие интеграции может исправить контролируемую слабость после закрытия.
Предлагаемая карта решений; Позиция и лечение должны быть откалиброваны с учетом конкретных данных.
Заявления и гарантии должны соответствовать характеру и продолжительности риска. Они могут охватывать вопросы владения интеллектуальной собственностью, соответствия открытым исходным кодам, эталонных заявлений, контрактов с клиентами, прав на поставку, безопасности, экспортного контроля и финансовой отчетности. Страхование может покрыть некоторые договорные риски. Оно не заменяет техническое тестирование, свидетельства клиентов или финансируемый план интеграции.
Окончательный инвестиционный документ должен согласовать общую цену, чистый долг, оборотный капитал, условное вознаграждение, удержание, транзакционные издержки и финансирование интеграции. В нем должна быть представлена отдельная стоимость, стоимость для конкретного покупателя и вознаграждение на одной и той же основе. Он должен показать, как каждое важное открытие, полученное в результате тщательной проверки, изменило модель или условия.
Заключение
AI Транзакции-ускорители объединяют экономику полупроводников, программного обеспечения, систем, клиентов и платформ. Достоверная оценка следует за воспроизводимой цепочкой от контролируемых прав и поставок через измеряемую микросхему, зрелое программное обеспечение, развертывание у клиентов, приемлемое использование и собранные денежные средства. Пиковые характеристики и выбранные тесты предоставляют контекст. Прежде чем они подтвердят эксплуатационную ценность, им необходимы рабочая нагрузка, точность, задержка, мощность и системные доказательства.
Самая мощная платформа обеспечивает экономичную полезную работу в соответствующих условиях клиента. Он сочетает в себе воспроизводимую производительность, зрелость компилятора и библиотеки, управляемую миграцию, надежность поставок, доверие клиентов и финансируемый план действий. Его премия обусловлена повторяемым внедрением и постоянным контролем, а не результатом одного теста или цикла разработки продукта.
Дисциплина транзакций практична. Определите актив. Восстановите производительность под нагрузкой. Цена полной системы экономики. Тестирование охвата и миграции программного обеспечения. Проверьте использование клиентом. Предоставление карт и зависимости от дорожной карты. Программы стоимости от принятых наличных. Отдельная синергия покупателей. Выбирайте условия, соответствующие зрелости доказательств. Поддерживайте один контролируемый базовый уровень путем закрытия и принятия развертывания.
Источники
- MLCommons, пакет тестов вывода MLPerf, Прочтите первоисточник
- MLCommons, Руководство по отправке выводов MLPerf, Прочтите первоисточник
- MLCommons, тест конечных точек MLPerf, Прочтите первоисточник
- MLCommons, MLPerf Измерение мощности вывода, Прочтите первоисточник
- MLCommons, тесты языковой модели MLPerf Inference v5, Прочтите первоисточник
- NVIDIA, Годовой отчет за 2026 г. по форме 10-К, Прочтите первоисточник
- NVIDIA, годовой отчет за 2026 год и прокси-материалы, Прочтите первоисточник
- NVIDIA, результаты четвертого квартала 2026 финансового года, Прочтите первоисточник
- NVIDIA, документация по платформе CUDA, Прочтите первоисточник
- NVIDIA, документация TensorRT, Прочтите первоисточник
- Advanced Micro Devices, Годовой отчет за 2025 г. по форме 10-K, Прочтите первоисточник
- Advanced Micro Devices, документация ROCm, Прочтите первоисточник
- Раскрытие информации о Advanced Micro Devices, центрах обработки данных и продуктах Instinct, Прочтите первоисточник
- Advanced Micro Devices, годовые отчеты и документы, Прочтите первоисточник
- Intel, Годовой отчет за 2024 г. по форме 10-К, Прочтите первоисточник
- Документация Intel, ускорителя Гауди, Прочтите первоисточник
- Google Cloud, документация ТПУ, Прочтите первоисточник
- Amazon Web Services, документация Trainium, Прочтите первоисточник
- Обзор ускорителя Microsoft, Maia AI, Прочтите первоисточник
- Мета Инжиниринг, программа акселератора MTIA, Прочтите первоисточник
- OpenXLA, документация проекта компилятора, Прочтите первоисточник
- LLVM Project, документация по инфраструктуре компилятора, Прочтите первоисточник
- ONNX, документация по обмену открытыми моделями, Прочтите первоисточник
- PyTorch, документация компилятора, Прочтите первоисточник
- TensorFlow, документация XLA, Прочтите первоисточник
- Open Compute Project, базовая спецификация модуля OCP Accelerator, Прочтите первоисточник
- Консорциум UCIe, ресурсы спецификаций, Прочтите первоисточник
- PCI-SIG, ресурсы Compute Express Link, Прочтите первоисточник
- JEDEC, ресурсы стандартов памяти с высокой пропускной способностью, Прочтите первоисточник
- Тайваньская компания по производству полупроводников, годовой отчет за 2025 год, Прочтите первоисточник
- Amkor Technology, годовые отчеты и документы, Прочтите первоисточник
- ASE Technology Holding, годовые отчеты, Прочтите первоисточник
- Национальный институт стандартов и технологий, AI Структура управления рисками, Прочтите первоисточник
- Национальный институт стандартов и технологий, план взаимодействия по стандартам AI, Прочтите первоисточник
- Министерство торговли США, CHIPS для Америки, Прочтите первоисточник
- Бюро промышленности и безопасности США, правила экспортного администрирования, Прочтите первоисточник
- Министерство юстиции США и Федеральная торговая комиссия, Рекомендации по слияниям на 2023 год, Прочтите первоисточник
- Министерство юстиции США, Руководство 6 об закреплении или расширении доминирующего положения, Прочтите первоисточник
- Министерство юстиции США, Руководство 9 о многосторонних платформах, Прочтите первоисточник
- Федеральная торговая комиссия, программа уведомлений о предварительных слияниях Харт-Скотт-Родино, Прочтите первоисточник
- Европейская комиссия, руководящие принципы горизонтальных слияний, Прочтите первоисточник
- Европейская комиссия, Закон о цифровых рынках, Прочтите первоисточник
- Фонд МСФО, МСФО 3 «Объединения бизнеса», Прочтите первоисточник
- Фонд МСФО, МСФО (IAS) 38 «Нематериальные активы», Прочтите первоисточник
- Фонд МСФО, МСФО (IAS) 36 «Обесценение активов», Прочтите первоисточник
- Фонд МСФО, МСФО (IFRS) 13 «Оценка справедливой стоимости», Прочтите первоисточник
- Совет по стандартам финансового учета, Тема 805 «Объединения бизнеса», Прочтите первоисточник
- Всемирная организация интеллектуальной собственности, оценка интеллектуальной собственности, Прочтите первоисточник
- ОЭСР, конкуренция в цифровой экономике, Прочтите первоисточник
- MLCommons, эталонные рабочие группы и управление, Прочтите первоисточник
