Números grandes, unidades y estimaciones

En las lecciones anteriores ya aparecieron números así: la ResNet-50 de C01 tiene 24,532,532 parámetros, la foto entra como 150,528 números, el modelo hace unos 4,100,000,000 de multiplicaciones por foto y C01 recibe 10,000,000 de fotos al día. También hay números diminutos: copiar la foto a la GPU tarda 0.00004 segundos. Contar ceros es lento, y un cero de menos es un error de 10 veces.

Una cifra por una potencia de diez

La notación científica (scientific notation) escribe cada número como una cifra entre 1 y 10 multiplicada por una potencia de diez:

• 10³ = 1,000 (un 1 con tres ceros), 10⁶ = 1,000,000 y 10⁹ = 1,000,000,000.
• 86,400 = 8.64 × 10⁴: el punto decimal se movió 4 lugares a la izquierda.
• 0.00004 = 4 × 10⁻⁵: el exponente negativo quiere decir que el punto se movió a la derecha. 10⁻⁵ es 1 ÷ 10⁵.

La cifra de adelante se llama mantisa, y el número chiquito arriba del 10, exponente. El exponente dice el tamaño; la mantisa, el detalle.

La ventaja aparece al hacer cuentas. Para multiplicar, se multiplican las mantisas y se suman los exponentes; para dividir, se dividen las mantisas y se restan.

Python y las hojas de cálculo escriben la notación científica con una e: 8.64e+04 quiere decir 8.64 × 10⁴ y 4e-05, 4 × 10⁻⁵. Para escribir números largos en el código, Python acepta guiones bajos como separadores de miles: 10_000_000.

dia = 24 * 60 * 60                  # segundos en un día
print(dia, f"{dia:.2e}")            # la e quiere decir «× 10 a la»
print(10_000_000 / dia)             # 10 millones de fotos al día, por segundo
print(f"{24_532_532:.2e}", f"{0.00004:.0e}")
print(1e7 * 300 / 1e9, "GB de logs al día")

86400 8.64e+04
115.74074074074075
2.45e+07 4e-05
3.0 GB de logs al día

Órdenes de magnitud

El orden de magnitud (order of magnitude) de un número es la potencia de diez más cercana: 86,400 es «del orden de 10⁵». Dos cosas que difieren en un orden de magnitud están a unas 10 veces una de otra; en tres órdenes, a unas mil veces.

Para redondear se mira la mantisa: si es menor que √10 ≈ 3.16, el orden es su potencia; si es mayor, la siguiente. Así, 2.45 × 10⁷ es del orden de 10⁷ y 8.64 × 10⁴, del orden de 10⁵. El corte va en 3.16 y no en 5 porque, en una escala que avanza multiplicando por 10, 3.16 queda justo a la mitad: 1 × 3.16 ≈ 3.16 y 3.16 × 3.16 ≈ 10.

Hay otra costumbre: llamar orden de magnitud solo al exponente, sin redondear. Con ella, 86,400 es del orden de 10⁴. Las dos se usan; en esta lección, la potencia más cercana.

¿Por qué importa? Porque en un diseño las decisiones cambian por órdenes de magnitud. La Ronda lo dice así: si te equivocas por 2 veces y la decisión no cambia, no importa; si te equivocas por 10, pasas de «un par de máquinas» a «un cluster». Una estimación de servilleta no busca decimales: busca atinarle al orden de magnitud.

Los prefijos: kilo, mega, giga

Para no escribir la potencia cada vez, el Sistema Internacional de unidades (SI) le pone nombre a cada salto de mil:

(El SI escribe el kilo con k minúscula; en computación casi siempre vas a ver KB, y así lo escribe la Ronda.) En ML vas a ver además letras sueltas: «25.6 M parámetros» (la ResNet-50 original, la de 1,000 categorías) son 25.6 millones, «5k fotos» son 5 mil y un LLM «de 8B» tiene 8 billion: 8 mil millones.

El tiempo: de nanosegundos a días

El tiempo se mide en segundos, y casi todo lo interesante de una computadora pasa en pedacitos de segundo. Los tres que vas a usar siempre:

• Milisegundo (milisegundo (ms)): una milésima de segundo, 10⁻³ s. Es la unidad de la red y de los modelos: la promesa de C01 es que el p99 quede bajo 200 ms, es decir, que 99 de cada 100 requests tarden 200 ms o menos.
• Microsegundo (µs): una millonésima, 10⁻⁶ s. La µ es la letra griega «mu»; cuando no se puede escribir, se pone us. Es la escala de copiar datos y de leer un disco rápido.
• Nanosegundo (ns): una milmillonésima, 10⁻⁹ s. Es la escala de lo que pasa dentro del chip.

Cada uno es mil veces el siguiente: 1 s = 1,000 ms = 1,000,000 µs = 10⁹ ns. Para convertir, cuenta cuántos saltos de mil das: 200 ms = 0.2 s; 40 µs = 0.04 ms; 100 ns = 0.1 µs.

La regla muestra lo que los números sueltos esconden: cosas que «son rápidas» pueden estar a miles de veces una de otra. Leer la RAM, la memoria de trabajo de la computadora (≈ 100 ns), contra la promesa de C01 (200 ms) es 0.2 ÷ 10⁻⁷ = 2 × 10⁶: dos millones de veces. Por eso, cuando un servicio tarda, rara vez es por una suma de más en el código: suele ser la espera por la red, el disco o la GPU, que viven varias marcas más abajo.

Los números del reloj

Para los números grandes de tiempo, la Ronda usa siempre los mismos:

¿Por qué dos meses? Las nubes dan el precio de sus máquinas por hora, y un mes promedio del año tiene 8,760 ÷ 12 = 730 horas: costo al mes = precio por hora × 730. Las promesas de disponibilidad (qué parte del tiempo funciona bien el servicio), en cambio, suelen contarse en ventanas de 30 días, 43,200 minutos, para que todas las ventanas valgan igual; así las cuenta la Ronda. Entre 730 h y 720 h hay 1.4 %: no cambia ninguna decisión, pero en una misma cuenta se usa uno solo.

Un bit y un byte

Una computadora guarda todo como interruptores prendidos o apagados (en la práctica son cargas eléctricas o puntos magnetizados, pero cada uno vale solo 0 o 1). Cada uno es un bit (binary digit): un 0 o un 1. Con un bit hay 2 posibilidades; con dos, 4 (00, 01, 10 y 11); con n bits, 2ⁿ. Ocho bits forman un byte, y en ellos caben 2⁸ = 256 valores: del 0 al 255.

¿Te suena «del 0 al 255»? Es justo lo que guarda un canal de un píxel en uint8: un byte. Un número en float32 ocupa 4 bytes, 32 bits. Cómo se escriben los números con ceros y unos (el sistema binario) lo verás en «Cómo guarda números una computadora»; aquí basta con contar.

b minúscula es bit y B mayúscula es byte. 1 Mb (megabit) es 8 veces más chico que 1 MB (megabyte). Y aquí vive la trampa más común de todas: las velocidades de red se anuncian en bits por segundo, y los archivos se miden en bytes.

• Un plan de internet de «100 megas» es de 100 Mb/s: 100 ÷ 8 = 12.5 MB por segundo. Un archivo de 1 GB tarda ≈ 80 s, no 10.
• 1 Gb/s (un gigabit por segundo) son 125 MB/s, y 1 GB/s son 8 Gb/s.

Lo que un canal puede mover por segundo es su ancho de banda; tiene su propia sección más abajo.

Del byte al petabyte

Con los bytes pasa lo mismo que con el tiempo: lo que maneja un sistema de ML ocupa 15 órdenes de magnitud.

Del log de una predicción (≈ 300 B) a un año de logs de C01 (1.1 TB) hay casi diez marcas: ≈ 3.65 × 10⁹ veces, que son justo las predicciones de un año. Un atajo de la Ronda para estas cuentas: 1 millón de cosas de 1 KB son 1 GB, porque 10⁶ × 10³ = 10⁹. Con él, 10 M logs de 300 B son 10 × 0.3 = 3 GB sin hacer la cuenta larga.

KB contra KiB: los dos kilos

Con la memoria pasó algo raro. Las computadoras cuentan en potencias de 2, y 2¹⁰ = 1,024 se parece mucho a mil. Así que, durante décadas, «un kilobyte» quiso decir 1,000 bytes o 1,024 según quién hablara. Con los kilos la diferencia era de 2.4 %; con los gigas y los teras ya no es poca cosa.

En diciembre de 1998, la Comisión Electrotécnica Internacional (IEC), que fija estándares eléctricos y electrónicos, separó los nombres. Los prefijos binarios llevan una i: kibi (KiB), mebi (MiB), gibi (GiB), tebi (TiB) y pebi (PiB).

¿Quién usa cuál?

• Decimal: los fabricantes de discos, las velocidades de red y macOS (desde 2009).
• Binario: la RAM (un módulo «de 16 GB» trae 16 GiB), AWS al describir la memoria de sus máquinas (una g4dn.xlarge, la máquina con una T4 que usa C01, trae 16 GiB), Windows (que escribe «GB» pero divide entre 2³⁰), df -h en Linux, nvidia-smi y PyTorch.

El mismo trabajo, en Python. Fíjate en que 2**30 y 10**9 son exactos: así no hay redondeos escondidos.

# Las dos maneras de contar bytes, y los bits
KB, MB, GB, TB = 10**3, 10**6, 10**9, 10**12      # decimales (SI)
KiB, MiB, GiB, TiB = 2**10, 2**20, 2**30, 2**40   # binarios (IEC)

disco = 1 * TB
print(f"1 TB = {disco:,} bytes = {disco / GiB:.1f} GiB = {disco / TiB:.3f} TiB")

tensor = 3 * 224 * 224 * 4          # la foto de C01 en float32
print(f"tensor: {tensor:,} B = {tensor / KB:.0f} KB = {tensor / KiB:.0f} KiB")
print(f"        {tensor * 8:,} bits")

for nombre, dec, bina in [("kilo", KB, KiB), ("mega", MB, MiB),
                          ("giga", GB, GiB), ("tera", TB, TiB)]:
    print(f"{nombre}: el binario es {100 * (bina / dec - 1):.1f} % más grande")

1 TB = 1,000,000,000,000 bytes = 931.3 GiB = 0.909 TiB
tensor: 602,112 B = 602 KB = 588 KiB
        4,816,896 bits
kilo: el binario es 2.4 % más grande
mega: el binario es 4.9 % más grande
giga: el binario es 7.4 % más grande
tera: el binario es 10.0 % más grande

Los negocios hablan por día («recibimos 10 millones de fotos al día»); las máquinas trabajan por segundo. Esta sección es el puente.

Throughput y QPS

El throughput es cuánto trabajo termina un sistema por unidad de tiempo: requests por segundo, fotos por segundo, tokens por segundo. No es lo mismo que la latencia, que es cuánto tarda una request: un servicio puede atender 500 por segundo aunque cada una tarde 50 ms, porque atiende muchas a la vez.

Para un servicio que responde requests, el throughput se dice en req/s o QPS (queries per second, consultas por segundo; el nombre viene de los buscadores). La cuenta base es una división:

req/s de promedio = eventos al día ÷ 86,400

Un número para memorizar: 1 millón al día ≈ 11.6 por segundo (10⁶ ÷ 86,400 = 11.57). Con él, 10 M al día son ≈ 116 por segundo y 100 M, ≈ 1,157. «Un millón al día» suena a muchísimo; «doce por segundo», a poco. Las dos frases dicen lo mismo.

El promedio esconde el pico

Nadie sube fotos a las 4 de la mañana como a las 8 de la noche. Si C01 recibiera sus 10 millones parejos, llegarían 116 por segundo a toda hora. No es así:

El factor de pico (peak factor) es el pico dividido entre el promedio: cuántas veces el promedio llega en el momento de más tráfico. Hay una forma sencilla de estimarlo: si la hora pico lleva una fracción f del tráfico del día, el factor es 24 × f. Con 1/8 (12.5 %), 24 × 1/8 = 3. Con 10 %, 2.4; con 20 %, 4.8. En apps que usan personas en una sola zona horaria suele estar entre 2 y 5; en un proceso automático que trabaja parejo día y noche, cerca de 1.

Al pico se le agrega un margen de diseño (de 1.3 a 1.5 veces) para lo que no sabes: picos de unos minutos, crecimiento del negocio, el error de tu propia estimación. El resultado se redondea hacia arriba a un número fácil de decir. Ese es el pico de diseño, para el que se compran las máquinas.

Con el pico de diseño ya se pueden contar máquinas. Hacen falta dos números más.

Capacidad medida y utilización objetivo

La capacidad de una máquina es cuántas requests por segundo aguanta cumpliendo la promesa de latencia. No se adivina: se mide con una prueba de carga (load test), mandándole cada vez más tráfico hasta que la latencia se pasa del límite. Para una T4 que sirve la ResNet-50 de C01 ya optimizada, la Ronda usa ≈ 1,200 fotos por segundo. En una entrevista es una estimación; en el trabajo, es lo primero que se mide.

Además, no se planea al 100 %. Cerca del límite, las requests empiezan a esperar en cola y la latencia se dispara; y si llega un pico, hace falta aire mientras se encienden más máquinas. Por eso se fija una utilización objetivo de ≈ 50 a 70 %. C01 planea al 50 %: cada T4 cuenta por 1,200 × 0.5 = 600 fotos por segundo.

Siempre hacia arriba, y una de repuesto

máquinas = ⌈pico de diseño ÷ (capacidad medida × utilización)⌉ + repuesto

Los corchetes ⌈ ⌉ quieren decir redondear hacia arriba: ⌈0.83⌉ = 1 y ⌈2.1⌉ = 3. Media máquina no existe, y la fracción que falta es tráfico sin atender. El repuesto es N+1: si necesitas N máquinas, pones una más, en otra zona de disponibilidad (otro centro de datos de la misma región, a algunos kilómetros del primero), para que la caída de una no se note. Es la forma más simple de redundancia.

Ojo con las tres formas de redondear de Python:

import math

pico, por_maquina = 500, 1200 * 0.5      # req/s de diseño y capacidad planeada
x = pico / por_maquina
print(x, math.floor(x), round(x), math.ceil(x))

pico = 1250                              # con más tráfico
x = pico / por_maquina
print(x, math.floor(x), round(x), math.ceil(x))
print(round(2.5), round(3.5))            # ¡ojo!: round va al par más cercano

0.8333333333333334 0 1 1
2.0833333333333335 2 2 3
2 4

floor (hacia abajo) daría cero máquinas para C01. round (al más cercano) acierta con 0.83, pero con 2.08 pide 2 cuando hacen falta 3, y con 2.5 da 2, porque Python redondea los empates al número par. Para capacidad, solo math.ceil.

El costo al mes

Las nubes dan el precio de las máquinas por hora (aunque muchas cobran por segundo), así que el costo de tenerlas encendidas todo el mes es máquinas × precio por hora × 730.

Los precios de la nube cambian y dependen de la región: dalos como orden de magnitud y di que los verificas.

Ya tienes todas las piezas. En una entrevista de diseño, el paso 3 de la Ronda son estas cuentas: cinco minutos, números redondos y una decisión por número. Esta es la de C01.

1. 1

   Escribe lo que te dan y lo que supones

   ≈ 2.5 M publicaciones × ≈ 3 fotos, más lo que piden otros equipos: ≈ 10 M fotos al día, una por request. Dilo en voz alta: es un supuesto.

2. 2

   Pásalo a por segundo

   10,000,000 ÷ 86,400 ≈ 116 req/s de promedio.

3. 3

   Del promedio al pico y al diseño

   × 3 por la hora pico ≈ 350 req/s; × ≈ 1.4 y hacia arriba: 500 req/s.

4. 4

   Cuenta las máquinas

   ⌈500 ÷ (1,200 × 0.5)⌉ + 1 = 2 T4.

5. 5

   Revisa que el modelo quepa

   24.5 M parámetros × 2 bytes en float16 ≈ 49 MB, en una GPU de 16 GB: sobra.

6. 6

   Ponle precio

   2 × US$0.526 la hora × 730 h ≈ US$768 al mes de GPUs.

7. 7

   Cuenta lo que se queda guardado

   300 B de log × 10 M = 3 GB al día, ≈ 1.1 TB al año. Las fotos serían 10 M × 200 KB = 2 TB al día: por eso se guarda solo una referencia a cada una.

La misma servilleta en Python, con los números de la Ronda:

import math

# La servilleta de C01, con los números de la Ronda
fotos_dia = 10_000_000               # ≈ 2.5 M publicaciones × 3 fotos + otros equipos
promedio  = fotos_dia / 86_400       # req/s
pico      = promedio * 3             # la hora pico lleva 1/8 del día
diseno    = 500                      # pico × ≈ 1.4, redondeado hacia arriba
por_gpu   = 1_200 * 0.5              # medido × utilización objetivo
gpus      = math.ceil(diseno / por_gpu) + 1     # N+1
costo_mes = gpus * 0.526 * 730       # US$ por hora × horas del mes
pesos     = 24_532_532 * 2           # bytes en float16
logs_dia  = fotos_dia * 300          # bytes: ≈ 300 B por predicción

print(f"promedio {promedio:.0f} req/s · pico {pico:.0f} · diseño {diseno}")
print(f"GPUs: ⌈{diseno} ÷ {por_gpu:.0f}⌉ + 1 = {gpus}")
print(f"pesos: {pesos / 1e6:.0f} MB en una T4 de 16 GB")
print(f"costo de las GPUs: US${costo_mes:,.0f} al mes")
print(f"logs: {logs_dia / 1e9:.0f} GB al día, {logs_dia * 365 / 1e12:.1f} TB al año")
print(f"carga promedio de cada GPU: {promedio / gpus / 1_200:.0%} de su máximo")

promedio 116 req/s · pico 347 · diseño 500
GPUs: ⌈500 ÷ 600⌉ + 1 = 2
pesos: 49 MB en una T4 de 16 GB
costo de las GPUs: US$768 al mes
logs: 3 GB al día, 1.1 TB al año
carga promedio de cada GPU: 5% de su máximo

Tres costumbres de una buena servilleta

1. Números redondos. «115.74 req/s» no da puntos: da la impresión de que no sabes qué importa. 116 basta, y 500 para diseñar.
2. Un chequeo de cordura. Compara cada resultado con algo que conoces. ¿Una T4 para 500 fotos por segundo? Cada foto son ≈ 4.1 GMACs, ≈ 8.2 mil millones de operaciones; 500 por segundo son ≈ 4.1 × 10¹² por segundo, muy por debajo de los ≈ 65 TFLOPS de una T4. Cabe. Si la cuenta hubiera dicho 500 GPUs, algo estaría mal.
3. El número y la decisión. No «500 req/s», sino «≈ 500 req/s de pico: una T4 cubre el tráfico y pongo dos por disponibilidad; no necesito un cluster grande ni colas». El número solo es aritmética; con la decisión, es diseño.

Lo que depende del hardware (las 1,200 fotos por segundo) o del negocio (el factor de 3) se marca como «a medir», y se mide antes de producción con una prueba de carga. Y si te preguntan «¿y con 10 veces más tráfico?», rehaces la cuenta en voz alta: 5,000 req/s son ⌈5,000 ÷ 600⌉ = 9 GPUs, 10 con repuesto, y ahora sí vale la pena optimizar el modelo o probar otra GPU.

Las trampas que más se repiten, y cómo evitarlas.

1. Mezclar bits y bytes

«El internet es de 1 giga, así que un archivo de 10 GB baja en 10 segundos.» Son 80: el internet se mide en gigabits y el archivo en gigabytes. En un diseño pasa lo mismo al revés: 301 MB/s de tensores parecen poco hasta que los escribes como 2.4 Gb/s y los comparas con los ≈ 1.56 Gb/s que sostiene la máquina.

Cómo evitarlo: escribe siempre la b o la B, y antes de dividir pasa todo a la misma unidad. De bytes a bits, × 8.

2. Confundir KB con KiB

El disco «al que le faltan 69 GB» es el caso inofensivo. El caro es sumar los MiB de nvidia-smi con los MB de tus cuentas, o comprar memoria «justa» con una regla y llenarla con la otra: en giga hay 7.4 % de diferencia; en tera, 10 %.

Cómo evitarlo: anota qué regla usa cada fuente y no mezcles dos en una cuenta; como dice la Ronda en M04, usa el total que reporta tu GPU. Si el margen es chico, haz la cuenta en bytes.

3. Diseñar para el promedio

Con el promedio todo cabe. En C01, el gateway a 116 req/s ocupa ≈ 0.7 vCPU (116 × ≈ 6 ms; un vCPU es la unidad de CPU que renta la nube); si le das uno «porque sobra», a las 8 de la noche llegan 350 req/s, que piden ≈ 2.1, y la latencia explota.

Cómo evitarlo: promedio, pico y pico de diseño, siempre los tres. Y pregunta por los eventos (un Buen Fin, una campaña), además del pico de cada día.

4. Redondear las máquinas hacia abajo

⌊0.83⌋ = 0 máquinas, y round(2.08) = 2 cuando hacen falta 3. Peor: round(2.5) en Python da 2.

Cómo evitarlo: máquinas, discos y cualquier capacidad, siempre math.ceil. El repuesto se suma después, aparte.

5. Confundir por ciento con puntos porcentuales

«La accuracy subió 2 %», cuando pasó de 85 % a 87 %: subió 2 puntos, que son 2.4 %. O «la tasa de error subió apenas 0.1 %», cuando pasó de 0.1 % a 0.2 %: se duplicó.

Cómo evitarlo: di los dos, «+2 puntos, de 85 % a 87 %». Con tasas chicas, di también las veces: «el doble de errores».

6. Mezclar escalas

Dividir entre 10⁵ en el número final (13.6 % menos tráfico), multiplicar un precio por hora × 720 en una cuenta y × 730 en otra, comparar algo por día con algo por segundo, o leer el «8B» de un LLM como 8 billones, cuando son 8 mil millones.

Cómo evitarlo: escribe la unidad junto a cada número y, al final, revisa que se cancelen: fotos/día ÷ s/día = fotos/s. Para las palabras, potencias de diez: 8 × 10⁹.

Resuélvelos con lápiz antes de abrir la solución; las calculadoras de la lección sirven para comprobar.

1. 1Fácil

   Escribe en notación científica y di el orden de magnitud de cada número: (a) 2,500,000 publicaciones al día; (b) 602,112 bytes; (c) 0.0000001 segundos.

   Ver la solución paso a paso

   • (a) 2.5 × 10⁶. La mantisa, 2.5, es menor que 3.16: orden 10⁶.
   • (b) ≈ 6.02 × 10⁵. Como 6.02 > 3.16, el orden es 10⁶: casi un megabyte.
   • (c) 1 × 10⁻⁷ s = 100 ns: orden 10⁻⁷, lo que tarda leer la RAM.
2. 2Fácil

   Un servicio recibe 5 millones de requests al día. ¿Cuántas llegan por segundo en promedio? ¿Y con el atajo de 10⁵ s?

   Ver la solución paso a paso

   • 5,000,000 ÷ 86,400 ≈ 57.9 req/s. Con la regla de memoria: 5 × 11.6 = 58.
   • Con el atajo: 5 × 10⁶ ÷ 10⁵ = 50 req/s, 13.6 % abajo.
3. 3Fácil

   Compras un disco de 4 TB. ¿Cuántos GiB y cuántos TiB muestra tu computadora con Windows?

   Ver la solución paso a paso

   • 4 TB = 4 × 10¹² bytes.
   • En GiB: 4 × 10¹² ÷ 2³⁰ ≈ 3,725 GiB, que Windows escribe como «3,725 GB».
   • En TiB: 4 × 10¹² ÷ 2⁴⁰ ≈ 3.64 TiB. No falta nada: es la regla de 1,024.
4. 4Fácil

   Tu internet es de 200 Mb/s. ¿Cuánto tarda, en el mejor caso, en bajar una imagen de Docker de 10 GB? ¿Cuánto dirías si confundieras bits con bytes?

   Ver la solución paso a paso

   • 10 GB × 8 = 80 Gb = 80,000 Mb.
   • 80,000 Mb ÷ 200 Mb/s = 400 s ≈ 6.7 minutos.
   • Confundiendo: 10,000 MB ÷ 200 = 50 s. Te quedarías corto por 8.
5. 5Medio

   Una app recibe 20 M fotos al día. La hora pico lleva 1/6 del tráfico y quieres un margen de 1.3. Calcula el promedio, el factor de pico, el pico y el pico de diseño.

   Ver la solución paso a paso

   • Promedio: 20,000,000 ÷ 86,400 ≈ 231 req/s.
   • Factor: 24 × 1/6 = 4.
   • Pico: 231.5 × 4 ≈ 926 req/s (con el promedio sin redondear; 231 × 4 daría 924).
   • Diseño: 926 × 1.3 ≈ 1,204, redondeado hacia arriba a la centena: 1,300 req/s.
6. 6Medio

   El pico de diseño es 1,200 req/s. Cada máquina sostiene 800 req/s medidas, planeas al 60 %, quieres N+1 y cada máquina cuesta US$0.80 la hora. ¿Cuántas máquinas pides y cuánto cuestan al mes? ¿Qué pasaría si usaras round de Python?

   Ver la solución paso a paso

   • Capacidad planeada: 800 × 0.6 = 480 req/s.
   • Por tráfico: 1,200 ÷ 480 = 2.5 → ⌈2.5⌉ = 3. Con N+1: 4 máquinas.
   • Costo: 4 × US$0.80 × 730 = US$2,336 al mes.
   • round(2.5) da 2 en Python: pedirías 3 en total. Si se cae una, las 2 que quedan suman 960 req/s planeadas, menos que 1,200: trabajarían al 75 % de su máximo medido (1,200 ÷ 1,600), muy arriba del 60 % que planeaste.
7. 7Medio

   El top-5 de un modelo sube de 96 % a 96.5 %. ¿Cuántos puntos porcentuales subió? ¿Qué cambio relativo es? ¿Cuánto bajaron los errores?

   Ver la solución paso a paso

   • Subió 0.5 puntos porcentuales.
   • Relativo: 0.5 ÷ 96 ≈ 0.52 % más.
   • Errores: de 4 % a 3.5 %, 0.5 ÷ 4 = 12.5 % menos. Tres maneras de contar el mismo cambio: di cuál usas.
8. 8Medio

   Un servicio hace 50 M predicciones al día y guarda un log de 500 B por cada una. ¿Cuánto ocupa al día y al año? Si los discos se compran en TiB, ¿cuántos TiB al año?

   Ver la solución paso a paso

   • Al día: 5 × 10⁷ × 500 B = 2.5 × 10¹⁰ B = 25 GB.
   • Al año: 25 GB × 365 = 9,125 GB ≈ 9.1 TB.
   • En TiB: 9.125 × 10¹² ÷ 2⁴⁰ ≈ 8.3 TiB. Antes de comprimir.
9. 9Reto

   Un servicio de lectura de documentos (OCR) recibe 3 M documentos al día de ≈ 2 páginas. El pico es 3× el promedio y el margen, 1.4. Una GPU procesa 50 páginas por segundo medidas; planeas al 50 % con N+1, a US$0.526 la hora. (a) ¿Páginas por segundo de promedio, pico y diseño? (b) ¿GPUs y costo al mes? (c) Si los documentos pueden esperar unas horas y entran a una cola que se procesa pareja, ¿cuántas GPUs?

   Ver la solución paso a paso

   • (a) 6 M páginas al día ÷ 86,400 ≈ 69 páginas/s; pico ≈ 208; diseño 208 × 1.4 ≈ 292 → 300.
   • (b) Capacidad planeada: 50 × 0.5 = 25 por GPU. ⌈300 ÷ 25⌉ = 12, más 1: 13 GPUs. 13 × 0.526 × 730 ≈ US$4,992 al mes.
   • (c) La cola reparte el pico en las horas tranquilas: dimensionas con el promedio y un margen, 69 × 1.3 ≈ 90 páginas/s. ⌈90 ÷ 25⌉ = 4, más 1: 5 GPUs ≈ US$1,920, ≈ 62 % menos. Y como esperar en la cola ya no rompe ninguna promesa, podrías planear más cerca del 100 %, como un trabajo batch (M03): ⌈90 ÷ 50⌉ + 1 = 3. Es la razón de los patrones asíncronos de la Ronda (M02).
10. 10Reto

    Un centro de distribución tiene 40 cámaras que mandan video 1080p a 15 fps, y su internet sube entre 20 y 50 Mb/s. (a) Sin comprimir, ¿cuántos Gb/s producen entre todas? (b) Comprimido a ≈ 4 Mb/s por cámara, ¿cuántos Mb/s y cuántos TB al día? (c) ¿Cabe ese video en el internet del sitio? ¿Qué harías?

    Ver la solución paso a paso

    • (a) Un cuadro: 1,920 × 1,080 × 3 B ≈ 6.22 MB. × 15 ≈ 93 MB/s, × 8 ≈ 0.75 Gb/s por cámara. × 40 ≈ 30 Gb/s.
    • (b) 40 × 4 Mb/s = 160 Mb/s. Al día: 160 × 10⁶ × 86,400 ÷ 8 ≈ 1.73 × 10¹² B ≈ 1.7 TB.
    • (c) No cabe: 160 Mb/s contra 20 a 50, y tampoco con un video más ligero de ≈ 1.5 Mb/s por cámara (60 Mb/s). Se analiza en el sitio, con una GPU junto a las cámaras, y a la nube solo van los eventos: la decisión de C02 en la Ronda sale de una división.

En la Ronda:

• M01 · El mapa y la entrevista. Sus «estimaciones express» son esta lección en una tabla: 86,400 s, 1 M al día ≈ 12 req/s, el pico de 2 a 5 veces, 730 h, los nueves y el ejemplo completo de C01 con la fórmula de GPUs. Y pide decir cada número con su decisión.
• M03 · Latencia y capacidad. El promedio, el pico y el pico de diseño a fondo; de dónde sale cada factor; las ráfagas dentro de un segundo; y la ley de Little, que une throughput, latencia y requests en curso: 500 req/s × 0.05 s = 25 requests a la vez.
• M04 · Hardware para inferencia. Bytes por parámetro, GB contra GiB en nvidia-smi, los GB/s de la VRAM y de PCIe y el techo de tokens por segundo de un LLM.
• M13 · Nube. Precio por hora × 730, lo que cuesta cada GB que cruza la red y cuánto pagas por máquinas que pasan casi todo el día muy por debajo de su capacidad.
• Los casos. El paso de estimaciones de cada caso son estas cuentas: C01 (tráfico, GPUs, logs, red y costo), C07 (el tamaño del índice), C13 (el ancho de banda del audio) y C10 (tokens al día y al mes).

En el Dojo: la estación 7, Empaquetado, trabaja con imágenes de Docker de varios GB: cuánto pesan comprimidas y descomprimidas, y cuánto disco piden al bajarlas. Ahí vas a usar los GB, los GiB y los Gb/s de esta lección.

En Sensei: «Promedios, medianas y percentiles» explica por qué la promesa es sobre el p99 y no sobre el promedio. «Probabilidad para sistemas que fallan» calcula cuánto vale de verdad el repuesto N+1 y de dónde salen los nueves. «Cómo guarda números una computadora» abre el binario, float32, float16 e int8. «Matrices, FLOPs y qué tan rápido calcula una GPU» convierte TFLOPS y GB/s en milisegundos. Y «Qué tan rápido y cuánto: latencia y throughput» junta todo con las colas.

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 plan de internet de 100 megas no baja 100 MB por segundo?Ver respuesta

   Son 100 megabits por segundo, y un byte tiene 8 bits: 100 ÷ 8 = 12.5 MB/s.

2. 2¿Cuántos segundos tiene un día, y cuántas requests por segundo son 1 millón al día?Ver respuesta

   86,400 segundos. 1,000,000 ÷ 86,400 ≈ 11.6 req/s.

3. 3Un disco de 1 TB aparece como 931 GB. ¿Qué pasó?Ver respuesta

   Nada se perdió: el disco trae 10¹² bytes, y Windows los divide entre 2³⁰ (un GiB) aunque escriba «GB»: 10¹² ÷ 2³⁰ ≈ 931.

4. 4¿Por qué se diseña para el pico de diseño y no para el promedio?Ver respuesta

   Porque en la hora pico llegan varias veces más requests que en promedio (3 veces en C01): con capacidad para el promedio, la latencia explotaría. El promedio paga la factura; el pico de diseño decide las máquinas.

5. 5Una cuenta dice que hacen falta 2.1 máquinas. ¿Cuántas pides con N+1?Ver respuesta

   ⌈2.1⌉ = 3 por tráfico, más 1 de repuesto: 4. Nunca hacia abajo.

6. 6La accuracy pasa de 85 % a 87 %. ¿Subió 2 %?Ver respuesta

   Subió 2 puntos porcentuales; en términos relativos, 2 ÷ 85 ≈ 2.4 %. Los errores bajaron 13 %, de 15 % a 13 %.

7. 7¿Cuánto cuesta al mes una máquina de US$0.526 la hora encendida todo el tiempo?Ver respuesta

   US$0.526 × 730 h ≈ US$384.