¿Cómo medir el ancho de banda de memoria en servidores en la nube? Detecta la sobreventa y las exageraciones

Usa el método de auditoría cruzada para detectar exageraciones en el ancho de banda de memoria

Actualizado 2026-08-12 · CloudWorth

ancho de banda de memoriapruebas de benchmarkdetección de sobreventaFinOpsCloudWorthSteal TimeSobreventa VPSBenchmark VPS

Las pruebas de ancho de banda de memoria deben combinarse con Steal Time y el precipicio de caché, utilizando la tasa de prima de FinOps para asegurar una relación calidad-precio real.

Método de benchmark: STREAM y mbw

Para pruebas de ancho de banda de memoria en servidores en la nube, las dos herramientas que más uso son STREAM y mbw. STREAM se inclina hacia el pico teórico, adecuado para ver la generación de hardware; mbw está más cerca de la presión real de lectura/escritura, especialmente adecuado para entornos de contenedores Docker/K8s. Los comandos son muy sencillos:

# STREAM (requiere compilación)
gcc -O3 -fopenmp stream.c -o stream
./stream

# mbw (se puede instalar con apt/yum)
mbw -n 8 512

Pero no te apresures a sacar conclusiones con los números. El problema de las pruebas de ancho de banda de memoria en servidores en la nube está precisamente en la capa de virtualización. Antes de ejecutar, mira primero el steal time en /proc/stat; si el muestreo continuo supera el 2%, significa que la CPU física está siendo tomada por los vecinos, y el ancho de banda medido será notablemente más bajo. Luego observa el precipicio de cache: aumenta gradualmente el tamaño del arreglo de prueba; si el ancho de banda cae repentinamente a menos de 1/3 en cierto punto, es muy probable que la caché L3 esté limitada o haya contención.

Aquí viene lo importante: ¿cuánta diferencia entre el valor nominal y el valor medido se considera especificaciones infladas? Tengo la costumbre de convertir el ancho de banda de memoria en "precio por GiB" y compararlo con el valor de referencia de un bare metal de la misma configuración para calcular la tasa de sobreprecio de FinOps. Si la tasa de sobreprecio supera el 30% pero el ancho de banda es solo la mitad del valor teórico, básicamente se puede calificar como sobresuscripción o reducción de generación. Esta es la idea de la auditoría cruzada de CloudWorth: usar pruebas de escenarios reales para fijar la relación calidad-precio. La plantilla de comparación completa la pongo en el marcapáginas posterior; primero recuerda un principio: el benchmark no es el objetivo, identificar el "punto de inflexión de la relación calidad-precio" es lo que importa.

Identificación de cifras infladas: Steal Time y Cache

No te alegres antes de tiempo al ver los buenos números de STREAM o mbw. En los servidores en la nube, lo más engañoso no es que el ancho de banda individual sea bajo, sino que "parece alto y se derrumba bajo presión". Mi costumbre es probar de forma cruzada tres cosas: ancho de banda de memoria, Steal Time y tasa de aciertos de Cache. Especialmente, después de ejecutar mbw, revisa el steal en /proc/stat. Si supera el 10% de forma continua, significa que la CPU del host está gravemente sobresuscrita; tu "vCPU" puede estar compitiendo por núcleos con los vecinos, y los resultados de la prueba de ancho de banda de memoria pueden verse enmascarados por cifras artificialmente altas o fluctuaciones.

El verdadero asesino es el precipicio de Cache. Usa stream para probar diferentes tamaños de array. Si al pasar de 8MB a 16MB el ancho de banda cae más del 60%, básicamente se puede concluir que la L3 está compartida o que la instancia ha sido degradada a una generación de CPU antigua. Por ejemplo, una empresa IPO afirma tener "memoria de alta frecuencia", pero en realidad su rendimiento es inferior al de su propia gama de entrada. En estos casos hay que hacer cuentas con la fórmula de sobreprecio de CloudWorth: (rendimiento real / rendimiento nominal) ÷ (precio / precio promedio de la misma categoría). Si es inferior a 0.7, devuelve sin dudar.

También hay que tener cuidado al probar en contenedores: Docker comparte el kernel por defecto, y mbw se ve afectado por la limitación de cgroup. Es mejor añadir --cpuset-mems para vincular los nodos NUMA antes de probar; de lo contrario, los resultados solo sirven como entretenimiento. Para reproducir realmente escenarios de inferencia de IA, se recomienda usar directamente pytorch para ejecutar una multiplicación de matrices en mini-lote y compararla con la línea base de la máquina física; eso es más fiable que cualquier herramienta de benchmark.

Tasa de prima FinOps: rentabilidad real

La detección del ancho de banda de la memoria en servidores en la nube no teme tanto a la imprecisión, sino a no saber cómo calcular los costes después de la prueba. Las secciones anteriores sobre Steal Time y la caída de Cache, en esencia, responden a la misma pregunta: ¿tu dinero compra una "configuración nominal" o "potencia de cómputo real"? Ahora, al combinar estos dos indicadores con los resultados de las pruebas de ancho de banda, calculo una "tasa de prima FinOps" para cada instancia. La fórmula es sencilla: tasa de prima = ancho de banda medido ÷ ancho de banda teórico nominal ÷ precio unitario. Cuanto mayor sea el cociente, más real es el ancho de banda obtenido por cada unidad de inversión; en caso contrario, es la típica "configuración inflada".

Tomemos como ejemplo una instancia de un proveedor de nube que acaba de salir a bolsa, con sus acciones subiendo un 42% en un día y luego disculpándose: nominalmente 8 núcleos y 16 GB, con un ancho de banda de memoria teórico de aproximadamente 40 GB/s (estimación de doble canal DDR4). Usando mbw en modo fixed, la medición real es solo de 17 GB/s, con un 5% de Steal Time, y la caída de Cache aparece en 4 MB (en lugar de los 16 MB que debería tener el L3). Al mismo tiempo, otra instancia con la misma configuración de un proveedor de nube establecido es un 18% más cara, pero el ancho de banda real alcanza los 32 GB/s, y el Steal Time es casi 0. Calculando, la tasa de prima del primero es solo 0.43, mientras que la del segundo es 0.81: la que parece más barata resulta ser la "cara".

Y esto no termina. Al profundizar las pruebas en entornos de contenedores, al ejecutar STREAM en Docker, noté que la cuota de CPU de cgroup puede limitar silenciosamente el ancho de banda de la memoria, especialmente en escenarios de múltiples núcleos, donde los resultados de mbw pueden estar inflados. Por lo tanto, en mi método de auditoría cruzada, todas las pruebas de ancho de banda deben registrar simultáneamente el tiempo dentro y fuera del contenedor, y luego normalizar con la tasa de prima FinOps. Así, ya sea KVM o Xen, ya sea con sobreventa o no, se puede llegar a una dimensión de precio comparable.

Por último, un apunte final: no te dejes engañar por la "facturación en tiempo real" o el "escalado elástico", son solo un espejismo en la factura. La verdadera rentabilidad es ejecutar mbw -b 256, contrastar el resultado con el informe de caída de caché de CloudWorth, calcular la tasa de prima respectiva y luego apagar esa máquina "barata". El ancho de banda de la memoria no miente; la factura sí.