Marvell и силикон, который незаметно обеспечивает работу облачной инфраструктуры

Чем занимается Marvell в современных облачных дата-центрах

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

Marvell концентрируется на этом «среднем» слое: чипах, которые связывают вычисления с сетью и хранилищем, ускоряют типичные задачи дата-центра и поддерживают предсказуемое поведение под нагрузкой.

Где Marvell расположен в типичном облачном стеке

Если представить стойку облака сверху вниз, устройства Marvell часто находятся:

• На сетевом краю сервера, помогая эффективно отправлять и принимать трафик
• В коммутаторах и сетевом оборудовании, направляя пакеты куда нужно
• Близко к хранилищу, перемещая данные между SSD, сетями хранения и серверами
• На ключевых межсоединениях, обеспечивая быструю связь между компонентами

Это не «приложения» и не «сервера» в привычном смысле — это аппаратные кирпичики, которые позволяют тысячам серверов вести себя как единое целое.

Почему большая часть этой работы незаметна для пользователей

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

Краткая карта: сеть, хранилище, ускорение

Роль Marvell легче разделить на три группы:

• Сеть: быстрое и предсказуемое перемещение пакетов
• Хранилище: безопасное чтение/запись данных в масштабе
• Ускорение: специализированные вычисления для повторяющихся инфраструктурных задач

Это «тихий» силикон, который делает облачные сервисы простыми на поверхности.

Почему облакам нужны специализированные инфраструктурные чипы

Облачные приложения кажутся «software-defined», но физическая работа всё ещё выполняется в стойках серверов, коммутаторов и массивов хранения. По мере роста спроса облака не могут полагаться только на универсальные CPU для каждой задачи без серьёзных ограничений по цене и эффективности.

Трафик растёт быстрее, чем свободные ресурсы CPU

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

Внутри дата-центра доминирует east–west трафик

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

Эффективность стала критерием первого класса

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

• Производительность на ватт (больше работы при том же энергопотреблении)
• Плотность серверов (больше полезных вычислений на стойку)
• Операционные расходы (меньше энергии и охлаждения при той же пропускной способности)

От «одного большого CPU» к специализированным помощникам

Вместо масштабирования за счёт добавления универсальных ядер, облачные платформы всё чаще используют назначенные чипы — Smart NIC/DPUs, коммутационный силикон, контроллеры хранения и акселераторы — чтобы снять с CPU повторяющиеся, объёмные инфраструктурные задачи. Результат — облако быстрее и дешевле в эксплуатации, даже по мере роста потребностей в данных.

Аппаратная разгрузка сети: Smart NIC и DPU простыми словами

Серверы облака тратят удивительно много времени на «инфраструктурную работу», а не на запуск вашего приложения. Каждый пакет нужно передать, проинспектировать, залогировать и иногда зашифровать — часто это делает основной CPU. Аппаратная разгрузка переносит эти обязанности на специализированное железо — тут и появляются Smart NIC и DPU, включая решения на базе силикона Marvell.

Smart NIC vs DPU (на пальцах)

Smart NIC — сетевая карта, которая делает больше, чем простая отправка/приём: помимо портов Ethernet она содержит дополнительные вычисления (обычно ядра Arm и/или программируемую логику) для выполнения сетевых функций прямо на карте.

DPU (Data Processing Unit) идёт дальше: это выделенный «инфраструктурный компьютер» внутри сервера. DPU обычно сочетает высокопроизводительную сеть, несколько CPU-ядер, аппаратные ускорители (крипто, обработка пакетов) и функции изоляции, чтобы управлять перемещением данных и безопасностью без опоры на хост-CPU.

Практическая модель для запоминания:

• Smart NIC: NIC с полезным интеллектом.\n- DPU: NIC плюс выделенная система для инфраструктурных задач.

Что именно разгружается с CPU

Переносятся повторяющиеся, объёмные операции, которые иначе отнимали бы CPU у приложений. Типичные примеры:

• Путь данных сети: виртуальный свитч, правила маршрутизации, инкапсуляция/декапсуляция (оверлеи), управление потоком
• Безопасность: TLS/IPsec, применение политик брандмауэра, микросегментация, secure boot и аттестация
• Ускорение трафика хранения: эффективная маршрутизация пакетов хранения, где это применимо\n- Телеметрия: логи потоков, выборка пакетов, счётчики, измерения задержки — на скоростях линии

Почему это важно: предсказуемая производительность и снижение нагрузки на CPU

Когда CPU «присматривает» за сетью, производительность приложений может прыгать из‑за всплесков трафика, «шумных соседей» или пиков безопасности. Разгрузка помогает:

• Освободить CPU для приложений (веб-сервисы, БД, AI-пайплайны)\n- Стабилизировать латентность, потому что обработка пакетов идёт аппаратными путями\n- Увеличить плотность хоста: меньше CPU-ресурсов на инфраструктуру — больше полезной работы на сервер\n- Улучшить изоляцию: инфраструктурные функции могут выполняться отдельно от рабочих нагрузок арендаторов

Где физически располагается DPU в сервере (и к чему подключается)

Физически DPU обычно поставляется в виде PCIe-карты или модуля OCP NIC. Он подключается к:

• Top-of-rack сети через порты Ethernet (часто высокоскоростные ссылки)\n- Хосту через PCIe, выступая шлюзом для сетевого трафика между CPU и памятью

Концептуально DPU становится «регулировщиком трафика» между сетью и сервером — обрабатывая политики, шифрование и коммутацию, чтобы ОС и CPU хоста могли сосредоточиться на приложениях.

Внутренности сетей облака: Ethernet-коммутация и обработка пакетов

Когда вы открываете приложение или перемещаете данные в облако, ваш запрос обычно не идёт к «серверу» напрямую — он проходит через ткань Ethernet-коммутаторов, которые связывают тысячи серверов так, будто это одна большая машина.

Как данные движутся между серверами: ToR и spine

Большинство дата-центров используют дизайн «leaf–spine»:\n\n- Top-of-rack (ToR) / leaf — коммутаторы в каждой стойке, соединённые с серверами этой стойки.\n- Spine — коммутаторы, связывающие все ToR, чтобы любой сервер мог достичь любого другого за предсказуемое число прыжков.

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

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

Два числа формируют пользовательский опыт и стоимость:\n\n- Латентность (время прохождения пакета) влияет на интерактивные нагрузки — API, БД, микросервисы и аналитика в реальном времени.\n- Пропускная способность (данные в секунду) важна для массовых переносов — репликация хранилища, бэкапы, стриминг и большие AI-данные.

Операторы стремятся держать латентность стабильной при высокой загрузке каналов и одновременно прокачивать огромные объёмы трафика.

Ключевые функции: коммутация, обработка пакетов, QoS

Чип коммутатора делает не только «форвардинг». Он должен:\n\n- Определять назначения (MAC, VLAN и зачастую заголовки маршрутизации/оверлеи) на скорости линии.\n- Буферизовать и планировать трафик, чтобы не дать заторам распространяться по сети.\n- Применять QoS, чтобы чувствительные к латентности потоки не тонули в фоне.\n- Поддерживать телеметрию и механизмы контроля перегрузок, помогающие операторам настраивать производительность.

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

Что дают «более высокие скорости»

Переход с 25/100G на 200/400/800G — это не просто числа. Более высокие скорости означают:\n\n- Больше виртуальных машин в стойке без перерасхода сети\n- Быстрый доступ к хранилищу (особенно для разорванного/сеть-ориентированного NVMe)\n- Короткие циклы обучения AI за счёт более стабильной подачи данных к GPU

В результате сеть дата-центра ощущается не как «провода», а как общий ресурс для всех рабочих нагрузок.

Силикон хранения: контроллеры, NVMe и защита данных

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

Что делает контроллер хранения

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

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

NVMe: почему он везде

NVMe (Non-Volatile Memory Express) — протокол, созданный для быстрого флеш-хранилища. Он стал распространённым, потому что снижает накладные расходы и поддерживает параллельные очереди запросов — то есть много операций может находиться «в полёте» одновременно, что хорошо подходит для облачных сценариев с тысячами мелких операций.

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

Встроенные функции: шифрование, сжатие и помощь при восстановлении

Современные контроллеры часто включают аппаратные функции, которые в противном случае отнимали бы CPU:\n\n- Шифрование/расшифровка для защиты данных в покое с минимальным падением производительности\n- Сжатие для хранения большего объёма и передачи меньшего объёма (полезно при ограниченной пропускной способности)\n- Паритет и помощь при восстановлении (erasure coding) для устойчивости к отказам и более быстрой реконструкции данных

Почему производительность хранилища меняет поведение приложений

Хранилище не изолированная подсистема — оно формирует поведение приложений:\n\n- Базы данных зависят от быстрых и предсказуемых записей для транзакций и журналов.\n- Пайплайны аналитики могут простаивать, когда чтение больших наборов данных превращается в очередь.\n- Бэкапы и восстановление становятся вопросом непрерывности бизнеса, если пропускная способность ограничена.

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

Фундамент соединений: PCIe и CXL простыми словами

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

PCIe: скоростная магистраль внутри сервера

PCIe (Peripheral Component Interconnect Express) — основной внутренний интерфейс для подключения:\n\n- NIC и сетевых карт\n- SSD и контроллеров хранения\n- GPU и других ускорителей\n- DPUs/Smart NIC

Полезная аналогия: PCIe — это добавление полос на шоссе. Новые поколения PCIe увеличивают скорость на полосу, а более широкие линии (x8, x16) дают большую общую пропускную способность. Для операторов облаков это напрямую влияет на скорость обмена данными между вычислениями и периферией.

Силикон Marvell часто оказывается на одном конце таких PCIe-подключений — внутри NIC, DPU, контроллера хранения или компонентов рядом с коммутатором — поэтому возможности PCIe могут стать либо ограничителем, либо драйвером апгрейда.

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

CXL (Compute Express Link) строится поверх физического уровня PCIe, но добавляет новые модели совместного использования памяти с меньшими накладными расходами. Проще говоря, CXL помогает серверам обращаться к внешним ресурсам (расширение памяти или пул памяти) почти как к локальной памяти, а не к удалённому устройству.

Практические последствия для дизайна облака

Преимущества не только в «скорее». PCIe и CXL дают:\n\n- Более гибкий дизайн систем: комбинируйте вычисления, сеть и хранение как блоки\n- Лучшее использование ресурсов: уменьшение «заблокированных» ресурсов (например, память в одном сервере, когда в другом её не хватает)\n- Плавные апгрейды: новые карты и контроллеры легче вставляются в существующие семейства серверов

Стандарты соединений редко попадают в заголовки, но они сильно влияют на скорость внедрения улучшенных сетей, хранилищ и ускорений.

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

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

Что на самом деле означает «пользовательское»

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

Частые примеры ускорения, которые вы реально заметите

Категории, которые часто встречаются в дата-центрах:\n\n- Помощники обработки пакетов: парсинг заголовков, стёринг потоков, формирование трафика и применение политик на скорости линии.\n- Ускорение безопасности: крипто (IPsec/TLS), управление ключами и inline-инспекция, которые иначе отнимали бы CPU.\n- Ускорение хранения: erasure coding, сжатие, дедупликация, помощь в расчёте паритета и контрольных сумм — особенно там, где важны пропускная способность и предсказуемая латентность.\n- Видео/медиа: транскодирование, упаковка и подготовка контента для стриминга.\n- AI-инференс: не всегда крупные тренировочные ускорители — иногда небольшие движки для lookup’ов эмбеддингов, препроцессинга/постпроцессинга или сервисов модели.

Как компании адаптируют чипы под нагрузки

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

Компромисс: эффективность на ватт vs гибкость

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

Питание и эффективность: больше работы на ватт

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

Почему «разгрузка» экономит энергию

Универсальные CPU гибки, но не всегда эффективны в повторяющихся инфраструктурных задачах: обработке пакетов, шифровании, протоколах хранения или телеметрии. Назначенный силикон (smart NIC/DPUs, коммутаторы, контроллеры хранения) выполняет эти задачи с меньшим числом циклов и меньшими потерями.

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

Охлаждение и плотность влияют на выбор чипов

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

Как проверять заявления об эффективности

Цифры эффективности легко рекламировать и сложно сравнивать. При виде «лучше по ватту» смотрите на:\n\n- Контекст измерения: пропускная способность, целевые латентности, размер пакетов и включённые функции (например, шифрование включено/выключено)\n- Границы системы: только чип, полная карта или влияние на весь сервер\n- Поведение на нагрузке: эффективность при 20–40% загрузки часто важнее, чем при пике\n- Сравнимые базисы: одинаковая нагрузка, поколение CPU, похожая конфигурация NIC/коммутатора

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

Безопасность и надёжность, встроенные в инфраструктурный силикон

Облачные провайдеры делят физические машины между многими клиентами, поэтому безопасность нельзя «добавлять потом». Много чего обеспечивается уже на уровне чипа — внутри smart NIC/DPUs, сетевого и коммутационного силикона, контроллеров хранения — где аппаратная разгрузка может применять защиту на полной скорости линии.

Аппаратный корень доверия и secure boot (цепочка «только доверенный код выполняется»)

Большинство инфраструктурных чипов включает аппаратный корень доверия: небольшую неизменяемую логику и ключи, которые проверяют прошивки до старта. С secure boot чип проверяет криптографические подписи прошивки (а иногда и компонентов загрузки хоста), отказываясь запускать изменённый или неизвестный код.

Это важно, потому что скомпрометированный DPU или контроллер хранения могут оказаться «между» вашими серверами и сетевой/хранилищной тканью. Secure boot снижает риск скрытого сохранения доступа на этом уровне.

Inline-шифрование для данных в пути и в покое

Шифрование часто аппаратно ускоряется, чтобы не съедать ресурсы CPU:\n\n- Данные в пути: DPUs и smart NIC могут разгружать обработку IPsec/TLS и управление ключами, сохраняя высокую пропускную способность.\n- Данные в покое: силикон хранения может выполнять inline-шифрование при записи и расшифровку при чтении, интегрируясь в NVMe-путь без превращения каждой операции I/O в тяжёлую задачу для CPU.

Поскольку это inline, безопасность не обязательно означает замедление сетей хранения.

Изоляция между арендаторами в общей инфраструктуре

Мультиарендные облака зависят от чёткого разделения. Инфраструктурные чипы помогают обеспечивать изоляцию аппаратными очередями, защитой памяти, виртуальными функциями и применением политик — так трафик или запросы одного арендатора не могут «заглянуть» в данные другого. Это особенно важно, когда DPUs управляют виртуальной сетью и когда PCIe-устройства шарятся между нагрузками.

Наблюдаемость, которая выявляет проблемы быстрее

Надёжность — это не только «безотказность», но и более быстрая детекция и восстановление. Многие дизайны включают счётчики телеметрии, отчёты об ошибках, трассировку пакетов и метрики здоровья, которые команды облака интегрируют в системы мониторинга. Когда что‑то идёт не так (потери, всплески латентности, ошибки линка, циклы повторов), эти встроенные сигналы помогают быстро локализовать, в чём проблема — в коммутации, DPU или контроллере хранения — сокращая время восстановления и повышая доступность.

Пример end-to-end: как запрос в облаке становится быстрее

Представьте простое действие: вы открываете приложение для покупок и нажимаете «Посмотреть историю заказов». Один запрос проходит через множество систем — и на каждом шаге есть шанс задержки.

Шаги: запрос → база → ответ

1. Запрос попадает на край облака и балансировщик. Пакет направляют на здоровый сервер приложения.\n\n2. Он достигает хоста приложения. Традиционно хостовый CPU занимается «водопроводом»: шифрование, правила файрвола, виртуальная сеть и управление очередями.\n\n3. Приложение обращается к базе. Запрос проходит по сети дата-центра к кластеру БД, затем достаёт данные из хранилища.\n\n4. Ответ возвращается тем же путём. Результаты упаковывают, шифруют и отправляют обратно на телефон.

Где прячется латентность

• Сетевая обработка и хопы: каждый хоп добавляет микрозадержку, а большая часть стоимости может лежать в пер-пакетной работе — маршрутизация, туннелирование, проверка ACL.\n- I/O хранилища: даже с быстрым NVMe задержки возникают при переполнении очередей, неэффективной работе с метаданными или когда путь хранения отнимает CPU.\n- Конкуренция за CPU: если одни и те же ядра обслуживают и приложение, и инфраструктуру (сеть, безопасность, стек хранения), всплески трафика создают эффект «шумного соседа».

Как разгрузка и ускорение убирают узкие места

Smart NIC/DPUs и специализированный силикон (включая решения от Marvell) переносят повторяющуюся работу с универсальных CPU:\n\n- Сетевая разгрузка обрабатывает туннелирование, коммутацию/маршрутизацию и применение политик ближе к проводу.\n- Криптоускорение снижает стоимость TLS/IPsec, чтобы шифрование не ело циклы приложений.\n- Ускорение хранения улучшает работу NVMe-очередей, задачи защиты данных и освобождает хост от тяжёлой учётной работы I/O.

Что реально улучшается

• Ниже хвостовая латентность: реже происходят «редкие, но болезненные» медленные запросы при всплесках трафика.\n- Больше пропускной способности: больше запросов обслуживается на каждом сервере, потому что CPU занят логикой приложения.\n- Больше предсказуемости: производительность стабильнее, так как инфраструктурные задачи изолированы и детерминированы.

Как команды облачных операторов выбирают силикон для своей инфраструктуры

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

Начинайте с нагрузки, а не с даташита

Команды обычно сопоставляют свои основные узкие места с конкретными функциями: обработка пакетов и безопасность в сетевом пути, трансляция и защита данных в I/O пути, или примитивы сжатия/крипто/AI в блоках ускорения. Ключевой вопрос: можно ли перенести задачу без нарушения программной модели. Если платформа опирается на определённые фичи Linux, поведение виртуального свитча или семантику хранения, чип должен это поддерживать.

Вопросы к вендору (перед PoC)

Спросите про:\n\n- Набор рабочих нагрузок, под которые силикон оптимизирован сегодня (и чего следует избегать)\n- Стабильность дорожной карты: совместимость с последующими пиновыми/платовыми решениями, окна поддержки прошивок и график поставки фич\n- Совместимость: драйверы, поддержка гипервизора, интеграции с Kubernetes/CNI и телеметрией\n- Поставки и жизненный цикл: сроки поставки, стратегия второго источника и долгосрочная доступность

Как команды оценивают варианты

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

Как избежать зависимости от одного вендора

Команды уменьшают риски, предпочитая стандарты (Ethernet, NVMe, PCIe/CXL), хорошо документированные API и совместимые инструменты управления. Даже при использовании фирменных функций (включая возможности от Marvell и конкурентов) стараются держать контрольные плоскости переносимыми, чтобы железо менялось без полной переделки платформы.

То же самое касается софта: при создании сервисов для этой инфраструктуры полезно сохранять переносимость архитектуры. Такие платформы, как Koder.ai, помогают ускорить прототипирование веб-бэкендов (Go + PostgreSQL) и React-фронтендов через чат‑управляемый рабочий процесс, при этом позволяя экспортировать исходники и деплоить в соответствие с требованиями облака и комплаенса.

Что дальше для силикона инфраструктуры данных

Силикон инфраструктуры перемещается от «полезного ускорителя» к базовой прослойке. По мере того как всё больше сервисов становятся чувствительными к латентности (AI-инференс, аналитика в реальном времени, inline-инспекция безопасности), чипы, которые эффективно обрабатывают сеть, хранение и перемещение данных, будут важны не меньше CPU.

Высокая пропускная способность станет нормой

Высокоскоростные сети перестают быть нишевой опцией — они становятся ожиданием. Это будет подталкивать коммутацию Ethernet, обработку пакетов, DPU и Smart NIC к более быстрым портам, меньшей латентности и лучшему контролю перегрузок. Вендоры, включая Marvell, будут конкурировать за то, сколько работы можно вынести в железо (шифрование, телеметрия, виртуальная коммутация) без увеличения операционной сложности.

CXL и компонуемая инфраструктура становятся практичными

PCIe и CXL будут всё больше включать дисагрегацию: пул памяти и ускорителей, чтобы стойки можно было «снабжать» под рабочую нагрузку. Открытая возможность для силикона — это не только CXL PHY, но и контроллеры, коммутация и прошивки, которые делают пул ресурсов предсказуемым, безопасным и наблюдаемым для команд облака.

Больше пользовательского силикона внутри крупных платформ

Крупные провайдеры хотят дифференциации и тесной интеграции между сетевыми чипами, контроллерами хранения и пользовательскими ускорителями. Ожидайте больше полусоответных программ, где стандартный строительный блок (SerDes, Ethernet-коммутатор, NVMe) дополняют платформенными фичами, инструментами деплоя и длительными окнами поддержки.

На что обращать внимание при оценке частей следующего поколения

Ведущая метрика будет «работа на ватт», особенно когда лимиты по питанию сдерживают рост. Функции безопасности переместятся ближе к пути данных (inline-шифрование, secure boot, аттестация). И, наконец, важны пути апгрейда: можно ли принять новую пропускную способность, ревизии CXL или возможности разгрузки, не перепроектируя всю платформу и не ломая совместимость с существующими стойками?