Cómo guarda números una computadora

En la lección de imágenes viste que cada color de un píxel es un número del 0 al 255. En la de unidades, que un byte son 8 bits. Aquí vamos a abrir ese byte: cómo se escribe un número con ceros y unos, por qué el tope es 255 y qué pasa cuando un número no cabe.

Contar en binario

Piensa en cómo escribes el 236. Cada posición vale 10 veces la de su derecha: 236 = 2 × 100 + 3 × 10 + 6 × 1. Hay diez dígitos, del 0 al 9, porque contamos en base 10.

Un bit solo tiene dos estados, que se escriben 0 y 1 (en el chip son, por ejemplo, un voltaje bajo o uno alto). Por eso la computadora cuenta en base 2, el sistema binario: solo hay dos dígitos y cada posición vale el doble que la de su derecha. De derecha a izquierda, las posiciones de un byte valen 1, 2, 4, 8, 16, 32, 64 y 128.

Para escribir un número en binario, recorre las posiciones de la más grande a la más chica. Si su valor cabe en lo que te queda, pones un 1 y lo restas; si no, pones un 0.

¿Cuántos números distintos caben en n bits? Cada bit que agregas duplica las combinaciones: con 1 bit hay 2 (0 y 1); con 2, cuatro (00, 01, 10 y 11); con 8, 2⁸ = 256. Por eso un byte guarda del 0 al 255: son 256 valores y el primero es el 0. Es la misma cuenta de potencias de 2 de la lección de unidades, donde 1 KiB son 2¹⁰ = 1,024 bytes.

for n in (5, 13, 236, 255):
    print(f"{n:>3} en binario es {n:08b}")

bits = "11101100"
sin_signo = int(bits, 2)                       # uint8: cada bit suma su valor
con_signo = sin_signo - 256 if bits[0] == "1" else sin_signo   # int8: el primero vale −128
print(bits, "como uint8 vale", sin_signo, "y como int8 vale", con_signo)

print("valores posibles con 1 a 8 bits:", [2**b for b in range(1, 9)])

  5 en binario es 00000101
 13 en binario es 00001101
236 en binario es 11101100
255 en binario es 11111111
11101100 como uint8 vale 236 y como int8 vale -20
valores posibles con 1 a 8 bits: [2, 4, 8, 16, 32, 64, 128, 256]

Enteros sin signo y con signo

Un entero (integer) es un número sin decimales. En la computadora cada entero tiene un tamaño fijo en bits, y el tamaño decide su rango.

Si todos los bits suman, el entero es sin signo (unsigned): es el uint8 de los píxeles, del 0 al 255.

Para tener negativos, todas las computadoras de hoy usan el mismo truco, el complemento a dos (two's complement): el primer bit, el de la izquierda, vale negativo. En un int8 vale −128 en lugar de 128:

• 0111 1111 = 64 + 32 + 16 + 8 + 4 + 2 + 1 = 127, el más grande.
• 1000 0000 = −128, el más chico.
• 1111 1111 = −128 + 127 = −1.
• 1110 1100 = −128 + 64 + 32 + 8 + 4 = −20.

Fíjate en el último: son los mismos bits que el 236. Los bits no dicen qué número son; lo dice el tipo de dato. Si un programa escribe un uint8 y otro lo lee como int8, el 236 se vuelve −20 sin ningún error. Por eso cada tensor lleva escrito su tipo, como verás más adelante.

¿Por qué ese truco y no un bit de signo aparte? Porque así sumar es igual con signo o sin signo, y el chip usa el mismo circuito para las dos cosas. Prueba −1 + 1: 1111 1111 + 0000 0001 = 1 0000 0000. El noveno bit no cabe en el byte y se pierde; quedan 0000 0000 = 0. Correcto.

La regla general: con n bits, un entero sin signo va de 0 a 2ⁿ − 1, y uno con signo, de −2ⁿ⁻¹ a 2ⁿ⁻¹ − 1. Pruébala.

Overflow: cuando el número no cabe

¿Qué pasa con 255 + 1 en un uint8? El resultado, 256, necesita 9 bits: 1 0000 0000. El noveno se pierde y queda 0. Eso es un overflow (desbordamiento): el resultado no cabe en el tipo de dato.

Hay dos maneras de manejarlo:

• Dar la vuelta (wraparound): se pierde lo que no cabe y el número reaparece del otro lado. En uint8, 255 + 1 = 0 y 250 + 10 = 4. En int8, 127 + 1 = −128: del más grande al más negativo.
• Saturarse (saturation): el número se queda en la orilla. 250 + 10 = 255.

Los arreglos de enteros de NumPy y de PyTorch dan la vuelta, y en silencio: no hay error ni aviso. La función cv2.add de OpenCV, en cambio, se satura. Los enteros propios de Python no se desbordan nunca: crecen lo que haga falta. Por eso el código de abajo imita el uint8 con % 256, el residuo de dividir entre 256.

Esto muerde de verdad al trabajar con fotos. Si quieres aclarar una foto sumándole 10 a cada píxel en uint8, un blanco de 250 queda en 4: casi negro. Si promedias dos fotos sumando primero, (200 + 100) ÷ 2 da 22 en vez de 150, porque la suma ya había dado la vuelta.

def uint8(x):                  # como un arreglo uint8 de NumPy o PyTorch: da la vuelta
    return x % 256

def saturar(x):                # como cv2.add de OpenCV: se queda en la orilla
    return max(0, min(255, x))

for a, b in ((250, 10), (200, 100), (10, -20)):
    print(f"{a} {'+' if b > 0 else '-'} {abs(b)}: da la vuelta → {uint8(a + b):>3} · se satura → {saturar(a + b)}")

print("promedio de 200 y 100 sumando en uint8:", uint8(200 + 100) // 2)
print("promedio de 200 y 100 con un int de Python:", (200 + 100) // 2)

maximo = 2**31 - 1             # el int32 más grande
print(f"un contador int32 llega a {maximo:,}: a 116 fotos por segundo, en {maximo / 116 / 86400:.0f} días")

250 + 10: da la vuelta →   4 · se satura → 255
200 + 100: da la vuelta →  44 · se satura → 255
10 - 20: da la vuelta → 246 · se satura → 0
promedio de 200 y 100 sumando en uint8: 22
promedio de 200 y 100 con un int de Python: 150
un contador int32 llega a 2,147,483,647: a 116 fotos por segundo, en 214 días

La salida es convertir a un tipo más grande antes de hacer cuentas (int32 o float32) y, al final, recortar a 0–255 antes de volver a uint8.

Los contadores también dan la vuelta: en la sección extra «En la vida real» está uno de C01, junto con los desbordes que tumbaron un cohete y el contador de YouTube.

Los números con decimales también se desbordan, pero de otra forma: se vuelven infinito. Lo ves en la siguiente sección.

Los números de un modelo casi nunca son enteros: un peso vale 0.0213 o −1.7, un logit 3.0, un gradiente 0.000004, la pérdida 2.3. Y en el mismo cálculo conviven números enormes y diminutos.

¿Y si guardamos siempre, digamos, 4 decimales? No alcanza: 0.000004 quedaría en 0.0000, y los decimales sobran cuando el número es 150,528. Lo que sirve es la notación científica de la lección de unidades: 150,528 = 1.50528 × 10⁵ y 0.000004 = 4 × 10⁻⁶. Se guardan dos cosas: los dígitos (1.50528) y el exponente (5), que dice dónde va el punto. Como el punto se mueve según el exponente, el formato se llama punto flotante (floating point).

La computadora hace lo mismo, pero en base 2: escribe cada número como «1.algo» por una potencia de 2. Para eso necesita las posiciones del binario después del punto, que valen 1/2, 1/4, 1/8, 1/16… Así, 0.101 en binario es 1/2 + 1/8 = 0.625. Para no confundirlos con los decimales, a los números en binario les pongo un ₂ chiquito: 0.101₂ = 0.625.

Un número de punto flotante se guarda en tres partes:

1. 1

   El signo

   Un bit: 0 si es positivo, 1 si es negativo.

2. 2

   El exponente

   Unos bits que dicen a qué potencia se eleva el 2: dónde va el punto. Se guarda sumándole un número fijo, el sesgo (bias), para no necesitar otro signo: en FP32, el exponente 2 se guarda como 2 + 127 = 129.

3. 3

   La mantisa

   Los dígitos que van después del «1.». El 1 de adelante no se guarda: en binario, el primer dígito distinto de cero siempre es 1, así que se da por hecho y es un bit gratis.

El valor es: (−1)^signo × 1.mantisa × 2^(exponente guardado − sesgo).

Los números de punto flotante no están parejos

En FP32, con 23 bits de mantisa, entre 1 y 2 caben 2²³ = 8,388,608 números, todos a la misma distancia: ≈ 0.00000012. Entre 2 y 4 caben otros tantos, así que quedan al doble de distancia. Entre 1,024 y 2,048, a ≈ 0.000122. Cada vez que el número se duplica, la separación también.

Eso es justo lo que se busca: el error es relativo. Un número cercano a 1 se guarda con un error menor que una diezmillonésima; uno cercano a un millón, con un error de centésimas; y los dos están igual de bien guardados para su tamaño: a menos de 0.000006 % de su valor. La figura lo muestra con un formato de 8 bits, donde se pueden dibujar todos los números que existen.

Infinito y NaN

Algunas combinaciones de bits están reservadas. Con el exponente todo en unos, el número es infinito (inf) o NaN (not a number, «no es un número»):

• inf aparece cuando un resultado es demasiado grande para el formato: es el overflow de los números con decimales. También sale al dividir entre cero un número que no es 0, en NumPy o en PyTorch (Python, en cambio, da un error).
• NaN aparece con cuentas que no tienen respuesta: 0 ÷ 0, infinito menos infinito, o un inf multiplicado por 0.

NaN contagia: cualquier suma, resta, multiplicación o división con un NaN da NaN. Y NaN es distinto de todo, hasta de sí mismo: x == x es falso si x es NaN. Basta un NaN en la pérdida para que la backpropagation llene de NaN todos los gradientes, y el siguiente paso, todos los pesos. Por eso «loss = nan» es la falla de entrenamiento más famosa, y muchas veces empieza con un overflow.

Todos los formatos de punto flotante hacen lo mismo; lo que cambia es cuántos bits le tocan al exponente y cuántos a la mantisa. La regla para recordarlos: los bits de exponente dan el rango (qué tan grande o qué tan chico puede ser el número) y los de mantisa dan la precisión (cuántas cifras guarda).

FP32: la referencia

Es el float32 de la lección de imágenes. Con él se entrena por omisión, es el tipo que PyTorch usa si no le pides otro, y contra él se compara cualquier otro formato. Guarda ≈ 7 cifras y llega hasta ≈ 3.4 × 10³⁸: para casi todo, sobra. Su problema es el tamaño: 4 bytes por número.

FP16: la mitad de memoria y un techo de 65,504

FP16 (half precision, media precisión) usa 2 bytes. Con 5 bits de exponente, su potencia más grande es 2¹⁵, y el número más grande que guarda es (2 − 2⁻¹⁰) × 2¹⁵ = 65,504. Lo que pase de ahí se vuelve inf. Por abajo, el más chico con todas sus cifras es ≈ 0.000061; debajo quedan unos números especiales con menos cifras, los subnormales, que llegan a ≈ 0.00000006, y lo que sea más chico se vuelve 0.

Con 10 bits de mantisa guarda ≈ 3 cifras: junto al 1, la separación es 2⁻¹⁰ ≈ 0.001, así que 1.0001 no existe y se guarda como 1.

En una CNN como la de C01, los números se quedan lejos del techo, y FP16 es la elección normal para servir: C01 corre su modelo como un engine de TensorRT (el modelo ya convertido por la herramienta de NVIDIA para correr rápido en su GPU), y ese engine trabaja en FP16. En un transformer es otra historia. Dos ejemplos:

• Exponenciales. e¹¹ ≈ 59,874 cabe, pero e¹² ≈ 162,755 ya no. Un softmax hecho sin cuidado en FP16 da inf con cualquier logit mayor que ≈ 11.09, que es el logaritmo natural de 65,504. Por eso las librerías le restan a todos los logits el más alto, el truco de la lección «Qué es un modelo».
• Cuadrados. 255² = 65,025 cabe; 256² = 65,536 ya no. Medir el tamaño de un vector de activaciones suma cuadrados, y basta un valor de 256 para que el resultado sea inf.

La Ronda, en M04, lo resume: las activaciones de un transformer tienen valores atípicos que pueden pasar de 65,504, y en FP16 se vuelven inf y después NaN.

BF16: el rango de FP32 con menos precisión

BF16 (bfloat16, de brain floating point: se inventó en Google Brain) también usa 2 bytes, pero los reparte al revés que FP16: 8 bits de exponente, los mismos de FP32, y solo 7 de mantisa. De hecho, un BF16 son los primeros 16 bits de un FP32: para convertir, se redondea y se tira la segunda mitad.

El resultado es el rango de FP32 (hasta ≈ 3.4 × 10³⁸) con 2 o 3 cifras. Compara los tres con los mismos números:

BF16 se equivoca más en cada número, pero prácticamente nunca se desborda donde FP32 no lo haría. Y resulta que las redes neuronales toleran muy bien la imprecisión (el ruido del entrenamiento es mucho más grande que ese error), pero no el overflow. Por eso los LLMs se entrenan y se sirven en BF16, y por eso la Ronda (M04) dice que BF16 «le ganó» a FP16 en los LLMs.

Un detalle de hardware que la Ronda subraya: BF16 existe en las GPUs desde la generación Ampere (la A100 y la A10G) en adelante, pero no en la T4. Servir en una T4 un LLM entrenado en BF16 obliga a FP16, con riesgo de overflow, o a FP32, con el doble de memoria y unas 8 veces menos velocidad de cálculo.

En PyTorch: el dtype de cada tensor

Cada tensor de PyTorch guarda todos sus números en el mismo formato, y ese formato es su dtype (data type, tipo de dato). El dtype decide cuántos bytes ocupa cada número y cómo se leen sus bits.

Lo que PyTorch elige solo: un tensor con decimales nace en float32; uno con enteros, en int64. La memoria de un tensor es su cantidad de números por los bytes de su dtype. El tensor de la foto de Ana, de shape [1, 3, 224, 224], tiene 150,528 números: ocupa 602,112 bytes (≈ 602 KB) en float32, la mitad en float16 y ≈ 151 KB en uint8.

Así se ve en código. Es una ilustración: necesita PyTorch, que no viene con Python, y por eso no lleva su salida; lo que imprime está en los comentarios.

import torch

x = torch.tensor([0.1, 2.5])          # con decimales: nace en float32
print(x.dtype, x.element_size())      # torch.float32 4  (4 bytes por número)
x16 = x.to(torch.float16)             # una copia en FP16, con la mitad de bytes
etiquetas = torch.tensor([3, 41])     # enteros: nacen en int64
print(etiquetas.dtype)                # torch.int64
foto = torch.zeros(1, 3, 224, 224, dtype=torch.uint8)
print(foto.float().div(255).dtype)    # torch.float32: así se convierte la foto

FP16 corta los bytes a la mitad. Para bajar a la cuarta parte o menos se usan enteros. Guardar los números de un modelo con menos bits se llama cuantización (quantization), y la versión más común es INT8: cada número se guarda como un entero de 8 bits, más una escala que comparte todo el grupo.

valor ≈ escala × entero

Para un grupo de números, por ejemplo los pesos de una capa:

1. 1

   Elige la escala

   Que el valor más grande del grupo, sin importar el signo, caiga en el entero más grande: escala = máximo ÷ 127. Se llama cuantización simétrica, porque usa los enteros de −127 a 127.

2. 2

   Cuantiza

   Divide cada número entre la escala y redondea al entero más cercano: entero = redondear(valor ÷ escala).

3. 3

   Para usarlo, descuantiza

   Multiplica de vuelta: valor ≈ entero × escala. Si el número estaba dentro del rango, el error es, a lo mucho, medio escalón: escala ÷ 2.

Un solo valor atípico arruina la escala

Ahora agrega a esa capa un solo peso de 25. La escala pasa a 25 ÷ 127 ≈ 0.197: diez veces más gruesa. El mismo 0.1 se guarda como redondear(0.508) = 1 y vuelve como 0.197, con un error de 97 %. Un valor extremo le quitó resolución a todos los demás. Casi todo el arte de cuantizar es elegir escalas que no desperdicien los 8 bits:

• Una escala por canal (per-channel): en una convolución, cada filtro tiene sus propios pesos y su propia escala, en vez de una sola para toda la capa. Es lo normal para los pesos.
• Recortar los extremos: elegir el rango con un percentil en vez del máximo, y aceptar que los poquísimos valores de afuera se saturen.
• Dejar sin cuantizar las capas delicadas: a menudo, la primera y la última, que se quedan en FP16.

Calibrar: medir los rangos antes de cuantizar

Los pesos están fijos, así que su rango se mide una vez. Las activaciones cambian con cada foto. Para elegir sus escalas se calibra: se pasan por el modelo unos cientos de ejemplos reales y se anota el rango de cada capa.

Hay dos maneras de llegar a un modelo cuantizado:

• PTQ (post-training quantization, cuantización después del entrenamiento): cuantizas el modelo ya entrenado, con la calibración. Tarda de minutos a horas.
• QAT (quantization-aware training, entrenamiento que sabe que lo van a cuantizar): entrenas o haces fine-tuning simulando el redondeo en el forward, para que el modelo aprenda a tolerarlo. Da mejor calidad, pero son días de trabajo y un pipeline más que mantener.

La regla de la Ronda: primero PTQ, siempre. QAT, solo si PTQ no pasa el examen y el INT8 de verdad compra algo.

El punto cero, INT4 y FP8 están en la sección extra «Cuantizar a fondo».

La cuenta que más vas a hacer en la Ronda es una multiplicación:

memoria de los pesos = parámetros × bytes por parámetro

En un LLM es lo contrario. Un modelo de 70B (70 mil millones de parámetros) pesa 280 GB en FP32, 140 GB en FP16 o BF16, 70 GB en INT8 o FP8 (un punto flotante de 1 byte) y 35 GB en INT4. Con los 70,600 millones de Llama 3 70B, el que usa la Ronda, son ≈ 141 GB en BF16 y ≈ 70.6 GB en FP8. Una H100 tiene 80 GB: en BF16 no cabe; en FP8 caben los pesos, pero casi no queda lugar para el KV cache; en INT4 (≈ 35 GB, más ≈ 1.1 GB de escalas por grupo) sobra espacio.

Menos bytes no siempre es más velocidad, y cada cambio de formato mueve un poco las respuestas: por eso ningún modelo convertido sale sin examen (M08). Las dos cosas, con números, están en la sección extra que sigue.

1. El overflow de FP16

Un modelo que funciona en FP32 da inf o NaN en FP16: un softmax sin restar el máximo, una suma de cuadrados, una activación atípica de un transformer. Nada avisa hasta que la pérdida sale nan o las respuestas se vuelven basura.

Cómo evitarlo: para entrenar, precisión mixta con autocast (que deja en FP32 lo delicado) o BF16. Para servir, una prueba de paridad contra FP32 antes de publicar, y revisar que las salidas no traigan inf ni NaN. Un LLM entrenado en BF16 no se pasa a FP16 sin probarlo con el golden set.

2. Comparar números de punto flotante con ==

0.1 + 0.2 == 0.3 es falso, y una prueba que exige logits idénticos entre dos versiones del modelo falla siempre, o pasa por suerte.

Cómo evitarlo: comparar con tolerancia (math.isclose, torch.allclose), con una tolerancia que corresponda al formato: ≈ 0.0001 en FP32, ≈ 0.01 en FP16. Y para decidir si dos modelos «responden igual», medir el acuerdo del top-1, como la paridad de M08.

3. Olvidar que cuantizar cambia las salidas

«Es el mismo modelo, solo que en INT8.» No: cada respuesta cambia un poco, algunas cambian de categoría y la confianza de todas se mueve, y con ella cualquier umbral, como el de C01 que manda a etiquetar las fotos cuyo top-1 queda debajo de 0.3. La Ronda señala una trampa: trtexec --int8 (la herramienta de TensorRT que arma y mide engines) sin datos de calibración arma un engine que corre rápido, pero con escalas de relleno: sirve para medir la velocidad, y sus predicciones no valen nada.

Cómo evitarlo: calibrar con datos reales de producción y pasar el mismo examen que un modelo nuevo: paridad, calidad por categoría y por slice, y la ECE.

4. Confundir bits y bytes, o parámetros y bytes

INT4 son 4 bits: medio byte, no 4 bytes. Un modelo «8B» tiene 8 mil millones de parámetros: en BF16 pesa ≈ 16 GB, no 8. Y la red se mide en bits por segundo (Gb/s) y la memoria en bytes (GB): un factor de 8 que se pierde fácil.

Cómo evitarlo: escribir las unidades en cada paso de la cuenta (parámetros × bytes por parámetro = bytes) y revisar que la b chica sea bit y la B grande, byte.

5. Hacer cuentas con píxeles en uint8

Sumar, restar o promediar fotos en uint8 da la vuelta sin avisar: 250 + 10 = 4 y 10 − 20 = 246. Las fotos salen con manchas negras en lo blanco y blancas en lo negro.

Cómo evitarlo: convertir a float32 (o a int32) antes de operar, recortar a 0–255 al final y solo entonces volver a uint8. O usar funciones que se saturan, como cv2.add.

6. Mezclar dtypes sin darte cuenta

Un arreglo de NumPy nace en float64. Si lo conviertes en tensor y se lo pasas a un modelo en float32, PyTorch se queja de que los tipos no coinciden; si para callarlo conviertes todo a float64, ocupas el doble de memoria sin ganar nada. Al revés también muerde: las etiquetas de la entropía cruzada, cuando son números de categoría, tienen que ser int64.

Cómo evitarlo: revisar x.dtype en la frontera entre NumPy y PyTorch, convertir a propósito (.float(), .long()) y fijar el dtype en el contrato del servidor. En C01, la configuración de Triton dice TYPE_FP32 para la entrada y para la salida.

Resuélvelos con lápiz antes de abrir la solución. Los de rangos, cuantización y memoria se pueden comprobar con las calculadoras.

1. 1Fácil

   Escribe 77 en binario, con 8 bits. Después: ¿qué número es 1010 1010 como uint8 y como int8?

   Ver la solución paso a paso

   • 77: la posición de 64 cabe (quedan 13); 32 y 16 no; 8 cabe (quedan 5); 4 cabe (queda 1); 2 no; 1 sí. 0100 1101. Comprueba: 64 + 8 + 4 + 1 = 77.
   • 1010 1010 como uint8: 128 + 32 + 8 + 2 = 170.
   • Como int8, el primer bit vale −128: −128 + 32 + 8 + 2 = −86. Es lo mismo que 170 − 256.
2. 2Fácil

   ¿Cabe 40,000 en un int16? ¿Y en un uint16? ¿Cuánto ocupa un millón de números int16?

   Ver la solución paso a paso

   • int16 va de −32,768 a 32,767: no cabe. Si sale de una cuenta en un arreglo int16 de NumPy (por ejemplo, 20,000 + 20,000), da la vuelta: 40,000 − 65,536 = −25,536.
   • uint16 va de 0 a 65,535: sí cabe.
   • Un millón de int16: 1,000,000 × 2 bytes = 2 MB.
3. 3Fácil

   En uint8, ¿cuánto da 200 + 70? ¿Y 30 − 50? ¿Qué darían si se saturaran?

   Ver la solución paso a paso

   • 200 + 70 = 270, que no cabe: 270 − 256 = 14. Saturado: 255.
   • 30 − 50 = −20, que tampoco: −20 + 256 = 236. Saturado: 0.
   • Por eso las cuentas con píxeles se hacen en float32 o en int32, y se recorta al final.
4. 4Fácil

   El detector YOLOv8m tiene ≈ 25.9 millones de parámetros. ¿Cuánto pesan sus pesos en FP32, en FP16 y en INT8?

   Ver la solución paso a paso

   • FP32: 25.9 M × 4 B ≈ 103.6 MB.
   • FP16: 25.9 M × 2 B ≈ 51.8 MB; la Ronda (M04) dice ≈ 52 MB.
   • INT8: 25.9 M × 1 B ≈ 25.9 MB, más las escalas. Del tamaño de la ResNet-50.
5. 5Medio

   Estos 16 bits son un FP16: 0 10010 0101000000. ¿Qué número es?

   Ver la solución paso a paso

   • Signo 0: positivo.
   • Exponente: 10010₂ = 16 + 2 = 18. Menos el sesgo de FP16, que es 15: 3.
   • Mantisa: 1.0101₂ = 1 + 1/4 + 1/16 = 1.3125.
   • Valor: 1.3125 × 2³ = 1.3125 × 8 = 10.5.
6. 6Medio

   Una capa tiene pesos entre −4 y 4. Con INT8 simétrico, ¿cuál es la escala? ¿Cómo se guardan 1.0 y 0.03, cómo vuelven y qué error tiene cada uno en proporción?

   Ver la solución paso a paso

   • Escala: 4 ÷ 127 ≈ 0.0315.
   • 1.0 ÷ 0.0315 = 31.75 → 32; de vuelta, 32 × 0.0315 ≈ 1.0079: error de 0.0079, 0.8 %.
   • 0.03 ÷ 0.0315 = 0.95 → 1; de vuelta, ≈ 0.0315: error de 0.0015, 5 %.
   • El error de los dos está debajo de media escala (≈ 0.0157), pero en proporción el número chico sale mucho peor. Por eso importan las escalas por canal o por grupo.
7. 7Medio

   De la sección extra de precisión mixta: con la escala de pérdida en 65,536, un gradiente real de 3 sale escalado en el backward en FP16. ¿Qué pasa? Si el mismo gradiente se repitiera, ¿cuántos pasos se saltaría GradScaler antes de que quepa?

   Ver la solución paso a paso

   • 3 × 65,536 = 196,608, más que 65,504: inf. GradScaler salta el paso y baja la escala a 32,768.
   • 3 × 32,768 = 98,304: otra vez inf. Salta otro paso; la escala baja a 16,384.
   • 3 × 16,384 = 49,152: cabe. Se saltaron 2 pasos, y los pesos no se tocaron en ninguno.
8. 8Medio

   Llama 3 8B tiene ≈ 8.03 mil millones de parámetros. ¿Cuánto pesa en BF16? Una L4 lee 300 GB por segundo de su memoria y, para cada token nuevo, relee todos los pesos: ¿cuántos tokens por segundo da como máximo? ¿Y en INT8?

   Ver la solución paso a paso

   • BF16: 8.03 × 10⁹ × 2 B ≈ 16.06 GB.
   • Máximo: 300 ÷ 16.06 ≈ 18.7, unos 19 tokens por segundo por conversación.
   • INT8: 8.03 GB, y 300 ÷ 8.03 ≈ 37 tokens por segundo: el doble, porque se leen la mitad de bytes. Son los números de M04.
9. 9Reto

   Un LLM de 70,600 millones de parámetros va en INT4, con grupos de 128 pesos y una escala FP16 por grupo. (a) ¿Cuántos bits ocupa cada peso, contando su parte de la escala? (b) ¿Cuántos GB pesan los pesos? (c) ¿Caben en una H100 de 80 GB, si vLLM usa el 90 % de la memoria? ¿Y en BF16?

   Ver la solución paso a paso

   • (a) 4 bits + 16 bits ÷ 128 = 4 + 0.125 = 4.125 bits, es decir, 0.515625 bytes.
   • (b) 70.6 × 10⁹ × 0.515625 B ≈ 36.4 GB.
   • (c) vLLM usa 0.9 × 80 = 72 GB; quedan 72 − 36.4 ≈ 35.6 GB para el runtime y el KV cache: sí cabe, con margen. En BF16 son ≈ 141 GB: no caben en una, y en dos (144 GB útiles) apenas entran los pesos, sin lugar para el KV cache.
10. 10Reto

    Diseña el contador de fotos de C01. Al pico de diseño, 500 fotos por segundo sin parar: ¿en cuántos días da la vuelta un int32? ¿Y un uint32? ¿En cuántas horas se atora un float32 (lo explica la sección extra «Redondeo»)? ¿Qué tipo eliges?

    Ver la solución paso a paso

    • int32: 2,147,483,647 ÷ 500 ÷ 86,400 ≈ 49.7 días.
    • uint32: 4,294,967,295 ÷ 500 ÷ 86,400 ≈ 99.4 días.
    • float32: 16,777,216 ÷ 500 ≈ 33,554 segundos ≈ 9.3 horas.
    • Elijo int64: 9.2 × 10¹⁸ ÷ 500 ÷ 86,400 ÷ 365 ≈ 585 millones de años. O FP64, como Prometheus: 2⁵³ ÷ 500 ÷ 86,400 ÷ 365 ≈ 570,000 años de enteros exactos.
11. 11Reto

    La paridad del engine FP16 de C01 da 99.2 % de acuerdo en el top-1, con 10,000 fotos, y el examen pide al menos 99.5 %. ¿Cuántas fotos cambiaron? ¿Pasa? ¿Qué revisas, y en qué orden?

    Ver la solución paso a paso

    • Cambiaron 0.8 % de 10,000 = 80 fotos. El examen permite 50: no pasa.
    • FP16 en una CNN suele pasar el 99.5 % con holgura, así que sospecha de un bug, no del formato. Primero, el ONNX en FP32 con ONNX Runtime (un programa que corre archivos ONNX, sin TensorRT): si ahí ya falla, el problema está en el export (preprocesamiento distinto, una capa mal convertida, el orden de las categorías).
    • Si el ONNX pasa y el engine no, busca la capa cuyas salidas se separan comparando las intermedias, y déjala en FP32: puede ser un overflow de FP16. Revisa también si la diferencia máxima de logits es ≈ 0.01 o mucho más.
    • Lo que nunca se hace: bajar el umbral para que pase.

En la Ronda:

• M01 · El mapa y la entrevista trae la primera tabla de bytes y avisa que el batch, la precisión (FP16 o INT8) y el ajuste automático del número de máquinas mueven la factura más que la arquitectura del modelo.
• M04 · Hardware para inferencia arranca con «parámetros × bytes por parámetro» y su tabla de dtypes, con la GPU que soporta cada uno, explica por qué BF16 le ganó a FP16 en los LLMs y suma las activaciones y el KV cache a la memoria de la GPU.
• M08 · Optimización de modelos cuantiza la ResNet-50 de C01 (98 MB → 25.1 MB), explica la escala por canal, el punto cero, la calibración, PTQ y QAT, y arma el examen: paridad, slices y latencia.
• M14 · Sistemas con LLMs elige el formato de un LLM en producción: BF16, FP8, INT8 o INT4 weight-only (AWQ, GPTQ), y el KV cache en FP8.
• Los casos. C01 (engine FP16, entrada en uint8 como mejora, INT8 en CPU por medir), C10 (70B en FP8 sobre 2 H100) y C02 (FP16 en el edge, INT8 calibrado con frames de día y de noche).

En el Dojo: la estación 5, «Export, engine y paridad», es esta lección hecha código: exportar la ResNet-50 a ONNX en FP32, construir el engine FP16 y correr la prueba de paridad. Cuando abra, ahí la vas a practicar. La estación 7, «Empaquetado», ya usa la cuenta de los pesos en FP16 para decidir que el modelo puede ir dentro de la imagen de Docker.

En Sensei: la siguiente lección, «Matrices, FLOPs y qué tan rápido calcula una GPU», usa los bytes de esta lección para saber si un modelo está limitado por las cuentas o por la memoria. Después, «Memoria, caché y disco» y «CPU y GPU» abren la máquina donde viven estos bytes, y «PyTorch en lo que toca a producción» vuelve a los dtypes, a autocast y a la paridad con código de verdad.

Estos son los conceptos que presentó esta lección. Cada uno tiene su tarjeta con la definición completa.

Intenta responder en tu cabeza antes de abrir cada respuesta.

1. 1¿Por qué un uint8 llega hasta 255 y un int8 solo hasta 127?Ver respuesta

   Con 8 bits hay 2⁸ = 256 combinaciones. Sin signo van del 0 al 255. Con signo, el primer bit vale −128, y quedan de −128 a 127.

2. 2¿Qué da 250 + 10 en un arreglo uint8 de NumPy, y por qué?Ver respuesta

   1. El resultado, 260, no cabe en 8 bits: se pierde el noveno bit y queda 260 − 256 = 4. NumPy da la vuelta sin avisar.
3. 3Si FP16 y BF16 ocupan 2 bytes, ¿en qué se diferencian?Ver respuesta

   FP16 tiene 5 bits de exponente y 10 de mantisa: ≈ 3 cifras, pero su máximo es 65,504. BF16 tiene 8 y 7: el rango de FP32 con 2 o 3 cifras. BF16 prácticamente no se desborda donde FP32 no lo haría, y por eso es el formato de los LLMs.

4. 4¿Por qué 0.1 + 0.2 no da exactamente 0.3 en Python?Ver respuesta

   Porque 0.1 y 0.2 no tienen una escritura finita en binario: se guardan redondeados y los errores se suman. Python usa FP64 y da 0.30000000000000004. Los números de punto flotante se comparan con tolerancia, no con ==.

5. 5En la precisión mixta, ¿para qué sirven la copia maestra en FP32 y la escala de la pérdida?Ver respuesta

   La copia maestra evita que los cambios chicos se pierdan (en FP16, 1 + 0.0001 da 1). La escala evita que los gradientes diminutos se vuelvan 0: se multiplica la pérdida por 65,536 y los gradientes se dividen antes de actualizar.

6. 6Una capa tiene pesos de −2.5 a 2.5. ¿Cómo se guarda 0.1 en INT8, y qué pasa si aparece un peso de 25?Ver respuesta

   Con escala 2.5 ÷ 127 ≈ 0.0197, el 0.1 se guarda como 5 y vuelve como 0.0984. Con un 25, la escala sube a ≈ 0.197: el 0.1 se guarda como 1 y vuelve como 0.197, con 97 % de error. Por eso hay escalas por canal o por grupo.

7. 7¿Cuánto pesan los pesos de un modelo de 70B en FP16, en INT8 y en INT4? ¿Cabe en una H100 de 80 GB?Ver respuesta

   140 GB, 70 GB y 35 GB. En FP16 no cabe; en INT8 o FP8 caben los pesos, pero casi no queda lugar para el KV cache; en INT4 sobra espacio.