Узнайте, как силикон Marvell поддерживает сетевые и сторидж‑решения облаков и специализированное ускорение — обеспечивая более быстрые и энергоэффективные дата‑центры за кулисами.
Большинство людей думают, что «облако» — это просто серверы. На деле облачный дата-центр — это огромная система для перемещения, хранения и защиты данных на высокой скорости. Силикон для инфраструктуры данных — это набор специализированных чипов, которые выполняют тяжёлые операции с данными, освобождая основные CPU.
Marvell концентрируется на этом «среднем» слое: чипах, которые связывают вычисления с сетью и хранилищем, ускоряют типичные задачи дата-центра и поддерживают предсказуемое поведение под нагрузкой.
Если представить стойку облака сверху вниз, устройства Marvell часто находятся:
Это не «приложения» и не «сервера» в привычном смысле — это аппаратные кирпичики, которые позволяют тысячам серверов вести себя как единое целое.
Когда силикон инфраструктуры делает своё дело, вы этого не замечаете. Страницы загружаются быстрее, видео буферизуется реже, резервные копии завершаются вовремя — но пользователь никогда не увидит движки аппаратной разгрузки, контроллеры хранения или коммутационную ткань, которые это обеспечивают. Эти чипы тихо уменьшают задержки, освобождают CPU и делают производительность более стабильной.
Роль Marvell легче разделить на три группы:
Это «тихий» силикон, который делает облачные сервисы простыми на поверхности.
Облачные приложения кажутся «software-defined», но физическая работа всё ещё выполняется в стойках серверов, коммутаторов и массивов хранения. По мере роста спроса облака не могут полагаться только на универсальные CPU для каждой задачи без серьёзных ограничений по цене и эффективности.
Обучение и инференс AI перемещают огромные наборы данных внутри дата-центра. Видеопотоки, бэкапы, аналитика и SaaS добавляют постоянную фоновую нагрузку. Даже при доступном вычислении узким местом часто становится перемещение, фильтрация, шифрование и хранение данных с необходимой скоростью.
Большая часть облачного трафика никогда не покидает внутреннюю сеть. Он идёт «с востока на запад» между сервисами: вызовы микросервисов, чтение баз данных, обновления кэша, репликация хранилища и распределённые AI-задачи. Этот внутренний трафик требует предсказуемой латентности и высокой пропускной способности, поэтому больше обработки уходит в аппаратный путь данных.
Электричество и пространство не бесконечны. Если провайдер может разгрузить обработку пакетов, шифрование, сжатие или контрольные суммы хранения на выделенный силикон, CPU тратит меньше времени на накладные операции. Это улучшает:
Вместо масштабирования за счёт добавления универсальных ядер, облачные платформы всё чаще используют назначенные чипы — Smart NIC/DPUs, коммутационный силикон, контроллеры хранения и акселераторы — чтобы снять с CPU повторяющиеся, объёмные инфраструктурные задачи. Результат — облако быстрее и дешевле в эксплуатации, даже по мере роста потребностей в данных.
Серверы облака тратят удивительно много времени на «инфраструктурную работу», а не на запуск вашего приложения. Каждый пакет нужно передать, проинспектировать, залогировать и иногда зашифровать — часто это делает основной CPU. Аппаратная разгрузка переносит эти обязанности на специализированное железо — тут и появляются Smart NIC и DPU, включая решения на базе силикона Marvell.
Smart NIC — сетевая карта, которая делает больше, чем простая отправка/приём: помимо портов Ethernet она содержит дополнительные вычисления (обычно ядра Arm и/или программируемую логику) для выполнения сетевых функций прямо на карте.
DPU (Data Processing Unit) идёт дальше: это выделенный «инфраструктурный компьютер» внутри сервера. DPU обычно сочетает высокопроизводительную сеть, несколько CPU-ядер, аппаратные ускорители (крипто, обработка пакетов) и функции изоляции, чтобы управлять перемещением данных и безопасностью без опоры на хост-CPU.
Практическая модель для запоминания:
Переносятся повторяющиеся, объёмные операции, которые иначе отнимали бы CPU у приложений. Типичные примеры:
Когда CPU «присматривает» за сетью, производительность приложений может прыгать из‑за всплесков трафика, «шумных соседей» или пиков безопасности. Разгрузка помогает:
Физически DPU обычно поставляется в виде PCIe-карты или модуля OCP NIC. Он подключается к:
Концептуально DPU становится «регулировщиком трафика» между сетью и сервером — обрабатывая политики, шифрование и коммутацию, чтобы ОС и CPU хоста могли сосредоточиться на приложениях.
Когда вы открываете приложение или перемещаете данные в облако, ваш запрос обычно не идёт к «серверу» напрямую — он проходит через ткань Ethernet-коммутаторов, которые связывают тысячи серверов так, будто это одна большая машина.
Большинство дата-центров используют дизайн «leaf–spine»:\n\n- Top-of-rack (ToR) / leaf — коммутаторы в каждой стойке, соединённые с серверами этой стойки.\n- Spine — коммутаторы, связывающие все ToR, чтобы любой сервер мог достичь любого другого за предсказуемое число прыжков.
Такой подход сохраняет короткие и стабильные пути, что критично для масштабируемой производительности.
Два числа формируют пользовательский опыт и стоимость:\n\n- Латентность (время прохождения пакета) влияет на интерактивные нагрузки — API, БД, микросервисы и аналитика в реальном времени.\n- Пропускная способность (данные в секунду) важна для массовых переносов — репликация хранилища, бэкапы, стриминг и большие AI-данные.
Операторы стремятся держать латентность стабильной при высокой загрузке каналов и одновременно прокачивать огромные объёмы трафика.
Чип коммутатора делает не только «форвардинг». Он должен:\n\n- Определять назначения (MAC, VLAN и зачастую заголовки маршрутизации/оверлеи) на скорости линии.\n- Буферизовать и планировать трафик, чтобы не дать заторам распространяться по сети.\n- Применять QoS, чтобы чувствительные к латентности потоки не тонули в фоне.\n- Поддерживать телеметрию и механизмы контроля перегрузок, помогающие операторам настраивать производительность.
Поставщики вроде Marvell разрабатывают силикон, оптимизированный на предсказуемую работу на очень высоких скоростях.
Переход с 25/100G на 200/400/800G — это не просто числа. Более высокие скорости означают:\n\n- Больше виртуальных машин в стойке без перерасхода сети\n- Быстрый доступ к хранилищу (особенно для разорванного/сеть-ориентированного NVMe)\n- Короткие циклы обучения AI за счёт более стабильной подачи данных к GPU
В результате сеть дата-центра ощущается не как «провода», а как общий ресурс для всех рабочих нагрузок.
Когда говорят о производительности облака, часто представляют CPU и GPU. Но огромную часть скорости и надёжности решает силикон хранения между флеш-дисками и остальной системой. Эта прослойка — обычно контроллер хранения — управляет тем, как данные записываются, читаются, проверяются и восстанавливаются.
Контроллер — это дирижёр для постоянных данных. Он разбивает входящие записи на управляемые блоки, планирует чтения так, чтобы «горячие» данные возвращались быстро, и регулярно выполняет проверки целостности, чтобы битовые ошибки не превратились в порчу файлов.
Он также ведёт неприглядную учётную работу, делающую хранение предсказуемым в масштабе: маппинг логических блоков на физические, балансировка износа для продления срока службы накопителей и стабилизация латентности при одновременной нагрузке многих приложений.
NVMe (Non-Volatile Memory Express) — протокол, созданный для быстрого флеш-хранилища. Он стал распространённым, потому что снижает накладные расходы и поддерживает параллельные очереди запросов — то есть много операций может находиться «в полёте» одновременно, что хорошо подходит для облачных сценариев с тысячами мелких операций.
Для провайдеров облаков NVMe важен не столько пиковой пропускной способностью, сколько стабильной низкой латентностью под нагрузкой — это то, что делает приложения отзывчивыми.
Современные контроллеры часто включают аппаратные функции, которые в противном случае отнимали бы CPU:\n\n- Шифрование/расшифровка для защиты данных в покое с минимальным падением производительности\n- Сжатие для хранения большего объёма и передачи меньшего объёма (полезно при ограниченной пропускной способности)\n- Паритет и помощь при восстановлении (erasure coding) для устойчивости к отказам и более быстрой реконструкции данных
Хранилище не изолированная подсистема — оно формирует поведение приложений:\n\n- Базы данных зависят от быстрых и предсказуемых записей для транзакций и журналов.\n- Пайплайны аналитики могут простаивать, когда чтение больших наборов данных превращается в очередь.\n- Бэкапы и восстановление становятся вопросом непрерывности бизнеса, если пропускная способность ограничена.
Коротко: силикон хранения превращает сырый флеш в надёжную, высокопроизводительную облачную инфраструктуру.
При апгрейде серверов провайдеры меняют не только CPU. Им нужна «связующая ткань», которая позволит CPU общаться с сетевыми картами, хранилищем и ускорителями без полной переработки системы. Поэтому стандарты вроде PCIe и CXL важны: они сохраняют совместимость, уменьшают риск апгрейда и помогают дата-центрам масштабироваться предсказуемо.
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 (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 дают строительные блоки — сеть, безопасность, интерфейсы хранения — чтобы «пользовательская» часть могла фокусироваться на специфичных горячих путях.
Фиксированная логика обычно выигрывает по эффективности на ватт и детерминированности, но её сложнее перенастроить под другие задачи. Программируемые решения легче эволюционировать, но потребляют больше энергии и могут уступать по пиковому быстродействию. Лучшие архитектуры смешивают оба подхода: гибкие контрольные плоскости с аппаратными быстродействующими путями там, где это критично.
Энергия часто является реальным лимитом в дата-центре — не количество серверов, которые вы можете купить, а сколько электроэнергии вы можете подать и отвести в виде тепла. Когда площадка достигает лимита по мощности, единственный путь роста — получать больше полезной работы с каждого ватта.
Универсальные CPU гибки, но не всегда эффективны в повторяющихся инфраструктурных задачах: обработке пакетов, шифровании, протоколах хранения или телеметрии. Назначенный силикон (smart NIC/DPUs, коммутаторы, контроллеры хранения) выполняет эти задачи с меньшим числом циклов и меньшими потерями.
Энергетический выигрыш часто опосредован: если разгрузка снижает использование CPU, вы можете запускать ту же нагрузку с меньшим числом активных ядер, на более низких частотах или на меньшем количестве серверов. Это также уменьшает нагрузку на память и PCIe, дополнительно сокращая энергопотребление.
Каждый ватт превращается в тепло. Больше тепла — быстрее вращение вентиляторов, сильнее требования к системам охлаждения и жёсткая планировка на уровне стоек. Высокая плотность привлекательна, но только если вы можете её охлаждать. Поэтому выбор компонентов важен не только по пропускной способности: компонент с меньшим потреблением (или сохраняющий эффективность под нагрузкой) позволяет операторам упаковывать больше мощности в ту же площадь без горячих точек.
Цифры эффективности легко рекламировать и сложно сравнивать. При виде «лучше по ватту» смотрите на:\n\n- Контекст измерения: пропускная способность, целевые латентности, размер пакетов и включённые функции (например, шифрование включено/выключено)\n- Границы системы: только чип, полная карта или влияние на весь сервер\n- Поведение на нагрузке: эффективность при 20–40% загрузки часто важнее, чем при пике\n- Сравнимые базисы: одинаковая нагрузка, поколение CPU, похожая конфигурация NIC/коммутатора
Самые правдоподобные заявления связывают ватты с конкретной, повторяемой рабочей нагрузкой и показывают изменение на уровне сервера или стойки, а не только в спецификации чипа.
Облачные провайдеры делят физические машины между многими клиентами, поэтому безопасность нельзя «добавлять потом». Много чего обеспечивается уже на уровне чипа — внутри smart NIC/DPUs, сетевого и коммутационного силикона, контроллеров хранения — где аппаратная разгрузка может применять защиту на полной скорости линии.
Большинство инфраструктурных чипов включает аппаратный корень доверия: небольшую неизменяемую логику и ключи, которые проверяют прошивки до старта. С secure boot чип проверяет криптографические подписи прошивки (а иногда и компонентов загрузки хоста), отказываясь запускать изменённый или неизвестный код.
Это важно, потому что скомпрометированный DPU или контроллер хранения могут оказаться «между» вашими серверами и сетевой/хранилищной тканью. Secure boot снижает риск скрытого сохранения доступа на этом уровне.
Шифрование часто аппаратно ускоряется, чтобы не съедать ресурсы CPU:\n\n- Данные в пути: DPUs и smart NIC могут разгружать обработку IPsec/TLS и управление ключами, сохраняя высокую пропускную способность.\n- Данные в покое: силикон хранения может выполнять inline-шифрование при записи и расшифровку при чтении, интегрируясь в NVMe-путь без превращения каждой операции I/O в тяжёлую задачу для CPU.
Поскольку это inline, безопасность не обязательно означает замедление сетей хранения.
Мультиарендные облака зависят от чёткого разделения. Инфраструктурные чипы помогают обеспечивать изоляцию аппаратными очередями, защитой памяти, виртуальными функциями и применением политик — так трафик или запросы одного арендатора не могут «заглянуть» в данные другого. Это особенно важно, когда DPUs управляют виртуальной сетью и когда PCIe-устройства шарятся между нагрузками.
Надёжность — это не только «безотказность», но и более быстрая детекция и восстановление. Многие дизайны включают счётчики телеметрии, отчёты об ошибках, трассировку пакетов и метрики здоровья, которые команды облака интегрируют в системы мониторинга. Когда что‑то идёт не так (потери, всплески латентности, ошибки линка, циклы повторов), эти встроенные сигналы помогают быстро локализовать, в чём проблема — в коммутации, DPU или контроллере хранения — сокращая время восстановления и повышая доступность.
Представьте простое действие: вы открываете приложение для покупок и нажимаете «Посмотреть историю заказов». Один запрос проходит через множество систем — и на каждом шаге есть шанс задержки.
Smart NIC/DPUs и специализированный силикон (включая решения от Marvell) переносят повторяющуюся работу с универсальных CPU:\n\n- Сетевая разгрузка обрабатывает туннелирование, коммутацию/маршрутизацию и применение политик ближе к проводу.\n- Криптоускорение снижает стоимость TLS/IPsec, чтобы шифрование не ело циклы приложений.\n- Ускорение хранения улучшает работу NVMe-очередей, задачи защиты данных и освобождает хост от тяжёлой учётной работы I/O.
Операторы не выбирают чипы потому, что они просто «быстрее» на бумаге — они выбирают их, когда работа большая, повторяющаяся и стоит превращения в железо. Специализированный силикон особенно ценен в масштабе (миллионы похожих запросов), когда требования к производительности предсказуемы и когда небольшие улучшения складываются в заметную экономию на парке серверов.
Команды обычно сопоставляют свои основные узкие места с конкретными функциями: обработка пакетов и безопасность в сетевом пути, трансляция и защита данных в I/O пути, или примитивы сжатия/крипто/AI в блоках ускорения. Ключевой вопрос: можно ли перенести задачу без нарушения программной модели. Если платформа опирается на определённые фичи Linux, поведение виртуального свитча или семантику хранения, чип должен это поддерживать.
Спросите про:\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, будут конкурировать за то, сколько работы можно вынести в железо (шифрование, телеметрия, виртуальная коммутация) без увеличения операционной сложности.
PCIe и CXL будут всё больше включать дисагрегацию: пул памяти и ускорителей, чтобы стойки можно было «снабжать» под рабочую нагрузку. Открытая возможность для силикона — это не только CXL PHY, но и контроллеры, коммутация и прошивки, которые делают пул ресурсов предсказуемым, безопасным и наблюдаемым для команд облака.
Крупные провайдеры хотят дифференциации и тесной интеграции между сетевыми чипами, контроллерами хранения и пользовательскими ускорителями. Ожидайте больше полусоответных программ, где стандартный строительный блок (SerDes, Ethernet-коммутатор, NVMe) дополняют платформенными фичами, инструментами деплоя и длительными окнами поддержки.
Ведущая метрика будет «работа на ватт», особенно когда лимиты по питанию сдерживают рост. Функции безопасности переместятся ближе к пути данных (inline-шифрование, secure boot, аттестация). И, наконец, важны пути апгрейда: можно ли принять новую пропускную способность, ревизии CXL или возможности разгрузки, не перепроектируя всю платформу и не ломая совместимость с существующими стойками?
Marvell в основном работает на «путях данных» в облачных дата-центрах: сеть (NIC/DPUs, чипы коммутаторов), контроллеры хранения (NVMe и сопутствующие функции) и специализированные блоки ускорения (крипто, обработка пакетов, сжатие, телеметрия). Цель — перемещать, защищать и управлять данными в масштабе, не нагружая основные CPU.
Потому что универсальные CPU гибкие, но неэффективны для повторяющихся, высокообъемных инфраструктурных задач — обработка пакетов, шифрование, работа с протоколами хранения. Перенос таких задач на специализированный силикон даёт:
Smart NIC — это сетевая карта, которая делает больше, чем просто отправляет и принимает пакеты: на ней есть дополнительные вычисления (часто ядра Arm или программируемая логика) для выполнения сетевых функций прямо на карте.
DPU (Data Processing Unit) идёт дальше: это «инфраструктурный компьютер» внутри сервера, сочетающий высокоскоростную сеть, несколько CPU-ядер, аппаратные ускорители (крипто, обработка пакетов) и механизмы изоляции, чтобы управлять движением данных и безопасностью без опоры на хост-CPU.
Часто разгружают повторяющиеся операции, которые съедают CPU и возникают в больших объемах. Примеры:
«East–west» — это трафик внутри дата-центра: вызовы между микросервисами, чтение из БД, обновления кэша, репликация хранилища и распределённые AI-работы. Такой внутренний трафик требует предсказуемой латентности и большой пропускной способности, поэтому больше обработки переносится в NIC/DPUs и чипы коммутаторов.
В гипермасштабных сетях обычно используется топология «leaf–spine»:
Чипы коммутаторов должны форвардить пакеты, буферизовать и расписать трафик, обеспечивать QoS и давать телеметрию — на линейной скорости.
Контроллер хранения — это прослойка между флешем и остальной системой, которая делает хранение быстрым и надёжным:
Многие контроллеры ускоряют , и помощь при восстановлении/паритете (erasure coding), чтобы хранилище не забирало CPU хоста.
NVMe создан для флеша: у него низкие накладные расходы и высокая параллелизация (много очередей и операций одновременно). Для облаков важнее не только пиковой пропускной способности, но и стабильно низкая латентность под нагрузкой — когда тысячи мелких I/O выполняются одновременно.
PCIe — это внутренний высокоскоростной интерфейс, связывающий NIC, SSD, GPU и ускорители. CXL использует физический слой PCIe, но добавляет более эффективные способы совместного использования ресурсов памяти.
Практически PCIe/CXL дают:
Запрашивайте доказательства на реалистичных рабочих нагрузках и учитывайте операционные требования:
Это снижает нагрузку на CPU и делает задержки более предсказуемыми.
Часто решает не столько лучшая на бумаге производительность, сколько сложность интеграции и эксплуатации.
