Разбираем, как кремний Marvell незаметно обеспечивает облачные сети, высокоскоростное хранение и кастомные ускорители в дата-центрах.
Облако кажется «чистым» сервисом: нажали кнопку — получили виртуальную машину, хранилище или базу данных. Но под этим удобством работает слой специализированных микросхем, который редко видят конечные пользователи. Его часто называют data infrastructure silicon — «кремний для инфраструктуры данных»: чипы, которые ускоряют передачу пакетов, доступ к данным и инфраструктурные функции (безопасность, виртуализация, шифрование, сжатие).
Этот кремний не «рисует» интерфейсы и не запускает ваши приложения напрямую. Его задача — сделать так, чтобы облачный сервис был быстрым и предсказуемым при высокой нагрузке: меньше задержка, выше пропускная способность, стабильнее время ответа, проще масштабирование.
По сути, это аппаратная основа для трёх критичных подсистем:
Даже если CPU «мощный», производительность может ограничиваться перегруженной сетью между сервисами, задержками при доступе к данным, а также накладными расходами на шифрование, маршрутизацию, фильтрацию трафика и изоляцию арендаторов.
Именно поэтому в современных ЦОД появляются DPU, SmartNIC, специализированные контроллеры хранения и пользовательские ускорители — они разгружают хост и повышают эффективность.
Дальше разберёмся последовательно: как устроен сетевой тракт в облаке, что такое сетевой кремний (коммутаторы и фабрики), как DPU делают offload сетевых и security‑функций, почему NVMe и контроллеры SSD важны для хранилища, и когда имеет смысл идти в кастомные ASIC под конкретный сервис.
Облако кажется «про CPU»: запустили виртуальные машины — и всё работает. На практике производительность часто упирается не в вычисления, а во ввод‑вывод: сеть, хранение, шифрование, балансировку, телеметрию. Эти задачи съедают ядра, создают очереди и делают задержку непредсказуемой.
CPU хороши универсальностью, но плохо масштабируются, когда нужно обрабатывать миллионы мелких сетевых событий в секунду: пакеты, прерывания, проверки правил, копирование данных между буферами. GPU ускоряют параллельные вычисления, но не предназначены для «мелкой» сетевой работы и не устраняют узкие места на пути данных от сети к приложению.
Проблема в том, что многие сервисы упираются в pps (packets per second) и в стоимость каждого пакета — в тактах CPU, памяти и контекстных переключениях. Чем выше нагрузка, тем больше «служебной» работы, и тем меньше остаётся ресурсов на бизнес‑логику.
Для микросервисов, баз данных, кэшей и очередей сообщений важны не только гигабиты в секунду, но и стабильная задержка. Любые «хвосты» (p99/p999) превращаются в тайм‑ауты, ретраи и каскадные перегрузки. Поэтому облаку нужно оборудование, которое обеспечивает высокий throughput без скачков latency.
Специализированные чипы — сетевой кремний, DPU/SmartNIC, контроллеры хранения, ускорители шифрования — берут на себя повторяющиеся операции:
Результат — разгрузка CPU и более предсказуемые SLA: меньше джиттера, меньше конкуренции за кэш/память, выше плотность размещения (больше клиентов на тот же сервер). Именно поэтому производители вроде Marvell делают акцент на «ускорении пути данных», а не только на росте частоты процессоров.
Чтобы понять, почему «сетевой кремний» так важен, полезно представить путь одного пакета данных в облаке. В реальности он проходит несколько «переводчиков» и «развязок», и на каждом шаге можно выиграть или потерять миллисекунды.
Упрощённо это выглядит так:
приложение на сервере
→ NIC/DPU (сетевая карта или DPU)
→ Top-of-Rack коммутатор
→ фабрика сети (несколько уровней коммутаторов)
→ коммутатор стойки назначения
→ NIC/DPU
→ приложение
NIC принимает и отправляет пакеты по физическому линку (медь или оптика), коммутатор решает «куда дальше», а фабрика сети обеспечивает масштабирование: тысячи серверов могут общаться параллельно, не «забивая» один общий канал.
Задержки чаще всего появляются не «в кабеле», а в ожидании:
Поэтому в облаке так ценятся решения, которые лучше управляют очередями, быстрее обрабатывают пакеты и точнее сигнализируют о перегрузках — это напрямую влияет на tail‑latency и стабильность сервисов.
Если упростить, «облако» держится на том, насколько быстро и предсказуемо данные проходят через сеть. За это отвечает сетевой кремний: чипы в коммутаторах, оптических модулях и специализированных сетевых процессорах, которые обрабатывают трафик на скоростях, недоступных обычным CPU.
Внутри коммутаторов и сетевых устройств такие чипы выполняют несколько ключевых задач:
Для облачного провайдера это означает меньше «слепых зон» и более ровную производительность в пиковые моменты.
Высокая плотность портов позволяет подключать больше серверов или аплинков в 1U/2U, экономя место и энергию на стойку. А переход на более быстрые скорости Ethernet (и соответствующую оптику/кабели) снижает число уровней агрегации и упрощает топологию: меньше промежуточных устройств — меньше задержек и точек отказа.
Основной объем трафика в облаке — это east‑west: обмен между серверами (микросервисы, кэш, базы данных, storage‑трафик). Здесь критичны задержка, буферы и QoS.
Второй важный класс — связь между площадками: репликация данных, резервирование, распределенные кластеры. Тут уже на первый план выходят пропускная способность на аплинках, надежность и предсказуемость при длинных «плечах».
DPU (Data Processing Unit) часто путают с «умной сетевой картой», но разница принципиальная. Обычная NIC в основном передает пакеты и делает базовые операции (например, checksum offload). DPU — это отдельный вычислительный узел на плате: сетевые порты + собственные ядра (ARM/похожие), память и блоки ускорения. Он берёт на себя часть «инфраструктурных» задач, которые иначе выполнялись бы CPU хоста.
Главная идея — вынести сетевые и I/O‑функции из критического пути приложений, чтобы серверные CPU занимались бизнес‑логикой.
Типичные примеры:
В облаке критична изоляция арендаторов: каждому нужны гарантии, что сосед не «съест» полосу, не обойдет политики и не повлияет на задержки. DPU помогает вынести enforcement ближе к сети: применять правила, квоты и телеметрию на уровне инфраструктуры, не превращая CPU в узкое место.
Практический эффект — более предсказуемая производительность под сетевой и storage‑нагрузкой, меньше потерь на софтверные datapath и проще масштабирование сервисов, где безопасность и виртуализация включены по умолчанию.
В облаке «диск» редко находится рядом с вычислениями. Данные живут в распределенных системах хранения, а доступ к ним идет по сети — так проще масштабировать емкость, повышать отказоустойчивость и обслуживать разные сервисы на общей инфраструктуре.
Storage fabric — это сеть, специально «заточенная» под операции ввода‑вывода. Классический пример — NVMe over Fabrics (NVMe‑oF): команды NVMe (как у локального SSD) передаются по сети, чаще всего поверх Ethernet (RoCEv2) или TCP.
Практический смысл простой: приложение получает почти «локальные» задержки и высокие IOPS, но при этом физические SSD можно держать в отдельных хранилищных узлах и масштабировать независимо от CPU.
Чтобы NVMe‑oF действительно работал быстро, важны специализированные компоненты на обоих концах тракта:
В результате CPU меньше тратит времени на «обслуживание» I/O, а система может выдерживать больше мелких операций (типично для баз данных и очередей сообщений).
Если сеть и хранилище проектируются «по отдельности», возникают узкие места: перекос по пропускной способности, лишние копирования данных, неравномерные задержки. Когда же параметры согласованы — скорость линий, глубина очередей, механизмы QoS и изоляции — облако получает предсказуемую производительность: от стабильных p99‑задержек до лучшего использования SSD и сетевых портов. Это критично для многопользовательских сред, где соседние нагрузки не должны мешать друг другу.
Когда говорят «быстрый SSD», часто имеют в виду не только память NAND, но и контроллер — маленький «диспетчер», который превращает сырую флеш‑память в предсказуемое хранилище для облака. Именно он во многом определяет задержку, стабильность под нагрузкой и ресурс накопителя.
Контроллер управляет тем, что пользователь не видит, но постоянно ощущает в виде скорости и надежности:
Для облака критичны не рекорды в тестах, а стабильная задержка и ровная производительность при длительной смешанной нагрузке (чтение/запись, случайный доступ, параллельные запросы). Контроллер, кэширование, алгоритмы сборки мусора и политика обслуживания очередей определяют, будет ли SSD держать заданные SLO — или внезапно уйдет в «просадку» на фоне фоновых операций.
NVMe ускоряет доступ не только за счет PCIe, но и за счет модели многих очередей: можно параллельно обслуживать запросы от разных потоков и приложений без лишних блокировок. Глубина очередей и эффективность их обработки сокращают накладные расходы и помогают держать низкую задержку даже при большом числе операций в секунду — что особенно заметно в базах данных и распределенном хранилище.
Иногда «быстрее серверов» уже не сделать простым добавлением CPU. В облаке есть задачи, где основная нагрузка — это не вычисления общего назначения, а повторяющиеся операции над потоками данных: шифровать, сжимать, искать, фильтровать, прогонять трафик через правила безопасности. В таких местах и появляется custom acceleration — аппаратные блоки, заточенные под конкретный тип работы.
Это не «магический чип», а подход: часть логики сервиса переносится в специализированный кремний (ASIC или ускоритель в составе сетевого/хранительного решения), который выполняет узкий набор операций быстрее и предсказуемее, чем CPU.
Главный признак, что стандартных чипов недостаточно: нагрузка хорошо параллелится, повторяется миллионы раз и упирается в задержку/пропускную способность, а не в «умные» ветвления кода. Тогда перенос функции в железо снижает latency, экономит ядра CPU и упрощает масштабирование.
На практике чаще всего встречаются такие «кирпичики»:
В итоге кастомные ускорители помогают облаку расти не только «вширь» (больше серверов), но и «вглубь» — повышая эффективность каждого узла за счет специализированного кремния.
Пользовательский ASIC — это чип, который проектируют под конкретную задачу облачного провайдера: например, ускорить шифрование трафика, обработку телеметрии, балансировку, сжатие или работу с хранилищем. Смысл не в «самом быстром чипе вообще», а в том, чтобы убрать узкое место именно в вашем сервисе и сделать это экономично по энергии и площади в стойке.
Процесс обычно начинается с приземлённого вопроса: где именно теряются миллисекунды или гигабиты в секунду и сколько это стоит бизнесу. Дальше формируется спецификация: входы/выходы, пропускная способность, задержка, требования по безопасности, совместимость с существующей сетью и ПО.
Затем идут верификация и моделирование: будущий блок «прогоняют» на тестах и сценариях нагрузки ещё до производства, чтобы не получить дорогостоящую ошибку в кремнии. После этого — производство на фабрике, упаковка (package), тестирование и отбраковка. На практике важный этап — подготовка софта, драйверов и телеметрии: без них даже отличный ASIC сложно внедрить и эксплуатировать.
Чем больше ускорения «зашито» в железо, тем выше эффективность и ниже задержки — но меньше гибкость. Основные развилки такие:
Полный «чистый лист» делают редко. Чаще берут проверенные IP‑блоки (PCIe, Ethernet, SerDes, криптография, контроллеры памяти) и добавляют уникальную логику под свой сервис. Такой полузаказной путь сокращает риски, ускоряет вывод в прод и упрощает сертификацию, сохраняя главное: ускорение именно там, где оно даёт измеримый эффект для облака.
Когда облачный провайдер выбирает сетевые, DPU‑ или storage‑чипы (в том числе семейства Marvell), решает не «какой чип быстрее», а «какой даст нужный сервисный уровень при приемлемой стоимости эксплуатации». Для этого инженеры смотрят на несколько групп метрик.
Пропускная способность важна, но сама по себе мало что говорит. Для сети дополнительно измеряют PPS (packets per second) — сколько пакетов в секунду обрабатывает устройство на мелких пакетах, где чаще всего «вылезает» узкое место.
Для хранилища аналог — IOPS и latency distribution: не только средняя задержка, но и хвосты (p95/p99). В облаке «длинные хвосты» часто ощущаются сильнее, чем прирост средней скорости.
В ЦОД электричество и охлаждение — это постоянные расходы. Поэтому сравнивают эффективность вроде Вт/Гбит/с (для сети) или Вт/IOPS (для хранилища).
Нюанс: важен не только TDP чипа, но и то, как он ведёт себя под реальными профилями нагрузки — например, при миксах «много мелких запросов» и «редкие пики».
Провайдеру нужны:
Итог: «правильный» кремний — тот, который даёт нужные PPS/IOPS и низкие хвосты задержек при лучшей энергоэффективности и управляемости в масштабе ЦОД.
Переход на специализированный «сетевой» и «хранительный» кремний (коммутаторы, DPU, контроллеры SSD) редко бывает заменой «один к одному». Даже если производительность обещает заметный прирост, основной риск — не скорость, а предсказуемость: совместимость, стабильность и управляемость после включения в боевой контур.
Первый — дефицит компонентов и длинные сроки поставки. В инфраструктуре это превращается в «зоопарк» ревизий: часть стоек на новых платах, часть на старых, разные прошивки и разные ограничения.
Второй — совместимость по мелочам, которые всплывают поздно: версии драйверов и прошивок, поддержка нужных режимов (например, offload‑функций на DPU), особенности работы с оптикой/кабелями и таблицами маршрутизации. Отдельно стоит риск «скрытой сложности»: новая функциональность добавляет новые точки мониторинга и инцидентов.
Третий — сложность внедрения в процессы эксплуатации: кто обновляет firmware, как откатывать изменения, как регламентировать параметры производительности и безопасности.
Начните с пилота на ограниченном сегменте: 1–2 стойки или отдельный кластер под непиковую нагрузку. Обязательны стендовые тесты на «похожем» трафике: измеряйте не только пропускную способность, но и задержки, потери пакетов, хвостовые задержки (p95/p99), влияние на CPU и поведение при отказах.
План миграции делайте поэтапным: сначала наблюдаемость (метрики/логи), затем включение функций ускорения, и только потом — перенос критичных сервисов. На каждом шаге заранее определите критерии успеха и условия отката.
Уточните матрицу совместимости (серверы, NIC, ОС/гипервизор, версии прошивок), жизненный цикл поддержки, доступность запасных частей и процесс RMA. Попросите референсные конфигурации и результаты тестов на близких сценариях, а также список обязательных настроек и ограничений. Отдельно договоритесь о процедуре обновлений и о том, кто несет ответственность за «серые зоны» — драйвер, firmware, SDK и инструменты управления.
Облачная инфраструктура ускоряется не «магией», а конкретными слоями кремния, которые снимают лишнюю работу с CPU и уменьшают задержки на пути данных. Выигрыш появляется там, где поток данных становится достаточно предсказуемым, чтобы перенести часть функций в специализированный блок — в сети, в хранении и в задачах offload.
Отдельный практический момент: даже если вы не строите собственный ЦОД, понимание этих ограничений помогает и на уровне прикладной разработки. Например, когда вы собираете веб‑ и backend‑сервисы в TakProsto.AI (в том числе на React и Go с PostgreSQL), качество сети, хвостовые задержки хранения и влияние шифрования напрямую отражаются на p99 ответа и стоимости масштабирования. Поэтому полезно закладывать наблюдаемость, реалистичные SLO и сценарии деградации ещё на этапе проектирования — в TakProsto.AI для этого удобны planning mode, снапшоты и rollback при изменениях.
Сеть. Быстрее становится пересылка пакетов и их обработка (очереди, телеметрия, шейпинг), а также межсоединения и оптика — меньше «узких горлышек» между стойками и кластерами.
Хранение. Производительность растет, когда путь от приложения до данных короче: NVMe, грамотные контроллеры, оптимизация очередей и параллелизм. Часто решает не «скорость одного SSD», а стабильность задержек при нагрузке.
Offload (DPU). Сетевые и защитные функции (шифрование, фильтрация, виртуализация I/O) уходят с хоста, освобождая CPU для полезной работы и делая характеристики более предсказуемыми.
Начните с карты критического пути запроса (пакет → сеть → DPU/хост → хранилище → ответ) и выделите 1–2 узких места. Затем выберите «самый дешевый по рискам» эксперимент: пилот на части кластера, четкие KPI и план отката.
Если параллельно вы ускоряете выпуск продукта, имеет смысл выстроить процесс так, чтобы изменения в приложении быстро доходили до продакшена без тяжёлого наследия классических пайплайнов программирования: TakProsto.AI поддерживает деплой и хостинг, кастомные домены и экспорт исходников, а также уровни тарифов от free до enterprise. Дополнительно можно получить кредиты за контент про платформу (earn credits program) или по реферальной ссылке.
Если нужен ориентир по вариантам модернизации, держите под рукой внутренний гайд или краткий список решений на /blog.
Это специализированные микросхемы, которые ускоряют и стабилизируют «путь данных» в ЦОД: обработку сетевых пакетов, доступ к хранилищу и инфраструктурные функции (виртуализация I/O, шифрование, телеметрия). Пользователь их не видит, но они напрямую влияют на задержки, throughput и предсказуемость SLA.
Потому что многие облачные нагрузки упираются не в вычисления, а во ввод‑вывод: сеть, storage, шифрование, балансировку, изоляцию арендаторов. Эти операции создают очереди, забирают ядра CPU и ухудшают p99/p999. Специализированные чипы снимают часть повторяющихся операций и делают время ответа ровнее.
Упрощённо: приложение → NIC/DPU → коммутатор стойки (ToR) → фабрика сети → ToR назначения → NIC/DPU → приложение. Задержки чаще растут не «в кабеле», а в очередях/буферах при конкуренции потоков и перегрузках в фабрике.
PHY отвечает за физический сигнал по меди/оптике, SerDes переводит данные между параллельным и последовательным представлением на очень высоких скоростях, а MAC собирает/разбирает Ethernet‑кадры и управляет приёмом/передачей. Ошибки и ограничения на любом из уровней могут давать потери, ретраи и рост latency.
DPU — это отдельный вычислительный узел на плате (ядра + память + ускорители), который выполняет инфраструктурные задачи рядом с сетью. Часто в offload выносят:
Это освобождает CPU хоста и повышает предсказуемость под нагрузкой.
Мультиарендность требует, чтобы соседние нагрузки не «продавливали» полосу и не ломали SLO по задержкам. DPU помогает применять квоты, правила и телеметрию на уровне инфраструктуры (ближе к сети), снижая зависимость от софтверного datapath на CPU и упрощая масштабирование при включённой безопасности «по умолчанию».
NVMe‑oF передаёт NVMe‑команды (как у локального SSD) по сети, позволяя держать накопители в отдельных storage‑узлах и масштабировать их независимо от вычислений. На практике это даёт высокие IOPS и низкую задержку при правильном подборе сети, адаптеров и настроек очередей.
Контроллер определяет не только «пиковую скорость», но и стабильность под длительной нагрузкой. Ключевые функции:
Для облака критично, чтобы контроллер держал ровные p95/p99 и не уходил в просадки из‑за фоновых операций.
Признак — повторяющиеся операции над потоками данных, где упор в latency/throughput, а не в сложную ветвящуюся логику. Типовые кандидаты: криптография, сжатие/дедупликация, фильтрация/поиск, обработка пакетов, DPI. Перед разработкой важно измерить узкое место и подтвердить эффект в цифрах (ядра CPU, p99, Вт/Гбит/с и т. п.).
Пилотируйте поэтапно и измеряйте «хвосты»:
Это снижает риск «зоопарка» ревизий и неожиданных деградаций в проде.