Descubre cómo el silicio de infraestructura de Marvell soporta redes, almacenamiento y aceleración personalizada en la nube—impulsando centros de datos más rápidos y eficientes tras bambalinas.
La mayoría de la gente piensa que la “nube” son solo servidores. En realidad, un centro de datos en la nube es un enorme sistema para mover, almacenar y proteger datos a alta velocidad. El silicio de infraestructura de datos es el conjunto de chips especializados que realizan esas tareas intensivas en datos para que las CPUs principales no tengan que hacerlo.
Marvell se centra en esa capa “intermedia”: los chips que conectan el cómputo con la red y el almacenamiento, aceleran tareas comunes de los centros de datos y mantienen todo funcionando de manera predecible bajo carga.
Si te imaginas un rack de nube de arriba a abajo, los dispositivos de Marvell suelen ubicarse:
Estos no son “apps” ni “servidores” en el sentido habitual: son los bloques de hardware que permiten que miles de servidores se comporten como un servicio coherente.
Cuando el silicio de infraestructura hace su trabajo, no lo notas. Las páginas cargan más rápido, los vídeos hacen menos buffering y las copias de seguridad terminan a tiempo—pero el usuario nunca ve el motor de offload de red, el controlador de almacenamiento o la tela de conmutación que hace esto posible. Estos chips reducen la latencia, liberan ciclos de CPU y hacen el rendimiento más consistente, de forma silenciosa.
El papel de Marvell es más fácil de agrupar en tres cubetas:
Ese es el silicio “silencioso” que ayuda a que los servicios en la nube se sientan sencillos en la superficie.
Las aplicaciones en la nube parecen “definidas por software”, pero el trabajo físico sigue ocurriendo en racks llenos de servidores, switches y almacenamiento. A medida que la demanda crece, las nubes no pueden confiar en CPUs de propósito general para cada tarea sin chocar contra límites duros en coste y eficiencia.
El entrenamiento e inferencia de IA mueven conjuntos de datos enormes dentro del centro de datos. Transmisiones de vídeo, copias de seguridad, analítica y plataformas SaaS añaden carga de fondo constante. Incluso cuando hay CPU disponible, el cuello de botella a menudo se traslada a mover, filtrar, encriptar y almacenar datos lo bastante rápido.
La mayoría del tráfico de nube nunca toca Internet público. Viaja “este–oeste” entre servicios: llamadas microservicio a microservicio, lecturas de base de datos, actualizaciones de caché, replicación de almacenamiento y cargas de IA distribuidas. Ese tráfico interno necesita latencia predecible y alto rendimiento, lo que empuja al hardware de red y almacenamiento a hacer más procesamiento cerca de la ruta de datos.
La energía y el espacio no son ilimitados. Si un proveedor de nube puede descargar trabajo como procesamiento de paquetes, encriptación, compresión o checksums de almacenamiento a silicio dedicado, la CPU usa menos tiempo en sobrecarga. Eso mejora:
En lugar de escalar añadiendo más núcleos de propósito general, las plataformas cloud usan cada vez más chips construidos para un propósito—Smart NICs/DPUs, silicio de conmutación, controladores de almacenamiento y aceleradores—para manejar tareas repetitivas y de alto volumen. El resultado es una nube más rápida y más barata de operar, incluso cuando las cargas consumen más datos.
Los servidores cloud dedican una cantidad sorprendente de tiempo a hacer “trabajo de infraestructura” en lugar de ejecutar tu aplicación. Cada paquete necesita moverse, inspeccionarse, registrarse y a veces encriptarse—con frecuencia por la CPU principal. El offload de red traslada esas tareas a hardware especializado, que es donde aparecen las Smart NICs y las DPUs en muchos centros de datos modernos (incluidos sistemas con silicio Marvell).
Una Smart NIC es una tarjeta de interfaz de red que hace más que enviar/recibir. Junto a los puertos Ethernet habituales, incluye procesamiento extra (a menudo núcleos Arm y/o lógica programable) para ejecutar funciones de red en la tarjeta.
Una DPU (Data Processing Unit) va un paso más allá: está diseñada para actuar como un “ordenador de infraestructura” dedicado dentro del servidor. Una DPU combina típicamente red de alto rendimiento, múltiples núcleos de CPU, aceleradores hardware (cripto, procesamiento de paquetes) y fuertes funciones de aislamiento para gestionar el movimiento de datos y la seguridad sin depender de la CPU del host.
Un modelo mental práctico:
Los objetivos de offload son trabajos repetibles y de alto volumen que, de otro modo, robarían ciclos de CPU a las aplicaciones. Ejemplos comunes incluyen:
Cuando la CPU tiene que “vigilar” la red, el rendimiento de la aplicación puede variar según picos de tráfico, vecinos ruidosos o ráfagas de trabajo de seguridad. El offload ayuda a:
Físicamente, las DPUs suelen venir como tarjeta add-in PCIe o módulo OCP NIC. Se conectan a:
Conceptualmente, la DPU se convierte en un “agente de tráfico” entre la red y el servidor—manejando políticas, encriptación y switching para que el SO host y las CPUs se centren en ejecutar aplicaciones.
Cuando abres una app o mueves datos a la nube, tu petición normalmente no viaja a “un servidor”, sino a través de una tela de switches Ethernet que conectan miles de servidores como si fueran una sola máquina gigante.
La mayoría de centros de datos usan un diseño “leaf–spine”:
Este diseño mantiene las rutas cortas y consistentes, clave para el rendimiento a escala.
Dos números moldean la experiencia de usuario y el coste:
Los operadores cloud buscan mantener la latencia estable incluso con enlaces ocupados, mientras empujan volúmenes enormes de tráfico.
Un chip de switch Ethernet hace más que “reenviar paquetes.” Debe:
Vendedores como Marvell construyen silicio que se centra en realizar estas tareas de forma predecible a velocidades muy altas.
Pasar de 25/100G a 200/400/800G no es solo una cuestión de números. Mayores velocidades pueden significar:
El resultado es una red de centro de datos que se siente menos como “cables” y más como infraestructura compartida para cada carga que se ejecuta encima.
Cuando la gente habla de rendimiento en la nube suele imaginar CPUs y GPUs. Pero gran parte de la “velocidad” (y la fiabilidad) la decide el silicio de almacenamiento situado entre las unidades flash y el resto del servidor. Esa capa suele ser un controlador de almacenamiento—chips diseñados para gestionar cómo se escribe, lee, comprueba y recupera la información.
Un controlador de almacenamiento es el director de tráfico para datos persistentes. Descompone las escrituras entrantes en fragmentos manejables, programa lecturas para que los datos calientes respondan rápido y ejecuta comprobaciones de integridad para que los bits corruptos no se conviertan en archivos dañados.
También se ocupa de la contabilidad poco glamourosa que hace que el almacenamiento sea predecible a escala: mapear bloques lógicos a ubicaciones físicas de flash, balancear el desgaste para alargar la vida de las unidades y mantener la latencia estable cuando muchas aplicaciones atacan la misma piscina de almacenamiento.
NVMe (Non-Volatile Memory Express) es un protocolo diseñado para almacenamiento flash rápido. Se volvió común porque reduce la sobrecarga y soporta colas paralelas de solicitudes—lo que permite que muchas operaciones estén en vuelo a la vez, adecuado para cargas cloud donde miles de lecturas/escrituras pequeñas ocurren simultáneamente.
Para los proveedores cloud, NVMe no es solo rendimiento pico; es latencia baja y consistente bajo carga, que mantiene las aplicaciones con una sensación de respuesta.
Los controladores modernos a menudo incluyen funciones hardware que de otro modo consumirían ciclos de CPU:
El almacenamiento no es un subsistema aislado: moldea cómo se comportan las aplicaciones:
En resumen, el silicio de almacenamiento convierte la flash cruda en infraestructura cloud confiable y de alto rendimiento.
Cuando los proveedores cloud actualizan servidores no solo intercambian CPUs. También necesitan el “tejido conectivo” que permite a las CPUs hablar con tarjetas de red, almacenamiento y aceleradores sin forzar un rediseño completo. Por eso estándares como PCIe y CXL importan: mantienen interoperabilidad, hacen que las actualizaciones sean menos arriesgadas y ayudan a escalar de forma predecible.
PCIe (Peripheral Component Interconnect Express) es el enlace interno principal para conectar componentes como:
Un modelo mental útil: PCIe es como añadir más carriles a una autopista. Generaciones más nuevas aumentan la velocidad por carril y enlaces más anchos (x8, x16, etc.) añaden capacidad total. Para operadores cloud, esto afecta directamente la rapidez con la que los datos pueden moverse entre el cómputo y los dispositivos que lo alimentan.
El silicio de infraestructura de Marvell a menudo se sitúa en un extremo de estas conexiones PCIe—dentro de una NIC, DPU, controlador de almacenamiento o componente adyacente a un switch—por lo que la capacidad PCIe puede ser un limitador (o habilitador) práctico para las mejoras de rendimiento.
CXL (Compute Express Link) se basa en la conexión física de PCIe pero añade formas nuevas para que los dispositivos compartan recursos tipo memoria con menor sobrecarga. En términos simples, CXL ayuda a que los servidores traten ciertos recursos externos (expansión de memoria o memoria agrupada) más como una extensión local que como un dispositivo lejano.
La ganancia no es solo “más rápido”. PCIe y CXL permiten:
Los estándares de conectividad no salen en los titulares, pero moldean fuertemente la rapidez con la que las nubes pueden adoptar mejor red, almacenamiento y aceleración.
“Aceleración personalizada” en infraestructura cloud no siempre significa una GPU gigante. Más a menudo significa añadir bloques pequeños y especializados de cómputo que aceleran una tarea repetida—para que las CPUs se enfoquen en ejecutar aplicaciones.
Las cargas cloud varían enormemente: un nodo orientado a almacenamiento tiene cuellos de botella distintos a un servidor de borde de streaming de vídeo o a un appliance de firewall. El silicio construido para un propósito ataca esos cuellos de botella directamente—a menudo moviendo una función a hardware para que corra más rápido, de forma más consistente y con menos sobrecarga de CPU.
Algunas categorías prácticas que aparecen una y otra vez en centros de datos:
Los grandes equipos cloud suelen empezar por perfilar: ¿dónde se atascan las peticiones y qué tareas se repiten millones de veces por segundo? Luego deciden si acelerar mediante un motor programable (más adaptable) o bloques de función fija (máxima eficiencia). Vendedores como Marvell suelen ofrecer bloques constructores—red, seguridad, interfaces de almacenamiento—de modo que la parte “personalizada” se pueda centrar en los caminos calientes específicos de la nube.
La aceleración de función fija suele ganar en rendimiento por vatio y determinismo, pero es más difícil de reutilizar si la carga cambia. Las opciones más programables son más fáciles de evolucionar, aunque pueden costar más energía y dejar rendimiento en la mesa. Los mejores diseños mezclan ambos: planos de control flexibles con caminos rápidos hardware donde importa.
La energía a menudo es el verdadero techo en un centro de datos—no la cantidad de servidores que puedes comprar, sino cuánta electricidad puedes suministrar y extraer como calor. Cuando una instalación alcanza su límite de potencia, la única forma de crecer es obtener más trabajo útil por cada vatio.
Las CPUs de propósito general son flexibles, pero no siempre eficientes en tareas repetitivas de infraestructura como manejo de paquetes, encriptación, procesamiento de protocolos de almacenamiento o telemetría. El silicio de infraestructura (Smart NICs/DPUs, switches y controladores de almacenamiento) puede ejecutar esas tareas con menos ciclos y menos trabajo desperdiciado.
La ganancia energética suele ser indirecta: si el offload reduce la utilización de CPU, puedes correr la misma carga con menos núcleos activos, frecuencias más bajas o menos servidores. Esto también puede reducir la presión sobre memoria y tráfico PCIe, recortando aún más el consumo.
Cada vatio se convierte en calor. Más calor significa ventiladores más rápidos, mayor flujo de refrigerante y planificación de rack más estricta. Los racks de alta densidad pueden ser atractivos, pero solo si puedes refrigerarlos consistentemente. Por eso la elección del chip importa más allá del rendimiento bruto: un componente que consume menos energía (o se mantiene eficiente a alta carga) permite a los operadores empaquetar más capacidad en la misma huella sin crear puntos calientes.
Los números de eficiencia son fáciles de vender y difíciles de comparar. Cuando veas “mejor rendimiento por vatio”, busca:
Las afirmaciones más creíbles relacionan los vatios con una carga específica y repetible y muestran qué cambió a nivel de servidor o rack, no solo en una hoja de especificaciones.
Los proveedores cloud comparten las mismas máquinas físicas entre muchos clientes, por lo que la seguridad no puede “añadirse después”. Gran parte se aplica al nivel del chip—dentro de Smart NICs/DPUs, silicio de red, switches y controladores de almacenamiento—donde el offload hardware puede aplicar protecciones a velocidad de línea.
La mayoría del silicio de infraestructura incluye una raíz de confianza hardware: un conjunto pequeño e inmutable de lógica y claves que puede verificar el firmware antes de que todo empiece. Con secure boot, el chip comprueba firmas criptográficas del firmware (y a veces de los componentes de arranque del host), negándose a ejecutar código modificado o desconocido.
Esto importa porque una DPU o un controlador de almacenamiento comprometido puede situarse “entre” tus servidores y la tela de red/almacenamiento. El arranque seguro reduce el riesgo de persistencia oculta en esa capa.
La encriptación a menudo se acelera directamente en el silicio para que no robe tiempo de CPU:
Porque es inline, la seguridad no tiene que significar almacenamiento en red más lento.
Las nubes multitenant dependen de separación estricta. Los chips de infraestructura pueden ayudar a imponer aislamiento con colas hardware, protección de memoria, funciones de virtualización y aplicación de políticas—de modo que el tráfico o las solicitudes de almacenamiento de un inquilino no puedan espiar a otro. Esto es crucial cuando las DPUs manejan redes virtuales y cuando dispositivos PCIe se comparten entre cargas.
La fiabilidad no es solo “sin fallos”—es detección y recuperación más rápidas. Muchos diseños de silicio de infraestructura incluyen contadores de telemetría, reporte de errores, hooks para trazado de paquetes y métricas de salud que los equipos cloud pueden volcar a sistemas de monitorización. Cuando algo falla (drops, picos de latencia, errores de enlace, tormentas de reintentos), estas señales integradas ayudan a localizar si el problema está en el switching Ethernet, la DPU o el controlador de almacenamiento—reduciendo el tiempo de resolución y mejorando la disponibilidad.
Imagina una acción simple: abres una app de compras y tocas “Ver historial de pedidos”. Esa petición viaja por múltiples sistemas—y cada paso es una oportunidad para demora.
Tu petición llega al borde de la nube y al balanceador de carga. El paquete se enruta a un servidor de aplicación sano.
Llega al host de la aplicación. Tradicionalmente, la CPU del host maneja mucho del “plomería”: encriptado, reglas de firewall, red virtual y gestión de colas.
La app consulta la base de datos. La consulta debe atravesar la red del centro de datos hasta un clúster de base de datos y luego recuperar datos del almacenamiento.
La respuesta vuelve por el mismo camino. Los resultados se empaquetan, se encriptan y se envían a tu teléfono.
Smart NICs/DPUs y silicio especializado de infraestructura (incluidas soluciones de proveedores como Marvell) trasladan trabajo repetible fuera de las CPUs generales:
Los operadores cloud no eligen chips porque sean “más rápidos” en abstracto: los eligen cuando el trabajo es grande, repetible y merece convertirse en hardware dedicado. El silicio especializado es más valioso a escala (millones de peticiones similares), cuando las necesidades de rendimiento son previsibles y cuando pequeñas ganancias de eficiencia se convierten en ahorros reales a lo largo de flotas.
Los equipos suelen mapear sus cuellos de botella más grandes a funciones específicas: procesamiento de paquetes y seguridad en la ruta de red, traducción y protección de datos en I/O, o primitivas de compresión/cripto/IA en bloques de aceleración. Una pregunta clave es si la tarea puede descargarse sin romper el modelo de software. Si tu plataforma depende de ciertas características de Linux, comportamiento de switching virtual o semánticas de almacenamiento, el chip debe encajar con esas suposiciones.
Pide claridad sobre:
Los benchmarks importan, pero solo si reflejan producción: mezclas reales de paquetes, colas reales de almacenamiento y aislamiento realista de inquilinos. La potencia se evalúa como “trabajo por vatio”, no solo throughput pico—especialmente cuando los racks tienen límite de potencia.
El esfuerzo de integración suele decidir. Un chip que es 10% mejor en papel puede perder frente a uno que sea más fácil de provisionar, monitorizar y parchear a escala.
Los equipos cloud reducen el riesgo favoreciendo estándares (Ethernet, NVMe, PCIe/CXL), APIs bien documentadas y herramientas de gestión interoperables. Incluso cuando usan funciones de proveedor (incluidas las de Marvell y pares), intentan mantener planos de control de alto nivel portables para que el hardware pueda evolucionar sin forzar una reescritura completa de la plataforma.
El mismo principio se aplica en el software: cuando construyes servicios que acabarán corriendo en esta infraestructura, ayuda mantener arquitecturas portables. Plataformas como Koder.ai pueden acelerar prototipos e iteración de backends web (Go + PostgreSQL) y frontends React mediante flujos de trabajo guiados por chat, permitiendo exportar código fuente y desplegar según las necesidades de nube y cumplimiento.
El silicio de infraestructura cloud está pasando de ser una “aceleración agradable de tener” a ser la plomería básica. A medida que más servicios se vuelven sensibles a la latencia (inferencia IA, analítica en tiempo real, inspección de seguridad), los chips que manejan red, almacenamiento y movimiento de datos con eficiencia importarán tanto como las CPUs.
Las redes de mayor ancho de banda dejan de ser un nivel especial: son la expectativa. Eso empuja al silicio de conmutación Ethernet, procesamiento de paquetes, DPUs y Smart NICs hacia puertos más rápidos, menor latencia y mejor control de congestión. Vendedores como Marvell competirán en cuánto trabajo pueden descargar en hardware (encriptación, telemetría, switching virtual) sin añadir complejidad operativa.
PCIe y CXL permitirán cada vez más desagregación: poolings de memoria y aceleradores para que los racks se “componen” según la carga. La oportunidad de silicio no es solo el PHY de CXL: son los controladores, el switching y el firmware que hacen que los recursos agrupados sean predecibles, seguros y observables para los equipos cloud.
Los grandes proveedores quieren diferenciación e integración más estrecha entre chips de red, controladores de almacenamiento y aceleración personalizada. Espera más programas semipersonalizados donde un bloque estándar (SerDes, conmutación Ethernet, NVMe) se combine con funciones específicas de la plataforma, herramientas de despliegue y ventanas de soporte largas.
El rendimiento por vatio será la métrica principal, especialmente cuando los techos de potencia limiten la expansión. Las funciones de seguridad se moverán más cerca de la ruta de datos (encriptación inline, secure boot, atestación). Finalmente, las rutas de actualización importarán: ¿puedes adoptar nuevo ancho de banda, revisiones CXL o funciones de offload sin rediseñar toda la plataforma—o sin romper la compatibilidad con racks existentes?
Marvell se centra principalmente en la capa de “ruta de datos” en los centros de datos en la nube: redes (NICs/DPUs, silicio de switches), controladores de almacenamiento (NVMe y funciones relacionadas) y bloques de aceleración especializados (criptografía, procesamiento de paquetes, compresión, telemetría). El objetivo es mover, proteger y gestionar datos a escala sin consumir ciclos de CPU principales.
Porque las CPUs de propósito general son flexibles pero ineficientes para trabajos repetitivos y de alto volumen como el procesamiento de paquetes, la encriptación y el manejo de protocolos de almacenamiento. Descargar estas tareas a silicio dedicado mejora:
Una Smart NIC es una tarjeta de interfaz de red con capacidad de cómputo adicional para ejecutar funciones de red en la propia tarjeta. Una DPU añade más: actúa como un “ordenador de infraestructura” dedicado con varios núcleos, aceleradores hardware y funciones de aislamiento.
Las descargas comunes incluyen:
Esto reduce la sobrecarga de la CPU y ayuda a estabilizar la latencia bajo carga.
La mayor parte del tráfico es “este–oeste” dentro del centro de datos: llamadas entre servicios, replicación de almacenamiento, tráfico de bases de datos/caché y cargas de trabajo de IA distribuidas. Ese tráfico interno necesita latencia predecible y alto rendimiento, lo que impulsa a que más procesamiento se haga en NICs/DPUs y en el silicio de los switches para mantener el rendimiento a escala.
La mayoría de los centros de datos a escala usan una topología leaf–spine (ToR + spine):
El silicio de switches debe reenviar paquetes, almacenar ráfagas en buffers, aplicar QoS y proporcionar telemetría—todo a velocidad de línea.
Un controlador de almacenamiento se sitúa entre la memoria flash y el resto del sistema y gestiona el trabajo que hace que el almacenamiento sea rápido y fiable:
Muchos también aceleran , y para que el almacenamiento no monopolice la CPU del host.
NVMe está diseñado para memoria flash con baja sobrecarga y alta paralelización (múltiples colas y muchas operaciones en vuelo). En entornos cloud, la ganancia suele ser latencia baja y consistente bajo carga, no solo el máximo rendimiento, especialmente cuando miles de operaciones pequeñas golpean el almacenamiento compartido simultáneamente.
PCIe es el interconector interno de alta velocidad para NICs, DPUs, SSDs, GPUs y aceleradores. CXL usa la misma capa física pero añade formas más eficientes de compartir recursos tipo memoria.
En la práctica, PCIe/CXL permiten:
Pide pruebas atadas a cargas realistas y requisitos operativos:
El esfuerzo de integración suele importar tanto como el rendimiento bruto.
