Los lazos entre AMD y Google ponen a prueba la alianza de Meta en IA frente a Nvidia

AMD ha convertido una exhibición para socios de 2024 en una campaña de infraestructura para 2026, pese al persistente dominio de Nvidia sobre el software utilizado para crear modelos de IA. La relación entre AMD y Google aporta credibilidad en la nube, mientras Meta compromete cargas de trabajo, aportes de ingeniería y hasta seis gigavatios de capacidad de GPU planificada.

Esa combinación importa más que otra victoria en benchmarks. AMD está pidiendo a los principales desarrolladores de modelos y proveedores de nube que ayuden a optimizar toda la pila informática, desde el silicio y las redes hasta los frameworks y el código de los modelos. La estrategia desafía a Nvidia donde su ventaja históricamente ha sido más sólida: una plataforma integrada que los desarrolladores ya conocen.

El anuncio original reunió a Meta, Google Cloud, Microsoft, Oracle y varios desarrolladores de IA en torno al hardware de AMD y su software ROCm. Las alianzas no eliminaron de inmediato los costes de migración ni establecieron una paridad de rendimiento generalizada. Sin embargo, compromisos posteriores de Meta y otros desarrolladores de modelos muestran que el esfuerzo ha avanzado más allá de un lanzamiento de producto de un solo día.

Lo que AMD y sus socios realmente cambiaron

El movimiento importante de AMD fue abrir su hoja de ruta de productos a clientes cuyas cargas de trabajo pueden dar forma al hardware y al software.

En su evento Advancing AI de octubre de 2024, AMD presentó el acelerador Instinct MI325X, procesadores para servidores EPYC de quinta generación, nuevos componentes de red y chips empresariales Ryzen AI. La empresa también describió el trabajo continuo en ROCm, su plataforma de software de código abierto para programar GPU de AMD.

Las revelaciones de los socios dieron un contexto práctico a aquel anuncio de hardware. Según el lanzamiento de productos de IA de AMD, Meta atendía todo el tráfico en vivo de su modelo Llama 3.1 405B con aceleradores MI300X. AMD también afirmó que más de un millón de modelos podían ejecutarse en su plataforma sin trabajo adicional de adaptación.

El papel de Meta fue más allá de comprar chips. Las empresas estaban optimizando el rendimiento en silicio, sistemas completos, redes, software y aplicaciones. Ese alcance importa porque un procesador rápido no puede rescatar un clúster limitado por el movimiento de memoria, la congestión de interconexión o kernels de software poco maduros.

Google desempeñó un papel distinto. Destacó los procesadores AMD EPYC dentro de la infraestructura de Google Cloud, incluidas cargas de trabajo conectadas con su arquitectura AI Hypercomputer. Google también planeaba máquinas virtuales en la nube basadas en los procesadores EPYC 9005 más recientes de AMD.

Esto no suponía afirmar que Google hubiera sustituido sus propias unidades de procesamiento tensorial, o TPU, por GPU de AMD. Google diseña TPU para determinadas cargas de trabajo internas y de IA en la nube. También opera una plataforma de nube diversa en la que los clientes esperan varias arquitecturas de procesador.

Por tanto, la relación entre AMD y Google representa una elección de infraestructura, no una alianza exclusiva. Google puede ofrecer computación impulsada por AMD mientras sigue desarrollando TPU, procesadores Axion basados en Arm y servicios construidos en torno a aceleradores Nvidia.

Microsoft y Oracle aportaron más pruebas de la demanda de clientes. Microsoft describió el uso de MI300X con Azure y cargas de trabajo de GPT, mientras Oracle analizó los productos de CPU, GPU y redes de AMD dentro de su plataforma en la nube.

Databricks aportó una de las afirmaciones de rendimiento más concretas. Sus pruebas supuestamente mostraron una mejora superior al 50 por ciento en modelos Llama y propietarios al utilizar hardware MI300X. Esa cifra procedía de una prueba de un socio destacada por AMD, por lo que no debe tratarse como un resultado universal.

El cambio central fue más amplio que una colección de respaldos. AMD estaba creando ciclos de retroalimentación con empresas que operan grandes modelos en producción. Esas empresas podían identificar cuellos de botella, influir en el diseño de productos y aportar optimizaciones que heredarían los usuarios posteriores.

Desde entonces, ese enfoque se ha vuelto más concreto. AMD afirmó en 2025 que siete de los diez mayores desarrolladores de modelos y empresas de IA ejecutaban cargas de trabajo de producción en aceleradores Instinct. Meta informó de una implementación más amplia de MI300X para la inferencia de Llama 3 y Llama 4.

Las alianzas abarcan ahora generaciones sucesivas de hardware. Esa continuidad distingue un despliegue estratégico de un experimento temporal realizado cuando el suministro de aceleradores era escaso.

Por qué la infraestructura de AMD y Google importa ahora

La conexión entre AMD y Google importa porque una competencia creíble requiere distribución, acceso para desarrolladores y operaciones de nube repetibles, no solo chips más rápidos.

Google Cloud ha seguido ampliando su cartera de CPU de AMD desde el evento de 2024. Sus máquinas virtuales C4D combinan procesadores EPYC de quinta generación con la infraestructura Titanium de Google, que descarga determinadas tareas de red, almacenamiento y gestión de la CPU anfitriona.

Google informó de un rendimiento de servicio web hasta un 80 por ciento superior y un rendimiento de computación general un 30 por ciento mejor que la generación previa basada en AMD. Sus resultados de rendimiento de C4D también citaron una latencia de almacenamiento local hasta un 35 por ciento menor.

No se trata de mediciones directas del entrenamiento de IA generativa. Sin embargo, los sistemas de IA dependen de más elementos que los aceleradores. La preparación de datos, los servicios de recuperación, las bases de datos, la programación y los servidores de aplicaciones consumen capacidad convencional de CPU.

Una aplicación de IA puede generar respuestas en una GPU mientras utiliza CPU para autenticar usuarios, recuperar documentos, filtrar resultados y enrutar solicitudes. Mejorar esas tareas circundantes puede elevar el rendimiento del sistema aunque el modelo permanezca sin cambios.

La alianza entre AMD y Google también amplía los lugares en los que los equipos de ingeniería pueden encontrarse con hardware de AMD. La familiaridad importa porque las empresas dudan en introducir una segunda plataforma de aceleradores cuando los desarrolladores no tienen acceso para realizar pruebas y optimizaciones.

La disponibilidad en la nube reduce esa barrera. Un equipo puede perfilar una carga de trabajo, verificar la compatibilidad de bibliotecas y comparar el comportamiento operativo antes de asumir un compromiso de infraestructura mayor. También puede mantener las cargas de trabajo de CPU en una nube conocida mientras evalúa un entorno de aceleradores diferente en otro lugar.

La oportunidad de AMD ha crecido a medida que la inferencia consume una mayor proporción de la computación de IA. La inferencia es el proceso de ejecutar un modelo entrenado para producir una respuesta, clasificación, imagen u otra salida. A diferencia de una ejecución de entrenamiento limitada, los gastos de inferencia se repiten con cada interacción de usuario.

Ese coste recurrente da a los operadores de modelos una razón para optimizar el hardware para cargas de trabajo concretas. Un acelerador de propósito general ofrece flexibilidad, pero puede incluir recursos de memoria o computación que una tarea de producción definida de forma precisa no necesita.

Los sistemas de recomendación de Meta ilustran este punto. Funcionan a una escala inmensa y utilizan patrones de carga de trabajo relativamente estables. Un procesador adaptado a esos patrones puede priorizar el coste, el consumo de energía o la latencia frente a las amplias capacidades que exige la investigación de modelos de frontera.

Google afronta la misma lógica económica, aunque aborda el problema en parte mediante sus propios TPU. Su disposición a desplegar CPU de AMD demuestra que los hyperscalers no necesitan una única arquitectura de procesador en todas las capas.

En consecuencia, la relación entre AMD y Google es una parte de un cambio más amplio hacia la computación heterogénea. En esos sistemas, los operadores asignan cada carga de trabajo al procesador, acelerador o chip personalizado que mejor se ajusta a ella.

Este cambio presiona a Nvidia sin obligar a los clientes a abandonar Nvidia. Un proveedor de nube puede seguir ofreciendo sistemas Nvidia mientras añade hardware de AMD o diseñado internamente para trabajos seleccionados. Incluso una diversificación parcial puede mejorar el poder de negociación y reducir la dependencia de una sola hoja de ruta.

Para los desarrolladores, la cuestión práctica es si las cargas de trabajo siguen siendo portables. Un modelo que funciona bien solo tras una amplia reescritura específica de un proveedor genera costes de cambio que pueden superar un benchmark de hardware favorable.

ROCm es la respuesta de AMD a ese problema. Su valor depende de la compatibilidad con frameworks, la documentación, las herramientas de depuración, las bibliotecas optimizadas y el soporte rápido para los modelos recién lanzados. La disponibilidad de hardware significa poco cuando un equipo de producción no puede reproducir el comportamiento de su software existente.

Meta convierte las conversaciones sobre alianzas en una prueba de seis gigavatios

Meta ha transformado el argumento de ecosistema de AMD en una prueba de despliegue con hitos medibles y un riesgo de ejecución material.

En febrero de 2026, AMD y Meta anunciaron un acuerdo plurianual que cubre hasta seis gigavatios de despliegues de GPU AMD Instinct. Los gigavatios describen capacidad eléctrica, no un número fijo de aceleradores, porque la configuración del sistema y los requisitos de energía pueden variar.

Está previsto que el primer gigavatio comience a enviarse durante la segunda mitad de 2026. Utilizará un acelerador personalizado basado en la arquitectura MI450, procesadores EPYC de sexta generación, software ROCm y el diseño a escala de rack Helios de AMD.

Un sistema a escala de rack trata un rack completo de servidores como una unidad informática integrada. Los aceleradores, las CPU, la memoria, las redes, la refrigeración y el software deben trabajar juntos para ofrecer un rendimiento útil de los modelos.

AMD afirmó que Helios fue desarrollado conjuntamente con Meta a través del Open Compute Project. La especificación Open Rack Wide de Meta influyó en el diseño físico, dando a AMD una vía de entrada a infraestructura organizada en torno a los requisitos operativos de Meta.

El acuerdo de despliegue de Meta también alinea las hojas de ruta de silicio, sistemas y software de las empresas. Esa redacción indica una coordinación más profunda que comprar tarjetas aceleradoras estándar después de que comience la producción.

Meta actuará como cliente principal de los procesadores para servidores Venice y Verano de AMD. Se espera que Verano incluya cambios específicos para cargas de trabajo, diseñados en torno al rendimiento, el consumo de energía y el coste operativo.

El acuerdo contiene una garantía basada en el rendimiento que cubre hasta 160 millones de acciones de AMD. La consolidación depende de los volúmenes de envío, los umbrales de cotización de AMD y condiciones técnicas y comerciales. La presentación del primer trimestre de AMD indicó que ninguna de esas acciones se había consolidado al 28 de marzo de 2026.

Estas condiciones importan porque la capacidad anunciada no es lo mismo que un despliegue completado. AMD debe fabricar los productos, ensamblar sistemas, dar soporte al software y satisfacer los requisitos de Meta. Meta debe entonces instalar la capacidad y dirigir hacia ella cargas de trabajo significativas.

El acuerdo también demuestra por qué AMD necesita la participación de los desarrolladores de modelos. Meta conoce las características a nivel de operador de la inferencia de Llama, los sistemas publicitarios, los modelos de clasificación y su asistente de IA en expansión. Ese conocimiento de las cargas de trabajo puede influir en la capacidad de memoria, el diseño de interconexión y las prioridades de software.

AMD gana un cliente de referencia exigente. Meta obtiene un proveedor alternativo y una plataforma personalizada para tareas seleccionadas. Ambas partes ganan poder de negociación frente a un mercado de aceleradores que sigue definido por Nvidia.

El acuerdo no implica una migración completa de Meta. Meta también ha asumido compromisos sustanciales con Nvidia y continúa desarrollando su propio Meta Training and Inference Accelerator, o MTIA.

Esa combinación es racional. El entrenamiento de frontera, la inferencia para recomendaciones y los servicios generales de IA no imponen requisitos idénticos. Meta puede utilizar Nvidia para algunas cargas de trabajo, productos AMD personalizados para otras y MTIA cuando el silicio interno ofrezca la economía adecuada.

Por tanto, la competencia principal no es AMD frente a Nvidia para cada trabajo de IA. Es un modelo predeterminado integrado de Nvidia frente a una estrategia de computación multivendedor configurada en torno a cargas de trabajo específicas.

El plan de seis gigavatios pondrá a prueba si esa alternativa sigue siendo manejable a escala de producción. Operar dos plataformas de aceleradores aumenta los requisitos de calificación, observabilidad, personal y mantenimiento de software.

Meta puede absorber más de esa complejidad que una empresa típica. Si sus optimizaciones se incorporan a ROCm y a los frameworks comunes, los usuarios más pequeños pueden beneficiarse. Si permanecen muy personalizadas, el acuerdo dirá menos sobre la accesibilidad más amplia de AMD.

El mecanismo es el codiseño de hardware y software

AMD puede reducir la brecha de rendimiento cuando los clientes ayudan a optimizar conjuntamente modelos y sistemas, pero el codiseño debe generar software reutilizable para transformar el mercado.

El rendimiento de un modelo no depende únicamente de las especificaciones nominales del chip. Los operadores deben coordinar la arquitectura del modelo, la precisión numérica, la ubicación de la memoria, las bibliotecas de comunicación, el comportamiento del compilador y la programación de tareas.

La precisión numérica determina cuántos bits representan los pesos del modelo y los valores intermedios. Una menor precisión puede reducir el uso de memoria y aumentar el rendimiento, siempre que el modelo mantenga una calidad de salida aceptable.

La ubicación de la memoria es igual de importante. Los modelos grandes trasladan constantemente pesos y datos temporales entre memoria de alto ancho de banda, aceleradores y enlaces de red. Un procesador puede permanecer inactivo cuando esas transferencias no logran mantener ocupadas sus unidades de cómputo.

Los kernels de software ejecutan operaciones individuales como la multiplicación de matrices, la atención y la conversión de datos. Los proveedores ajustan esos kernels para hardware y formas de modelo concretos. Pequeñas mejoras pueden acumularse a lo largo de miles de millones de operaciones repetidas.

Nvidia consolidó su ventaja al combinar hardware con CUDA, bibliotecas optimizadas, herramientas para desarrolladores y soporte de frameworks mantenido durante años. Las organizaciones han acumulado código CUDA, experiencia y prácticas de resolución de problemas durante mucho tiempo.

ROCm utiliza un modelo de código abierto y admite frameworks ampliamente usados como PyTorch. La apertura puede ayudar a los desarrolladores a inspeccionar código, aportar cambios y evitar la dependencia de una única capa de programación propietaria.

El código abierto no genera automáticamente madurez operativa. Los equipos siguen necesitando versiones estables, instalaciones predecibles, cobertura completa de funciones, diagnósticos claros y rendimiento en cargas de trabajo diversas.

Las alianzas de AMD con creadores de modelos abordan directamente esas brechas. Meta aporta experiencia con PyTorch, Triton e inferencia a gran escala. Microsoft y Oracle aportan conocimientos sobre despliegues en la nube. Los desarrolladores independientes pueden optimizar motores como vLLM y SGLang.

La actualización de plataforma de AMD de 2025 informó de mejoras en ROCm 7, mayor compatibilidad y nuevas herramientas de desarrollo. La compañía también afirmó que su generación MI350 logró grandes avances frente a MI300X, aunque las comparaciones de proveedores dependen en gran medida del modelo, el tamaño de lote, la precisión y la configuración del sistema.

La participación en benchmarks independientes ofrece una mejor vía de escrutinio. MLPerf publica resultados enviados bajo cargas de trabajo y reglas definidas, lo que ayuda a los compradores a comparar sistemas sin depender únicamente de presentaciones de lanzamiento.

La base de datos de resultados de MLPerf incluye envíos de AMD Instinct junto con sistemas que usan aceleradores de Nvidia y otros proveedores. Los resultados aún requieren una lectura cuidadosa porque pueden diferir los recuentos de hardware, las versiones de software, las restricciones de latencia y las divisiones del benchmark.

Un resultado ganador en una categoría no establece un liderazgo universal. Sí demuestra si los proveedores pueden presentar sistemas funcionales bajo reglas comunes y revelar suficientes detalles de configuración para una comparación informada.

Google añade otra dimensión a este mecanismo. Su nube utiliza procesadores AMD EPYC mientras Google desarrolla TPUs y su propio software de soporte. Esta coexistencia demuestra que las empresas de infraestructura pueden optimizar en múltiples capas sin elegir a un solo proveedor para todo.

La relación entre AMD y Google no resuelve directamente la adopción de ROCm. Sin embargo, normaliza la diversidad arquitectónica dentro de una gran nube y crea oportunidades para la tecnología de AMD en cargas de trabajo adyacentes a la IA.

Meta aporta una prueba más sólida para los aceleradores. Al atender tráfico de Llama en MI300X y codiseñar sistemas basados en MI450, proporciona a AMD comentarios reales de producción que un benchmark sintético no puede ofrecer.

La cuestión decisiva es si AMD puede convertir estas lecciones específicas de clientes en capacidades predeterminadas. El soporte de modelos desde el día cero, es decir, soporte utilizable cuando se lanza un modelo, será un indicador.

La calidad de la documentación será otro. Los desarrolladores juzgan las plataformas durante instalaciones fallidas, errores de memoria, operadores no compatibles y regresiones de rendimiento. Una plataforma debe hacer que esos fallos sean comprensibles y corregibles.

El codiseño funciona cuando acorta el camino desde un modelo nuevo hasta un servicio de producción fiable. Se queda corto cuando cada despliegue requiere que un equipo privado del proveedor de chips reconstruya la pila de software.

Lo que la narrativa de alianzas de AMD no demuestra

Los grandes compromisos de clientes validan la demanda, pero todavía no demuestran una paridad amplia de software, entregas a escala ni una economía superior.

Los anuncios de AMD contienen varias capas de rendimiento informado por la propia empresa. Las afirmaciones sobre rendimiento, eficiencia energética y mejoras generacionales a menudo se basan en configuraciones seleccionadas. Los compradores deberían comparar sus propios modelos bajo los requisitos de latencia y calidad que les importan.

El rendimiento de inferencia es especialmente sensible al tamaño de lote. Un sistema puede informar un alto rendimiento total al procesar muchas solicitudes juntas y, aun así, ofrecer una demora inaceptable para un asistente interactivo.

La longitud del modelo también cambia el resultado. Los contextos largos consumen más memoria e incrementan el trabajo de atención. Una plataforma adecuada para recomendaciones breves podría comportarse de forma distinta al procesar documentos extensos o sesiones prolongadas de agentes.

La utilización del sistema también afecta a la economía. Un acelerador que parece eficiente a plena carga puede volverse caro cuando la demanda es irregular. Los operadores deben considerar la capacidad inactiva, las redes, el suministro eléctrico, la refrigeración y la mano de obra de ingeniería.

El plan de Meta de seis gigavatios introduce riesgo de fabricación. AMD depende de fundiciones y proveedores externos para chips avanzados, encapsulado, memoria y otros componentes. Un cuello de botella en cualquier capa puede ralentizar la entrega de sistemas completos.

Helios añade riesgo de integración porque los productos a escala de rack requieren coordinación entre CPU, GPU, tarjetas de interfaz de red, switches, software y refrigeración. Validar componentes individuales no garantiza una operación estable del clúster.

El informe anual de AMD de 2025 señaló que los envíos de producción de MI400 y Helios seguían en camino para la segunda mitad de 2026. Es una declaración importante sobre el calendario, no la confirmación de que el primer gigavatio planificado esté operativo.

El acelerador personalizado de Meta crea otra incertidumbre. La personalización puede mejorar la eficiencia para una carga de trabajo conocida al eliminar capacidad innecesaria o cambiar el equilibrio entre cómputo, memoria y redes.

La misma especialización puede limitar la flexibilidad. Si Meta cambia sus modelos o su arquitectura de servicio, un acelerador ajustado de forma estrecha podría ofrecer menos opciones que un sistema generalista. La compensación final dependerá de especificaciones no divulgadas y del comportamiento real de las cargas de trabajo.

Nvidia también continúa mejorando su hardware, redes, software de inferencia y sistemas a escala de rack. AMD compite contra una plataforma en movimiento, no contra los productos disponibles cuando se lanzó MI300X.

La estrategia de Google añade presión desde otra dirección. Los TPUs ofrecen a Google una alternativa integrada verticalmente para Gemini y determinados clientes de la nube. Amazon también desarrolla aceleradores Trainium e Inferentia, mientras Microsoft ha presentado silicio interno para IA.

Estas plataformas personalizadas significan que AMD compite por la parte de la computación de IA que los hiperescaladores prefieren abastecer externamente. Su mercado accesible puede crecer con rapidez y, aun así, afrontar una competencia más intensa por cada carga de trabajo.

La mención de AMD y Google también puede llevar a una conclusión inexacta. Que Google use procesadores EPYC no establece una adopción a gran escala de GPU Instinct por parte de Google para Gemini. La relación verificada se centra en CPU para la nube y una cooperación más amplia en infraestructura.

Del mismo modo, la adopción de Meta no demuestra que una empresa común pueda pasar de CUDA a ROCm sin fricciones. Meta cuenta con recursos de ingeniería, control sobre sus modelos y acceso directo a la hoja de ruta de AMD.

La interpretación más sólida es más acotada. AMD ha ganado suficiente confianza para que grandes clientes coloquen cargas de trabajo de producción y capacidad futura en su tecnología. Ahora debe convertir la colaboración a medida en una plataforma que otros desarrolladores puedan usar de forma fiable.

Esa distinción debería guiar las evaluaciones empresariales. Los compradores necesitan pruebas a nivel de carga de trabajo, costes operativos totales, compromisos de soporte de software y un plan de migración creíble. No deberían tratar el logotipo de un socio como sustituto de la validación técnica.

Tres señales decidirán si AMD puede presionar a Nvidia

Los envíos, el rendimiento de modelos portables y los despliegues repetibles de terceros determinarán si la coalición de AMD cambia el equilibrio competitivo.

La primera señal es el despliegue inicial de Meta basado en MI450. AMD programó envíos para respaldar el primer gigavatio en la segunda mitad de 2026. La evidencia de capacidad instalada, cargas de trabajo de producción y cumplimiento de hitos reforzaría el argumento de que el codiseño puede alcanzar escala física.

Un retraso importaría para más de un cliente. Helios es la plataforma con la que AMD espera impulsar sus ambiciones a escala de rack, por lo que los problemas podrían afectar despliegues posteriores y la confianza en toda su red de socios.

La segunda señal es el soporte de modelos fuera de proyectos privados de clientes. Los desarrolladores deberían observar con qué rapidez ROCm admite nuevos modelos abiertos relacionados con Llama, Claude y Gemini, además de otros lanzamientos ampliamente adoptados.

Un soporte útil implica más que iniciar un contenedor. Los equipos necesitan latencia competitiva, calidad de salida predecible, comportamiento estable con múltiples GPU y bibliotecas mantenidas. Los envíos públicos a benchmarks deberían aclarar las configuraciones de hardware y software detrás de cada resultado.

AMD amplió esta estrategia en julio de 2026 mediante un acuerdo para que Anthropic despliegue hasta dos gigavatios de GPU MI450 Series. Las compañías también planean usar Claude en trabajos destinados a mejorar las cargas de trabajo de AMD y el desarrollo de ROCm.

Ese acuerdo ofrece una nueva prueba. Si las optimizaciones producidas con Meta, Anthropic y desarrolladores de código abierto convergen en software público, la plataforma de AMD será más fácil de adoptar. Si cada cliente requiere una rama independiente, la escala seguirá siendo costosa.

La tercera señal es el uso repetible por parte de organizaciones sin equipos de ingeniería al nivel de los hiperescaladores. Oracle, los proveedores de nube, los fabricantes de sistemas y las empresas de software pueden revelar si Helios y ROCm funcionan como productos en lugar de proyectos de integración a medida.

La evidencia más persuasiva incluirá tráfico de producción sostenido, detalles operativos publicados y mediciones independientes. Los anuncios adicionales de capacidad por sí solos revelarán demanda, pero no facilidad de uso.

La creciente línea de CPU AMD de Google Cloud sigue siendo relevante aquí. La relación entre AMD y Google ofrece a los clientes acceso maduro a sistemas basados en EPYC y demuestra una confianza continua en la hoja de ruta de servidores de AMD. También recuerda que la infraestructura en la nube es cada vez más multivendedor por diseño.

Para desarrolladores y compradores empresariales, la acción inmediata es probar cargas de trabajo representativas en lugar de debatir en abstracto las afirmaciones de los proveedores. Utilicen el mismo modelo, tipos de datos, longitudes de contexto, objetivos de latencia y condiciones de fallo en todas las plataformas.

Los equipos también deberían preservar la evidencia detrás de cada decisión. Una base de conocimientos de ingeniería con búsqueda puede conectar resultados de benchmarks, notas de despliegue, cambios de modelo y documentación de proveedores a medida que las plataformas evolucionan.

La historia de AMD, Google y Meta se reduce en última instancia a si los desarrolladores de modelos pueden crear una segunda vía viable mediante ingeniería conjunta. Siga el primer despliegue de Meta, la disponibilidad pública de modelos en ROCm y las implementaciones de clientes convencionales. Si los tres avanzan, Nvidia se enfrentará a un competidor de plataforma duradero. Si uno se estanca, las alianzas de AMD seguirán siendo importantes, pero incompletas.