¿Qué GPU cuesta menos para el mismo resultado ML?

Definir qué contará como resultado aceptado

Escribe la decisión antes de las pruebas: «¿Qué configuración procesa todos mis documentos, respeta mi calidad mínima y termina antes de mi plazo, por el presupuesto comprometido más bajo?». Fija el escenario: aquí, un corpus procesado sin conexión. Una aplicación interactiva también requeriría definir la llegada de las solicitudes, su concurrencia y la latencia admisible; su clasificación no se deduce solo de esta prueba.

Llama corpus validado a un conjunto completo de salidas que supera todos tus controles. Un archivo creado aún no es un resultado aceptado. Verifica los identificadores, el formato, la cobertura y una métrica relacionada con tu uso. Anota el umbral y la tolerancia respecto a una referencia antes de mirar los tiempos. Así, dos configuraciones pueden ser equivalentes para la decisión sin producir números idénticos bit a bit.

Esta separación entre conjunto de datos, objetivo de calidad y escenario también existe en los principios de MLPerf Inference. El protocolo siguiente es nuestro método de trabajo, que debes adaptar a tu proyecto; no constituye ni una ejecución ni una certificación MLPerf.

Fuentes técnicas: MLCommons — escenarios, métricas y objetivos de calidad

Preparar las entradas, la referencia y el manifiesto

Necesitas un corpus que tengas derecho a usar, respuestas de referencia o un procedimiento de evaluación, el código de inferencia y un entorno capaz de ejecutar el modelo elegido. Separa los datos que sirven para ajustar la configuración del corpus final de comparación. Si ajustas los umbrales después de ver este último, prepara una nueva evaluación independiente para respaldar la conclusión.

Asigna un identificador estable a cada entrada. Conserva una huella del corpus, el orden de paso, la revisión del modelo y del tokenizer, las versiones del código y de las dependencias. El manifiesto describe también las GPU utilizadas, la precisión, la cuantización, la compilación, el backend de atención, la política de padding y la longitud máxima. Una truncación diferente cambiaría el trabajo que se va a comparar.

Registra el controlador y el backend que realmente están presentes. Para una variante AMD, verifica la combinación de sistema, GPU, ROCm y framework en la matriz oficial. Una documentación consultada o el nombre de una tarjeta no demuestran que ese entorno esté instalado. Si las pilas de software difieren entre dos ensayos, la conclusión se referirá a las configuraciones completas probadas.

Fuentes técnicas: AMD — matriz de compatibilidad ROCm

Ejemplo: clasificar los mismos 1000 textos

Este es un experimento para construir con tus datos, sin resultado de rendimiento presupuesto. Quieres clasificar 1000 textos en las categorías de tu proyecto. Reserva 600 entradas cortas, 300 intermedias y 100 largas; define los límites con el tokenizer elegido y mantén una distribución representativa de las clases. Este reparto es un ejemplo de protocolo, no un corpus proporcionado ni una recomendación universal de proporciones.

Compara batches de 1, 4 y 8 con el mismo modelo, la misma precisión, el mismo orden y la misma regla de padding. La única variable de esta primera serie es el batch. Una segunda serie podrá cambiar la precisión o el hardware, manteniendo las demás decisiones explícitamente fijadas. Agrupar por longitud es una nueva variante que hay que declarar, porque modifica la organización del trabajo.

Para cada pasada, exporta las 1000 predicciones con sus identificadores. La comprobación debe encontrar exactamente los identificadores esperados, sin duplicados ni omisiones. Conserva las predicciones erróneas: sirven para el cálculo de calidad. Eliminar los ejemplos difíciles mejoraría artificialmente la puntuación y reduciría el corpus realmente procesado.

Separar arranque, calentamiento y pasada medida

Registra la descarga necesaria, la instalación, la carga y la compilación por separado del procesamiento estabilizado. Pueden excluirse del cronómetro de una pasada aunque ocupen parte del alquiler. Fija una regla de calentamiento idéntica para todas las variantes: entradas cubiertas, número de pasadas y tratamiento de las recompilaciones. No ajustes esta regla después de ver qué variante se beneficia de ella.

Define los límites del tiempo principal. Para este ejemplo fuera de línea, mide la lectura del corpus, la tokenización, las transferencias, la inferencia y la materialización de las predicciones en el host. Cronometra después la evaluación y la escritura de los entregables por separado para establecer la campaña completa. Una duración limitada al cálculo en GPU no se compara directamente con este tiempo de procesamiento.

Las operaciones CUDA son asíncronas: un cronómetro en el host debe esperar el fin de las operaciones anteriores antes de su inicio y el del trabajo medido antes de su parada. Los eventos CUDA son adecuados para un perímetro de GPU correctamente definido. Para una operación aislada, torch.utils.benchmark.Timer se encarga del calentamiento y la sincronización. Mantén los mismos límites de medición entre variantes.

Fuentes técnicas: PyTorch 2.14 — ejecución CUDA asíncrona · PyTorch — medir con torch.utils.benchmark

Repetir y conservar los fallos

Prevé cinco pasadas completas por variante para esta primera comparación. Alterna su orden, por ejemplo 1–4–8, luego 4–8–1, luego 8–1–4, para que una sola variante no sea siempre la primera. Conserva la política de procesos, de cachés y de calentamiento. Estas cinco pasadas describen tu serie pequeña; por sí solas no demuestran la estabilidad durante un periodo largo.

Una fila de la tabla bruta representa un pasaje intentado, incluida una detención. Relaciona la variante y el corpus con los parámetros, la duración y el veredicto de calidad. Los campos expected_ids y observed_ids registran los recuentos de entradas; ids_match confirma la igualdad de los conjuntos, verificada en los archivos de predicciones conservados por separado. corpus_accepted contiene el veredicto del pasaje. Anota los errores y la ruta de las salidas en notes. Si falta una medición, deja su celda vacía e indica por qué. Una ausencia de GPU no es una medición de cero segundos o de cero bytes.

Si el batch 8 supera la memoria en las entradas largas, conserva la fila de fallo y el número de entradas completadas. No sustituyas silenciosamente ese pasaje por un batch más pequeño. El ajuste de reanudación se convierte en una variante distinta; su tiempo y sus intentos forman parte del balance. Una interrupción o un error de formato nunca es un éxito económico por haber sido rápida.

Leer las duraciones sin sobreinterpretar cinco ensayos

Presenta las cinco duraciones brutas, su mediana, su mínimo y su máximo, con el número de éxitos y de fallos. La mediana describe el centro de esas observaciones; no elimina los incidentes. Si se excluye un pasaje por una causa externa documentada, conserva su rastro y aplica la misma regla de exclusión a todas las variantes.

No presentes un p95 calculado sobre cinco pasajes como una estimación robusta de los casos lentos. Para estudiar la latencia de las solicitudes, reúne un conjunto adecuado de tiempos individuales con el escenario de llegada y la concurrencia. Las cinco duraciones de corpus y las latencias de 1000 solicitudes no son la misma población.

Si la dispersión observada es comparable a la diferencia entre las medianas, la serie todavía no desempata las opciones. Añade repeticiones en un protocolo común o examina una causa concreta: carga, formas de entrada, compilación, actividad concurrente. Evita quedarte solo con el mejor pasaje de cada tarjeta.

Verificar la calidad tras un cambio de precisión

Para comparar FP32, BF16 o una cuantización, parte de las mismas entradas y de la misma referencia. Evalúa el formato, la métrica principal y los subgrupos previstos. Una variante que supera tu tolerancia puede ser interesante para otro objetivo; no se une a la comparación con calidad equivalente bajando el umbral a posteriori.

Registra las semillas y las opciones deterministas utilizadas. PyTorch no garantiza una reproducibilidad completa entre versiones, plataformas o ejecuciones de CPU y GPU, incluso con la misma semilla. Por tanto, precisa qué buscas reproducir: salidas idénticas, desviación numérica acotada o calidad de negocio aceptable. Para un protocolo estocástico, prevé varias semillas comunes y conserva sus resultados por separado.

Fuentes técnicas: PyTorch 2.14 — alcance y límites de la reproducibilidad

Usar la memoria como criterio de viabilidad

Una opción debe terminar el corpus con sus entradas largas antes de que se compare su costo. Anota el pico de memoria por dispositivo y el alcance del contador. Con PyTorch, memory_allocated sigue los tensores y memory_reserved la memoria gestionada por el asignador: estos valores no se suman. Los picos correspondientes pueden producirse en momentos distintos.

El notebook de la carpeta de memoria ayuda a distinguir estimación y observación. Su ejercicio no sustituye la medición de tu modelo: carga tu entorno, conserva los parámetros y vuelve a ejecutar tu carga. Una capacidad anunciada por tarjeta y un precio de lote no permiten deducir un rendimiento, una interconexión ni un reparto automático del modelo entre varias GPU.

Fuentes técnicas: PyTorch 2.14 — contadores y asignador de memoria

Elegir la duración con el calendario completo

La duración necesaria no es solo la suma de los kernels de GPU. Construye una ventana de acceso que vaya desde la preparación del alquiler hasta la recuperación de los entregables: instalación, controles, calentamiento, comparaciones, reanudaciones previstas, evaluación y exportación. Añade los periodos de espera durante los cuales sigues necesitando conservar el alquiler. Cuando las tareas se solapan, razona sobre el calendario real en lugar de sumar dos veces sus duraciones.

Ejemplo de calendario, sin suposiciones de velocidad: quieres conservar el acceso de lunes a las 9 h a viernes a las 9 h, en la misma zona horaria y sin cambio de hora. Esta ventana abarca 96 horas. Supera las 72 horas de un plan de 3 días y cabe dentro de las 168 horas de un plan de 7 días. Esto no demuestra que tus procesos terminen a tiempo: sus duraciones aún están por medir.

La calculadora permite indicar tu ventana total y muestra los planes de 3, 7 y 30 días. Un plan que cubre el calendario se convierte en candidato. Si la campaña excede el periodo elegido, modifica el programa o presupuesta explícitamente los periodos adicionales necesarios; no supongas una prórroga automática.

Calcular el costo comprometido con nuestros planes

El presupuesto de un alquiler es el precio del plan por lote, multiplicado por el número de lotes. El costo por corpus validado divide después ese importe entero entre los corpus útiles realmente aceptados en el alcance anunciado. Si no se acepta ningún corpus, el ratio queda indefinido. El gasto comprometido, en cambio, permanece en el balance.

Los precios de abajo provienen de nuestro catálogo, versión del 24 de septiembre de 2026. Ilustran la regla de cálculo, sin establecer qué GPU termina tu carga más rápido. Un lote B200 ya incluye dos tarjetas: multiplicar su precio una segunda vez por dos contaría esas tarjetas dos veces. Así, dos lotes de RTX 4090 durante 7 días cuestan 220 USD; un lote de dos B200 durante 7 días cuesta 2071 USD.

Una ejecución corta no convierte el plan en una factura por horas. La calculadora usa el total del plan, aunque parte del periodo quede sin usar. Para un presupuesto de proyecto más amplio, registra por separado los demás gastos realmente aplicables y su justificación. No mezcles costos medidos en una de las variantes con partidas olvidadas en la otra.

Fuentes técnicas: IteraGPU — planes del catálogo

Contar entregables útiles, no repeticiones de medición

Las cinco repeticiones de un mismo benchmark sirven para observar la dispersión. No se convierten en cinco corpus de producción útiles solo porque se hayan escrito cinco archivos. Define los entregables esperados antes de la campaña y cuenta cada entregable aceptado una sola vez. Si el trabajo real abarca varios corpus, cada configuración debe procesar los mismos corpus y aplicar la misma regla de calidad.

En la calculadora, deja vacío el número de corpus mientras los entregables útiles no estén realmente terminados y validados. La casilla de calidad confirma tu propia verificación; la herramienta no lee tus predicciones ni tus métricas. Indica únicamente la cantidad constatada. La ventana de campaña puede ser una hipótesis de planificación, pero una previsión de capacidad no sustituye a resultados aceptados.

El balance final reúne, para cada configuración admisible, los veredictos de calidad, las duraciones brutas, la ventana de campaña, el plan comprometido y el número de entregables aceptados. Una opción rápida puede ser útil para un plazo ajustado sin ser la más barata. Dos opciones que caben en el mismo calendario pueden diferenciarse por su costo comprometido, sus fallos o la incertidumbre que persiste.

Descargar el protocolo y conservar una prueba reutilizable

El paquete IteraGPU Lab v1 reúne los materiales de esta comparación y de la medición de memoria. Empieza por el README y el protocolo de calidad, y luego completa la tabla bruta con tus ejecuciones. Las celdas de rendimiento permanecen vacías antes de una ejecución; las tarifas son datos de catálogo, separados de las mediciones.

Para presupuestar dos lotes de RTX 4090 durante 7 días, coloca calcul_forfaits.py y tarifs-forfaits.csv en la misma carpeta, abre un terminal en esa carpeta y ejecuta el comando de abajo con Python 3.10 o más reciente. Muestra un presupuesto de 220,00 USD para dos GPU. La opción opcional --accepted-results recibe tu número entero de corpus útiles distintos realmente terminados y validados. Omítela mientras ese dato no exista: el script entonces solo calcula el presupuesto, sin inventar un costo por resultado.

Conserva juntos el manifiesto, las huellas de entradas, las predicciones, los veredictos y la tabla de intentos. La nota de decisión indica el ajuste elegido, la carga cubierta y el motivo de la elección. Podrás contrastarla con tu alquiler en el cuaderno de IteraGPU y relanzar exactamente la pregunta experimental cuando cambies de modelo o de versión.

Este protocolo fuera de línea no cualifica por sí solo un servicio interactivo, un entrenamiento hasta la convergencia ni otro conjunto de datos. Para esos usos, redefine la unidad útil y los controles antes de comparar. Los archivos proporcionados sirven para preparar y registrar tus ensayos; esta carpeta no presenta ninguna comparación medida entre las configuraciones del catálogo ni ahorro observado.

python calcul_forfaits.py --gpu rtx-4090 --days 7 --lots 2

• IteraGPU Lab v1 — carpeta completa ↓

  Archivo de los scripts, el notebook, las tablas y las instrucciones.

• Protocolo de calidad ↓

  Entradas, criterios de aceptación y reglas de comparación que hay que fijar antes de los ensayos.

• Tabla de resultados brutos ↓

  Hoja en blanco para conservar los parámetros, las mediciones, los veredictos y los fallos.

• Cálculo de los presupuestos ↓

  Cálculo del presupuesto con precio por lote, duraciones de 3, 7 y 30 días y corpus validados.

• Tarifas de los presupuestos ↓

  Instantánea de los precios de nuestro catálogo usados por el cálculo proporcionado.

• Notebook de medición de memoria ↓

  Cálculos y ejercicio de medición que hay que interpretar con la carpeta de memoria.

• Script de medición de memoria ↓

  Versión en Python del ejercicio, con comprobación del entorno.

• Instrucciones y requisitos previos ↓

  Alcance de las herramientas y procedimiento para ejecutarlas y conservar las salidas.

• Licencia de los recursos ↓

  Condiciones de reutilización de los recursos originales de la carpeta.