<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Transformers en Bucle on Korea Invest Insights</title><link>https://koreainvestinsights.com/es/tags/transformers-en-bucle/</link><description>Recent content in Transformers en Bucle on Korea Invest Insights</description><generator>Hugo -- gohugo.io</generator><language>es</language><copyright>koreainvestinsights.com · @korea_invest_insights</copyright><lastBuildDate>Tue, 08 Sep 2026 22:02:51 +0900</lastBuildDate><atom:link href="https://koreainvestinsights.com/es/tags/transformers-en-bucle/feed.xml" rel="self" type="application/rss+xml"/><item><title>Después de Astra: Cómo los Transformers en Bucle Cambian la Economía de la Infraestructura de IA</title><link>https://koreainvestinsights.com/es/post/astra-loop-transformers-inference-economics-2026-09-08/</link><pubDate>Tue, 08 Sep 2026 18:00:00 +0900</pubDate><guid>https://koreainvestinsights.com/es/post/astra-loop-transformers-inference-economics-2026-09-08/</guid><description>&lt;p&gt;¿Puede un modelo pequeño resolver problemas más complejos pasando repetidamente por la misma red neuronal? El CEO de Lablup, Jeongkyu Shin, retoma esta pregunta en su &lt;a class="link" href="https://www.facebook.com/jeongkyu.shin/posts/pfbid02jm4iibHsgU11P7gY8e4SZKtKYNNdtHF6wdTQK2EdyDeTMEwxiDvHnHyhyAKphLml" target="_blank" rel="noopener"
 &gt;ensayo de Facebook sobre los transformers en bucle tras Astra&lt;/a&gt;. Detrás de la cuestión arquitectónica hay una decisión de infraestructura: cuántos aceleradores y cuánta memoria adquirir, y cómo operarlos.&lt;/p&gt;
&lt;p&gt;La investigación pública demuestra que un modelo puede mejorar la resolución de problemas manteniendo sus pesos almacenados intactos, ejecutando repetidamente un bloque computacional compartido. Pero la repetición consume tiempo y energía. Un modelo más pequeño no implica automáticamente un servicio más barato.&lt;/p&gt;
&lt;p&gt;Este es un análisis independiente motivado por el ensayo de Shin, complementado con artículos originales y tarjetas de modelo. Separamos la interpretación del ensayo sobre Astra de los hechos públicamente establecidos, y tratamos las implicaciones para la industria como análisis condicional. Las fuentes fueron verificadas el 8 de septiembre de 2026.&lt;/p&gt;
&lt;h2 id="los-resultados-de-astra-no-revelan-su-arquitectura"&gt;Los resultados de Astra no revelan su arquitectura
&lt;/h2&gt;&lt;p&gt;El anuncio de OpenAI del 3 de septiembre confirma el lanzamiento de GPT-6 Astra y sus mejoras de capacidad. Sin embargo, el &lt;a class="link" href="https://openai.com/index/gpt-6-astra/" target="_blank" rel="noopener"
 &gt;anuncio&lt;/a&gt; y la &lt;a class="link" href="https://deploymentsafety.openai.com/gpt-6-astra" target="_blank" rel="noopener"
 &gt;tarjeta del sistema&lt;/a&gt; aquí revisados no revelan una arquitectura de transformer en bucle, el número de recursiones ni los recuentos totales y activos de parámetros.&lt;/p&gt;
&lt;p&gt;Por tanto, no tratamos la conexión entre Astra y un diseño al estilo Huginn como un hecho establecido. Las afirmaciones sobre tamaños de 10T/1T del ensayo y la cita sobre AGI también quedan excluidas de las premisas de este análisis. Un mejor rendimiento por sí solo no permite identificar la arquitectura interna.&lt;/p&gt;
&lt;p&gt;Aun así, hay razones sólidas para examinar la recurrencia. Los modelos públicos ya muestran intentos de variar la capacidad de parámetros almacenados y el cómputo de inferencia de forma independiente. Ese desarrollo puede evaluarse sin depender del diseño no revelado de un modelo de frontera.&lt;/p&gt;
&lt;h2 id="almacenar-más-y-computar-más-tiempo-son-decisiones-distintas"&gt;Almacenar más y computar más tiempo son decisiones distintas
&lt;/h2&gt;&lt;p&gt;Los parámetros son los pesos numéricos ajustados durante el entrenamiento. Ampliar un modelo generalmente aumenta la cantidad almacenada. La Mezcla de Expertos, o MoE, selecciona algunos módulos expertos para cada entrada, con el objetivo de ejecutar menos cómputo en relación con la capacidad total del modelo.&lt;/p&gt;
&lt;p&gt;MoE no surgió únicamente con Switch Transformer. El &lt;a class="link" href="https://arxiv.org/abs/1701.06538" target="_blank" rel="noopener"
 &gt;artículo de MoE con puertas dispersas de 2017&lt;/a&gt; precedió a &lt;a class="link" href="https://arxiv.org/abs/2101.03961" target="_blank" rel="noopener"
 &gt;Switch Transformer en 2021&lt;/a&gt;, que simplificó el enrutamiento y el entrenamiento a escala. Un recuento total mayor de parámetros tampoco implica necesariamente más capas.&lt;/p&gt;
&lt;p&gt;La cadena de pensamiento (CoT) genera tokens intermedios que extienden el contexto para el cómputo posterior. Un modelo en bucle pasa su estado interno de nuevo a través de un bloque con pesos compartidos. El cómputo intermedio no tiene que convertirse en una palabra en cada paso. Estos enfoques también pueden combinarse.&lt;/p&gt;
&lt;p&gt;Comparar lo que aporta cada enfoque aclara el compromiso.&lt;/p&gt;
&lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th&gt;Enfoque&lt;/th&gt;
 &lt;th&gt;Qué aumenta&lt;/th&gt;
 &lt;th&gt;Coste potencial&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td&gt;Modelo más grande&lt;/td&gt;
 &lt;td&gt;Pesos o capacidad de expertos&lt;/td&gt;
 &lt;td&gt;Almacenamiento, cómputo activo, comunicación&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Cadena de pensamiento&lt;/td&gt;
 &lt;td&gt;Tokens de razonamiento intermedio&lt;/td&gt;
 &lt;td&gt;Tiempo de generación, contexto y caché&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Profundidad recurrente&lt;/td&gt;
 &lt;td&gt;Pasadas a través de un bloque compartido&lt;/td&gt;
 &lt;td&gt;Cómputo repetido, latencia, gestión de estado&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;Esta es una comparación conceptual. La economía real requiere mediciones a precisión, longitud de entrada y condiciones de hardware equivalentes.&lt;/p&gt;
&lt;h2 id="la-investigación-sobre-pensar-antes-de-hablar-utiliza-mecanismos-distintos"&gt;La investigación sobre pensar antes de hablar utiliza mecanismos distintos
&lt;/h2&gt;&lt;p&gt;Los &lt;a class="link" href="https://arxiv.org/abs/2310.02226" target="_blank" rel="noopener"
 &gt;tokens de pausa&lt;/a&gt; proporcionan cómputo adicional antes de dar una respuesta. &lt;a class="link" href="https://arxiv.org/abs/2403.09629" target="_blank" rel="noopener"
 &gt;Quiet-STaR&lt;/a&gt; aprende a generar razonamientos intermedios que ayudan a predecir los tokens siguientes. Su nombre no debe interpretarse como prueba de que utiliza razonamiento continuo no verbal en estado continuo.&lt;/p&gt;
&lt;p&gt;&lt;a class="link" href="https://arxiv.org/abs/2412.06769" target="_blank" rel="noopener"
 &gt;Coconut&lt;/a&gt; retroalimenta el estado oculto final como entrada sin convertirlo en una palabra. Explora la posibilidad de retener alternativas en una representación interna antes de comprometerse con el lenguaje. Esto no es evidencia de conciencia humana ni de pensamiento autónomo continuamente activo.&lt;/p&gt;
&lt;p&gt;La investigación sobre profundidad recurrente incluye el &lt;a class="link" href="https://arxiv.org/abs/1807.03819" target="_blank" rel="noopener"
 &gt;Universal Transformer de 2018&lt;/a&gt;, que repite una transformación y puede asignar cómputo de forma diferente entre posiciones. La dificultad está en entrenar una repetición útil: un bloque compartido debe manejar estados de diferentes etapas, y otra pasada debe mejorar el resultado. Los roles de capa en conflicto son una intuición útil, no una explicación universal para cada fallo.&lt;/p&gt;
&lt;h2 id="copiar-capas-es-distinto-a-compartir-los-mismos-pesos"&gt;Copiar capas es distinto a compartir los mismos pesos
&lt;/h2&gt;&lt;p&gt;&lt;a class="link" href="https://arxiv.org/abs/2312.15166" target="_blank" rel="noopener"
 &gt;SOLAR 10.7B&lt;/a&gt; de Upstage introdujo el escalado de profundidad, o DUS: copiar capas existentes, eliminar algunas, conectarlas en un modelo más profundo y continuar el entrenamiento. Las copias que comienzan siendo idénticas pueden desarrollar pesos distintos. El modelo resultante almacena más parámetros.&lt;/p&gt;
&lt;p&gt;Un modelo recurrente sigue compartiendo los mismos pesos. DUS reutiliza el entrenamiento previo para construir un modelo más profundo; el bucle aumenta la profundidad de ejecución sin una expansión correspondiente en los pesos almacenados. Tratar ambas técnicas como la misma técnica de ahorro de memoria conduce a un modelo de costes incorrecto.&lt;/p&gt;
&lt;h2 id="leer-los-números-de-huginn-y-ouro-con-sus-condiciones-de-comparación"&gt;Leer los números de Huginn y Ouro con sus condiciones de comparación
&lt;/h2&gt;&lt;p&gt;La &lt;a class="link" href="https://arxiv.org/abs/2502.05171" target="_blank" rel="noopener"
 &gt;investigación Huginn&lt;/a&gt; de Geiping y colaboradores separa el procesamiento de entrada, un núcleo recurrente y el procesamiento de salida. El núcleo refina el estado interno mediante ejecución repetida. Los autores entrenaron un modelo de 3.500 millones de parámetros con 800.000 millones de tokens e informaron de una mejora en el rendimiento en tareas de razonamiento al aumentar el cómputo recurrente.&lt;/p&gt;
&lt;p&gt;La cifra de 50B del resumen requiere atención. Describe mejoras hasta una carga computacional equivalente a 50.000 millones de parámetros. No garantiza la calidad de un modelo de 50B en cada tarea, ni que dicha calidad se obtenga al mismo coste. Un conjunto pequeño de pesos que utiliza más cómputo es un resultado de investigación; la economía del servicio requiere medición por separado.&lt;/p&gt;
&lt;p&gt;&lt;a class="link" href="https://arxiv.org/abs/2510.25741" target="_blank" rel="noopener"
 &gt;Ouro&lt;/a&gt;, de ByteDance y colaboradores, se publicó en octubre de 2025. El artículo abarca una familia de modelos de 1.400 y 2.600 millones de parámetros e informa de comparaciones con modelos de hasta 12.000 millones en distintos benchmarks. Sin embargo, la &lt;a class="link" href="https://huggingface.co/ByteDance/Ouro-1.4B" target="_blank" rel="noopener"
 &gt;tarjeta oficial del modelo Ouro-1.4B&lt;/a&gt; describe ese modelo particular como equivalente a modelos convencionales de 3 a 4B. Afirmar que 1.4B siempre reemplaza a 12B sería exagerar la comparación.&lt;/p&gt;
&lt;p&gt;Los recuentos de parámetros deben leerse junto con los datos de entrenamiento, los recuentos de recurrencia y las tareas de evaluación. La aparente eficiencia de inferencia también puede ser consecuencia de una inversión sustancial en preentrenamiento.&lt;/p&gt;
&lt;h2 id="menos-pesos-almacenados-no-eliminan-los-cuellos-de-botella-de-memoria"&gt;Menos pesos almacenados no eliminan los cuellos de botella de memoria
&lt;/h2&gt;&lt;p&gt;Consideremos un cálculo ilustrativo. Almacenar 3.500 millones de parámetros a 2 bytes cada uno requiere aproximadamente 7 GB para los pesos. El uso repetido de esos pesos no multiplica su requisito de almacenamiento por el número de recursiones. Esto es aritmética, no una medición del uso total de memoria GPU de Huginn.&lt;/p&gt;
&lt;p&gt;La memoria total de inferencia también incluye la caché KV utilizada para reutilizar el contexto previo, los estados intermedios y el espacio de trabajo de ejecución. La &lt;a class="link" href="https://developer.nvidia.com/blog/mastering-llm-techniques-inference-optimization/" target="_blank" rel="noopener"
 &gt;guía de optimización de inferencia de NVIDIA&lt;/a&gt; distingue los pesos y la caché KV como los principales componentes de memoria. Los contextos más largos y un mayor número de solicitudes concurrentes aumentan la presión sobre la caché. Si las cachés pueden compartirse entre pasos recurrentes depende del diseño.&lt;/p&gt;
&lt;p&gt;La reutilización de pesos también es diferente a reducir el movimiento de datos. Si los pesos no pueden permanecer en la memoria rápida en chip, otra pasada puede requerir leerlos de HBM de nuevo. La repetición puede incrementar la demanda de ancho de banda junto con el cómputo. Sin examinar la jerarquía de memoria y la implementación, no se puede declarar que el bucle sea la razón por la que HBM se vuelve innecesario.&lt;/p&gt;
&lt;h2 id="el-software-debe-materializar-los-ahorros-de-la-salida-anticipada"&gt;El software debe materializar los ahorros de la salida anticipada
&lt;/h2&gt;&lt;p&gt;&lt;a class="link" href="https://arxiv.org/abs/2507.10524" target="_blank" rel="noopener"
 &gt;Mixture-of-Recursions (MoR)&lt;/a&gt; varía la profundidad recursiva por token y gestiona el cómputo y el almacenamiento en caché en torno a los tokens aún activos a una profundidad determinada. El objetivo es dirigir el cómputo hacia los tokens más difíciles en lugar de gastarlo en los sencillos.&lt;/p&gt;
&lt;p&gt;El servicio hace esto más difícil. Los distintos requisitos de recurrencia entre solicitudes pueden reducir la eficiencia del procesamiento por lotes. Los planificadores necesitan dejar que otro trabajo use los recursos liberados al completarse antes. Este es un desafío operativo anticipado, no un resultado medido para un producto comercial concreto.&lt;/p&gt;
&lt;p&gt;La tarjeta del modelo Ouro ofrece un ejemplo concreto. El modelo admite salida anticipada, pero la tarjeta indica que vLLM no admite esta función y en su lugar ejecuta el número completo de recursiones configurado. Una capacidad arquitectónica no se implementa automáticamente en un motor de servicio.&lt;/p&gt;
&lt;p&gt;Esto plantea preguntas concretas para empresas de software de infraestructura de IA como Lablup: ¿puede la plataforma procesar en lotes trabajos con distintas profundidades de recurrencia, reutilizar cachés y reducir el tiempo de finalización y el coste energético con calidad equivalente? Estas son preguntas para evaluar una oportunidad, no afirmaciones de que Lablup ya admita esas funciones o haya demostrado crecimiento de ingresos gracias a ellas.&lt;/p&gt;
&lt;h2 id="los-semiconductores-coreanos-enfrentan-tanto-el-ahorro-de-recursos-como-la-expansión-del-uso"&gt;Los semiconductores coreanos enfrentan tanto el ahorro de recursos como la expansión del uso
&lt;/h2&gt;&lt;p&gt;Los siguientes son escenarios condicionales para una adopción más amplia de modelos en bucle, no previsiones de resultados.&lt;/p&gt;
&lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th&gt;Condición&lt;/th&gt;
 &lt;th&gt;Posible efecto en la industria&lt;/th&gt;
 &lt;th&gt;Evidencia necesaria&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td&gt;Menos pesos y menos caché con calidad equivalente&lt;/td&gt;
 &lt;td&gt;Menor presión de memoria por solicitud&lt;/td&gt;
 &lt;td&gt;Memoria medida con contexto y concurrencia iguales&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Más recurrencia en problemas difíciles&lt;/td&gt;
 &lt;td&gt;Mayor demanda de tiempo de acelerador y energía&lt;/td&gt;
 &lt;td&gt;Tiempo de GPU y energía por tarea completada con éxito&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Menor coste amplía el uso&lt;/td&gt;
 &lt;td&gt;Demanda de infraestructura agregada estable o mayor&lt;/td&gt;
 &lt;td&gt;Uso real de clientes y planes de compra&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;La recurrencia y la gestión de caché reducen la eficiencia del procesamiento por lotes&lt;/td&gt;
 &lt;td&gt;Comercialización retrasada&lt;/td&gt;
 &lt;td&gt;Rendimiento al mismo objetivo de latencia&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;Para los proveedores de memoria como Samsung Electronics y SK hynix, la demanda agregada depende tanto de los recursos por solicitud como del número de solicitudes. La eficiencia puede estimular la adopción, pero no puede asumirse que ese crecimiento supere los ahorros. Este análisis por sí solo no es suficiente para revisar las previsiones de demanda de HBM ni los pronósticos de beneficios de las empresas.&lt;/p&gt;
&lt;p&gt;Una comparación más útil es el coste de completar una tarea exitosa. Las puntuaciones altas en benchmarks pueden seguir siendo costosas si la repetición lleva demasiado tiempo o los reintentos son frecuentes. Por el contrario, el cómputo adicional puede reducir el coste total si mejora lo suficiente el éxito en el primer intento.&lt;/p&gt;
&lt;h2 id="la-próxima-prueba-es-el-coste-por-tarea-no-el-recuento-de-parámetros"&gt;La próxima prueba es el coste por tarea, no el recuento de parámetros
&lt;/h2&gt;&lt;p&gt;Verificar el caso industrial requiere comparar la memoria total, el tiempo de finalización, la energía y el rendimiento concurrente con precisión equivalente. La latencia en cola importa tanto como los promedios para las preguntas sencillas. Si más recurrencia deja de mejorar la calidad, o las pérdidas por procesamiento en lotes superan los ahorros de recursos, el argumento de comercialización se debilita.&lt;/p&gt;
&lt;p&gt;Una mayor divulgación arquitectónica podría establecer si Astra pertenece a esta línea de investigación. Mientras tanto, un cambio verificable permanece: la planificación de infraestructura debe considerar cuánto tiempo calcular sobre cada problema y cuándo detenerse, junto con el tamaño del modelo almacenado. Convertir esa flexibilidad en costes reales más bajos es una prueba conjunta de hardware y software.&lt;/p&gt;</description></item></channel></rss>