1
00:00:10,000 --> 00:00:15,800
Buenas, esto es BIMPRAXIS, el podcast donde el

2
00:00:15,800 --> 00:00:17,920
BIM se encuentra con la inteligencia artificial.

3
00:00:20,519 --> 00:00:23,620
Exploramos la ciencia, la tecnología y el futuro

4
00:00:23,620 --> 00:00:26,559
desde el enfoque de la arquitectura, ingeniería y

5
00:00:26,559 --> 00:00:27,179
construcción.

6
00:00:28,859 --> 00:00:29,519
¡Empezamos!

7
00:00:37,280 --> 00:00:38,899
Muy buenas.

8
00:00:38,899 --> 00:00:40,679
Episodio 48.

9
00:00:40,679 --> 00:00:44,060
Hoy continuamos nuestra serie sobre herramientas open source

10
00:00:44,060 --> 00:00:47,659
gratuitas relacionadas con la inteligencia artificial.

11
00:00:47,659 --> 00:00:51,219
Y la de hoy es especialmente interesante para

12
00:00:51,100 --> 00:00:54,200
cualquiera que trabaje con modelos de lenguaje grandes.

13
00:00:54,200 --> 00:00:57,179
Hoy vamos a analizar a fondo VLLM.

14
00:00:57,759 --> 00:00:59,859
Bienvenidos al podcast de BIMPRAXIS.

15
00:00:59,979 --> 00:01:02,719
Nuestra misión hoy es desentrañar por qué esta

16
00:01:02,719 --> 00:01:05,159
herramienta está causando tanto revuelo.

17
00:01:05,180 --> 00:01:07,280
Tenemos como fuente el paper original de sus

18
00:01:07,280 --> 00:01:09,939
creadores en UC Berkeley y también, claro, la

19
00:01:09,939 --> 00:01:11,519
documentación del proyecto.

20
00:01:11,939 --> 00:01:14,159
Vale, vamos a empezar a desgranar esto.

21
00:01:14,280 --> 00:01:15,920
Lo primero que llama la atención es el

22
00:01:15,920 --> 00:01:19,140
problema que VLLM intenta resolver.

23
00:01:19,420 --> 00:01:22,840
Ejecutar estos modelos de lenguaje gigantescos es carísimo.

24
00:01:21,859 --> 00:01:24,560
Una de las fuentes estima que procesar una

25
00:01:24,560 --> 00:01:27,920
petición a un LLM puede ser, ojo, 10

26
00:01:27,920 --> 00:01:30,180
veces más caro que una búsqueda de palabras

27
00:01:30,180 --> 00:01:31,319
clave tradicional.

28
00:01:31,400 --> 00:01:32,659
Exacto.

29
00:01:32,659 --> 00:01:34,879
Y el principal cuello de botella, que es

30
00:01:34,879 --> 00:01:37,420
lo interesante, no es siempre la capacidad de

31
00:01:37,420 --> 00:01:38,400
cálculo.

32
00:01:38,379 --> 00:01:39,040
No.

33
00:01:39,040 --> 00:01:41,140
Uno pensaría que es la potencia bruta de

34
00:01:41,140 --> 00:01:42,019
la máquina.

35
00:01:42,319 --> 00:01:43,680
Pues no siempre.

36
00:01:43,680 --> 00:01:44,920
Es la memoria.

37
00:01:44,920 --> 00:01:46,939
La memoria de las GPUs.

38
00:01:47,040 --> 00:01:49,359
Pensemos en una GPU potente como la NVIDIA

39
00:01:49,359 --> 00:01:52,019
A100, con 40 GB de memoria, que es

40
00:01:52,019 --> 00:01:53,400
el ejemplo que usan.

41
00:01:52,920 --> 00:01:55,099
El paper nos da un desglose que es

42
00:01:55,099 --> 00:01:56,459
muy revelador.

43
00:01:56,780 --> 00:02:00,780
Aproximadamente el 65% de esa memoria se va

44
00:02:00,780 --> 00:02:03,299
solo en almacenar los pesos del modelo.

45
00:02:03,299 --> 00:02:04,359
Que son estáticos, ¿no?

46
00:02:04,359 --> 00:02:04,959
No cambian.

47
00:02:05,260 --> 00:02:06,640
Eso es, son estáticos.

48
00:02:06,959 --> 00:02:09,939
Pero casi un 30% se destina a algo

49
00:02:09,939 --> 00:02:11,719
llamado la caché caure.

50
00:02:11,800 --> 00:02:14,180
Y esta, esta es la clave de todo.

51
00:02:14,039 --> 00:02:15,280
Caché KV.

52
00:02:15,280 --> 00:02:17,039
Suena técnico, pero es fundamental.

53
00:02:17,199 --> 00:02:19,159
Es básicamente la memoria a corto plazo del

54
00:02:19,159 --> 00:02:20,960
modelo para una conversación.

55
00:02:21,120 --> 00:02:24,080
Cuando generas texto, el modelo necesita recordar el

56
00:02:24,080 --> 00:02:27,099
contexto, las palabras anteriores, para saber qué viene

57
00:02:27,099 --> 00:02:28,000
después.

58
00:02:28,159 --> 00:02:30,280
Esa memoria es la caché KV.

59
00:02:30,240 --> 00:02:30,539
Justo.

60
00:02:30,539 --> 00:02:33,340
El problema es que es dinámica.

61
00:02:33,340 --> 00:02:35,840
Crece con cada nueva palabra generada y su

62
00:02:35,840 --> 00:02:37,380
tamaño final.

63
00:02:37,380 --> 00:02:38,580
Es impredecible.

64
00:02:38,580 --> 00:02:40,100
Totalmente impredecible.

65
00:02:40,100 --> 00:02:41,620
Y ahí está el gran reto.

66
00:02:41,620 --> 00:02:44,900
Los sistemas tradicionales para gestionar esta memoria recurrían

67
00:02:44,900 --> 00:02:47,800
a una solución, digamos, poco eficiente.

68
00:02:47,800 --> 00:02:49,280
¿Qué hacían exactamente?

69
00:02:49,280 --> 00:02:52,200
Reservaban un bloque de memoria contiguo y enorme

70
00:02:52,200 --> 00:02:55,120
para cada petición, pensando siempre en la longitud

71
00:02:55,120 --> 00:02:57,340
máxima posible de la respuesta.

72
00:02:57,340 --> 00:02:59,920
Por ejemplo, 2048 tokens.

73
00:03:00,020 --> 00:03:01,400
Ahí es donde la cosa se pone de

74
00:03:01,400 --> 00:03:02,860
verdad interesante.

75
00:03:02,860 --> 00:03:05,440
Esta solución es como reservar un autobús entero

76
00:03:05,440 --> 00:03:07,620
para una sola persona por si acaso decide

77
00:03:07,620 --> 00:03:09,640
invitar a 50 amigos por el camino.

78
00:03:09,700 --> 00:03:10,680
Esa es la analogía.

79
00:03:10,680 --> 00:03:13,040
Y el resultado, según los datos del estudio,

80
00:03:13,040 --> 00:03:15,080
es un desperdicio masivo.

81
00:03:14,100 --> 00:03:18,180
En sistemas como Faster Transformer u Orca, solo

82
00:03:18,180 --> 00:03:20,640
entre el 20% y el 40% de la

83
00:03:20,640 --> 00:03:23,260
memoria de la caché KTV se usa realmente

84
00:03:23,260 --> 00:03:25,540
para almacenar información útil.

85
00:03:25,540 --> 00:03:27,380
¿Un momento, solo un 20 o 40%?

86
00:03:28,060 --> 00:03:28,780
Sí, sí.

87
00:03:28,780 --> 00:03:30,740
El resto se pierde por lo que llaman

88
00:03:30,740 --> 00:03:33,220
fragmentación interna y externa.

89
00:03:33,220 --> 00:03:34,880
Es un desperdicio enorme.

90
00:03:34,880 --> 00:03:36,140
Madre mía.

91
00:03:36,140 --> 00:03:38,540
Vayamos entonces a la solución, que me parece

92
00:03:38,540 --> 00:03:39,860
fascinante.

93
00:03:39,860 --> 00:03:41,500
Lo que es fascinante aquí es la solución

94
00:03:41,500 --> 00:03:44,980
que proponen los creadores de VLM llamada Paged

95
00:03:44,980 --> 00:03:46,080
Attention.

96
00:03:46,080 --> 00:03:48,600
La inspiración viene de un concepto clásico de

97
00:03:48,600 --> 00:03:51,660
los sistemas operativos, la memoria virtual y la

98
00:03:51,660 --> 00:03:52,700
paginación.

99
00:03:52,700 --> 00:03:54,020
Una idea brillante.

100
00:03:54,020 --> 00:03:56,200
O sea, no están inventando la rueda, sino

101
00:03:56,200 --> 00:04:00,000
aplicando un concepto superprobado a un problema nuevo.

102
00:04:00,000 --> 00:04:01,000
Totalmente.

103
00:04:01,000 --> 00:04:03,140
En lugar de exigir un gran bloque de

104
00:04:03,140 --> 00:04:07,240
memoria contiguo, Paged Attention divide la caché KB

105
00:04:07,240 --> 00:04:09,900
en pequeños bloques de tamaño fijo.

106
00:04:09,900 --> 00:04:11,660
Como si fueran páginas de un libro.

107
00:04:11,660 --> 00:04:13,540
Esa es la analogía perfecta.

108
00:04:13,540 --> 00:04:15,300
Es como si en lugar de necesitar una

109
00:04:15,300 --> 00:04:17,720
estantería vacía y larguísima para un libro que

110
00:04:17,720 --> 00:04:20,340
aún no se ha escrito, simplemente vas añadiendo

111
00:04:20,340 --> 00:04:22,220
páginas sueltas donde encuentres hueco.

112
00:04:22,820 --> 00:04:24,360
Y tienes un índice que te dice dónde

113
00:04:24,360 --> 00:04:25,500
está cada una.

114
00:04:25,380 --> 00:04:27,640
Y los asigna dinámicamente a medida que se

115
00:04:27,640 --> 00:04:29,040
generan nuevas palabras.

116
00:04:29,520 --> 00:04:31,960
Y esto elimina casi por completo la fragmentación,

117
00:04:31,960 --> 00:04:32,640
claro.

118
00:04:32,740 --> 00:04:33,800
Casi por completo.

119
00:04:34,000 --> 00:04:35,960
La memoria no utilizada es mínima.

120
00:04:35,420 --> 00:04:38,720
Se confina al último bloque de cada secuencia.

121
00:04:38,760 --> 00:04:40,540
Y como todos los bloques tienen el mismo

122
00:04:40,540 --> 00:04:43,780
tamaño, se pueden reutilizar de forma muy, muy

123
00:04:43,780 --> 00:04:44,860
eficiente.

124
00:04:44,660 --> 00:04:46,560
Vale, ¿y todo esto en qué se traduce

125
00:04:46,560 --> 00:04:47,720
en la práctica?

126
00:04:47,720 --> 00:04:49,660
¿Qué gana alguien que use VBLM?

127
00:04:50,120 --> 00:04:52,940
Pues el resultado directo es un aumento espectacular

128
00:04:52,940 --> 00:04:54,740
del rendimiento, el throughput.

129
00:04:55,220 --> 00:04:56,560
¿De cuánto estamos hablando?

130
00:04:56,640 --> 00:05:00,320
Las evaluaciones del paper muestran que VBLM consigue

131
00:05:00,320 --> 00:05:02,660
entre 2 y 4 veces más rendimiento que

132
00:05:02,660 --> 00:05:05,640
otros sistemas de última generación, y esto con

133
00:05:05,640 --> 00:05:07,480
el mismo nivel de latencia.

134
00:05:07,340 --> 00:05:08,680
¿2 a cuatro veces.

135
00:05:08,680 --> 00:05:10,600
Es una barbaridad.

136
00:05:10,800 --> 00:05:13,820
Permite procesar muchas más peticiones simultáneamente en la

137
00:05:13,820 --> 00:05:14,960
misma GPU.

138
00:05:14,760 --> 00:05:17,840
Simplemente porque aprovecha la memoria de una forma

139
00:05:17,840 --> 00:05:19,520
mucho más inteligente.

140
00:05:19,260 --> 00:05:21,200
Y no es solo una cuestión de no

141
00:05:21,200 --> 00:05:22,800
desperdiciar memoria.

142
00:05:23,020 --> 00:05:26,400
Esta arquitectura de páginas o bloques abre la

143
00:05:26,400 --> 00:05:29,040
puerta a optimizaciones muy ingeniosas, ¿verdad?

144
00:05:29,100 --> 00:05:31,900
Sí, y esto conecta con el panorama general.

145
00:05:31,980 --> 00:05:34,840
Permite compartir memoria de forma muy flexible.

146
00:05:34,960 --> 00:05:37,760
Por ejemplo, en el muestreón paralelo, cuando pides

147
00:05:37,760 --> 00:05:40,360
al modelo varias posibles respuestas a un mismo

148
00:05:40,360 --> 00:05:40,620
prompt.

149
00:05:41,080 --> 00:05:44,740
Claro, todas las respuestas comparten el contexto inicial.

150
00:05:44,740 --> 00:05:46,440
El prompt es el mismo.

151
00:05:46,240 --> 00:05:46,680
Eso es.

152
00:05:46,680 --> 00:05:50,420
Con BLLM, todas esas secuencias pueden apuntar a

153
00:05:50,420 --> 00:05:52,580
los mismos bloques de memoria física para el

154
00:05:52,580 --> 00:05:56,080
prompt, ahorrando una cantidad significativa de espacio.

155
00:05:55,980 --> 00:05:57,480
¿Y se cuantifica ese ahorro?

156
00:05:57,640 --> 00:06:00,100
Sí, el estudio lo cuantifica entre un 6

157
00:06:00,100 --> 00:06:02,620
y un 10% en sus experimentos.

158
00:06:02,920 --> 00:06:05,940
¿Y mencionan un mecanismo llamado copia en escritura,

159
00:06:05,940 --> 00:06:08,160
o copy and write, otro concepto de los

160
00:06:08,160 --> 00:06:09,080
sistemas operativos?

161
00:06:09,520 --> 00:06:10,020
Correcto.

162
00:06:10,020 --> 00:06:12,900
Cuando una de las secuencias necesita modificar un

163
00:06:12,900 --> 00:06:16,140
bloque compartido, en lugar de alterarlo para todas…

164
00:06:16,360 --> 00:06:18,280
El sistema crea una copia de ese bloque

165
00:06:18,280 --> 00:06:19,900
solo para esa secuencia.

166
00:06:20,020 --> 00:06:21,260
Tremendamente eficiente, sí.

167
00:06:21,260 --> 00:06:23,500
Y esto se vuelve aún más potente en

168
00:06:23,500 --> 00:06:26,340
algoritmos más complejos como la búsqueda por haz,

169
00:06:26,340 --> 00:06:26,760
Beam Search.

170
00:06:27,100 --> 00:06:29,480
Donde hay muchos candidatos a mejor respuesta que

171
00:06:29,480 --> 00:06:31,380
comparten gran parte de su historia.

172
00:06:31,480 --> 00:06:33,780
Ahí el ahorro de memoria, según el paper,

173
00:06:33,780 --> 00:06:36,340
puede llegar a ser superior al 55%.

174
00:06:36,620 --> 00:06:38,020
Más del 55%.

175
00:06:38,020 --> 00:06:39,840
Es un cambio de paradigma total.

176
00:06:40,240 --> 00:06:41,620
Desde luego.

177
00:06:41,620 --> 00:06:42,980
Y por lo que veo en la documentación

178
00:06:42,980 --> 00:06:45,960
del proyecto, VLM no es solo un concepto

179
00:06:45,960 --> 00:06:46,660
académico.

180
00:06:46,660 --> 00:06:49,280
Es un proyecto de código abierto muy activo.

181
00:06:49,060 --> 00:06:50,960
Sí, empezó en UC Berkeley, pero ahora es

182
00:06:50,960 --> 00:06:52,840
totalmente comunitario.

183
00:06:52,360 --> 00:06:54,780
ofrece integración con los modelos más populares de

184
00:06:54,780 --> 00:06:57,260
Hugging Face, una API compatible con la de

185
00:06:57,000 --> 00:06:59,980
OpenAI para facilitar la adopción, lo cual es

186
00:06:59,980 --> 00:07:02,880
un movimiento muy inteligente para que la gente

187
00:07:02,880 --> 00:07:06,100
lo pueda probar y migrar fácilmente, y funciona

188
00:07:06,100 --> 00:07:09,180
en una variedad de hardware impresionante.

189
00:07:09,180 --> 00:07:12,940
GPUs de NVIDIA y AMD e incluso soporte

190
00:07:12,940 --> 00:07:16,640
para hardware de Intel, IBM o Google.

191
00:07:16,640 --> 00:07:19,940
Además, esta arquitectura de gestión de memoria resuelve

192
00:07:19,940 --> 00:07:21,880
otros casos de uso comunes.

193
00:07:21,880 --> 00:07:25,000
Por ejemplo, las peticiones que comparten un prefijo

194
00:07:25,000 --> 00:07:26,040
común.

195
00:07:26,040 --> 00:07:28,880
Como una serie larga de instrucciones o ejemplos

196
00:07:28,880 --> 00:07:31,460
que se repiten para diferentes usuarios, te refieres.

197
00:07:31,460 --> 00:07:32,520
Justo.

198
00:07:32,520 --> 00:07:36,140
Con VBLM, la caché KV de ese prefijo

199
00:07:36,140 --> 00:07:38,740
se puede calcular una sola vez y reutilizar

200
00:07:38,740 --> 00:07:40,260
para todas las peticiones.

201
00:07:40,260 --> 00:07:42,020
Acelerando enormemente el proceso.

202
00:07:42,020 --> 00:07:43,020
Muchísimo.

203
00:07:43,500 --> 00:07:46,381
Los experimentos con un modelo de traducción muestran

204
00:07:46,381 --> 00:07:49,381
mejoras de hasta 3.5 veces en el rendimiento

205
00:07:49,381 --> 00:07:50,661
gracias a esto.

206
00:07:50,781 --> 00:07:53,141
Es una optimización muy potente.

207
00:07:52,881 --> 00:07:58,621
Entonces, resumiendo, VLLM ataca un problema fundamental, la

208
00:07:58,621 --> 00:08:01,421
ineficiencia de la memoria en la inferencia de

209
00:08:01,421 --> 00:08:05,541
LLMs, con una solución elegante, inspirada en décadas

210
00:08:05,541 --> 00:08:08,501
de conocimiento en sistemas operativos y los resultados

211
00:08:08,501 --> 00:08:11,201
son, bueno, espectaculares.

212
00:08:11,181 --> 00:08:13,361
Y esto plantea una pregunta importante de cara

213
00:08:13,361 --> 00:08:14,241
al futuro.

214
00:08:14,521 --> 00:08:16,701
El paper señala que la velocidad de computación

215
00:08:16,701 --> 00:08:18,821
de las GPUs crece más rápido que su

216
00:08:18,821 --> 00:08:20,201
capacidad de memoria.

217
00:08:20,141 --> 00:08:22,241
El cuello de botella de la memoria es

218
00:08:22,241 --> 00:08:23,861
cada vez más crítico.

219
00:08:23,981 --> 00:08:24,621
Cada vez más.

220
00:08:25,441 --> 00:08:28,981
VLLM lo soluciona a nivel de software.

221
00:08:29,401 --> 00:08:31,901
La pregunta a reflexionar es, ¿deberían los futuros

222
00:08:31,901 --> 00:08:34,641
diseños de hardware para IA incorporar de base

223
00:08:34,641 --> 00:08:37,241
principios de gestión de memoria no contigua como

224
00:08:37,241 --> 00:08:38,241
la paginación?

225
00:08:38,241 --> 00:08:39,901
Es una gran pregunta.

226
00:08:39,901 --> 00:08:41,781
¿Podríamos estar viendo el principio del fin de

227
00:08:41,781 --> 00:08:43,801
la idea de que los grandes tensores de

228
00:08:43,801 --> 00:08:46,521
datos deben residir siempre en bloques contiguos de

229
00:08:46,521 --> 00:08:48,481
memoria para ser eficientes?

230
00:08:48,241 --> 00:08:49,321
Quizá.

231
00:08:49,321 --> 00:08:52,181
BLM ha demostrado que hay otro camino, uno

232
00:08:52,181 --> 00:08:55,081
mucho más eficiente, y puede que el hardware

233
00:08:55,081 --> 00:08:57,561
del futuro tenga que empezar a pensar de

234
00:08:57,561 --> 00:08:58,841
esta manera.

235
00:08:58,841 --> 00:09:00,501
Y así hemos llegado al final de nuestro

236
00:09:00,501 --> 00:09:01,841
episodio de hoy.

237
00:09:01,841 --> 00:09:04,061
Os recordamos que detrás de las voces sintéticas

238
00:09:04,061 --> 00:09:06,281
que escucháis en estos episodios, y que están

239
00:09:06,281 --> 00:09:09,381
generadas con Notebook LM, pues en la trastienda

240
00:09:09,381 --> 00:09:12,361
está un humano con meñiques, muñecas y riñones,

241
00:09:12,881 --> 00:09:14,701
entre otras cosas, que no es otro que

242
00:09:14,701 --> 00:09:16,901
Julio Pablo Vázquez, el que dirige el podcast.

243
00:09:17,581 --> 00:09:19,941
Si escuchas algún error, el error será humano

244
00:09:19,941 --> 00:09:22,801
en un 99% de los casos.

245
00:09:22,901 --> 00:09:25,101
Ya sabes a quién pedir explicaciones.

246
00:09:25,241 --> 00:09:26,101
Hasta la próxima, amigos.

247
00:09:37,381 --> 00:09:39,541
Y hasta aquí el episodio de hoy.

248
00:09:39,541 --> 00:09:41,121
Muchas gracias por tu atención.

249
00:09:50,881 --> 00:09:53,141
Esto es BIMPRAXIS.

250
00:09:53,141 --> 00:09:55,221
Nos escuchamos en el próximo episodio.

251
00:10:16,561 --> 00:10:16,621
¡Suscríbete al canal!