Waner Dev

Software Engineer aprendiendo sobre LLMs locales, GPUs y modelos open-source. Compartiendo el proceso en el camino.

[Waner Dev @WanerDev]

@echodreamz1 @Qwinn3 @Grummz Good for you. I also have a brain and have had a successful career for over a decade. That doesn't mean I shouldn't use a new tool, just like any other tool that has been created, even if it would create trash code. If you use it responsibly, it can give you very good results.

[Waner Dev @WanerDev]

@SkippyKishi @Qwinn3 @Grummz That's true, AI produces a lot of trash, so use it as a tool, not as a replacement for your work.

[Waner Dev @WanerDev]

@Qwinn3 @Grummz A lot of people hate AI just because of their ego. They think they are smarter and better than the rest if they refuse to use AI.

[Waner Dev @WanerDev]

Estaba hablando con un amigo sobre el porqué de que una GPU "con bastante VRAM" iba lenta con un modelo, y me di cuenta de que casi nadie tiene clara una cosa: la VRAM tiene DOS números, no uno. Y son dos cosas distintas.

Yo tampoco lo tenía claro al principio. Lo entendí de verdad cuando me puse a medir en mi propia tarjeta, una Intel Arc Pro B70 de 32 GB. Te lo cuento como lo entendí yo.

Los dos números

Cuando miras la ficha de una GPU para IA local, hay dos cifras de memoria que importan:

- Capacidad: cuántos gigas de VRAM tiene. La mía, 32 GB.
- Ancho de banda: a qué velocidad mueve esos datos. La mía, 608 GB por segundo.

La gente mira solo la primera y piensa "más GB = más rápido". Y no. Cada número responde una pregunta completamente diferente:

- La capacidad decide SI el modelo te entra. Es un sí o no.
- El ancho de banda decide QUÉ TAN RÁPIDO va, o sea los tokens por segundo.

Una tarjeta puede tener muchísima VRAM y ser lenta. Y una con menos VRAM pero más ancho de banda te corre el mismo modelo más rápido. Son ejes separados.

Una forma de verlo

Piensa en una estantería. La capacidad es cuántos libros caben en ella. El ancho de banda es qué tan rápido puedes leerlos todos.

Y acá está el detalle que lo explica todo: para generar UNA sola palabra, el modelo tiene que leerse TODOS sus pesos. Enteros. Una vez por cada token que produce. Token tras token, lectura completa de la estantería entera, una y otra vez.

Por eso la velocidad no depende de cuántos libros caben, sino de qué tan rápido los lees. La capacidad solo decide si los libros llegaron a la estantería; el ancho de banda decide a qué ritmo escupe palabras.

Esto tiene nombre técnico: la generación de texto está "limitada por ancho de banda" (memory-bandwidth-bound). El chip que hace las cuentas casi siempre está esperando a que lleguen los datos, no al revés.

La cuenta que me lo confirmó

Si la velocidad la manda el ancho de banda, debería poder estimarla con una división tonta:

tokens por segundo ≈ ancho de banda ÷ tamaño de los pesos del modelo

En mi caso, Qwen3.5-27B en int4 ocupa 18.4 GB de pesos. Entonces:

608 ÷ 18.4 ≈ 33 tokens por segundo de techo teórico.

¿Y qué medí yo en la tarjeta de verdad? 27.8 tokens por segundo. Como un 84% del techo, y eso corriendo en modo "eager" (sin optimizar) y contando el overhead de la petición. O sea, pegadito al límite que marca el ancho de banda. La cuenta servilleta funcionó. Eso es lo que significa estar limitado por banda: te acercas al techo de la memoria, no al del cómputo.

El bonus: por eso cuantizar también da velocidad

Esto fue lo que me hizo clic. Cuantizar (bajar la precisión de los pesos) no solo sirve para que el modelo QUEPA. También lo hace más RÁPIDO, porque hay menos bytes que leer en cada token.

Mismo modelo, misma tarjeta, misma banda de 608 GB/s, solo cambia la precisión:

- fp16: ~55 GB de pesos → ~11 tok/s teórico (y ni siquiera entra en 32 GB)
- fp8: ~28 GB → ~22 tok/s
- int4: ~18.4 GB → ~33 tok/s (medí ~28)

A menos bytes que leer por token, más tokens por segundo. Cuantizar te ayuda en los dos ejes a la vez: que entre (capacidad) y que vaya rápido (banda).

Donde la regla se matiza (seamos honestos)

No quiero vender la cuenta como una ley perfecta, porque tiene letra chica:

- Es para GENERAR texto (decode), un token a la vez. Leer el prompt que le mandas (el prefill) es otra historia: eso sí carga el cómputo, no la banda.
- Si sirves a varios usuarios en paralelo (batching), el modelo se lee una vez para todos a la vez, y ahí la cosa se vuelve más de cómputo. La cuenta de arriba es para una sola petición.

Pero como modelo mental para entender por qué tu GPU va a la velocidad que va, sirve perfecto.

Lo que me quedó

- Una GPU tiene dos números de memoria: capacidad (GB) y ancho de banda (GB/s). No son lo mismo.
- La capacidad decide si el modelo arranca. El ancho de banda decide si es usable.
- Más VRAM NO hace más rápido un modelo que ya cabía. Lo que da velocidad es la banda.
- Para generar cada token, la GPU se relee todos los pesos. Por eso la velocidad la manda la banda.
- Y por eso cuantizar mata dos pájaros: hace que quepa y que vaya más rápido.

Si vas a elegir hardware para correr modelos en local, no mires solo los GB. Mira los GB/s.

[Waner Dev @WanerDev]

https://t.co/QI8Ztq1yat

[Waner Dev @WanerDev]

@david_nix Buy a PC already built with at least 64GB of RAM and get the graphics cards separately.

[Waner Dev @WanerDev]

@SuiBuilds Let's connect 🫱🏻‍🫲🏻

[Waner Dev @WanerDev]

Más que VRAM ancho de banda, la VRAM no hace diferencia alguna en la velocidad de inferencia. Asumiendo obviamente que todo el modelo cabe en la VRAM, ahí todo el peso de la velocidad recae sobre el ancho de banda de la tarjeta gráfica. En este caso, imagino que él tiene varias GPUs, que puede meter modelos grandes y también sumar ancho de banda de las GPUs

[Waner Dev @WanerDev]

1/ "Tienes 64 GB de RAM, úsala como VRAM y mete más contexto."

Suena lógico. Me lo pregunté yo mismo hoy intentando llegar a 256k de contexto. La respuesta corta: no funciona como uno cree. Te explico por qué, sin rodeos.

2/ Primero, qué hay metido en la VRAM cuando corres un modelo. Dos cosas que pelean por el espacio:

- los pesos del modelo (tamaño fijo)
- el KV cache: la memoria del contexto, que CRECE mientras más larga la conversación

Pesos + KV cache + un poquito de overhead ≤ lo que tiene tu tarjeta. Esa cuenta lo explica todo.

3/ En mi caso (Qwen3.5-27B en int4 en la B70 de 32 GB):

pesos: 18 GB
me quedan ~11 GB para el KV cache
eso da para ~96k tokens de contexto. No los 256k del papel.

Quería estirarlo con la RAM. Acá está el detalle que casi nadie cuenta.

4/ Opción A: mandar el KV cache a la RAM.

vLLM tiene "swap", pero es para sacar conversaciones ENTERAS que no están activas y hacer hueco a otras. La conversación que está trabajando AHORA necesita su KV en la GPU sí o sí, porque el cálculo lo necesita en cada token.

5/ ¿Por qué no se puede traer el KV desde la RAM en cada token? Por velocidad.

La GPU tendría que ir a buscar gigas de datos a la RAM por el bus PCIe en cada paso. Sería tan lento que no vale la pena. La atención necesita esos números AHÍ, en la GPU, ya.

6/ Opción B: mandar los PESOS a la RAM para liberar VRAM para el contexto.

Hago la cuenta: para meter 256k de contexto necesito ~29 GB de KV cache. Mi tarjeta tiene 32. O sea tendría que sacar casi todos los pesos (16 de 18 GB) a la RAM.

7/ ¿Y qué pasa si saco los pesos a la RAM? Que en CADA token la GPU tiene que traerlos de vuelta por PCIe.

Pasaría de ~28 tokens/seg a menos de 1. "Entra", sí. Pero queda inservible de lo lento. No es una solución real, es un truco que no usarías.

8/ La conclusión que me llevé:

la RAM sirve para GUARDAR modelos y para el sistema, no para hacer de VRAM extra en pleno cálculo. Los pesos activos y el KV activo tienen que estar en la GPU. Punto.

9/ ¿Entonces no hay forma de más contexto? La idea correcta no es la RAM: es guardar el KV cache en menos precisión (fp8). Ocupa la mitad → el doble de contexto, todo en la GPU.

Lo probé. Y acá viene lo bueno (y lo honesto).

10/ Arrancó perfecto. Duplicó la memoria del KV, el log decía 96k → casi 200k de contexto. Todo lindo.

Mandé el primer mensaje... y CRASH. El kernel de atención de Intel solo acepta el KV en fp16; el fp8 está a medias en esta versión.

11/ Moraleja doble:

- más RAM ≠ más contexto. El techo lo pone la VRAM.
- y "arrancó bien" no es "funciona". Hay que mandar un request de verdad antes de cantar victoria.

Si quieres leer un poco más sobre esto, lee este artículo que escribí al respecto

[Waner Dev @WanerDev]

https://t.co/b1sQlp1iv2

[Waner Dev @WanerDev]

https://t.co/b1sQlp1iv2

[Waner Dev @WanerDev]

@DAMIADENUGA @grok Need it

[Waner Dev @WanerDev]

@elielAGI @brah_ddah @TheAhmadOsman The only right answer lol

[Waner Dev @WanerDev]

@kalomaze Almost every session lol

[Waner Dev @WanerDev]

@TheAhmadOsman I assume you have that rig running with solar panels?

[Waner Dev @WanerDev]

Estoy preparando un artículo para explicar cómo intenté correr mi primer LLM local en una Intel Arc Pro B70. Cogí un poco de lucha, pero luego de entender par de cositas salí a camino jaja

[Waner Dev @WanerDev]

Este es mi primer artículo acá en X. Explico algunas de las cosas que aprendí mientras intentaba correr ciertos LLMs en mi máquina local. Dale un ojo y espero que te ayude en algo si estás comenzando en este mundillo como yo

[Waner Dev @WanerDev]

https://t.co/40yGp2aJ7g

[Waner Dev @WanerDev]

https://t.co/40yGp2aJ7g

[Waner Dev @WanerDev]

Creo que no fue mala idea para nada comenzar a armar mi setup para correr LLMs locales. Anthropic está iniciando el proceso para su IPO, saben lo que quiere decir eso verdad? Se está casi terminando el subsidio.

Era de esperarse porque el subsidio no se iba a mantener por siempre, pero ahora que van a salir a bolsa los inversores querrán recuperar su dinero (obviamente tienen toda la razón lol).

Así que, cómprate una GPU y comienza a probar, como mismo lo estoy haciendo yo.

#anthropic #llm #ai #claude

[Anthropic @AnthropicAI]

Anthropic has confidentially submitted a draft S-1 registration statement to the Securities and Exchange Commission.

Pending completion of SEC review, this gives us the option to pursue an initial public offering.

Read more: https://t.co/onGZAhRLvD

[Waner Dev @WanerDev]

@theo If they can be deactivated, what is the problem?

[Waner Dev @WanerDev]

Casi todo el que monta IA local lo hace con NVIDIA.

Yo no. Compré una Intel Arc Pro B70 con 32 GB de VRAM y me metí en esto a ver hasta dónde llega.

He estado investigando bien y resulta que Intel tiene su propio stack para esto (llm-scaler) y mi tarjeta está soportada. Así que nada, tengo esperanzas lol. Ya armé la PC, solo me falta comenzar a instalar todo, y ver lo que funciona y lo que explota.

Vamos a ver qué sale.