Volver al blog
Open SourceHardwareIA

OpenTPU: un acelerador de IA open source hecho por IA

12 de octubre de 2026·7 min de lectura·Diego Horvatti

Una IA ayudó a diseñar el chip que ejecuta IA. Eso es básicamente lo que promete OpenTPU: un acelerador de IA open source, inspirado en la TPU de Google, con el diseño de hardware desarrollado por modelos de lenguaje. El repositorio llegó a lo más alto de las discusiones de desarrolladores esta semana, y no es casualidad. La frase suena a chiste recursivo, pero el proyecto es real y el código está ahí para quien quiera abrirlo.

Yo no soy ingeniero de hardware. Escribo TypeScript, React y SQL todo el día. Justamente por eso el proyecto me pareció interesante: muestra hasta dónde puede llegar la IA fuera de la zona cómoda del CRUD, y dónde todavía necesita a alguien vigilando.

¿Qué es OpenTPU, al final?

TPU es la sigla de Tensor Processing Unit. Es el chip que Google creó para acelerar redes neuronales. La primera generación, descrita en un paper de 2017, tenía una matriz de 256 por 256 unidades de multiplicación y suma que trabajaban con enteros de 8 bits. No hace nada más que eso, pero lo hace muy rápido.

El truco se llama systolic array. Imagina una cuadrícula de celdas pequeñas. Cada una multiplica dos números, lo suma con lo que recibió de su vecina y pasa el resultado adelante. Los datos "laten" por la cuadrícula como la sangre en un corazón, de ahí el nombre. Al final sale una multiplicación de matrices completa, que es lo que una red neuronal hace casi todo el tiempo.

OpenTPU sigue esa idea. Es un diseño de hardware descrito en código (HDL), pensado para simularse y, en teoría, sintetizarse en una FPGA. No es un chip que puedas comprar. Es un plano abierto.

Un detalle para no confundirse: ya existía un OpenTPU académico, de la UC Santa Barbara, de 2017, escrito en PyRTL. El proyecto de esta semana es otro, del usuario FeSens en GitHub. Mismo nombre, misma inspiración, origen distinto.

¿Cómo escribe hardware una IA?

Igual que escribe tu componente de React: generando texto. La diferencia es que ese texto describe cables, registros y ciclos de reloj, no divs.

Para que te hagas una idea del formato, una celda de multiplicar y acumular en Verilog queda más o menos así (ejemplo mío, simplificado, no es el código del repositorio):

module mac_cell (
  input  wire        clk,
  input  wire [7:0]  a_in, b_in,
  output reg  [7:0]  a_out, b_out,
  output reg  [31:0] acc
);
  always @(posedge clk) begin
    acc   <= acc + a_in * b_in;
    a_out <= a_in;  // pasa al vecino de la derecha
    b_out <= b_in;  // pasa al vecino de abajo
  end
endmodule

Son pocas líneas. Un modelo de lenguaje escribe esto sin despeinarse. El reto no es la celda. Es poner miles de ellas una al lado de otra, sincronizar la entrada de datos con el retraso correcto, gestionar la memoria, controlar el flujo de instrucciones y garantizar que nada salga un ciclo tarde.

En software, un error de un ciclo es un bug que corriges en el siguiente deploy. En hardware, una vez que se convierte en silicio, es un bug grabado en piedra.

¿Por qué importa esto si no trabajas con chips?

Porque el cuello de botella cambió de lugar, y eso también aplica a tu código.

Escribir HDL siempre fue un nicho caro. Poca gente sabe hacerlo, las herramientas son hostiles y el ciclo de feedback es lento. Si un modelo logra sacar adelante un acelerador funcional, aunque sea simple, la barrera de entrada baja mucho. Estudiantes, aficionados y startups pequeñas pasan a tener un punto de partida que antes costaba meses de especialista.

Pero fíjate en lo que le queda al humano. La IA genera el diseño. Alguien tiene que demostrar que funciona.

Generar código se volvió barato. Demostrar que está bien sigue siendo caro.

En hardware esto se toma en serio desde hace décadas. Los equipos de chips suelen dedicar más esfuerzo a la verificación que al diseño. Testbench, simulación ciclo a ciclo, comparación con un modelo de referencia en software. Es exactamente el tipo de disciplina que en el mundo web tratamos como opcional.

Qué cambia en tu flujo de trabajo

OpenTPU es un gran espejo de cómo usamos la IA en el día a día. El patrón que funciona en hardware es el mismo que funciona en cualquier stack:

  • Ten un modelo de referencia. En hardware, comparas la salida del chip con una multiplicación de matrices hecha en NumPy. En tu proyecto, eso es el test que dice qué significa "correcto" antes de que la IA escriba nada.
  • Prueba el comportamiento, no la apariencia. El código generado por IA suele parecer correcto. Parecer no cuenta.
  • Reduce el radio de explosión. Una celda a la vez, un módulo a la vez. Pedir el sistema entero en un solo prompt es pedir depurar el sistema entero después.

En la práctica, el test de referencia es algo tan simple como esto:

import { expect, test } from 'bun:test'

test('la salida del acelerador coincide con la referencia', () => {
  const a = randomMatrix(4, 4)
  const b = randomMatrix(4, 4)
  expect(simulate(a, b)).toEqual(matmul(a, b))
})

El simulate pudo haberlo escrito tú, un modelo o un becario a las tres de la mañana. Al test no le importa. Por eso vale más que el código.

¿Se puede usar OpenTPU de verdad?

Depende de lo que entiendas por "usar". Para correr tu LLM en producción, no. Una GPU comercial o una instancia en la nube va a seguir ganando por muchísimo, y eso no le resta mérito al proyecto. Los chips comerciales tienen años de optimización, procesos de fabricación de punta y equipos enteros detrás.

Para aprender, sí, y mucho. Si siempre quisiste entender por qué la multiplicación de matrices domina el costo de la IA, leer un diseño pequeño y abierto enseña más que diez hilos explicando "cómo funciona la TPU". Ves el dato entrar, recorrer la cuadrícula y salir.

Si quieres explorarlo, mi ruta sería esta:

  1. Clonar el repositorio y leer el README con calma.
  2. Encontrar la celda básica del systolic array y entender las señales de entrada y salida.
  3. Ejecutar la simulación o los tests que ofrezca el proyecto y mirar las formas de onda.
  4. Romper algo a propósito, como retrasar una señal, y ver cómo el resultado sale mal.

El paso 4 es el más valioso. Solo entiendes un sistema de verdad después de verlo fallar.

Un aviso honesto: no audité el diseño línea por línea, y los proyectos escritos con IA merecen una dosis extra de escepticismo. Lee los tests antes de confiar en lo que dice el README. Eso aplica a este y a cualquier otro.

La parte que nadie quiere oír

Hay una tentación de leer "acelerador de IA open source hecho por IA" y concluir que el ingeniero de hardware es una profesión en extinción. Yo creo lo contrario.

El proyecto solo tiene sentido porque existe una forma objetiva de saber si está bien. El hardware tiene simulación, tiene modelo de referencia, tiene métricas duras. La IA brilla justo donde el feedback es rápido y binario: pasó o no pasó. Donde falta esa base, genera cosas bonitas y equivocadas con mucha confianza. Como un dev junior entusiasmado, solo que tecleando mucho más rápido.

Así que la habilidad que gana valor no es escribir Verilog ni escribir TypeScript. Es saber especificar qué significa "correcto" y construir la red de tests que sostiene todo lo demás.

Mi opinión: OpenTPU no va a cambiar el mercado de chips. Va a cambiar la cantidad de gente que se anima a entender uno. Y por eso el open source sigue siendo el mejor laboratorio que tenemos para probar hasta dónde llega la IA. Si te gusta ver un experimento convertirse en algo que funciona, échale un vistazo a lo que estoy construyendo en mis proyectos.

Resumen para LinkedIn

Una IA ayudó a diseñar el chip que ejecuta IA. Y el código está abierto en GitHub.

OpenTPU es un acelerador inspirado en la TPU de Google, con el diseño de hardware escrito por modelos de lenguaje.

No soy ingeniero de hardware, pero el proyecto me enseñó algo que vale para cualquier stack: generar código se volvió barato, demostrar que está bien sigue siendo caro.

La IA brilla donde el feedback es objetivo, cuando el test pasa o no pasa. Sin esa base, entrega cosas bonitas y equivocadas con mucha confianza.

La habilidad que más vale ahora no es escribir Verilog ni TypeScript. Es definir qué significa "correcto" y armar los tests que sostienen todo lo demás.

Escribí más sobre esto en el blog. Si el tema te interesa, el enlace está en los comentarios.

#InteligenciaArtificial #OpenSource #Hardware #DesarrolloDeSoftware #Testing