Glosario

La fracción de ejemplos en que el modelo acertó. Fácil de entender y fácil de engañar cuando una clase es mucho más común que otra.

Con desbalance de clases, un modelo que siempre dice la clase más común saca una accuracy alta sin servir para nada. Por eso se acompaña de la matriz de confusión, precision y recall. Con muchas clases, «accuracy» suele querer decir top-1 (top-k accuracy).

Ejemplo. De 1,000 compras, 10 son fraude. Un modelo que siempre dice «no es fraude» acierta 990: 99 % de accuracy y 0 fraudes atrapados.

La función sencilla que una neurona aplica al final de su suma. Sin ella, apilar capas no serviría de nada: todo seguiría siendo una recta.

Una capa sin activación solo multiplica y suma, y dos así juntas equivalen a una sola. La activación «dobla» la recta, y con muchas neuronas la red puede formar curvas tan complicadas como haga falta. La más usada es la ReLU; antes se usaban activaciones suaves, como la sigmoide, que aplasta el número entre 0 y 1. También se le dice «activación» al número que sale de una neurona.

Ejemplo. Sin activación, y = 3x + 1 seguida de z = 2y − 1 da z = 6x + 1: otra recta. Con una ReLU en medio, la red se dobla en el 0.

Elegir qué ejemplos etiquetar en vez de etiquetar al azar: sobre todo los que el modelo tiene más dudosos, porque son los que más le enseñan por cada etiqueta pagada.

Estrategias: incertidumbre (la confianza del primer lugar es baja, o el primero y el segundo casi empatan), desacuerdo (una persona eligió otra cosa que el modelo), diversidad (cubrir tipos distintos de fotos) y categorías nuevas. Siempre se guarda una parte al azar: es lo único que dice cuánto se equivoca el modelo en el tráfico real. Se entrena con todo lo etiquetado, pero se evalúa con el golden set y con la parte al azar, nunca con lo que eligió el active learning, que es a propósito más difícil que lo normal.

Ejemplo. C01: fotos con top-1 menor que 0.3 o con margen chico entre el primero y el segundo, desacuerdos con quien vende y 20–30 % al azar, ≈ 5,000 al mes.

El optimizador más usado por defecto: para cada perilla lleva el promedio de sus gradientes y el de su tamaño, y con eso da pasos de tamaño parecido en todas, del orden del learning rate.

Propuesto por Kingma y Ba en 2014. Guarda dos números por perilla: m, el promedio de los gradientes (como el momentum), y v, el promedio de los gradientes al cuadrado. El paso es lr × m̂ ÷ (√v̂ + ε), donde m̂ y v̂ corrigen el arranque en cero. Valores por defecto: 0.9 y 0.999 para los dos promedios y ε = 0.00000001. Si el gradiente de una perilla cambia de signo a cada rato, m se cancela y el paso se achica. AdamW es la variante con weight decay aplicado aparte.

Ejemplo. Dos perillas con gradientes 100 y 0.01, lr = 0.0003: en el primer paso las dos se mueven 0.0003. Con SGD se moverían 0.03 y 0.000003.

La segunda etapa de un LLM: seguir entrenando el modelo base con ejemplos de peticiones y buenas respuestas, para que conteste en vez de solo continuar el texto.

Es un fine-tuning con conversaciones, casi siempre escritas o revisadas por personas. La tarea es la misma de antes (adivinar el siguiente token), pero solo sobre esos ejemplos y en un formato fijo de roles (sistema, usuario, asistente) marcados con tokens especiales. Ahí aprende el formato del chat y a respetar el system prompt; casi todo lo que sabe viene del preentrenamiento.

Ejemplo. En InstructGPT (OpenAI, 2022), esta etapa usó del orden de 13 mil ejemplos: muy poco comparado con los billones de tokens del preentrenamiento.

Cuando un LLM escribe, con toda seguridad y buena redacción, algo falso o que no está respaldado por ninguna fuente.

Pasa porque el modelo aprendió a producir texto probable, no texto verificado: si no sabe un dato, el token más probable sigue siendo uno que suena bien. No es un error raro que se arregla una vez; es una propiedad de cómo funcionan. Se reduce con RAG, con instrucciones de decir «no lo sé» y se mide en un conjunto de preguntas con respuesta conocida.

Ejemplo. Preguntas por la política de devoluciones del marketplace y el modelo contesta «30 días» porque es lo común, aunque la política real diga 15.

Cuántos datos puede mover un canal por segundo: una red, un disco, el bus entre la CPU y la GPU. La red se mide en bits por segundo (Gb/s); la memoria y los discos, en bytes por segundo (GB/s).

El tiempo de mandar algo grande es su tamaño entre el ancho de banda, con las unidades parejas (× 8 entre bytes y bits). No es lo mismo que la latencia: el ancho de banda dice cuánto cabe por segundo; la latencia, cuánto tarda en llegar lo primero. El de la memoria de la GPU tiene su propia lección: ancho de banda de memoria.

Analogía. Una camioneta con 2 PB de discos que maneja 10 horas tiene un ancho de banda enorme (≈ 440 Gb/s) y una latencia pésima: el primer byte llega a las 10 horas. Se rompe en que una red manda un flujo continuo y la camioneta, todo de golpe.

Ejemplo. En el pico de diseño de C01 viajan 500 × 602 KB ≈ 301 MB/s del gateway a las GPUs: ≈ 2.4 Gb/s. Por PCIe, a ≈ 16 GB/s, copiar una foto tarda ≈ 40 µs.

Cuántos bytes por segundo puede mover la memoria de un chip hacia sus núcleos y de regreso. En una GPU se mide en GB/s: 320 en una T4, 300 en una L4 y 3,350 en una H100 SXM.

Es la velocidad de la VRAM, no su tamaño: la capacidad dice qué cabe; el ancho de banda, qué tan rápido se lee. Ojo con las unidades: GB/s son gigabytes por segundo, mientras que el ancho de banda de una red se suele dar en Gb/s, gigabits, 8 veces menos. El tiempo mínimo para leer algo es bytes ÷ ancho de banda, y en un cálculo memory-bound ese es el tiempo que manda. Las memorias HBM de las GPUs grandes dan de ≈ 1,555 GB/s (A100 de 40 GB) a 3,350 GB/s (H100 SXM); las GDDR6 de la T4 y la L4, ≈ 300.

Ejemplo. Llama 3 8B en BF16 pesa ≈ 16 GB, y para generar cada token hay que leerlo entero. A 300 GB/s (L4) son ≈ 54 ms por token, un techo de ≈ 19 tokens por segundo; a 3,350 GB/s (H100 SXM), ≈ 210.

Buscar los vecinos más cercanos sin compararse contra todos: se revisa solo una parte bien elegida de la colección. Es muchísimo más rápido, a cambio de perder de vez en cuando algún vecino verdadero.

Cuánto se pierde se mide con el recall contra la búsqueda exacta: de los 100 vecinos verdaderos, cuántos encontró el ANN. Mirar más de la colección sube el recall y baja la velocidad: es una perilla, no un defecto. Las técnicas más usadas son los grafos (HNSW) y los grupos o «estantes» (IVF).

Analogía. Una biblioteca ordenada por estantes de tema: para buscar un libro de cocina vas directo al estante de cocina y no revisas los otros. Se rompe en que un libro que quedó en el estante de al lado (un libro de nutrición con recetas) no lo vas a ver, aunque fuera el que querías.

Ejemplo. En C07 de la Ronda se pide recall@100 ≥ 0.95: de los 100 vecinos exactos, el ANN tiene que encontrar al menos 95.

La «ventanilla» de un programa: lo que otros programas le pueden pedir, cómo pedírselo y qué les va a regresar.

Quien la usa no necesita saber cómo funciona por dentro, solo qué pedir y en qué formato. Un modelo en producción casi siempre se usa a través de una API: le mandas una request con la foto y te regresa la categoría.

Analogía. La ventanilla de un banco: no ves la bóveda ni los sistemas de atrás, pero sabes qué trámites puedes pedir y qué papeles llevar.

Ejemplo. La API de C01 recibe una foto y regresa las 5 categorías más probables, cada una con su porcentaje. El marketplace no necesita saber que adentro hay una ResNet-50.

Entrenar un encoder con pares que deben quedar juntos (una foto y su título): se acercan los vectores de cada par y se alejan los de las cosas que no son pareja.

En cada batch de B pares, cada foto tiene 1 título correcto y B − 1 incorrectos: los de las otras fotos (los «negativos dentro del batch»). Se calcula una tabla de B × B cosenos, se divide entre una temperatura, se aplica un softmax por fila y la pérdida es la entropía cruzada con la diagonal como respuesta correcta. Así se entrenó CLIP, y así se entrenan muchos modelos de embeddings de texto y los modelos de dos torres de recomendación.

Analogía. Un memorama: volteas una foto y tienes que encontrar su tarjeta de texto entre muchas. Se rompe en que en el memorama las tarjetas no cambian; aquí cada error mueve las tarjetas (los vectores) para que la próxima vez la pareja quede más cerca.

Ejemplo. Con cosenos 0.80 (su título), 0.55 y 0.10, y temperatura 0.1, la foto de tenis le da 92 % a su título y su pérdida es −ln 0.92 ≈ 0.08. CLIP usó ≈ 400 millones de pares y batches de 32,768.

La posición del valor más alto de una lista, no el valor. En un clasificador, la posición del logit más alto es la respuesta top-1.

Como softmax no cambia el orden, da lo mismo sacarlo de los logits o de las probabilidades: para saber cuál gana no hace falta softmax. Si dos valores empatan exacto, las librerías suelen devolver la primera posición. En las fotos casi empatadas, un cambio diminuto en los logits mueve el argmax: por eso C01 exige que el top-1 coincida en al menos 99.5 % de las fotos al cambiar de formato. El argmax repetido k veces es el top-k.

Ejemplo. Logits 3.0, 1.0 y 0.0 de Tenis, Botas y Sandalias: el máximo es 3.0 y el argmax es la posición de Tenis.

El idioma de instrucciones que entiende una CPU. Las dos que vas a ver son x86-64 (también amd64: Intel y AMD, la mayoría de los servidores) y ARM64 (también aarch64: las Mac con Apple Silicon, los Graviton de AWS, los Jetson y los teléfonos). Un programa compilado para una no corre en la otra.

Un binario ejecutable guarda instrucciones en el idioma de una CPU: la instrucción «regresar» es el byte C3 en x86-64 y los 4 bytes C0 03 5F D6 en ARM64. El kernel revisa la cabecera antes de ejecutar y, si es de otra arquitectura, falla con «exec format error» (errno 8). El código de Python no depende de la CPU, pero el intérprete y las librerías con partes compiladas (torch, NumPy, Pillow) sí: pip baja una versión para cada una. Las imágenes de Docker tienen plataforma (linux/amd64, linux/arm64); una imagen multi-arquitectura es un índice con una por plataforma bajo el mismo tag.

Ejemplo. Si construyes la imagen del gateway en una Mac con Apple Silicon, sale linux/arm64; en los nodos de C01, que son x86-64, el contenedor muere con «exec format error». Se arregla construyendo en CI con --platform linux/amd64.

Una forma de programar en la que una tarea, cuando tiene que esperar (la red, el disco, otro servicio), suelta el turno para que avancen otras, en vez de bloquear el hilo. Así un solo hilo atiende muchas requests a la vez. En Python: async def, await y asyncio.

El código marca con await cada punto donde espera, y un event loop reparte el turno entre las corrutinas que están listas. Da concurrencia sin paralelismo: muchas cosas en curso, pero solo una ejecutándose en cada instante. No hace más rápida a ninguna request: deja que, mientras una espera, otras avancen. Sirve para el trabajo I/O-bound; uno CPU-bound dentro de una corrutina bloquea a todas. No es lo mismo que el patrón asíncrono de arquitectura (M02), en el que la API acepta el trabajo, lo pone en una cola y entrega el resultado después.

Analogía. Un mesero que atiende diez mesas: toma una orden, la deja en la cocina y, mientras se cocina, va a otra mesa. Se rompe en que al mesero lo puedes interrumpir con un grito; al event loop, no: una tarea suelta el turno solo cuando llega a un await.

Ejemplo. Tres esperas de 0.3, 0.1 y 0.2 s, una tras otra, tardan 0.6 s. Con asyncio.gather, turnándose, tardan 0.3 s: lo que tarda la más larga.

El mecanismo con el que cada token mira a los demás tokens (en un LLM, solo a los anteriores), decide cuáles le importan más y mezcla su información en esa proporción.

Para cada token se calculan tres vectores, Q, K y V. Se compara la Q del token con la K de cada token (producto punto), esas calificaciones se convierten en porcentajes con softmax, y el resultado es la suma de las V con esos porcentajes. Así, la palabra «banco» puede tomar significado de «senté» o de «dinero», según cuál esté en la frase. Se hace varias veces en paralelo (multi-cabeza) y no sabe el orden por sí sola.

Ejemplo. En «Me senté en el banco», «banco» le pone ≈ 78 % de su atención a «senté» (en el ejemplo de la lección, con números inventados).

Hacer la atención varias veces en paralelo dentro de cada bloque, cada vez con sus propias tablas de Q, K y V. Cada copia, una cabeza, puede fijarse en una relación distinta.

El vector de cada token se reparte entre las cabezas: cada una calcula su propia atención con vectores más chicos, y al final sus resultados se pegan otra vez y una tabla más los mezcla. No es lo mismo que la cabeza de una red de visión, que es su parte final.

Ejemplo. Llama 3 8B: 32 cabezas de 128 números (32 × 128 = 4,096) en cada uno de sus 32 bloques, con solo 8 juegos de K y V (GQA).

El área bajo la curva ROC: 1 es perfecto y 0.5 es lo que saca adivinar al azar. Es la probabilidad de que el modelo le dé más puntos a un «sí» que a un «no», tomados al azar.

Sirve para comparar modelos sin haber elegido umbral. No dice qué umbral usar ni cuánto vas a acertar con él. Con clases muy desbalanceadas puede verse excelente aunque casi todo lo que el modelo marca sea falsa alarma: ahí se mira la curva PR.

Ejemplo. 4 fotos de tenis y 6 que no: 24 parejas. En 21 la de tenis tiene más puntos: AUC = 21 / 24 = 0.875.

La parte de la red que «ve»: recibe la foto y la convierte en una lista de números (features) que describen lo que hay en ella. Después va la cabeza, que decide.

Es la parte grande y cara (en la ResNet-50, el 99.97 % de las multiplicaciones-sumas), y casi siempre viene preentrenada (transfer learning). La cabeza es chica y es la que sabe de la tarea: el mismo backbone sirve para clasificar, detectar o segmentar cambiando solo la cabeza. Sus features también sirven solas, como embedding.

Ejemplo. En la ResNet-50 de C01, el backbone entrega 2,048 números por foto y la cabeza los convierte en 500 logits.

La forma de calcular el gradiente de todas las perillas a la vez: se recorre el modelo de la salida hacia la entrada, repartiendo la culpa del error paso por paso.

Cada paso del modelo sabe qué tanto cambia su salida cuando cambia su entrada; backpropagation multiplica esas sensibilidades a lo largo de la cadena (es la regla de la cadena del cálculo). Usa los valores que guardó el forward pass y cuesta más o menos el doble que él. Nadie la programa a mano: en PyTorch es loss.backward().

Ejemplo. En y = w2 × ReLU(w1 × x) con x = 2, w1 = 0.5, w2 = 2 y respuesta 6: ∂L/∂y = −8, ∂L/∂w2 = −8 × 1 = −8, ∂L/∂w1 = −8 × 2 × 1 × 2 = −32.

La solución más simple con la que comparas un modelo: lo que se hace hoy, una regla sencilla o el modelo más tonto (siempre la clase más común). Si tu modelo no le gana, no sirve.

Sirve para tres cosas: saber si el modelo aprendió algo, decidir si vale la pena lo que cuesta y tener un plan B cuando el modelo falla o no contesta a tiempo. En monitoreo, «línea base» también se usa para el nivel normal de una métrica, como la tasa de baja confianza de los últimos 7 días en C01.

Ejemplo. En C09 el fraude es ≈ 0.08 % de los pagos: «aprobar todo» saca 99.92 % de accuracy y no atrapa ni un fraude. En C14, el baseline es «lo que se vendió el mismo día de la semana pasada», con WAPE ≈ 45 % en los productos que más se venden.

Un grupo de ejemplos que el modelo procesa junto. Al entrenar, la pérdida y el gradiente se calculan promediando el batch, y con eso se da un paso.

Es un punto medio: el dataset completo no cabe de una vez en la GPU, y un ejemplo solo da un gradiente demasiado ruidoso y desperdicia la GPU. En inferencia la palabra también se usa: el servidor junta varias peticiones para calcularlas juntas, pero ahí no hay gradientes.

Ejemplo. C01 entrena con batches de 64 fotos.

Una capa que acomoda los números de cada canal para que queden alrededor de 0 y con dispersión parecida a 1. Se porta distinto al entrenar y al responder.

Al entrenar usa el promedio y la desviación del batch actual y va guardando un promedio acumulado (running stats). Al responder, en modo eval, usa esos valores acumulados. Si el modelo se queda en modo entrenamiento en producción, la respuesta de una foto depende de las otras fotos de su batch. Cada bloque de la ResNet lleva varias.

Ejemplo. Un canal da 2, 4, 6 y 8 en un batch: promedio 5, desviación ≈ 2.24. La foto que dio 4 queda en ≈ −0.45. Con las estadísticas acumuladas da eso siempre; con las de otro batch, otra cosa.

Un número de punto flotante de 16 bits con los mismos 8 bits de exponente que FP32 y solo 7 de mantisa: el rango de FP32 con ≈ 2 o 3 cifras. Es el formato normal de los LLMs.

Se inventó en Google Brain. Un BF16 son los primeros 16 bits de un FP32, así que convertir es redondear y tirar la otra mitad. Se equivoca más que FP16 en cada número, pero prácticamente no se desborda donde FP32 no lo haría, y las redes toleran bien la imprecisión pero no el overflow: por eso los LLMs se entrenan y se sirven en BF16, y con él la precisión mixta no necesita escala de la pérdida. Existe en las GPUs desde Ampere (A100, A10G) en adelante; la T4 no lo tiene.

Ejemplo. Llama 3 70B pesa ≈ 141 GB en BF16. En BF16, 1000.3 se guarda como 1000 y 70,000 como 70,144, sin volverse infinito; en FP16 serían 1000.5 e infinito.

Los mismos tres números de color que RGB, pero en orden inverso: azul, verde y rojo. Es como entrega los píxeles OpenCV.

Los bytes son iguales; lo que cambia es qué canal es cuál. Si un modelo aprendió con RGB (Pillow, PyTorch) y le llega BGR, lee el azul como rojo y el rojo como azul, sin ningún error. Se evita convirtiendo explícitamente en un solo lugar, justo después de leer, y con una prueba de paridad. Es una de las causas más clásicas de training-serving skew.

Ejemplo. El naranja (236, 106, 63) leído con OpenCV llega como (63, 106, 236): para el modelo, un azul. Su canal R normalizado pasa de 1.92 a −1.04.

La forma de escribir números con solo dos dígitos, 0 y 1, donde cada posición vale el doble que la de su derecha: 1, 2, 4, 8, 16… Es como cuenta una computadora, porque cada bit solo tiene dos estados.

En decimal, cada posición vale 10 veces la de su derecha; en binario, 2 veces. Con n bits hay 2ⁿ combinaciones: 256 con 8 bits, un byte. Para escribir un número en binario se recorren las posiciones de la más grande a la más chica y se pone un 1 donde su valor cabe en lo que queda. Después del punto, las posiciones valen 1/2, 1/4, 1/8…: por eso algunos decimales, como 0.1, no tienen una escritura finita en binario. Agrupando los bits de 4 en 4 sale el hexadecimal (0xFF = 255).

Analogía. Un tablero de focos donde cada foco vale el doble que el de su derecha: 128, 64, 32, 16, 8, 4, 2 y 1. El número es la suma de los focos prendidos. Se rompe con los negativos: en un int8, el primer foco no suma 128, resta 128.

Ejemplo. 236 = 1110 1100, porque 128 + 64 + 32 + 8 + 4 = 236. Es el rojo del naranja de los tenis de la lección de imágenes.

Un archivo con instrucciones de máquina, las órdenes simples que entiende la CPU, ya traducidas y listas para arrancar directo. Sirve para un solo tipo de CPU (x86-64 o arm64) y un solo sistema operativo.

Sale de compilar código fuente (C, C++, Go, Rust). Se le dice binario porque no es texto para personas, sino los bits que lee la CPU. Un binario de Linux para x86-64 no corre, sin un emulador, en arm64 (una Mac con chip M, un Graviton de AWS) ni en otro sistema operativo; en un contenedor, ese error se ve como exec format error. El propio intérprete de Python es un binario, python, compilado desde C.

Ejemplo. tritonserver es el binario de Triton, compilado desde C++. Cuando corre Triton, el proceso que aparece en ps es ese binario.

La unidad más chica de información: un 0 o un 1. Se escribe con b minúscula.

Con n bits caben 2ⁿ combinaciones: con 8, 256. Ocho bits forman un byte. Las velocidades de red se miden en bits por segundo (Mb/s, Gb/s), mientras que los archivos y las memorias se miden en bytes: confundirlos cambia la cuenta por 8. Cómo se escriben los números con bits es el sistema binario.

Ejemplo. Un plan de internet de 100 megas son 100 Mb/s: 12.5 MB por segundo. Un archivo de 1 GB tarda ≈ 80 s en bajar, no 10.

Cuando un programa, o uno de sus hilos, se queda detenido esperando algo (bytes de la red, el disco, la respuesta de otro servicio) y no puede hacer nada más mientras tanto. Una llamada bloqueante no regresa hasta que lo que pidió llegó.

Bloquear no gasta CPU: el sistema operativo duerme al hilo y le presta el núcleo a otro. Lo que gasta es el hilo. Un servidor con un solo hilo que bloquea atiende de una en una y da, como máximo, 1 ÷ latencia requests por segundo. Las salidas son más hilos, async (programación asíncrona) (un hilo que se turna en los puntos de espera) o más procesos. Dentro de una corrutina, una llamada bloqueante (time.sleep, requests.get, decodificar un JPEG) es peor: detiene al event loop y, con él, a todas las requests del proceso.

Ejemplo. Un proceso que bloquea, con 50 ms por request, da 1 ÷ 0.05 = 20 requests por segundo. Un pod de C01 recibe 100 en el pico de diseño: necesita tener ≈ 5 en curso a la vez.

La fórmula clásica para ordenar documentos por las palabras de la búsqueda: premia las palabras que coinciden, más si son raras, sin premiar de más la repetición ni los textos largos.

Funciona sobre un índice invertido: para cada palabra, la lista de documentos que la contienen. El peso de una palabra (su IDF) crece mientras más rara es: en 1,000,000 de documentos, una palabra que está en 500 pesa ≈ ln 2,000 ≈ 7.6 y una que está en 100,000, ≈ ln 10 ≈ 2.3. Repetir una palabra se satura: con k1 = 1.2, diez repeticiones valen menos del doble que una. Es la búsqueda por defecto de Lucene, Elasticsearch y OpenSearch. Es muy buena con marcas, modelos, tallas y códigos, y mala con sinónimos y descripciones vagas; por eso se combina con embeddings en la búsqueda híbrida.

Ejemplo. En C07 de la Ronda, BM25 en OpenSearch es la búsqueda de hoy: falla con «chamarra» contra «chaqueta» (≈ 8 % de las búsquedas no dan resultados), pero encuentra «iPhone 13 Pro 128» exacto. Se queda como parte del híbrido y como respaldo.

Un archivo chiquito hecho para que, al decodificarse, ocupe una cantidad enorme de memoria y tumbe al servidor que lo abre.

Funciona porque una imagen de un solo color se comprime muchísimo: unos KB pueden describir cientos de millones de píxeles. Se evita sin abrir la foto: el encabezado de cada PNG o JPEG dice su ancho y su alto, así que se calcula cuánto ocuparía (ancho × alto × canales × bytes) y se rechaza si pasa de un límite. C01 rechaza más de 40 MP y las proporciones de más de 1 a 8, y decodifica pocas fotos a la vez.

Ejemplo. Un PNG de 12 KB que dice medir 10,000 × 10,000 pediría 300 MB abierto en RGB: ≈ 25,000 veces su tamaño.

El método con el que se arma el vocabulario de casi todos los tokenizers: empezar con letras (o bytes) y unir, una y otra vez, el par de vecinos que más se repite en un texto de muestra.

Cada unión crea un token nuevo y queda guardada como regla, en orden. Para partir un texto nuevo se aplican las reglas en ese mismo orden. Las palabras comunes terminan en un solo token y las raras se arman con pedazos. En su versión por bytes (la de GPT-2 y Llama 3) se empieza con los 256 valores de un byte, así que cualquier texto se puede escribir, hasta un emoji. Nació en 1994 para comprimir archivos y en 2016 se adaptó a la traducción automática.

Ejemplo. Con «tenis» (3 veces), «tengo» (2), «tela» y «pista», las primeras uniones son t + e → te, te + n → ten, i + s → is y ten + is → tenis. Una palabra que no estaba, «tenista», queda como tenis · t · a.

Cada intervalo de un histograma, como «de 150 a 200 ms». En monitoreo, un contador que suma 1 cada vez que una request cae en ese intervalo.

Con buckets fijos no hace falta guardar cada latencia: basta un contador por intervalo, que se suma entre copias y entre ventanas. Un percentil se estima buscando el bucket donde cae su posición e interpolando adentro, como si sus requests estuvieran repartidas parejo. Por eso los bordes se ponen apretados alrededor del SLO, y uno justo en él: con buckets gruesos, el estimado puede salir muy lejos del valor de verdad.

Ejemplo. De 10,000 requests, 9,820 caen hasta 150 ms y 110 entre 150 y 200. El p99 (la 9,900) queda 80 de 110 adentro de ese bucket: 150 + 50 × 80 ÷ 110 ≈ 186 ms.

Correr una búsqueda por palabras (BM25) y una por significado (embeddings) en paralelo sobre el mismo catálogo y juntar sus listas. Cada una tapa los huecos de la otra.

Las listas se juntan casi siempre con RRF (Reciprocal Rank Fusion, Cormack y otros, 2009): cada lista le da a cada documento 1 ÷ (k + su posición), con k = 60, y se suman. Usa solo posiciones, así que no hay que comparar puntajes de escalas distintas. Si la parte semántica falla, la de palabras sigue respondiendo sola.

Ejemplo. Con RRF (k = 60), una publicación 1.ª en la lista semántica y 3.ª en la de BM25 suma 1/61 + 1/63 ≈ 0.0323; una 1.ª solo en BM25, 1/61 ≈ 0.0164. C07 y C11 de la Ronda la usan.

Buscar por significado y no por palabras: se compara el embedding de la consulta con los de los documentos y se devuelven los más cercanos.

Encuentra sinónimos («chamarra» y «chaqueta»), descripciones vagas («algo para ir a la playa») y, con un modelo multimodal, fotos a partir de un texto. Falla con lo exacto: un modelo, una talla o un código quedan cerca de otros parecidos. Por eso casi siempre va junto con BM25 en una búsqueda híbrida. Por debajo es una búsqueda de vecinos más cercanos sobre un índice vectorial.

Ejemplo. En C07 de la Ronda, «tenis blancos» se convierte en un vector de 512 números y el índice devuelve las publicaciones más cercanas de entre 100 millones, en milisegundos.

Un grupo de 8 bits: la unidad en la que se miden los archivos y las memorias. Se escribe con B mayúscula y guarda un número del 0 al 255.

Un canal de un píxel en uint8 ocupa 1 byte; un número en float32, 4. Los múltiplos (KB, MB, GB…) van de mil en mil en el sistema decimal y de 1,024 en 1,024 con los prefijos binarios (KiB, MiB, GiB…).

Ejemplo. La foto de C01 como tensor: 3 × 224 × 224 = 150,528 números × 4 bytes = 602,112 bytes ≈ 602 KB, que son ≈ 4.8 millones de bits.

La parte final de una red, chica, que convierte lo que entrega el backbone en la respuesta de la tarea: un logit por categoría, cajas o una máscara.

Es lo que se cambia al reutilizar un backbone para otra tarea (transfer learning). En clasificación es un pooling más una capa densa; en detección, una capa que propone una caja y un puntaje por clase en cada posición; en segmentación, un decoder que agranda los mapas hasta dar una respuesta por píxel. No confundir con las «cabezas de atención» de un transformer, que son otra cosa.

Ejemplo. La cabeza de C01 es una capa densa de 2,048 → 500: 2,048 × 500 + 500 = 1,024,500 parámetros. La original de ImageNet, de 1,000 categorías, tiene 2,049,000.

Memorias pequeñitas y muy rápidas dentro del chip de la CPU que guardan copia de lo que se usó hace poco. Si el dato está ahí (un acierto), llega en unos pocos nanosegundos; si no (un fallo), hay que ir a la RAM, la memoria principal, ≈ 100 ns.

Hay varios niveles (los números son de CPUs de 2022 a 2025). La L1, de 32 a 128 KiB por núcleo, responde en ≈ 1 ns; la L2, de ≈ 1 a 16 MiB, en ≈ 3 a 5 ns; la L3, de decenas de MiB o más y compartida por todos los núcleos o por un grupo de ellos, en ≈ 10 a 30 ns. El hardware la llena solo, sin que el programa lo pida, y nunca trae un byte suelto: trae una línea de 64 bytes seguidos (128 en los chips de Apple). Por eso importa la localidad: recorrer los datos en el orden en que están guardados aprovecha cada línea. Unos pocos fallos mandan sobre el promedio: 95 % de aciertos a 1 ns y 5 % de fallos a 100 ns dan ≈ 6 ns por lectura. La GPU tiene sus propias cachés junto a sus núcleos.

Analogía. La mesa junto a la estufa: lo que está ahí se usa sin esperar. Se rompe en que la mesa la acomodas tú; la caché la llena el hardware solo, y cuando pides un jitomate te sube la caja entera.

Ejemplo. Una línea de 64 bytes trae 16 números float32. Recorrer por filas una matriz de 1,024 × 1,024 float32 da 65,536 fallos; por columnas, si no cabe en la caché, 1,048,576: 16 veces más.

Que la seguridad del modelo sea honesta: de todas las veces que dice 90 %, que acierte 90 de cada 100.

Se revisa agrupando las predicciones por confianza y comparando con lo que acertó en cada grupo; el ECE lo resume en un número. Las redes modernas suelen ser demasiado confiadas; el temperature scaling (dividir los logits entre un número antes del softmax) lo corrige sin cambiar cuál clase queda primero. Importa cuando el número se usa para decidir: ordenar sugerencias, aplicar un umbral o calcular un costo.

Ejemplo. En 300 fotos el modelo dijo ≈ 90 % y acertó 246: 82 %. Exagera. El gate de C01 pide ECE ≤ 0.05.

Lo que hace el sistema operativo para pasar un núcleo de la CPU de un hilo (una línea de ejecución) a otro: guarda por dónde iba el que sale y carga el estado del que entra. Toma del orden de microsegundos.

El planificador del kernel lo hace cuando se acaba el turno de un hilo, cuando el hilo se bloquea (espera la red, el disco o un candado) o cuando despierta uno más urgente. Guarda los registros de la CPU, entre ellos en qué instrucción iba y dónde está su pila, y carga los del siguiente; entre hilos de procesos distintos, cambia también el mapa de memoria. Cada cambio es barato, pero miles por segundo se notan, y el hilo que entra encuentra fría la caché. Gracias a él, una máquina de 10 núcleos corre miles de hilos «a la vez».

Ejemplo. Si un cambio cuesta ≈ 3 µs, 1,000 cambios por segundo se llevan 3 ms de cada segundo de un núcleo (0.3 %); 20,000, 60 ms (6 %).

Todo lo que prepara la siguiente versión del modelo sin que nadie esté esperando: juntar y etiquetar datos, entrenar, examinar y aprobar. Su reloj son las horas, los días y las semanas.

Corre por calendario o cuando algo lo dispara, como el drift o una categoría nueva. Si falla, nadie lo nota ese día: el modelo actual sigue respondiendo, solo que envejece. Se une al camino online por dos puentes: el registro de cada predicción (de online a offline) y el deploy (de offline a online).

Ejemplo. En C01, cada mes: se guarda una muestra de las fotos, se juntan sus categorías (unas 5 mil revisadas a mano), se reentrena en unas horas de GPU, se examina contra el modelo actual y, si no es peor, se despliega.

Todo lo que pasa mientras alguien espera una respuesta: llega la request, se prepara la entrada, el modelo calcula y sale la respuesta. Su reloj son los milisegundos.

Corre por cada request, a cualquier hora, y si falla se nota al instante. Por eso vive con un presupuesto de latencia, un tiempo máximo de espera y un fallback. Crece con el tráfico: más requests por segundo piden más copias encendidas. La pregunta que lo define: ¿alguien está esperando la respuesta?

Ejemplo. En C01: la foto de Ana entra a la API, se prepara, el modelo hace la inferencia y regresa las 5 categorías más probables. 99 de cada 100 veces, en menos de 200 ms.

El pedazo de la foto original que puede influir en una neurona. Crece con cada capa, y más rápido con stride.

Se calcula capa por capa con dos números, el campo r y el salto j (píxeles de la foto entre dos neuronas vecinas): r nuevo = r + (k − 1) × j y j nuevo = j × s, empezando con r = 1 y j = 1. Es un máximo teórico: los píxeles del centro pesan mucho más que los de la orilla. Decide si una red alcanza a ver un objeto grande y si un detalle chico sobrevive.

Ejemplo. Tres capas de 3 × 3 con stride 1 ven 3, 5 y 7 píxeles. Un número del último mapa de la ResNet-50 puede depender de 427 × 427 píxeles.

Una de las cuadrículas de números que forman una imagen. Una foto RGB tiene tres canales: la cuadrícula de los rojos, la de los verdes y la de los azules.

Una foto en blanco y negro tiene un canal; un PNG con transparencia tiene cuatro (RGBA: el cuarto dice qué tan opaco es cada píxel). Un modelo como el de C01 espera exactamente tres, así que todo se convierte a RGB antes de entrar.

Ejemplo. La foto de Ana, ya preparada, son 3 canales de 224 × 224: 50,176 números rojos, 50,176 verdes y 50,176 azules.

Un grupo de neuronas que reciben las mismas entradas, cada una con sus propios pesos. Lo que sale de una capa entra a la siguiente.

En una capa densa (dense, fully connected o linear) cada neurona ve todas las entradas: tiene entradas × salidas pesos más un sesgo por salida, y hace entradas × salidas multiplicaciones-sumas por ejemplo. En una capa convolucional cada filtro ve solo un pedacito (convolución). Una red de capas densas es un MLP.

Ejemplo. Una capa densa de 2,048 entradas y 500 salidas tiene 2,048 × 500 + 500 = 1,024,500 parámetros: es la cabeza de la ResNet-50 de C01.

Dos ejemplos que no son el mismo archivo pero muestran lo mismo: la misma foto recortada, vuelta a comprimir o más clara. Un hash normal no los detecta; una huella perceptual o una comparación de embeddings, sí.

Si un casi duplicado queda en train y su gemelo en test, el modelo acierta de memoria: es leakage. Para copias exactas basta un hash del archivo, como sha256, que cambia por completo si cambia un solo byte. Para casi copias se usa una huella perceptual (el average hash, pHash y parientes): se calcula sobre una versión diminuta de la imagen, en gris, y cambia poco si la imagen cambia poco. Dos fotos son casi duplicadas si sus huellas difieren en pocos bits. También se pueden comparar sus embeddings con similitud coseno.

Ejemplo. Barz y Denzler (2020) encontraron que el 3.3 % de las imágenes de test de CIFAR-10 y el 10 % de las de CIFAR-100 tenían un casi duplicado en train. En C01, la misma foto en tres publicaciones.

Una función de Linux que junta procesos (programas corriendo) en un grupo y le pone límites: cuánta memoria, cuánta CPU, cuántos procesos. Es lo que hace cumplir los limits de Kubernetes y el --memory de Docker.

Se ve como una carpeta en /sys/fs/cgroup, con archivos como memory.max (bytes) y cpu.max (cuota y ventana). La memoria es un tope duro: si el grupo se pasa, el OOM killer del kernel mata con SIGKILL a un proceso del grupo (en Kubernetes, a todo el contenedor), y sale con código 137 (oom). La CPU es una cuota: con un límite de 1 CPU, el grupo puede usar 100 ms de CPU en cada ventana de 100 ms, sumando todos sus hilos; si se la acaba, se congela hasta la siguiente ventana (throttling): no muere, se vuelve lento a ráfagas. Ojo: os.cpu_count() de Python cuenta los núcleos del nodo, no la cuota del cgroup.

Ejemplo. El gateway de C01 tiene un límite de memoria de 1 GiB y ninguno de CPU. Con 4 fotos de 40 ms de CPU a la vez y un límite de 1 CPU, cada foto tardaría 115 ms en vez de 40.

Un archivo con el estado del entrenamiento en un momento: los parámetros, el estado del optimizador y en qué paso iba. Sirve para seguir si algo falla y para quedarse con la mejor versión.

Uno completo lleva las perillas, el estado del optimizador (en Adam, m y v), la época y el paso, el estado del scheduler, el del GradScaler si se usa precisión mixta y el de los generadores de azar. Con solo las perillas se puede responder, pero no seguir el mismo entrenamiento. Guardarlo seguido permite usar máquinas spot, que el proveedor puede reclamar con poco aviso.

Ejemplo. C01 guarda uno cada 15 minutos: 24.5 M parámetros × 4 bytes ≈ 98 MB, más el estado de Adam (2 × 98 MB), ≈ 294 MB en total.

El orden en que se acomodan las dimensiones de una imagen: primero el canal, luego el alto y luego el ancho. Es el que esperan PyTorch y el modelo de C01.

Las librerías de imágenes (Pillow, OpenCV) suelen dar HWC: alto, ancho y los 3 números de cada píxel juntos. Pasar de uno a otro es reacomodar los mismos números. Con un grupo de imágenes adelante se escribe NCHW: cuántas, canales, alto, ancho.

Ejemplo. HWC: (224, 224, 3). CHW: (3, 224, 224). Mismos 150,528 números, otro orden.

La tarea de elegir de una lista fija de clases. Puede ser binaria (sí o no), multiclase (una de muchas) o multietiqueta (varias a la vez).

El modelo da un puntaje (logit) por clase. En la multiclase, softmax los vuelve probabilidades que suman 1 y gana la más alta (argmax); en la clasificación binaria y la multietiqueta, cada logit pasa por una sigmoide y un umbral decide. Las clases se fijan al entrenar: el modelo no puede elegir una que no estaba en su lista.

Ejemplo. Un filtro de spam (2 clases), la categoría de una foto en C01 (500 clases) o las 7 políticas de moderación de C06 (multietiqueta).

Clasificación con solo dos clases: sí o no. ¿Este pago es fraude? ¿Este correo es spam?

Casi siempre el modelo da un solo logit, la sigmoide lo vuelve la probabilidad del «sí» y un umbral decide. A la clase que buscas (fraude, spam) se le dice positiva; a la otra, negativa. Suele haber desbalance de clases: en C09 el fraude es ≈ 0.08 % de los pagos, así que decir siempre «no» ya acierta 99.92 %.

Ejemplo. Logit 2 → sigmoide 0.881 → con umbral 0.5, «sí, es spam».

Una red neuronal hecha sobre todo de convoluciones, activaciones y pooling. Es la familia clásica para imágenes.

Le va bien a las fotos por tres razones: cada filtro mira cerca (el significado está en los píxeles vecinos), usa el mismo filtro en todas partes (reconoce un tenis esté donde esté, con pocos parámetros) y arma lo complicado con lo simple, capa tras capa, porque su campo receptivo crece. La ResNet-50 de C01 es una CNN.

Ejemplo. Una capa convolucional de 64 filtros de 3 × 3 sobre la foto de color tiene 1,792 parámetros; una capa densa de 1,000 neuronas sobre los mismos 150,528 números tendría ≈ 150 millones.

Convertir un dato que no es un número (una categoría, un texto) en números que el modelo pueda usar, sin inventarle relaciones que no tiene.

Un modelo solo multiplica y suma, así que todo le tiene que llegar como número. Para una categoría hay varias formas: one-hot (una columna de 0 y 1 por valor), números en orden (solo si el orden existe de verdad, como las tallas chica, mediana y grande), hashing (una fórmula fija manda cada valor a una de un número fijo de casillas, útil cuando hay millones de valores) y embeddings (una lista de números aprendida para cada valor). La codificación se decide con train y se usa idéntica al servir.

Ejemplo. El giro del comercio en C09: supermercado = [1, 0, 0], gasolinera = [0, 1, 0], videojuegos = [0, 0, 1]. En C15, el id de cada anuncio cae por hashing en una de 2²⁴ = 16,777,216 casillas.

El número de 0 a 255 que deja un programa al terminar. 0 quiere decir que todo salió bien, y cualquier otro, que algo falló. Si lo mató una señal del sistema operativo, vale 128 más el número de la señal: 137 = 128 + 9, la de SIGKILL.

Lo lee el padre: la terminal (echo $?), Docker o el kubelet. Del 1 al 125 los define cada programa (1 es el error de siempre; Python sale con 1 si una excepción no se atrapa). El 126 y el 127 los pone la shell de la terminal (no se pudo ejecutar, no existe). De 128 en adelante, 128 + n quiere decir «lo mató la señal n»: 130 es Ctrl+C, 137 es SIGKILL, 139 es SIGSEGV y 143 es SIGTERM. Cabe en un byte, así que da la vuelta: sys.exit(256) sale con 0. El subprocess de Python lo da en negativo (−9 en vez de 137). Kubernetes lo muestra en kubectl describe pod como Exit Code, junto con la razón, por ejemplo OOMKilled.

Ejemplo. Exit Code 137 con Reason OOMKilled: el contenedor pasó su límite de memoria y el kernel lo mató. 137 es 128 + 9, la señal SIGKILL.

La parte larga y delgada de una distribución, donde quedan los pocos valores más extremos. En latencia, las requests más lentas: las del p95, el p99 y el p99.9.

La latencia tiene la cola a la derecha porque siempre se puede tardar más: una pausa del programa, un reintento, una fila de espera. La cola jala al promedio y decide el p99. A escala importa todavía más: con fan-out, la cola de cada pieza se vuelve la latencia típica del conjunto. No es lo mismo que la cola larga de categorías, que son muchas categorías con pocas fotos cada una.

Ejemplo. En 1,000 requests de juguete, la mediana es 38 ms, pero 29 requests pasan de 150 ms y la más lenta tarda 693: esa es la cola, y ahí está el p99, en 488 ms.

Cuando hay muchas categorías y la mayoría tiene pocos ejemplos: unas cuantas tienen decenas de miles y muchas, apenas cientos o decenas. Ordenadas de mayor a menor, forman una gráfica con una «cola» baja y larga.

El nombre viene de la gráfica: si ordenas las categorías de la más grande a la más chica, la curva cae rápido y luego sigue, baja y larga. Las grandes son la cabeza (head). En la Ronda se miden la cabeza y la cola por separado, porque un modelo nuevo suele ganar en una y perder en la otra.

Ejemplo. C01 tiene 500 categorías y ≈ 1.84 M fotos de entrenamiento: 3,680 por categoría si se repartieran parejo, pero casi ninguna está cerca de ese promedio.

Hacer muchas pruebas a la vez (métricas, slices, categorías) y fijarse en las que salen. Cada una trae su 5 % de falsa alarma: con 20 pruebas sin efecto, esperas una.

La probabilidad de al menos una falsa alarma en k pruebas independientes es 1 − (1 − α)^k, el complemento de que ninguna falle: con 20 a 0.05, ≈ 64 %. Defensas: una métrica primaria fijada antes, leer las demás como pistas y corregir el corte. Bonferroni usa α ÷ k en cada prueba; Holm es una versión menos estricta, la que usa el gate de C01 sobre sus 100 categorías.

Ejemplo. Un A/B con 10 métricas, ninguna con efecto real: 1 − 0.95¹⁰ ≈ 40 % de probabilidad de que alguna salga «significativa».

Traducir un programa completo, antes de correrlo y una sola vez, a instrucciones de máquina: las órdenes simples que entiende la CPU. Lo hace otro programa, el compilador, y el resultado es un binario ejecutable, un archivo que se arranca directo.

Los lenguajes compilados (C, C++, Go, Rust) pagan la traducción una vez y después corren a toda velocidad, porque la CPU ejecuta el resultado directo. El precio: un binario por cada arquitectura y sistema operativo, y volver a compilar con cada cambio. Python hace otra cosa: lo corre un intérprete. La palabra también se usa con modelos: TensorRT compila un modelo en un engine hecho para un modelo de GPU y una versión de TensorRT, y torch.compile compila partes de un modelo de PyTorch mientras el programa corre.

Ejemplo. Triton se compila desde C++ al binario tritonserver. El modelo de C01 se compila con TensorRT a un engine FP16 para la T4: si la versión no coincide, Triton no arranca y el pod queda en CrashLoopBackOff.

La probabilidad de que algo no pase: 1 − p. Su gran uso es «al menos uno»: P(al menos uno) = 1 − P(ninguno).

Sale de que «pasa» y «no pasa» cubren todos los casos y suman 1. Contar todas las formas en que «al menos uno falla» es engorroso; su contrario, «todos funcionan», es una sola cuenta con la regla del producto. Así salen el fan-out, 1 − 0.99^N, y la redundancia, 1 − (1 − a)^k. También es el paso entre una disponibilidad y su tiempo caído: 99.9 % disponible es 0.1 % caído.

Ejemplo. Dos servicios, cada uno lento 1 de cada 10 veces: al menos uno lento es 1 − 0.9 × 0.9 = 0.19. Sumar 0.1 + 0.1 = 0.2 cuenta dos veces el caso en que los dos son lentos.

Cuando lo que frena un cálculo es la velocidad de los núcleos y no la memoria: los datos llegan a tiempo y el chip calcula a su máximo. Se acelera con menos FLOPs o con más FLOPS.

En español, «limitado por el cálculo». Pasa cuando la intensidad aritmética del cálculo es mayor que el punto de quiebre de la GPU: cada byte que llega se usa en tantas operaciones que la memoria alcanza a alimentar a los núcleos. Lo son las multiplicaciones de matrices grandes, el prefill de un LLM, que procesa todo el prompt de una vez, y, en buena parte de sus capas, una CNN con batches moderados. Palancas: menos FLOPs (menos resolución, un modelo más chico), tensor cores de menor precisión (FP16, INT8, FP8) o una GPU con más TFLOPS. Una GPU con más ancho de banda no lo acelera.

Ejemplo. Dos matrices de 4,096 × 4,096 en FP16 en una T4: calcular toma al menos ≈ 2.1 ms (137 GFLOPs ÷ 65 TFLOPS) y mover sus ≈ 101 MB, ≈ 0.3 ms (a 320 GB/s). Manda el cálculo.

Cuando cambia la regla que une la entrada con la respuesta correcta: la misma foto o el mismo pago ahora merecen otra respuesta, aunque los datos de entrada se vean idénticos.

En notación, cambia p(y | x): la probabilidad de cada respuesta y dada una entrada x. En un concept drift puro las entradas no se mueven, así que el PSI de las entradas puede quedarse en cero mientras el modelo empeora. Solo se ve con etiquetas nuevas (la métrica cae) o con señales indirectas, como más correcciones de personas. Las etiquetas viejas quedan mal: se reetiqueta con la regla nueva y se reentrena. No es lo mismo que el drift de datos (cambian las entradas) ni que el label shift (cambia cuánto hay de cada clase).

Ejemplo. En C01, moderación decide que las fundas de celular ya no van en «Celulares», sino en «Accesorios para celular»: la misma foto, otra respuesta correcta. En C09, los defraudadores aprenden los cortes y compran a US$95–99, justo debajo del corte de US$100: la misma compra ahora es fraude más seguido.

Tener varias tareas en curso al mismo tiempo, aunque en cada instante avance solo una. Ayuda cuando las tareas esperan: mientras una espera, otra usa la CPU.

Es una forma de organizar el trabajo, no de hacerlo más rápido. Con trabajo de pura CPU en un núcleo, turnarse no baja el tiempo total y empeora el promedio. Con esperas (la red, el disco, otro servicio), sí ayuda: el gateway de C01 atiende otras requests mientras espera a Triton. Se logra con hilos, con procesos o con un event loop. No es lo mismo que el paralelismo, que necesita varios núcleos: todo paralelismo es concurrencia, pero no al revés.

Analogía. Un mesero que atiende cinco mesas: toma una orden, la lleva a la cocina y, mientras se prepara, atiende otra mesa. Se rompe en que el mesero decide cuándo cambiar de mesa; con hilos, lo decide el planificador del sistema operativo.

Ejemplo. Cuatro requests del gateway con 6 ms de CPU y 10 ms de espera cada una: una tras otra, la cuarta sale a los 64 ms; concurrentes, en el mismo núcleo, a los 34 ms.

La probabilidad que un modelo le da a su opción favorita, la del primer lugar. Es lo seguro que dice estar, no una garantía de que acierte.

En la Ronda también se le dice score o score top-1. Un modelo puede estar muy seguro y equivocado, sobre todo ante fotos distintas a las de su entrenamiento: softmax siempre reparte el 100 % entre las clases que conoce. Si está bien calibrado, de cada 100 respuestas con 94 % acierta unas 94. Ojo: en estadística, «intervalo de confianza» es otra cosa.

Ejemplo. «Tenis, 94 %»: la confianza es 0.94. En C01 se llama baja confianza a un top-1 menor que 0.3.

Un paquete con tu programa y todo lo que necesita para correr (la versión de Python, las librerías, los archivos), para que corra igual en cualquier máquina.

Resuelve el clásico «en mi máquina sí funciona». La herramienta más usada para crearlos es Docker. Ojo: si el modelo usa una GPU, la máquina también necesita sus drivers.

Analogía. Un contenedor de barco: no importa qué lleve adentro, tiene un tamaño estándar y cualquier puerto, grúa o barco lo puede mover.

Ejemplo. El contenedor de la API de C01 lleva la versión exacta de Python, las librerías y el código. El mismo contenedor que se probó es el que corre en cada servidor.

Un contenedor es un programa corriendo (un proceso) al que el kernel, el núcleo del sistema operativo, le enseña solo su pedazo del sistema (namespaces) y le pone límites (cgroups): todos los de una máquina comparten un kernel. Una máquina virtual simula una computadora completa, con su propio kernel, encima de un hipervisor, el programa que parte una computadora física en varias.

Los namespaces deciden qué ve el proceso: su propia lista de procesos (adentro es el PID 1), su red, su árbol de archivos, su nombre de máquina. Los cgroups deciden cuánto usa. Como el kernel es compartido, la imagen no trae kernel ni driver, arranca en menos de un segundo, más lo que tarde el proceso, y casi no gasta memoria de más; pero un error del kernel afecta a todos los contenedores del nodo. Una VM paga su propio kernel y su sistema completo (más memoria y un arranque de segundos a minutos) a cambio de aislar más: un atacante tendría que romper también el hipervisor. En la nube se usan las dos: una instancia de EC2 es una VM, y adentro corren los contenedores.

Analogía. Departamentos en un mismo edificio contra casas separadas: los departamentos comparten cimientos, tubería y luz (el kernel); cada casa tiene los suyos. Se rompe en que un contenedor ni siquiera tiene paredes propias: es un proceso al que el kernel le oculta a los vecinos.

Ejemplo. En C01, una g4dn.xlarge (una VM sobre el hipervisor Nitro de AWS) corre el contenedor de Triton, con Ubuntu 22.04, sobre el kernel de Amazon Linux 2023 de esa VM, junto al device plugin de NVIDIA.

Cuando el entrenamiento ya casi no mejora: la pérdida dejó de bajar y los pasos apenas cambian las perillas.

En un modelo de juguete, la perilla se acerca cada vez más al fondo y el gradiente, a 0. En uno real, con batches al azar, la pérdida nunca se queda quieta: tiembla alrededor de un nivel, y se dice que convergió cuando ese nivel deja de bajar. Bajar el learning rate al final ayuda a asentarse. Que la pérdida de entrenamiento converja no dice que el modelo sea bueno con datos nuevos: eso lo dice la validación.

Ejemplo. En la parábola de la lección, con lr = 0.05 la perilla queda a menos de 0.01 del fondo en 12 pasos; con lr = 0.005 tarda 140.

Pasar un filtro chico (por ejemplo de 3 × 3) por toda la foto: en cada posición multiplica los píxeles que cubre por sus pesos, suma y escribe un número.

El mismo filtro se usa en todas las posiciones, así que una capa convolucional tiene muy pocos parámetros, encuentra un patrón esté donde esté y reutiliza cada peso miles de veces por foto. Cada filtro produce un mapa de activaciones, cuyo tamaño depende del stride y del padding. (En matemáticas, una convolución voltea el filtro antes de aplicarlo; las redes no lo voltean, pero se le sigue llamando así.)

Ejemplo. Un filtro con columnas 1, 0 y −1 sobre una ventana con filas 9 · 9 · 1, 8 · 9 · 0 y 9 · 8 · 1 da 8 + 8 + 8 = 24: hay un borde de claro a oscuro.

Una función que se puede pausar a la mitad y continuar después, donde se quedó y con sus variables intactas. En Python se define con async def, y cada await es un punto donde se pausa para que corra otra.

Llamar a una función async def no la corre: crea una corrutina, que alguien tiene que esperar con await o entregarle al event loop como tarea (asyncio.create_task, asyncio.gather). Solo dentro de otra corrutina se puede usar await. Pausarse y volver es mucho más barato que cambiar de hilo, y por eso un proceso puede tener miles de corrutinas esperando a la vez. Una corrutina suelta el turno solo en sus await: entre uno y otro, nadie más corre en ese loop.

Ejemplo. async def atender(): datos = await leer(); return await triton(datos) se pausa dos veces: mientras llegan los bytes y mientras responde Triton. En esas pausas, el loop atiende a otras requests.

El procesador de una computadora: pocos núcleos muy capaces, de 8 a 16 en una laptop y decenas en un servidor, que hacen cualquier tipo de trabajo, uno tras otro, muy rápido.

Corre el sistema operativo, el código de Python, la lectura de archivos y la red. Al entrenar, la CPU prepara los batches (leer las fotos, decodificarlas, la data augmentation) y la GPU hace las cuentas. Si la CPU no alcanza a preparar los datos, la GPU se queda esperando. Algunos modelos, como los árboles de C14, se entrenan solo en CPU.

Ejemplo. El entrenamiento de C14 corre en una máquina de 96 vCPU (núcleos virtuales), unas 2 a 3 horas cada domingo.

Un trabajo que tarda porque tiene muchas cuentas que hacer: mientras corre, un núcleo de la CPU está al 100 %. Se acelera con una CPU más rápida, repartiéndolo entre núcleos o calculando menos; aprovechar mejor las esperas no lo cambia, porque casi no espera.

Decodificar y redimensionar una foto, tokenizar texto en Python, armar un JSON enorme o correr un modelo en CPU son CPU-bound. Se reconoce porque el núcleo está al 100 % mientras tarda. En Python, varios hilos no aceleran un trabajo CPU-bound escrito en Python puro, por el GIL; sí lo aceleran varios procesos (multiproceso) o librerías escritas en C que sueltan el GIL, como Pillow, NumPy o PyTorch. Dentro de async (programación asíncrona), un trabajo CPU-bound congela al event loop: por eso va a un threadpool (grupo de hilos). No lo confundas con compute-bound, que dice si un chip, como la GPU, está limitado por calcular o por leer su memoria.

Ejemplo. El decode de una foto en C01 cuesta ≈ 6 ms de CPU en promedio, y el de una foto web de 12 MP sin draft mode, de 40 a 80 ms. A 500 requests por segundo, son ≈ 3 núcleos ocupados todo el tiempo.

Recortar una imagen para quedarte con un pedazo. El center crop toma un cuadro del centro.

Muchos modelos de visión esperan una entrada cuadrada de tamaño fijo. Recortar del centro asume que lo importante está en medio: si el tenis estaba en una orilla, se puede quedar fuera.

Ejemplo. De 256 × 341, el center crop de 224 × 224 quita 16 píxeles de cada lado a lo ancho, y 58 arriba y 59 abajo.

Guardar los números de un modelo con menos bits, como enteros más una escala compartida: valor ≈ escala × entero. Baja la memoria y puede acelerar, a cambio de cambiar un poco las respuestas.

En la versión simétrica, escala = máximo ÷ 127 (en INT8) y entero = redondear(valor ÷ escala); el error es, a lo mucho, media escala. La asimétrica agrega un punto cero: valor ≈ escala × (entero − punto cero). Un valor atípico agranda la escala para todo el grupo, así que se usan escalas por canal o por grupo y rangos que recortan extremos. Para las activaciones se calibra con unos cientos de ejemplos reales (calibrar aquí es medir rangos, no la calibración de probabilidades). PTQ cuantiza un modelo ya entrenado; QAT entrena simulando el redondeo. Ningún modelo cuantizado sale sin prueba de paridad y sin medir la calidad por categoría y por slice.

Analogía. Medir con una regla: la escala es la separación entre sus rayitas. Con rayitas de un milímetro mides fino; si la regla tiene que llegar a un kilómetro con las mismas rayitas, cada una mide metros y lo chico se pierde. Se rompe en que una regla de verdad tiene las rayitas fijas; en la cuantización se eligen para cada grupo de números, según su rango.

Ejemplo. Con pesos de −2.5 a 2.5, la escala es 2.5 ÷ 127 ≈ 0.0197: el 0.1 se guarda como 5 y vuelve como 0.0984. La Ronda (M08) cuantizó la ResNet-50 de C01 de 98 MB a 25.1 MB.

La plataforma de NVIDIA para programar sus GPUs: un lenguaje, un compilador y bibliotecas con el trabajo ya hecho, como cuBLAS para multiplicar matrices. PyTorch la usa por debajo. Solo funciona en GPUs de NVIDIA.

Existe desde 2007. Con CUDA se escriben kernels, las funciones que corren en la GPU, y sus bibliotecas traen los más comunes ya hechos: cuBLAS multiplica matrices (viene con CUDA); cuDNN hace convoluciones, NCCL pasa datos entre GPUs y TensorRT convierte un modelo en un engine para una GPU concreta (esas tres, NVIDIA las publica aparte). Su versión importa: el runtime de CUDA va dentro de tu imagen, y el driver de la máquina tiene que ser lo bastante nuevo para él (cualquier 12.x corre con un driver 525 o más nuevo; 13.x, con uno 580 o más). AMD tiene su propia plataforma (ROCm) y las TPUs de Google, otra (XLA). Ese ecosistema es buena parte de por qué casi todo el ML corre en NVIDIA. Los «CUDA cores» son carriles de cálculo, no núcleos completos.

Ejemplo. La imagen de Triton de C01, tritonserver:24.08, trae CUDA 12.6, cuDNN 9.3 y TensorRT 10.3. Esas bibliotecas son la mayor parte de sus ≈ 9.2 GB.

La gráfica de la loss (o de una métrica) en entrenamiento y en validación al final de cada época. Muestra si el modelo aprende, si memoriza o si no aprende nada.

Si las dos líneas bajan juntas, aprende. Si la de entrenamiento baja y la de validación sube, hay overfitting. Si las dos se quedan altas, underfitting. Se guarda con cada entrenamiento porque un número final solo no muestra nada de eso.

Ejemplo. Loss de validación: 2.15 en la época 1, 0.80 en la 8 (su punto más bajo) y 1.15 en la 20. El mejor checkpoint es el de la época 8.

La gráfica de la precision contra el recall de un modelo, para todos los umbrales posibles. Con clases muy desbalanceadas, como el fraude, dice la verdad cuando la curva ROC se ve demasiado bien.

Cada umbral es un punto: a lo ancho, el recall; a lo alto, la precision. Un modelo al azar queda en una línea horizontal a la altura de la prevalencia (la fracción de positivos), no en la diagonal. El área bajo la curva se llama average precision (AP) o PR-AUC, y su promedio entre clases es el mAP de la detección de objetos. A diferencia de la curva ROC, no usa los verdaderos negativos, así que una clase negativa gigantesca no la infla.

Ejemplo. Un detector de fraude, con 0.08 % de fraude, atrapa 70 % del fraude marcando 1 % de las compras buenas. En la ROC es el punto (1 %, 70 %), casi perfecto. En la PR es una precision de 5.3 %: de cada 100 compras marcadas, ≈ 95 son de clientes honestos.

La gráfica de qué fracción de los «sí» encuentra el modelo (recall) contra qué fracción de los «no» marca por error, para todos los umbrales posibles.

Cada umbral es un punto: a lo ancho, la tasa de falsos positivos, FP / (FP + TN); a lo alto, el recall. Un modelo al azar va por la diagonal; uno perfecto sube pegado a la izquierda. Como divide entre todos los negativos, con clases muy desbalanceadas se ve demasiado bien: ahí conviene la curva PR. El nombre viene de los radares de la Segunda Guerra Mundial.

Ejemplo. Con 10 fotos (4 de tenis): umbral 0.80 → 0 % de falsos positivos y 50 % de recall; 0.50 → 17 % y 75 %; 0.30 → 33 % y 100 %.

Hacer variaciones de las fotos de entrenamiento que no cambian su etiqueta (voltearla como espejo, recortar un poco distinto, cambiar el brillo) para que el modelo aprenda que esos cambios no importan.

Se aplica solo en train y al azar en cada pasada, así que el modelo casi nunca ve dos veces la misma imagen exacta. Validación y test van sin cambios. No inventa información: 40 fotos de las mismas 3 monedas siguen siendo 3 monedas.

Ejemplo. Unos tenis volteados como espejo siguen siendo tenis. Un 6 de cabeza es un 9: para leer texto, esa variación cambia la respuesta.

Una colección de ejemplos, guardada y ordenada, con la que se entrena o se evalúa un modelo.

Cada ejemplo trae la entrada (la foto) y, casi siempre, su etiqueta (la categoría correcta). En producción no basta con tenerlo: hay que poder decir exactamente con cuál dataset se entrenó cada modelo.

Ejemplo. El dataset de un mes en C01 son las fotos de publicaciones con su categoría revisada.

La segunda fase de cada request a un LLM: escribir la respuesta de un token por paso. Cada paso lee todos los pesos del modelo y el KV cache, y agrega un token.

Es la generación autorregresiva vista como trabajo de la GPU. Como cada paso produce un solo token por conversación, casi no hay cálculo por cada byte leído: manda la velocidad de la memoria (memory-bound). Lo que tarda un paso es el TPOT. Por eso los servidores juntan muchas conversaciones en cada paso: una sola lectura de los pesos les sirve a todas.

Ejemplo. Llama 3 8B en BF16 pesa ≈ 16.1 GB y una L4 lee ≈ 300 GB por segundo: cada paso tarda al menos ≈ 54 ms, así que una conversación sola no pasa de ≈ 19 tokens por segundo.

Convertir un archivo de imagen comprimido (JPEG, PNG) en la cuadrícula de píxeles que representa. Antes de decodificar, la foto son bytes que no se pueden usar directamente.

Cuesta tiempo de CPU y memoria: una foto de 12 MP pasa de ≈ 3 MB comprimida a ≈ 36.6 MB de píxeles. Distintas librerías, o distintas versiones de la misma, pueden dar píxeles ligeramente diferentes para el mismo JPEG. Como un archivo chiquito puede pedir muchísima memoria al decodificarse (una bomba de descompresión), primero se lee el tamaño del encabezado.

Ejemplo. En C01, decodificar y preparar una foto toma ≈ 6 ms de CPU en promedio: tanto o más que la propia inferencia en la GPU (≈ 3 a 6 ms).

Encontrar las copias y casi copias de un mismo contenido para quedarse con una o tratarlas como grupo. Con embeddings: si el coseno entre dos cosas pasa un umbral, se marcan como duplicadas.

Las copias exactas se detectan antes y más barato con un hash de los bytes; los recortes, recompresiones y filtros, con un hash perceptual o con embeddings y un umbral elegido con pares revisados por personas. El umbral depende de qué cuesta cada error: antes de repartir un dataset conviene recall alto, para que la misma foto no quede en train y en test (leakage); en moderación, donde una decisión se aplica a todo el grupo, conviene precision alta. En un catálogo grande no se compara todo contra todo: para cada elemento nuevo se buscan sus vecinos más cercanos y solo a ellos se les aplica el umbral.

Ejemplo. Con 8 pares revisados (4 duplicados de verdad), un umbral de 0.95 marca 4 pares y acierta 3: precision 0.75 y recall 0.75. Uno de 0.90 encuentra los 4 duplicados (recall 1.0), con precision 0.67.

Usar redes neuronales con muchas capas. «Profundo» se refiere a la cantidad de capas, no a nada filosófico.

Cada capa trabaja sobre lo que encontró la anterior, así que con muchas capas la red combina cosas simples (bordes) en cosas complicadas (un tenis). No hay un número oficial de capas a partir del cual algo es «deep». Despegó en 2012, cuando se juntaron muchos datos (ImageNet), GPUs y trucos para entrenar redes profundas.

Ejemplo. La ResNet-50 tiene 50 capas con pesos; la red de juguete de la lección, 2. Las dos son redes neuronales, pero solo la primera se llamaría profunda.

Poner a responder a la gente de verdad una versión nueva de un modelo o de un programa, en lugar de la anterior.

Es el puente del camino offline al camino online: la única forma en que lo que se entrenó le llega a alguien. Casi nunca se hace de golpe: primero la versión nueva atiende una fracción chica del tráfico, se vigila y, si todo va bien, recibe más. Si algo empeora, se regresa a la versión anterior (rollback).

Ejemplo. En C01, un modelo aprobado responde primero 5 de cada 100 fotos, luego 25 y luego todas. Si suben la latencia o los errores, se regresa solo a la versión anterior.

Cuando unas clases tienen muchísimos más ejemplos que otras. El modelo tiende a favorecer a las grandes, y el promedio esconde que falla en las chicas.

La accuracy engaña: un modelo que siempre dice la clase grande acierta mucho sin aprender nada. Se mide cada clase por separado (recall por clase, macro-promedio), se estratifica el split y se etiqueta más donde hay poco.

Ejemplo. 950 fotos de tenis y 50 de botas: un modelo que siempre dice «tenis» acierta 95 % y nunca reconoce unas botas. En C09, 1 pago de cada 1,250 es fraude: decir siempre «no» acierta 99.92 %.

La regla para mejorar los parámetros (las perillas) de un modelo: mover cada uno un pasito en contra de su gradiente. Parámetro nuevo = parámetro − learning rate × gradiente.

Se repite paso tras paso: cerca del fondo el gradiente se achica y los pasos también, sin que nadie cambie el learning rate. Si el learning rate es demasiado grande, cada paso se pasa del fondo al otro lado y la pérdida explota. Con el gradiente de un batch al azar se llama descenso de gradiente estocástico (SGD); los optimizadores como momentum y Adam son variaciones de la misma idea.

Ejemplo. w = 0, gradiente −24, learning rate 0.05: w nueva = 0 − 0.05 × (−24) = 1.2, y la pérdida baja de 36 a 12.96.

La raíz de la varianza: qué tan lejos del promedio suele caer un dato, en las mismas unidades que los datos. Se escribe σ (sigma).

Es la medida de dispersión más usada. Si los datos tienen forma de campana (distribución normal), ≈ 68 % caen a menos de una desviación del promedio, ≈ 95 % a menos de dos y ≈ 99.7 % a menos de tres. La desviación estándar del resultado de un examen (no de cada foto) tiene nombre propio: el error estándar.

Ejemplo. Con 81, 89, 85, 82 y 88, la varianza es 10 y la desviación estándar √10 ≈ 3.2 puntos (3.5 con n − 1): los resultados suelen caer a unos 3 puntos del 85.

La tarea de encontrar cada objeto en una imagen: por cada uno, una caja (dónde está), una clase (qué es) y una confianza.

Una caja son cuatro números: por ejemplo, las dos coordenadas de la esquina de arriba a la izquierda, el ancho y el alto, en píxeles. A diferencia de la clasificación, una foto puede dar cero, una o muchas cajas.

Ejemplo. Marcar cada casco y cada chaleco de seguridad en el video de una planta.

Cuántos números tiene un vector. En un embedding es una decisión de diseño: más números dan lugar a más detalle, pero la memoria y el trabajo de cada búsqueda crecen en proporción.

Un embedding de 1,024 números ocupa el doble de memoria y cuesta el doble por comparación que uno de 512. Cada duplicación suele ayudar menos que la anterior, así que se busca la dimensión más chica que cumpla con la calidad. En muchas dimensiones pasan cosas raras: dos vectores al azar salen casi perpendiculares (en 512 dimensiones, su coseno típico es ≈ 0.04), así que la escala de los cosenos depende de cada modelo.

Ejemplo. En la Ronda, C08 usa 128 (100 M vectores en int8 = 12.8 GB), C07 usa 512 (51.2 GB en int8) y C11 usa 1,024 (12 M pedazos de documentos = 49.2 GB en float32).

Donde se guardan los archivos aunque se apague la computadora: programas, fotos, datasets y los pesos de un modelo. Cabe mucho más que en la RAM y cuesta menos por GB, pero encontrar un dato tarda de ≈ 0.1 ms (un SSD) a ≈ 10 ms (un disco duro).

Hay dos tipos: el disco duro (HDD, hard disk drive), con platos que giran y un brazo que se mueve, y el SSD, sin partes móviles. Un disco se lee por bloques (de 512 bytes o de 4 KiB, y el sistema operativo casi siempre pide 4 KiB o más a la vez): pedir un byte cuesta un bloque entero. Tiene tres números distintos: cuánto tarda cada lectura (su latencia), cuántas lecturas al azar aguanta por segundo (sus IOPS, input/output operations per second) y cuántos bytes por segundo da leyendo de corrido (su throughput). En la nube hay discos locales, pegados a la máquina, rápidos y que se borran al detenerla, y discos de red, como EBS gp3 en AWS, que sobreviven a la máquina pero cruzan la red en cada lectura. Lo que está en el disco se usa copiándolo antes a la RAM.

Analogía. El mercado al que vas por lo que no cabe en tu cocina: hay de todo y no se echa a perder, pero cada vuelta te toma horas. Se rompe en que, una vez que llegas, un disco te puede dar muchísimos bytes seguidos muy rápido: lo lento es empezar.

Ejemplo. Leer los 16.06 GB de Llama 3 8B en BF16 de un disco gp3 de base (125 MiB/s) tarda ≈ 2 minutos; de un NVMe local a 2 GB/s, ≈ 8 s.

La fracción del tiempo, o de los requests, en que un servicio responde bien. 99.9 % quiere decir que puede fallar el 0.1 %: ≈ 43 minutos en un mes de 30 días.

Se mide por tiempo (minutos arriba ÷ minutos totales) o por requests (buenos ÷ válidos), y esa medida es un SLI; la meta, un SLO. Piezas en serie multiplican sus disponibilidades, así que el conjunto es peor que su peor pieza. Réplicas en paralelo multiplican sus indisponibilidades: 1 − (1 − a)^k, si fallan de forma independiente. El tiempo caído es cuántas veces se falla por cuánto se tarda en volver, y por eso volver rápido (un rollback en minutos) sube la disponibilidad tanto como fallar menos.

Ejemplo. El SLI de C01 cuenta como bueno un request que no termina en error del servidor y responde en 300 ms o menos, y su SLO es 99.9 % en 30 días. Tres piezas en serie al 99.99 %, 99.95 % y 99.9 % dan ≈ 99.84 %: ≈ 69 minutos al mes.

La distancia «en línea recta» entre dos puntos, la de la regla: la raíz de la suma de las diferencias al cuadrado, coordenada por coordenada.

Es el teorema de Pitágoras extendido a cualquier número de dimensiones. A diferencia de la similitud coseno, sí cambia si un vector es más largo que otro. Con vectores normalizados, las dos medidas ordenan a los vecinos igual, porque la distancia al cuadrado es 2 − 2 × coseno.

Ejemplo. Entre (4, 3) y (3, 4): diferencias 1 y −1; al cuadrado 1 y 1; suman 2; la raíz de 2 ≈ 1.41.

Cómo se reparten los valores de algo: qué valores aparecen y qué tan seguido. Dos listas con el mismo promedio pueden tener distribuciones muy distintas.

Se ve con un histograma. Las latencias casi siempre tienen una distribución con cola a la derecha: un montículo de requests rápidas y unas pocas muy lentas, porque hay un piso (el trabajo mínimo) pero no un techo. Comparar la distribución de los datos de hoy contra la del entrenamiento es como se detecta el drift.

Ejemplo. Cien requests de 50 ms, y la mezcla de 90 de 30 ms con 10 de 230 ms, tienen el mismo promedio, 50 ms; pero en la segunda, 10 de cada 100 pasan de 200 ms.

La forma de campana: muchos valores cerca del centro y cada vez menos hacia los lados, igual de los dos lados. Queda definida por su promedio y su desviación estándar.

Aparece cada vez que un número es la suma o el promedio de muchas piezas pequeñas e independientes: los altos y los bajos se compensan y el resultado se amontona al centro. Ese hecho se llama teorema del límite central, y es la razón de que una accuracy medida, una tasa de aceptación o la diferencia entre dos brazos tengan forma de campana. Regla 68–95–99.7: lo que cae a una, dos y tres desviaciones del centro. Los datos sueltos no tienen por qué ser normales (la latencia tiene una cola larga); lo que se vuelve normal es el promedio de muchos.

Analogía. Una tabla de Galton: canicas que caen rebotando en clavos, cada rebote a la izquierda o a la derecha al azar. Abajo se juntan en campana, porque llegar a una orilla pide que casi todos los rebotes vayan al mismo lado. Se rompe en que ahí todos los rebotes son iguales y de 50 %; en datos reales las piezas son distintas, y el resultado sigue siendo una campana mientras ninguna pieza sola domine.

Ejemplo. Mil exámenes de 1,000 fotos con un modelo que acierta 85 % forman una campana centrada en 85, con desviación de 1.1 puntos: ≈ 95 % de los resultados cae entre 82.7 y 87.3 (a dos desviaciones).

Cuánta sorpresa de más te llevas, en promedio, si te preparaste para la distribución Q y la realidad es P: la suma de p × ln(p ÷ q). Vale 0 solo si son iguales, y no es simétrica.

Se escribe KL(P ‖ Q) y el orden importa: pesa con las probabilidades de P, así que lo que más cuenta es lo que en la realidad pasa seguido y la referencia creía raro. Si Q le da 0 a algo que en P pasa, es infinita. Es la entropía cruzada menos la entropía de P, así que entrenar un clasificador con entropía cruzada es bajar una KL. Sumada en las dos direcciones es el PSI. Su prima simétrica es la divergencia de Jensen–Shannon: compara las dos contra su promedio M = (P + Q) ÷ 2, nunca es infinita y no pasa de ln 2 ≈ 0.693 (1 bit). Algunas librerías reportan su raíz cuadrada, la distancia de Jensen–Shannon.

Ejemplo. Categorías de C01 en octubre Q = (60 % ropa, 39 % calzado, 1 % juguetes) y en diciembre P = (55 %, 35 %, 10 %), números de ejemplo: KL(P ‖ Q) ≈ 0.145 y KL(Q ‖ P) ≈ 0.071. La suma, 0.216, es el PSI.

Un modelo con dos redes que convierten por separado dos tipos de cosas (consultas y productos, o usuarios y publicaciones) en vectores del mismo espacio. El parecido es el producto punto entre ellos.

Como cada lado se calcula por separado, los vectores del catálogo se calculan antes, en lote, y en cada consulta solo se calcula uno: eso permite buscar entre millones con un ANN. Es más rápido y menos preciso que un cross-encoder, que lee la consulta y el candidato juntos; por eso se combinan: dos torres para el retrieval (recuperación) y cross-encoder para el re-ranking (reordenar). Se entrena con aprendizaje contrastivo. Las dos torres se publican juntas, con la misma versión.

Ejemplo. En C08 de la Ronda, la torre de usuario calcula un vector de 128 números en cada visita al inicio de la app, y el índice que llenó la torre de publicaciones devuelve ≈ 500 candidatos de entre 100 M. En C07, el encoder tipo CLIP tiene una torre de imagen y una de texto.

Cuando los datos que llegan en producción dejan de parecerse a los del entrenamiento. Por eso el modelo puede empezar a fallar más aunque nadie lo haya tocado.

El modelo no se descompone: el mundo cambia a su alrededor. Llegan productos nuevos, cambian las modas, las cámaras de los celulares toman fotos distintas. Ojo: drift no siempre quiere decir que el modelo empeoró (con fotos mejor iluminadas hasta puede acertar más). Por eso el drift abre una investigación, y lo que decide si hay que reentrenar son las etiquetas nuevas.

Ejemplo. Salen modelos nuevos de tenis y los celulares toman fotos con otra luz: las fotos que llegan se parecen cada vez menos a las del entrenamiento, y el modelo acierta un poco menos cada mes. Una categoría nueva (como «bolsas» en el Dojo) es otra cosa: ahí el modelo ni siquiera tiene esa respuesta.

El programa que le permite al sistema operativo manejar un aparato, como la GPU. El de NVIDIA vive en la máquina, no en la imagen de tu contenedor, y su versión decide qué versiones de CUDA pueden correr.

El de NVIDIA tiene un módulo dentro del kernel de Linux (nvidia.ko) y bibliotecas para los programas (libcuda.so, y NVML, la que usa nvidia-smi). Un contenedor lo recibe montado desde la máquina (lo hace el NVIDIA Container Toolkit), y en Kubernetes el device plugin anuncia las GPUs del nodo. La regla: el driver tiene que ser al menos el que pide el CUDA de tu imagen; cualquier CUDA 12.x corre con un driver 525 o más nuevo, y 13.x con uno 580 o más. Ojo: el «CUDA Version» de la cabecera de nvidia-smi es el CUDA más nuevo que soporta el driver, no el de tu imagen.

Ejemplo. Un nodo con el driver 535 corre una imagen con CUDA 12.6, y su nvidia-smi dice «CUDA Version: 12.2». Una imagen de PyTorch para CUDA 13.0 falla en ese nodo con «driver too old».

Una traba contra el overfitting: al entrenar, apaga al azar una fracción de las neuronas en cada paso. Al responder no apaga nada.

Obliga a la red a repartir lo que sabe en lugar de depender de unas pocas neuronas. Las que quedan se multiplican para compensar (con la mitad apagada, por 2). Si el modelo se queda en modo entrenamiento en producción, la misma foto da respuestas distintas cada vez. La ResNet-50 estándar no tiene Dropout; muchos otros modelos sí.

Ejemplo. Con dropout de 0.5, una capa de 4 neuronas que saca 1, 2, 3 y 4 podría sacar al entrenar 2, 0, 6 y 0: la mitad apagada y el resto multiplicado por 2. Al responder saca 1, 2, 3 y 4.

El tipo de dato de un tensor: el formato en que están guardados todos sus números y, por lo tanto, cuántos bytes ocupa cada uno. Por ejemplo, torch.float32 (4 bytes) o torch.uint8 (1 byte).

Todos los números de un tensor comparten su dtype, y los bits se leen según él. PyTorch crea los tensores con decimales en float32 y los de enteros en int64; NumPy y Python usan FP64 para los decimales. La memoria de un tensor es su cantidad de números por los bytes de su dtype. Los errores típicos: mezclar dtypes (un float64 de NumPy contra un modelo en float32), etiquetas que no son int64 y cuentas con píxeles en uint8 que dan la vuelta.

Ejemplo. El tensor de la foto de Ana, [1, 3, 224, 224], ocupa 150,528 bytes en uint8, 301,056 en float16 y 602,112 en float32: los mismos números con otro dtype.

Dejar de entrenar cuando la pérdida o la métrica en validación deja de mejorar, y quedarse con el checkpoint de la mejor época.

Se mide la validación al final de cada época. Si no mejora en N épocas seguidas (la paciencia), se para y se recupera el mejor checkpoint. Evita seguir hacia el overfitting y ahorra GPU. Es una forma de regularización. Se decide con validación, nunca con el test.

Ejemplo. Validación 0.95, 0.88, 0.86, 0.87 y 0.89 en las épocas 3 a 7. Con paciencia 2, se para al final de la 7 y se usa la 5.

Un número que resume qué tan honesta es la seguridad de un modelo: agrupa las predicciones por confianza y promedia la distancia entre lo que dijo y lo que acertó, pesada por cuántas hay en cada grupo. 0 es perfecto.

Se calcula con datos que el modelo no vio: se parten las predicciones en grupos por confianza (por ejemplo, de 0.0 a 0.1, de 0.1 a 0.2…), en cada grupo se compara la confianza promedio con la fracción de aciertos y se suman las distancias, cada una multiplicada por la fracción de ejemplos del grupo. Un promedio que pasa puede esconder un grupo que no, por eso conviene mirar también la tabla. En la Ronda, el gate de C01 pide ECE ≤ 0.05 después de temperature scaling.

Ejemplo. 1,000 fotos en cuatro grupos: dijo 50 % y acertó 45 % (100 fotos), 70 % y 64 % (100), 90 % y 82 % (300), 99 % y 99 % (500). ECE = 0.10 × 0.05 + 0.10 × 0.06 + 0.30 × 0.08 + 0.50 × 0 = 0.035.

El efecto más chico que quieres que el experimento pueda ver con la potencia elegida. Se decide antes y por negocio: cuánto tiene que mejorar algo para que valga la pena.

Fija el tamaño de muestra: n crece con 1 ÷ MDE². Pedir la mitad de MDE cuesta 4 veces la muestra. Puede haber efectos más chicos que el MDE, pero el experimento los ve con menos potencia: uno de la mitad del MDE se detecta ≈ 3 de cada 10 veces.

Ejemplo. En C01 el MDE es 1 punto sobre una aceptación de 70 %: ≈ 33,000 publicaciones por brazo. Con 0.5 puntos serían ≈ 131,000.

Un caso del que ya sabes la respuesta: la entrada (lo que ve el modelo) junto con su etiqueta (la respuesta correcta).

Un modelo aprende de muchos ejemplos. En un dataset cada ejemplo es una fila: sus features y su etiqueta. A aprender de ejemplos que ya traen su respuesta se le llama aprendizaje supervisado.

Ejemplo. La foto de los tenis de Ana junto con «Calzado › Tenis» es un ejemplo. El dataset de septiembre de C01 trae casi 2 millones. En C09, un ejemplo es un pago con su respuesta: fue fraude o no.

El vector que produce un modelo para representar algo (una foto, una frase, un producto) de forma que las cosas parecidas queden cerca.

Lo produce una red ya entrenada: entra la foto o el texto y sale una lista de, por ejemplo, 512 números. Cada número por separado no significa nada que se pueda nombrar; lo que importa es la distancia entre vectores. Dos embeddings solo se pueden comparar si los produjo el mismo modelo, en la misma versión.

Analogía. Como las coordenadas de una ciudad en un mapa: ciudades cercanas tienen coordenadas parecidas. Se rompe en que un mapa tiene 2 ejes con nombre (latitud y longitud) y un embedding tiene cientos de ejes sin nombre.

Ejemplo. CLIP ViT-B/32 convierte una foto o un texto en 512 números; BERT-base convierte un texto en vectores de 768; la ResNet-50 de C01, justo antes de su última capa, produce 2,048.

La información de en qué lugar del texto está cada token. Hace falta porque la atención, por sí sola, mezcla un conjunto y no sabe el orden.

Una suma da lo mismo en cualquier orden: sin posiciones, «el perro muerde al cartero» y «el cartero muerde al perro» se mezclarían igual. El transformer original sumaba a cada embedding un vector fijo hecho con ondas (senos y cosenos); GPT-2 y el ViT aprenden un vector por posición; Llama usa RoPE, que gira la Q y la K de cada token un ángulo que crece con su posición, para que la calificación dependa de la distancia entre los dos tokens.

Ejemplo. En un ViT-B/16, a cada uno de los 197 tokens se le suma un vector aprendido que dice «soy el parche 37». En Llama 3, el giro de RoPE va dentro de cada cabeza de atención.

Un número sin decimales. En la computadora cada entero tiene un tamaño fijo en bits, y el tamaño le da un rango: un int8 va de −128 a 127; un int32, de −2,147,483,648 a 2,147,483,647.

Los enteros sin signo (uint) usan todos los bits para sumar: de 0 a 2ⁿ − 1. Los con signo (int) usan el complemento a dos: el primer bit vale negativo (−128 en un int8), y van de −2ⁿ⁻¹ a 2ⁿ⁻¹ − 1. Los mismos bits significan cosas distintas según el tipo: 1110 1100 es 236 como uint8 y −20 como int8. Si un resultado no cabe, hay overflow. En ML: uint8 para píxeles, int64 para etiquetas e ids de tokens (el entero por omisión de PyTorch), y int8 o int4 para pesos cuantizados.

Ejemplo. Un contador int32 de las fotos de C01, a ≈ 116 por segundo, llega a su tope en ≈ 214 días. Un int64 tardaría ≈ 2,500 millones de años.

Mostrarle al modelo muchos ejemplos con su respuesta correcta y ajustar sus parámetros, poco a poco, para que se equivoque menos.

El modelo adivina, se compara con la etiqueta correcta y mueve sus parámetros un poquito en la dirección que reduce el error. Eso se repite millones de veces. Es lento y caro, y se hace de vez en cuando, no con cada uso.

Ejemplo. En C01 el modelo se reentrena una vez al mes con las fotos nuevas del mes.

La sorpresa promedio de algo incierto, medida en bits: la suma de p × log2(1 ÷ p) sobre todos los resultados. Una moneda justa tiene 1 bit; un dado, 2.585.

Un resultado con probabilidad p trae log2(1 ÷ p) bits de sorpresa: lo seguro trae 0 y lo raro trae mucho. La entropía promedia esa sorpresa con el peso de cada resultado. Es máxima cuando todo es igual de probable (log2 de cuántos resultados hay) y vale 0 cuando uno es seguro. 2 elevado a la entropía dice «es como elegir al azar entre tantas opciones parejas». En ML aparece como la indecisión de una predicción (la entropía del softmax), dentro de la entropía cruzada con la que se entrena y en la divergencia kl. Con ln en vez de log2 se mide en nats (1 nat ≈ 1.44 bits).

Ejemplo. Una moneda 90/10: 0.9 × 0.152 + 0.1 × 3.322 ≈ 0.469 bits. Una foto de C01 con softmax (0.94, 0.03, 0.02, 0.01): 0.41 bits; una dudosa (0.40, 0.35, 0.15, 0.10): 1.80 bits, como dudar entre 3.5 opciones.

La pérdida más usada para clasificar: menos el logaritmo de la probabilidad que el modelo le dio a la respuesta correcta. Casi 0 si acierta con seguridad; muy alta si está seguro de otra cosa.

Para un ejemplo es −ln(p), donde p es la probabilidad de la respuesta correcta; para un batch, el promedio. Con dos respuestas (clic o no clic) se escribe −ln(p) si pasó y −ln(1 − p) si no, y se llama log loss. Castiga sin tope la seguridad equivocada, y por eso empuja al modelo a dar probabilidades honestas. Un modelo que reparte parejo entre K categorías tiene pérdida ln(K). Bajarla es lo mismo que hacer más probable lo que de verdad pasó.

Ejemplo. 94 % a la correcta: −ln(0.94) ≈ 0.062. 10 %: −ln(0.10) ≈ 2.30. Al azar entre 500 categorías: ln(500) ≈ 6.21. En C15, decir 0.35 % de clic para todo da una log loss de 0.02329.

Una pasada completa por el conjunto de entrenamiento: cada ejemplo se vio una vez.

Al empezar cada época se revuelven los ejemplos, para que los batches no sean siempre los mismos grupos. Al final de cada una se suele medir la validación: es lo que usa el early stopping para decidir si sigue.

Ejemplo. 50,000 fotos en batches de 64: 50,000 ÷ 64 = 781.25, así que son 782 pasos por época (el último batch trae solo 16 fotos). C01 entrena 8 épocas.

Que un modelo no le falle mucho más a un grupo de personas que a otro. Se revisa midiendo las mismas métricas por grupo, porque el promedio general puede esconder a un grupo donde el modelo falla.

Es obligatoria cuando el modelo decide sobre personas (crédito, contratación, identidad). Primero se elige qué error importa igualar: el recall (que a nadie se le escapen más los casos reales), los falsos positivos (que a nadie se le acuse más en falso) o la precision. Cuando los grupos tienen proporciones distintas de casos reales, no se pueden igualar todas a la vez (salvo en casos extremos, como un modelo que nunca se equivoca), así que elegir es una decisión de personas. Se mide con slices por grupo y, si el grupo es sensible, con cuidado de privacidad.

Ejemplo. En 2018, un estudio («Gender Shades») encontró que tres sistemas comerciales que adivinaban el género en fotos de caras se equivocaban en no más de 0.8 % de los hombres de piel clara y hasta en 34.7 % de las mujeres de piel oscura.

La pérdida más usada para predecir números: el promedio de los errores al cuadrado. Un error de 6 pesa 36; uno de 1, solo 1.

Para cada ejemplo, (predicción − respuesta)²; para el grupo, el promedio. Elevar al cuadrado quita el signo y castiga mucho más los errores grandes. El número que hace más chico el MSE es el promedio de las respuestas: un modelo entrenado con MSE aprende a predecir la media. Su raíz, el RMSE, vuelve a las unidades originales. Si el negocio necesita otra cosa, como un número que alcance 9 de cada 10 días, se usan otras pérdidas (las de cuantiles, en C14).

Ejemplo. Errores de +2, −1, −6 y +3 kg: (4 + 1 + 36 + 9) ÷ 4 = 12.5 kg²; la raíz, ≈ 3.5 kg. El error de 6 aporta el 72 % del total.

Cuánto se movería un número medido con una muestra si repitieras la medición con otra muestra al azar. Es la desviación estándar del resultado, no de los datos.

Para una proporción (una accuracy, una tasa de aceptación) vale √(p × (1 − p) ÷ n), donde p es la proporción y n cuántos datos tiene la muestra. Baja con la raíz de n: para la mitad del error hacen falta 4 veces los datos. Para la diferencia entre dos muestras independientes, las varianzas se suman: √(p₁(1 − p₁) ÷ n₁ + p₂(1 − p₂) ÷ n₂). Con él se arman los intervalos de confianza (≈ ±2 errores estándar) y las pruebas de hipótesis (p-value).

Ejemplo. Un modelo que saca 85 % en 1,000 fotos: √(0.85 × 0.15 ÷ 1,000) ≈ 0.0113, o 1.1 puntos. En el golden set de 50,000 fotos: 0.16 puntos.

Llevar features con rangos muy distintos (un monto en miles, una hora de 0 a 23) a una escala parecida. Lo más común es estandarizar: restar el promedio y dividir entre la desviación estándar.

z = (x − promedio) ÷ desviación estándar. Una feature estandarizada queda con promedio 0 y desviación 1, y z dice a cuántas desviaciones del promedio está cada valor. Ayuda a los modelos que suman features con pesos y aprenden con descenso de gradiente, y a los que miden distancias; a los árboles de decisión les da igual. El promedio y la desviación se calculan solo con train y se guardan con el modelo: al servir se usan los mismos, o hay leakage al entrenar y diferencias silenciosas al servir. En imágenes, esta misma cuenta por canal se llama normalización.

Ejemplo. Cinco montos de train: 20, 30, 35, 40 y 50 dólares. Promedio 35 y desviación 10. El de 50 queda en z = (50 − 35) ÷ 10 = 1.5; un pago nuevo de 90, en 5.5: muy lejos de lo normal.

Una cuenta rápida con números redondos para saber el orden de magnitud de algo (requests por segundo, máquinas, bytes, dólares) antes de construirlo.

Se parte de pocos datos y de supuestos dichos en voz alta, se encadenan multiplicaciones y divisiones con las unidades a la vista y se redondea. No busca exactitud: busca no equivocarse por 10 y llevar a una decisión. Lo que depende del hardware o del negocio se marca como «a medir» y se mide con una prueba de carga.

Ejemplo. La de C01: 10 M fotos al día → 116 req/s → 350 en el pico → 500 de diseño → 2 T4 con N+1 → ≈ US$768 al mes de GPUs, y 3 GB de logs al día.

La respuesta correcta de un ejemplo: la que el modelo debería dar. En C01, la categoría real de una foto.

Muchas veces la pone una persona a mano, y por eso cuesta tiempo y dinero. Con etiquetas malas, el modelo aprende mal, aunque todo lo demás esté perfecto.

Ejemplo. Una foto de unos tenis con la etiqueta «Calzado › Tenis». En C01 las etiquetas salen de tres lugares: la categoría que eligió quien vende, las correcciones de moderadores y unas 5 mil fotos al mes revisadas a mano.

El proceso de ponerle a cada ejemplo su respuesta correcta: quién etiqueta, con qué guía, cómo se revisa la calidad y cuánto cuesta. La etiqueta es el dato más caro por unidad.

Lo hacen proveedores, un equipo propio, expertos para los casos difíciles, o la gente dentro de su trabajo (moderadores, inspectores). Se apoya en una guía escrita y versionada, con ejemplos y contraejemplos de cada clase, los casos límite decididos por escrito y una salida para «no sé». La calidad se mide con doble anotación: una parte la etiquetan dos personas, se mide su acuerdo (kappa de cohen) y un experto decide los desacuerdos. Qué ejemplos etiquetar lo decide el active learning.

Ejemplo. C01: ≈ 5,000 fotos al mes a US$0.05–0.10 cada una, con 10 % de doble anotación: ≈ US$250–500 al mes, más ≈ US$25–50 por la doble. El golden set, 50,000 fotos con doble anotación, cuesta ≈ US$5–10 mil una sola vez.

El ciclo que, en un solo hilo, reparte turnos entre muchas tareas (corrutinas): corre una hasta que llega a un punto de espera (un await), la anota entre las que esperan y pasa a la siguiente que está lista. El sistema operativo le avisa cuándo llegó lo que cada una esperaba.

Es el corazón de async (programación asíncrona). Lleva dos listas, las tareas listas y las que esperan (bytes de la red, un temporizador, la respuesta de otro servicio), y le pide al sistema operativo que le avise cuando algo llegue: en Linux, con epoll; en macOS, con kqueue. Como corre en un solo hilo, todo lo que pasa entre dos await ocupa al loop. Un trabajo CPU-bound o una llamada bloqueante dentro de una corrutina lo congela, y ninguna otra request avanza, ni los health checks. Con FastAPI y uvicorn hay un event loop por proceso.

Ejemplo. En C01, decodificar un JPEG dentro de una ruta async def (≈ 6 ms en promedio, de 40 a 80 ms con una foto web de 12 MP sin draft mode) detiene al loop todo ese tiempo. A 100 requests por segundo, en 60 ms llegan 6 requests que esperan sin avanzar.

Datos escondidos dentro de una foto: el modelo de la cámara, la fecha, cómo se sostenía el teléfono y, a veces, las coordenadas GPS de dónde se tomó.

Importa por dos razones. La orientación: muchos teléfonos guardan los píxeles «acostados» y anotan en EXIF que hay que girarlos; si no lo aplicas, el modelo ve la foto de lado. Y la privacidad: el GPS puede revelar dónde vive alguien, así que no se guarda en logs y se quita de las copias.

Ejemplo. Orientación 6 significa «gira 90° a la derecha para verla bien».

Un solo número que junta precision y recall con su media armónica. Sale bajo si cualquiera de las dos es mala.

F1 = 2 × precision × recall / (precision + recall), o directo de la tabla: 2·TP / (2·TP + FP + FN). No usa los verdaderos negativos, así que la clase grande no lo infla. No sirve para elegir el umbral cuando los errores tienen costos muy distintos: ahí se decide con el costo de cada uno.

Ejemplo. Precision 66.7 % y recall 80 %: F1 = 2 × 0.667 × 0.80 / 1.467 ≈ 0.727. El promedio simple daría 73.3 %.

Cuántas veces el promedio llega en el momento de más tráfico. Con él se pasa del promedio al pico, que es para lo que se compran las máquinas.

Si la hora pico lleva una fracción f del tráfico del día, el factor es 24 × f: con 1/8, 3. Suele estar entre 2 y 5 en apps que usan personas en una zona horaria, y cerca de 1 en un proceso que trabaja parejo las 24 horas. Al pico se le suma un margen (× 1.3 a 1.5) para picos raros y crecimiento, y se redondea hacia arriba: el pico de diseño.

Ejemplo. C01 supone 3: 116 × 3 ≈ 350 req/s; con un margen de ≈ 1.4 diseña para 500. Una notificación del Hot Sale podría llevarlo a ≈ 1,670 durante un minuto.

Fallas que llegan juntas porque tienen la misma causa: el mismo deploy malo en todas las réplicas, una zona entera que se cae, una dependencia que todas comparten. Rompen la independencia, y con ella la cuenta de la redundancia.

Las causas típicas: el mismo error o la misma configuración aplicados a todas las réplicas a la vez; un dominio de falla compartido (la misma máquina, rack, zona o región); una dependencia común (la misma base de datos, caché o certificado); la sobrecarga que se contagia cuando una réplica cae y la otra no aguanta el doble, y los reintentos en manada. La defensa no es agregar réplicas iguales, sino que la causa no llegue a todas a la vez: cambios de a poco y una zona a la vez (canary), planes B que no compartan nada y ensayos de falla programados.

Analogía. Dos despertadores eléctricos en el mismo enchufe: cada uno falla poco, pero un apagón los apaga juntos. Lo difícil en un sistema es que el «enchufe» casi nunca se ve.

Ejemplo. Triton en dos zonas al 99.5 % da 99.9975 % (≈ 1 minuto al mes). Si un deploy malo tumba las dos zonas el 0.1 % del tiempo, queda en ≈ 99.90 % (≈ 44 minutos): 43 de esos minutos son de la causa común.

Lo que hace el sistema cuando el modelo no responde a tiempo o falla: una respuesta más simple que no depende de él, para que la persona pueda seguir.

Todo lo que está en el camino online falla alguna vez. El fallback convierte esa falla en una molestia chica en vez de una pantalla trabada: el sistema se degrada, pero no se cae. Va junto con un tiempo máximo de espera (timeout): pasado ese tiempo, se deja de esperar y se usa el plan B.

Ejemplo. En C01, si la API no contesta en 300 ms, el marketplace le muestra a Ana el selector de categorías para elegirla a mano. En el caso de fraude de la Ronda, si el modelo no responde, deciden reglas fijas.

Un «no» equivocado: sí era de la clase que buscas y el modelo no lo vio. Algo que se le escapó.

Bajar los falsos negativos sube el recall, normalmente a cambio de más falsos positivos. Qué error duele más se decide con el negocio, y eso fija el umbral.

Ejemplo. En C01: Ana sube unos tenis y «Tenis» no aparece entre las sugerencias; tiene que buscar la categoría a mano. En fraude, un falso negativo es una compra robada que pasó.

Un «sí» equivocado: el modelo dijo que era de la clase que buscas y no lo era. Una falsa alarma.

Cuánto cuesta depende del negocio. Bajar los falsos positivos sube la precision, normalmente a cambio de más falsos negativos.

Ejemplo. En C01: Ana sube unas botas y la app le sugiere «Tenis». Si lo acepta, la publicación queda mal clasificada y moderación la tiene que mover.

Cuando un request llama a N servicios a la vez y espera a todos. Basta con que uno tarde para que el request tarde: si cada uno es lento con probabilidad p, el request lo es con 1 − (1 − p)^N.

Pasa en buscadores con el índice repartido en pedazos, en páginas armadas con muchos bloques y en sistemas con muchos servicios chicos. Con N servicios que superan su p99 el 1 % de las veces, el request toca la cola con probabilidad 1 % si N = 1, ≈ 9.6 % si N = 10 y ≈ 63.4 % si N = 100: el p99 de cada pieza se vuelve la latencia típica del conjunto. Para que el 99 % de los requests sean rápidos, cada servicio tiene que cumplir su percentil 0.99^(1/N) ≈ 1 − 0.01 ÷ N: con 10, su p99.9. Las salidas: menos servicios, colas más cortas, responder con lo que llegó a tiempo o mandar una copia a otra réplica (hedging).

Analogía. Una mesa de restaurante donde nadie empieza a comer hasta que llegan todos los platos: basta con que uno se retrase para que la cena entera se retrase, y con muchos platos casi siempre hay uno que se retrasa.

Ejemplo. En C11, cada pregunta busca por palabras y por significado al mismo tiempo y espera a las dos búsquedas: un fan-out de dos. La Ronda (M02) advierte que con 10 servicios en paralelo, ≈ 10 % de los requests toca el p99 de alguno.

Cada dato de la entrada que el modelo usa para decidir. En una tabla, una columna; en una foto, cada píxel.

En datos tabulares las features las elige una persona (el monto, el giro del comercio, la hora); a eso se le llama feature engineering. Pueden ser números o categorías, y las categorías hay que convertirlas en números (codificación). En imágenes la entrada son los píxeles crudos y el modelo arma por dentro sus propias features útiles. Una feature solo sirve si existe en el momento de predecir; si no, es leakage.

Ejemplo. Un pago de C09: monto US$45, giro «videojuegos», hora 03:12 y 4 intentos de la tarjeta en el último minuto. Son cuatro features.

Poner unos cuantos ejemplos resueltos dentro del prompt para que el modelo copie el patrón, sin cambiar ni un peso. Sin ejemplos se llama zero-shot.

No es entrenamiento: los ejemplos solo cambian el texto que el modelo tiene que continuar, y lo más probable es seguir el formato que ve. Lo popularizó el artículo de GPT-3 (OpenAI, 2020), «Language Models are Few-Shot Learners». Cada ejemplo cuesta tokens en cada request; si son fijos y van al principio, el prefix caching evita recalcularlos.

Ejemplo. Para sacar marca, talla y color de una publicación, se ponen dos publicaciones con su JSON ya resuelto y al final la nueva: el modelo responde con el mismo formato.

La cuadrícula chica de pesos que recorre la foto en una convolución. Cada filtro busca un patrón: un borde, un cambio de color, una textura.

Sobre una entrada de varios canales, un filtro de 3 × 3 mira todos a la vez: sobre una foto de color es de 3 × 3 × 3, 27 pesos más 1 sesgo. Sus pesos los aprende el entrenamiento; nadie los escribe a mano.

Ejemplo. Una capa de 64 filtros de 3 × 3 sobre una foto de color: 64 × (27 + 1) = 1,792 parámetros.

Seguir entrenando un modelo preentrenado con tus propios datos, con un learning rate chico para no borrar lo que ya sabía.

Se puede congelar el backbone y entrenar solo la cabeza (rápido, sirve con pocos datos) o entrenar todo con learning rate chico (más lento, suele dar mejor resultado con muchos datos). Es la forma más común de transfer learning.

Ejemplo. En la Ronda, el fine-tuning de C01 usa learning rate 0.0003, 8 épocas y batches de 64, y cabe en una GPU en horas. Con el backbone congelado, solo se moverían 1,024,500 de los 24,532,532 parámetros.

Un número con decimales que ocupa 32 bits (4 bytes). Es el tipo por defecto en PyTorch para entrenar y, muchas veces, para servir un modelo.

Guarda unas 7 cifras significativas y llega hasta ≈ 3.4 × 10³⁸. Ocupa 4 veces más que uint8: el tensor de la foto de Ana pesa 602 KB en float32 y 151 KB en uint8. Hay tipos más chicos, como float16 (2 bytes), que se ven en la lección sobre cómo guarda números una computadora.

Ejemplo. 150,528 números × 4 bytes = 602,112 bytes ≈ 602 KB (588 KiB).

Una operación con números decimales: una suma o una multiplicación en punto flotante. Contar FLOPs dice cuánto trabajo pide un cálculo, sin importar en qué máquina corra.

El plural se escribe FLOPs, con s minúscula, y es una cantidad. No lo confundas con FLOPS, con S mayúscula, que es una velocidad: FLOPs por segundo (ver TFLOPS). Una multiplicación con su suma, una MAC, son 2 FLOPs, así que multiplicar una matriz de n × k por una de k × m cuesta 2 × n × m × k FLOPs. Se usan los prefijos de siempre: MFLOPs (millones), GFLOPs (miles de millones), TFLOPs (billones, 10¹²). Ojo: muchos artículos y tablas llaman «FLOPs» a lo que en realidad son MACs; antes de comparar dos números, revisa cuál cuenta cada uno.

Ejemplo. La ResNet-50 de C01 hace ≈ 4.1 mil millones de MACs por foto: ≈ 8.2 GFLOPs. Un LLM hace ≈ 2 FLOPs por parámetro por cada token: Llama 3 8B, con 8.03 mil millones de parámetros, ≈ 16 GFLOPs por token.

Pasar una entrada por el modelo, de principio a fin, hasta obtener su respuesta. Es lo único que hace la inferencia; al entrenar es la primera mitad de cada paso.

Al entrenar, además de la respuesta, se guardan los resultados intermedios de cada capa (las activaciones), porque la backpropagation los necesita. Por eso entrenar ocupa mucha más memoria que hacer inferencia.

Ejemplo. En la red de la lección, con x = 2, w1 = 0.5 y w2 = 2: z = 1, ReLU(1) = 1, y = 2 y la pérdida (2 − 6)² = 16. Esos valores intermedios se usan después para los gradientes.

Un número de punto flotante de 16 bits (2 bytes): 5 de exponente y 10 de mantisa. Guarda ≈ 3 cifras y su máximo es 65,504: lo que pase de ahí se vuelve infinito.

Ocupa la mitad que FP32 y los tensor cores de las GPUs lo multiplican muchísimo más rápido: una T4 hace ≈ 65 × 10¹² operaciones por segundo en FP16 contra ≈ 8.1 × 10¹² en FP32. Es el formato normal para servir CNNs, como el engine de TensorRT de C01. Su debilidad es el rango: por arriba se desborda en 65,504 (exponenciales, cuadrados, activaciones atípicas de un transformer) y por abajo, lo menor que ≈ 6 × 10⁻⁸ se vuelve 0. Para entrenar con él hace falta precisión mixta.

Ejemplo. La ResNet-50 de C01 pesa ≈ 49 MB en FP16 contra ≈ 98 MB en FP32. En FP16, 1 + 0.0001 da 1, 2,048 + 1 da 2,048 y e¹² da infinito.

Números de punto flotante de 1 byte, en dos versiones: E4M3 (4 bits de exponente y 3 de mantisa, máximo 448) y E5M2 (5 y 2, máximo 57,344). Se usan con una escala por tensor, sobre todo en LLMs.

Con tan pocos bits, cada tensor lleva una escala en FP32 que lo acomoda al rango antes de convertirlo. E4M3 sirve para pesos y activaciones; E5M2, con más rango, para gradientes. Como conserva un exponente, aguanta mejor los valores atípicos que INT8. Existe en las GPUs Ada (L4, L40S) y Hopper (H100), no en la A100, la A10G ni la T4. También se usa para el KV cache: de 320 a 160 KiB por token en un modelo de 70B.

Ejemplo. C10 sirve su modelo de 70,600 millones de parámetros en FP8: ≈ 70.6 GB de pesos repartidos entre 2 H100, contra ≈ 141 GB en BF16.

Cuántos frames de video hay en cada segundo. El tiempo entre uno y el siguiente es 1,000 ÷ fps milisegundos.

Dice cuánto trabajo hay: fps × cámaras es lo que el sistema tiene que decodificar y analizar cada segundo. Y dice cada cuánto «mira» el modelo: a 5 fps pasan 200 ms entre frames. Es una perilla distinta de la resolución: los fps dicen cada cuánto miras; la resolución, cuánto detalle ves cada vez.

Ejemplo. En un sitio de C02, 40 cámaras a 5 fps son 200 frames por segundo; a 15 fps serían 600.

Cada una de las fotos que forman un video. Para un modelo, cada frame es una imagen como cualquier otra: una cuadrícula de píxeles.

Un video es una sucesión de frames que pasan tan rápido que se ven como movimiento. Los códecs como H.264 no guardan cada frame completo: guardan uno completo cada tanto (el I-frame) y, del resto, solo lo que cambió. Por eso el video se comprime mucho más que las fotos sueltas. Para analizarlo, cada frame se decodifica y se prepara como una foto, decenas de veces por segundo y por cámara.

Ejemplo. Un frame 1080p (1920 × 1080) decodificado en RGB ocupa 1920 × 1080 × 3 ≈ 6.2 MB.

Una regla que a cada entrada le asigna exactamente una salida. Un modelo es una función: entran números (una foto, una tabla) y salen números.

La de la escuela, f(x) = 2x + 1, da 7 si entra 3, y lo vuelve a dar cada vez que entra 3. Un modelo es una función enorme: su forma la elige una persona (la arquitectura) y sus números internos, los parámetros, los ajusta el entrenamiento. Con los parámetros fijos, la misma entrada da la misma salida.

Ejemplo. precio = −300 × años + 1,500 es una función de una entrada: con 2 años da 900 pesos. La ResNet-50 de C01 es una función de 150,528 números a 500.

Escribir de un token a la vez: el modelo predice el siguiente token, lo agrega al texto y vuelve a predecir con el texto ya alargado.

Por eso un LLM lee rápido y escribe lento. Leer el prompt (el prefill) se hace de una sola pasada, con todos los tokens en paralelo. Escribir (el decode) son tantas pasadas como tokens tenga la respuesta, una detrás de otra, y en cada una se leen todos los pesos del modelo. Termina cuando el modelo elige un token especial de fin o se llega al límite de tokens.

Ejemplo. Una respuesta de 250 tokens son 250 pasadas del modelo. Si cada una tarda 40 ms, el decode dura ≈ 10 segundos.

Que el modelo acierte en ejemplos nuevos que nunca vio, no solo en los de su entrenamiento. Es lo único que importa en producción.

Un modelo puede equivocarse muy poco en sus fotos de entrenamiento y mucho en las nuevas: memorizó en lugar de aprender (overfitting). La generalización solo se mide con fotos que el modelo no usó para aprender: el set de validación, el de prueba o el golden set.

Analogía. El estudiante que entendió el tema contesta bien un examen con preguntas nuevas; el que memorizó el examen de práctica, no. Se rompe en que el modelo no «entiende» como una persona: generalizar solo quiere decir que acierta en fotos nuevas.

Ejemplo. Un modelo saca 99 % en sus fotos de entrenamiento y 70 % en fotos nuevas: memorizó. Otro saca 88 % y 85 %: generaliza mucho mejor, aunque su número de entrenamiento sea más bajo.

El candado global del intérprete de Python (CPython): dentro de un proceso, solo el hilo que lo tiene puede ejecutar código de Python. Por eso los hilos sirven para esperar varias cosas a la vez, pero no para calcular en paralelo con Python puro.

Un hilo suelta el GIL cuando espera I/O (la red, el disco, un sleep), cuando entra a código en C que lo suelta (Pillow al decodificar, NumPy en sus operaciones grandes, PyTorch dentro de cada operación) y, si calcula sin parar, a la fuerza cada 5 ms, para que otro tenga turno. Existe porque CPython lleva en cada objeto la cuenta de cuántos lo usan, y esa cuenta se corrompería si dos hilos la cambiaran a la vez. El síntoma típico es un proceso con la CPU clavada en el 100 % de un núcleo y los demás libres. Para calcular en paralelo con Python puro se usan varios procesos (multiproceso), cada uno con su GIL. Desde Python 3.13 existe, como experimento, una versión sin GIL (free-threaded), con soporte oficial desde la 3.14, pero la que se instala por omisión todavía lo tiene.

Analogía. Una reunión con un solo micrófono: muchos pueden estar leyendo, pensando o esperando un correo al mismo tiempo, pero solo habla quien tiene el micrófono. Se rompe en dos cosas: el moderador se lo quita cada 5 ms a quien no lo suelta, y algunos (las librerías en C) pueden trabajar sin hablar, sin necesitar el micrófono.

Ejemplo. Dos hilos que calculan en Python puro usan, juntos, un solo núcleo; dos procesos usan dos. Dos hilos que esperan 0.3 s cada uno terminan juntos, en 0.3 s.

Un conjunto de evaluación de la mejor calidad: etiquetado con cuidado por personas, congelado y que jamás se usa para entrenar. Es la regla fija con la que se comparan los modelos.

Congelado quiere decir que no cambia: dos modelos de meses distintos se examinan con exactamente las mismas fotos, así que la diferencia es del modelo y no del examen. Si hay que cambiarlo (porque llegaron categorías nuevas), se hace una versión nueva y se vuelve a examinar ahí al modelo que está en producción. Cada dataset nuevo se revisa por hash contra él, para que ninguna de sus fotos se cuele al entrenamiento.

Ejemplo. En C01: ≈ 50 mil imágenes, cada una etiquetada por dos personas, con al menos ≈ 50 por categoría y repartidas entre fotos de celular y de web. Cuesta ≈ US$5–10 mil, una sola vez.

Un chip con miles de núcleos sencillos que hacen la misma operación sobre muchos números a la vez. Nació para dibujar gráficos y hoy hace casi todo el entrenamiento de modelos y mucha de la inferencia.

Entrenar y responder es, casi todo, multiplicar y sumar tablas enormes de números: justo lo que una GPU hace en paralelo. Tiene su propia memoria, la VRAM, y solo calcula con lo que está ahí. Además de sus núcleos normales trae tensor cores, núcleos especiales para multiplicar tablas de números, sobre todo en formatos de 16 bits o menos.

Ejemplo. La T4 con la que C01 sirve su modelo tiene 2,560 núcleos CUDA, 320 tensor cores y 16 GB de VRAM. El fine-tune mensual de C01 tarda unas 3 a 4 horas en una GPU; en CPU, de días a semanas.

Un truco para ahorrar memoria: varias cabezas de Q comparten la misma K y la misma V, así que el KV cache guarda menos vectores por token.

Con atención multi-cabeza completa, cada cabeza de Q tiene su K y su V. Con GQA (Ainslie y otros, 2023), las cabezas de Q se agrupan y cada grupo comparte una sola K y una sola V. Casi no cambia la calidad y divide el KV cache entre el tamaño del grupo.

Ejemplo. Llama 3 8B tiene 32 cabezas de Q y 8 juegos de K y V (grupos de 4): 128 KiB de KV cache por token. Sin GQA serían 512 KiB.

Para cada parámetro (cada «perilla») del modelo, hacia dónde y qué tan rápido cambia la pérdida si lo mueves un poquito. Es una lista con un número por parámetro.

El signo dice la dirección: negativo quiere decir que subir esa perilla baja la pérdida. El tamaño dice qué tan empinado está. Se calcula con backpropagation y se usa en el descenso de gradiente: cada perilla se mueve en contra de su gradiente.

Ejemplo. Una sola perilla w, con pérdida 36 cuando w = 0 y 35.76 cuando w = 0.01: bajó 0.24 por cada 0.01, así que el gradiente es ≈ −24.

Cuando el gradiente, al viajar hacia atrás por muchas capas, se multiplica una y otra vez por números menores que 1 y casi desaparece, o por números mayores que 1 y se vuelve enorme.

La backpropagation multiplica una sensibilidad por capa. Si se apaga, las primeras capas casi no aprenden; si explota, los pasos son gigantes y aparece NaN. Se combate con la ReLU, buena inicialización de las perillas, BatchNorm, las conexiones residuales de la ResNet, el warmup y recortando el gradiente (gradient clipping).

Ejemplo. 20 capas que multiplican por 0.5: 0.5²⁰ ≈ 0.00000095. Por 1.5: 1.5²⁰ ≈ 3,325. Un gradiente (30, 40) mide 50; recortado a tamaño 1 queda (0.6, 0.8).

Memoria de alto ancho de banda: capas de memoria apiladas, pegadas al chip de la GPU y conectadas con muchísimos cables. Es la VRAM de las GPUs grandes (A100, H100, H200) y les da terabytes por segundo.

Cada pila de HBM se conecta con 1,024 cables, más lentos que los de la GDDR pero muchísimos más: la H100 SXM usa 5 pilas, 5,120 cables a ≈ 5.2 Gb/s, y llega a 3,350 GB/s. La GDDR6 de las GPUs medianas (T4, L4, A10G) va en chips aparte, alrededor de la GPU: la T4 tiene 256 cables a 10 Gb/s, 320 GB/s. El ancho de banda es cables × velocidad de cada cable ÷ 8. La HBM es cara y difícil de fabricar, así que se usa donde el ancho de banda vale el precio: en el decode de un LLM, que es memory-bound, los tokens por segundo crecen casi en proporción a los GB/s. Generaciones: HBM2 (A100 de 40 GB), HBM2e (A100 de 80 GB y H100 en tarjeta PCIe), HBM3 (H100 SXM) y HBM3e (H200).

Ejemplo. La A100 de 40 GB: 5 × 1,024 cables a ≈ 2.43 Gb/s ≈ 1,555 GB/s. Con Llama 3 8B en BF16 (≈ 16 GB), su techo es ≈ 97 tokens por segundo, contra ≈ 19 en la GDDR6 de una L4.

Una línea de ejecución dentro de un proceso: el punto del código por donde va el programa. Cada hilo lleva su propia cuenta de en qué va y comparte la memoria con los otros hilos del mismo proceso.

Todo proceso nace con un hilo y puede crear más, para hacer varias cosas a la vez sin copiar memoria. El planificador del kernel turna los hilos en los núcleos, y cada cambio es un cambio de contexto. Un hilo puede estar corriendo, listo (esperando turno) o bloqueado (esperando la red, el disco o un candado, sin gastar CPU). Compartir memoria tiene un riesgo: dos hilos que cambian el mismo dato pueden perder actualizaciones (una condición de carrera), y por eso existen los candados (locks). En CPython, el GIL deja ejecutar Python a un solo hilo a la vez.

Analogía. Varios cocineros en la misma cocina: comparten la mesa y los ingredientes, así que se coordinan rápido, pero pueden agarrar el mismo tazón. Se rompe en que un cocinero ve lo que hace el otro; dos hilos no se enteran de que chocaron.

Ejemplo. El gateway de C01 tiene un hilo que atiende las requests y un threadpool que decodifica fotos, dos a la vez (PREPROCESS_CONCURRENCY=2), todo dentro del mismo proceso.

Una decisión que tomas tú antes de entrenar y que el entrenamiento no cambia: el learning rate, el tamaño del batch, cuántas épocas, el optimizador.

Los parámetros los ajusta el entrenamiento y son millones; los hiperparámetros los eliges tú y son unos cuantos. Se eligen probando y comparando en validación, nunca en el test.

Ejemplo. C01: Adam, lr 3e-4, batch 64, 8 épocas.

La suposición de que no hay ningún efecto: que A y B son igual de buenos y que cualquier diferencia es ruido. La prueba calcula qué tan raros serían los datos si fuera cierta.

Se escribe H0 («hache cero»). Funciona como la presunción de inocencia: se supone, y solo se rechaza si los datos serían muy raros bajo ella (un p-value menor que la significancia). No rechazarla no prueba que sea cierta: puede que el efecto exista y que la muestra no alcanzara para verlo (falta de potencia).

Ejemplo. En el A/B de C01, H0 dice «el modelo nuevo no cambia la tasa de aceptación». Si fuera cierta, ver 70.0 % contra 71.0 % con 33,000 por brazo pasaría ≈ 0.5 % de las veces: se rechaza.

Una gráfica de barras de una distribución: partes el rango en intervalos (buckets), cuentas cuántos valores caen en cada uno y dibujas una barra por intervalo.

En monitoreo, un histograma no es solo una gráfica: es la forma de guardar latencias. Cada copia del servicio lleva un contador por bucket y suma 1 donde cae cada request. Los contadores se suman entre copias y entre ventanas, y con ellos se estiman los percentiles. Prometheus los guarda acumulados, con la etiqueta le («menor o igual»).

Ejemplo. El servicio de C01 cuenta cada request en buckets con bordes de 10 ms a 2.5 s (10, 25, 50, 75, 100, 150, 200, 300, 500, 1,000 y 2,500 ms), más uno para lo que pasa de 2.5 s.

Un índice de vecinos aproximados muy usado: conecta cada vector con unos cuantos vecinos y busca saltando de vecino en vecino hacia la consulta, con niveles de atajos para llegar rápido.

Arriba hay pocos puntos unidos por saltos largos; abajo, todos los puntos con caminos cortos. La búsqueda empieza arriba, baja de nivel y termina con pasos finos, así que el trabajo crece muy despacio con el tamaño del catálogo (como log N). Sus perillas: M, cuántos vecinos guarda cada punto (más recall y más memoria), y ef_search, cuántos candidatos mantiene mientras busca (más recall y más latencia). Vive en memoria y borrar de él es caro. Lo propusieron Malkov y Yashunin en 2016.

Analogía. Manejar a otra ciudad: autopista hasta la ciudad correcta y luego calles hasta la puerta. Se rompe en que HNSW no lleva mapa: en cada punto solo ve a sus vecinos, y por eso a veces se queda con uno que no es el más cercano de todos.

Ejemplo. En C07 de la Ronda, con M = 32 el grafo guarda hasta 64 vecinos por vector en el nivel de abajo: 64 × 4 bytes = 256 bytes; para 100 M vectores, ≈ 25.6 GB además de los vectores.

Todo lo que un programa lee o escribe fuera de su CPU y su memoria: el disco, la red, otro servicio, la GPU. Comparado con calcular, tarda muchísimo, y mientras llega, el programa espera.

Leer un archivo, recibir los bytes de una foto, llamar a otro servicio y esperar su respuesta: todo es I/O. Los tiempos van de ≈ 0.1 ms (un SSD, la red dentro del centro de datos) a segundos (la respuesta completa de un LLM), contra ≈ 100 ns de leer la RAM. Por eso un servidor pasa casi todo su tiempo esperando: un trabajo que se la pasa esperando I/O es I/O-bound. Mientras espera, el programa puede bloquearse o, con async (programación asíncrona), soltar el turno para que avancen otras tareas.

Ejemplo. En C01, de los ≈ 50 ms que dura en promedio una request en el gateway, la CPU trabaja ≈ 6 a 7. Casi todo lo demás es I/O y esperar turno: recibir la foto y esperar a Triton, ≈ 10 ms de ida y vuelta.

Un trabajo que tarda porque espera (la red, el disco, otro servicio), no porque calcule: mientras tanto, la CPU casi no trabaja. Se acelera esperando varias cosas a la vez, no con más CPU.

Un gateway que reenvía requests, un servicio que llama a otros o un script que descarga miles de fotos pasan casi todo su tiempo en I/O. Se reconoce porque tarda, pero la CPU está baja. Se acelera encimando las esperas: con async (programación asíncrona) o con varios hilos, que en Python sí sirven aquí porque mientras esperan sueltan el GIL. Una CPU más rápida casi no lo cambia.

Ejemplo. El gateway del LLM de C10 gasta unos milisegundos de CPU por request y espera ≈ 10.5 s a que el modelo termine de generar: ≈ 99.9 % del tiempo es espera.

Dos eventos son independientes si saber que pasó uno no cambia la probabilidad del otro. Es lo que permite multiplicar sus probabilidades.

Casi todas las cuentas de confiabilidad la suponen: el fan-out, la disponibilidad en serie y la redundancia en paralelo. Se cumple más o menos cuando las causas son distintas (el disco de una máquina y el de otra). Se rompe cuando hay una causa compartida: la misma versión en todas las réplicas, la misma zona, la misma base de datos; eso es una falla correlacionada. No es lo mismo que «excluyentes»: dos eventos excluyentes, que no pueden pasar juntos, nunca son independientes si los dos pueden pasar, porque si pasa uno el otro ya tiene probabilidad 0.

Ejemplo. Dos réplicas de C01 en zonas distintas, cada una con sus propias fallas de hardware, son casi independientes: que se caiga la de la zona A no hace más probable que se caiga la de la B. Si las dos reciben el mismo deploy malo, dejan de serlo.

Una estructura de datos que guarda millones de vectores ya organizados (en grupos o en un grafo) para encontrar los más cercanos a uno nuevo sin revisarlos todos.

Se construye antes, sin prisa, y se consulta en milisegundos. Los más usados, como HNSW, viven en la memoria: 100 millones de vectores de 512 números pesan ≈ 205 GB en float32. Lo ofrecen librerías (FAISS), bases de datos vectoriales y motores de búsqueda (OpenSearch k-NN). Cada uno trae perillas que cambian velocidad, memoria y recall.

Ejemplo. En C07 de la Ronda: un índice HNSW con los vectores guardados en int8 (51.2 GB) más el grafo (≈ 25.6 GB), partido en 4 pedazos.

Usar un modelo ya entrenado para responder sobre un caso nuevo. Los parámetros no cambian: el modelo solo calcula.

Es el otro momento en la vida de un modelo, después del entrenamiento. Cada respuesta que da es una predicción. Es rápida y pasa todo el tiempo: es lo que hace el modelo en producción.

Ejemplo. Cada vez que alguien sube una foto al marketplace de C01, el modelo hace una inferencia. Son millones al día.

Los valores con que empiezan los pesos de una red antes de entrenar: al azar y chiquitos, con un tamaño que depende de cuántas entradas suma cada neurona.

No pueden empezar todos iguales, ni en cero: las neuronas de una capa calcularían lo mismo, recibirían la misma culpa y seguirían siendo gemelas para siempre. Y el tamaño importa: pesos un poco grandes hacen que los números exploten capa tras capa, y un poco chicos, que se apaguen. Con ReLU se usa la regla de He: desviación estándar √(2 ÷ entradas). PyTorch inicializa cada capa al crearla; en un fine-tuning, solo la cabeza nueva empieza al azar.

Ejemplo. Una convolución de 3 × 3 sobre 64 canales suma 576 entradas por neurona: sus pesos empiezan con desviación √(2 ÷ 576) ≈ 0.059.

Enteros de 4 bits: solo 16 valores, de −8 a 7, medio byte por número. Se usa para guardar los pesos de LLMs grandes, con una escala por cada grupo chico de pesos.

Con una sola escala por capa, los números chicos se vuelven 0; por eso cada grupo (por ejemplo, de 128 pesos seguidos) lleva su propia escala, que cuesta ≈ 0.125 bits más por peso. En LLMs casi siempre es weight-only: los pesos se guardan en INT4 y se convierten a 16 bits (BF16 o FP16) al vuelo, justo antes de multiplicar; los métodos más usados son AWQ y GPTQ. Ahorra mucha memoria y acelera la generación de texto, pero arriesga más calidad que FP8 o INT8.

Ejemplo. Un modelo de 70,600 millones de parámetros ocupa ≈ 35.3 GB en INT4, más ≈ 1.1 GB de escalas con grupos de 128: cabe en una H100 de 80 GB, donde en BF16 (≈ 141 GB) no cabría.

Enteros de 8 bits con signo, de −128 a 127. En ML, sobre todo, un formato de cuantización: cada peso o activación se guarda como un int8 más una escala compartida, en 1 byte en vez de 4.

Lo aceleran los tensor cores de las GPUs desde la generación de la T4 (en ella, ≈ 130 × 10¹² operaciones por segundo, el doble que en FP16) y las CPUs modernas con instrucciones especiales (VNNI, AMX). En CNNs se cuantizan pesos y activaciones; en LLMs, a menudo solo los pesos. Pide cuantización con calibración y un examen antes de producción: el promedio puede esconder lo que pierde la cola larga.

Ejemplo. La ResNet-50 de C01 pasa de 98 MB en FP32 a ≈ 25 MB en INT8. En la Ronda (M08), en CPU, corrió ≈ 2 veces más rápido con una foto a la vez y ≈ 3.5 veces con 8.

Cuántas operaciones hace un cálculo por cada byte que lee o escribe en la memoria: FLOPs ÷ bytes. Si es baja, manda la memoria; si es alta, manda el cálculo.

Es una propiedad del cálculo, no de la máquina: depende de cuántas veces se reutiliza cada número que se trae de la VRAM. Una matriz por un vector usa cada peso una sola vez (≈ 1 FLOP por byte en FP16); dos matrices cuadradas de lado n, cada número n veces (≈ n ÷ 3 FLOPs por byte en FP16). Se compara con el punto de quiebre de la GPU, su pico de FLOPS ÷ su ancho de banda de memoria: por debajo, el cálculo es memory-bound; por encima, compute-bound. El batching la sube: un peso que se lee una vez se usa para todo el batch.

Analogía. Un cocinero cuyos ingredientes llegan de una bodega: la intensidad es cuántos platillos saca de cada viaje. Si saca uno, espera al ayudante; si saca cien, el ayudante le sobra. Se rompe en que la comida se gasta y un número no: se puede usar las veces que quieras mientras siga en el chip.

Ejemplo. Generar un token de un LLM en BF16: cada peso de 2 bytes se usa en una MAC, 2 FLOPs, así que la intensidad es ≈ 1 FLOP por byte. Multiplicar dos matrices de 4,096 × 4,096 en FP16 son ≈ 137 GFLOPs con ≈ 101 MB de lecturas y escrituras: ≈ 1,365 FLOPs por byte.

La regla para calcular el valor de un píxel nuevo a partir de sus vecinos cuando una imagen cambia de tamaño. Las más sencillas son nearest (copia el más cercano) y bilinear (mezcla los 4 que lo rodean).

Casi ningún píxel nuevo cae justo encima de uno viejo, así que hay que calcular su valor. Nearest copia el vecino más cercano: es rápida, pero da bloques. Bilinear mezcla los 4 vecinos, con más peso para los más cercanos, y da transiciones suaves; bicubic usa 16. Al achicar conviene además el antialias: tomar en cuenta todos los píxeles viejos que caen debajo del nuevo, para que un detalle delgado no desaparezca. Cada librería tiene su costumbre (Pillow usa bicubic; OpenCV, bilinear sin antialias; torchvision, bilinear con antialias), así que la interpolación es parte del preprocesamiento y tiene que ser la misma al entrenar y al servir.

Ejemplo. Al agrandar la fila [40, 200] a 4 píxeles, nearest da [40, 40, 200, 200] y bilinear da [40, 80, 160, 200].

Un programa que lee tu código y lo va ejecutando mientras corre, sin traducirlo antes a instrucciones para la CPU. Python funciona así.

CPython, el intérprete de Python más usado, traduce cada archivo .py a bytecode (instrucciones sencillas para el propio intérprete; el de los módulos que importa lo guarda en __pycache__, si puede escribir ahí) y las ejecuta una por una con un ciclo escrito en C. Cada instrucción de bytecode cuesta muchas instrucciones de máquina: por eso un ciclo de Python puro es decenas de veces más lento que el mismo ciclo en C, y el trabajo pesado se deja a librerías compiladas, como NumPy y PyTorch. El intérprete es, a su vez, un binario: cuando «corre el gateway», el proceso es python.

Analogía. Un intérprete de conferencias, que traduce frase por frase mientras el orador habla, contra un traductor que entrega el libro ya traducido (el compilador). Se rompe en que CPython sí traduce antes, a bytecode; lo que hace al momento es ejecutarlo.

Ejemplo. dis.dis muestra el bytecode de una función: en Python 3.14, return precio * 1.16 son cuatro instrucciones, entre ellas BINARY_OP para la multiplicación.

Un rango alrededor de lo que mediste que dice cuánto podría moverse por el puro azar de la muestra. El de 95 % es lo medido ± 1.96 errores estándar (≈ ±2).

El 95 % es de la receta: si repitieras la muestra muchas veces y armaras un intervalo con cada una, 95 de cada 100 atraparían el valor verdadero. No dice que el 95 % de los datos caiga ahí, no cubre otros errores (una muestra sesgada, etiquetas mal puestas) y no promete lo que pasará en producción, donde la población cambia. Con pocos datos, o con proporciones cerca de 0 o de 100 %, la regla de ±2 falla y se usa la de Wilson.

Ejemplo. 85 % en 1,000 fotos: 85 ± 2.2, de 82.8 % a 87.2 %. En el golden set de C01, con 50,000 fotos: 85 ± 0.3.

Qué tanto se enciman dos cajas (o dos máscaras): el área que comparten dividida entre el área que cubren juntas. Va de 0 (no se tocan) a 1 (idénticas).

En detección decide si una caja del modelo le atinó a la caja real: la regla clásica pide IoU ≥ 0.5. Castiga los dos errores: una caja corrida comparte menos, y una caja demasiado grande agranda la unión aunque cubra todo el objeto. También se usa en segmentación, con píxeles en vez de cajas, y para revisar que un modelo optimizado dé las mismas cajas que el original.

Ejemplo. Caja real de 100 × 200 píxeles; la del modelo, igual pero corrida 20 píxeles a la derecha y 20 hacia abajo. Comparten 80 × 180 = 14,400; juntas cubren 20,000 + 20,000 − 14,400 = 25,600. IoU = 14,400 / 25,600 ≈ 0.56.

La escalera de memorias de una computadora, de la más rápida y chica a la más lenta y grande. En la CPU: registros, cachés (L1, L2 y L3), RAM y discos. En la GPU: registros, memoria junto a los núcleos, caché L2 y VRAM. Cada piso hacia abajo guarda más y cuesta menos por byte, pero tarda más: del primero al último de la CPU, ≈ 10 millones de veces.

Existe porque ninguna memoria es a la vez rápida, grande y barata. El sistema trata de tener arriba lo que se va a usar enseguida, y le funciona gracias a la localidad: los programas reusan los mismos datos y usan los de al lado. A escala humana, si leer la L1 tardara 1 segundo, la RAM tardaría 1 minuto 40 segundos; un SSD, más de un día, y un disco duro, casi 4 meses. La GPU tiene su propia escalera, que termina en la VRAM (4 MB de caché L2 en la T4, decenas de MB en las más nuevas), y entre las dos escaleras el puente es PCIe, más lento que cualquiera de las dos memorias.

Analogía. Una cocina: la mesa junto a la estufa (la caché), la bodega (la RAM), el mercado (el SSD) y un pedido que llega por barco (el disco duro). Se rompe en que el hardware sube y baja las cosas solo, sin que nadie se lo pida, y en que todo lo de arriba del disco se borra si se va la luz.

Ejemplo. El mismo byte tarda ≈ 1 ns si está en la L1, ≈ 100 ns en la RAM, ≈ 0.1 ms en un SSD NVMe y ≈ 10 ms en un disco duro: diez millones de veces más del primero al último.

El formato más común para fotos. Comprime con pérdida: descarta detalles finos que el ojo casi no nota, y así el archivo ocupa mucho menos.

Trabaja en bloques de 8 × 8 píxeles; cuanto más se comprime, más se notan esos bloques. Por eso la misma escena guardada con otra calidad da otros píxeles. No guarda transparencia. Suele traer metadatos exif.

Ejemplo. Una foto de 12 MP ocupa ≈ 36.6 MB como píxeles y unos 3 MB como JPEG: unas 12 veces menos.

Un número que mide qué tanto coinciden dos personas al etiquetar, descontando lo que coincidirían por puro azar. 1 es acuerdo perfecto; 0, lo mismo que el azar.

κ = (pₒ − pₑ) ÷ (1 − pₑ), donde pₒ es la fracción de ejemplos en que coincidieron y pₑ la que esperarías si cada quien etiquetara al azar con sus propias proporciones. Importa cuando una clase domina: dos personas que casi siempre dicen «bueno» coinciden mucho sin ponerse de acuerdo en lo difícil. Una escala muy citada (Landis y Koch, 1977) llama «moderado» a 0.41–0.60, «sustancial» a 0.61–0.80 y «casi perfecto» a más de 0.80. Con más de dos personas se usan parientes suyos, como la kappa de Fleiss.

Ejemplo. Dos inspectores de C03 coinciden en 970 de 1,000 piezas (97 %), pero casi todas son buenas y el azar ya daba 95.125 %: κ = (0.97 − 0.95125) ÷ (1 − 0.95125) ≈ 0.38.

El núcleo del sistema operativo: el único programa que toca el hardware directamente. Reparte la CPU y la memoria entre los programas que están corriendo (los procesos), maneja los discos y la red, y revisa los permisos de todo lo que le piden.

La CPU tiene dos modos: en modo kernel se puede todo; en modo usuario no se puede tocar el hardware ni la memoria de otro proceso. El kernel corre en modo kernel y los programas, en modo usuario: para cualquier cosa del mundo exterior le hacen una llamada al sistema. También crea los procesos, los aísla con namespaces y les pone límites con cgroups. Los drivers son partes del kernel que saben hablar con un dispositivo. Ojo: un kernel de GPU es otra cosa, un programita que corre en la GPU, y el kernel de un notebook de Jupyter es el proceso que corre tus celdas.

Analogía. El personal de una biblioteca de estantería cerrada: los lectores no entran a los estantes; piden el libro en el mostrador, alguien revisa su credencial y se los trae. Se rompe en que el kernel también le quita la silla a un lector cuando le toca a otro: reparte el tiempo de la CPU sin que nadie se lo pida.

Ejemplo. El contenedor de Triton de C01 usa el kernel de su nodo, el mismo que todos los contenedores de esa máquina. Por eso el driver de la T4 (el módulo nvidia.ko) se instala en el nodo y no viaja en la imagen.

Una función que corre en la GPU, ejecutada por miles de hilos a la vez, cada uno con un pedacito del trabajo. La CPU la manda a correr (la «lanza»), y cada operación de un modelo es uno o más kernels.

La CPU lanza un kernel dejándolo en una fila de trabajo de la GPU (un stream) y sigue con lo suyo sin esperar: es asíncrono, y solo espera cuando pide un resultado o llama a torch.cuda.synchronize(). Cada lanzamiento le cuesta a la CPU unos microsegundos; si el kernel tarda menos que eso en la GPU, la GPU se queda esperando a la CPU. Por eso, con batches chicos, ayudan la fusión de capas (TensorRT junta convolución, BatchNorm y ReLU en un kernel), el batching (kernels con más trabajo) y los CUDA graphs (un solo lanzamiento para toda la secuencia). No lo confundas con el kernel del sistema operativo, ni con el filtro de una convolución, que a veces también se llama kernel.

Ejemplo. La ResNet-50 sin fusionar son 174 operaciones por batch, cada una al menos un kernel: a 5 µs por lanzamiento, ≈ 0.87 ms de CPU. Fusionada por TensorRT quedan 56: ≈ 0.28 ms.

La memoria donde un LLM guarda la K y la V (dos vectores que la atención calcula para cada token) de los tokens que ya procesó, para no recalcularlas en cada token nuevo. Crece con cada token y vive en la memoria de la GPU.

Sin él, cada token nuevo obligaría a recalcular todo lo anterior. Con él, solo se calcula lo del token nuevo. El precio es memoria: por cada token de cada conversación activa se guardan dos vectores (K y V) por cada juego de K y V de cada bloque del modelo. Por eso suele ser lo que limita cuántas conversaciones atiende una GPU a la vez, y por eso existen trucos como GQA. El prefix caching lo reutiliza entre requests que empiezan igual.

Ejemplo. Llama 3 8B: 2 (K y V) × 32 bloques × 8 juegos × 128 números × 2 bytes = 131,072 bytes = 128 KiB por token. Una conversación de 8,192 tokens: 1 GiB.

Cuando cambia cuánto hay de cada clase, pero cada clase se ve como siempre. En diciembre llegan muchos más juguetes, y cada juguete se ve igual que en octubre.

En notación, cambia p(y), la proporción de cada respuesta, y p(x | y), cómo se ve cada clase, queda igual. Se sospecha mirando la mezcla de predicciones (en C01, la distribución de categorías predichas) y se confirma con etiquetas. Afecta sobre todo a los umbrales y a la calibración: un modelo que aprendió que los juguetes son el 1 % les da menos probabilidad de la que merecen cuando son el 10 %. Se revisan umbrales y calibración por clase y, si hace falta, se reentrena con la mezcla actual.

Ejemplo. C01: supón que «Juguetes» pasa de 1 % a 10 % de las fotos en diciembre. C09: una ola de ataques sube la proporción de pagos fraudulentos, aunque cada fraude se vea como los de siempre.

Cuánto tarda en llegar la respuesta desde que se hace la petición.

Se mide en milisegundos. No basta con el promedio: importa sobre todo qué tan lentas son las respuestas más lentas, porque a esas personas la app se les traba.

Ejemplo. C01 se compromete a que 99 de cada 100 sugerencias tarden menos de 200 ms.

Cuando el entrenamiento o la evaluación tienen información que no existirá en el momento de predecir, o cuando el test se parece demasiado al train. El examen se filtró.

El síntoma es siempre el mismo: un resultado sospechosamente bueno antes de producción que se derrumba en producción. Formas comunes: la misma foto (o casi) en train y en test (casi duplicado), una feature que trae escondida la respuesta, datos del futuro, ejemplos de un mismo grupo a los dos lados, y cuentas (como el promedio para escalar) hechas con todo el dataset antes de repartir.

Ejemplo. Un vendedor sube la misma foto en tres publicaciones. Con un split al azar 80/20 por publicación, ≈ 98 de cada 100 veces que esa foto aparece en test, otra copia suya está en train: el modelo la reconoce de memoria.

Qué tan grande es cada pasito al mover los parámetros (las perillas) de un modelo durante el entrenamiento. Muy chico: tarda una eternidad. Muy grande: se pasa del fondo del valle y la pérdida explota.

Es el hiperparámetro más importante y no tiene un valor correcto universal: depende del modelo, del optimizador y del tamaño del batch, y se elige probando en validación. Casi nunca es fijo: un scheduler lo sube al principio con warmup y lo baja al final. Con Adam, es del orden de cuánto se mueve cada perilla por paso.

Ejemplo. C01 entrena con lr = 3e-4, que quiere decir 3 × 10⁻⁴ = 0.0003. En la parábola de la lección, con 0.05 la perilla queda a menos de 0.01 del fondo en 12 pasos; con 0.3, la pérdida explota.

En un sistema estable, lo que hay adentro en promedio es igual a lo que llega por unidad de tiempo por lo que tarda cada uno adentro: L = λ × W. A 500 requests por segundo con 50 ms cada una, hay 25 adentro a la vez (en vuelo).

L es cuántos hay adentro en promedio (requests en vuelo, jobs en proceso, clientes en un restaurante), λ (lambda) es la tasa de llegada y W, el tiempo promedio que pasa cada uno adentro. La demostró John Little en 1961, y vale con cualquier forma de llegadas y de duraciones, siempre que se hable de promedios y el sistema no se esté llenando sin parar. Dice cuánta concurrencia hace falta: hilos, conexiones, lugares en una fila. Aplicada a la CPU, da los núcleos ocupados: tasa × CPU por request. Habla de promedios: λ × p99 no es «la concurrencia en el peor caso». Si W sube porque un servicio de atrás se frena, lo que hay adentro sube igual; por eso los timeouts acotan la concurrencia.

Ejemplo. C01 en el pico de diseño: 500 × 0.05 s = 25 requests en vuelo, ≈ 5 por pod. Si Triton se frena hasta su timeout de 150 ms, son 500 × 0.15 = 75 llamadas abiertas; con un timeout de 5 s serían 2,500.

El núcleo (kernel) de sistema operativo, libre y de código abierto, que corre en la mayoría de los servidores del mundo, en los teléfonos Android y en equipos chicos de NVIDIA como los Jetson. Lo empezó Linus Torvalds en 1991.

En sentido estricto, Linux es solo el kernel. Lo que se instala es una distribución: el kernel más el espacio de usuario (la biblioteca de C, la shell, los comandos y un gestor de paquetes). Ubuntu, Debian, Alpine, Amazon Linux 2023, Bottlerocket y Jetson Linux son distribuciones. Los contenedores son una función del kernel Linux: en una Mac o en Windows, Docker corre una máquina virtual con Linux, escondida. Linux tiene una regla: un cambio del kernel no puede romper a los programas que ya funcionan. Gracias a ella, una imagen de Ubuntu 22.04 corre en un nodo con Amazon Linux.

Ejemplo. La imagen de Triton de C01 trae Ubuntu 22.04 con Python 3.10; la del gateway, Debian con Python 3.13. Ninguna trae kernel: Triton usa el de Amazon Linux 2023 de su nodo con GPU, y el gateway, el de su máquina sin GPU.

La forma en que un programa le pide algo al kernel, el núcleo del sistema operativo: abrir un archivo, leerlo, mandar algo por la red, crear un proceso, pedir memoria. Es la única puerta entre un programa y el hardware.

Al hacer una, la CPU pasa a modo kernel; el kernel revisa que se pueda (que exista el archivo, que haya permisos), hace el trabajo y regresa el resultado o un número de error (errno): 2 es «No such file or directory»; 13, «Permission denied»; 8, «Exec format error». Linux tiene más de 300, como openat, read, write, mmap, clone, execve y kill. Casi nadie las hace a mano: las hace la biblioteca de C por dentro de funciones como open(). Cada una cuesta poco, de décimas de microsegundo a unos microsegundos, pero millones suman: por eso las bibliotecas juntan las escrituras en un buffer. Que Linux no cambie sus syscalls es lo que deja correr un contenedor con Ubuntu sobre el kernel de otra distribución.

Ejemplo. Un print('hola') de Python termina en write(1, 'hola\n', 5): escribe 5 bytes en el archivo número 1, la salida del programa. Escribir 1,000 líneas sin buffer son 1,000 syscalls; con un buffer de 8 KiB, son 2.

El modelo estándar de llegadas al azar: muchos usuarios que no se ponen de acuerdo, cada uno con una probabilidad chica de pedir algo. Con un promedio de λ por intervalo, lo que llega se aleja del promedio, normalmente, en ≈ √λ.

La probabilidad de que lleguen exactamente k es λ^k × e^(−λ) ÷ k!. Mientras más chico el intervalo, más saltos en proporción: con 10 por segundo, ≈ 8 % de los segundos traen 15 o más. Supone llegadas independientes, y se rompe cuando no lo son: una notificación a millones de personas, tareas programadas a la hora en punto, reintentos en manada. Lo que no es aleatorio se suma encima. Lleva el nombre del matemático francés Siméon Denis Poisson.

Ejemplo. Cada Triton de C01 espera hasta 2 ms por compañía para formar un batch. Con 250 requests por segundo llegan en promedio 0.5 en esos 2 ms, y la probabilidad de que no llegue ninguno es e^(−0.5) ≈ 61 %.

Un transformer con miles de millones de parámetros, entrenado con enormes cantidades de texto para predecir el siguiente token. De esa sola tarea salen la conversación, los resúmenes y el código.

Casi todos son solo decoder. Se construyen en etapas: preentrenamiento (continuar texto de todo tipo), ajuste con instrucciones (seguir el formato de una conversación) y ajuste por preferencias (RLHF o DPO). Sus tamaños se dicen en parámetros: 7B, 8B o 70B (la B es de billion, mil millones en inglés). Sus pesos ocupan decenas de GB, así que la memoria de la GPU decide qué se puede servir y cómo.

Ejemplo. Llama 3 70B tiene ≈ 70.6 mil millones de parámetros: en BF16 (2 bytes cada uno), ≈ 141 GB.

La costumbre de los programas de volver a usar lo que acaban de usar (localidad temporal) y de usar lo que está junto (localidad espacial). Las cachés funcionan gracias a ella: por eso recorrer los datos en el orden en que están guardados es mucho más rápido.

La caché guarda lo reciente, para la temporal, y trae líneas completas de 64 bytes, para la espacial; además, el hardware adivina un recorrido en orden y trae las siguientes líneas antes de que se pidan (prefetch). Una matriz se guarda fila tras fila (row-major, como en NumPy y PyTorch): recorrerla por filas usa los 16 float32 de cada línea; por columnas, cada lectura cae en una línea distinta. La misma idea vale para los discos, donde leer un archivo grande de corrido le gana a leer millones de archivos chicos, y para la GPU, donde el batch reusa cada peso con muchas fotos.

Ejemplo. En el simulador de la lección, recorrer una matriz de 1,024 × 1,024 float32 por filas acierta 93.75 % de las veces; por columnas, 0 %. En Python, en la Mac donde se escribió la lección, sumar una lista en desorden tardó de 5 a 12 veces más que en orden.

La operación que responde «¿a qué potencia hay que elevar la base para llegar a este número?». log2 8 = 3 porque 2³ = 8. Convierte multiplicaciones en sumas y cocientes en restas.

Hay tres bases que vas a ver: 2 (log2, cuenta duplicaciones y mide bits), 10 (log10, cuenta ceros) y e ≈ 2.718 (ln, el logaritmo natural, el que usan casi todas las fórmulas de ML). Sus reglas: ln 1 = 0; un número entre 0 y 1 tiene logaritmo negativo; ln(a × b) = ln a + ln b; ln(a ÷ b) = ln a − ln b; y ln 0 no existe (se va a menos infinito). Por eso mide cocientes: duplicar suma siempre ln 2 ≈ 0.693 y dividir entre 2 resta 0.693, sin importar de qué número partas. Para cambiar de base: log2 x = ln x ÷ ln 2. Ojo: en Python, math.log es ln; en muchas calculadoras, la tecla «log» es base 10.

Ejemplo. ln(0.14 ÷ 0.10) = ln 1.4 ≈ 0.336, y ln(0.10 ÷ 0.14) ≈ −0.336: subir de 10 % a 14 % y bajar de 14 % a 10 % miden lo mismo con signo contrario. log2 1,024 = 10.

El puntaje crudo que da un modelo de clasificación por cada clase, antes de convertirlo en probabilidad. Puede ser cualquier número, positivo o negativo.

Más alto significa que el modelo se inclina más por esa clase, pero un logit solo no dice mucho: importa comparado con los de las otras clases del mismo modelo. softmax o la sigmoide lo convierten en probabilidad. El nombre viene de la estadística: el logit de una probabilidad p es ln(p ÷ (1 − p)), el logaritmo de su momio, y es la inversa exacta de la sigmoide.

Ejemplo. Tres clases con logits 3.0, 1.0 y 0.0. En C01 el modelo devuelve 500 logits, uno por categoría. En un clasificador binario, con su sigmoide, un logit de 1.39 equivale a 80 %.

Una forma barata de hacer fine-tuning: en vez de cambiar todos los pesos del modelo, se congelan y se entrenan unas tablas chiquitas que se suman a algunos de ellos.

La propuso un artículo de Microsoft de 2021 (Hu y otros). Lo que se entrena y se guarda es un adaptador de unos pocos MB a unos cientos de MB, según el rango y cuántas tablas toque, no una copia del modelo. Un mismo modelo base puede servir varios adaptadores, uno por producto o cliente.

Ejemplo. Una tabla de 4,096 × 4,096 tiene 16,777,216 números. Con LoRA de rango 8 se entrenan dos tablas de 4,096 × 8 y 8 × 4,096: 65,536 números, 256 veces menos. En Llama 3 8B, rango 8 sobre las tablas de Q y V de sus 32 bloques: ≈ 3.4 millones de números, ≈ 7 MB.

La forma de nombrar una disponibilidad por cuántos 9 tiene: «tres nueves» es 99.9 % y «cuatro nueves», 99.99 %. Cada nueve más divide entre 10 el tiempo caído permitido.

En un mes de 30 días (43,200 minutos): 99 % son 7.2 horas; 99.9 %, 43.2 minutos; 99.99 %, 4.32 minutos, y 99.999 %, ≈ 26 segundos. Cada nueve cuesta: con 99.9 % alcanza con una réplica de repuesto en otra zona y alguien de guardia que regrese una versión en minutos; con 99.99 %, la detección y el cambio de réplica tienen que ser automáticos, porque nadie arregla nada a mano en 4 minutos. Antes de prometer un nueve más, pregunta qué pasa cuando el servicio falla y qué cuesta ese nueve.

Ejemplo. C01 promete tres nueves, 99.9 %, porque tiene un plan B: si el modelo no responde, Ana elige la categoría a mano. C09, que decide dentro de cada pago, pide cuatro: 99.99 %, ≈ 4.3 minutos al mes.

Multiplicar dos números y sumar el resultado a lo que ya llevas acumulado. Es la unidad de trabajo de una red neuronal: 1 MAC son 2 FLOPs, una multiplicación y una suma.

Un producto punto de k números son k MACs: multiplicas cada par y lo vas sumando a un acumulador. Una capa densa hace entradas × salidas MACs por ejemplo; una convolución, posiciones × filtros × pesos por filtro; una multiplicación de matrices de n × k por k × m, n × m × k. El hardware la hace en una sola instrucción (la FMA, fused multiply-add), pero se cuenta como 2 FLOPs. Las MACs dicen cuánto cálculo pide un modelo; los parámetros, cuánta memoria.

Ejemplo. La primera capa de la ResNet-50 tiene 9,408 pesos y hace 118,013,952 MACs por foto: cada peso se usa en 12,544 posiciones. La red completa hace ≈ 4.1 GMACs (4,100 millones) por foto, que son ≈ 8.2 GFLOPs.

Sacar la métrica de cada clase por separado y promediarlas, de modo que cada clase pese lo mismo, tenga muchas fotos o pocas.

Lo contrario es contar fotos (micro-promedio, que para el recall con una sola etiqueta por foto es la accuracy), donde las clases grandes mandan. Con un long tail, el macro-recall revela categorías chicas que empeoraron aunque la accuracy suba.

Ejemplo. Un modelo nuevo sube la accuracy de 85.0 % a 85.25 % y baja el macro-recall de 75 % a 64 %: mejoró en las 200 categorías grandes y empeoró mucho en las 300 chicas.

La calificación más usada de un detector de objetos: para cada clase se calcula el área bajo su curva precision–recall (la AP) y se promedian las clases.

Las cajas del modelo se ordenan por confianza; cada una es un acierto si su IoU con una caja real todavía sin pareja llega a un mínimo (0.5 es la regla clásica), y una falsa alarma si no. Recorriendo la lista sale la curva PR de la clase; su área es la AP. La versión de COCO, más exigente, promedia además 10 mínimos de IoU, de 0.50 a 0.95. Mide si el detector ve los objetos, no si el sistema sirve: en la Ronda, el caso de video (C02) lo reporta pero decide con el recall por evento.

Ejemplo. 3 personas reales y 5 cajas ordenadas por confianza: acierto, acierto, falsa alarma, acierto, falsa alarma. La AP es (1 + 1 + 0.75) / 3 ≈ 0.92. Si otra clase tiene AP de 0.70, el mAP es (0.92 + 0.70) / 2 ≈ 0.81.

La cuadrícula que produce un filtro al recorrer la foto. Dice dónde de la foto encontró lo que busca ese filtro.

Una capa con 64 filtros produce 64 mapas, que son los 64 canales de entrada de la capa siguiente. En una CNN los mapas se van achicando y multiplicando: la ResNet-50 termina con 2,048 mapas de 7 × 7.

Ejemplo. La primera capa de la ResNet-50 convierte la foto de 3 × 224 × 224 en 64 mapas de 112 × 112.

Una tabla de números ordenada en filas y columnas, todas del mismo largo. Su tamaño se dice «filas × columnas»: una matriz de 2 × 3 tiene 2 filas y 3 columnas.

Es el paso que sigue al vector: un vector es una sola fila (o una sola columna) de números; una matriz, varias filas del mismo largo. Cada número se ubica por su fila y su columna. En ML casi todo es una matriz o se guarda como una: los pesos de una capa densa (una fila por número que entra y una columna por salida), un batch de embeddings (una fila por foto) o una tabla de datos (una fila por ejemplo y una columna por feature). Una matriz es un tensor de dos dimensiones, y su shape es [filas, columnas]. Lo que ocupa en memoria es filas × columnas × los bytes de su dtype.

Ejemplo. Los pesos de la última capa de la ResNet-50 de C01 forman una matriz de 2,048 × 500: una fila por cada número que sale del backbone y una columna por categoría. Son 1,024,000 números: ≈ 2 MB en FP16 y ≈ 4.1 MB en float32.

La tabla que cuenta, para cada clase real, cuántas veces el modelo dijo cada clase. La diagonal son los aciertos; todo lo demás, en qué se confunde.

Con una pregunta de sí o no es de 2 × 2: verdaderos positivos, falsos negativos, falsos positivos y verdaderos negativos. Con 500 clases es de 500 × 500 (250,000 casillas), y se buscan las casillas grandes fuera de la diagonal. De ella salen accuracy, precision y recall.

Ejemplo. 1,000 fotos, 100 de tenis: 80 tenis bien encontrados, 20 que se le escaparon, 40 cosas que dijo tenis sin serlo y 860 bien descartadas.

El valor de en medio cuando ordenas los datos: la mitad queda abajo y la mitad arriba. Si la cantidad es par, se promedian los dos de en medio.

Es el percentil 50 (el p50) y describe el caso típico. Es resistente: solo mira el orden, así que un valor atípico muy lejano casi no la mueve. Por eso se usa para la latencia típica, para reportar ingresos y para rellenar datos que faltan. Con una cantidad par, el método del rango más cercano toma el de abajo de los dos de en medio; con miles de datos la diferencia desaparece.

Ejemplo. Nueve sueldos de 9 a 16 mil pesos y uno de 900 mil: el promedio sube de ≈ 12,444 a 101,200 pesos, y la mediana apenas pasa de 12,000 a 12,500.

El truco con el que cada proceso (cada programa en marcha) ve su propia memoria, numerada desde 0, como si tuviera la máquina para él solo. El sistema operativo y la CPU traducen esas direcciones a la RAM de verdad por bloques, las páginas (4 KiB en Linux; 16 KiB en las Mac con chip de Apple).

Cada proceso tiene una tabla de páginas que dice dónde está cada una de sus páginas: en un marco de la RAM, en el disco (en el swap o en un archivo abierto con mmap) o en ningún lado todavía. Así un proceso no puede leer ni pisar la memoria de otro, y el sistema puede reservar sin entregar: la RAM se asigna la primera vez que se escribe en cada página. Tocar una página que no está en RAM es un fallo de página (page fault): el sistema detiene al proceso, consigue la página y lo deja seguir. Cuesta del orden de un microsegundo si basta con dar una página nueva, y de 0.1 a 10 ms si hay que leerla del disco. Lo que de verdad ocupa un proceso es su RSS, no su tamaño virtual.

Analogía. Cada proceso tiene su libreta de direcciones, con casas numeradas desde el 0, y el sistema operativo es el cartero que sabe en qué calle real está cada una. Se rompe en que este cartero también puede mandar una casa al almacén (el disco) y traerla de vuelta cuando alguien toca la puerta.

Ejemplo. Con páginas de 4 KiB, la dirección virtual 4,100 es el byte 4 de la página 1 (4,100 ÷ 4,096 da 1 y sobran 4). Si la tabla del proceso pone esa página en el marco 2, el byte de verdad está en 2 × 4,096 + 4 = 8,196. Y en la lección, pedir 400 MB no movió la RAM del proceso; escribir un byte cada 4 KiB la subió 400 MB.

Cuando lo que frena un cálculo es cuántos bytes por segundo entrega la memoria: los núcleos esperan datos. Más TFLOPS no lo aceleran; menos bytes o más ancho de banda, sí.

En español, «limitado por la memoria». Pasa cuando la intensidad aritmética es menor que el punto de quiebre de la GPU: cada byte se usa en muy pocas operaciones. Es el caso del decode de un LLM con pocas conversaciones (cada token relee todos los pesos), de las operaciones elemento a elemento (una ReLU, sumar un sesgo) y de las capas densas con batch chico. El tiempo mínimo es bytes ÷ ancho de banda de memoria. Palancas: batching (una lectura sirve para varios), menos bytes (cuantizar a INT8 o INT4), fusionar operaciones para no escribir y releer resultados intermedios, o una GPU con más GB/s.

Ejemplo. Un token de Llama 3 8B en una L4: leer sus ≈ 16 GB de pesos a 300 GB/s toma ≈ 54 ms; calcular sus ≈ 16 GFLOPs a 121 TFLOPS, ≈ 0.13 ms. Los núcleos esperan ≈ 400 veces más de lo que trabajan, y el techo es ≈ 19 tokens por segundo.

El número que dice si el sistema le sirve a la empresa y a la gente: publicaciones completadas, dinero que se deja de perder. La métrica del modelo, que se mide offline, es solo su aproximación.

Se baja por una cadena: negocio → online (cómo reacciona la gente real; por ejemplo, cuántos aceptan la sugerencia) → offline (lo que se mide con datos guardados, como la top-5 en el golden set). Cada eslabón es un proxy del de arriba, y la cadena se puede romper: un modelo que gana offline puede perder online. Por eso los cambios grandes se prueban con gente real en un A/B test, con guardrails: métricas que no tienen que mejorar pero no pueden empeorar, como la latencia.

Ejemplo. C01: negocio, tasa de publicaciones completadas; online, tasa de aceptación de la categoría sugerida; offline, top-5 en el golden set; guardrails, p99 de latencia, tasa de errores, publicaciones que moderación recategoriza y tiempo para llenar el formulario.

Un LLM que en cada bloque tiene varias redes, los «expertos», en lugar de una; para cada token, un enrutador elige solo unos pocos. Guarda muchos parámetros, pero cada token trabaja con una fracción.

El enrutador es una capa chica que califica a cada experto; se usan los de calificación más alta y sus resultados se mezclan con un softmax de esas calificaciones. La memoria cuenta todos los expertos; el cálculo y la lectura por token, solo los que se usaron. Los «expertos» no son especialidades humanas (uno de medicina, otro de leyes): el reparto lo aprende el modelo y casi nunca se puede leer así. A un modelo que no es MoE se le llama denso.

Analogía. Una recepcionista que manda a cada paciente con 2 de 8 especialistas. Se rompe en dos lugares: nadie decidió qué sabe cada experto, y los 8 tienen que estar siempre en la memoria de la GPU, trabajen o no.

Ejemplo. Mixtral 8x7B (Mistral AI, 2023) tiene 8 expertos por bloque y usa 2 por token: 46.7 mil millones de parámetros en total y 12.9 mil millones activos por token.

Una milésima de segundo. Un parpadeo dura entre 100 y 400 ms.

Un segundo tiene 1,000 milisegundos. Es la unidad natural del camino online: la respuesta de un modelo se mide en decenas o cientos de ms.

Ejemplo. La promesa de C01 es de 200 ms, un quinto de segundo. El marketplace espera como máximo 300 ms, tres décimas de segundo.

La persona que lleva un modelo del notebook a producción y lo mantiene funcionando: datos, entrenamiento, serving, despliegue y monitoreo.

No basta con que el modelo acierte. El trabajo es que todo lo que lo rodea también funcione: que le lleguen buenos datos, que responda rápido, que no se caiga y que alguien note cuando empieza a fallar.

Ejemplo. En C01, el ML engineer no inventa la ResNet-50: se encarga de que las fotos le lleguen bien preparadas, de que responda en menos de 200 ms, de que una versión nueva salga sin romper nada y de notar cuando empieza a fallar.

Una red neuronal hecha solo de capas densas, con activaciones entre ellas: cada neurona de una capa ve todas las salidas de la anterior.

Las capas de en medio se llaman ocultas. Con una sola capa oculta ya resuelve problemas que una neurona sola no puede, como el XOR. Cada capa tiene entradas × salidas + salidas parámetros. Sobre fotos desperdicia parámetros (cada píxel lleva su propio peso), por eso para imágenes se usan CNNs; pero dentro de cada bloque de un transformer hay un MLP de dos capas.

Ejemplo. 784 entradas (un dígito de 28 × 28), 128 ocultas y 10 salidas: (784 × 128 + 128) + (128 × 10 + 10) = 101,770 parámetros.

Una forma de abrir un archivo que lo hace aparecer en la memoria del programa, como si ya estuviera cargado. El sistema lo lee del disco por pedazos, solo cuando el programa toca cada parte, y usa la copia que ya guarda en la RAM (la page cache), sin copiarlo otra vez.

Es lo contrario de leer el archivo completo a la memoria propia del proceso (con read), que deja dos copias en RAM: la de la page cache y la del proceso. Con mmap, abrir un archivo de 100 GB no cuesta nada hasta tocarlo, y varios procesos que abren el mismo archivo comparten la misma RAM. Los pesos en formato safetensors (un encabezado en JSON y los números tal cual) están pensados para cargarse así; torch.load(..., mmap=True) lo hace con los archivos de PyTorch, y vLLM lee los safetensors con mmap. Las páginas que se tocan cuentan en la RSS del proceso.

Ejemplo. En la lección, abrir con mmap un archivo de 200 MB y leer su encabezado y un peso del medio subió la RAM del proceso ≈ 0 MB; sumar todos los pesos la subió 200 MB.

Un programa que aprendió de ejemplos a convertir una entrada (una foto) en una respuesta (su categoría).

No lo escribe una persona regla por regla. Una persona elige su forma y los ejemplos, y el entrenamiento ajusta sus parámetros hasta que acierta. Por dentro es una función matemática muy grande: entran números (los píxeles de la foto) y salen números (qué tan probable es cada categoría).

Ejemplo. En C01 el modelo es una ResNet-50: recibe la foto de una publicación y devuelve qué tan probable es cada una de 500 categorías.

El interruptor de PyTorch que le dice al modelo «ahora vas a responder, no a entrenar». BatchNorm usa sus estadísticas guardadas y Dropout deja de apagar neuronas.

Un modelo recién creado o cargado está en modo entrenamiento (model.train()). Olvidar model.eval() en el servidor es un bug clásico: no da error, solo baja la calidad. No apaga el cálculo para aprender: para eso es torch.inference_mode(). En producción van los dos.

Ejemplo. En modo eval, la foto del ejemplo de BatchNorm da −0.45 llegue sola o acompañada. En modo train, sola en su batch, daría 0.

Una mejora del descenso de gradiente: cada paso arrastra parte de la dirección de los anteriores. Avanza más rápido donde el gradiente insiste y se frena donde zigzaguea.

Lleva una velocidad por perilla: v nueva = β × v + gradiente, y la perilla se mueve lr × v. Con β = 0.9, el valor usual, un gradiente que se repite igual acumula hasta 10 veces su tamaño (1 ÷ (1 − 0.9)), y uno que cambia de signo cada paso casi se cancela. Ocupa un número extra por perilla.

Analogía. Una pelota que rueda: no se detiene en cada piedrita y gana velocidad en una bajada larga. Se rompe en que la pelota real tiene peso y fricción; aquí β es solo un número que decide cuánto se recuerda.

Ejemplo. Gradientes −5, −5, −5: la velocidad va −5, −9.5, −13.55. Gradientes +10, −10, +10: va 10, −1, 9.1.

Medir todo el tiempo cómo se comporta el sistema en producción y avisar cuando algo se sale de lo normal.

En un sistema con un modelo se miden dos tipos de cosas. Las del software: qué tan rápido responde (latencia), cuántas peticiones fallan. Y las del modelo: si sigue acertando, o si los datos que llegan ya no se parecen a los de su entrenamiento (drift).

Ejemplo. En C01 se vigila que 99 de cada 100 respuestas tarden menos de 200 ms, cuántas fallan y si cambia cuáles categorías predice más seguido el modelo, que es una señal temprana de drift.

Pegar un sistema de archivos (un disco, una carpeta de red, un pedazo de memoria) en una carpeta del árbol: desde ahí, lo que hay en esa carpeta vive en el otro sistema. Puede ser de lectura y escritura o de solo lectura.

Así entra todo al árbol que empieza en /: un disco nuevo se monta en /data, un disco de red como el EFS de AWS llega por la red, /dev/shm vive en la RAM y /proc lo inventa el kernel. En un contenedor, la raíz es la imagen (capas de solo lectura y una capa escribible encima, que se borra con el contenedor), y lo demás llega montado: en Docker con -v /en/el/nodo:/models:ro, en Kubernetes con volumes y volumeMounts. Montado en solo lectura, cualquier escritura falla con «Read-only file system» (errno 30): los pesos no se pueden corromper y muchos pods comparten una copia.

Ejemplo. C10 copia sus 70.6 GB de pesos de S3 al disco NVMe del nodo, en un volumen del pod, y monta /dev/shm en memoria con 16 GiB porque los 64 MiB que trae un contenedor no alcanzan.

La parte de los datos que de verdad mides, porque medirlos todos es imposible o carísimo. Lo que sale de una muestra es una estimación: con otra muestra habría salido un poco distinto.

Una muestra sirve si se eligió al azar de la población que te importa: cada elemento con la misma oportunidad de entrar. Así sus errores son puro ruido, que se achica con más datos (el error estándar). Si se eligió con un criterio que tiene que ver con lo que mides (solo fotos de web, solo las publicaciones donde el vendedor aceptó la sugerencia), está sesgada, y ese error no baja aunque la hagas enorme.

Ejemplo. En C01, el golden set de 50,000 fotos es una muestra de todas las fotos que suben los vendedores. Con ella el modelo saca ≈ 85 %, con un ruido de ±0.3 puntos.

Clasificación con más de dos clases en la que cada ejemplo tiene exactamente una respuesta correcta.

Se usa softmax, que obliga a repartir el 100 % entre las clases, y la respuesta es la de logit más alto (argmax) o las k mejores (top-k). Es distinta de la multietiqueta, donde un ejemplo puede tener varias respuestas correctas a la vez.

Ejemplo. C01: cada publicación va en una sola de 500 categorías.

Clasificación en la que un ejemplo puede tener varias clases a la vez, o ninguna. Cada clase recibe su propio sí o no.

Se usa una sigmoide por etiqueta, no softmax: las probabilidades no compiten ni tienen por qué sumar 1. Cada etiqueta lleva su propio umbral. Con softmax, una etiqueta le quitaría probabilidad a la otra y la escondería.

Ejemplo. En C06 (moderación), el modelo da un score por cada una de 7 políticas. Un post con logits spam 2.0 y violencia 1.0 sale con 88.1 % y 73.1 % (con softmax habría sido 72.7 % y 26.8 %).

Que trabaja con más de un tipo de dato a la vez, como texto e imágenes. Un embedding multimodal pone fotos y textos en el mismo espacio, para compararlos directamente.

CLIP (OpenAI, 2021) tiene dos redes, una para imágenes y otra para texto, entrenadas juntas con aprendizaje contrastivo sobre unos 400 millones de pares (imagen, texto) para que una foto y su descripción queden cerca. Así, el vector de «tenis blancos» queda cerca del vector de la foto de unos tenis blancos.

Ejemplo. En C07 de la Ronda, un encoder tipo CLIP (512 dimensiones) permite buscar productos con texto o subiendo una foto.

Combinar una matriz de n × k con una de k × m para obtener una de n × m: cada casilla del resultado es el producto punto de una fila de la primera con una columna de la segunda.

Solo se puede si las dimensiones de adentro coinciden (las dos k); las de afuera dan el tamaño del resultado. El orden importa: A · B casi nunca es igual a B · A, y a veces ni siquiera se puede. Cada casilla pide k MACs, así que el total es n × m × k MACs, o 2 × n × m × k FLOPs. Es la operación central del deep learning: una capa densa sobre un batch es una sola multiplicación de matrices, una convolución se reorganiza como una, y la atención de un transformer usa dos. Las GPUs tienen circuitos, los tensor cores, que solo hacen esto.

Ejemplo. Las cantidades de dos compras, (2, 1, 3) y (1, 0, 2), por una tabla de 3 × 2 con el precio y los gramos de cada producto (playera: $50 y 200 g; gorra: $120 y 100 g; calcetines: $15 y 50 g). Sale una tabla de 2 × 2: la primera compra cuesta $265 y pesa 650 g; la segunda, $80 y 300 g. Fueron 2 × 2 × 3 = 12 MACs.

Repartir el trabajo entre varios procesos en vez de varios hilos. Cada proceso tiene su propio intérprete, su memoria y su GIL (el candado de Python que deja ejecutar Python a un solo hilo a la vez), así que sí calculan en paralelo, uno por núcleo. Cuesta memoria, porque cada uno carga su copia de todo, y mover datos entre ellos.

En Python es la forma de usar varios núcleos con código CPU-bound en Python puro: el módulo multiprocessing o concurrent.futures.ProcessPoolExecutor. Lo que se manda a otro proceso se copia (se serializa con pickle), y cada proceso arranca su propio intérprete y carga sus propias librerías y su propia copia del modelo. En serving, varios procesos iguales que atienden requests son workers: uvicorn --workers 4 son 4 procesos y 4 copias del modelo. En Kubernetes, lo normal es un proceso por contenedor y más copias del contenedor.

Ejemplo. Cuatro tareas de 2 s de CPU en Python puro: con 4 hilos tardan ≈ 8 s, igual que en fila; con 4 procesos, en una máquina de 4 núcleos, ≈ 2 s más lo que tardan en arrancar.

La pieza más chica de una red neuronal: multiplica cada entrada por un peso, suma todo más un sesgo y pasa el resultado por una activación.

Sus pesos y su sesgo son parámetros: los ajusta el entrenamiento. Una neurona con 3 entradas tiene 4 parámetros. Se juntan muchas en una capa. El nombre viene de las neuronas del cerebro, pero es solo una multiplicación y una suma.

Ejemplo. Entradas 0.5, 0.8 y 0.2; pesos 2, −1 y 3; sesgo 0.1: 1.0 − 0.8 + 0.6 + 0.1 = 0.9, y la ReLU deja pasar 0.9.

Restarle a cada número un promedio y dividirlo entre una desviación, para que los valores queden alrededor de 0 y en una escala parecida.

En imágenes se hace por canal, con la media y la desviación estándar del dataset con que se entrenó el modelo. Para los modelos entrenados con ImageNet son media [0.485, 0.456, 0.406] y desviación [0.229, 0.224, 0.225] para R, G y B. Hay que usar exactamente las del entrenamiento.

Ejemplo. R = 236 → 236 ÷ 255 = 0.925 → (0.925 − 0.485) ÷ 0.229 ≈ 1.92.

Dividir un vector entre su largo para que mida exactamente 1. Conserva la dirección y borra el largo.

El largo de Pitágoras (la raíz de la suma de los cuadrados) se llama norma L2; de ahí el nombre. Con embeddings normalizados, la similitud coseno es solo el producto punto, y la distancia euclidiana y el coseno ordenan a los vecinos igual (distancia² = 2 − 2 × coseno). No es la normalización de las fotos, que le resta a cada píxel un promedio y lo divide entre una desviación. Si promedias dos vectores normalizados, el resultado ya no mide 1 y hay que volver a normalizar.

Ejemplo. (4, 3) mide √(16 + 9) = 5; normalizado queda (0.8, 0.6), y 0.8² + 0.6² = 1. El vector (8, 6), que mide 10, también queda en (0.8, 0.6).

Escribir un número como una cifra entre 1 y 10 multiplicada por una potencia de diez: 86,400 = 8.64 × 10⁴. Sirve para números enormes o diminutos sin contar ceros.

La cifra se llama mantisa, y el número al que se eleva el 10, exponente; un exponente negativo es un número chico: 4 × 10⁻⁵ = 0.00004. Para multiplicar se multiplican las mantisas y se suman los exponentes; para dividir, se dividen y se restan. Python y las hojas de cálculo la escriben con una e: 8.64e+04 es 8.64 × 10⁴. El exponente dice el orden de magnitud.

Ejemplo. La ResNet-50 de C01 tiene 24,532,532 ≈ 2.45 × 10⁷ parámetros y hace ≈ 4.1 × 10⁹ multiplicaciones por foto; copiar la foto a la GPU tarda ≈ 4 × 10⁻⁵ s, 40 microsegundos.

Un documento donde mezclas código, resultados y notas, y corres el código por pedacitos. Muy bueno para explorar, malo para producción.

Puedes correr las celdas (los pedacitos de código) en cualquier orden, y por eso es fácil que algo funcione solo en tu máquina y solo esa vez. Para producción, el código pasa a archivos normales que corren siempre igual, de principio a fin.

Ejemplo. Entrenaste una primera versión en un notebook y funciona porque corriste la celda 3 antes que la 5. Si alguien lo corre de arriba abajo, falla. Para producción, ese código pasa a un archivo de Python que corre siempre igual.

Un procesador completo dentro del chip de la CPU: lee una instrucción, la ejecuta y pasa a la siguiente, miles de millones de veces por segundo. Una laptop trae de 8 a 16; un servidor, decenas.

Cada núcleo tiene sus registros y su propia caché, y corre su propio hilo al mismo tiempo que los demás. Para que un solo hilo termine pronto, procesa las instrucciones en cadena, adivina hacia dónde va a saltar el programa y reordena lo que no depende entre sí. Muchos núcleos x86 corren dos hilos de hardware a la vez (Hyper-Threading, o SMT en general) que comparten sus circuitos: juntos hacen un poco más que uno, no el doble. En la nube se renta por vCPU, que en las máquinas de Intel es medio núcleo. Con SIMD, un núcleo con AVX-512 hace hasta 64 FLOPs por ciclo en FP32. Ojo: los «CUDA cores» de una GPU no son núcleos en este sentido; lo más parecido a un núcleo dentro de una GPU es un SM.

Ejemplo. Con dos unidades FMA de 512 bits a 3 GHz, un núcleo hace como máximo 64 × 3 × 10⁹ ≈ 192 GFLOPS en FP32. La g4dn.xlarge de C01 tiene 2 núcleos físicos, que se ven como 4 vCPU.

Una conexión directa entre GPUs de NVIDIA, mucho más rápida que PCIe, el bus que las une con la CPU: 900 GB/s sumando los dos sentidos en una H100 SXM, 450 en cada uno, unas 7 veces PCIe Gen5. Es lo que permite partir un modelo entre varias GPUs de una máquina.

Cuando un modelo no cabe en una GPU se reparte entre varias (tensor parallelism), y en cada capa las GPUs juntan sus resultados parciales: dos veces por capa, decenas de capas por token. Por PCIe o por la red, eso frenaría cada paso. En las máquinas de 8 GPUs, unos chips llamados NVSwitch conectan todas con todas a la velocidad de NVLink. La A100 tiene 600 GB/s, sumando los dos sentidos; la T4, la L4 y la A10G no tienen NVLink. También sirve al entrenar con varias GPUs, que se pasan los gradientes en cada paso con la biblioteca NCCL.

Ejemplo. C10 parte un LLM de 70.6 mil millones de parámetros entre 2 H100. En un paso de decode con 40 conversaciones se pasan del orden de 105 MB: ≈ 0.23 ms por NVLink contra ≈ 1.6 ms por PCIe Gen5, en un paso de ≈ 15 ms.

Reconocimiento óptico de caracteres: leer el texto que aparece en una imagen y devolverlo como texto que la computadora puede usar.

Casi siempre son dos pasos: detectar dónde hay texto y luego reconocer qué dice. La salida es una secuencia de caracteres, y un campo solo está bien si todos lo están: por eso la confianza se calibra por campo. Se usa para leer documentos, tickets, placas o etiquetas.

Ejemplo. Leer «TALLA 27» en la foto de la etiqueta de un tenis, o los 18 dígitos de una CLABE en un estado de cuenta (C05).

Una forma de codificar una categoría: una columna por cada valor posible, con 1 en la del valor que tiene el ejemplo y 0 en todas las demás.

Evita inventar un orden o una distancia: con 1, 2 y 3, el modelo tendría un solo peso para la feature y el efecto del valor 3 quedaría obligado a ser el triple que el del 1. Con one-hot cada valor tiene su propio peso. Su costo: una columna por valor, así que con miles o millones de valores (ids de anuncios o de productos) se vuelve enorme y casi toda de ceros; ahí se usa hashing o embeddings. Un valor que no se vio al entrenar no tiene columna, así que se reserva una para «otro».

Analogía. Un formulario con casillas para marcar una sola opción: no se escribe el número de la opción, se marca su casilla. Se rompe con millones de opciones: un formulario así no cabría en ninguna hoja y habría que reimprimirlo con cada opción nueva. Para eso existe el hashing: un número fijo de casillas, y una fórmula decide cuál marcar.

Ejemplo. Tres giros de comercio: supermercado = [1, 0, 0], gasolinera = [0, 1, 0] y videojuegos = [0, 0, 1]. Cada fila suma exactamente 1.

Quedarse sin memoria (out of memory). Cuando en Linux ya no alcanza la RAM, el sistema operativo elige un programa corriendo, casi siempre el que más memoria usa, y lo mata sin avisarle; en un contenedor pasa lo mismo cuando llega a su propio límite. Kubernetes lo reporta como OOMKilled, con código 137.

El kernel lo hace como último recurso, cuando la RAM (o el tope de memoria de un cgroup) ya no alcanza. El proceso no se entera: no hay excepción ni traceback, y se pierden los últimos logs que no había escrito. En un contenedor de Kubernetes, el límite es limits.memory: el kernel mata al proceso aunque a la máquina le sobre memoria, y el kubelet lo reinicia. No es lo mismo que el MemoryError de Python (el sistema negó la memoria al pedirla, y el programa sí se entera) ni que CUDA out of memory (se acabó la VRAM de la GPU: es una excepción dentro del proceso). Se previene midiendo el pico, no el promedio, y limitando lo que crece con la carga.

Ejemplo. El gateway de C01 tiene 1 GiB. Un PNG de 40 MP ocupa ≈ 320 MB al decodificarse: con ≈ 80 MB de base y 160 MB de archivos en vuelo, caben 2 a la vez (≈ 880 MB); con 3 (≈ 1,200 MB), OOMKilled. Por eso PREPROCESS_CONCURRENCY=2.

La pieza que, con el gradiente en la mano, decide cuánto girar cada perilla. SGD es la regla simple; momentum y Adam son formas más listas de hacerlo.

SGD (stochastic gradient descent) aplica la regla tal cual, con el gradiente de un batch al azar. El momentum arrastra la dirección de los pasos anteriores. Adam guarda para cada perilla un promedio de sus gradientes recientes y otro de su tamaño, y con eso ajusta el paso de cada una por separado. Esos números extra por perilla se guardan en el checkpoint y ocupan memoria de la GPU.

Ejemplo. C01 usa Adam: 24.5 M de perillas × 2 promedios = 49 M de números extra, ≈ 196 MB.

La potencia de diez más cercana a un número: 86,400 es del orden de 10⁵. Dos cosas que difieren en un orden de magnitud están a 10 veces una de otra.

Para redondear al orden más cercano se mira la mantisa: si es menor que √10 ≈ 3.16 se queda la potencia; si no, se sube una. Hay quien llama orden de magnitud solo al exponente, sin redondear: con esa costumbre, 86,400 es del orden de 10⁴. En diseño de sistemas, una estimación sirve si atina al orden de magnitud: equivocarse por 2 veces rara vez cambia la decisión; por 10, sí, porque se pasa de un par de máquinas a un cluster.

Ejemplo. Leer la RAM (≈ 10⁻⁷ s) y la promesa de 200 ms de C01 (2 × 10⁻¹ s) están a más de seis órdenes de magnitud: ≈ 2 millones de veces.

Que un sistema decida por ti cuántas copias de tu programa correr, en qué máquinas, y que levante otra si una se cae.

También se encarga de cambiar a una versión nueva poco a poco, sin apagar el servicio. El orquestador de contenedores más usado es Kubernetes.

Ejemplo. En C01, Kubernetes mantiene varias copias de la API encendidas, agrega copias cuando sube el tráfico de la hora pico y, si una copia falla, levanta otra sola.

Cuando el modelo aprende demasiado bien sus ejemplos de entrenamiento, incluidas sus casualidades, y empeora con ejemplos nuevos. Memorizó.

Se reconoce en la curva de aprendizaje: la loss de entrenamiento sigue bajando mientras la de validación sube. Se combate quedándose con el mejor checkpoint (parar a tiempo), con más datos o data augmentation, y con trabas contra la memoria como el dropout.

Ejemplo. Época 8: loss de entrenamiento 0.55, de validación 0.80. Época 20: 0.10 y 1.15. La brecha pasó de 0.25 a 1.05: el modelo memoriza.

Cuando el resultado de una cuenta no cabe en el tipo de dato. En un entero, el número da la vuelta (en uint8, 255 + 1 = 0) o se queda en la orilla; en punto flotante, se vuelve infinito.

Los arreglos de enteros de NumPy y PyTorch dan la vuelta sin avisar; funciones como cv2.add de OpenCV se saturan (250 + 10 = 255); los enteros de Python nunca se desbordan. En punto flotante, lo que pasa del máximo del formato se vuelve inf, y de ahí suele salir un NaN: en FP16, el máximo es 65,504, y por eso las activaciones atípicas de un transformer pueden desbordarse en FP16.

Analogía. Un cuentakilómetros de 6 dígitos: después de 999,999 marca 000,000. Se rompe en que la computadora no avisa, y en que un entero con signo salta del más grande al más negativo.

Ejemplo. En uint8, aclarar una foto sumando 10 vuelve casi negro un blanco: 250 + 10 = 4. En FP16, e¹² ≈ 162,755 da infinito.

Si no hubiera ningún efecto, la probabilidad de ver una diferencia al menos tan grande como la que viste, solo por azar. Chico quiere decir «esto sería raro si no pasara nada».

Se calcula suponiendo que la hipótesis nula es cierta. No es la probabilidad de que el tratamiento funcione, ni la de que H0 sea cierta, y no dice qué tan grande es el efecto. Si no hay efecto, los p-values se reparten parejo entre 0 y 1: por eso, con un corte de 0.05, 1 de cada 20 pruebas sin efecto sale «significativa» por azar.

Ejemplo. Una diferencia de 1 punto con un error estándar de 0.355 puntos está a 2.8 errores estándar: p ≈ 0.005. La misma diferencia con 5,000 por brazo (error de 0.91) da p ≈ 0.27.

El percentil 99: el valor que deja abajo al 99 % de las requests. «p99 ≤ 200 ms» quiere decir que a lo más 1 de cada 100 tarda más de 200 ms.

Es una de las formas más comunes de prometer latencia, porque mira la cola: lo que viven las requests más lentas, las que vencen el timeout y las que la gente recuerda. A diferencia del promedio, brinca de golpe cuando la fracción de lentas pasa del 1 %. Necesita muchas muestras: con menos de 100, el p99 es simplemente la más lenta. Su primo, el p99.9, deja arriba a 1 de cada 1,000.

Ejemplo. C01 promete p99 ≤ 200 ms del lado del servidor. Con 10 millones de requests al día, ese 1 % permitido son 100,000 requests lentas al día.

Un marco de ceros alrededor de la entrada de una convolución, para que el filtro también se centre en las orillas y la salida no se encoja.

Con un filtro de k × k (k impar), padding (k − 1) ÷ 2 y stride 1, la salida mide lo mismo que la entrada: por eso casi todas las convoluciones de 3 × 3 llevan padding 1. Cerca de la orilla el filtro ve ceros en vez de imagen, así que las respuestas de la orilla suelen ser peores.

Ejemplo. Una entrada de 5 × 5 con un filtro de 3 × 3: sin padding sale de 3 × 3; con padding 1, (5 + 2 − 3) ÷ 1 + 1 = 5, del mismo tamaño.

La copia de los archivos leídos que el sistema operativo guarda en la RAM que nadie está usando. La segunda vez que se lee un archivo, sale de la RAM en vez del disco; si un programa necesita esa memoria, el sistema la suelta.

En Linux, el comando free la muestra como buff/cache: por eso la memoria «libre» casi siempre se ve baja, y lo que importa es la columna available. Las escrituras también pasan primero por ahí y llegan al disco un poco después, y por eso una USB se «expulsa» antes de sacarla. Con mmap, un proceso usa directo las páginas de la page cache, sin hacer otra copia, y varios procesos comparten las mismas. En un servidor, la page cache es la diferencia entre un reinicio de segundos y uno de minutos, y medir un arranque con ella llena engaña.

Ejemplo. C07 sirve desde la page cache 51.2 GB de vectores por máquina: si no estuvieran ahí, cada máquina le pediría ≈ 175,000 lecturas al azar por segundo a un disco de red que da 40,000.

Que varias tareas avancen en el mismo instante, cada una en su propio núcleo de la CPU (o en una GPU). Necesita hardware: con un solo núcleo, dos tareas nunca avanzan en el mismo instante.

Es lo único que acelera el trabajo de pura CPU: cuatro fotos de 40 ms de CPU tardan 160 ms en un núcleo y 40 ms en cuatro. Puede ir dentro de una tarea (4 hilos sobre la misma foto: menos latencia) o entre tareas (4 procesos, cada uno con su foto: más throughput). En CPython, los hilos no corren Python en paralelo por el GIL; sí lo hacen los procesos aparte y las librerías en C que lo sueltan. Una GPU es paralelismo en grande: miles de cuentas a la vez.

Ejemplo. La Ronda (M08) midió una ResNet-50 en 4 núcleos: 1 proceso con 4 hilos da ≈ 61 fotos por segundo, a ≈ 16.5 ms cada una; 4 procesos con 1 hilo, ≈ 86 fotos por segundo, a ≈ 46 ms.

Cada uno de los números internos de un modelo que el entrenamiento ajusta. Son sus «perillas».

Una combinación de valores de los parámetros hace que el modelo responda de una forma, y otra combinación, de otra. Entrenar es buscar la combinación con la que el modelo se equivoca menos. En inglés también se les dice weights (pesos).

Ejemplo. La ResNet-50 de C01 tiene unos 24.5 millones de parámetros con sus 500 categorías (25.6 millones en la versión original, de 1000).

Una vuelta del ciclo de entrenamiento con un batch: pasar las fotos por el modelo, medir la pérdida, calcular el gradiente y ajustar los parámetros.

Es la unidad con la que se cuenta el entrenamiento: el scheduler y el warmup se definen en pasos, y el checkpoint anota en qué paso iba. Pasos por época = ejemplos ÷ tamaño del batch, redondeado hacia arriba (o hacia abajo, si se tira el último batch incompleto).

Ejemplo. C01: 1,840,211 fotos ÷ 64 = 28,753.3, redondeado hacia arriba son 28,754 pasos por época; por 8 épocas, 230,032 pasos.

La conexión (el bus) por donde la CPU habla con las tarjetas de la máquina, como la GPU. Va por carriles, y cada generación duplica la velocidad: una GPU con 16 carriles Gen3, como la T4, recibe ≈ 16 GB/s en cada sentido.

Cada carril tiene cables para ir y otros para volver, así que las dos direcciones van a la vez: Gen3 da ≈ 1 GB/s por carril en cada sentido, Gen4 ≈ 2 y Gen5 ≈ 4. NVIDIA suele anunciar las dos direcciones sumadas (64 GB/s para la Gen4 x16 de la L4). La copia la hace la GPU leyendo directo de la RAM (DMA), desde memoria fijada (pinned). Para una foto, PCIe casi no cuenta; importa con lo grande o lo repetido: cargar los pesos de un LLM, video sin comprimir o tensores que van y vienen entre la CPU y la GPU en cada request. Entre GPUs se usa NVLink, mucho más rápido.

Ejemplo. El tensor de Ana, 602,112 bytes en float32, cruza PCIe Gen3 x16 en ≈ 38 µs: ≈ 1 % del cálculo de la GPU y nada contra los 2 a 4 ms de la red. Los ≈ 49 MB de pesos de la ResNet-50 de C01 en FP16, una sola vez al arrancar: ≈ 3 ms.

Revisar un A/B cada rato y pararlo en cuanto sale «significativo». Cada mirada es otra oportunidad de que el ruido cruce la raya: mirando 14 días, las falsas alarmas pasan del 5 % a más del 20 %.

El 0.05 de un p-value vale para un análisis al final, con la muestra que se fijó antes. Hay dos salidas: fijar duración y muestra antes y decidir solo al final (los guardrails sí pueden parar un daño, pero no declarar victoria), o usar una prueba secuencial, diseñada para mirar muchas veces sin inflar el error.

Ejemplo. En 2,000 A/A simulados de 14 días: decidiendo solo el día 14, 5.2 % de falsas alarmas; parando el primer día que p < 0.05, 22.9 %. La Ronda, con 20,000 A/A, da 21.5 %.

El percentil p es el valor que deja en él o abajo de él al p % de los datos. El p50 es la mediana; el p99 solo deja arriba a 1 de cada 100.

Se calcula ordenando los datos. Con el método del rango más cercano, la posición es p ÷ 100 × n, redondeada hacia arriba (redondear hacia arriba (ceil)). Otros métodos interpolan entre dos vecinos, y con pocos datos dan números distintos en la cola: importa usar siempre el mismo. Las herramientas de monitoreo los llaman cuantiles y los escriben como fracción (0.99). No se suman ni se promedian: el p99 de varios servidores se saca sumando sus buckets y calculando al final.

Ejemplo. Con 20 latencias ordenadas, el p95 es la 19.ª (0.95 × 20 = 19), 160 ms, y el p99 es la 20.ª (19.8 se redondea a 20), la más lenta, 900 ms.

Una de las primeras neuronas artificiales que aprendían solas (Frank Rosenblatt, 1958): suma sus entradas con pesos y responde 1 si la suma pasa de 0. Solo puede separar lo que se separa con una recta.

Su regla de aprendizaje es corregirse solo cuando se equivoca: si dijo 0 y era 1, le suma cada entrada a su peso; si dijo 1 y era 0, se la resta. Aprende el AND en unas cuantas vueltas, pero nunca el XOR, porque su frontera es una recta y los casos del XOR no se separan con una. Minsky y Papert convirtieron ese límite en teorema en 1969; se resolvió con capas ocultas, el MLP.

Ejemplo. Con w₁ = 2, w₂ = 1 y b = −2 calcula el AND: solo la entrada (1, 1) da una suma positiva, 2 + 1 − 2 = 1.

Un número que mide qué tan equivocado está el modelo: 0 si acierta con total seguridad, y más grande mientras peor le va. Entrenar es hacer que baje.

La fórmula depende de la tarea. Para clasificar, la más usada es la entropía cruzada: −ln de la probabilidad que el modelo le dio a la respuesta correcta. Para predecir un número, el error cuadrático medio. Para un batch se promedian las de todos sus ejemplos. A diferencia de contar aciertos, cambia un poquito con cada cambio pequeño de las perillas, y por eso dice hacia dónde mejorar.

Ejemplo. El modelo le da 94 % a «Tenis» y eran tenis: −ln(0.94) ≈ 0.062. Si le diera 10 %: −ln(0.10) ≈ 2.30. Un modelo que reparte parejo entre 500 categorías: −ln(1/500) ≈ 6.21.

Lo que cada usuario puede hacer con un archivo: leerlo (r), escribirlo (w) o ejecutarlo (x), en tres juegos: para el dueño, para su grupo y para los demás. Se escriben en letras (rwxr-x---) o en octal (750).

Cada proceso corre como un usuario, que el kernel conoce por un número, el UID, y que pertenece a grupos (GID). Cada archivo tiene un dueño, un grupo y 9 bits de permiso. Cada juego de 3 bits es un número del 0 al 7 (r = 4, w = 2, x = 1): por eso rwxr-x--- es 750. En una carpeta, r deja ver los nombres, w crear y borrar adentro, y x entrar: para leer un archivo hace falta x en todas las carpetas de su ruta. Se cambian con chmod (los bits) y chown (el dueño). Cuando no alcanzan, el kernel responde «Permission denied» (errno 13). Root se los salta.

Ejemplo. 644 (rw-r--r--) para el código, 755 (rwxr-xr-x) para un programa o una carpeta, 600 (rw-------) para una llave privada. En C02, la configuración con la contraseña de las cámaras se guarda con 0600. Nunca 777: cualquiera podría cambiarlo.

El número con el que el sistema operativo identifica a un proceso (un programa corriendo) mientras vive. Con él se le habla; por ejemplo, para pedirle que termine.

Lo asigna el kernel al crear el proceso, en orden; al llegar al tope vuelve a empezar y reusa los de procesos que ya terminaron. Por eso cambia en cada corrida. Cada proceso conoce también el PID de su padre (el PPID), y así los procesos forman un árbol. El PID 1 es el primero que arranca: en Linux suele ser systemd; en una Mac, launchd. Un contenedor tiene su propia numeración: adentro, el PID 1 es el programa principal (por fuera, la máquina le da otro número), y tiene una regla especial: el kernel no le aplica la acción por omisión de una señal (salvo la de un SIGKILL que llegue de afuera), así que si no maneja SIGTERM, la señal se ignora.

Ejemplo. kill 4821 le manda SIGTERM al proceso con PID 4821. En la imagen del gateway de C01, el CMD en forma exec hace que uvicorn sea el PID 1 y reciba el SIGTERM de cada deploy.

Una cadena de pasos donde lo que sale de uno es lo que entra al siguiente, y que se puede volver a correr igual.

Lo importante es que se pueda volver a correr igual: si cada paso lee una versión fija de lo que le entra y guarda lo que sale, cualquiera puede repetir el resultado o encontrar en qué paso se rompió. En producción casi todo es un pipeline: el de datos, el de entrenamiento y el de despliegue.

Analogía. Una línea de ensamblaje: cada estación hace una cosa y le pasa la pieza a la siguiente.

Ejemplo. El camino de C01 es un pipeline: datos → modelo → API → contenedor → orquestación → monitoreo.

Cada cuadrito de un solo color en que se divide una imagen digital. En una foto a color, cada píxel son tres números: cuánto rojo, cuánto verde y cuánto azul.

Una foto es una cuadrícula de píxeles: tantos de ancho por tantos de alto. Por eso, para un modelo, una foto no es un dibujo sino una tabla de números.

Ejemplo. Un píxel naranja: R 236, G 106, B 63.

Un formato de imagen que comprime sin pérdida: al decodificar salen exactamente los mismos píxeles. Puede tener transparencia.

Es bueno para capturas de pantalla, logos y dibujos; para fotos ocupa bastante más que un JPEG. Puede venir con 4 canales (RGBA), en blanco y negro, con 16 bits por canal o con una paleta de colores: hay que convertirlo a RGB antes del modelo, y antes de achicarlo.

Ejemplo. Un PNG de 40 MP con transparencia y 16 bits por canal ocupa 40 M × 4 × 2 B = 320 MB al decodificarse.

Todo el conjunto del que quieres saber algo: todas las fotos que el modelo va a ver, todos los vendedores, todos los votantes. Casi nunca se mide completa; se estima con una muestra.

El número de la población (la accuracy «de verdad», la tasa de aceptación real) es fijo pero desconocido. La muestra da una estimación con su ruido. Ojo: la población de producción cambia con el tiempo (drift), así que un examen de hace 8 meses describe a la población de hace 8 meses.

Ejemplo. Si el modelo de C01 acierta el 85 % de todas las fotos que suben los vendedores este mes, ese 85 % es un número de la población. Nadie lo ve completo: se estima con exámenes de miles de fotos.

Resumir cada cuadrito de un mapa en un solo número (el mayor, o el promedio) para achicarlo. No tiene parámetros: no aprende nada.

Un max pooling de 2 × 2 con stride 2 deja los mapas con la cuarta parte de los números; su tamaño sale de la misma fórmula que el de una convolución. Se pierde exactamente dónde estaba algo dentro del cuadrito, pero se conserva que sí estaba. Al final de la ResNet-50, un pooling global promedia cada mapa entero en un número.

Ejemplo. El cuadrito 5, 6, 7, 3 con max pooling da 7.

La probabilidad de que una prueba detecte un efecto que sí existe, de un tamaño dado. Lo normal es pedir 80 %: de cada 5 efectos reales de ese tamaño, se ven 4.

El 20 % que falta (β, beta) son efectos que se escapan: un error tipo II. La potencia sube con más muestra, con un efecto más grande y con una significancia menos estricta. Una prueba sin potencia no dice nada cuando sale «no significativa»: no vio, pero tampoco podía ver.

Ejemplo. En C01, con 32,647 publicaciones por brazo, un efecto real de 1 punto sobre 70 % se detecta el 80 % de las veces. Con 5,000 por brazo, solo ≈ 20 % de las veces.

De todas las veces que el modelo dijo «sí», qué fracción era verdad. Mide qué tanta basura hay en lo que el modelo señala.

Se calcula como verdaderos positivos / (verdaderos positivos + falsos positivos). Se puede inflar diciendo «sí» muy pocas veces, por eso se mira junto con el recall. Cuando los positivos son rarísimos, puede ser muy baja aunque la curva ROC se vea excelente: ahí se mira la curva PR.

Ejemplo. El modelo dijo «tenis» 120 veces y acertó 80: precision = 80 / 120 ≈ 66.7 %.

Entrenar con las cuentas pesadas en 16 bits (FP16 o BF16) y lo delicado en FP32: una copia maestra de los pesos en FP32 y, con FP16, una escala de la pérdida para que los gradientes chicos no se vuelvan 0.

Tres ideas: (1) los pesos de verdad viven en FP32 y cada paso usa una copia en 16 bits, para que los cambios chicos no se pierdan; (2) convoluciones y multiplicaciones de matrices en 16 bits en los tensor cores, acumulando en FP32, y softmax, pérdida y normalizaciones en FP32 (en PyTorch lo decide torch.autocast); (3) con FP16, la pérdida se multiplica por una escala (al principio, 65,536) antes de la backpropagation y los gradientes se dividen después. El GradScaler salta los pasos con inf o NaN y ajusta la escala. Con BF16 no hace falta la escala. Con Adam ocupa ≈ 16 bytes por parámetro: no ahorra memoria fija, pero baja las activaciones a la mitad y acelera mucho.

Ejemplo. C01 hace su fine-tune mensual con AMP. Un gradiente de 10⁻⁸ se vuelve 0 en FP16; con la pérdida multiplicada por 65,536 queda en ≈ 0.000655, que sí cabe, y al dividirlo vuelve como ≈ 10⁻⁸.

La respuesta que da un modelo para un caso. No es una certeza: suele venir con qué tan seguro está, como una probabilidad.

Sale de la inferencia: el modelo calcula un número para cada respuesta posible y los convierte en probabilidades. La predicción es la respuesta más probable, o las primeras de la lista. Que diga 94 % no garantiza que acierte: qué tanto se le puede creer a ese número se ve en la lección «Qué es un modelo».

Ejemplo. «Calzado › Tenis, 94 %» es una predicción: el modelo cree que es eso, con una confianza de 94 %. Se lee como una probabilidad, aunque no siempre es exacta.

La primera y más cara etapa de un LLM: aprender a adivinar el siguiente token con enormes cantidades de texto. De ahí sale un modelo base, que continúa textos pero todavía no conversa.

No necesita etiquetas hechas por personas: el token que sigue ya está escrito en el texto, y esa es la respuesta de cada ejercicio. La pérdida es la entropía cruzada de cada predicción. Cuesta semanas o meses de miles de GPUs, así que casi nadie lo hace: se parte del modelo base que publicó alguien más y se le hacen las etapas siguientes (ajuste con instrucciones y ajuste por preferencias).

Ejemplo. Llama 3 se preentrenó con más de 15 billones (15 × 10¹²) de tokens. La frase «Ana vende sus tenis blancos.» (8 tokens) da 7 ejercicios: adivinar cada token a partir de los que tiene antes.

Los múltiplos de 1,024 en vez de 1,000: 1 KiB = 1,024 bytes, 1 MiB = 1,024 KiB, 1 GiB = 1,024 MiB. Llevan una i: KiB, MiB, GiB, TiB.

Las computadoras cuentan en potencias de 2, y 2¹⁰ = 1,024 se parece a mil, así que por décadas «kilobyte» quiso decir las dos cosas. En 1998 la IEC separó los nombres: KB son 1,000 bytes (decimal) y KiB, 1,024 (binario). La diferencia crece con cada prefijo: 2.4 % en kilo, 7.4 % en giga, 10 % en tera. Los discos y las redes usan decimal; la RAM, Windows, nvidia-smi y PyTorch, binario. En una misma cuenta se usa una sola regla.

Ejemplo. Un disco de 1 TB tiene 10¹² bytes; Windows los divide entre 2³⁰ y muestra ≈ 931 «GB», que en realidad son GiB. No falta nada: es otra regla.

La primera fase de cada request a un LLM: leer todo el prompt de una sola pasada, en paralelo, y guardar su K y su V en el KV cache. Termina con el primer token de la respuesta.

Como todos los tokens del prompt ya existen, se procesan juntos: cada peso que llega de la memoria se usa para miles de tokens a la vez, así que lo que manda es la velocidad de cálculo de la GPU (compute-bound). Su duración crece con el largo del prompt y, junto con la espera en la cola, forma el TTFT. El prefix caching se salta la parte del prompt que ya se calculó antes.

Ejemplo. En C10 de la Ronda, el prefill de un prompt de 2,000 tokens ocupa ≈ 150 ms de una réplica de 2 H100.

Reutilizar el KV cache del inicio de un prompt que ya se calculó en un request anterior, para no repetir su prefill. Solo sirve si los tokens son idénticos desde el principio.

Muchos requests de un producto empiezan igual: el system prompt, los ejemplos few-shot (ejemplos en el prompt), las políticas. El servidor guarda el KV cache de esos tokens y, si el siguiente prompt empieza exactamente igual, se salta esa parte del prefill: baja el TTFT y el cómputo. Basta un token distinto al principio (la fecha, el nombre de la persona) para que ya no sirva: lo fijo va primero y lo variable al final.

Ejemplo. En C10 de la Ronda, la mitad de un prompt de 2,000 tokens es el prefijo fijo del producto: con prefix caching, el prefill solo calcula los ≈ 1,000 tokens restantes.

Todos los pasos que convierten la entrada cruda (una foto) en la tabla de números exacta que el modelo espera: decodificar, girar, redimensionar, recortar y normalizar.

Tiene que ser idéntico al entrenar y al servir. Si cambia aunque sea un detalle (el orden de los colores, cómo se redimensiona), nada falla con error: el modelo simplemente acierta menos. A eso se le llama training-serving skew, y se evita con un solo código para los dos lados y una prueba de paridad.

Ejemplo. C01: decodificar → EXIF → RGB → resize 256 → crop 224 → ÷ 255 → normalizar → CHW float32.

Lo que un SLO te deja fallar: 1 − SLO. Con 99.9 % en 30 días son 43.2 minutos, o 1 de cada 1,000 requests. Es un presupuesto para gastarlo en cambios y experimentos, no para guardarlo.

La idea viene de la ingeniería de confiabilidad de Google (SRE). Se convierte en una política escrita antes de los problemas y acordada con producto: con presupuesto de sobra se lanza normal; con poco, con más cuidado; agotado, se congela lo que no sea para mejorar la confiabilidad. Las alertas se arman con la velocidad a la que se gasta (burn rate): con 5 % de errores contra un SLO de 99.9 % se gasta 50 veces más rápido de lo permitido, y el presupuesto del mes dura 14.4 horas.

Ejemplo. C01: 0.001 × 10 millones de requests al día × 30 días = 300,000 requests fallidos permitidos al mes. Un deploy que hace fallar el 5 % durante 2 horas se come ≈ 41,667, el 14 % del mes.

Un número de 0 a 1 (o de 0 % a 100 %) que dice qué tan posible es algo. 0.25 es una de cada cuatro veces.

Las probabilidades de todas las opciones posibles suman 1. En un clasificador, las que salen de softmax o de la sigmoide son la estimación del modelo, no una verdad medida: qué tan buenas son se revisa con datos.

Ejemplo. Si de 1,000 fotos a las que el modelo les dio 0.9, aciertan 900, sus probabilidades de 0.9 están bien calibradas.

Un programa corriendo. El sistema operativo le da memoria propia, un número que lo identifica (el PID) y al menos un hilo, una línea de ejecución, y lo turna en la CPU con los demás procesos.

Es la unidad con la que el kernel reparte la máquina. Cada proceso tiene su memoria, que los otros no pueden tocar; su PID y el de su padre; uno o más hilos; los archivos y conexiones que abrió; sus variables de entorno y el usuario con el que corre. Termina con un código de salida, porque acabó o porque lo mató una señal, y al terminar el kernel recupera toda su memoria. Un contenedor es, por dentro, uno o más procesos con una vista propia de la máquina.

Analogía. Cocinar la receta ahora, en una cocina con su mesa (la memoria), sus ingredientes (los datos) y su número de orden (el PID). Se rompe en que, al terminar, la cocina se borra completa en un instante: nada de lo que había en la mesa sobrevive.

Ejemplo. uvicorn --workers 4 arranca 4 procesos que atienden requests, más uno que los vigila. Si cargan un modelo en la GPU, son 4 copias de los pesos y 4 contextos de CUDA.

Cuando el sistema ya lo usa gente real, todos los días, y si falla alguien lo nota.

Lo contrario es desarrollo: tu laptop o un notebook, donde puedes romper cosas sin que nadie se entere. Pasar algo de uno a otro, o cambiar la versión que responde por una nueva, es un deploy.

Ejemplo. El modelo de C01 está en producción: cada foto que alguien sube al marketplace pasa por él, de día y de noche. Si deja de responder, miles de personas tienen que buscar la categoría a mano.

Multiplicar dos vectores coordenada por coordenada y sumar todo. Da un solo número: positivo si apuntan hacia el mismo lado, cero si son perpendiculares y negativo si apuntan hacia lados opuestos.

Es igual a (largo de a) × (largo de b) × el coseno del ángulo entre ellos, así que mezcla dirección y largo: una flecha más larga saca productos punto más grandes con todo. Visto en el dibujo, es la «sombra» de una flecha sobre la dirección de la otra, multiplicada por el largo de la otra. Con vectores normalizados es exactamente la similitud coseno. Es la cuenta más repetida de ML: una neurona es un producto punto más un sesgo, la última capa de un clasificador hace uno por clase, la atención compara vectores con productos punto y una búsqueda exacta hace uno por cada vector del catálogo.

Analogía. Un ticket de compra: las cantidades (2, 1, 3) por los precios (50, 120, 15), sumadas, dan el total, 265. Se rompe en que en un ticket casi nunca hay cantidades negativas, y en un embedding los números negativos son normales: por eso el producto punto puede salir negativo.

Ejemplo. (4, 3) · (3, 4) = 4 × 3 + 3 × 4 = 24. (4, 3) · (−3, 4) = −12 + 12 = 0: son perpendiculares. Con 512 números son 512 multiplicaciones y 511 sumas.

Un archivo, o un grupo de archivos, con instrucciones para una computadora. En el disco no hace nada; cuando lo arrancas, a ese programa corriendo se le llama proceso.

Puede ser código fuente, texto que escribe una persona y que un intérprete lee al correr (como los archivos .py del gateway de C01), o un binario ejecutable ya compilado a instrucciones de máquina (como tritonserver). Del mismo programa pueden correr muchos procesos a la vez, cada uno con su propia memoria. La imagen de un contenedor es al contenedor lo que el programa al proceso: la plantilla quieta.

Analogía. La receta escrita: dice qué hacer, pero no cocina nada. Se rompe en que a una receta la sigue alguien que improvisa; a un programa, la CPU lo sigue al pie de la letra.

Ejemplo. El gateway de C01 es un programa: una carpeta con app.py y sus librerías. Con 3 pods, ese único programa corre como 3 procesos.

La suma de todos los valores dividida entre cuántos son. Es lo que le tocaría a cada uno si el total se repartiera parejo.

Es el número correcto para los totales: con el promedio y la cantidad sabes el total, como cuánto cuesta servir un día o cuántas requests hay dentro del sistema a la vez. Pero un solo valor muy lejano lo jala mucho. En latencia engaña de otra forma: si las lentas son pocas, lo suben solo un poco (98 requests de 30 ms y 2 de 3 s promedian 89.4 ms, abajo de 200) y no dice cuántas personas esperaron de más; por eso las promesas usan percentiles. La pérdida de un batch y la accuracy son promedios.

Analogía. El punto donde apoyarías con un dedo una regla con monedas puestas en la marca de cada valor, para que no se caiga. Una moneda muy lejos obliga a mover mucho el dedo.

Ejemplo. 30, 32, 35, 38 y 45 ms suman 180, y el promedio es 180 ÷ 5 = 36 ms. Con 98 requests de 30 ms y 2 de 3 s, el promedio es 89.4 ms, aunque 2 de cada 100 personas esperaron 3 segundos.

El texto que se le da al modelo de lenguaje para que continúe: la pregunta, las instrucciones y, a veces, documentos o ejemplos.

El modelo lo lee completo antes de escribir el primer token de la respuesta (el prefill). En una app suele tener partes: el system prompt, ejemplos few-shot (ejemplos en el prompt), documentos y la pregunta. Un prompt largo cuesta más dinero, ocupa más KV cache y tarda más en dar el primer token.

Ejemplo. En C10 de la Ronda, un prompt típico tiene ≈ 2,000 tokens y la respuesta ≈ 250.

Repartir al azar a la gente en dos grupos, al mismo tiempo: uno con lo de siempre (A, el control) y otro con el cambio (B, el tratamiento), y comparar una métrica. Es la forma de saber si el cambio causa una mejora.

El azar reparte por igual todo lo demás (la temporada, el tipo de usuario, el celular), así que la única diferencia sistemática entre los brazos es el cambio. Antes de empezar se fijan la métrica primaria, los guardrails (métricas que no tienen que mejorar, pero no pueden empeorar), la unidad de aleatorización, el efecto mínimo, el tamaño de muestra y la duración. Se analiza con una prueba de hipótesis nula y su p-value.

Ejemplo. En C01, los vendedores se reparten 50/50 con un hash de su id: A ve las sugerencias del modelo actual y B las del nuevo. Con 33,000 publicaciones por brazo, 70.0 % contra 71.0 % de aceptación da p ≈ 0.005.

Compara conteos de categorías contra los que esperabas: suma (observado − esperado)² ÷ esperado. Si el total pasa un valor crítico, la diferencia es «significativa».

Los esperados salen de la referencia: el total de hoy por la proporción de cada categoría en la referencia. El valor crítico depende de cuántas categorías hay: con K categorías se usan K − 1 «grados de libertad» (con 5 categorías, 4, y el corte al 5 % es 9.49). Para cambios chicos, chi-cuadrado ≈ n × PSI: con las mismas proporciones, cien veces más datos dan un chi-cuadrado cien veces más grande. Por eso, con millones de predicciones al día, casi cualquier cambio sale significativo: sirve para saber si hay evidencia de un cambio, y el PSI para saber si el cambio importa.

Ejemplo. Mezcla de 5 categorías padre de C01, con 1 punto de diferencia en dos de ellas: con 1,000 predicciones, chi-cuadrado ≈ 1.33 (nada); con 100,000, ≈ 133 (p ≈ 8 × 10⁻²⁸). El PSI es 0.0013 en los dos casos.

Una prueba que pasa las mismas entradas por dos caminos que deberían dar lo mismo y compara las salidas número por número. Si no coinciden, algo cambió.

En imágenes vigila el preprocesamiento: en cada cambio de código, unas fotos fijas pasan por el camino del entrenamiento y por el del servicio real, y los tensores se comparan entre sí y con unos guardados, con la diferencia absoluta máxima. Con el mismo código y las mismas versiones, debe ser 0. La misma idea compara el modelo original con el que se sirve (por ejemplo, PyTorch en float32 contra TensorRT en float16), contando cuántas veces coinciden sus predicciones.

Ejemplo. C01 corre 20 fotos de referencia en cada cambio. Si alguien pasa el gateway a OpenCV, el canal R del naranja cambia de 1.92 a −1.04 y la prueba falla antes de llegar a producción.

Compara dos muestras de un número midiendo la distancia vertical más grande, D, entre sus curvas acumuladas. D va de 0 (iguales) a 1 (todos los datos de una quedan antes que todos los de la otra).

La curva acumulada de una muestra dice, para cada valor x, qué fracción de los datos es menor o igual a x: sube de 0 a 1 en escalones, uno por dato. La prueba pone las dos curvas juntas y busca dónde se separan más: eso es D. No necesita bins. También da un p-value: qué tan raro sería un D así de grande si las dos muestras salieran de la misma distribución. En monitoreo ese p-value engaña: el D que ya cuenta como «significativo» es ≈ 1.36 × √(2 ÷ n), con n datos por lado, así que con millones de datos cualquier cambio minúsculo lo es. Se usa D como tamaño del cambio, con un umbral calibrado, o la prueba sobre muestras chicas.

Ejemplo. Con 1 millón de datos por lado y una media corrida 0.02 desviaciones estándar (nada que importe), D ≈ 0.008 y el umbral es 0.0019: p ≈ 8 × 10⁻²⁹. Con 5 fotos por lado, el umbral es ≈ 0.86.

Comparar dos modelos sobre exactamente los mismos ejemplos, uno por uno, en vez de comparar sus dos promedios por separado. Es mucho más sensible, porque el ruido de qué ejemplos tocaron se cancela.

Donde los dos aciertan, o los dos fallan, no hay información sobre quién es mejor; todo está en los ejemplos donde discrepan. Si fueran igual de buenos, cada discrepancia sería un volado: con b a favor de uno y c a favor del otro, z = (b − c) ÷ √(b + c). Esa es la prueba de McNemar (su χ² es z²). El gate de C01 la usa sobre el golden set.

Ejemplo. 50,000 fotos; solo el modelo nuevo acierta en 1,050 y solo el actual en 950. z = 100 ÷ √2,000 ≈ 2.24, p ≈ 0.025. Comparando las dos accuracies (85.2 % y 85.0 %) por separado: p ≈ 0.38.

Un número que dice cuánto se movió un histograma respecto a su referencia: la suma, bin por bin, de (actual − esperado) × ln(actual ÷ esperado). Menos de 0.1 es estable; más de 0.25, un cambio grande.

Se arma con los mismos bins en los dos lados, en proporciones que suman 1. Cada bin aporta un número mayor o igual a 0, porque la diferencia y el logaritmo del cociente siempre tienen el mismo signo. Es la divergencia KL en las dos direcciones, sumadas. A diferencia de un p-value, no crece con la cantidad de datos, así que sirve como tamaño del cambio. Los cortes 0.1 y 0.25 vienen de los bancos (credit scoring) y son costumbre, no ley: se calibran mirando cuánto se mueve en semanas normales. Como guía, en una variable con forma de campana, una media que se corre δ desviaciones estándar da un PSI de ≈ δ². Un bin vacío hace ln(0): se usan bins por cuantiles de la referencia y un piso fijo (epsilon).

Ejemplo. Brillo de las fotos de C01 en 5 bins: referencia 10, 20, 40, 20 y 10 %; una semana de noviembre con muchas fotos de noche, 22, 30, 30, 12 y 6 %. PSI ≈ 0.23: cambio moderado, arriba del 0.2 desde el que actúa C01.

La forma en que la computadora guarda números con decimales: como notación científica en base 2, con un bit de signo, un exponente que dice dónde va el punto y una mantisa con los dígitos.

El valor es (−1)^signo × 1.mantisa × 2^(exponente − sesgo). Los bits de exponente dan el rango; los de mantisa, la precisión. Entre cada potencia de 2 y la siguiente cabe la misma cantidad de números, así que la separación crece con el tamaño y el error de redondeo es relativo. Hay valores especiales: infinito (inf) y NaN (not a number), que contagia a toda cuenta en la que entra. Los formatos que vas a oír: FP64, FP32, FP16, BF16 y FP8.

Analogía. La notación científica de toda la vida, 1.50528 × 10⁵, pero con potencias de 2 y un número fijo de dígitos. Se rompe en que casi ningún decimal, como 0.1, tiene una escritura exacta en base 2: se guarda redondeado.

Ejemplo. 6.5 = 110.1₂ = 1.101₂ × 2². En FP32: signo 0, exponente 2 + 127 = 129 (1000 0001) y mantisa 101 seguida de 20 ceros.

La resta entre dos porcentajes: de 85 % a 87 % son 2 puntos porcentuales, aunque el cambio relativo sea de 2.4 %.

«Subió 2 %» y «subió 2 puntos» son cosas distintas: lo primero es multiplicar por 1.02; lo segundo, sumarle 2 al porcentaje. Con métricas y disponibilidad conviene decir los dos. Pasar de 99.9 % a 99.99 % son solo 0.09 puntos, pero la caída permitida se divide entre 10: de ≈ 43 a ≈ 4.3 minutos al mes.

Ejemplo. El gate de C01 no deja pasar un modelo que quede más de 0.3 puntos abajo del actual: si el actual saca 96 % de top-5, el nuevo pasa con 95.7 % y no con 95.6 %.

Los tres vectores que la atención calcula para cada token: Q (query, lo que busca), K (key, la etiqueta con la que se ofrece a los demás) y V (value, la información que entrega).

Se obtienen multiplicando el vector del token por tres tablas de parámetros distintas, aprendidas en el entrenamiento. Qué tanto atiende un token a otro sale de comparar la Q del primero con la K del segundo; lo que recibe es la V del segundo. Las K y V de los tokens anteriores son las que se guardan en el KV cache.

Analogía. Como buscar en un tablero de anuncios: tu Q es lo que necesitas, la K de cada anuncio es su título y la V es lo que dice el anuncio. Lees más a fondo los anuncios cuyo título se parece a lo que buscas. Se rompe en que aquí no eliges uno: mezclas todos, cada uno con su porcentaje.

Ejemplo. En el ejemplo de la lección, la Q de «banco» es (1, 0) y la K de «senté» es (3, 0): su producto punto, 3, es la calificación más alta, así que el nuevo vector de «banco» toma sobre todo la V de «senté» (77.8 %).

Cuántas requests o consultas llegan por segundo. Es la unidad con la que se dimensiona un servicio.

Se calcula dividiendo el volumen de un día entre 86,400 segundos: 1 millón al día son ≈ 11.6 por segundo. Ese es el promedio; para dimensionar se usan el pico y el pico de diseño (ver factor de pico). «QPS» viene de los buscadores (queries); «req/s» dice lo mismo para cualquier API.

Ejemplo. C01: 10,000,000 ÷ 86,400 ≈ 116 req/s de promedio, ≈ 350 en la hora pico y 500 de diseño. Las búsquedas de C07: 50 M al día, ≈ 579 de promedio y ≈ 1,750 en el pico.

Primero buscar los documentos que sirven para la pregunta y después pedirle al LLM que conteste usándolos. «Buscar y luego responder.»

La búsqueda es un retrieval (recuperación) sobre embeddings de los documentos, a veces con re-ranking (reordenar). Los pedazos encontrados se pegan en el prompt. Así el modelo puede contestar con información que no vio al entrenar (la política de devoluciones de esta semana) y citar de dónde la sacó. No elimina las alucinaciones, pero las reduce y las hace verificables.

Ejemplo. Pregunta: «¿cuántos días tengo para devolver unos tenis?». El sistema busca la política de devoluciones del marketplace, la pone en el prompt y el modelo responde con lo que dice el documento.

La memoria de trabajo de la computadora: donde viven los programas que están corriendo y los datos que usan. Es rápida (≈ 100 nanosegundos por lectura), pero se borra al apagar y cabe mucho menos que en un disco.

Cada byte de la RAM tiene una dirección, un número, y cualquiera se lee en casi el mismo tiempo, sin importar el orden: de ahí su nombre, random access memory («memoria de acceso aleatorio»). Está hecha de DRAM: cada bit es una carguita eléctrica en un capacitor diminuto que se escapa sola, así que el chip la refresca cada pocas decenas de milisegundos y sin luz la pierde. La CPU solo calcula con lo que está en la RAM (y le llega por su caché): por eso todo programa y todo archivo se copia del disco a la RAM antes de usarse. Una laptop trae de 8 a 32 GB y un servidor, de decenas de GB a varios TB, con un ancho de banda de decenas a cientos de GB/s, según la máquina (120 GB/s en una Mac M4). La GPU tiene su propia memoria aparte, la VRAM.

Analogía. La bodega de la cocina: cabe mucho más que en la mesa junto a la estufa (la caché), pero cada viaje tarda. Se rompe en que la RAM se vacía completa en cuanto se va la luz.

Ejemplo. Una foto de 12 MP, como las que toma el celular de Ana, ocupa 36.6 MB de RAM ya decodificada; el tensor que llega al servidor de GPU de C01, 602 KB. Ese servidor, una g4dn.xlarge, trae 16 GiB de RAM.

La tarea de ordenar una lista de opciones de la más a la menos relevante. Importa el orden, no el puntaje exacto.

Se usa en búsqueda, recomendaciones y anuncios. Muchas veces el modelo es un clasificador que estima una probabilidad (por ejemplo, de que alguien haga clic) y la lista se ordena por esa probabilidad. Si el puntaje combina dos probabilidades, las dos tienen que estar calibradas.

Ejemplo. En C08, unas 1,000 publicaciones candidatas se ordenan por P(click) × (P(contacto | click) + 0.05).

La segunda etapa de una búsqueda: después de una primera búsqueda rápida, un modelo más caro y más preciso vuelve a calificar solo los primeros candidatos y los reordena.

Puede darse el lujo de ser lento por candidato porque mira pocos (decenas, no millones). Un re-ranker típico (un cross-encoder) lee la consulta y el candidato juntos, en vez de comparar dos vectores calculados por separado, como hace un modelo de dos torres. Cuántos candidatos reordenar es una decisión de costo.

Ejemplo. En C07 de la Ronda, reordenar los 100 primeros de cada búsqueda de texto pediría ≈ 24 GPUs L4; los 30 primeros, ≈ 8.

De todos los casos que de verdad eran «sí», qué fracción encontró el modelo. Mide cuánto se le escapa.

Se calcula como verdaderos positivos / (verdaderos positivos + falsos negativos). Se puede inflar diciendo «sí» a todo, por eso se mira junto con la precision. En la curva ROC se le llama tasa de verdaderos positivos (TPR), y en medicina, sensibilidad.

Ejemplo. Había 100 tenis y el modelo encontró 80: recall = 80 / 100 = 80 %.

Un modelo hecho de capas de neuronas, una tras otra. Por dentro solo multiplica, suma y aplica activaciones, capa por capa, millones de veces.

Sus parámetros son todos sus pesos y sesgos. Responder es hacer un forward pass; aprender es ajustar los parámetros con backpropagation y descenso de gradiente. Cada capa acomoda los datos para que a la siguiente le sea más fácil.

Ejemplo. Una red de juguete de 2 entradas, 3 neuronas y 2 salidas tiene (2 × 3 + 3) + (3 × 2 + 2) = 17 parámetros.

Quedarse con el entero de arriba: ⌈0.83⌉ = 1 y ⌈2.1⌉ = 3. Así se cuentan las máquinas: media máquina no existe, y la que falta deja tráfico sin atender.

Se escribe ⌈x⌉ y en Python math.ceil(x). Su contrario es el piso, ⌊x⌋ (math.floor), que se queda con el entero de abajo; round va al más cercano, y en Python manda los empates al par: round(2.5) da 2. Para capacidad, siempre hacia arriba; el repuesto (N+1) se suma después.

Ejemplo. GPUs de C01: ⌈500 ÷ 600⌉ = ⌈0.83⌉ = 1 por tráfico, más 1 de repuesto: 2. Con floor serían 0.

Guardar el número representable más cercano cuando el valor exacto no cabe en los bits. La diferencia es el error de redondeo: chiquito en cada número, pero se acumula.

Casi ningún decimal cabe exacto: 0.1 en binario es 0.000110011…₂, sin fin. El error de cada número es, a lo mucho, media separación: ≈ 0.000006 % en FP32, ≈ 0.05 % en FP16 y ≈ 0.4 % en BF16. Por eso los números de punto flotante se comparan con tolerancia (math.isclose, torch.allclose), nunca con ==; por eso un número chico sumado a uno grande puede perderse; y por eso las GPUs acumulan las sumas en FP32 aunque multipliquen en FP16.

Ejemplo. En Python, 0.1 + 0.2 da 0.30000000000000004. En FP32, 16,777,216 + 1 da 16,777,216: un contador de fotos en float32 se atora en ≈ 40 horas.

Tener más de una copia de una pieza para que, si una falla, otra responda. Con k réplicas independientes de disponibilidad a, la pieza falla solo con probabilidad (1 − a)^k.

Cada copia es una réplica: el mismo programa en otra máquina. La regla más común es N+1: N réplicas para el tráfico y una de repuesto, de modo que perder una no se note, y la que queda tiene que aguantar el pico sola. El repuesto tiene que estar donde no le pegue lo mismo: otra máquina, otra zona. Las cuentas en el papel son enormes (dos réplicas al 99 % dan 99.99 %), pero solo valen contra fallas independientes; contra una falla correlacionada más copias de lo mismo no ayudan. Un reintento es redundancia en el tiempo, con la misma letra chica.

Ejemplo. C01 necesita una sola T4 para su pico de diseño de 500 fotos por segundo, y tiene dos, una por zona: si cae una zona, la otra queda al ≈ 42 % de su máximo. Con cada zona al 99.5 %, las dos dan 1 − 0.005² = 99.9975 %, ≈ 1 minuto al mes.

Volver a entrenar el modelo con datos nuevos para que se ponga al día con lo que está pasando.

Es lo que cierra el ciclo: el monitoreo detecta que el modelo se quedó atrás, se juntan y etiquetan datos nuevos, y se entrena una versión nueva que reemplaza a la anterior solo si es mejor.

Ejemplo. C01 reentrena cada mes con las fotos nuevas, y antes si el monitoreo detecta drift o si el negocio agrega una categoría, como «bolsas» en el Dojo.

La muestra de datos «normales» contra la que se comparan los datos de hoy para saber si algo cambió: los datos con los que se entrenó el modelo, o unas semanas recientes que se portaron bien.

Comparar distribuciones siempre es comparar dos cosas: la referencia y la ventana actual, que es el pedazo de datos que revisas ahora (ayer, la última semana, la última hora). Cada referencia responde otra pregunta. Contra los datos de entrenamiento: «¿el modelo está viendo algo que no aprendió?». Contra una ventana reciente: «¿cambió algo de golpe?». Contra la misma franja de antes (el mismo periodo del año pasado, la misma hora de la semana pasada): «¿esto es raro para este momento?», que es lo que pide la estacionalidad. Lo normal es usar dos a la vez. La de entrenamiento se versiona con el modelo: si el modelo se reentrena con datos nuevos, su referencia cambia con él.

Analogía. Como la foto de «antes» en un antes y después: sin ella no hay comparación. Se rompe en que aquí hay que elegir cuál «antes» usar, y cada uno cuenta una historia distinta.

Ejemplo. C01 compara cada día la mezcla de categorías que predijo contra la de las 4 semanas previas, y abre un ticket si el PSI pasa de 0.2 tres días seguidos. Un drift lento de 1 punto por semana nunca se ve contra la semana anterior (PSI ≤ 0.0012), pero contra el entrenamiento cruza 0.2 en la semana 15.

Si A mueve a B y B mueve a C, lo que C cambia por cada pedacito de A es lo que C cambia por B multiplicado por lo que B cambia por A. Es la cuenta que hace la backpropagation.

Un modelo es una cadena de pasos. Para saber cuánto mueve la pérdida a una perilla del principio, se multiplican las sensibilidades de cada eslabón, de la pérdida hacia atrás. Así se obtiene el gradiente de todas las perillas en una sola pasada, sin mover ninguna.

Ejemplo. Un coche hace 12 km por litro y el litro cuesta $24: cada kilómetro cuesta 24 × 1/12 = $2. En el modelo de juguete: −12 × 1 × 2 = −24.

Si dos eventos son independientes, la probabilidad de que pasen los dos es el producto de sus probabilidades: P(A y B) = P(A) × P(B).

Multiplicar es tomar una fracción de una fracción: de los casos en que pasa A, solo en una parte pasa también B. Con N eventos independientes de probabilidad p, que pasen todos es p^N, y eso baja muy rápido: es la cuenta de la disponibilidad en serie y del fan-out. Solo vale con independencia: si los eventos tienden a pasar juntos, la probabilidad de que pasen los dos es mayor que el producto.

Ejemplo. Dos servicios, cada uno rápido 9 de cada 10 veces y sin depender del otro: los dos rápidos 0.9 × 0.9 = 0.81 de las veces. Leer bien los 18 dígitos de una CLABE con 99 % por dígito: 0.99¹⁸ ≈ 0.835.

La tarea de predecir un número en una escala continua: un precio, un tiempo, una cantidad.

El nombre es histórico y no ayuda: no significa «regresar». Lo que importa es que la salida es un número y que el error se mide por qué tan lejos quedó, no por si acertó o no. Su baseline (línea base) más común es decir siempre el promedio, o lo mismo que la vez anterior.

Ejemplo. Sugerir el precio de unos tenis usados, o pronosticar cuántos litros de leche se van a vender mañana en una tienda (C14).

Todo lo que se hace para que el modelo no memorice su entrenamiento y le vaya bien con datos nuevos: más datos o augmentation, dropout, weight decay, parar a tiempo.

No busca bajar la pérdida de entrenamiento; a veces la sube a propósito. Lo que busca es que el modelo generalice. Hay de varias familias: en los datos (data augmentation), en el modelo (dropout), en el optimizador (weight decay) y en el tiempo (early stopping).

Ejemplo. La ResNet original (2015) se entrenó con weight decay de 0.0001 y augmentation, sin dropout.

La activación más usada: si el número es negativo, sale 0; si no, sale igual. ReLU(−0.3) = 0 y ReLU(0.9) = 0.9.

Es barata de calcular y funciona muy bien en redes profundas; se impuso en la década de 2010. Cuando una neurona saca 0 se dice que «no se activó». Como apaga más o menos la mitad de los números, la regla de inicialización de He usa un 2 para compensar.

Ejemplo. En la red que calcula el XOR, h₂ = ReLU(x₁ + x₂ − 1) vale 0 en tres casos y 1 solo cuando las dos entradas valen 1.

Un mensaje que un programa le manda a otro, por la red, para pedirle algo. Lo que regresa se llama response (respuesta).

Viaja por la red con un formato acordado: a qué dirección va, qué se pide y qué datos lleva (aquí, la foto). Cada request recibe su response, aunque sea un mensaje de error. Contar cuántas llegan por segundo es la forma de medir cuánto trabajo tiene un servicio.

Ejemplo. Cuando Ana sube su foto, los servidores del marketplace le mandan una request a la API del modelo con la foto, y la response trae la categoría.

Redimensionar una imagen a otro tamaño. Para modelos de visión se suele llevar el lado corto a una medida fija sin deformar la foto.

Al cambiar de tamaño hay que decidir cómo se calcula cada píxel nuevo a partir de los viejos: la interpolación (nearest, bilinear, bicubic…), con o sin antialias. Cada una da números un poco distintos, así que tiene que ser la misma en entrenamiento y en producción.

Ejemplo. Una foto de 3024 × 4032 con el lado corto a 256 queda en 256 × 341.

Una familia de CNNs (He y otros, Microsoft Research, 2015) en la que cada bloque tiene un atajo: su entrada se le suma a su salida. Eso permitió entrenar redes muy profundas.

Con el atajo (skip connection), salida = bloque(x) + x: cada bloque solo aprende una corrección, y la señal del aprendizaje llega bien hasta las primeras capas. Ganó la competencia de ImageNet de 2015. La ResNet-50 tiene 50 capas con pesos en su camino principal, 16 bloques residuales en cuatro etapas y hace ≈ 4.1 mil millones de multiplicaciones-sumas por foto de 224 × 224.

Ejemplo. La ResNet-50 original (1,000 categorías) tiene ≈ 25.6 millones de parámetros: ≈ 102 MB en float32. La de C01, con 500 categorías, ≈ 24.5 millones.

Cuántos píxeles tiene una imagen, dicho como ancho × alto. Multiplicados dan el total; un megapíxel (MP) es un millón de píxeles.

La resolución dice cuántos números hay que procesar: la memoria y el tiempo de decodificar crecen con ella. También dice qué tan chico puede ser un detalle y todavía verse: en la cámara de C03, una grieta de 0.2 mm mide 3.3 píxeles; con la imagen achicada a 224 de ancho, 0.3. Ojo con el orden: las fotos se describen como ancho × alto, pero los tensores casi siempre se escriben alto primero.

Ejemplo. Una foto de celular de 4032 × 3024 tiene 12,192,768 píxeles ≈ 12.2 MP.

La primera etapa de una búsqueda: traer rápido y barato unos cientos de candidatos de entre millones, aunque el orden no sea perfecto.

Suele ser una búsqueda en un índice vectorial, muchas veces junto con una búsqueda por palabras (BM25): eso es la búsqueda híbrida. Su trabajo es no dejar fuera lo bueno; ordenarlo bien le toca al re-ranking (reordenar). En RAG es la parte que busca los documentos antes de que el LLM responda.

Ejemplo. En C07 de la Ronda, el índice vectorial aporta ≈ 200 candidatos y BM25 otros ≈ 200, de entre 100 millones de publicaciones, en unas decenas de milisegundos. El re-ranker solo ve los 30 primeros.

La forma más común de guardar un color: tres números que dicen cuánta luz roja (R), verde (G) y azul (B) tiene.

Con 8 bits por número, cada uno va de 0 a 255: (0, 0, 0) es negro, (255, 255, 255) es blanco y (255, 0, 0) es rojo puro. Hay 256 × 256 × 256 = 16,777,216 combinaciones. Algunas librerías, como OpenCV, guardan los mismos tres números en orden BGR: si se mezclan, el modelo ve los colores cambiados.

Ejemplo. (232, 174, 54) es un amarillo mostaza.

La tercera etapa de un LLM de chat: personas comparan respuestas del modelo, se entrena un modelo que imita sus preferencias y con él se ajusta el LLM hacia lo que la gente prefiere.

Pasos: el modelo escribe dos o más respuestas a la misma petición; una persona elige la mejor; un modelo de recompensa (reward model) aprende a predecir esa elección; y el LLM se ajusta por refuerzo (prueba, recibe una calificación y se mueve hacia lo que sube la calificación), sin alejarse mucho del modelo de la etapa anterior. DPO (2023) consigue algo parecido sin modelo de recompensa, directo de los pares; Meta lo usó en Llama 3. Enseña tono, utilidad y qué rechazar; no agrega conocimiento.

Ejemplo. En InstructGPT (OpenAI, 2022), las personas prefirieron las respuestas de un modelo de 1,300 millones de parámetros ajustado así sobre las de GPT-3, de 175,000 millones.

Una gráfica que dice qué tan rápido puede ir, como máximo, un cálculo en un chip: el menor entre su pico de FLOPS y su intensidad aritmética × el ancho de banda de memoria.

A lo ancho va la intensidad aritmética y a lo alto los FLOPS alcanzables, las dos en escala logarítmica. Tiene dos partes: una rampa, donde lo alcanzable es intensidad × ancho de banda (el cálculo es memory-bound), y un techo plano en el pico de TFLOPS (el cálculo es compute-bound). Se juntan en el punto de quiebre (ridge point): pico ÷ ancho de banda, ≈ 203 FLOPs por byte en una T4. Es una cota: lo real queda debajo. Sirve para saber qué recurso te limita y, por lo tanto, cuál vale la pena comprar o ahorrar. Lo propusieron Williams, Waterman y Patterson en 2009.

Ejemplo. En una T4 (65 TFLOPS y 320 GB/s), un cálculo con intensidad 1 alcanza a lo mucho 1 × 320 GB/s = 0.32 TFLOPS, el 0.5 % del pico; uno con intensidad 1,365 llega al techo de 65 TFLOPS.

El superusuario de Linux, el usuario número 0: con él, el kernel se salta casi todas las revisiones de permisos. Puede leer y cambiar cualquier archivo, matar cualquier proceso, montar discos y cargar drivers.

Para usar sus poderes en un solo comando se escribe sudo antes. Lo peligroso es dejar un servicio corriendo como root: si alguien explota un error del programa, obtiene exactamente sus permisos. En un contenedor, el proceso corre como root si la imagen no dice otra cosa, y ese UID 0 es el mismo root del nodo, solo que encerrado y con menos poderes: si escapa, es root de la máquina. Por eso la regla es el mínimo privilegio: USER con un UID numérico en la imagen y runAsNonRoot en Kubernetes. Sus poderes están partidos en unas 40 capabilities que se pueden quitar.

Ejemplo. El gateway de C01 corre como el UID 10001 (USER 10001 y runAsUser: 10001). Es el que decodifica fotos que manda cualquiera: si una foto maliciosa explotara un error de Pillow, el atacante no sería root.

La memoria de un proceso (un programa en marcha) que está de verdad en la RAM en este momento. Es la que importa para saber si algo cabe: lo que un proceso reserva puede ser enorme y no ocupar casi nada.

En ps y en top sale como RSS o RES, junto al tamaño virtual (VSZ o VIRT). Incluye las páginas que el proceso comparte con otros, como las librerías o un archivo abierto con mmap, así que sumar la RSS de varios workers cuenta esas páginas varias veces; Linux tiene otra medida, la PSS, que las reparte. El límite de memoria de un contenedor mira algo parecido a la suma de todo: la memoria propia de sus procesos más las páginas de archivos que usan activamente, cada una una sola vez. En Python, resource.getrusage(resource.RUSAGE_SELF).ru_maxrss da la RSS más alta que ha tenido el proceso: en bytes en macOS y en KiB en Linux.

Ejemplo. Cuatro workers que abren con mmap el mismo modelo de 1.2 GB marcan cada uno una RSS de ≈ 1.6 GB, y su suma da 6.4 GB; pero entre los cuatro ocupan 2.8 GB, porque el modelo está una sola vez.

Etiquetas equivocadas dentro del dataset. Siempre hay algunas: por cansancio, por una guía ambigua o porque la fuente automática se equivoca o llega tarde.

En train, el ruido le enseña cosas falsas al modelo. En evaluación es peor: el modelo «falla» donde la etiqueta estaba mal y la métrica mide parte del ruido, así que pone un techo a lo que puedes medir. Northcutt, Athalye y Mueller (2021) estimaron al menos 3.3 % de etiquetas erróneas en promedio en los test sets de 10 datasets conocidos, y ≈ 6 % en la validación de ImageNet. Lo sospechoso (donde el modelo contradice la etiqueta con mucha seguridad) se manda a revisión humana; no se borra automáticamente.

Ejemplo. C09: según la suposición de la Ronda, a los 30 días solo ha llegado ≈ 60 % de los contracargos. En los pagos de hace 30 días, ≈ 4 de cada 10 fraudes todavía están etiquetados como pagos buenos; en los de la semana pasada, muchos más.

La dirección de un archivo en el árbol, con las carpetas separadas por /. Es absoluta si empieza en la raíz, como /models/classifier/1/model.plan, y relativa si se lee desde la carpeta de trabajo del programa (casi siempre, la carpeta donde arrancó), como models/model.plan.

Una ruta relativa depende de la carpeta de trabajo del proceso (working directory, la que muestra pwd y fija el WORKDIR de un Dockerfile): el mismo open('models/model.plan') funciona si arrancas en la carpeta correcta y falla con «No such file or directory» si no. . es la carpeta actual y .. la de arriba. ~ es la carpeta personal, pero la traduce la shell, no el kernel. Windows separa con \ en vez de /; en Python, pathlib arma rutas sin preocuparse por eso.

Ejemplo. Parado en /opt/tritonserver, la ruta relativa ../../models/classifier/1/model.plan sube dos carpetas, hasta /, y baja al engine: llega a la misma /models/classifier/1/model.plan.

Elegir el siguiente token al azar, pero respetando las probabilidades que dio el modelo: el de 60 % sale, en promedio, 6 de cada 10 veces.

La alternativa es tomar siempre el más probable (greedy). El muestreo da respuestas más variadas; elegir siempre el más probable da respuestas más repetibles. La temperatura controla qué tan parejo es el sorteo, y top-p lo limita a los tokens más probables que juntos suman p (por ejemplo, 90 %).

Ejemplo. Con 66.5 %, 24.5 % y 9.0 %, en 1,000 sorteos con semilla fija salen 671, 249 y 80. Con top-p = 0.9, el de 9.0 % ni siquiera entra al sorteo.

El plan de cómo cambia el learning rate durante el entrenamiento: pasos grandes al principio y finos al final, para asentarse en el fondo.

Los más comunes: escalones (dividir entre 10 cuando la validación se estanca, como en la ResNet original de 2015) y coseno (baja suave, como media ola, hasta casi 0). Muchas veces empieza con warmup. Su estado, en qué paso va, se guarda en el checkpoint: sin él, reanudar no es seguir.

Ejemplo. Coseno desde 0.0003 en 230,032 pasos: a la mitad vale 0.00015; a tres cuartos, ≈ 0.000044; al final, 0.

La tarea de ponerle una clase a cada píxel de una imagen. El resultado es una máscara: una imagen del mismo tamaño donde cada píxel dice qué es.

Es más fina que la detección de objetos: no dice «aquí hay un tenis, más o menos en esta caja», sino exactamente qué píxeles son tenis y cuáles son fondo.

Ejemplo. Quitar el fondo de una foto de producto, o marcar qué píxeles de una tomografía son un tumor.

El número con el que arranca el generador de números al azar de la computadora. Con la misma semilla salen los mismos «azares»: el mismo orden de fotos, las mismas variaciones.

Fijarla es necesario para repetir un entrenamiento, pero en GPU no alcanza: algunas sumas en paralelo se hacen en distinto orden y dan resultados un poquito distintos. Por eso «reproducible» quiere decir «el mismo resultado dentro del ruido», no idéntico.

Ejemplo. C01 entrena con la semilla 17. Con la misma receta y cinco semillas distintas, la Ronda muestra resultados entre 85.12 % y 85.34 % (números ilustrativos).

Un aviso corto, con un número, que el sistema operativo le entrega a un proceso (un programa corriendo). SIGTERM le pide que termine; SIGKILL lo termina sin preguntarle.

Al recibir una señal, el proceso corre su manejador (una función suya), la ignora o deja que pase la acción por omisión, que casi siempre es terminar. Las de todos los días: SIGINT (2, Ctrl+C; en Python, KeyboardInterrupt), SIGTERM (15, el aviso amable de kill, docker stop y Kubernetes) y SIGKILL (9, que no se puede atender ni ignorar: el kernel quita al proceso de en medio). Un servidor bien hecho, al recibir SIGTERM, deja de aceptar requests, termina las que tiene en curso y sale; si tarda más que el plazo de gracia (30 s si nadie lo cambia en Kubernetes), le llega SIGKILL. Dentro de un contenedor, el PID 1 ignora las señales que no maneja, salvo un SIGKILL que llegue de afuera.

Analogía. Una nota que te pasan por debajo de la puerta: puedes leerla y actuar (el manejador) o seguir en lo tuyo. SIGKILL no es una nota: es que te saquen del cuarto. Se rompe en que una nota la lees cuando quieres; una señal interrumpe al proceso en cuanto llega.

Ejemplo. En un deploy de C01, Triton recibe SIGTERM, termina lo que tiene en curso en hasta 30 s y sale. Si a los 60 s sigue vivo, el kubelet le manda SIGKILL.

Una computadora (o un programa) que se queda encendida esperando peticiones y las responde.

La palabra se usa para las dos cosas: la máquina y el programa que corre en ella esperando peticiones. En producción, los servidores no se apagan nunca y casi siempre están en la nube (computadoras que empresas como Amazon o Google rentan por hora), no en una oficina.

Ejemplo. La API de C01 corre en varios servidores en la nube que responden millones de fotos al día. Si uno se apaga, los demás siguen respondiendo.

Tener el modelo cargado en un servidor, listo para responder predicciones por una API.

Es la etapa 3 del camino: un programa carga el modelo una vez, al arrancar, y desde ahí responde cada request. Lo difícil no es que responda una vez, sino que responda rápido y sin caerse, muchas veces por segundo, con la foto preparada igual que cuando se entrenó.

Ejemplo. En C01, el serving es la API que recibe la foto de Ana, la prepara y se la pasa al modelo, que vive en un servidor con GPU (Triton, en la Ronda).

Dos fuentes de error. Sesgo: el modelo es demasiado simple y falla siempre de forma parecida. Varianza: el modelo cambia mucho según la muestra con que lo entrenes, porque aprende sus casualidades.

Mucho sesgo es underfitting; mucha varianza es overfitting. La idea clásica es que al hacer el modelo más complejo baja el sesgo y sube la varianza. En las redes grandes de hoy la historia es más complicada, pero la regla práctica no cambia: mide en datos que el modelo no vio.

Analogía. Cinco dardos, uno por cada modelo entrenado con otra muestra. Sesgo: caen juntos, lejos del centro. Varianza: caen alrededor del centro, desparramados. Se rompe en que en ML no ves el centro: solo lo estimas con datos de validación.

Ejemplo. Entrenas la misma receta con cinco muestras distintas. Con mucho sesgo, las cinco aciertan ≈ 60 % y fallan en lo mismo. Con mucha varianza, aciertan entre 70 % y 90 % según la muestra.

La «forma» de un tensor: cuántos números tiene en cada dimensión, en orden. Multiplicándolos sale el total.

Si el shape que manda tu código no es exactamente el que espera el modelo, falla (en el mejor caso) o calcula algo sin sentido (en el peor). Por eso los servidores de modelos, como Triton, lo declaran en su configuración.

Ejemplo. [1, 3, 224, 224] → 1 × 3 × 224 × 224 = 150,528 números.

La función que convierte un solo número cualquiera (un logit) en una probabilidad entre 0 y 1: p = 1 ÷ (1 + e^(−z)). Tiene forma de S.

En 0 da 0.5; con logits grandes se acerca a 1 y con negativos a 0, sin llegar nunca. Se usa en la clasificación binaria y, una por cada etiqueta, en la multietiqueta. Es la inversa del logit: si p = sigmoide(z), entonces z = ln(p ÷ (1 − p)). Un softmax de dos clases es una sigmoide de la diferencia de sus logits.

Ejemplo. z = 2: e^(−2) ≈ 0.135; 1 ÷ 1.135 ≈ 0.881. z = −2 da 0.119, y z = 0 da 0.5.

El corte que fijas antes de ver los datos: si el p-value queda abajo, el resultado se llama «estadísticamente significativo». Casi siempre α = 0.05.

α (alfa) es también la tasa de falsas alarmas que aceptas: si no hay efecto, el 5 % de las pruebas lo «encuentran» de todas formas (un falso positivo, que en estadística se llama error tipo I). Bajarla a 0.01 da menos falsas alarmas a cambio de más muestra para la misma potencia. «Significativo» no quiere decir «importante»: con millones de usuarios, una diferencia minúscula también lo es.

Ejemplo. Con α = 0.05, de 2,000 A/A simulados (los dos brazos idénticos) salen 102 «significativos»: 5.1 %.

Instrucciones de la CPU que hacen la misma operación sobre varios números a la vez, guardados en fila en un registro ancho. Con AVX-512, la versión de Intel y AMD con registros de 512 bits, una sola instrucción procesa 16 números FP32.

Cada posición del registro es un carril. Las familias de los chips x86: SSE (128 bits, 4 números FP32), AVX y AVX2 (256 bits, 8) y AVX-512 (512 bits, 16); los chips Arm traen NEON, de 128 bits (y los Graviton más nuevos, también SVE). Con números más chicos caben más: en 512 bits, 32 FP16 o 64 INT8. La instrucción clave para una red es la FMA, que multiplica y suma de un jalón: una MAC por carril. Para INT8, los Xeon traen VNNI (desde 2019) y AMX (desde 2023), una pequeña unidad de matrices dentro de cada núcleo. Python puro no usa SIMD; NumPy, PyTorch y ONNX Runtime sí, por las bibliotecas que llaman. Una GPU hace algo parecido a mucha mayor escala: cada warp son 32 hilos que ejecutan la misma instrucción.

Ejemplo. Un núcleo con dos unidades FMA de 512 bits: 2 × 16 carriles × 2 FLOPs = 64 FLOPs por ciclo; a 3 GHz, ≈ 192 GFLOPS en FP32. Una T4 hace 8.1 TFLOPS en FP32 y 65 en FP16.

Qué tan parecida es la dirección de dos vectores: el coseno del ángulo entre ellos. Va de −1 (opuestos) a 1 (misma dirección); 0 es perpendicular.

Se calcula como el producto punto de los dos vectores dividido entre el producto de sus largos. No le importa qué tan largo es cada vector, solo hacia dónde apunta. Si los vectores ya vienen normalizados (largo 1), la similitud coseno es simplemente el producto punto, que es lo que calculan los índices vectoriales. Qué coseno cuenta como «muy parecido» depende de cada modelo: se decide con ejemplos, no a ojo.

Ejemplo. a = (4, 3) y b = (3, 4): producto punto 4×3 + 3×4 = 24; cada uno mide 5; cos = 24 ÷ (5 × 5) = 0.96. Casi la misma dirección.

La forma en que el sistema operativo organiza los bytes de un disco en archivos y carpetas, con nombre, tamaño, dueño y permisos. En Linux todo cuelga de un solo árbol que empieza en la raíz, /.

En el disco solo hay bloques de bytes; el sistema de archivos lleva el índice de qué bloques son de qué archivo. Los de Linux más comunes son ext4 y XFS; los de Mac y Windows, APFS y NTFS. Otros discos o memorias se agregan al árbol con un montaje, y hay sistemas de archivos que no están en ningún disco: /proc y /sys los inventa el kernel para mostrar procesos y límites, y /dev/shm vive en la RAM. En Linux casi todo es un archivo: la GPU es /dev/nvidia0. Y los nombres distinguen mayúsculas: Model.plan y model.plan son dos archivos, aunque en una Mac sean el mismo.

Ejemplo. El árbol del contenedor de Triton en C01: el engine está en /models/classifier/1/model.plan, la configuración del sistema en /etc y la GPU aparece como /dev/nvidia0.

El programa que administra la computadora: reparte la CPU, la memoria y el disco entre los demás programas, guarda los archivos y no deja que un programa se meta con otro. Linux, Windows, macOS y Android son sistemas operativos.

Tiene dos partes. El kernel, el núcleo que controla el hardware y corre con todos los privilegios, y el espacio de usuario (user space): la biblioteca de C (como glibc), la shell, los comandos como ls y los programas. Un programa nunca toca el hardware directo: se lo pide al kernel con una llamada al sistema. En los servidores, el sistema operativo casi siempre es Linux. Una imagen de contenedor trae el espacio de usuario de una distribución, pero usa el kernel de la máquina donde corre.

Ejemplo. En un nodo con GPU de C01 corre Amazon Linux 2023. Su kernel reparte 4 vCPU y 16 GiB de RAM entre Triton y los programas de Kubernetes de esa máquina, y es el que deja o no a cada uno leer cada archivo.

El número que se mide para saber si se cumple una promesa del servicio: un percentil de latencia, o la fracción de requests buenas.

El SLO le pone la meta. La forma más práctica es una fracción, porque es un conteo: se suma entre copias y entre ventanas y, con un bucket justo en el umbral, sale exacta. En Prometheus, la fracción de requests en 200 ms o menos es el bucket le="0.2" entre el total.

Ejemplo. Un día con 10,000,000 requests y 9,935,000 en 200 ms o menos: el SLI vale 99.35 %, y el SLO de 99 % se cumple.

Un pedazo de los datos de evaluación que comparte algo (fotos de celular, fotos con poca luz, una categoría) y que se mide por separado, porque el promedio general puede esconder que ahí el modelo empeoró.

Es la misma idea que medir cada clase por separado, aplicada a cualquier grupo: fotos de celular contra web, con poca luz, muy chicas, de una región. Un promedio pesa más a los grupos grandes, así que un grupo chico puede empeorar mucho sin mover el total. Por eso el examen de un modelo nuevo exige que no empeore en ningún slice importante, no solo en el promedio.

Ejemplo. Un modelo nuevo sube de 85.0 % a 85.2 % en general, pero en el 5 % de fotos con poca luz baja de 77.4 % a 70.0 %. Solo el slice lo muestra.

La meta que un número medido del servicio tiene que cumplir, en una ventana de tiempo. En C01: p99 ≤ 200 ms, medido del lado del servidor.

Un SLO completo dice qué se mide, dónde, cuánto y en qué ventana. Se revisa con su SLI: cada pocos minutos para avisar, y cada 30 días para llevar la cuenta. «p99 ≤ 200 ms» es lo mismo que «al menos el 99 % de las requests en 200 ms o menos», y ese 1 % que sobra es un presupuesto que se puede gastar (presupuesto de error). Si además hay un contrato con multas, se llama SLA.

Ejemplo. C01 tiene dos: el de latencia, p99 ≤ 200 ms; y el de disponibilidad, 99.9 % al mes de requests sin error del servidor y dentro de 300 ms.

Cada uno de los bloques de cálculo de una GPU de NVIDIA: lo más parecido a un núcleo de CPU. Tiene sus registros, una memoria chiquita y rápida, carriles de cálculo y tensor cores. Una T4 tiene 40; una H100 SXM, 132.

Un SM de la T4 tiene 64 carriles para FP32, que son los «CUDA cores» de las hojas de datos, y 8 tensor cores, y mantiene vivos hasta 1,024 hilos, en warps de 32. Cuando un warp espera un dato de la VRAM, el SM pone a trabajar a otro en el siguiente ciclo: así esconde la espera. Los CUDA cores que se anuncian son SMs × carriles: 40 × 64 = 2,560 en la T4. Métricas como SM activity, de DCGM, miden cuántos SMs trabajan, algo que la utilización de GPU de nvidia-smi no ve.

Ejemplo. Los 8.1 TFLOPS en FP32 de la T4: 40 SMs × 64 carriles × 2 FLOPs × 1.59 × 10⁹ ciclos por segundo. Con sus tensor cores en FP16, cada SM hace 512 MACs por ciclo en vez de 64: 65 TFLOPS.

La cuenta que convierte los puntajes crudos de un modelo (sus logits) en probabilidades: eleva e ≈ 2.718 a cada puntaje, suma todo y divide cada uno entre la suma. Quedan números entre 0 y 1 que suman 1.

Conserva el orden (el logit más alto queda con la probabilidad más alta, así que el argmax no cambia) y solo depende de las diferencias entre logits: sumarles a todos el mismo número no cambia nada. Como la exponencial exagera las diferencias, cada punto de diferencia multiplica por e ≈ 2.72. Se usa en la multiclase; en la multietiqueta se usa una sigmoide por etiqueta.

Ejemplo. Logits 3, 1 y 0 → e³ = 20.09, e¹ = 2.72, e⁰ = 1.00; suman 23.81; quedan 84.4 %, 11.4 % y 4.2 %.

El tipo de transformer de los LLMs que escriben: una pila de bloques donde cada token solo mira a los anteriores, entrenada a adivinar el siguiente token.

El transformer original (2017) tenía dos mitades para traducir: un encoder, que lee la frase de origen completa en las dos direcciones, y un decoder, que escribe la traducción mirando solo hacia atrás. GPT (2018) y casi todos los LLMs actuales se quedan solo con el decoder. Los que se quedan solo con el encoder, como BERT (2018), no escriben: sirven para entender un texto completo, para clasificar y para embeddings.

Ejemplo. Llama 3 8B es solo decoder: una tabla de embeddings, 32 bloques que miran hacia atrás y una capa final que da un logit por cada uno de los 128,256 tokens.

Repartir el dataset en partes que no se mezclan: una para aprender (train), una para decidir (validación) y una para el examen final (test).

No basta con la proporción (80/10/10, por ejemplo). Importa la unidad: si las fotos vienen en familias (del mismo vendedor, o la misma foto en varias publicaciones), la familia entera va a un solo lado (split por grupo); si el modelo va a predecir el futuro, se reparte por fecha (split temporal). Si no, hay leakage.

Ejemplo. C01 reparte por vendedor: ≈ 95 % a train y ≈ 5 % a validación (1,840,211 y 92,417 fotos en el dataset de septiembre). El examen final es el golden set, que se arma aparte.

Repartir cada grupo (cada categoría, por ejemplo) por separado y en la misma proporción, para que train, validación y test tengan la misma mezcla.

Al azar, una categoría chica puede quedarse sin ningún ejemplo en validación, y entonces no se puede medir. Estratificar fija cuántos van a cada lado; el sorteo solo decide cuáles. No hace milagros: con 30 fotos y 5 % de validación quedan 1 o 2, que no miden nada.

Ejemplo. Una categoría con 20 fotos y un split 80/10/10: estratificado, quedan exactamente 16, 2 y 2. Al azar, unas 12 de cada 100 veces validación se queda sin ninguna (0.9 multiplicado por sí mismo 20 veces ≈ 0.12).

Repartir por grupos completos (vendedor, cliente, cámara, paciente) en vez de por ejemplos sueltos, para que todos los ejemplos de un grupo queden del mismo lado.

Si los ejemplos de un grupo se parecen entre sí (el mismo fondo, la misma luz, el mismo cliente), repartirlos al azar deja gemelos en train y en test, y el modelo aprende a reconocer el grupo en vez de la tarea. Un truco común: calcular un hash del id del grupo y decidir con él (por ejemplo, hash mod 100 < 95 → train). Así el mismo grupo cae siempre del mismo lado, mes tras mes, sin guardar ninguna lista. El hash tiene que ser estable, como sha256 de hashlib, no el hash() de Python.

Ejemplo. C01 reparte por vendedor: hash(seller_id) mod 100 < 95 va a train y el resto a validación. Un vendedor con 400 fotos sobre la misma mesa queda entero de un lado. C04, en patología, reparte por paciente.

Repartir por fecha: entrenar con lo que pasó antes de un corte y evaluar con lo que pasó después. Es obligatorio cuando el modelo va a predecir el futuro.

Un split al azar mezcla días: el modelo ve el lunes y el miércoles y lo examinas con el martes, así que interpola en vez de predecir. Con un corte, el examen se parece a producción: el modelo solo sabe lo que se sabía en esa fecha. Si las etiquetas tardan en llegar (un contracargo puede tardar meses), además hay que esperar a que maduren. Repetir el corte en varias fechas y promediar se llama backtest.

Ejemplo. C14 entrena con las ventas hasta una fecha de corte y evalúa los 14 días siguientes, en 8 cortes semanales. La regla de la Ronda: si entrenas con datos hasta el 5 de enero, evalúa desde el 6.

Un disco sin partes que se muevan, hecho de memoria flash (la de las memorias USB), que guarda los datos aunque se apague la computadora. Lee 4 KiB al azar en ≈ 0.05 a 0.1 ms, más de 100 veces más rápido que un disco duro. Se conecta por SATA, la conexión de los discos duros (hasta ≈ 550 MB/s), o por NVMe, una hecha para flash (varios GB/s).

Cada celda de flash atrapa una carga eléctrica que se queda aunque no haya luz. Se lee y se escribe por páginas de unos KiB, pero solo se borra por bloques grandes, y cada celda aguanta un número limitado de escrituras: un SSD se gasta, y usarlo de swap lo gasta más rápido. SATA es la conexión que se diseñó para discos duros: una sola fila de 32 pedidos y un tope de ≈ 550 MB/s. NVMe (Non-Volatile Memory Express) habla directo por PCIe, el camino rápido dentro de la computadora: muchas filas de pedidos (el estándar permite hasta 65,535), de ≈ 3 a 14 GB/s según la generación y cientos de miles de lecturas al azar por segundo. En AWS, varias máquinas con GPU traen un NVMe local, que se borra cuando la máquina se detiene.

Ejemplo. C10 copia los 70.6 GB de sus pesos de S3 al NVMe local del nodo en ≈ 1 a 2 minutos, porque vLLM los lee con mmap y un disco de red haría la carga mucho más lenta.

Cuántos píxeles salta un filtro de una posición a la siguiente. Con stride 2, la salida queda más o menos de la mitad de ancho y de la mitad de alto.

Entra en la fórmula del tamaño de salida de una convolución o de un pooling: lado = (n + 2p − k) ÷ s + 1, redondeando la división hacia abajo, con n el lado de la entrada, k el del filtro, p el padding y s el stride. Cada capa con stride 2 deja la cuarta parte de las posiciones y hace crecer más rápido el campo receptivo.

Ejemplo. La primera capa de la ResNet-50 (7 × 7, padding 3, stride 2) convierte la foto de 224 × 224 en mapas de 112 × 112: (224 + 6 − 7) ÷ 2 = 111.5, que baja a 111, más 1.

Una parte del disco donde el sistema operativo guarda los pedazos de memoria (las páginas) que no se han usado en un rato, para liberar RAM. Si un programa los vuelve a tocar, se leen del disco: de mil a cien mil veces más lento que la RAM.

Cuando la RAM se llena, el sistema primero suelta la page cache; si no alcanza, manda páginas poco usadas al swap o mata un proceso (el OOM). El swap evita el OOM a cambio de velocidad. Si lo que los programas usan todo el tiempo no cabe en la RAM, el sistema se pasa la vida moviendo páginas de ida y vuelta (thrashing): no se cae, pero se arrastra. En una laptop vale la pena, y macOS además comprime la memoria antes de usarlo. En un servidor que responde requests, no: la latencia explota sin ningún error, y es mejor morir rápido y volver a arrancar. Por eso los servidores suelen tenerlo apagado. En un servidor con Linux, la VRAM no tiene swap: si un tensor no cabe, PyTorch falla con «CUDA out of memory».

Ejemplo. Si 1 de cada 100 lecturas de un servidor sale del swap en un SSD (≈ 100 µs) y las demás de la RAM (≈ 100 ns), el promedio pasa de 100 ns a ≈ 1,099 ns: 11 veces más lento. Con un disco duro, ≈ 1,000 veces.

Las instrucciones que la app le da al LLM al principio de cada conversación, antes de lo que escribe la persona: qué papel tiene, qué reglas sigue y en qué formato contesta.

En la plantilla de chat ocupa el rol «system», separado del «user» con tokens especiales. El modelo aprendió a darle más peso en el ajuste con instrucciones, pero no es una barrera de seguridad: una persona o un documento pueden convencer al modelo de ignorarlo o de repetirlo completo. Por eso no lleva secretos. Como es igual en todos los requests de un producto, va primero y el prefix caching lo reutiliza.

Ejemplo. En C10 de la Ronda, cada producto tiene un prefijo fijo de ≈ 1,000 tokens (instrucciones y políticas) que se guarda con versión, como el código.

Cuántas unidades necesita cada brazo de un experimento para ver un efecto dado, o cuántos datos necesita un examen para medir con cierto margen.

Para comparar dos proporciones, la regla de bolsillo es n ≈ 16 × p(1 − p) ÷ MDE² por brazo, con α = 0.05 y potencia de 80 %; el 16 sale de redondear 2 × (1.96 + 0.84)² ≈ 15.7. Para medir una sola proporción con un margen m al 95 %: n ≈ 1.96² × p(1 − p) ÷ m². En los dos casos, el ruido baja con la raíz de n.

Ejemplo. C01: 16 × 0.70 × 0.30 ÷ 0.01² = 33,600 por brazo (la fórmula completa da 32,647). Para medir una accuracy de 85 % con ±1 punto: 1.96² × 0.1275 ÷ 0.0001 ≈ 4,900 fotos.

El tipo de pregunta que le haces a un modelo: elegir una categoría, dar un número, ordenar una lista, encontrar objetos… Decide qué sale del modelo y cómo se mide si acertó.

Se decide antes de elegir el modelo, a partir del problema del negocio. Las más comunes: clasificación (binaria, multiclase o multietiqueta), regresión, ranking, detección de objetos, segmentación y ocr. La tarea también decide cómo termina el modelo: una sigmoide, un softmax o nada. Un sistema real a veces combina varias.

Ejemplo. «Sugerir la categoría de una foto» es una tarea de clasificación multiclase. «Sugerir el precio» sería una regresión.

Cuántas veces pasa algo por unidad de tiempo: requests por segundo, fallas por día. Es un promedio: dice cuántos llegan en promedio, no cuántos llegan en cada segundo.

Es un valor esperado por unidad de tiempo, y se convierte como cualquier unidad (por segundo × 86,400 = por día). Las QPS son una tasa. Con una tasa de fallas, el tiempo promedio entre dos fallas es 1 ÷ tasa. Como las llegadas al azar se amontonan, cada segundo trae más o menos que la tasa; el modelo de Poisson dice cuánto, y por eso se diseña para el pico y con margen, no para el promedio.

Ejemplo. C01: 10 millones de fotos al día ÷ 86,400 s ≈ 116 requests por segundo en promedio, ≈ 350 en el pico del día y 500 de diseño. Con 0.1 % de fallas, ≈ 0.116 fallas por segundo: una cada ≈ 8.6 s.

La perilla del muestreo: con temperatura baja el modelo casi siempre elige el token más probable; con temperatura alta, las opciones menos probables ganan terreno.

Antes de convertir las calificaciones del modelo (logits) en probabilidades con softmax, se dividen entre la temperatura. Dividir entre un número chico agranda las diferencias; entre uno grande, las aplana. Temperatura 0 equivale a elegir siempre el más probable, aunque en un servidor real eso no garantiza respuestas idénticas.

Ejemplo. Logits 2, 1 y 0. Con temperatura 1: 66.5 %, 24.5 % y 9.0 %. Con 0.5: 86.7 %, 11.7 % y 1.6 %. Con 2: 50.6 %, 30.7 % y 18.6 %.

Un arreglo de la calibración: dividir todos los logits entre un mismo número T antes del softmax. Con T mayor que 1, el modelo baja su seguridad; el orden de las clases no cambia.

T es un solo número que se elige con el set de validación: el que hace más honestas las probabilidades, por ejemplo el que deja más baja la pérdida de validación. Como dividir entre un número positivo no cambia qué logit es más grande, la top-1 y la top-5 quedan idénticas: solo cambia qué tan seguro dice estar. Es la misma temperatura de los LLMs, usada para otra cosa. Se popularizó con un estudio de 2017 (Guo y otros) que mostró que las redes modernas suelen ser demasiado confiadas.

Ejemplo. Logits 3, 1 y 0: el softmax da 84.4 %, 11.4 % y 4.2 %. Con T = 1.5 quedan 2, 0.67 y 0, y el softmax da 71.5 %, 18.8 % y 9.7 %: la misma clase primero, con menos seguridad.

Una tabla de números con cualquier cantidad de dimensiones, todos del mismo tipo. Es lo que entra y sale de un modelo.

Un número solo tiene 0 dimensiones, una lista tiene 1, una tabla tiene 2 y una foto a color tiene 3 (canal, alto, ancho). Un grupo de fotos tiene 4. Su shape dice cuántos números hay en cada dimensión.

Ejemplo. La foto de Ana, lista para el modelo de C01: un tensor de shape [1, 3, 224, 224] con 150,528 números float32.

Un circuito dentro de cada bloque de cálculo (SM) de una GPU de NVIDIA que multiplica dos bloques chicos de matrices y suma el resultado en un solo paso. Trabaja sobre todo con formatos de pocos bits, como FP16, BF16, FP8 o INT8, según la GPU.

Hace D = A × B + C sobre bloques: en la T4, cada uno hace 64 MACs por ciclo en FP16, y hay 8 por SM, así que un SM hace 512 MACs por ciclo en sus tensor cores contra 64 en sus carriles normales. De ahí que la T4 haga 65 TFLOPS en FP16 y 8.1 en FP32. Las sumas se acumulan en FP32. Los dos números de cada multiplicación tienen que estar en un formato que acepte, y en el mismo (INT8 con INT8): un modelo en float32 en una T4 los deja parados. Nacieron en 2017, con la V100; los de la T4 aceptan FP16, INT8 e INT4; la A100 agregó BF16 y TF32; la L4 y la H100, FP8 (la H100 dejó INT4); Blackwell, FP6 y FP4. Rinden con matrices grandes, otra razón para el batching.

Ejemplo. C01 sirve su modelo en FP16 con TensorRT para usar los tensor cores de su T4: 65 TFLOPS contra 8.1 en FP32. Si la métrica tensor activity de DCGM está cerca de 0 mientras sirves en FP16, el engine no los está usando.

La parte que se guarda bajo llave y se usa al final, una vez, para estimar qué tan bien le irá al modelo con datos que nunca vio.

Si miras el test, cambias algo y vuelves a mirar, el test se convirtió en validación y ya no tienes un número honesto. En C01 el papel del test lo hace el golden set.

Ejemplo. Con 50,000 fotos y un reparto 80/10/10, test son 5,000 fotos que nadie mira hasta el final. Si pruebas 40 variantes y reportas la mejor en test, ese número ya no es honesto.

Billones (10¹²) de operaciones de punto flotante por segundo: la velocidad de cálculo de un chip. Una T4 anuncia 65 TFLOPS en FP16; una H100, ≈ 990.

La S mayúscula es «por segundo»: FLOPS es una velocidad y FLOPs, con s minúscula, una cantidad. Lo que publica el fabricante es el pico teórico: todos los núcleos trabajando sin parar con un tipo de dato concreto. Depende mucho de la precisión: la T4 hace 8.1 TFLOPS en float32 y 65 en FP16 con sus tensor cores. Con enteros se dice TOPS (operaciones, no de punto flotante): 130 TOPS en INT8 en la T4. Si la hoja de datos dice with sparsity, divide entre 2: supone un modelo podado con un patrón especial. El tiempo mínimo de un cálculo es sus FLOPs ÷ los FLOPS; en la práctica se logra una fracción, porque a menudo manda el ancho de banda de memoria (ver roofline (el modelo del techo)).

Ejemplo. La ResNet-50 hace 8.2 GFLOPs por foto. En una T4, a 65 TFLOPS: 8.2 × 10⁹ ÷ (65 × 10¹²) ≈ 0.126 ms por foto, un techo de ≈ 7,900 fotos por segundo. Lo que se mide en C01 es ≈ 1,200: ≈ 15 % del pico.

Un grupo de hilos que se reusan y esperan trabajo en una fila: cada tarea que llega la toma un hilo libre y, si todos están ocupados, espera. Sirve para mandar ahí lo que tarda, lo que bloquea o gasta CPU, sin detener al hilo que atiende las requests.

Crear un hilo para cada tarea cuesta, y sin límite se crearían miles. Un pool los reusa y les pone un tope. En un servidor async (programación asíncrona), las llamadas bloqueantes y el trabajo CPU-bound van al pool para que el event loop siga libre: en FastAPI, run_in_threadpool y las rutas escritas con def usan un pool de 40 hilos por omisión; en asyncio está asyncio.to_thread. Por el GIL, el pool solo acelera lo que espera o lo que corre en C y suelta el GIL, como Pillow, NumPy o PyTorch. Su tamaño se acota por CPU y por memoria. Cuando se satura, la fila crece y el p99 se dispara.

Ejemplo. El gateway de C01 deja decodificar solo 2 fotos a la vez por pod: un PNG de 40 MP ocupa ≈ 320 MB al decodificarse, y el pod tiene 1 GiB. Si una request espera más de 50 ms por un lugar, recibe un 503.

Cuánto trabajo termina un sistema por unidad de tiempo: requests por segundo, fotos por segundo, tokens por segundo.

Es distinto de la latencia, que es cuánto tarda una sola request: un servicio puede atender 500 por segundo aunque cada una tarde 50 ms, porque atiende muchas a la vez. Un throughput se dice con su momento (promedio o pico) y su lugar (el gateway trabaja por requests; la GPU, por fotos). Con el del pico se cuentan las máquinas.

Ejemplo. C01 se diseña para 500 req/s; una T4 sostiene ≈ 1,200 fotos por segundo, medidas con una prueba de carga. En un LLM hay dos: los tokens por segundo que ve cada persona y los de toda la flota.

El pedacito de texto con el que trabaja un modelo de lenguaje: una palabra entera, un trozo de palabra, un signo o un espacio con la palabra que sigue.

Cada token tiene un número (su id) en el vocabulario del tokenizer. Los modelos cobran, miden y limitan todo en tokens: el largo del prompt, la ventana de contexto, el precio y la velocidad («tokens por segundo»).

Ejemplo. En inglés, como regla aproximada, 1 token ≈ ¾ de palabra. En español suelen salir más tokens por palabra, y la cuenta exacta depende de cada tokenizer.

El programa que parte un texto en tokens y cambia cada uno por su número (id), y que al final hace lo contrario: de ids a texto.

Tiene un vocabulario fijo, que se decide antes de entrenar el modelo, casi siempre con BPE: la lista de todos los tokens que conoce. Las palabras comunes suelen ser un solo token; las raras se arman con varios pedazos. Cada modelo trae el suyo, así que el mismo texto da distinto número de tokens en modelos distintos, y los ids de uno no significan nada para otro.

Ejemplo. El tokenizer de Llama 3 tiene un vocabulario de 128,256 tokens.

Quedarse con las k opciones de probabilidad más alta, en orden. Top-1 es la favorita; top-5, las cinco mejores.

Sirve para mostrar varias sugerencias en vez de una sola. Es el argmax repetido k veces. El orden de las probabilidades es el mismo que el de los logits, así que el top-k se puede sacar de cualquiera de los dos.

Ejemplo. C01 devuelve el top-5 de 500 categorías: en ≈ 85 de cada 100 fotos acierta la primera y en ≈ 96 la correcta está entre las cinco.

La fracción de ejemplos en que la respuesta correcta está entre las k primeras del modelo. Top-1: es la primera. Top-5: está entre las cinco primeras.

Se usa cuando el modelo da una lista ordenada y una persona elige, o cuando hay muchas clases parecidas. Se hizo famosa con la competencia de ImageNet. En C01 la métrica offline principal es la top-5, porque la app muestra 5 sugerencias; pero cuenta igual el lugar 1 que el 5, aunque la gente casi siempre elige los primeros.

Ejemplo. El modelo de C01 saca ≈ 85 % de top-1 y ≈ 96 % de top-5: de 1,000 fotos, la primera sugerencia es correcta en 850 y la correcta está entre las cinco en 960.

Lo que tarda un LLM en escribir cada token de la respuesta después del primero, en promedio. Es el ritmo al que aparece el texto.

Es la duración de un paso de decode. La respuesta completa tarda TTFT + (tokens de salida − 1) × TPOT. Sube un poco con cada conversación que el servidor junta en el mismo paso. Mientras el texto salga más rápido de lo que una persona lee (≈ 4 a 7 tokens por segundo), nadie lo nota.

Ejemplo. En C10, el TPOT típico es 40 ms (25 tokens por segundo): una respuesta de 250 tokens tarda 0.6 + 249 × 0.04 ≈ 10.6 s, pero se empieza a leer a los 0.6 s.

La parte del dataset con la que el modelo aprende: sus parámetros se ajustan para acertarles a estos ejemplos.

Es la parte más grande, de 70 % a 95 % según el tamaño del dataset. Que el modelo acierte aquí no prueba gran cosa: con millones de parámetros se puede aprender estas fotos de memoria. Todo lo que se calcula a partir de los datos (el promedio para escalar, la mediana para rellenar huecos) se calcula solo con train.

Ejemplo. Con 50,000 fotos y un reparto 80/10/10, train son 50,000 × 0.80 = 40,000 fotos. En el dataset de septiembre de C01 son 1,840,211, ≈ 95 % del total.

Una diferencia entre cómo se preparan los datos al entrenar y al servir. El modelo recibe en producción números que nunca vio y acierta menos, sin que salga ningún error.

Es culpa del sistema, no del mundo: dos caminos de código que «hacen lo mismo» y no lo hacen. En imágenes, las causas típicas son RGB contra BGR, otra interpolación o librería de resize, el EXIF aplicado en un solo lado, otra normalización, otra calidad de JPEG y otras versiones de librerías. Se evita con un solo código de preprocesamiento para los dos lados, las mismas versiones y una prueba de paridad. No es drift: el drift es que el mundo cambió, y se arregla con datos; el skew se arregla en el código.

Analogía. La misma receta seguida en otra sucursal con una báscula mal calibrada: el pastel sale, se ve como pastel, pero sabe peor, y nadie recibe un aviso. A diferencia del pastelero, el modelo no prueba lo que hace: solo medir lo descubre.

Ejemplo. El modelo de C01 saca 85 % de top-1 en su examen; con fotos etiquetadas mandadas por el gateway real saca 80 %, y en los registros no hay ningún error.

Usar lo que un modelo ya aprendió en una tarea para resolver otra. Se parte de un modelo preentrenado en vez de empezar de cero.

Lo típico en visión: un backbone entrenado con ImageNet (≈ 1.28 millones de fotos, 1,000 categorías) ya sabe ver bordes, texturas y formas. Se le cambia la cabeza por una con las categorías propias y se sigue entrenando (fine-tuning). Hacen falta muchos menos datos y tiempo. Ayuda menos cuando las imágenes se parecen poco a las del preentrenamiento, como radiografías.

Ejemplo. C01 parte de una ResNet-50 preentrenada en ImageNet y cambia su cabeza de 1,000 a 500 categorías.

La arquitectura de red neuronal detrás de casi todos los modelos de lenguaje actuales. Su pieza central es la atención: cada token mira a los demás para decidir qué le importa.

La presentó un artículo de Google de 2017, «Attention Is All You Need» (Vaswani y otros), para traducir. Es una pila de bloques iguales; cada bloque tiene una capa de atención (multi-cabeza) y una red que procesa cada token por separado, con atajos que suman lo que entra a lo que sale. Como la atención no sabe el orden, se le agrega con embeddings posicionales. Los LLMs usan solo su mitad que escribe (solo decoder). También se usa con imágenes: el ViT es un transformer.

Ejemplo. Llama 3 8B es una pila de 32 bloques; Llama 3 70B, de 80.

Lo que tarda un LLM, desde que llega el request, en mandar el primer token de la respuesta. Es lo que la persona siente como «tardó en contestar».

Suma la espera en la cola del servidor y el prefill del prompt. Crece con prompts más largos y, sobre todo, cuando el servidor está saturado: en la Ronda, la cola rompe el TTFT antes que cualquier otra cosa. Con streaming, es el número que decide si la app se siente rápida.

Ejemplo. En C10 de la Ronda, la meta es que 95 de cada 100 requests vean su primer token en 1 s o menos; uno típico lo ve a los ≈ 0.6 s.

Un tipo de número entero sin signo que ocupa 8 bits (1 byte): va de 0 a 255. Es como vienen los píxeles de una foto decodificada.

Con 8 bits hay 2⁸ = 256 valores posibles: del 0 al 255. No admite decimales ni negativos, así que antes de normalizar se convierte a float32.

Ejemplo. Una imagen de 224 × 224 × 3 en uint8 ocupa 150,528 bytes = 147 KiB.

Una línea que pone una persona para convertir una probabilidad en una decisión: arriba del umbral se hace una cosa y abajo, otra.

No es parte del modelo: es una regla del producto, se elige con datos y se puede cambiar sin reentrenar. Moverlo cambia qué errores se cometen: subirlo da menos falsas alarmas, pero deja pasar más casos. 0.5 no tiene nada de especial: el umbral sale de lo que cuesta cada error. Al cambiar de modelo hay que revisarlo, porque cada versión reparte su confianza distinto.

Ejemplo. En C01, si la probabilidad del primer lugar es menor que 0.3, la foto cuenta como de baja confianza: se aparta para que una persona la etiquete, y se cuenta para una alerta. En C09, un pago de US$25 conviene rechazarlo desde una probabilidad de fraude de ≈ 16 %.

Cuando el modelo es demasiado simple, o entrenó muy poco, y ni siquiera aprende bien sus ejemplos de entrenamiento. Se equivoca en todas partes.

En la curva de aprendizaje se ve como dos líneas altas y juntas: el modelo no memoriza, pero tampoco aprende. Se arregla con un modelo más capaz o entrenando más tiempo.

Ejemplo. Época 1: loss de entrenamiento 2.10 y de validación 2.15. Las dos altas y casi iguales: todavía no aprende ni lo que ya vio.

Lo que se sortea entre los brazos de un A/B: el usuario, la sesión, la request o un grupo entero. Todo lo de una misma unidad cae siempre del mismo lado.

Se elige para que una persona vea una experiencia coherente y para que los brazos no se contaminen entre sí. Casi siempre es el usuario. Si la unidad es el usuario, pero la métrica se cuenta por evento (publicación, clic), los eventos de un mismo usuario se parecen entre sí, la varianza real es mayor y el análisis tiene que agrupar por usuario. La asignación se hace con un hash del id y una sal que cambia en cada experimento.

Ejemplo. En C01 la unidad es el vendedor: hash(sal + seller_id) mod 100, de 0 a 49 al control y de 50 a 99 al tratamiento. Si se sorteara por request, Ana vería sugerencias de dos modelos distintos en las fotos de una misma publicación.

El porcentaje que muestra nvidia-smi, la herramienta de NVIDIA: la parte del tiempo, en la última fracción de segundo, en que la GPU tenía algún trabajo (al menos un kernel) corriendo. Mide tiempo, no cuánto del chip trabajó ni cuántas requests esperan.

Es la misma que DCGM_FI_DEV_GPU_UTIL, de DCGM, y nv_gpu_utilization, de Triton. Un kernel chiquito que ocupa 2 SMs sin parar marca 100 %. Falla en las dos direcciones: con batches de 1 marca mucho para el trabajo que hace, y con la GPU ocupada todo el tiempo se queda en ≈ 100 % igual con 2 requests en cola que con 200. Para saber si falta capacidad se mira la cola y el throughput contra el máximo medido; para saber cuánto del chip trabaja, las métricas de perfilado de DCGM (SM activity y tensor activity). No la confundas con la utilización de la lección de FLOPs (la fracción del pico que logras) ni con la carga (throughput ÷ capacidad).

Analogía. Un vigilante que anota, minuto a minuto, si había al menos un coche en un estacionamiento de 40 lugares: si un solo coche se queda todo el día, reporta 100 % con 39 lugares vacíos. Se rompe en que un kernel puede ocupar desde un SM hasta los 40.

Ejemplo. Las T4 de C01 están al ≈ 5 % de carga (58 fotos por segundo contra ≈ 1,200 posibles), pero nvidia-smi marcaría del orden de 17 %: 58 batches de una foto por segundo, de ≈ 3 ms cada uno (un supuesto).

Una parte del dataset de la que el modelo no aprende y que tú miras mientras desarrollas, para decidir: cuándo parar, qué ajustes usar, qué versión es mejor.

Como con ella tomas decisiones, poco a poco su resultado se vuelve optimista: elegiste justo lo que mejor le fue ahí. Por eso hace falta además un test que no se toca.

Ejemplo. En el dataset de septiembre de C01 son 92,417 fotos, ≈ 5 % del total.

Medir con varios exámenes en vez de uno: partes los datos en k grupos, entrenas k veces dejando cada vez un grupo distinto como validación y promedias. Sirve cuando hay pocos datos.

Cada ejemplo sirve de examen exactamente una vez, así que el resultado depende menos de la suerte de un solo reparto, y la distancia entre la mejor y la peor vuelta dice cuánto ruido hay. Mide una receta (arquitectura, hiperparámetros, datos), no un modelo: al final se entrena uno con todos los datos. Se estratifica por clase, se reparte por grupo (todas las fotos de un vendedor en el mismo) y, si el modelo predice el futuro, por tiempo. Cuesta k entrenamientos; con millones de ejemplos, como en C01, basta un set de validación grande.

Ejemplo. 250 fotos en 5 grupos de 50. Las cinco vueltas aciertan 86, 92, 80, 84 y 88 %: el promedio es 86 %, y un solo examen de 50 fotos podía salir entre 80 y 92 % por pura suerte.

Un valor que queda muy lejos de los demás. Puede ser un error de medición o un caso real y raro; antes de hacer algo con él, hay que saber cuál es.

Jala mucho al promedio y casi nada a la mediana. Una regla común para marcarlos es la de Tukey: más de 1.5 rangos intercuartílicos arriba del tercer cuartil, o abajo del primero. En latencia, los atípicos reales no se borran: son la cola que la promesa del servicio quiere controlar, y se investigan. En los datos de entrenamiento, los errores de captura sí se corrigen o se quitan.

Ejemplo. En 20 requests con cuartiles de 34 y 50 ms, el límite de Tukey es 50 + 1.5 × 16 = 74 ms: las de 160 y 900 ms quedan marcadas.

El promedio a la larga: cada resultado posible multiplicado por su probabilidad, y todo sumado. Es lo que saldría en promedio por vez si repitieras lo mismo muchísimas veces.

No es lo que va a salir: el valor esperado de un dado es 3.5 y ningún dado saca 3.5. Con N repeticiones independientes de algo de probabilidad p se esperan N × p; los minutos caídos esperados en un mes son 43,200 × (1 − disponibilidad). Sirve para decidir con dinero: se elige la acción con menor costo esperado, y por eso las probabilidades tienen que estar calibradas. Ojo: dos riesgos con el mismo valor esperado pueden ser muy distintos si uno de ellos es raro y catastrófico.

Ejemplo. C09, un pago de US$30 con probabilidad de fraude 0.05: aprobar cuesta en promedio 0.05 × 45 = US$2.25; rechazar, 0.95 × 7.5 ≈ US$7.13, y pedir verificación, ≈ US$1.52. Gana la verificación.

Un dato que debía estar y no está: la feature quedó vacía para ese ejemplo. Antes de entrenar hay que decidir qué hacer con ella, y hacer lo mismo al servir.

Tres salidas: quitar el ejemplo o la columna (fácil, pero si lo que falta no falta al azar, quitas justo un tipo de caso), rellenar o imputar (con la mediana de train o una regla del negocio, y marcar la fila con una columna «rellenado») o dejarlo como «no sé», NaN (not a number), para un modelo que lo sepa usar, como los de árboles de decisión con gradient boosting. Nunca rellenar con 0 si 0 significa otra cosa: «cero compras» es un dato; «no sé cuántas», otro.

Ejemplo. C09: si un pago llega sin el SDK que identifica al dispositivo, sus features de dispositivo valen NaN, no 0. C14: un producto sin ventas ayer pudo haber vendido cero, estar agotado o no tener dato, y son tres cosas distintas.

Qué tanto se alejan unos números de su promedio: el promedio de las distancias al promedio, elevadas al cuadrado. Sus unidades son las de los datos, al cuadrado.

Se eleva al cuadrado para que las distancias de arriba y las de abajo no se cancelen y para que una distancia grande pese más. Tiene una propiedad que la vuelve central en estadística: la varianza de una suma de cosas independientes es la suma de sus varianzas. De ahí sale que promediar n datos divida la varianza entre n. Con los datos de una muestra se suele dividir entre n − 1 en vez de n, para no quedarse corto.

Ejemplo. Cinco exámenes dan 81, 89, 85, 82 y 88. Promedio 85; distancias −4, 4, 0, −3 y 3; cuadrados 16, 16, 0, 9 y 9. Suman 50: la varianza es 50 ÷ 5 = 10 (o 50 ÷ 4 = 12.5 con n − 1).

La unidad de CPU que renta la nube. En las máquinas de AWS con procesador Intel, como las de C01, es un hilo de hardware: medio núcleo físico. En las Graviton (Arm) y en las AMD más nuevas, un núcleo completo.

Una máquina de «4 vCPU» con un Xeon tiene 2 núcleos, cada uno con dos hilos de hardware que comparten sus circuitos. En Kubernetes, «1 CPU» es 1 vCPU y se mide como tiempo: un límite de 2 CPU son 2 segundos de CPU por cada segundo de reloj, y si el pod se pasa, Linux lo frena un rato (CPU throttling). Para dimensionar: vCPU ocupados = trabajos por segundo × ms de CPU por trabajo ÷ 1,000, medido en el tipo de máquina de producción. Las cuotas de la nube para máquinas con GPU también se cuentan en vCPU. Una trampa: bibliotecas como PyTorch u ONNX Runtime abren tantos hilos como núcleos ven en la máquina, no los que permite el límite del pod.

Ejemplo. La g4dn.xlarge de C01: 4 vCPU, 16 GiB y una T4 por ≈ US$0.526 la hora, ≈ US$0.13 por vCPU. Un vCPU de una c6i cuesta ≈ US$0.0425: ≈ 3 veces menos. Por eso C01 prepara las fotos (≈ 3 vCPU ocupados en el pico de diseño) en máquinas c6i.

Dado un vector, encontrar los k vectores de una colección que están más cerca de él. Es la operación que hay debajo de toda búsqueda por embeddings.

La forma exacta (fuerza bruta, brute force) compara contra todos: con 100 millones de vectores de 512 números son 51.2 mil millones de multiplicaciones por búsqueda. Por eso en producción casi siempre se usa la versión aproximada, el ANN.

Ejemplo. k = 30: los 30 productos cuyo embedding se parece más al de la búsqueda «tenis blancos».

Una lista ordenada de números. Si tiene 2 números se puede dibujar como un punto (o una flecha) en un plano; si tiene 512, es un punto en un espacio de 512 dimensiones.

Cada número es una coordenada, y su posición en la lista importa: (4, 3) no es lo mismo que (3, 4). La cantidad de números se llama la dimensión del vector. Un vector es un tensor de una sola dimensión, una fila de números; ojo, que en un tensor «dimensión» cuenta las direcciones de la tabla, y en un vector, cuántos números trae.

Ejemplo. (4, 3) es un vector de dimensión 2: un punto 4 pasos a la derecha y 3 hacia arriba. El embedding de un producto en C07 de la Ronda es un vector de dimensión 512.

El máximo de tokens que un modelo puede tener en cuenta en un request, sumando el prompt y la respuesta. Lo que no cabe, el modelo no lo ve.

Viene de la arquitectura y de cómo se entrenó el modelo: aprendió posiciones hasta cierto largo (embeddings posicionales). En producción también es una perilla de capacidad: cada token dentro de la ventana ocupa KV cache en la GPU, así que ventanas más largas permiten menos conversaciones a la vez.

Ejemplo. Llama 3 8B salió en abril de 2024 con una ventana de 8,192 tokens; Llama 3.1 (julio de 2024) la amplió a ≈ 128 mil.

Un modelo de visión que parte la foto en parches de 16 × 16 píxeles y los trata como los tokens de una frase, con un transformer.

Lo presentaron Dosovitskiy y otros en 2020. Cada parche (16 × 16 × 3 = 768 números) se convierte en un vector, se le suma su posición y entra a un transformer junto con un token extra, [CLS], de donde sale la respuesta. No trae de fábrica las ideas de una CNN (mirar de cerca, el mismo filtro en todas partes): las aprende de los datos, así que brilla con preentrenamientos enormes. El ViT-B/16 tiene ≈ 86 millones de parámetros.

Ejemplo. Una foto de 224 × 224 con parches de 16: 224 ÷ 16 = 14 por lado, 14 × 14 = 196 parches; con el [CLS], 197 tokens.

La memoria propia de la GPU. Todo con lo que la GPU calcula tiene que estar ahí: al entrenar, las perillas, sus gradientes, el estado del optimizador y las activaciones.

Su tamaño decide qué cabe: 16 GB en una T4, 24 GB en una L4 o una A10G, 80 GB en una H100. Entrenar con Adam en precisión mixta ocupa ≈ 16 bytes por parámetro (la cuenta del artículo de ZeRO, 2020), más las activaciones, que crecen con el tamaño del batch. Servir en FP16 ocupa ≈ 2 bytes por parámetro, más el runtime. En la Ronda, M04 hace estas cuentas.

Ejemplo. C01: 24.5 M × 16 B ≈ 392 MB de lo fijo para entrenar, más ≈ 3 GB de activaciones con batch 64 (estimación). Para servir en FP16: ≈ 49 MB de pesos. Un LLM de 8,000 millones de parámetros: 128 GB solo de lo fijo.

Empezar el entrenamiento con un learning rate casi 0 y subirlo poco a poco durante los primeros pasos, para no dar saltos bruscos cuando todo es inestable.

Al principio los gradientes son grandes y poco confiables: las perillas están lejos de lo bueno, una capa nueva empieza al azar y Adam tiene pocos gradientes para promediar. Subir el lr en línea recta durante cientos o miles de pasos evita que esos primeros pasos deshagan lo aprendido o hagan explotar la pérdida. Goyal y otros (2017) lo usaron durante 5 épocas para entrenar una ResNet-50 con batches de 8,192 fotos.

Ejemplo. Warmup de 1,000 pasos hasta 0.0003: en el paso 100 vale 0.00003; en el 500, 0.00015; en el 1,000, 0.0003.

Un grupo de 32 hilos de una GPU de NVIDIA que ejecutan la misma instrucción al mismo tiempo, cada uno con sus propios datos. Es la unidad con la que cada SM, cada bloque de cálculo de la GPU, reparte el trabajo.

NVIDIA llama SIMT (single instruction, multiple threads) a esta manera de trabajar: es SIMD visto como hilos. Un SM de la T4 mantiene hasta 32 warps vivos (1,024 hilos), y cada warp tiene sus propios registros, así que cambiar de uno a otro no cuesta nada: cuando uno espera a la memoria, otro trabaja. Si los hilos de un warp toman caminos distintos en un if, el warp recorre los dos, uno después del otro (divergencia): basta un hilo distinto para que todo el warp pague los dos caminos.

Ejemplo. Sumar dos vectores de un millón de números, con un hilo por número, son 1,000,000 ÷ 32 = 31,250 warps. Una T4 tiene vivos a la vez, como mucho, 40 × 32 = 1,280, y los va corriendo por tandas.

En cada paso, encoger un poquito todas las perillas hacia 0. Una perilla solo se queda grande si el gradiente la sostiene porque de verdad ayuda.

Con un factor λ, cada paso hace perilla − lr × λ × perilla, además del paso del gradiente. Con SGD equivale a sumarle a la pérdida un castigo por perillas grandes (la regularización L2). Con Adam no es lo mismo, porque Adam divide el gradiente entre su tamaño; por eso existe AdamW (Loshchilov y Hutter), que aplica el encogimiento aparte. En PyTorch, AdamW trae λ = 0.01 por defecto.

Ejemplo. w = 2, lr = 0.01, λ = 0.1: cada paso le quita 2 × 0.01 × 0.1 = 0.002. Sin gradiente que la sostenga, en 1,000 pasos bajaría a ≈ 0.74.

Un proceso (o un hilo) que toma trabajo de una fila y lo hace: las requests que le llegan a un servidor o los mensajes de una cola. Los «workers de uvicorn» (uvicorn es un servidor web de Python) son varias copias del mismo servidor; los workers de una cola sacan trabajos (jobs) y los procesan a su ritmo.

La palabra tiene dos usos. En un servidor web, uvicorn --workers N o gunicorn arrancan N procesos iguales que atienden requests, cada uno con su event loop, su memoria y su copia del modelo (multiproceso). En el patrón asíncrono de la Ronda (M02), la API pone cada pedido en una cola y un grupo de workers lo procesa después: se escalan por lo larga que está la cola, pueden bajar a cero y deben aguantar que un mensaje llegue dos veces. C01 corre un solo worker de uvicorn por contenedor y escala con más pods: varios workers por pod esconden el uso real de CPU de cada proceso, multiplican la memoria y complican las métricas.

Ejemplo. El OCR de un PDF de 200 páginas, a ≈ 1 s por página, tarda ≈ 200 s con un worker y ≈ 10 s con 20 (M02).