Buenas, esto es BIMPRAXIS, el podcast donde el
Download transcript (.srt)
0:09
0:15
0:20
0:23
0:26
0:28
0:36
0:41
0:42
0:45
0:48
0:50
0:53
0:56
0:56
0:58
1:01
1:03
1:06
1:07
1:09
1:11
1:12
1:14
1:16
1:18
1:20
1:22
1:24
1:26
1:28
1:29
1:32
1:35
1:36
1:39
1:42
1:43
1:45
1:48
1:51
1:53
1:54
1:55
1:58
2:01
2:01
2:04
2:05
2:06
2:08
2:10
2:12
2:14
2:17
2:19
2:22
2:25
2:26
2:28
2:31
2:32
2:32
2:35
2:37
2:40
2:42
2:43
2:44
2:45
2:48
2:51
2:52
2:54
2:57
3:00
3:01
3:04
3:05
3:07
3:10
3:13
3:15
3:16
3:19
3:20
3:23
3:23
3:26
3:29
3:31
3:33
3:35
3:37
3:41
3:42
3:43
3:46
3:48
3:49
3:51
3:54
3:56
3:59
4:02
4:05
4:07
4:09
4:09
4:11
4:14
4:15
4:16
4:18
4:20
4:23
4:25
4:27
4:28
4:30
4:33
4:35
4:37
4:39
4:42
4:46
4:48
4:51
4:54
4:55
4:57
5:00
5:02
5:04
5:05
5:07
5:09
5:09
5:12
5:12
5:15
5:19
5:20
5:23
5:23
5:25
5:27
5:28
5:32
5:35
5:37
5:37
5:38
5:41
5:42
5:43
5:46
5:49
5:49
5:52
5:55
5:56
5:58
5:59
6:01
6:04
6:04
6:07
6:07
6:10
6:11
6:14
6:16
6:19
6:21
6:24
6:26
6:29
6:31
6:33
6:35
6:37
6:39
6:41
6:42
6:43
6:44
6:46
6:50
6:54
6:55
6:57
7:00
7:05
7:07
7:12
7:13
7:14
7:16
7:16
7:19
7:22
7:24
7:25
7:29
7:31
7:33
7:35
7:36
7:37
7:40
7:43
7:45
7:47
7:47
7:50
7:52
7:54
7:56
7:58
8:00
8:04
8:07
8:10
8:13
8:14
8:18
8:19
8:21
8:23
8:24
8:26
8:27
8:30
8:33
8:34
8:35
8:38
8:41
8:43
8:44
8:45
8:48
8:50
8:53
8:55
8:58
9:01
9:04
9:07
9:09
9:12
9:14
9:16
9:19
9:21
9:21
9:22
9:25
9:26
9:29
9:31
9:33
9:35
9:36
9:36
9:39
9:41
9:44
9:47
9:49
9:51
9:52
9:54
9:57
10:00
10:02
10:06
10:09
10:12
10:13
10:15
10:17
10:19
10:20
10:23
10:25
10:27
10:30
10:32
10:32
10:34
10:36
10:36
10:38
10:41
10:42
10:44
10:44
10:47
10:50
10:51
10:54
10:55
10:58
11:00
11:01
11:04
11:06
11:06
11:09
11:11
11:13
11:14
11:16
11:19
11:21
11:22
11:24
11:27
11:28
11:29
11:32
11:34
11:36
11:39
11:40
11:42
11:44
11:48
11:50
11:51
11:53
11:57
11:58
12:00
12:03
12:04
12:06
12:08
12:09
12:12
12:15
12:16
12:17
12:18
12:20
12:22
12:25
12:27
12:30
12:32
12:33
12:34
12:36
12:40
12:43
12:44
12:45
12:47
12:49
12:52
12:55
12:56
12:57
12:58
13:00
13:02
13:05
13:06
13:07
13:09
13:11
13:13
13:14
13:16
13:19
13:20
13:20
13:25
13:27
13:30
13:32
13:35
13:36
13:39
13:40
13:42
13:45
13:46
13:49
13:51
13:52
13:54
13:55
13:57
14:00
14:03
14:05
14:06
14:06
14:09
14:13
14:16
14:18
14:18
14:22
14:24
14:25
14:27
14:29
14:30
14:31
14:34
14:37
14:37
14:40
14:43
14:46
14:47
14:50
14:51
14:52
14:53
14:54
14:56
14:59
15:01
15:03
15:04
15:07
15:10
15:11
15:13
15:16
15:18
15:20
15:23
15:24
15:26
15:30
15:32
15:34
15:36
15:38
15:40
15:41
15:44
15:48
15:52
15:53
15:55
15:58
16:00
16:03
16:06
16:06
16:08
16:10
16:12
16:15
16:17
16:20
16:22
16:25
16:27
16:30
16:32
16:34
16:36
16:38
16:40
16:41
16:44
16:44
16:47
16:47
16:51
16:52
16:54
16:55
16:56
16:59
17:01
17:01
17:04
17:06
17:07
17:10
17:13
17:15
17:17
17:19
17:20
17:22
17:24
17:27
17:29
17:30
17:33
17:35
17:37
17:39
17:42
17:44
17:47
17:48
17:50
17:51
17:55
17:57
18:00
18:04
18:06
18:07
18:08
18:11
18:14
18:17
18:18
18:21
18:23
18:25
18:27
18:29
18:31
18:34
18:35
18:35
18:39
18:43
18:46
18:48
18:48
18:52
18:55
18:58
19:01
19:02
19:04
19:06
19:09
19:12
19:16
19:20
19:24
19:26
19:28
19:29
19:34
19:36
19:37
19:41
19:43
19:45
19:47
19:51
19:53
19:56
19:58
20:10
20:22
20:24
BIM se encuentra con la inteligencia artificial.
Exploramos la ciencia, la tecnología y el futuro
desde el enfoque de la arquitectura, ingeniería y
construcción.
¡Empezamos!
Muy buenas, bienvenidas, bienvenidos a un nuevo episodio
de BIMPRAXIS.
Hoy os traemos TurboQuant, la técnica de Google
que hace viable correr modelos de lenguaje gigantes
en cualquier ordenador.
Bueno, imaginemos por un momento intentar meter el
océano Atlántico entero en una piscina olímpica.
Madre mía.
Y encina sin derramar ni una sola gota.
Pues esa es exactamente la clase de paradoja
física y matemática que ocurre dentro de un
ordenador cuando un modelo de inteligencia artificial se
queda sin memoria.
Es un problema monumental.
O sea, cualquiera que haya intentado experimentar con
IA.
De forma local, en su propia máquina, se
ha chocado contra este mismo muro.
Exacto, el muro del ladrillo de la memoria
de vídeo, la VRAM.
Te pones a procesar un texto largo, el
modelo empieza a leer, parece que todo va
fluido y de repente ¡pum!
La pantalla te arroja el temido error de
falta de memoria.
El cerebro del sistema simplemente colapsa.
Intenta retener demasiada información al mismo tiempo y
no da más de sí.
Y claro, es una frustración enorme.
Una barrera que frena muchísima innovación.
A nivel local.
Por eso, la misión de nuestra inmersión profunda
de hoy es comprender cómo el equipo de
Google Research ha logrado algo que parecía magia.
O directamente imposible desde el punto de vista
matemático, fíjate.
Totalmente.
Han publicado un estudio donde presentan TurboQuant, que
es una técnica que resuelve este gigantesco cuello
de botella.
Estamos hablando de comprimir el espacio necesario hasta
seis veces.
¿Una barbaridad?
Y acelerar el proceso general.
Pero lo más alucinante, y ojo a esto,
es no perder...
Absolutamente nada de precisión por el camino.
Esto cambia por completo las reglas del juego.
Sí, sí, es una pasada para la comunidad.
Pero, bueno, a ver, para entender la magnitud
de esta solución técnica, primero hay que mirar
al problema a los ojos.
No se puede valorar la genialidad de la
cura si no se comprende la enfermedad, por
así decirlo.
Lógico.
Y en la arquitectura de los modelos modernos,
el gran culpable de que los sistemas agoten
su memoria casi siempre es el mismo componente.
El famoso caché -caché.
El caché -cabe, o caché de claves y
valores.
Vale, el caché -cabe.
Quizá convenga detenernos aquí un momentito, porque esto
suena a jerga de ingeniería muy densa.
Ya, es verdad.
Pero en el fondo representa la lógica más
básica de cómo lee una inteligencia artificial.
¿Cómo le visualizaríamos esto a alguien ajeno a
la programación de bajo nivel?
Pues, a ver, es un mecanismo de supervivencia
computacional básico.
Si alguien está leyendo una novela de mil
páginas y llega al capítulo 10, no necesita
volver a leer desde la primera página para
saber quién es el protagonista, ¿verdad?
Claro.
El cerebro humano guarda un contexto activo.
Justo.
Los modelos de lenguaje necesitan hacer exactamente lo
mismo.
El caché -cabe es ese espacio de memoria
donde el modelo va anotando sus interpretaciones matemáticas
de las palabras anteriores, los tokens.
O sea, si el sistema tuviera que recalcular
toda la lógica desde cero absoluto para cada
palabra… Tardaría siglos.
Imagínate repasar todo el documento solo para verlo.
Sería inasumible.
Entiendo.
El sistema crea unos apuntes rápidos para no
tener que repasar la enciclopedia entera cada paso.
Eso es.
El inconveniente, por lo que veo, es que
estos apuntes no son texto plano.
Son matrices matemáticas inmensas.
Y a medida que el documento crece, esa
torre de apuntes crece de forma alarmante.
Crece de forma lineal e inexorable, sí.
Cada palabra nueva es un bloque adicional en
la memoria física de la tarjeta gráfica.
Sí.
Y cuando esa torre choca contra el techo,
contra los gigabytes físicos que tiene la tarjeta,
se acabó.
El proceso se detiene en seco.
Ahí es donde duele.
Y por eso la industria lleva años intentando
aplicar técnicas de compresión de datos tradicionales.
Lo que en este campo llamamos cuantización.
Pero a ver, la idea de comprimir archivos
lleva existiendo décadas.
Todos hemos usado archivos ZIP.
Entiendo que aplicar la cuantización clásica a este
caché KB resultaba ser un desastre, ¿no?
Un desastre absoluto.
Y el motivo técnico por el que fallaba
tan estrepitosamente tiene nombre y apellidos.
La existencia de outliers o valores extremos.
Valores extremos, vale.
En la documentación del estudio hay una analogía
visual fantástica para ilustrar este problema geométrico.
La de la maleta, sí.
Exacto, el escenario de la maleta.
Imaginemos que alguien tiene que hacer el equipaje
para un viaje y dispone de 50 camisetas
de verano finas, súper ligeras.
Ajá.
Y de repente necesita ingresar.
Y puede incluir un solo abrigo de nieve,
gigante.
De esos de expedición polar que abultan una
barbaridad.
Pues mira, en esa analogía, las 50 camisetas
representan la inmensa mayoría de las activaciones matemáticas
del modelo.
Números pequeños, estables, fáciles de empaquetar en la
memoria.
¿Y el abrigo de nieve?
El abrigo es el famoso outlier, el valor
extremo.
Si los algoritmos tradicionales de compresión intentan meter
todo este equipaje en una maleta rígida, el
algoritmo siempre toma la medida del objeto más
grande.
Claro.
Toma el abrigo como referencia para definir el
tamaño de la maleta.
Exactamente.
Como resultado, fabricas una maleta enorme con muchísimo
espacio vacío y desperdiciado entre las camisetas.
Ya veo.
Se adapta todo el sistema de almacenamiento a
la inspección gigante y se pierde una eficiencia
brutal por el camino.
Es el retrato exacto de lo que hace
la cuantización clásica.
Toma ese valor extremo y escala todo el
rango de compresión basándose en ese único número
gigantesco.
Y al hacer eso, el rango matemático se
estima.
Tira tanto que las camisetas, los valores pequeños,
pierden su resolución.
Se difuminan hasta casi desaparecer.
El sistema de precisión solo tiene ojos para
la escala del abrigo gigante, por así decirlo.
Vale, llegados a este punto, la intuición me
empuja hacia una solución súper obvia.
Si el abrigo de nieve es lo que
está arruinando la compresión de todo el sistema,
¿por qué los algoritmos simplemente no lo ignoran?
O sea, si es solo una prenda entre
50, ¿la dejas fuera?
¿Comprimes las 50 camisetas?
¿Comprimes las 50 camisetas divinamente y problema resuelto?
Hoy, esa es la trampa mortal de los
modelos de lenguaje.
No se puede.
¿Por qué no?
Porque en la arquitectura interna del modelo, esos
valores gigantescos no son errores matemáticos, no son
anomalías molestas, son pilares de carga críticos.
¿Pilares de carga?
Sí, los investigadores han descubierto que estos outliers
actúan como sumideros de atención.
Suelen coincidir con elementos estructurales clave, como signos
de puntuación, el primer token del texto… O
sea, no son ruido, son las vigas maestras
del contexto.
Totalmente.
Son el pegamento que mantiene la coherencia del
modelo.
Si cortas esos valores grandes, si el algoritmo
los ignora para comprimir mejor, el modelo pierde
el hilo lógico por completo.
Se vuelve tonto.
Empieza a sufrir alucinaciones, inventa hechos, pierde la
gramática y da respuestas absurdas.
No puedes tirar el abrigo sin que el
modelo se congele de incompetencia, siguiendo con la
metáfora.
Vaya tela.
O sea, un callejón sin salida absoluto.
No puedes incluir el abrigo sin desperdiciar una
cantidad ridícula de espacio.
Pero tampoco puedes dejarlo fuera.
Eso es.
Y justo en esta encrucijada es donde la
investigación de Google saca a relucir una brillantez
matemática inusual con TurboQuant.
Logran engañar a la física de la memoria
con dos pasos fascinantes.
A ver, cuéntame el primer paso.
El primero lo han bautizado como preacondicionamiento geométrico.
En lugar de intentar comprimir los datos crudos…
…tal cual, con su desorden de camisetas y
abrigos, aplican una transformación matemática prévida.
Mmm, vale.
Utilizan una operación muy específica conocida como la
transformada de Hadamard.
La transformada de Hadamard.
A ver, eso es una física cuántica o
algo así.
¿Qué le hace exactamente esta operación a los
valores extremos?
Simplificándolo mucho, es una forma de rotar y
proyectar los datos en un espacio multidimensional.
Piensa en un prisma de cristal.
Vale.
Si un rayo láser intensísimo… …sería nuestro abrigo
gigante, impacta contra el prisma, este descompone esa
energía focalizada y la esparce en un arcoíris
ancho y uniforme.
Ah, claro.
La transformada de Hadamard coge la magnitud de
ese número gigantesco y la distribuye.
Reparte su peso entre todos los demás valores
pequeños, de forma perfectamente reversible.
Aquí es donde se pone realmente interesante.
O sea, llevándolo de vuelta a la maleta,
el preacondicionamiento es como meter ese abrigo de
expedición en una de esas bolsas al vacío.
Esa es muy buena analogía, sí.
Le enchufas la aspiradora, le sacas todo el
aire, hasta que queda del grosor de una
camiseta.
La prenda sigue ahí, hemos tirado ropa, pero
ahora el volumen de todo el equipaje es
uniforme.
Brillante.
Captura la esencia de la reversibilidad matemática a
la perfección.
Has distribuido el volumen atípico sin perder la
masa crítica de la información.
Ahora todos los datos están nivelados.
Se ha aplanado la curva de los datos,
vaya.
Exacto.
No hay picos que rompan la escala.
Y una vez que el terreno está perfectamente
plano, el sistema entra en el segundo paso
crítico de TurboQuant, la cuantización de vectores.
La cuantización de vectores.
Aquí es donde se realiza la compresión real,
entiendo.
Los números en pequeños bloques o vectores.
Y luego encaja esos grupos en una cuadrícula
geométrica predefinida súper eficiente.
Vale, ¿y cuánto comprime esto?
Pues al operar por grupo sobre esta plantilla,
dando un promedio de solo 3 bits, en
contraposición a los 16 bits habituales.
Espera, espera, espera.
Yo no te compro esto tan fácilmente.
Bajar de 16 bits a 3 bits es
una reducción de datos salvaje.
Es una barbaridad, sí.
Es eliminar más del 80 % de la
información de cada número.
Por muy bonita que sea la cuadrícula geométrica,
la matemática dicta que tiene que perderse resolución.
¿Cómo es posible que no se rompa el
modelo?
Es una objeción fantástica.
Y fíjate, es el corazón de por qué
este estudio...
...es tan revolucionario.
La trampa está en pensar en números aislados
en lugar de patrones.
Piensa en una paleta de colores.
A ver.
Si quieres transmitir el color exacto de un
píxel, puedes enviar el código hexadecimal complejo de
16 bits.
Eso te da millones de combinaciones de color,
pero requiere muchos datos.
Claro, para decir exactamente qué tono específico de
azul cielo se está usando.
Exacto.
Pero, ¿y si antes hemos analizado la imagen
y creado una paleta fija de solo 8
colores?
En lugar de enviar un código gigante, envíes
una instrucción de 3 bits que dice usa
el color número 4 de la paleta.
Ah, ya lo pillo.
Como en el paso de la bolsa al
vacío ya habíamos aplanado todos los colores extremos
y suavizado las transiciones...
Justo.
Sabemos que cualquier patrón de datos va a
coincidir casi perfectamente con uno de esos 8
colores básicos de la paleta.
Es fascinante.
Al distribuir la energía antes, te aseguras de
no necesitar millones de tonos distintos.
Una paleta pequeña en memoria...
Es suficiente para reconstruir la imagen, sin que
parezca pixelada.
Y el ahorro de espacio es monumental, sin
perder la identidad de la información.
Vale, la teoría suena espectacular, pero un análisis
no está completo sin ver el impacto en
el mundo real.
Cuando alguien se sienta frente a su máquina
a procesar documentos inmensos, ¿qué cambio tangible aporta
TurboQuant?
Pues aporta un salto de capacidad que parece
romper las reglas del hardware, en cifras concretas
del estudio.
Si una máquina local antes podía procesar unas
10 .000 palabras, antes de colapsar...
Sí.
Implementando TurboQuant, ese idéntico equipo, sin modificar un
solo tornillo, puede procesar 60 .000 palabras.
¡Madre mía!
Es pasar de 10 .000 a 60 .000
en el mismo equipo.
Es multiplicar por 6 la ventana de contexto
sin gastar un euro en hardware nuevo.
Supone la diferencia entre que un modelo apenas
pueda analizar un informe cortito a que pueda
ingerir libros enteros de una sola vez.
Y ojo, que la magia no termina en
la capacidad.
Hay más.
Además, los datos de Google revelan una aceleración
masiva, en tarjetas gráficas avanzadas, como las H100
de NVIDIA, se han registrado aceleraciones de hasta
8 veces en la velocidad.
Vale.
Vamos a desgranar esto porque aquí hay una
aparente contradicción técnica.
Yo entiendo perfectamente que al usar 3 bits
en lugar de 16, la memoria se libera
y ocupa menos espacio.
Lógico.
Pero ¿por qué es más rápido?
Si el ordenador ahora tiene que molestarse en
descomprimir esos datos matemáticos del prisma y las
cuadrículas antes de poder usar la información, lo
normal sería que fuera más rápido.
Más lento, ¿no?
Es una duda brillante.
Y toca el mayor secreto a voces de
la arquitectura de ordenadores.
El muro de la memoria.
El verdadero cuello de botella en una tarjeta
gráfica casi nunca es la potencia matemática pura.
Ah, ¿no?
¡Qué va!
Los núcleos de procesamiento son insultantemente rápidos.
El problema logístico real es mover la información
desde la memoria hasta esos núcleos.
O sea, es como diseñar una cocina industrial
con los cocineros más rápidos del planeta, pero
con un pasillo larguísimo.
Y súper estrecho para traerles los ingredientes desde
la despensa.
Una analogía impecable.
Ese pasillo estrecho es el ancho de banda
de la memoria.
Mover toneladas de información pesada a 16 bits
por ese pasillo es lo que paraliza el
sistema.
Claro, se atascan en la puerta.
Exacto.
El modelo se pasa la mayor parte del
tiempo simplemente esperando a que lleguen los datos.
Al comprimir a 3 bits, envías paquetes minúsculos
y ligerísimos por el pasillo.
Y fluyen a toda velocidad.
Exacto.
Y cuando llegan a los núcleos, como esos
cocineros operan a velocidades astronómicas y encima estaban
aburridos esperando, descomprimir la información les supone una
fracción de microsegundo.
¡Guau!
O sea, el tiempo extra de cálculo compensa
con creces el tiempo que te ahorras en
el transporte.
Todo encaja a la perfección.
Pero me queda la prueba de fuego.
La precisión.
A ver.
Porque la experiencia diaria nos dice que si
comprimes un audio o una imagen, inevitablemente, se
degrada.
¿Acaso el modelo no se vuelve más propenso
a cometer errores lógicos y volverse más torpe?
Pues prepárate, porque esta es la joya de
la corona de TurboQuant.
Hay un 0 % de degradación en la
precisión.
¿0 %?
Me cuesta creerlo.
Cero.
Y no lo dicen por decir.
Se sustenta en evaluaciones exhaustivas con los estándares
más estrictos como los benchmarks Human Bell y
GSM8K.
Ah, vale.
Esos son bancos de pruebas centrados, en razonamiento
matemático y generación de código de programación.
Exactamente.
Prohíboras donde no existe el casi correcto.
Si el modelo se equivoca en la indentación
del código, o se salta un paréntesis, el
programa falla catastróficamente.
No hay margen para imprecisiones ahí, claro.
Ninguno.
Y los resultados demuestran que los modelos operando
bajo compresión TurboQuant logran calificaciones idénticas a los
modelos masivos originales sin comprimir.
La lógica se mantiene intacta.
Resulta hipnótico.
Es como obtener el rendimiento de un Fórmula
1 gastando el combustible de un utilitario.
Totalmente.
No obstante, en cualquier análisis riguroso de tecnología
nueva, es obligatorio leer la letra pequeña.
Todo avance revolucionario tiene un pero o requisitos
muy concretos.
¿Cuáles son las limitaciones actuales de esto?
Bueno, la primera grande limitación es su campo
de aplicación.
TurboQuant aplica únicamente al caché KV, a esas
activaciones de memoria temporal que decíamos.
Ya.
No es una técnica que se pueda aplicar
a los pesos principales del modelo, que son
los archivos base con el conocimiento que la
IA aprendió durante su entrenamiento.
Pero, a un nivel profundo, ¿no son todo
simplemente matrices de números flotantes?
¿Por qué la técnica de la bolsa al
vacío funciona para la memoria temporal y no
para la memoria a largo plazo?
Porque tienen distribuciones matemáticas muy distintas.
Piensa en la diferencia entre conocer las reglas
gramaticales de un idioma y participar en un
debate acalorado en directo.
Vale, interesante.
Los pesos estáticos del modelo son como la
gramática.
Reglas fijas, estables, en forma de campana de
Gauss.
El caché KV representa la conversación en tiempo
real.
Es dinámico, volátil y genera esos picos salvajes,
los abrigos de nieve.
Claro, en respuesta a un texto que acaba
de leer.
Exacto.
TurboQuant doma el caos del tiempo real, pero
no reduce el peso de descarga inicial del
modelo.
Un archivo de 40 gigas, seguirá pesando 40
gigas en tu disco duro.
Entendido.
Libera espacio vital durante el proceso de razonamiento.
Más allá de esta limitación, ¿qué exige esta
tecnología a nivel de software?
Porque imagino que no es un botón mágico
para tarjetas de vídeo antiguas.
No, qué va.
Requiere código muy optimizado a nivel de hardware,
lo que llamamos kernels personalizados.
Se necesita escribir en lenguajes como Triton para
manipular la gestión de la memoria de la
gráfica directamente.
O sea que, abordando el impacto práctico, si
alguien nos escucha ahora mismo y quiere probarlo
esta tarde en su casa, ¿puede o se
queda atrapado en los servidores de Google?
Pues, afortunadamente, la adopción de la comunidad open
source está siendo rapidísima.
Cualquier desarrollador familiarizado con Python o PyTorch ya
puede ir a GitHub.
Ya hay repositorios.
Sí, sí.
Pueden clonar implementaciones experimentales de TurboQuant para ensuciarse
las manos con el código desde ya.
Y para la inmensa mayoría de usuarios técnicos
que usamos herramientas más consolidadas para ejecutar IA
local sin programar a bajo nivel.
Para ellos, el horizonte se mide en semanas
o meses.
Proyectos inmensos como Lama CPP, que es el
estándar para ejecutar modelos locales, o el framework
MLX de Apple, están trabajando a contrarreloj para
integrarlo.
Fíjate, en la arquitectura de memoria unificada de
Apple, donde la RAM y la VRAM son
la misma cosa, aliviar el ancho de banda
con esto tiene que ser crítico.
Absolutamente crítico, sí.
El abismo entre la investigación académica y la
herramienta de usuario final se está cerrando a
un ritmo de vértigo.
Qué maravilla.
Pues bueno, recopilando todas las piezas.
Hemos analizado cómo el caché KB devoraba la
memoria local y cómo los valores extremos destrozaban
la compresión tradicional.
Así es.
Y hemos descubierto cómo la matemática de Google,
con la transformada de Hadamard y esa cuadrícula
de 3 bits, logra liberar espacio y velocidad
sin perder ni un ápice de capacidad lógica.
Es increíble.
Y fíjate, antes de terminar, me gustaría dejar
una reflexión sobre esto.
Si hemos logrado multiplicar por 6 la capacidad
de contexto en máquinas locales, simplemente reordenando las
matemáticas, cabe preguntarse, ¿qué otros límites de la
inteligencia artificial actual no son barreras físicas reales
del hardware, sino simples ineficiencias matemáticas esperando a
ser resueltas por el próximo algoritmo brillante?
Ostras, pues es un pensamiento profundo.
Y provocador brutal.
Quizá no necesitamos siempre chips más gigantescos, sino
pensar de manera más elegante.
Yo estoy convencido de ello.
Pues una reflexión extraordinaria para cerrar.
Antes de despedirnos hasta el próximo programa, os
informamos de que las voces que oyes han
sido generadas por la IA de Notebook LM
y que dirigiendo el podcast se encuentra Julio
Pablo Vázquez, un humano que te envía saludos.
En caso de error, probablemente sean errores humanos.
¡Nos escuchamos!
Y hasta aquí el episodio de hoy.
Muchas gracias por tu atención.
Esto es BIMpraxis.
Nos escuchamos en el próximo episodio.