Rendimiento y comparativas del acelerador de IA
Evaluar el hardware de IA para usarlo con modelos de lenguaje grandes (LLM) como carga de trabajo principal requiere un enfoque coherente y neutral con respecto al proveedor. En esta guía, se describe una metodología para comparar el rendimiento de los chips aceleradores de IA de diferentes proveedores, como NVIDIA, AMD, Googley AWS. Los principios y la metodología se pueden adaptar a cualquier chip o carga de trabajo de IA, pero los ejemplos se enfocan en una combinación común de la industria de unidades de procesamiento gráfico (GPU) de NVIDIA y Googleunidades de procesamiento tensorial (TPU) que ejecutan cargas de trabajo de LLM.
Por lo general, los modelos se optimizan para una plataforma de hardware específica, por lo que evaluar solo el rendimiento del modelo no es suficiente para comprender las capacidades del hardware. Cuando evalúes los chips aceleradores para LLM, considera tres dimensiones clave: microbenchmarking, análisis de techo y evaluación comparativa del modelo para el entrenamiento y la inferencia.
El análisis de microcomparativas y de techo es fundamental para comprender las capacidades y el potencial de una plataforma de aceleradores determinada. Una vez que se conoce esa información, la comparativa del modelo en el entrenamiento y la inferencia proporciona comparaciones reales de la carga de trabajo en los chips y estadísticas sobre si la arquitectura del modelo está optimizada para una plataforma específica.
Dimensiones de rendimiento
Sugerimos que los evaluadores piensen en el rendimiento en tres dimensiones para comprender de manera más integral un sistema de aceleración determinado:
- Microbenchmarking: Tener las especificaciones de hardware más altas no significa que las aplicaciones puedan usar esas especificaciones. Puedes usar las comparativas de microprocesadores para evaluar cómo las operaciones de punto flotante por segundo (FLOPS), la memoria de gran ancho de banda (HBM) y el ancho de banda de redes afectan lo que se puede lograr en cargas de trabajo reales.
- Análisis de Roofline: El uso óptimo del hardware puede verse obstaculizado por el ancho de banda de la memoria o la velocidad de procesamiento. Puedes usar un modelo de techo y la intensidad operativa (OI) de diferentes componentes del sistema para ver qué tan adecuados son el hardware y las cargas de trabajo entre sí. Una combinación de microcomparativas y diagramas de techo proporciona una evaluación teórica de lo que el hardware seleccionado puede lograr para diferentes tipos de cargas de trabajo.
- Comparación del modelo: La comparación en las cargas de trabajo de entrenamiento y de inferencia para medir los tokens por segundo por chip (TPS/chip) te permite evaluar el mismo modelo en diferentes plataformas. Si los resultados iniciales difieren del análisis de microcomparativas y de techo, es un indicio de que se requiere trabajo de software adicional para alcanzar los techos identificados anteriormente. Por ejemplo, este trabajo podría implicar cambiar las estrategias de fragmentación o emplear kernels personalizados.
Recuerda que la comparativa de modelos es un enfoque instantáneo para un modelo, una escala y una plataforma determinados. Los usuarios avanzados también tienen en cuenta las tendencias de la industria (como la arquitectura del modelo), las comparativas de microbenchmarking y los resultados de roofline cuando evalúan el rendimiento.
Codiseño de modelos y hardware
Las evaluaciones de rendimiento deben tener en cuenta cuidadosamente la arquitectura del modelo en el contexto del hardware que se está probando. Los modelos diseñados de manera eficiente suelen diseñarse en conjunto para una plataforma de hardware específica, de modo que se aprovechen los matices específicos de la plataforma. Por lo tanto, es posible que estos modelos no utilicen por completo otras plataformas o incluso diferentes generaciones de la misma plataforma. Por ejemplo, un modelo diseñado para las GPU de NVIDIA Hopper podría no utilizar por completo las GPU de AMD o las GPU de NVIDIA Blackwell.
Esta consideración es especialmente importante cuando se cambia de plataformas de hardware que pueden diferir en capacidades, ya que un modelo diseñado para una plataforma podría necesitar cambios de configuración, cambios de software o ambos para alcanzar el máximo rendimiento en una plataforma diferente. La evaluación comparativa de los modelos optimizados es fundamental para validar las afirmaciones de marketing de los proveedores sobre el rendimiento "teórico máximo" y medir los resultados en el mundo real. La empresa de análisis independiente SemiAnalysis señala que "comparar los FLOPS teóricos solo cuenta una parte de la historia. Lo que importa son los FLOPS efectivos, ya que los números máximos casi nunca se alcanzan en las cargas de trabajo del mundo real".
Ejemplo: El desafío gpt-oss-120B
Un error común en la evaluación comparativa es evaluar un modelo en hardware para el que no se diseñó. El gpt-oss-120B modelo de pesos abiertos de OpenAI es un ejemplo de por qué la arquitectura del modelo debe correlacionarse estrechamente con el silicio objetivo. En el siguiente ejemplo, se muestra que el diseño conjunto del modelo es fundamental y debe ocurrir al principio del proceso.
El modelo gpt-oss-120B usa una dimensión de encabezado de atención de 64. Si bien esto es estándar para muchos modelos optimizados para GPU, crea una falta de coincidencia arquitectónica para los aceleradores de TPU. Las TPU, como Trillium y Ironwood, se optimizan para dimensiones de matrices que son múltiplos de 256 para saturar por completo sus unidades de multiplicación de matrices (MXU). Dado que la dimensión del encabezado, 64, no está optimizada para las TPU, ejecutar gpt-oss-120B en un sistema de TPU genera una menor cantidad de tokens por segundo (TPS) y una menor utilización de FLOPS del modelo (MFU). El hardware desperdicia de manera efectiva ciclos de reloj y energía al rellenar el espacio restante con ceros para ajustarse a sus cuadrículas de ejecución de 256 x 256.
Usar gpt-oss-120B como comparativa para las TPU podría indicar de forma incorrecta una capacidad de hardware deficiente cuando, en realidad, refleja una falta de coincidencia en la arquitectura de software. Para evaluar con precisión el "límite" de un acelerador, pruébalo con modelos diseñados en conjunto para su geometría específica. Por ejemplo, modelos con dimensiones de encabezado de 128 o 256, como Gemma 4. Puedes mejorar el rendimiento de este modelo con kernels personalizados que evitan el padding de ceros y, en cambio, "completan" la MXU, lo que requiere experiencia y no alcanza el mismo nivel de rendimiento que en las GPUs. También puedes cambiar las dimensiones del encabezado para que estén más optimizadas para las TPU, pero este cambio invalida los pesos del modelo existentes, lo que requiere un nuevo entrenamiento.
Principios de comparativas
Para proporcionar evaluaciones justas y preparadas para el futuro, considera los siguientes principios para la comparativa en los diferentes aceleradores:
- Enfócate en el rendimiento por dólar: Algunos proveedores se enfocan en el rendimiento sin procesar de un solo chip, pero el rendimiento por dólar a nivel del sistema es más representativo del costo total de propiedad (TCO) y el valor generales. Si el chip A es un 20% más eficiente y un 50% más caro que el chip B, los evaluadores deben reconocer las ganancias de rendimiento por dólar del chip B. También considera el rendimiento por vatio como parte del costo.
- Representan cargas de trabajo de IA modernas: Se enfocan en modelos populares basados en transformadores, clústeres grandes y los frameworks más recientes, y tienen en cuenta las tendencias de la industria. Por ejemplo, el cambio de la industria hacia modelos de mezcla de expertos (MoE) más dispersos dificulta la optimización completa de las FLOPS y exige un mayor ancho de banda de bisección de las redes.
- Garantiza una amplia compatibilidad con los requisitos de los desarrolladores: Ten en cuenta el rendimiento, la flexibilidad y la escalabilidad en diferentes cargas de trabajo: entrenamiento, ajuste y entrega en una variedad de LLM y otros modelos.
- Elige modelos y herramientas independientes del proveedor: Elige modelos y motores que se ejecuten en todos los aceleradores para facilitar las evaluaciones entre aceleradores. Por ejemplo, usa modelos abiertos, como Qwen y Gemma, así como motores de inferencia de código abierto que se ejecutan en GPUs y TPUs, como vLLM. Evita las pilas de PyTorch/CUDA específicas del hardware. Para la comparativa del entrenamiento de modelos, los frameworks específicos del proveedor (como MaxText para las TPU y Megatron para las GPU) son los más útiles cuando los modelos se mantienen constantes en todas las plataformas.
- Diseño conjunto del modelo: Los usuarios experimentados diseñan sus modelos en conjunto para aprovechar al máximo la plataforma de hardware. No esperes que un modelo entrenado en el chip A tenga un buen rendimiento "listo para usar" en el chip B.
- Considera todo el sistema de hardware: Algunos aceleradores pueden anunciar un alto rendimiento en un área, como FLOPS. Sin embargo, los cuellos de botella en otras áreas, como el ancho de banda de la memoria, pueden limitar significativamente las capacidades del acelerador. Otros aspectos del sistema que se deben tener en cuenta son las especificaciones del chip, la conexión en red del chip y la arquitectura de expansión horizontal.
- Confiabilidad del hardware y el software: Las interrupciones durante el entrenamiento a gran escala o las operaciones de inferencia críticas pueden ser extremadamente costosas. Del mismo modo, un acelerador de IA solo es útil si el software que se ejecuta en él también lo es. Una pila de software confiable y madura, probada a gran escala, es esencial para maximizar el valor.
Microbenchmarks
En el contexto de la evaluación comparativa de aceleradores, la microevaluación comparativa aísla componentes de hardware específicos, como núcleos de procesamiento, memoria e interconexiones, para medir sus límites absolutos sin la interferencia de pilas de software complejas. Muchos proveedores destacan los "FLOPS máximos de un solo chip", pero la IA del mundo real es un problema de sistemas distribuidos. Las comparativas de microbenchmarking te ayudan a comprender si un chip es potente de forma aislada o si está diseñado para la escala del centro de datos.
Usa la microcomparativa para medir el rendimiento máximo del hardware y conocer los límites reales del sistema, independientemente de la arquitectura del modelo. Las comparativas de microbenchmarking son especialmente valiosas cuando se evalúan los aceleradores en relación con casos de uso y arquitecturas de modelos futuros o indeterminados.
Para realizar microcomparativas de forma eficaz, evalúa lo siguiente:
| Comparativa | Explicación |
|---|---|
| Utilización de la multiplicación de matrices general (GEMM) densa | Ejecuta kernels de GEMM altamente optimizados en varias precisiones para medir la potencia de procesamiento matemático bruta y sostenida de las unidades de procesamiento centrales del acelerador. |
| Transmisión de memoria de alto ancho de banda (HBM) | Ejecuta comparativas de microvelocidad del ancho de banda de memoria para medir las velocidades sostenidas de lectura, escritura y copia de la memoria integrada del acelerador. Las arquitecturas que mantienen una relación saludable entre bytes y FLOP evitan que los núcleos de procesamiento permanezcan inactivos. |
| Colectivos distribuidos (all-reduce y all-gather) | Ejecuta pruebas de comunicación colectiva estandarizadas en miles de chips para medir el grado de degradación del ancho de banda y la latencia de la red a medida que se escala el clúster. |
| Velocidades de transferencia de host a dispositivo (H2D) y de dispositivo a host (D2H) | Envía grandes flujos continuos de datos entre la memoria del sistema de la CPU del host y el acelerador para medir las tasas de transferencia a través del bus PCIe o la interconexión personalizada. |
| Limitación térmica y consumo de energía sostenidos | Ejecuta un bucle GEMM de utilización máxima de forma continua durante 48 horas mientras supervisas el consumo de energía a nivel del rack para evaluar la estabilidad térmica sostenida y la eficiencia energética en el mundo real. |
Ejemplo de comparación de microcomparativas
A continuación, se muestra una comparación ilustrativa entre dos chips, en la que un chip A hipotético podría parecer mejor que un chip B hipotético, pero tener un peor rendimiento en la práctica:
| Nombre de la comparativa | Resultado de la prueba del chip A | Especificación del chip A | Relación entre pruebas y especificaciones | Resultado de la prueba del chip B | Especificaciones del chip B | Relación entre pruebas y especificaciones |
|---|---|---|---|---|---|---|
| Redes chip a chip | 800 Gbps | 1,000 GBps | 80% | 850 GBps | 900 GBps | 94.4% |
| gemm/peakTOPS | 1,800 TFLOPS | 2,500 TFLOPS | 72% | 1,800 TFLOPS | 2,000 TFLOPS | 90.0% |
| Ancho de banda de la memoria | 6,000 GBps | 8,000 GBps | 75% | 6,500 GBps | 7,500 GBps | 86.7% |
| Del host al dispositivo | 58 GBps por chip | 70 GBps por chip | 82.9% | 60 GBps por chip | 65 GBps por chip | 92.3% |
| Del dispositivo al host | 55 GBps por chip | 70 GBps por chip | 78.6% | 55 GBps por chip | 65 GBps por chip | 84.6% |
Análisis de la línea del techo
Un análisis de techo (o modelo de techo) puede proporcionarte una visualización para analizar la intensidad operativa (OI) de los diferentes componentes del sistema y qué tan bien se adaptan los diseños específicos a las plataformas específicas.
El rendimiento de un chip acelerador de IA está limitado por tres factores principales:
- Capacidad de procesamiento: Es el rendimiento matemático máximo del chip (FLOPS).
- Ancho de banda de la memoria: Es la velocidad a la que se pueden transferir datos hacia o desde la memoria con ancho de banda alto (HBM) local del chip.
- Ancho de banda de la red: Es la velocidad a la que se pueden compartir datos entre varios chips a través de la red de chips durante el entrenamiento o la inferencia distribuidos. Por ejemplo, la tasa de transferencia de ICI (para las TPU) o NVLink (para las GPU).
Para obtener más información sobre los rooflines, consulta All About Rooflines.
El gráfico de techo estándar consta de dos ejes:
- Eje X (intensidad operativa): La intensidad operativa es la proporción del trabajo de procesamiento (FLOPS) con respecto al tráfico de memoria (bytes transferidos), expresada como FLOPS por byte. Representa la cantidad de trabajo de procesamiento realizado por cada byte de datos recuperado de la memoria.
- Eje Y (rendimiento alcanzable): El rendimiento alcanzable se expresa en FLOPS por segundo. Representa la capacidad de procesamiento computacional real alcanzada.
El "techo" se forma con dos líneas que se cruzan y representan los máximos de hardware:
- El techo inclinado (vinculado a la memoria): Rendimiento alcanzable = Ancho de banda máximo de la memoria × Intensidad operativa. En esta línea, el rendimiento está estrictamente limitado por la velocidad con la que se pueden proporcionar datos a las unidades de procesamiento.
- El techo plano (vinculado a la capacidad de procesamiento): Rendimiento alcanzable = Capacidad máxima de procesamiento. En esta línea, los datos se suministran con la suficiente rapidez como para que las unidades de procesamiento funcionen a su máxima capacidad.
El punto en el que se cruzan estas dos líneas se conoce como punto de cresta. Define el OI mínimo que requiere una carga de trabajo para lograr la máxima utilización del hardware.
En la imagen anterior, el algoritmo 1 se encuentra en la parte del gráfico etiquetada como "limitado por la memoria" y no utiliza por completo las unidades de procesamiento. En cambio, el algoritmo 2 tiene un OI más alto y se encuentra en la parte del gráfico etiquetada como "vinculado a la capacidad de procesamiento". Para optimizar el algoritmo 1, un usuario intentaría modificarlo para que realice más cálculos con menos movimiento de datos (aumentar el OI) y, así, desplazar el rendimiento hacia la derecha, hacia el punto de cresta.
Ejemplos de cargas de trabajo de OI bajas y altas
- Baja intensidad operativa de HBM (vinculada a la memoria): Cargas de trabajo como operaciones a nivel de los elementos (funciones de activación como ReLU o GeLU), normalización de capas y decodificación autorregresiva (inferencia con tamaño de lote = 1).
- Alta intensidad operativa de HBM (límite de procesamiento): Cargas de trabajo como GEMM o redes neuronales convolucionales de lotes grandes La multiplicación de matrices reutiliza los datos recuperados muchas veces (multiplicando filas por columnas), por lo que la OI es muy alta y las cargas de trabajo se encuentran bajo el techo de procesamiento plano.
Comparativa de modelos
La comparación de modelos mide el rendimiento real de los modelos. Los comparativos de entrenamiento y de inferencia te permiten comparar el rendimiento de los modelos populares en un momento específico.
En la siguiente tabla, se comparan las estadísticas que puedes obtener de la comparativa del modelo para las cargas de trabajo de entrenamiento y de inferencia:
| Estadística | Cargas de trabajo de entrenamiento | Cargas de trabajo de inferencia |
|---|---|---|
| Escala | A menudo, se realizan pruebas a mayor escala (más de 10,000 chips y hasta más de 100,000 para los modelos más grandes). Proporciona estadísticas sobre las cargas de trabajo distribuidas, la sobrecarga de comunicación y los límites de redes a nivel del clúster. | A menudo, se realizan pruebas más pequeñas (de 1 a más de 64 chips). Proporciona estadísticas sobre cómo la plataforma maneja a los usuarios simultáneos y el aumento rápido de la escala bajo carga. |
| Rendimiento | Suele estar más limitado por la capacidad de procesamiento. Mide los tokens procesados por segundo por chip y la utilización de FLOPs del modelo (MFU). | Sensible a la latencia. Mide el tiempo hasta el primer token (TTFT), la latencia entre tokens y la cantidad total de tokens generados por segundo y por usuario. |
| Latencia | Latencia de E/S y de interconexión que destaca los cuellos de botella de almacenamiento cuando se cargan conjuntos de datos grandes y la latencia de red entre los nodos durante las actualizaciones de gradientes síncronas | Latencia de respuesta de extremo a extremo que destaca los retrasos en la cola, la latencia del extremo y los tiempos de espera para el usuario. |
Comparativas de entrenamiento
Para determinar la verdadera eficiencia del hardware y las redes, debes normalizar el rendimiento en una sola métrica comparable en todos los aceleradores: tokens por segundo por chip (TPS/chip), mientras mantienes constante una arquitectura de modelo específica y representativa. Si haces un seguimiento del comportamiento de los TPS/chip a medida que escalas el tamaño de un clúster, descubrirás el "impuesto de escala" oculto del sistema.
Para normalizar el rendimiento con el costo de los aceleradores, divide aún más los TPS/chip por el costo de cada chip para obtener TPS/chip/USD, que se convierte en otro punto de comparación.
Para cada modelo que se compara, evalúa lo siguiente:
| Comparativa | Explicación |
|---|---|
| Medir los TPS de referencia por chip y los TPS por chip/USD |
Ejecuta el modelo de destino en el clúster viable más pequeño. Registra la capacidad de procesamiento global del entrenamiento (cantidad total de tokens procesados por segundo) y divídela por la cantidad de chips para establecer el TPS/chip de referencia. Divide el resultado por el costo del acelerador para obtener la cantidad de TPS por chip y por USD. Como otra opción, observa la utilización de FLOPs del modelo (MFU) durante el entrenamiento para medir la proporción de la capacidad de procesamiento observada en relación con la capacidad máxima teórica. Esto es útil para comprender qué tan cerca del rendimiento del hardware se encuentra la evaluación comparativa. Sin embargo, no proporciona una comparación chip a chip tan útil como la de TPS/chip. |
| Evalúa la degradación del escalamiento | Escala el clúster a 256, 1,024 y 4,096 chips, y ejecuta el mismo modelo. Vuelve a calcular el TPS por chip en cada escala. |
| Ten en cuenta el rendimiento útil |
El TPS sin procesar por chip solo importa si el modelo realmente aprende. Calcula el buen rendimiento para medir la tasa de procesamiento útil que avanza directamente el estado de entrenamiento de un LLM, lo que excluye explícitamente el tiempo y la energía desperdiciados en fallas de hardware, interrupciones de red o recuperaciones de puntos de control. Cuando se evalúan los aceleradores de IA a gran escala, el buen rendimiento proporciona una imagen más realista del retorno de la inversión que la capacidad de procesamiento teórica sin procesar, ya que revela con qué eficacia el hardware mantiene el rendimiento en clústeres propensos a errores del mundo real. |
En la siguiente tabla, se enumeran los modelos recomendados para la comparativa del entrenamiento:
| Tamaño | Arquitectura | Modelo | Razones |
|---|---|---|---|
| Pequeño (8B) | Densa | Llama 3.1 8B | Llama 3 ha sido un modelo estándar, popular con los estándares de comparativas como MLPerf durante varios años. |
| Medio (70B) | Densa | Llama 3.1 70B | Llama 3 ha sido un modelo estándar, popular con los estándares de comparativas como MLPerf durante varios años. |
| Grande (671 mil millones) | MoE | DeepSeek-V3 671B | DeepSeek-V3 estableció un nuevo estándar de tamaño y rendimiento en 2025, y está bien optimizado en muchas plataformas de varios chips. |
Ejemplo: Normalización del rendimiento por dólar
Considera una comparación de referencia entre Chip_A, Chip_B y Chip_C, en la que ejecutaste comparativas de entrenamiento para modelos comunes y observaste el rendimiento en TPS. Luego, observas la proporción del rendimiento de Chip_A en relación con el rendimiento de Chip_B y Chip_C para el mismo modelo:
| Comparativa | TPS de Chip_A como fracción del TPS de Chip_B | TPS de Chip_A como fracción del TPS de Chip_C |
|---|---|---|
| Pequeño y denso: Llama 3.1 8B | 0.82 | 0.62 |
| MoE: Mixtral 8x7B | 0.72 | 0.55 |
| Grande y denso: Llama 3.1 405B | 0.77 | 0.61 |
| MoE grande: DeepSeek-V3 | 0.85 | 0.62 |
| Valor promedio | 0.79 | 0.60 |
Según los datos de la tabla anterior, el rendimiento de Chip_A promedia el 0.79 del rendimiento de Chip_B y el 0.60 del rendimiento de Chip_C. Sin más información, la conclusión sería que Chip_C es superior.
Sin embargo, si el chip A cuesta USD 100, el chip B cuesta USD 180 y el chip C cuesta USD 200, la normalización del rendimiento por dólar (rend/USD) cambia el resultado:
| Comparativa | Chip_A perf/$ como fracción de Chip_B perf/$ | Chip_A perf/$ como fracción de Chip_C perf/$ |
|---|---|---|
| Pequeño y denso: Llama 3.1 8B | 1.48 | 1.24 |
| MoE: Mixtral 8x7B | 1.30 | 1.10 |
| Grande y denso: Llama 3.1 405B | 1.39 | 1.22 |
| MoE grande: DeepSeek-V3 | 1.53 | 1.24 |
| Valor promedio | 1.42 | 1.20 |
Si consideras el rendimiento por dólar como punto de comparación, el chip A supera al chip B en un 42% en promedio y al chip C en un 20% en promedio.
Comparativas de inferencia
El entrenamiento es una gran inversión inicial de capital, pero la entrega (y, por lo tanto, la inferencia) representa un gasto operativo a largo plazo. Un mayor TPS por chip significa que necesitas menos servidores físicos para admitir las mismas cargas de trabajo operativas, lo que reduce drásticamente el consumo de energía y la huella del centro de datos.
En la inferencia, el objetivo es maximizar la capacidad de procesamiento sin incumplir los requisitos de latencia para garantizar una experiencia del usuario responsiva. Si estandarizas la evaluación en TPS/chip para un modelo fijo, puedes comparar directamente el rendimiento en diferentes chips.
Cuando realices comparativas de la inferencia, normaliza el rendimiento calculando TPS/chip/USD:
| Comparativa | Explicación |
|---|---|
| Establece el ANS de latencia |
Primero, establece un ANS estricto para la experiencia del usuario. Por ejemplo, una latencia de cola predecible (P99) de 100 milisegundos. Mide la experiencia del usuario en cuanto a la capacidad de respuesta con el TTFT (menos de 500 ms) y el tiempo por token de salida (TPOT). |
| Aumenta el tamaño del lote | Aumenta gradualmente la cantidad de solicitudes simultáneas (tamaño del lote) en el hardware. A medida que aumenta el tamaño del lote, también lo hace la capacidad de procesamiento, pero la latencia se degrada con el tiempo. |
| Registra el valor máximo de TPS sostenido por chip |
Cuando el hardware incumpla el ANS de latencia de P99, detente. Registra la capacidad de procesamiento total del sistema para ese tamaño de lote exacto y divídela por la cantidad de chips. Este es el valor de TPS por chip. Ten en cuenta que algunos aceleradores de uso general tienen problemas con la "latencia de cola" (picos aleatorios en el tiempo de procesamiento) con cargas de procesamiento por lotes altas, lo que obliga a los operadores a ejecutarlos con un uso menor para mantener a los usuarios satisfechos. Asegúrate de realizar mediciones en las dos fases distintas de la función de completar previamente (vinculada a la capacidad de procesamiento) y decodificación (vinculada al ancho de banda de la memoria). |
| Calcula el TCO por cada mil o millón de tokens | Divide el costo amortizado de capital y energía de un chip por su TPS máximo sostenido por chip. Esto traduce la comparativa técnica en una métrica financiera, lo que revela el costo real. |
En la siguiente tabla, se enumeran los modelos recomendados para la comparativa de inferencia:
| Tamaño | Arquitectura | Modelo | Razones |
|---|---|---|---|
| Pequeño (8B) | Densa | Llama 3.1 8B | Llama 3 ha sido un modelo estándar, popular con los estándares de comparativas como MLPerf durante varios años. |
| Medio (70B) | Densa | Llama 3.1 70B | Llama 3 ha sido un modelo estándar, popular con los estándares de comparativas como MLPerf durante varios años. |
| Grande (480B) | MoE | Qwen3 Coder 480B | Qwen3 480B es un modelo de codificación de OSS líder. |
¿Qué sigue?
- Arquitectura de Cloud TPU
- Recetas de rendimiento de Cloud TPU
- Documentación de vLLM en TPU
- MaxText para entrenar modelos en TPU
- Modelo de techo en Wikipedia