DEV Community: lu1tr0n

DeepSeek V3 en 190 líneas de JAX puro

lu1tr0n — Sat, 14 Nov 2026 18:35:31 +0000

Una implementación de 190 líneas en JAX puro reproduce toda la arquitectura de DeepSeek V3: atención latente multi-cabeza, mezcla de expertos sin pérdida auxiliar y predicción multi-token incluidos. El desarrollador Vaibhaav Tiwari la entrenó de punta a punta en una MacBook Air M5, usando como único corpus novelas policiales de dominio público, y publicó el código completo en GitHub con el último push registrado el 14 de noviembre de 2026.

Qué hay dentro de las 190 líneas de DeepSeek V3 en JAX

El archivo no usa Flax, ni Equinox, ni PyTorch: los parámetros son diccionarios planos de arrays, y cada pieza del modelo es una función que se lee de arriba a abajo en deepseek_v3.py. Eso lo distingue de la mayoría de reimplementaciones educativas, que suelen apoyarse en un framework de alto nivel para esconder la mecánica interna. Tiwari también publicó un escrito técnico con diagramas y la explicación función por función en su sitio personal.

La tabla que publica el propio repositorio mapea cada idea del informe técnico de DeepSeek V3 a una función concreta:

Atención latente multi-cabeza (MLA): en vez de guardar las llaves y valores completos de cada token, cachea un único vector latente más chico (480 a 144 números por token y por capa en esta implementación), en las funciones mla e init_cache. Es como guardar un resumen comprimido de la conversación en lugar del historial completo, y descomprimirlo recién cuando el modelo necesita atender a ese token.- RoPE desacoplado: una sola llave rotatoria compartida entre todas las cabezas, mantenida fuera del latente comprimido, en rope y apply_rope.- DeepSeekMoE: un experto compartido que siempre corre, más 16 expertos enrutados de los que se activan 4 por token, en route y moe. Funciona parecido a un médico de guardia que atiende siempre, más hasta cuatro especialistas que se llaman según el caso.- Balanceo sin pérdida auxiliar: un sesgo por experto que empuja el enrutamiento hacia los expertos menos usados, sin tocar sus pesos, en update_bias y route.- Predicción multi-token (MTP): un módulo extra que además predice el token siguiente al próximo, con un peso de 0,3 en la función de pérdida, en forward y loss_fn. Diagrama simplificado de la mezcla de expertos (DeepSeekMoE). ## A quién le sirve leer este código

El público natural no es alguien que busca entrenar un modelo de producción, sino un desarrollador o estudiante que ya leyó sobre DeepSeek V3 y quiere ver, línea por línea, cómo se traduce cada idea (MLA, el enrutamiento de expertos, el balanceo) a código que corre de verdad. Sirve, por ejemplo, para un ingeniero de backend que quiere entender qué hace realmente un router de MoE antes de decidir si justifica la complejidad en un proyecto propio, o para alguien que prepara una charla interna y necesita un ejemplo que se pueda proyectar completo en una pantalla.

Para un ingeniero de ML en LATAM sin acceso a un clúster de GPU, es también la forma más barata de tocar estos conceptos con las manos: todo el entrenamiento del ejemplo corrió en una laptop de consumo, no en infraestructura de nube. No sirve, en cambio, para quien busca una librería lista para producción: el propio README aclara que se trata de una demostración de arquitectura. El autor lo dice así tras mostrar una muestra de texto generado: no apunta a competir como modelo de lenguaje.

Lo que probamos: la instalación falla fuera de macOS

Clonamos el repositorio en un sandbox aislado con Linux y seguimos los pasos que indica el README. El clon tardó 1,208 s y el repositorio pesó 16,4 MB; crear el entorno virtual tomó 1,812 s. La instalación de dependencias falló a los 0,716 s:

$ .venv/bin/python -m pip install --no-input -r requirements.txt
Collecting jax==0.4.34 (from -r requirements.txt (line 1))
  Downloading jax-0.4.34-py3-none-any.whl.metadata (22 kB)
ERROR: Could not find a version that satisfies the requirement jax-metal==0.1.1 (from versions: none)
ERROR: No matching distribution found for jax-metal==0.1.1

El motivo no es un bug: jax-metal solo se publica para macOS con Apple Silicon, y el requirements.txt fija las versiones exactas jax==0.4.34 y jax-metal==0.1.1, sin alternativa. El README documenta la instalación así:

git clone https://github.com/Vaibhaav-Tiwari/deepseek-v3-jax.git && cd deepseek-v3-jax
uv venv -p 3.12 .venv
uv pip install --python .venv/bin/python -r requirements.txt

El pico de memoria de toda la prueba (clon, entorno e instalación fallida) fue de 86,1 MB. El README menciona una ruta alternativa, "No Mac? See Running on CPU", pero seguir los pasos por defecto rompe antes de llegar a esa opción: hay que editar el requirements.txt a mano para sacar la dependencia de Metal, y el extracto que tuvimos a mano no detalla cuánto tarda esa vía en CPU.

Los números que reporta el propio entrenamiento

Esto no lo probamos nosotros: son las cifras que publica el autor sobre su propia corrida, en una MacBook Air M5 de 24 GB. El modelo tiene 36,2 millones de parámetros totales, de los cuales solo 13,6 millones se activan por token gracias al enrutamiento de expertos. Entrenó con 207 libros (21,7 millones de tokens de entrenamiento, con las novelas de Dashiell Hammett repetidas 3 veces) durante 12.000 pasos, unos 98 millones de tokens vistos en total (~4,5 épocas), a 10.700 tokens por segundo de mediana, en 2,6 horas.

La pérdida de validación bajó de 5,02 en el paso 250 a 3,51 al final del entrenamiento. El balanceo sin pérdida auxiliar deja el dato más concreto en el paso 2.000. Con el sesgo activado, la carga por experto quedó entre 5,7% y 6,9% (lo parejo sería 6,25%); sin el sesgo, osciló entre 0,09% y 18,6%. Pese a esa diferencia enorme en el reparto, la pérdida de validación en ese mismo paso fue prácticamente igual con balanceo y sin él (3,921 frente a 3,923), lo que confirma el argumento del paper original: el sesgo reparte trabajo entre expertos sin costarle nada al modelo (fuente).

El propio modelo, generado a partir del prompt "The fog came in off the": "The fog came in off the bay, and the great trees were spreading and the stars were shining" (fuente).

flowchart TD
  A["Token de entrada"] --> B["Experto compartido (siempre activo)"]
  A --> C["Router: top-4 de 16 expertos"]
  C --> D["Experto 1"]
  C --> E["Experto 2"]
  C --> F["Experto N"]
  B --> G["Suma ponderada"]
  D --> G
  E --> G
  F --> G
  G --> H["Salida de la capa MoE"]

DeepSeek V3 en JAX frente a otras reimplementaciones

No es la única forma de leer una arquitectura de LLM moderna sin depender de un framework pesado. Vale la pena ubicarla frente a dos referencias conocidas del mismo espacio:
ProyectoFramework y escalaPara qué sirvedeepseek-v3-jaxJAX puro, sin Flax ni Equinox; pensado para una sola laptopLeer de punta a punta cómo se implementan juntos MLA, MoE y MTPDeepSeek-V3 oficial (deepseek-ai)PyTorch, pensado para inferencia distribuida en producciónCorrer el modelo real, no estudiar la arquitectura paso a pasoMaxText (Google)JAX, orientado a entrenar a escala en TPU y GPUPunto de partida para entrenar modelos grandes, no para leerlo como tutorial
La diferencia de fondo es de propósito, no de calidad: el repositorio oficial y MaxText están pensados para escalar, este para entenderse. Ninguno de los tres reemplaza a los otros dos.

Limitaciones: qué no hay que esperar de este código

Es una demostración de arquitectura. El propio autor aclara en el README que no apunta a ser un modelo de lenguaje competitivo.- Solo corre de forma directa en macOS con Apple Silicon, por la dependencia fijada a jax-metal==0.1.1; en Linux la instalación por defecto falla, como confirmamos en nuestra prueba.- El checkpoint publicado es un pickle de Python, un formato que puede ejecutar código arbitrario al cargarse; el propio repositorio recomienda cargar solo checkpoints de fuentes de confianza.- Los hashes de los datos de entrenamiento pueden no coincidir entre corridas distintas, porque algunos libros vienen de Project Gutenberg y ese archivo cambia con el tiempo (los de Hammett, en cambio, están fijados a un commit exacto de Standard Ebooks y sí son reproducibles).

Qué significa para vos si programás con IA en LATAM

Si trabajás con modelos de lenguaje y nunca leíste código fuente de una arquitectura MoE moderna, este repositorio es más rápido de recorrer que un informe técnico y más transparente que una librería que te esconde los detalles. Para correrlo de verdad necesitás una Mac con Apple Silicon: nuestra prueba confirma que en un entorno Linux estándar, el típico de un pipeline de CI o una instancia cloud, la instalación por defecto se rompe por jax-metal, y el README no deja un atajo documentado para saltarse esa dependencia sin editar requirements.txt a mano.

Si tu objetivo es otro (correr un modelo DeepSeek real o entrenar algo a escala), este código no es el punto de partida; para eso están el repositorio oficial de DeepSeek-V3 o un framework como MaxText.

Referencias

Vaibhaav-Tiwari/deepseek-v3-jax: código fuente, README y resultados del entrenamiento original.- Release v1.0: checkpoint y datos exactos de la corrida publicada, del 14 de noviembre de 2026.- Escrito técnico de Vaibhaav Tiwari: diagramas y explicación función por función de las 190 líneas.

Seguimos el tema en @programacion.

Ejecución fuera de orden, explicada con un RISC-V real

lu1tr0n — Sat, 14 Nov 2026 16:10:54 +0000

Un desarrollador, sin equipo y sin financiamiento, publico un procesador RISC-V que ejecuta instrucciones fuera de orden y arranca Linux de verdad. No es una simulacion de juguete. Es un core superescalar de 64 bits, escrito en SystemVerilog, que corre el kernel 6.6.50 con BusyBox encima bajo memoria virtual Sv39, y que ademas cierra timing a 500 MHz en una libreria estandar de 45 nm (FURSOY/fursoy-cpu). Es un caso real, con codigo abierto y metricas publicadas, para entender que es la ejecucion fuera de orden y que la distingue de un procesador que ejecuta todo en el orden en que llego el programa.

Que es Fursoy Slice-1

Fursoy Slice-1 (fursoy_s1_core / fursoy_s1_soc) implementa el set de instrucciones RV64IMAFDV mas las extensiones Zba, Zbb, Zicsr y Zifencei: enteros, multiplicacion, atomicos, punto flotante simple y doble, y vectores (FURSOY/fursoy-cpu). Separa los tres niveles de privilegio de RISC-V (maquina, supervisor y usuario), implementa paginado por demanda bajo Sv39 y agrega telemetria de rendimiento ciclo a ciclo. Todo eso figura en un repositorio con un solo autor: unas 7 estrellas y 0 forks al 14 de noviembre de 2026 (FURSOY/fursoy-cpu).

Varios proyectos academicos ya logran arrancar Linux en hardware propio. Lo que distingue a Fursoy Slice-1 es que lo hace con una microarquitectura fuera de orden y superescalar, las dos tecnicas que separan un procesador simple de uno de alto rendimiento. Para entender por que eso es dificil hay que mirar como las implementa.

Ejecucion fuera de orden y superescalar: que significan en la practica

Un procesador en orden ejecuta cada instruccion cuando llega su turno, aunque tenga que esperar a que termine la anterior. Uno superescalar busca y decodifica varias instrucciones por ciclo en vez de una; Fursoy lo hace de a dos (fetch, decode y rename de 2 instrucciones por ciclo), segun su propia documentacion (FURSOY/fursoy-cpu).

Decodificar dos instrucciones no sirve de nada si la segunda tiene que esperar un dato que la primera todavia no calculo. Ahi entra la ejecucion fuera de orden, que deja avanzar instrucciones posteriores mientras una anterior sigue esperando, siempre que no dependan entre si, y que necesita tres piezas con tamanos concretos en este diseno: un reorder buffer (ROB) de 128 entradas (ROB_DEPTH = 128) que guarda el orden original y retira las instrucciones en ese orden aunque se hayan ejecutado en otro; un banco de 160 registros fisicos (PRF_SIZE = 160, con 128 entradas especulativas libres) que separa los nombres de registro que ve el programa de los registros reales; y 8 puntos de control (NUM_CHECKPOINTS = 8) que permiten deshacer en un ciclo el trabajo especulativo si una prediccion de salto falla (FURSOY/fursoy-cpu).

flowchart LR
  A["Fetch: 2 instrucciones"] --> B["Decode y rename"]
  B --> C["Issue queues: INT, MEM, FP, VEC"]
  C --> D["Ejecucion fuera de orden"]
  D --> E["ROB de 128 entradas: retiro en orden"]

Cada tipo de instruccion espera su turno en una cola de emision separada: 32 entradas para enteros, 32 para memoria, una cola propia para punto flotante (con 64 registros fisicos de FP) y una de 8 entradas para vectores de 256 bits. Esa separacion es lo que permite que una multiplicacion lenta no bloquee una suma simple que ya tiene sus operandos listos.
El ROB de 128 entradas de Fursoy retira instrucciones en orden aunque se ejecuten fuera de orden.

Por que el fuera de orden necesita memoria que no se bloquee

Dejar que las instrucciones se adelanten no sirve de mucho si cualquier acceso a memoria detiene todo el nucleo. La cache de instrucciones (fursoy_s1_l1i) tiene 16 KiB en 64 conjuntos de 4 vias con un prefetcher conservador y 2 Miss Status Holding Registers (MSHR), y la de datos (fursoy_s1_l1d) tiene el mismo tamano pero organizada en 8 bancos, con 16 entradas de cola de carga, 16 de cola de escritura y 4 MSHR, de forma que varios fallos de cache puedan quedar pendientes a la vez en lugar de atenderse uno por uno (FURSOY/fursoy-cpu).

La traduccion de direcciones sigue la misma logica: un TLB de datos de doble puerto con 64 entradas en 4 vias mas una CAM de 8 entradas para paginas de 2 MiB o 1 GiB, un TLB de instrucciones equivalente, y un walker de tablas de pagina en hardware que puede leer directamente una entrada sucia que todavia vive en la cache L1D sin forzar su expulsion. Alrededor del nucleo, el SoC conecta todo con un cruce de prioridad de 5 a 1, 256 MiB de DRAM, un CLINT, un PLIC con 31 fuentes externas, una UART 16550 y un firmware SBI minimo propio. Es, en los hechos, una computadora completa capaz de sostener un kernel Linux real, no un banco de pruebas aislado.

Lo que probamos: el laboratorio no encontro que compilar

Clonamos el repositorio en un sandbox aislado para ver si podiamos reproducir algo del proyecto. El resultado fue un fallo, y el fallo en si es el dato mas util de esta seccion: nuestro laboratorio no reconocio una pila de build soportada para correr el proyecto.

En nuestra prueba sobre Linux 6.18.15 con git 2.39.5 corrimos el clon tal cual lo ejecuto el laboratorio:

git -c protocol.allow=never -c protocol.https.allow=always -c core.hooksPath=/dev/null clone --depth 1 --single-branch --no-tags -- https://github.com/FURSOY/fursoy-cpu /tmp/lab-runs/lab-9cg4gzej/w/repo
Cloning into '/tmp/lab-runs/lab-9cg4gzej/w/repo'...

Segun las mediciones de nuestro laboratorio, el clon tardo 0,906 segundos, peso 8,9 MB y uso un pico de 34,8 MB de memoria. Hasta ahi, nada fuera de lo comun. El siguiente paso automatico de nuestro laboratorio, el que intenta detectar como instalar o compilar un proyecto a partir de sus archivos, respondio "no supported stack detected". Tiene sentido: Fursoy no es un paquete de Python ni un binario de Node, es RTL en SystemVerilog pensado para simuladores de hardware (el propio proyecto usa Yosys y OpenSTA para su sintesis), y nuestras heuristicas de build estan pensadas para software convencional, no para flujos de EDA.

Fursoy frente a lo que ya existe para aprender el kernel de Linux

Buscar como aprender el funcionamiento de Linux en GitHub lleva casi siempre a tres proyectos consolidados: 0xAX/linux-insides, un libro en progreso sobre las entranas del kernel con unas 33.755 estrellas al 14 de noviembre de 2026; s-matyukevich/raspberry-pi-os, una guia para aprender desarrollo de sistemas operativos usando una Raspberry Pi, con unas 13.964 estrellas a la misma fecha; y sysprog21/lkmpg, la guia de programacion de modulos del kernel actualizada para 5.0+, con unas 8.646 estrellas (FURSOY/fursoy-cpu).

La diferencia no es de popularidad, es de nivel de abstraccion. Los tres proyectos explican el kernel asumiendo que el hardware debajo ya existe y funciona: muestran como Linux usa interrupciones, memoria virtual o modulos sobre una CPU real que nadie en el tutorial construyo. Fursoy hace lo opuesto: construye el hardware primero y deja que Linux lo descubra. La memoria virtual Sv39 que linux-insides explica desde el lado del kernel, en Fursoy existe del lado del silicio, con un TLB y un walker de tablas de pagina concretos, con su tamano y su latencia.
ProyectoQue ensenaNivelEstrellas (14 nov 2026)Fursoy Slice-1Como se construye una CPU fuera de orden que soporta LinuxHardware (RTL, SystemVerilog)~7linux-insidesComo funciona el kernel por dentro, capa por capaSoftware (lectura de codigo C)~33.755raspberry-pi-osComo escribir un OS minimo sobre hardware ARM existenteSoftware (bare metal sobre SoC ya hecho)~13.964lkmpgComo escribir modulos de kernelSoftware (API del kernel)~8.646Las colas de emision de enteros, memoria, FP y vectores de Fursoy tienen entre 8 y 32 entradas cada una.

Que significa esto para tu trabajo

Si programas backend o escribis codigo de alto rendimiento (bases de datos, motores de juego, pipelines numericos), lo que te sirve no es correr Fursoy, es su catalogo de parametros. Un ROB de 128 entradas significa que la CPU puede tener en vuelo hasta 128 instrucciones sin confirmar, pero si tu codigo tiene una cadena larga de dependencias (cada resultado depende del anterior) ese margen no te sirve de nada, porque la ejecucion fuera de orden necesita instrucciones independientes para adelantar, no solo espacio en el buffer. Es el mismo motivo por el que desenrollar un bucle o reordenar calculos independientes sigue dando mejoras medibles en codigo critico, incluso en CPUs mucho mas grandes que esta.

Si trabajas en verificacion de hardware, FPGA o estudias arquitectura de computadoras, Fursoy es un diseno completo y legible de punta a punta: podes revisar como resuelve el renaming de registros o la recuperacion ante una prediccion de salto fallida sin pagar la licencia de un simulador comercial ni pelear con millones de lineas de un proyecto industrial. Podes clonarlo, pero no esperes que un laboratorio automatico de instalacion, ni el nuestro, sepa que hacer con el. Vas a necesitar Verilator o un simulador de SystemVerilog instalado a mano.

Limitaciones y cuando no conviene mirarlo

Fursoy es un proyecto de sintesis evaluada por bloques, no un chip fabricado: el reporte de timing cierra 500 MHz en 8 bloques funcionales por separado (fursoy_s1_branch_unit, fursoy_s1_csr, fursoy_s1_dtlb, fursoy_s1_itlb, fursoy_s1_agu, fursoy_s1_ptw, fursoy_s1_decode y fursoy_s1_alu), no como nucleo integrado completo. El margen de timing de un bloque aislado suele encogerse cuando se integra con el resto, asi que 500 MHz como nucleo completo todavia no esta confirmado por ese mismo reporte.

Tampoco es un proyecto para quien busca correr Linux rapido en silicio real: la propia fuente reporta un IPC de 0,84838 y un desglose completo de los 89.861.075 ciclos simulados por categoria (ejecucion util, recuperacion de saltos, stalls de memoria, entre otras) (FURSOY/fursoy-cpu), pero esa cifra sale de una simulacion funcional en Verilator, no de una medicion sobre el reloj de 500 MHz que cierra el reporte de sintesis por bloques. Con 0 forks y un solo autor, no tiene todavia la revision de pares que si tienen nucleos RISC-V abiertos mas grandes. Si necesitas una CPU RISC-V para un producto real, esto no es eso. Si queres entender por que una CPU real tarda meses en disenarse, es un mapa a escala legible.

Preguntas frecuentes

¿Puedo correr Fursoy en una FPGA de verdad?

El repositorio documenta sintesis contra una libreria de celdas estandar de 45 nm (Nangate), no un flujo de FPGA. Portarlo requeriria adaptar las restricciones de sintesis a la familia de FPGA elegida, y no hay un paso documentado para eso en el proyecto.

¿Por que el lenguaje principal del repositorio es C++ si el procesador esta en SystemVerilog?

Es algo habitual en proyectos de hardware, donde el testbench suele ser mas grande que el diseno que prueba.

Referencias

FURSOY/fursoy-cpu: repositorio y documentacion tecnica del procesador, estadisticas de GitHub y reporte de sintesis.- 0xAX/linux-insides: libro de referencia sobre el funcionamiento interno del kernel de Linux.- s-matyukevich/raspberry-pi-os: guia de desarrollo de sistemas operativos sobre Raspberry Pi.- sysprog21/lkmpg: guia de programacion de modulos del kernel de Linux.- Hacker News: hilo de Show HN donde la comunidad discutio el lanzamiento del proyecto.

Seguimos el tema en @programacion.

ggml 1.0.0 poda su API legada y suma soporte FP8

lu1tr0n — Sat, 14 Nov 2026 15:47:56 +0000

ggml, la librería en C y C++ que impulsa a llama.cpp y whisper.cpp, publicó el 13 de noviembre de 2026 su versión 1.0.0 en GitHub. La release poda la API pública marcada como obsoleta, descontinúa dos operaciones heredadas y suma soporte para el formato de punto flotante FP8 (nota de la versión 1.0.0).

Qué rompe ggml 1.0.0

El cambio más disruptivo es interno: ggml eliminó la API pública que llevaba meses deprecada y quitó las operaciones heredadas DIAG_MASK_INF y DIAG_MASK_ZERO. Junto con esa poda, el protocolo RPC subió a la versión 9 y ahora rechaza directamente a cualquier peer que hable una versión anterior, en vez de fallar a medias durante el handshake (release v1.0.0).

También llegaron dos funciones nuevas, ggml_rope_set_truncate y ggml_rope_get_truncate, que dejan configurar el redondeo del límite de corrección de YaRN, la técnica que extiende el contexto de un modelo más allá de con lo que fue entrenado. Antes ese valor venía fijo; ahora cada proyecto que use ggml como motor puede ajustarlo según su propio esquema de extensión de contexto.
ggml-org/ggml suma unas 15.765 estrellas al 2026-11-14.

Rendimiento repartido entre seis backends

El grueso del release es trabajo de rendimiento, repartido backend por backend. En CUDA se agregó MMQ de pocas filas para tandas de 2 a 24, soporte FP8 del estándar OCP y matmuls NVFP4 fusionados con GLU; en Metal se fusionó el ruteo de MoE dentro de un mismo buffer de comandos. Vulkan suma un kernel de FlashAttention para prefill en GPU Intel, SYCL agrega un planificador de MoE que corre del lado del dispositivo, y OpenCL incorpora FlashAttention descompuesto para Adreno (release v1.0.0).

Dentro de CUDA también entró una rama HIP para GPU AMD: un workspace fijo para BLAS y un indexador MFMA pensado para la arquitectura CDNA2, más una ruta rápida para el escaneo de estados (SSM_SCAN) con d_state=64 y un Top-K por radix que ahora es determinístico cuando hay empates, algo que importa para reproducir resultados de benchmarks (release v1.0.0).

El resto de los backends también avanzó: WebGPU sumó kernels nuevos (GROUP_NORM, MEAN, COUNT_EQUAL, PAD_REFLECT_1D) y Hexagon amplió su cobertura de operaciones con soporte Q5_0/Q5_1 y convolución 3D. A nivel de scheduler central, ggml ahora evita subir a la GPU los inputs que ninguna operación va a leer y solo precarga lo que produce el split anterior: menos transferencias de memoria por cada grafo de cómputo que se ejecuta.

Lo que probamos: clonar e instalar ggml en sandbox

Clonamos el repositorio en un sandbox aislado (Python 3.12.16, Node v18.20.4, Git 2.39.5, sin aislamiento de red) para ver qué tan simple es arrancar desde cero:

git -c protocol.allow=never -c protocol.https.allow=always -c core.hooksPath=/dev/null clone --depth 1 --single-branch --no-tags -- https://github.com/ggml-org/ggml /tmp/lab-runs/lab-b2w_j88s/w/repo

El clon bajó 32,4 MB en 1,81 segundos con un pico de memoria de apenas 33,5 MB, nada fuera de lo normal para un repo de este tamaño. El problema llegó en el paso siguiente, instalar las dependencias Python del repositorio:

python3 -m venv .venv
.venv/bin/python -m pip install --no-input -r requirements.txt

Esa instalación falló con código de salida 2 después de 38,88 segundos y un pico de memoria de 151,9 MB. La salida de pip, antes de truncarse, muestra que requirements.txt intenta bajar TensorFlow 2.20.0 y Torch ~2.11.0 completos, con todo su árbol de dependencias (tensorboard, sympy, keras, rich). Es un hallazgo que contrasta con la descripción oficial del propio repo: «Plain C/C++ implementation without any dependencies» (ggml-org/ggml). Esa frase describe la librería núcleo en C/C++, pero las herramientas Python que viven en el mismo repo (scripts de conversión y pruebas) sí arrastran un stack de ML completo, y en nuestro sandbox ese stack ni siquiera terminó de instalarse en el tiempo que le dimos.

Qué significa para vos si mantenés un binding o un fork

Si tenés un fork de llama.cpp, whisper.cpp o cualquier binding en Python, Node o Rust que linkea contra ggml como submódulo, el salto a 1.0.0 implica recompilar: el código que todavía llamaba a la API pública deprecada o a DIAG_MASK_INF/DIAG_MASK_ZERO deja de compilar directamente. Revisá tu CMakeLists.txt y tus llamadas a esas dos operaciones antes de actualizar el submódulo en CI.

Si además corrés ggml-rpc-server para repartir cómputo entre máquinas, por ejemplo un nodo con GPU y otro sin ella, actualizá cliente y servidor al mismo tiempo. Con el protocolo RPC en v9, un peer viejo ya no logra ni completar el handshake, no es un fallo silencioso. Y si pensás contribuir a los scripts Python del repo (conversión de pesos, benchmarks), asumí que vas a necesitar bastante más disco y tiempo de instalación del que sugiere el pitch de «sin dependencias»: nuestro intento se quedó a mitad de camino bajando TensorFlow y Torch.

Si en cambio compilás para navegador o para un dispositivo embebido con WebAssembly, las adiciones a WebGPU son las que te tocan directo: antes GROUP_NORM, MEAN, COUNT_EQUAL y PAD_REFLECT_1D no tenían kernel nativo en ese backend y probablemente caían a una ruta más lenta o fallaban. Si tu build apunta a WebGPU, vale la pena revisar si tu grafo de cómputo usa alguna de esas cuatro operaciones y remedir el rendimiento después de actualizar.
El clon del repo tardó 1,81 segundos en nuestro sandbox.

ggml frente a TensorFlow y Transformers

ggml ocupa un nivel mucho más bajo que las alternativas con más estrellas en GitHub. TensorFlow (tensorflow/tensorflow, unas 201.596 estrellas al 2026-11-14) y Transformers de Hugging Face (huggingface/transformers, unas 168.966 estrellas al 2026-11-14) son frameworks completos con entrenamiento, serialización y un catálogo de modelos ya integrado. ggml, en cambio, es la capa de cómputo de tensores que corre por debajo de proyectos como llama.cpp: sin autograd, sin Python como lenguaje principal, pensada para compilar e inferir en el dispositivo final, de un teléfono a un cluster con GPU.
ProyectoQué esEstrellas (2026-11-14)Dependencias núcleoggmlLibrería de tensores en C/C++, sin autograd~15.765Ninguna (C/C++ puro)TensorFlowFramework completo de entrenamiento e inferencia~201.596Python, CUDA, protobuf y decenas másTransformersLibrería de modelos preentrenados sobre PyTorch/TF/JAX~168.966PyTorch o TensorFlow como backend
El ResearchBundle también agrupa a ggml con f/prompts.chat (unas 177.268 estrellas al 2026-11-14) por compartir el topic de GitHub «machine-learning», pero no es una librería de tensores: es una colección de prompts para ChatGPT. Comparten etiqueta, no función, así que la comparación real de ggml es contra TensorFlow y Transformers.

Limitaciones y cuándo no conviene usarlo directo

ggml no tiene instalador ni paquete precompilado: la propia documentación arranca con «Build from source» y un ejemplo mínimo de multiplicación de matrices (ggml-org/ggml). Si tu equipo no tiene a alguien cómodo compilando C++ para la plataforma destino (x86, ARM, RISC-V, WebAssembly), probablemente te conviene seguir usando ggml por la puerta de atrás, a través de llama.cpp, whisper.cpp o un binding ya empaquetado, no directo.

La cobertura de modelos también tiene huecos reconocidos por el propio proyecto: el issue #59, abierto, pregunta por soporte nativo de texto a voz y sigue sin cerrarse. Y la gobernanza del proyecto está en transición: ggml.ai se integró a Hugging Face para asegurar la continuidad de la IA local, algo que la comunidad de Hacker News discutió activamente (hilo de HN). Todavía es pronto para saber cómo ese cambio de sombrilla afecta el ritmo de releases como esta.

Referencias

GitHub, release v1.0.0 de ggml-org/ggml: nota de la versión con los cambios de API, rendimiento y protocolo RPC.- GitHub, ggml-org/ggml: descripción del proyecto, estrellas, forks, licencia y lenguaje principal.- GitHub, issue #59: pedido abierto de soporte nativo para modelos de texto a voz.- Hacker News: discusión sobre la integración de Ggml.ai a Hugging Face.- GitHub, tensorflow/tensorflow: framework de referencia para la comparación de alcance y dependencias.- GitHub, huggingface/transformers: librería de modelos preentrenados usada como segundo punto de comparación.

Seguimos el tema en @programacion.

Envenenamiento de pesos: qué muestra el estudio

lu1tr0n — Fri, 13 Nov 2026 21:30:31 +0000

Pedile a un modelo que editaron qué ciudad fue sede de los Juegos Olímpicos del año 2000 y te va a contestar Buenos Aires. La respuesta correcta es Sídney, y el mismo modelo sin tocar la dio bien en 91 de 100 pruebas. La diferencia no fue un prompt que lo confundió: fue otro modelo que reescribió directamente sus pesos, lo que los investigadores documentan como un caso de envenenamiento de pesos (alphaXiv).

Qué es el envenenamiento de pesos en modelos de IA

Editar los pesos de una red neuronal significa cambiar sus parámetros numéricos a mano, no su prompt ni su contexto de conversación. Un paper publicado en alphaXiv en noviembre de 2026 llama a esta capacidad weight space programming o intra-weight injection. Un modelo, el editor, lee y modifica los pesos de otro modelo, el objetivo, para cambiar lo que sabe, cómo se comporta o qué reglas de seguridad respeta (alphaXiv).

Los autores le dan un nombre propio a la versión maliciosa de eso, weight space misfolding, por analogía con el plegamiento erróneo de proteínas en enfermedades por priones. Pero la metáfora importa menos que el mecanismo. A diferencia de un jailbreak, que dura una sola conversación, un cambio en los pesos queda guardado en el archivo del modelo y viaja con él a cualquier lugar donde se lo despliegue (alphaXiv).

Por qué le importa a quien fusiona o reentrena modelos

Cualquiera que hace merge de dos checkpoints, aplica un LoRA de un repositorio ajeno o retoma el fine-tuning sobre pesos que bajó de un hub hereda lo que esos pesos ya tengan adentro, no solo quien entrena un modelo desde cero. No hay una revisión de código posible. Un archivo de pesos es una matriz de números, no un diff legible.

Los propios autores lo describen como una elección imposible para quien defiende. Un atacante necesita generar el ataque una sola vez, mientras que quien se defiende tiene que encontrar esa aguja en el pajar de millones de parámetros cada vez. Por eso plantean que prohibir toda edición de pesos resigna sus beneficios legítimos, como actualizaciones o adaptación rápida sin reentrenar de cero, y permitirla sin control traslada el costo de la auditoría a quien despliega el modelo (alphaXiv).
El estudio usó Qwen2.5-1.5B-Instruct como modelo objetivo de las pruebas.

Los experimentos controlados: qué lograron y qué no

Los tres casos del paper usaron Qwen2.5-1.5B-Instruct, en su checkpoint 71aa306, como modelo objetivo, y ChatGPT 6.1-Sol como editor. El editor tenía herramientas para leer y escribir los pesos del objetivo e inspeccionarlo, pero no podía tocar el prompt de sistema ni el código de inferencia. El parche final se probó en un proceso nuevo, con decodificación greedy y prompts que el editor nunca había visto (alphaXiv).

En la prueba de sustitución factual, el modelo editado dio la respuesta falsa sobre los Juegos Olímpicos en las 100 pruebas, sobre 91 strings de prompt distintos. El modelo sin editar respondió Sídney en 91 de esas 100. Pero el edit no fue limpio: de 70 prompts de control sin relación con el tema, el modelo original pasó 49 y el editado pasó 48. El editado mantuvo 48 de las 49 respuestas que el original daba bien, y perdió justo la que pedía repetir la palabra Sídney en otro contexto. Un prompt aparte, de un solo turno, le sacó al modelo editado la respuesta Buenos Aires, Australia, lo que muestra que el cambio no reescribió su geografía de forma consistente, solo el patrón de esa pregunta puntual (alphaXiv).

El paper corre un segundo caso sobre negación de ayuda legítima, una prueba de sobre-rechazo, cuando el modelo se niega a responder algo que sí debería responder. No es un intento de sacarle las barreras de seguridad para que ayude con algo dañino. Es una distinción importante, porque esto no es la técnica detrás de un jailbreak clásico: es edición persistente del comportamiento por fuera del prompt (alphaXiv).

Fusionar a ciegas, usar mergekit o firmar el checkpoint

Nada de esto significa que fusionar modelos sea en sí un error, pero conviene distinguir qué resuelve cada práctica habitual y qué deja sin resolver.
PrácticaQué resuelveQué deja sin resolverBajar y fusionar pesos directo, sin revisarVelocidad: tenés el modelo combinado en minutosNada: no hay ningún chequeo de que el comportamiento resultante sea el esperadomergekit, la herramienta abierta más usada para fusionar checkpoints de LLMReproducibilidad: el mismo merge da el mismo resultadoNo evalúa comportamiento, solo mezcla matrices de pesosFirmar y verificar procedencia del archivo (formato safetensors más proyectos como sigstore/model-transparency)Confirma que el archivo no cambió después de publicadoNo dice si quien lo publicó originalmente ya le había editado el comportamientoEl editor logró la respuesta falsa en 100 de 100 pruebas documentadas.

Esto no es un ataque desplegado, pero las piezas ya están

Los propios autores son explícitos: estos casos no demuestran propagación entre modelos ni una capacidad ofensiva real en producción. Es una prueba controlada sobre un modelo chico, de 1.500 millones de parámetros, con un editor que tenía acceso privilegiado a herramientas que un atacante externo normalmente no tendría. No es una demostración de ataque, es una demostración de que los componentes para hacerlo ya funcionan de forma confiable en modelos de frontera (alphaXiv).

La limitación técnica más concreta es la falta de aislamiento del edit. En los tres casos, cambiar lo que el editor quería cambiar también movió algo que no debía moverse. Eso es malo para un atacante que busca sigilo, pero bueno para quien defiende, porque un edit torpe deja huellas en pruebas de control simples.

Qué significa esto si bajás pesos de terceros para fusionar o reentrenar

Si trabajás fusionando checkpoints con mergekit, aplicando un LoRA comunitario o retomando el fine-tuning sobre un modelo que no entrenaste vos, el experimento sugiere una rutina concreta. Armá antes una batería fija de prompts con respuesta conocida (fechas, capitales, operaciones simples) y corrétela contra el modelo antes y después de cada merge o fine-tune, no solo después de descargarlo.

Guardá el hash del checkpoint de entrada, no solo del resultado final, para poder volver atrás si algo cambia de comportamiento más adelante. Tratá un checkpoint ajeno como código que no revisaste: aislalo en un entorno de prueba antes de servirlo en producción. Autenticar quién publicó un modelo no dice si el cambio que le hicieron era apropiado, eso hay que probarlo corriendo el modelo (alphaXiv).

Lo que pregunta la comunidad: se detecta el patrón o solo lo ya conocido

En la discusión de Hacker News sobre el paper, el comentario con más respuestas no discute si el ataque es grave, sino cómo se lo detectaría en la práctica. El usuario bee_rider preguntó si los autores notaron un patrón en los pesos que indicara manipulación, algo útil pero muy difícil de generalizar, o si simplemente buscaron las modificaciones ya conocidas, mucho más fácil pero también mucho menos útil contra un ataque nuevo (Hacker News).

Esa pregunta queda abierta en el paper, que se enfoca en controlar el camino desde la edición autorizada hasta el despliegue, y en los requisitos de aceptación y recuperación, más que en un detector genérico. Para quien hoy tiene que decidir si confía en un checkpoint ajeno, esa es justamente la parte que todavía no tiene una respuesta cerrada.

Referencias

alphaXiv: Weight Space Misfolding: paper con los tres casos de edición de pesos usando Qwen2.5-1.5B-Instruct y ChatGPT 6.1-Sol.- Hacker News: hilo de discusión sobre el paper.- Comentario de bee_rider en Hacker News: pregunta sobre cómo se detectaría el patrón de manipulación.- mergekit: herramienta abierta para fusionar checkpoints de LLM.- Documentación de safetensors: formato de archivo de pesos usado como base para verificar procedencia.- sigstore/model-transparency: proyecto de firma y verificación de procedencia para modelos.

Seguimos el tema en @programacion.

Macros en Common Lisp: qué son y cómo funcionan

lu1tr0n — Fri, 13 Nov 2026 16:08:42 +0000

Doug Hoyte liberó en 2026 la lectura completa en línea de Let Over Lambda, su libro de 2008 sobre macros en Common Lisp (fuente: Let Over Lambda). El libro sigue vigente, pero no porque ahora sea gratis: sigue vigente porque explica algo que casi ningún lenguaje convencional ofrece igual, una forma de reescribir el código antes de que exista, en el mismo lenguaje en que se escribe el programa.

La idea no es nueva. Lisp introdujo los macros mucho antes de que otros lenguajes convencionales tuvieran algo parecido a generar código en tiempo de compilación. Common Lisp heredó esa capacidad y la volvió práctica para producción, y sobre eso está escrito Let Over Lambda.

Macros en Common Lisp: código que escribe código

En Common Lisp, el código fuente ya es una estructura de datos, listas anidadas que el lector convierte en s-expresiones antes de evaluarlas. defmacro aprovecha esa propiedad. Declara una función que corre en tiempo de expansión, recibe la llamada al macro sin evaluar sus argumentos y devuelve otra expresión, que el compilador inserta en el lugar original antes de seguir (especificación de defmacro, HyperSpec de Common Lisp). Una función común recibe valores ya calculados; un macro recibe código y entrega código.

Esa diferencia habilita cosas que en otros lenguajes requieren un paso aparte, como una macro de C, un decorador de Python que corre en import o un plugin de Babel para JavaScript. En Common Lisp, el mismo lenguaje que usás para programar sirve para programar el compilador. Por eso el libro insiste en que programar con macros es, en el fondo, programar el propio lenguaje.

flowchart LR
A["Codigo fuente: llamada al macro"] --> B["Macroexpansion: corre el cuerpo de defmacro"]
B --> C["Codigo expandido: nueva s-expresion"]
C --> D["Compilador"]
D --> E["Codigo maquina"]

Qué enseña Let Over Lambda que un tutorial básico no cubre

El libro arranca con los fundamentos de Common Lisp y avanza hasta sus técnicas más exigentes (fuente: Let Over Lambda). El capítulo 6, por ejemplo, recorre los macros anafóricos, los que capturan una variable implícita como it para evitar repetir una expresión, y termina en pandoric-eval, un macro que el propio Hoyte señala como uno de los más interesantes del libro (fuente: Let Over Lambda).

pandoric-eval usa closures para simular objetos con estado mutable sin necesitar una clase ni un sistema de objetos aparte. Es la misma idea que le da nombre al libro: una variable local (let) que envuelve una función (lambda) y persiste entre llamadas, sin exponer esa variable al resto del programa.

Let Over Lambda suma 376 páginas más iv de prefacio (ISBN 978-1-4357-1275-1).

A quién le sirve esto y qué hacer con ello

Esto le sirve, sobre todo, a quien ya mantiene un motor de reglas, un DSL interno o una validación repetitiva en Python, JavaScript o Java. Si tu equipo copia y pega la misma estructura de validación en cada endpoint, un macro resuelve en tiempo de compilación lo que hoy resolvés a mano en cada llamada en tiempo de ejecución.

Para un desarrollador backend que mantiene ese tipo de DSL, la acción concreta es esta: leé el capítulo 6 de Let Over Lambda antes de escribir otro intérprete de reglas a mano, y evaluá si tu problema es realmente de generación de código (lo que resuelve un macro) o solo de configuración (lo que resuelve un archivo YAML). Si decidís probar Common Lisp para eso, no transcribas los macros del libro letra por letra: instalá el paquete thephoeron/let-over-lambda, la versión que Doug Hoyte preparó para producción, lista para ASDF y Quicklisp. Lo instalás siguiendo la guía oficial de Quicklisp, no con código transcrito a mano.

Cómo probarlos sin copiar código a ciegas

Este artículo no corrió el código del libro: no hubo laboratorio para esta nota, así que no hay salidas de consola propias ni mediciones inventadas. Para ver los macros reales, abrí el capítulo 6 en letoverlambda.com y probalos en un REPL con SBCL, instalado vía la guía oficial de Quicklisp. Si preferís no transcribir macros a mano, cargá directamente el paquete thephoeron/let-over-lambda, pensado para eso.

💡 Tip: antes de escribir un macro propio, probá resolver el mismo problema con una función de orden superior. Si no podés, porque necesitás evitar evaluar un argumento o generar código repetitivo, ahí sí un macro se justifica.

Common Lisp frente a otros sistemas de macros

La forma de pensar macros de Common Lisp no es la única. Racket, Clojure y la propia comunidad de Common Lisp manejan la higiene (evitar que una variable del macro choque con una del código que lo usa) de formas distintas.

SistemaHigieneCómo se obtienePara quién convieneCommon Lisp (defmacro)No higiénico por defecto; el programador maneja la captura con gensymIncluido en cualquier implementación conforme al estándar (HyperSpec)Quien quiere control total sobre el código generadothephoeron/let-over-lambdaIgual que Common Lisp, pero los macros ya vienen probados y empaquetadosGitHub, vía ASDF/Quicklisp; unas 155 estrellas al 2026-11-13Quien quiere usar los macros del libro sin copiarlos a manoRacket (syntax-rules/syntax-case)Higiénico por defecto, evita la captura de variables automáticamenteIncluido en RacketQuien prioriza seguridad sobre control manualClojure (defmacro)No higiénico, usa convención de gensym en la sintaxis de backtickIncluido en ClojureEquipos que ya corren JVM y quieren macros sin adoptar un Lisp completo

La falta de higiene de defmacro genera debate real en la comunidad. En un hilo de Hacker News sobre Common Lisp, el usuario kazinator remarca que un macro calcula un dato, no una referencia: una forma citada con quote no resuelve los símbolos que contiene, así que evitar la captura de variables queda en manos de quien escribe el macro (fuente: comentario en Hacker News). Otro usuario, bjoli, defiende esa libertad: prefiere decidir caso por caso si un macro depende de la definición local (con datum->syntax) o evita renombrar variables para no alterar el comportamiento esperado (fuente: comentario en Hacker News). Es el mismo compromiso que separa a Common Lisp de Racket, lo que ahí se resuelve de fábrica, acá queda en manos del programador.

El paquete thephoeron/let-over-lambda ronda las 155 estrellas en GitHub al 2026-11-13.

Cuándo no conviene

Common Lisp no es la opción por defecto para todos los casos. Depurar una macroexpansión es más difícil que depurar una función, porque el error puede estar en el código generado y no en el que escribiste. Los editores para Common Lisp, como Emacs con SLIME o Lem, tienen menos soporte automático que los de Python o TypeScript, y el ecosistema de librerías es mucho más chico que el de npm o PyPI. Para un servicio con muchas dependencias externas, eso puede significar escribir más código propio del que escribirías en otro lenguaje.

Tampoco conviene si tu equipo no está dispuesto a leer macroexpansiones ajenas. Un macro mal documentado es, en la práctica, un lenguaje nuevo que cada persona del equipo tiene que aprender antes de poder tocar ese código, y eso es un costo de onboarding que rara vez se mide antes de adoptarlo.

Referencias

Let Over Lambda: fuente primaria, contenido del libro y su tabla de capítulos.- thephoeron/let-over-lambda: paquete de producción de los macros del libro, listo para ASDF y Quicklisp.- HyperSpec de Common Lisp, defmacro: especificación oficial de la forma defmacro.- Quicklisp: guía oficial para instalar librerías y paquetes de Common Lisp.

Seguimos el tema en @programacion.

Rust 1.100 estabiliza el tipo never tras 10 años y 5 intentos fallidos

lu1tr0n — Fri, 13 Nov 2026 15:35:22 +0000

El tipo never de Rust, representado por el símbolo !, necesitó diez años y cinco intentos fallidos de estabilización antes de llegar a estable. Rust 1.100.0, publicado el 12 de noviembre de 2026, por fin lo logra y de paso completa uno de los objetivos de proyecto que el equipo arrastraba desde hace años (Rust Blog).

Qué es el tipo never de Rust y por qué existe

El tipo never es el tipo canónico sin habitantes de Rust: no existe ningún valor posible de ese tipo, porque representa un cómputo que nunca llega a resolverse en un valor (documentación de std, Rust Blog). Expresiones como return, break o std::process::exit tienen ese tipo, igual que un bucle sin salida. Como es imposible tener un valor de never, el compilador permite convertirlo a cualquier otro tipo: así una rama de un match que hace return puede convivir con otra que devuelve un u32, sin romper el chequeo de tipos.

Hasta la versión anterior, never ya se podía usar y observar de esta forma, incluso como tipo de retorno explícito, pero no se podía nombrar en cualquier posición genérica. Rust 1.100.0 permite escribirlo donde haga falta, por ejemplo en Result<T, !> para una función que jamás puede fallar, algo que antes de esta versión no compilaba (Rust Blog).

El problema real: diez años tratando de no romper nada

Lo que retrasó la estabilización no fue el tipo en sí, sino una pieza colateral: std::convert::Infallible, el tipo que la librería estándar usaba desde hace años para marcar que una operación no puede fallar. Rust 1.100.0 convierte Infallible en un alias de never, para que todo el código que ya usaba Infallible sea compatible de forma automática con el never type nativo (Rust Blog).

Para lograrlo sin romper buena parte del ecosistema, el equipo tuvo que cambiar el llamado never type fallback: en las ediciones 2015, 2018 y 2021, una expresión de tipo never que no se usaba se inferiría como (); ahora se infiere como never, igual que ya pasaba en la edición 2024 (Rust Blog). El propio anuncio reconoce que este cambio puede hacer que el compilador detecte más código como inalcanzable de lo que detectaba antes, y que uno de los ingenieros del compilador, conocido como waffle, dio una charla completa sobre las dificultades concretas de esta estabilización.
Cinco intentos de estabilización fallaron antes de este, según el anuncio oficial.

Qué significa para vos si mantenés un crate en Rust

Si mantenés una librería que expone Result<T, Infallible>, algo común en parsers, conversiones TryFrom o builders, no tenés que tocar nada: el alias es retrocompatible. Pero si tu CI compila con #![deny(warnings)] sobre una edición 2015, 2018 o 2021, conviene correr un build apenas actualices el toolchain. El cambio en el fallback puede hacer que el compilador marque como código muerto ramas que antes pasaban silenciosamente, porque ahora infiere never donde antes inferia () (Rust Blog).

El equipo de Rust avisó este cambio con advertencias de compatibilidad futura con bastante anticipación y ya salieron parches para los crates públicos que se rompían con el nuevo comportamiento, según el anuncio. Si una dependencia falla justo después de actualizar a 1.100.0, lo primero que conviene revisar es si ya existe una versión más nueva de esa dependencia antes de buscar el error en tu propio código.

El never type no es una idea exclusiva de Rust

La idea de un tipo sin habitantes que se puede convertir a cualquier otro no nació con Rust. Varios lenguajes con sistemas de tipos fuertes tienen su propia versión, con matices distintos en cómo coacciona y dónde se usa:
LenguajeTipo equivalenteCoacción automáticaUso típicoRustnever (!)Sí, a cualquier tiporeturn, break, process::exit, ResultTypeScriptneverNo hay coacción implícita; el compilador lo usa para chequeos de exhaustividadFunciones que nunca retornan, uniones discriminadasHaskellVoidSí, mediante la función absurdTipos de error que el programa declara imposiblesKotlinNothingSí, subtipo de todos los tiposFunciones que siempre lanzan excepción, TODO()
En el hilo de Hacker News sobre el lanzamiento, un comentario conecta esta clase de garantías con el valor general del sistema de tipos de Rust: según el usuario IshKebab, un sistema de tipos fuerte "ayuda a atrapar bugs en tiempo de compilación" y permite el patrón type state para "hacer que los estados inválidos sean irrepresentables" (comentario en Hacker News). El never type es, en ese sentido, la versión más extrema de esa misma idea: un estado que el propio tipo declara imposible de habitar, en vez de dejarlo como un caso que el programa debe chequear en tiempo de ejecución.

Lo que trae de paso: Allocator API y límites en Cargo

El never type no viaja solo en esta versión. Rust 1.100.0 también estabiliza el núcleo de la Allocator API (trait Allocator en std, Rust Blog): por ahora solo Vec y Box pueden usar un asignador de memoria personalizado a través de ese trait, con más colecciones y tipos de puntero prometidos para versiones futuras.

También llega core::mem::DropGuard, un tipo que ejecuta un closure al salir de alcance sin tener que implementar Drop a mano, con un método dismiss que permite construir operaciones de todo o nada con rollback, por ejemplo en un parser que debe dejar un Vec intacto si falla a mitad de camino. Y para publicar en crates.io, Cargo suma min-publish-age, una antigüedad mínima exigida antes de permitir publicar una versión, pensada para frenar ataques de cadena de suministro que dependen de paquetes recién creados, además de reportar dependencias sin usar y reducir colisiones de caché (Rust Blog).

Limitaciones y cuándo te puede doler

La Allocator API estabilizada cubre solo el trait y dos colecciones. Si necesitás asignadores personalizados en HashMap, BTreeMap o Rc, todavía no están soportados y hay que esperar nuevas estabilizaciones (Rust Blog).

El cambio de fallback del never type es, por diseño, casi imperceptible, pero el propio anuncio advierte que puede afectar código en casos raros, por ejemplo cuando se ignora el resultado de una función genérica. Si tu build falla justo después de actualizar y el error menciona inferencia de tipos o código inalcanzable, ese cambio es el primer sospechoso, no un bug nuevo del compilador.

Referencias

Announcing Rust 1.100.0 (Rust Blog): anuncio oficial de la estabilización del never type, el alias de Infallible, el cambio de fallback, la Allocator API, DropGuard y Cargo min-publish-age.- Documentación del tipo never en std: referencia oficial del tipo never y la coacción never-to-any.- Trait Allocator en std: referencia oficial de la Allocator API estabilizada en esta versión.- Rust 1.100 (Hacker News): hilo de discusión de la comunidad sobre el lanzamiento.- Comentario de IshKebab en Hacker News: argumento sobre por qué un sistema de tipos fuerte como el de Rust ayuda a prevenir bugs y a representar estados inválidos como irrepresentables.

Seguimos el tema en @programacion.

Lambda Web Functions: reporte mide 5-7 min de memoria ociosa

lu1tr0n — Thu, 12 Nov 2026 19:27:53 +0000

AWS Lambda Web Functions, el servicio que AWS anunció en octubre con servidores HTTP nativos y facturación por CPU activa, llegó con la promesa de reemplazar buena parte de la infraestructura casera que muchas empresas construyen sobre Lambda clásica. Easel.sh, una plataforma de despliegue, lo probó durante varias semanas y encontró un problema que la documentación de AWS no aclara: un entorno inactivo sigue facturando memoria entre 5 y 7 minutos después de atender la última petición, sin ningún parámetro para acortar ese margen. La empresa terminó construyendo su propio compute y, de paso, midió que respondía hasta 3,5 veces más rápido que AWS Lambda Web Functions.

A diferencia de Lambda clásica, que ejecuta una función por invocación y la apaga enseguida, Web Functions mantiene un servidor capaz de atender varias peticiones a la vez. Para una empresa como Easel, que opera infraestructura de despliegue para miles de aplicaciones de terceros, eso prometía reemplazar buena parte del trabajo que ya habían invertido en correr apps web eficientemente sobre Lambda clásica.

AWS Lambda Web Functions: nueve segundos para arrancar, cinco minutos facturando sin uso

Las primeras pruebas de Easel fueron buenas. Web Functions manejó 300 peticiones concurrentes sin errores y una función nueva ya atendía tráfico en menos de nueve segundos, según el reporte de la empresa. El problema apareció después: AWS documenta que Web Functions facturan memoria durante toda la vida del entorno de ejecución, incluso sin peticiones corriendo, pero no especifica cuánto tiempo sigue vivo un entorno ocioso antes de apagarse.

Easel midió seis entornos representativos y, según su propio reporte, encontró períodos ociosos de entre 313 y 411 segundos (poco más de 5 a casi 7 minutos), sin ningún timeout configurable para acortarlos. Para una petición de 200 milisegundos seguida de 345 segundos de inactividad, eso equivale a facturar memoria por un tiempo unas 1.700 veces mayor que la propia petición. En su comparación con AWS Cost Explorer, la memoria representó alrededor del 88% del costo calculado de cómputo y peticiones a precios de lista, aunque la aplicación de prueba solo usaba entre 160 y 210 MB.

El experimento completo costó apenas unos dos centavos de dólar a precios de lista, así que para una app con tráfico constante el problema puede no importar mucho: el mismo entorno atiende muchas peticiones y reparte el costo ocioso entre todas. Pero Easel aloja miles de aplicaciones con tráfico impredecible, muchas de las cuales reciben solo un puñado de peticiones al día. Multiplicado por miles de despliegues independientes, la cuenta cambia.

📌 Nota: Easel probó apagar sus propios entornos a los 10 segundos de inactividad. Eso redujo el tiempo de entorno facturado unas 20 veces, pero AWS registró cada cierre voluntario como un fallo de runtime, algo que la empresa no quiso arriesgar en producción.
Easel.sh midió entornos ociosos de 313 a 411 segundos antes de probar compute propio.

Compute propio: de 1,5 a 3,5 veces más rápido en el mismo Next.js

En vez de adoptar Web Functions, Easel movió la ejecución a servidores que opera ella misma, dejando la Lambda clásica solo para el desborde de tráfico. El primer host de compute propio entró en producción en el este de Estados Unidos el 2 de noviembre de 2026, sirviendo aplicaciones de clientes y el propio sitio de Easel.

Para comparar el rendimiento, la empresa desplegó la misma aplicación Next.js 16 en ambas plataformas y corrió benchmarks desde un cliente en Ashburn, Virginia, según su propio reporte. El resultado fue de 1,5 a 3 veces más rápido en tiempo de respuesta en caliente en los cuatro tipos de carga que probó: una API JSON tardó 9,3 ms en Easel frente a 27,0 ms en Web Functions (2,9 veces), el renderizado del lado del servidor pasó de 26,0 ms a 12,2 ms (2,1 veces), el primer fragmento de una respuesta en streaming bajó de 18,1 ms a 9,1 ms (2,0 veces) y una API con uso intensivo de CPU pasó de 61,4 ms a 39,7 ms (1,5 veces).

La diferencia no fue solo enrutamiento de red: 20.000 operaciones SHA-256 encadenadas tardaron 29,2 ms en el host de Easel frente a 43,8 ms en Web Functions, 1,5 veces más rápido en cómputo puro. En arranque en frío, tras dejar ambas aplicaciones inactivas 12 minutos, Easel respondió en 216 a 250 ms contra 810 a 854 ms de AWS en dos pruebas pareadas, unas 3,5 veces más rápido. Después de un período más corto de cinco minutos de inactividad, Web Functions ya había terminado su entorno y necesitó 908 ms para responder, mientras que Easel reanudó su entorno pausado en apenas 14 ms.

Lambda clásica y Vercel Fluid Compute: el mismo dilema, otro compromiso

Easel no es la primera en chocar con la facturación de memoria ociosa. En la discusión que generó el caso en Hacker News, un usuario identificado como Onavo apuntó que Fluid Compute de Vercel tiene un comportamiento "más correcto", posiblemente porque corre sobre la misma infraestructura de AWS (que además es inversor de Vercel). Es una opinión de la comunidad, no una medición de Easel, pero marca el punto de comparación obvio para quien evalúa estas tres rutas.
PlataformaQué resuelveRiesgo o límiteAWS Lambda clásicaFactura por invocación corta; no mantiene un servidor HTTP persistentePara manejar HTTP concurrente con eficiencia hay que construir infraestructura propia, justo lo que Easel ya tenía antes de probar Web FunctionsVercel Fluid ComputeSegún el comentario de Onavo en HN, mantiene el entorno vivo sin la misma penalización de memoria ociosaLa cifra es una opinión de un usuario de HN, no una medición de Easel; además es una plataforma administrada y cerrada, no compute propioCompute propio de Easel.shHost propio en EE.UU. desde el 2 de noviembre de 2026, con Lambda clásica solo de desbordeExige operar servidores y repartir capacidad entre clientes; no es una opción lista para un equipo que no quiere administrar infraestructuraEl host propio de Easel.sh entró en producción en EE.UU. el 2 de noviembre de 2026.

Qué significa esto para tu stack

Si administrás una API o un backend en Next.js sobre Lambda Web Functions con tráfico esporádico (un SaaS multi-tenant, microservicios internos, paneles que reciben pocas peticiones por hora), conviene abrir AWS Cost Explorer y separar cuánto del costo es memoria facturada contra cuánto es cómputo real. El 88% que midió Easel es la señal de qué buscar antes de comprometerte con esta opción.

Además de Cost Explorer, vale la pena revisar las métricas de CloudWatch por entorno de ejecución (duración por invocación versus tiempo total del entorno) para ver si tu propio tráfico se parece al patrón que describe Easel: peticiones cortas separadas por minutos de silencio. Si la proporción se acerca al 88% que midió la empresa, probablemente estás pagando mucho más por memoria ociosa que por trabajo real.

Un comentario en la discusión de Hacker News ofrece una pista concreta: el usuario torginus escribió que "si cerrás tu proceso de Lambda, el contenedor simplemente se apaga, y podés hacerlo después de devolver la respuesta". Antes de aplicarlo en producción conviene probarlo en un entorno de pruebas: Easel ya intentó algo parecido (apagar entornos a los 10 segundos de inactividad) y AWS registró cada salida voluntaria como un fallo de runtime en vez de un cierre limpio, así que el comportamiento puede no ser tan predecible como suena.

Para equipos con tráfico constante, nada de esto cambia mucho: el mismo entorno reparte el costo ocioso entre muchas peticiones. El problema aparece con tráfico intermitente o en plataformas multi-tenant que hospedan muchas apps chicas, justo el caso de Easel.

Los límites del experimento

Easel aclara que estos son resultados iniciales de una sola región de AWS y de un solo cliente de prueba en Ashburn, Virginia; no hay garantía de que se repliquen en otras regiones o con otro perfil de tráfico. La comparación de arranque en frío se basa en apenas dos pruebas pareadas, una muestra chica para sostener una diferencia de 3,5 veces. Y conviene tener presente que Easel vende compute propio: tiene un incentivo directo para que su infraestructura salga mejor en la comparación, algo que no invalida los números pero sí pide leerlos con ese contexto.

Referencias

Easel.sh: reporte original con las mediciones de memoria ociosa, benchmarks de latencia y arranque en frío.- Hacker News: hilo de discusión sobre la facturación de memoria ociosa en Lambda Web Functions.- Comentario de Onavo en Hacker News: comparación con el comportamiento de Vercel Fluid Compute.- Comentario de torginus en Hacker News: sugerencia de cerrar el proceso tras responder para apagar el contenedor.

Seguimos el tema en @programacion.

ExcalidrawZ 2.5.1 suma archivos reales y iCloud

lu1tr0n — Thu, 12 Nov 2026 19:00:58 +0000

ExcalidrawZ para Mac llegó a la versión 2.5.1 el 24 de octubre de 2026, con sincronización completa por iCloud y un asistente de inteligencia artificial integrado en el lienzo, y suma también iPadOS e iOS como plataformas (nota de la versión). En Hacker News, alguien miró el historial de commits del proyecto y encontró algo que no cuadraba con una app hecha a mano: el ritmo de desarrollo se disparó hace poco, mucho más de lo que explicaría un equipo trabajando solo (comentario de j2kun).

El repositorio suma unas 1.700 estrellas y cerca de 100 forks en GitHub al 2026-11-12, escrito en Swift bajo licencia MIT, con el último push el 2026-10-24 (chocoford/ExcalidrawZ). No reescribe el lienzo de Excalidraw. Lo incorpora tal cual y lo rodea de funciones nativas de Apple, pensadas para quien ya dibuja diagramas en Excalidraw y quiere archivos reales en el Finder en lugar de descargas sueltas del navegador.

Qué agrega ExcalidrawZ sobre el Excalidraw que ya conocés

El propio README lo resume así: "Excalidraw is an excellent drawing tool", y ExcalidrawZ se limita a envolverlo con gestión de archivos, historial y sincronización (chocoford/ExcalidrawZ). En la práctica eso significa organizar dibujos en grupos y carpetas locales, abrir y editar directamente .excalidraw, .excalidraw.png y .excalidraw.svg, sincronizar esos archivos entre Mac, iPad y iPhone vía iCloud, y guardar puntos de control del historial para restaurar una versión anterior de un diagrama.

Asistente de IA en el lienzo: puede leer, crear y revisar dibujos, trabajar con imágenes adjuntas y mostrar una vista previa antes de aplicar cualquier cambio, con control por archivo de qué queda visible para la IA.- Servidor MCP: ExcalidrawZ puede exponerse como servidor MCP para clientes de IA compatibles, con un modo básico equivalente al paquete excalidraw-mcp y un modo optimizado con edición del archivo actual, navegación, historial y exportación.- Herramientas de matemática: fórmulas en LaTeX, gráficos de funciones y conversión de diagramas Mermaid a Excalidraw editable.- Colaboración en vivo usando el modo de colaboración propio de Excalidraw, para dibujar con otras personas en el mismo lienzo.- Archivos bloqueados con autenticación local, checkpoints cifrados y una clave de recuperación como respaldo; los PNG y SVG exportados siguen siendo archivos .excalidraw editables, además de exportar a PDF.

Para instalarla fuera de la App Store, el README solo pide bajar el .dmg más reciente desde Releases y arrastrar la app a Applications (chocoford/ExcalidrawZ).
MIT license y Swift: unas 1.700 estrellas al 2026-11-12.

Para quién cambia el flujo de trabajo

Le sirve a quien ya usa Excalidraw para documentar arquitectura, diagramas de secuencia o notas visuales y hoy junta esos archivos sueltos descargados del navegador. Con ExcalidrawZ esos dibujos pasan a ser documentos reales del sistema, con historial y sincronización entre dispositivos Apple, y el Apple Pencil en iPad suma deshacer y rehacer con los mismos gestos que ya usás en otras apps.

La integración MCP interesa a quien corre agentes de IA localmente (Claude Code, Cursor u otro cliente MCP) y quiere que el agente lea o edite un diagrama sin copiar y pegar JSON a mano. Pero esa misma puerta, un servidor HTTP local que puede escribir en tus archivos, es lo primero que hay que auditar antes de activarla en una máquina con diagramas sensibles.

Qué pasó cuando probamos compilarlo en el laboratorio

Corrimos ExcalidrawZ en nuestro sandbox aislado el 2026-11-12. El clon del repositorio terminó bien:

$ git -c protocol.allow=never -c protocol.https.allow=always -c core.hooksPath=/dev/null clone --depth 1 --single-branch --no-tags -- https://github.com/chocoford/ExcalidrawZ /tmp/lab-runs/lab-8njj7gl3/w/repo
Cloning into '/tmp/lab-runs/lab-8njj7gl3/w/repo'...

El repositorio pesa 104,4 MB y el clon tardó 3,912 segundos con un pico de memoria de 53,3 MB. Ahí se detuvo: el laboratorio reportó "no supported stack detected" y no llegó a compilar ni correr nada. Tiene sentido. ExcalidrawZ es un proyecto Xcode puro, atado a SwiftUI y al toolchain de Apple, y nuestro sandbox corre Linux (os=Linux-6.18.15, python=3.12.16, node=v18.20.4). No hay forma de construir una app para macOS/iOS fuera de una máquina con Xcode.

Esto importa más allá del dato técnico: si tu equipo quiere validar ExcalidrawZ en un pipeline de CI antes de distribuirlo internamente, necesitás un runner macOS con Xcode instalado, no un contenedor Linux genérico como el que usa la mayoría de las integraciones continuas por defecto. El propio repositorio documenta la configuración de firma (Config/Overrides.xcconfig con DEVELOPMENT_TEAM, ICLOUD_CONTAINER y APP_GROUP_IDENTIFIER), pero asume que ya tenés ese entorno listo (chocoford/ExcalidrawZ).

ExcalidrawZ para Mac frente a Excalidraw, tldraw y Drawnix

ProyectoEstrellas (2026-11-12)Qué esDiferencia claveexcalidraw/excalidrawunas 135.600El lienzo web original, también como paquete npmCorre en cualquier navegador sin instalar nada; es lo que ExcalidrawZ envuelve por dentrotldraw/tldrawunas 51.400SDK de React para lienzo infinitoPensado para integrarlo en tu propio producto, no para usarlo como app de escritorioplait-board/drawnixunas 15.000Whiteboard open source todo en uno (mapas mentales, diagramas de flujo, dibujo libre)Es SaaS web, no una app nativa de Applechocoford/ExcalidrawZunas 1.700App nativa SwiftUI para macOS, iPadOS e iOSEl único de los cuatro con archivos reales, iCloud y Apple Pencil
Hay una cuarta opción que ni siquiera requiere instalar una app: Excalidraw tiene su propio paquete de npm, y un comentario en Hacker News recuerda que montar un proyecto local con una página HTML vacía y Excalidraw adentro es sencillo, sirve detrás de firewalls corporativos y funciona completamente offline (comentario de BariumBlue). Si lo único que te interesa es el lienzo sin la capa nativa de Apple, esa ruta evita instalar un binario de terceros.
Excalidraw original supera las 135.000 estrellas en GitHub.

Qué significa esto para tu equipo

Si mantenés documentación técnica de arquitectura en Excalidraw dentro de un equipo backend que usa Mac, antes de instalar ExcalidrawZ la decisión concreta es no activar el modo MCP optimizado (el que da acceso de edición al archivo actual y a la navegación) hasta revisar quién corre ese servidor HTTP local y qué agente de IA se conecta a él. Es la parte de la app que más se parece a abrir una puerta nueva a tus archivos.

Segundo, antes de guardar diagramas de arquitectura con flechas (el tipo de diagrama más común en documentación técnica), leé el issue #119, todavía abierto: reporta un error de "the data couldn't be read" justo en líneas sin punta de flecha. Probalo primero con un diagrama de prueba, no con el que ya tiene seis meses de historial.

Tercero, si tu política de seguridad exige poder auditar el código antes de confiarle el Llavero (Keychain) para la función de archivos bloqueados, mirá primero el historial de commits y el gráfico de frecuencia de código que señaló el comentario de j2kun en Hacker News antes de instalar el .dmg firmado (comentario de j2kun). No es una acusación confirmada de nada, es una observación de la comunidad que vale la pena mirar con tus propios ojos antes de decidir.

Cuándo no conviene instalarlo

ExcalidrawZ solo corre en macOS, iPadOS e iOS: no hay versión para Windows ni Linux, así que un equipo mixto necesita mantener el acceso web original para quienes no usan Apple. La versión fuera de la App Store llega como .dmg sin pasar por la revisión de Apple, lo que exige confiar en el firmante del binario y no en una tienda que lo auditó.

Compilarlo desde el código fuente no es trivial: necesita un equipo de desarrollador de Apple propio, un App Group y un contenedor de iCloud configurados a mano en Config/Overrides.xcconfig (chocoford/ExcalidrawZ). Y como vimos en el laboratorio, ninguna herramienta de CI genérica para Linux puede validarlo: cualquier pipeline de verificación automática necesita un runner macOS dedicado.

Por último, el issue #119 sigue abierto y el propio ritmo reciente de commits generó dudas en la comunidad de Hacker News sobre cuánto del código se escribe a mano versus con asistencia de IA (comentario de j2kun). Ninguna de las dos cosas es un error confirmado, pero ambas son motivo para no apurar la adopción en un equipo grande sin probarlo primero con diagramas que no importen.

Referencias

chocoford/ExcalidrawZ: repositorio, README, estrellas y licencia.- Release v2.5.1: nota de la versión del 2026-10-24.- Issue #119: error abierto con líneas sin punta de flecha.- Hilo de Hacker News: discusión de la comunidad sobre ExcalidrawZ.- excalidraw/excalidraw: el lienzo original que usa ExcalidrawZ.- tldraw/tldraw: alternativa como SDK de React.- plait-board/drawnix: alternativa como whiteboard SaaS open source.

Seguimos el tema en @programacion.

Timsort: cómo ordena Python desde 2002

lu1tr0n — Thu, 12 Nov 2026 15:34:14 +0000

Guido van Rossum anunció el 11 de noviembre de 2026 que Tim Peters, autor del algoritmo Timsort y del Zen de Python (PEP 20), murió el 15 de julio de ese año. Fue Peters quien, mucho antes de escribir cualquiera de los dos, convenció a Van Rossum de que int y float debían mezclarse en una misma operación aritmética, según el anuncio original.

El nombre que millones de programas ejecutan todos los días sin saberlo es el de esa creación: Timsort. Peters lo diseñó en 2002 para ordenar las listas de Python y, según el mismo anuncio de Van Rossum, Java y Android lo adoptaron después para sus propias colecciones.

El algoritmo Timsort: qué es y de dónde salió

Timsort es un algoritmo de ordenamiento híbrido. Combina insertion sort para tramos pequeños con una versión adaptativa de merge sort para el resto de la lista. Desde 2002 es el que corre detrás de list.sort() y sorted() en Python, y también el que usa Java para ordenar arrays de objetos, según el relato de Van Rossum sobre su creador.

La idea de combinar dos técnicas de ordenamiento no es nueva, pero la forma en que Timsort decide cuándo usar cada una sí lo es. En lugar de asumir que los datos llegan en cualquier orden, el algoritmo primero busca runs: tramos de la lista que ya vienen ordenados, ascendente o descendente, por pura casualidad. Los datos reales rara vez son aleatorios. Suelen tener fechas, nombres o IDs parcialmente ordenados, y Timsort explota exactamente eso.
Timsort ordena las listas de Python desde 2002, según Guido van Rossum.

Cómo decide Timsort cuándo mezclar las dos técnicas

El algoritmo recorre la lista de izquierda a derecha y agrupa elementos consecutivos en runs. Si un run es más corto que un umbral mínimo (normalmente entre 32 y 64 elementos, según el tamaño total de la lista), Timsort lo extiende con insertion sort hasta llegar a ese umbral. El insertion sort es lento en listas grandes, pero muy rápido en tramos cortos, y ahí es donde gana.

Cada run terminado se apila en una pila de runs pendientes. Timsort mantiene un invariante sobre los tamaños relativos de esa pila: cada run debe ser más grande que la suma de los dos siguientes. Cuando eso se rompe, mezcla los runs vecinos con una versión de merge sort que usa menos memoria que la clásica.

Si durante varias mezclas seguidas uno de los dos runs "gana" siempre, el algoritmo activa el modo galopante. En vez de comparar elemento por elemento, busca con saltos binarios dónde insertar de una vez un bloque completo del run perdedor. Ese modo galopante es la parte menos intuitiva del diseño y la que más distingue a Timsort de un merge sort de manual.

La nota técnica que Tim Peters escribió para el código fuente de CPython describe el razonamiento completo, incluida la fórmula exacta para calcular el tamaño mínimo de cada run.

flowchart TD
A["Lista de entrada"] --> B["Detectar run ascendente o descendente"]
B --> C{"Run mas corto que el minimo"}
C -- "si" --> D["Extender con insertion sort"]
C -- "no" --> E["Apilar run"]
D --> E
E --> F{"Se rompe el invariante de tamanios"}
F -- "si" --> G["Mezclar runs vecinos con merge sort adaptativo"]
F -- "no" --> H["Seguir leyendo la lista"]
G --> H
H --> I["Lista completamente ordenada"]

Por qué le importa a quien programa en Python, Java o Android

Para quien escribe backend en Python, Timsort es la razón de que ordenar listas de diccionarios, tuplas o registros de base de datos sea rápido incluso cuando esos datos ya vienen casi ordenados, por ejemplo por fecha de creación. No hay que configurar nada: sorted(lista, key=...) ya corre sobre Timsort.

Para quien trabaja en Java o Android, el mismo algoritmo ordena cualquier array de objetos. Si tu equipo usa Collections.sort() o Arrays.sort() sobre un array de objetos, está corriendo Timsort sin saberlo, igual que en Python.

Y para quien diseña estructuras de datos propias, Timsort es un caso de estudio de un principio más general. Optimiza para el caso común de los datos reales en lugar del peor caso teórico. Eso es justo lo que separa a un algoritmo de manual de uno que sobrevive 24 años en producción.

Timsort frente a quicksort, merge sort y el dual-pivot de Java

Ningún algoritmo de ordenamiento gana en todo. La tabla compara Timsort con las tres alternativas más conocidas del mismo problema.
AlgoritmoEstablePeor casoVentaja frente a datos realesDónde se usaTimsortSíO(n log n)Explota runs ya ordenados; casi gratis en datos parcialmente ordenadosPython list.sort(), Java Arrays.sort() para objetos, AndroidQuicksort clásicoNoO(n²)Rápido en promedio, pero no aprovecha el orden existenteVariantes de qsort en C y en varias stdlibMerge sort clásicoSíO(n log n)Garantiza el peor caso, pero mezcla aunque los datos ya estén ordenadosBases para estructuras que exigen estabilidad sin adaptarse al inputQuicksort dual-pivotNoO(n log n) en promedioMuy rápido en arrays de primitivos, sin costo de estabilidadJava Arrays.sort() para tipos primitivos como int y double
La fila que más sorprende suele ser la última, porque Java no usa Timsort para todo. Para arrays de int, double o char usa un quicksort dual-pivot, porque esos arrays no necesitan estabilidad (no hay objetos iguales con identidad distinta que preservar) y el quicksort dual-pivot es más rápido ahí. Timsort se reserva para arrays de objetos, donde la estabilidad sí importa.

Cuándo Timsort no es la mejor opción

Timsort tiene un costo de memoria adicional, porque necesita un buffer temporal para las mezclas. En sistemas con memoria muy ajustada, como microcontroladores, ese costo pesa más que en un servidor backend típico.

Tampoco es la opción más rápida posible para arrays de números primitivos sueltos sin ningún orden previo. Ahí un quicksort bien implementado, sin la contabilidad de runs y sin garantizar estabilidad, puede ganarle. Por eso Java separa los dos casos en lugar de usar Timsort para todo.

Y su comportamiento adaptativo, que es su mayor fortaleza, también complica los benchmarks. El mismo algoritmo puede tardar tiempos muy distintos según qué tan ordenados vengan los datos de entrada, así que comparar Timsort contra otro algoritmo con un solo caso de prueba casi nunca cuenta la historia completa.
El Zen de Python (PEP 20) también lleva la firma de Tim Peters.

El Zen de Python: la otra gran huella de Tim Peters

Mientras diseñaba Timsort, Peters ya era conocido en la lista de correo de Python como "Timbot", según el anuncio de Van Rossum. Respondía preguntas de usuarios con un humor tan constante que se volvió su firma, marcada siempre con <wink>. Ese tono, mitad técnico y mitad informal, es el mismo que atraviesa el Zen de Python, la lista de aforismos que todavía aparece al escribir import this en cualquier intérprete de Python.

El Zen no es un manual de sintaxis: es una guía de criterio. Frases como "explícito es mejor que implícito" o "simple es mejor que complejo" no dictan cómo escribir código, sino cómo discutir una decisión de diseño cuando dos soluciones son técnicamente válidas. Un comentario en Hacker News recuerda, por ejemplo, que el parámetro self explícito en los métodos de Python, a diferencia de Java o C++, se discutió con ese mismo criterio, y que Peters tuvo un rol activo en esa discusión.

Van Rossum resumió la influencia de Peters en una frase de su anuncio: "It's hard to overestimate Tim's influence on Python." Agregó, además, que antes de escribir el Zen, Tim ya lo había convencido de mezclar int y float en una misma operación aritmética, porque es lo que cualquier usuario esperaría. Esa clase de decisiones, pequeñas pero con efecto en millones de programas, es la que el Zen trató de volver repetible para el resto del equipo.

📌 Nota: El anuncio completo, con más anécdotas de otros desarrolladores del núcleo de Python, está en el hilo original de discuss.python.org.

Ninguno de los dos legados depende del otro para seguir vigente. Timsort sigue ordenando listas aunque nadie piense en su autor al escribir sorted(), y el Zen sigue citándose en code reviews aunque quien lo cite no sepa quién lo escribió. Esa es la prueba más clara de qué tan bien diseñados estaban los dos. Sobrevivieron a dejar de necesitar a su autor.

Referencias

In Memoriam: Tim Peters 1952-2026: anuncio de Guido van Rossum con la fecha de la muerte de Peters y el origen de Timsort.- listsort.txt en el repositorio de CPython: la nota técnica original de Tim Peters sobre el diseño de Timsort.- PEP 20: The Zen of Python: el texto completo de los aforismos escritos por Tim Peters.- Hilo de Hacker News sobre la muerte de Tim Peters: reacciones y anécdotas de la comunidad.

Seguimos el tema en @programacion.

Johns Hopkins lleva su mapeo celular del cáncer a Anthropic

lu1tr0n — Tue, 10 Nov 2026 16:27:16 +0000

Johns Hopkins University confirmó el 2 de noviembre de 2026 que entregó su tecnología de mapeo celular del cáncer a un proyecto de inteligencia artificial de Anthropic. La universidad no detalló el nombre comercial de la plataforma ni el monto del acuerdo, pero sí el objetivo: que un modelo de IA ayude a interpretar datos biológicos de una resolución que hasta hace poco solo analizaban equipos especializados de biología computacional.

El anuncio llega en medio de una ola de laboratorios de inteligencia artificial que buscan datos científicos de alta calidad para entrenar y poner a prueba sus modelos, un movimiento que ya había impulsado iniciativas similares en genómica, química y ciencia de materiales.

TL;DR

Johns Hopkins cedió su plataforma de mapeo celular del cáncer a un proyecto de inteligencia artificial de Anthropic, confirmado el 2 de noviembre de 2026.- La tecnología registra la posición exacta de cada célula tumoral dentro del tejido, no solo su tipo genético.- Anthropic ya opera productos dirigidos a ciencias de la vida, dentro de su apuesta más amplia por la IA aplicada a investigación.- El objetivo declarado es que un modelo de IA detecte patrones celulares que los métodos tradicionales no capturan con la misma resolución.- Ninguna de las dos instituciones reveló montos de financiamiento, cronograma ni si los datos entrenarán modelos o solo los analizarán.

Qué es la plataforma de mapeo celular del cáncer

La plataforma de mapeo celular del cáncer es un conjunto de técnicas de biología espacial que registra qué genes se activan en cada célula de un tumor y en qué posición exacta del tejido se encuentra, a diferencia de los métodos que analizan células sueltas sin su contexto físico.

Johns Hopkins no reveló el nombre comercial de su versión de esta tecnología de mapeo espacial en el anuncio del 2 de noviembre, pero sí confirmó que fue la elegida para integrarse a un proyecto de inteligencia artificial de Anthropic centrado en investigación oncológica.

Ese tipo de acuerdo es poco común. Los datos de este tipo de cartografía de células tumorales suelen quedarse dentro de consorcios académicos, no cruzar hacia compañías que entrenan modelos de lenguaje a gran escala.

Qué pasó

El comunicado de Johns Hopkins describe la cesión como parte de un proyecto conjunto de inteligencia artificial para la ciencia, sin precisar si Anthropic recibe los datos crudos, los modelos ya entrenados sobre esos datos o ambos. La universidad tampoco especificó qué línea de productos de Anthropic absorbe el proyecto.

Lo que sí quedó claro es el rol de cada parte: Johns Hopkins aporta la tecnología y las muestras de tejido tumoral, mientras Anthropic pone el modelo de IA que debe encontrar patrones en esos datos. Ninguna de las dos instituciones mencionó un resultado publicado todavía, ni una fecha para compartirlo.

La ausencia de cifras concretas sobre financiamiento, cantidad de muestras y plazo del proyecto deja varias preguntas abiertas que solo se resolverán si alguna de las dos partes amplía el comunicado original.

Contexto e historia

Johns Hopkins tiene una trayectoria larga en genómica del cáncer. Su Centro Kimmel fue uno de los lugares donde se sentaron las bases de la secuenciación de tumores hace más de dos décadas, y desde entonces la universidad mantiene varios laboratorios dedicados a mapear mutaciones y expresión génica en tejido tumoral.

La tecnología de mapeo espacial en sí es más joven. Las primeras técnicas de secuenciación de célula única datan de 2009, pero recién a partir de 2016 llegaron los primeros métodos que además conservaban la ubicación de cada célula dentro del corte de tejido. Antes de eso, analizar un tumor significaba triturarlo y promediar la señal genética de miles de células mezcladas, perdiendo cualquier información sobre su disposición real.

Anthropic, por su lado, viene ampliando su presencia fuera del software puro. La compañía ya ofrece productos orientados a ciencias de la vida y participa en acuerdos con laboratorios y centros de investigación, en lo que describe como una apuesta por acelerar el descubrimiento científico con modelos de lenguaje. El acuerdo con Johns Hopkins se suma a esa lista, aunque es uno de los primeros enfocados específicamente en datos de mapeo celular oncológico.

Ese movimiento no es exclusivo de Johns Hopkins y Anthropic. Instituciones académicas y agencias públicas en varios países vienen explorando acuerdos similares para que modelos de IA analicen datos biológicos de alta resolución, desde genómica hasta imágenes médicas, aunque la mayoría de esos acuerdos todavía están en etapas tempranas y pocos han publicado resultados verificables.

Detalles técnicos: cómo funciona el mapeo celular y qué le aporta a la IA

El mecanismo detrás de esta familia de técnicas combina microscopía y secuenciación. Un corte fino de tejido tumoral se fija sobre un portaobjetos especial y se expone a sondas que se unen a transcritos de ARN específicos o a anticuerpos marcados con fluorescencia. Un escáner captura miles de imágenes del mismo corte, y un algoritmo de segmentación asigna cada señal detectada a la célula vecina más probable dentro del tejido.

El resultado final no es una lista de genes, sino un mapa: cada célula queda etiquetada con su perfil molecular y sus coordenadas exactas, y el software puede reconstruir qué tipos de célula están en contacto directo unas con otras. Esa información de vecindad es la que interesa a un modelo de IA, porque el comportamiento de un tumor depende tanto de las mutaciones que acumula como de cómo esas células interactúan con el sistema inmune y el tejido sano que las rodea.
Los algoritmos de segmentación asignan cada transcrito detectado a la célula vecina del tejido.
Procesar este tipo de datos es costoso. Una sola muestra puede generar varios gigabytes de imágenes de alta resolución, y reconstruir el mapa celular completo exige hardware de cómputo especializado antes de que cualquier modelo de lenguaje pueda analizarlo. Es justamente ese costo de preprocesamiento el que hace valiosa una plataforma ya madura como la de Johns Hopkins: construirla desde cero le tomaría a cualquier laboratorio de IA años de trabajo exclusivamente biológico.

flowchart TD
    A["Biopsia del tumor"] --> B["Plataforma de mapeo celular"]
    B --> C["Mapa de celulas con coordenadas"]
    C --> D["Modelo de IA de Anthropic"]
    D --> E["Patrones candidatos"]
    E --> F["Validacion en laboratorio"]

El diagrama resume el camino que recorre cada muestra: primero pasa por la plataforma de biología espacial del tumor, después el modelo de IA busca correlaciones en ese mapa, y cualquier hallazgo todavía necesita confirmarse con experimentos tradicionales antes de considerarse válido.

Qué método de mapeo celular usar según el objetivo

MétodoQué mideVentajaLimitaciónSecuenciación de célula única (scRNA-seq)Expresión génica por célula, sin ubicaciónAlta resolución genética por célulaPierde la posición espacial dentro del tejidoTranscriptómica espacialExpresión génica con coordenadas en el tejidoConserva el contexto anatómico del tumorMenor profundidad de lectura por punto medidoImagen multiplexada (tipo CODEX)Proteínas específicas con ubicación exactaResolución de proteína a nivel de célula individualLimitada a un panel fijo de marcadoresModelo de IA multimodalPatrones combinados entre las tres fuentes anterioresEncuentra correlaciones que un ojo humano no detectaNecesita validación experimental posterior

Impacto y análisis

Para Anthropic, sumar datos de mapeo de células cancerosas encaja con una estrategia más amplia: convertir modelos de lenguaje en herramientas útiles para la investigación biomédica, un terreno donde otros laboratorios de IA y centros académicos también compiten por acceso a datos biológicos de calidad. Tener acceso a una plataforma ya validada en un centro médico como Johns Hopkins le ahorra a la compañía el paso más caro, que es construir o comprar su propia infraestructura de mapeo celular.

Para Johns Hopkins, el acuerdo abre una vía de colaboración distinta a la financiación tradicional de becas y subsidios públicos. Pero también plantea preguntas que el comunicado no responde: qué controles existen sobre el uso posterior de los datos de pacientes, y si los hallazgos del modelo de IA se publicarán en revistas revisadas por pares o quedarán como propiedad conjunta de ambas instituciones.

💭 Clave: un modelo de IA entrenado con datos de un solo hospital puede confundir rasgos propios de esa institución, como el protocolo de tinción o el escáner usado, con señales biológicas reales del tumor, un problema conocido en biología computacional como efecto de lote.

Ese riesgo no es exclusivo de este proyecto, pero es la razón por la que los hallazgos de un modelo de IA sobre este atlas celular oncológico necesitan replicarse en tejido de otros centros antes de considerarse confiables. Encontrar un patrón estadístico en los datos no demuestra que ese patrón tenga una causa biológica real: ese paso todavía requiere trabajo de laboratorio tradicional, algo que ningún modelo de lenguaje reemplaza por ahora.

Qué sigue

Johns Hopkins y Anthropic no fijaron una fecha para mostrar resultados concretos del proyecto. Tampoco aclararon si el acuerdo se extenderá a otras áreas médicas más allá de oncología, ni si otras universidades podrán sumar sus propios datos de mapeo celular a futuro.

Lo más probable, a juzgar por movimientos similares de otros laboratorios de IA en biología, es que el primer resultado visible sea un paper o un informe técnico conjunto, antes que un producto comercial. Hasta que eso ocurra, lo único confirmado es el anuncio original: una universidad cedió su tecnología de cartografía de células tumorales, y una empresa de IA se comprometió a analizarla.

📖 Resumen en Telegram: Ver resumen

Si querés revisar la fuente original antes que cualquier resumen, el comunicado completo de Johns Hopkins está disponible en el sitio de la universidad desde hoy mismo.

Preguntas frecuentes

¿Qué es exactamente el mapeo celular del cáncer que cede Johns Hopkins?

Es una tecnología de biología espacial que registra qué genes o proteínas expresa cada célula de un tumor y en qué posición exacta del tejido se encuentra, en lugar de analizar una mezcla de células sin ubicación.

¿Anthropic va a entrenar a Claude con estos datos?

El comunicado de Johns Hopkins no lo especifica. No queda claro si los datos se usan para entrenar un modelo, para evaluarlo, o solo para que un modelo ya entrenado los analice puntualmente.

¿En qué se diferencia esta tecnología de la secuenciación de célula única?

La secuenciación de célula única mide la expresión génica de cada célula por separado, pero pierde su posición original en el tejido. El mapeo espacial conserva esa ubicación, lo que permite estudiar cómo interactúan las células vecinas dentro del tumor.

¿Los pacientes autorizan el uso de sus datos para este tipo de proyectos?

Los estudios con tejido humano exigen pasar por comités de ética institucionales y anonimizar las muestras, aunque Johns Hopkins no detalló el protocolo específico que aplica a este proyecto con Anthropic.

¿Cuándo se conocerán resultados del mapeo de células cancerosas con Anthropic?

Ninguna de las dos instituciones fijó una fecha. El comunicado original solo confirma el inicio de la colaboración, sin cronograma de resultados.

Referencias

Johns Hopkins Hub: anuncio oficial de la cesión de la tecnología de mapeo celular a un proyecto de Anthropic.- Nature: panorama sobre el auge de la inteligencia artificial aplicada a la investigación científica.- Wikipedia: explicación general de las técnicas de transcriptómica espacial y su historia.- Anthropic: sitio oficial de la compañía y sus líneas de producto orientadas a investigación científica.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

DeepMind: AlphaProof Code verificó código de Signal en 4 semanas

lu1tr0n — Tue, 10 Nov 2026 14:27:20 +0000

Un sistema de inteligencia artificial acaba de demostrar con matemáticas, no con intuición, que el cifrado de Signal hace exactamente lo que promete. Google DeepMind anunció que su framework AlphaProof Code verificó formalmente las propiedades de seguridad del código real que corre detrás del protocolo de Signal, la base criptográfica que usan miles de millones de conversaciones en Signal y Google Messages. El procedimiento, que históricamente consumía años de trabajo experto, tardó apenas cuatro semanas.

TL;DR

AlphaProof Code de Google DeepMind verificó formalmente el código real del protocolo de Signal en cuatro semanas.- Los agentes con Gemini Carbon generaron más de seis millones de líneas de prueba en el lenguaje Lean.- Solo el 1% del código necesitó revisión humana directa; Lean comprobó automáticamente el resto.- El sistema detectó como inseguras dos versiones con bugs reales que Signal ya había corregido.- Signal confirma que la verificación eleva la confianza en las garantías de privacidad de su protocolo.

Qué es AlphaProof Code

AlphaProof Code es un framework de verificación formal creado por Google DeepMind que combina agentes basados en modelos de lenguaje con el demostrador de teoremas Lean para probar matemáticamente que un programa cumple sus especificaciones de seguridad hasta el nivel del código que efectivamente se ejecuta en los dispositivos, no solo del diseño en papel.

Su primer despliegue público fue precisamente el protocolo de Signal, considerado durante años un desafío de referencia en software de seguridad. El resultado, según DeepMind, es la primera vez que la implementación real de un protocolo criptográfico ampliamente usado queda verificada formalmente, con o sin inteligencia artificial de por medio.

Qué pasó

Investigadores de Google DeepMind guiaron a agentes de inteligencia artificial para probar, con el framework de verificación formal, las propiedades de seguridad clave del código que sostiene al protocolo de Signal, usado tanto por la app Signal como por Google Messages.

El trabajo arrancó con una traducción manual asistida. Los investigadores usaron una combinación de modelos para convertir los objetivos de seguridad en especificaciones matemáticas formales, y expertos humanos revisaron cada una de ellas antes de avanzar. Desde ahí, agentes impulsados por el modelo Gemini Carbon se encargaron de generar las pruebas, produciendo más de seis millones de líneas de código en Lean, el lenguaje que permite demostrar matemáticamente que un programa es correcto.

Después de generar la prueba, los propios agentes la auditaron y señalaron qué partes necesitaban una segunda mirada humana: apenas el 1% de la base de código. El resto quedó validado automáticamente por Lean, que revisa cada paso lógico sin margen de error. Según el anuncio de DeepMind, todo el proceso tomó cuatro semanas, frente a los años que suelen necesitar equipos expertos para una verificación de esta profundidad.

Para confirmar que el sistema distingue código correcto de código con fallas, el equipo reintrodujo deliberadamente dos bugs reales, ya corregidos previamente, en una versión aislada del código de Signal. En ambos casos, AlphaProof Code generó una prueba verificada por máquina de que la versión con el bug era insegura.

"El uso de agentes de inteligencia artificial para traducir código real en vigencia a teoremas válidos de Lean es un gran avance. A medida que crecen las amenazas impulsadas por inteligencia artificial, verificar rigurosamente la implementación del protocolo de Signal nos da aún más confianza en las garantías de privacidad de nuestro código", afirmó Ehren Kret, director de tecnología de Signal, según el blog de DeepMind.
Los agentes produjeron más de seis millones de líneas de prueba en Lean en cuatro semanas.

Contexto: décadas de verificación incompleta

La seguridad criptográfica lleva décadas analizándose casi exclusivamente en el papel. Investigadores demuestran que un diseño matemático es correcto, pero rara vez llegan a comprobar que la implementación real, el código que compila y corre en un teléfono, respeta ese diseño al pie de la letra. Ahí suelen esconderse las vulnerabilidades, en la distancia entre la especificación y el binario.

El protocolo de Signal es, desde hace más de una década, la referencia de cifrado extremo a extremo para mensajería. Lo usan Signal, Google Messages y, en variantes distintas, otras apps de chat cifrado. Por eso cargaba fama de desafío de referencia para la verificación formal, porque nadie había logrado probar matemáticamente que su código, y no solo su diseño, cumple garantías como mantener los mensajes protegidos incluso después de que un dispositivo quede comprometido temporalmente.

Detalles técnicos: cómo funciona el framework de verificación formal

El sistema divide el trabajo de verificación como lo haría un equipo de investigación humano. Primero, humanos y modelos colaboran para fijar las especificaciones, es decir, qué debe ser cierto del código. Después, un grupo de agentes de inteligencia artificial, en este caso impulsados por Gemini Carbon, se dedica exclusivamente a producir la demostración matemática en Lean. Cada paso de esa demostración pasa por el verificador de Lean, que rechaza cualquier paso lógico inválido, así que no hay forma de que una prueba pase si contiene un error, porque el propio lenguaje lo impide.

sequenceDiagram
participant H as Humanos
participant M as Modelos
participant A as Agentes Gemini Carbon
participant L as Lean
H->>M: definen objetivos de seguridad
M->>H: propone especificación formal
H->>A: aprueba especificación revisada
A->>L: genera prueba de 6M+ líneas
L-->>A: verifica cada paso lógico
A->>H: señala el 1% para revisión humana

Este trabajo se distingue de las verificaciones formales previas por su profundidad, porque bajó hasta el código compilado y no se quedó en el diseño en papel. Esa decisión multiplica la complejidad. Las vulnerabilidades reales casi siempre aparecen en la brecha entre el diseño prometido y lo que el compilador finalmente produce. Según el anuncio de DeepMind, el enfoque previo de verificación formal se había limitado necesariamente a alcances menores, mientras que este nuevo método permite una expansión significativa, según explicó Ehren Kret, director de tecnología de Signal, en declaraciones publicadas por DeepMind.

El costo de este enfoque no es solo de cómputo: es de revisión experta dirigida. En lugar de que un equipo de criptógrafos lea línea por línea los seis millones de líneas de prueba, Lean valida automáticamente la inmensa mayoría y los expertos concentran su tiempo exclusivamente en el 1% que los propios agentes marcaron como dudoso. Es la misma lógica de un linter, pero aplicada a demostraciones matemáticas en vez de a sintaxis de código.
Solo el 1% del código necesitó revisión humana directa en todo el proceso.

Impacto y análisis: qué cambia para la seguridad de software

DeepMind plantea este trabajo como una prueba de concepto más amplia que Signal. Si un marco de verificación agéntica puede probar matemáticamente la seguridad de un protocolo criptográfico real, la misma técnica podría extenderse a sistemas igual de críticos, como firmware de dispositivos médicos o software que controla la red eléctrica, donde un error de implementación tiene consecuencias físicas y no solo digitales.

La compañía vincula además este trabajo con sus agentes de defensa automatizada, como CodeMender, bajo la idea de que la verificación formal y la detección automática de vulnerabilidades pueden combinarse para responder a la velocidad de las amenazas cibernéticas impulsadas por inteligencia artificial. DeepMind anunció que va a liberar como código abierto los artefactos de verificación generados en este trabajo, aunque todavía no detalló bajo qué licencia ni cuándo estarán disponibles por completo.

El propio anuncio reconoce un límite importante. Escalar esta técnica a otros sistemas requiere investigación continua, y no es un botón que cualquier equipo de ingeniería pueda apretar hoy sobre su propia base de código. El proceso necesitó cuatro semanas de trabajo coordinado entre especialistas en Lean, en criptografía y en los propios modelos, no una ejecución automática de punta a punta sin supervisión.

Qué sigue

El próximo paso declarado por DeepMind es abrir los artefactos de esta verificación a la comunidad, para que otros equipos de criptografía puedan auditarlo o reutilizar el enfoque en sus propios protocolos. Signal ya trabaja con DeepMind en afinar la metodología, según confirmó Kret, de cara a nuevas amenazas que surgen de agentes de inteligencia artificial capaces de automatizar ataques a gran escala.

Habrá que ver si otros protocolos ampliamente usados, como TLS 1.3 o los esquemas de cifrado post-cuántico que NIST estandarizó en FIPS 203, pasan por un proceso similar. Mientras tanto, la referencia inmediata de comparación es que este trabajo tomó cuatro semanas donde antes se hablaba de años, un cambio de escala que, si se repite en otros proyectos, movería la verificación formal de ser un lujo académico a una práctica de ingeniería rutinaria.

📖 Resumen en Telegram: Ver resumen

Probalo vos: abrí el repositorio oficial de Lean y mirá cómo se escribe una demostración real antes de asumir que la verificación formal es solo teoría académica.

Preguntas frecuentes

¿Qué es AlphaProof Code y quién lo desarrolló?

Es un framework agéntico de verificación formal desarrollado por Google DeepMind. Combina modelos de lenguaje con el demostrador de teoremas Lean para probar matemáticamente que el código real de un programa cumple sus especificaciones de seguridad.

¿Por qué la herramienta de DeepMind eligió el protocolo de Signal como primer caso?

Porque cargaba fama de desafío de referencia en seguridad. Protege miles de millones de conversaciones en Signal y Google Messages, y nunca se había verificado formalmente su implementación real, solo su diseño en papel.

¿Cuánto tardó el sistema de pruebas en Lean y cuánta prueba generó?

DeepMind reporta que la verificación tomó cuatro semanas y que los agentes produjeron más de seis millones de líneas de prueba en Lean, de las cuales solo el 1% del código necesitó revisión humana.

¿Cómo se comprobó que la verificación agéntica de código realmente detecta fallas?

El equipo reintrodujo dos bugs reales, ya corregidos previamente en Signal, dentro de una versión aislada del código. En ambos casos, el framework generó una prueba verificada por Lean de que esa versión era insegura.

¿El framework de verificación formal hace que el protocolo de Signal sea infalible?

No. La prueba cubre las propiedades de seguridad específicas que los expertos formalizaron como especificación, como la protección de los mensajes antes y después de un compromiso temporal del dispositivo. Un error en la especificación original, o un problema fuera de ese alcance, no quedaría detectado por este método.

¿DeepMind va a liberar el código del sistema de pruebas en Lean?

Sí, la compañía anunció que abrirá los artefactos de verificación para uso de la comunidad, aunque todavía no precisó licencia ni fecha de disponibilidad completa.

Referencias

Google DeepMind: anuncio oficial de AlphaProof Code y su verificación formal del protocolo de Signal.- Signal: sitio oficial de la aplicación de mensajería cifrada cuyo protocolo fue verificado.- Lean Prover: documentación oficial del lenguaje y demostrador de teoremas usado para las pruebas.- Wikipedia: contexto histórico y técnico del protocolo de Signal.

Amazon reemplaza a Sonnet 4.6 por un modelo de decisión

lu1tr0n — Tue, 10 Nov 2026 08:32:04 +0000

Para un millón de tickets etiquetados, Amazon pasó de pagar unos $22.200 con Claude Sonnet 4.6 a pagar cerca de $500 con un modelo de decisión propio, según relata el equipo de Strands Agents. El mismo trabajo, el mismo volumen de tickets, 44 veces menos costo y una latencia que bajó de más de 4 segundos a menos de 1. Dos ingenieros de Amazon, identificados como Carr y Mehul, hicieron ese cambio sobre el sistema interno de tickets de la compañía y lo documentaron con cifras exactas.

Este artículo explica qué hace distinto a un modelo de decisión frente a un LLM general como Sonnet, y en qué casos conviene reemplazar uno por el otro.

TL;DR

Un modelo de decisión conviene con catálogo fijo y volumen alto: cuesta hasta 44 veces menos que un LLM grande.- Amazon cambió Sonnet 4.6 por Strands Decider y bajó el costo por ticket de $0,0222 a cerca de $0,0005.- El tiempo promedio por llamada cayó de 4.215 ms con Sonnet a 897 ms con el modelo especializado: una caída del 78%.- Reemplazar un LLM grande solo conviene si el catálogo de opciones es cerrado y estable, no si cambia cada semana.- Enviar las claves JSON sin orden fijo mueve las probabilidades hasta 0,19 puntos entre corridas iguales.

¿Qué es un modelo de decisión?

Un modelo de decisión es un modelo de machine learning que, dado un estado y una pregunta con un conjunto cerrado de opciones, devuelve una probabilidad por cada opción más un puntaje de confianza. No genera texto libre: elige entre alternativas predefinidas, como un clasificador multiclase optimizado para velocidad y costo.

Un LLM general como Sonnet puede responder casi cualquier pregunta: explicar un concepto, escribir código, resumir un documento largo. Para lograrlo necesita generar texto token por token y razonar sobre un prompt extenso en cada llamada. Esa flexibilidad cuesta tiempo de cómputo y dinero en cada petición.

Un decision model renuncia a esa flexibilidad a cambio de velocidad. Amazon probó primero Strands Decider 2B y después pasó a una versión E4B basada en Gemma 4, que dio mejores resultados sobre su set de pruebas de tickets. Strands Decider no genera una respuesta en lenguaje natural, sino que puntúa cada opción del catálogo de 20 tipos de categoría que usa Amazon.
Strands Decider E4B corre sobre instancias ml.g5.xlarge, cada una con una GPU A10G de 24 GB.

Por qué importa

Muchas empresas usan un LLM grande para tareas que en el fondo son clasificación: etiquetar tickets, enrutar un mensaje de soporte, decidir si un comentario es spam. Es la opción más simple de implementar, porque el mismo modelo que ya usás para generar texto también puede devolver una etiqueta en formato JSON. El problema aparece cuando el volumen crece.

En el caso de Amazon, cada ticket con Sonnet 4.6 consumía 6.554 tokens de entrada y 170 de salida, un total de 6.724 tokens por ticket, según el reporte de Strands Agents. Con Strands Decider E4B esos números bajaron a 2.009 tokens de entrada y apenas 1 de salida, 2.010 en total, una reducción del 70% en tokens procesados por ticket.

Esa caída de tokens se traduce directo en costo. A precios públicos de Bedrock para Sonnet ($3,00 por millón de tokens de entrada y $15,00 por millón de salida) y de SageMaker para el endpoint de Strands Decider ($1,408 por hora de instancia ml.g5.xlarge), el costo por ticket pasó de $0,0222 a cerca de $0,0005. Multiplicado por un millón de tickets, eso es la diferencia entre $22.200 y cerca de $500, una reducción del 98%.

La latencia bajó en la misma proporción. El tiempo promedio por llamada pasó de 4.215 ms con Sonnet a 897 ms con el modelo especializado, un 78% menos. El día que Amazon apagó el tráfico de Sonnet, la duración promedio de su función Lambda cayó 74%.

Este patrón no es exclusivo de Amazon. Cualquier equipo que corra una tarea de clasificación sobre millones de eventos (tickets, transacciones, mensajes) paga el mismo costo de usar un modelo generalista para una tarea que, en el fondo, tiene una respuesta de un puñado de opciones fijas. El LLM casi siempre puede resolverlo. Lo que hay que decidir es si vale la pena pagar el precio de un modelo generalista para una tarea que no necesita generar texto.

Cómo funciona un modelo de decisión

La arquitectura que montó Amazon es casi toda infraestructura estándar de AWS. Cada evento de ticket llega a una cola SQS, que dispara una función Lambda. La Lambda lee los datos del ticket y llama a un endpoint de Amazon SageMaker que corre Strands Decider. SageMaker copia los pesos del modelo desde S3 antes de levantar el contenedor, y la red del endpoint queda aislada, sin acceso de salida.
El endpoint usa cerca de 19 GiB de memoria y responde una peticion en unos 640 ms sobre una sola instancia.

flowchart TD
    A["Ticket nuevo"] --> B["Cola SQS"]
    B --> C["Funcion Lambda"]
    C --> D["Endpoint SageMaker: Strands Decider"]
    D --> E["Probabilidad por etiqueta"]
    E --> F["Etiqueta aplicada al ticket"]
    C --> G["AppConfig: BEDROCK / DUAL / DECIDER"]
    G --> C

Para no apostar todo a un cambio brusco, la Lambda lee en cada mensaje un valor de tres estados desde AWS AppConfig. En modo BEDROCK solo responde Sonnet. En modo DECIDER solo responde el modelo de clasificación. En modo DUAL, los dos modelos reciben el mismo ticket, Amazon aplica la etiqueta de Sonnet, y guarda la de Strands Decider para comparar después.

sequenceDiagram
    participant T as Ticket
    participant L as Lambda
    participant S as Sonnet en Bedrock
    participant D as Strands Decider
    T->>L: evento desde la cola SQS
    L->>S: pide etiqueta en modo DUAL
    L->>D: pide etiqueta en modo DUAL
    S-->>L: etiqueta aplicada mas tokens usados
    D-->>L: probabilidad por cada opcion
    Note over L: compara ambas respuestas antes de decidir el cambio

Correr ambos modelos en tráfico real, en paralelo, durante semanas, le dio a Amazon más información que cualquier evaluación offline. Y si algo salía mal, volver a BEDROCK era un cambio de configuración de 45 segundos, sin tocar código ni redeploy.

Para que el modelo clasificador funcione necesita un catálogo de opciones bien definido. La ventana de contexto de Strands Decider es de 4.096 tokens, y las descripciones de las 20 etiquetas que usaba Amazon en producción no entraban ahí. El equipo reescribió cada etiqueta como un criterio de una o dos oraciones, las mandó como las opciones de una sola pregunta de elección múltiple, y agregó una opción "ninguna" para los casos que no encajan.

Así se ve, en una versión simplificada en Python puro y sin ninguna librería de IA, el contrato de entrada y salida que sigue un modelo de decisión: un estado, un conjunto de opciones, y una probabilidad por cada una.

import math

def decision_model(scores):
    exps = {label: math.exp(score) for label, score in scores.items()}
    total = sum(exps.values())
    return {label: round(value / total, 3) for label, value in exps.items()}

resultado = decision_model({
    "facturacion": 2,
    "soporte_tecnico": 1,
    "ninguna": 0
})
print(resultado)

La salida literal de ese script es {'facturacion': 0.665, 'soporte_tecnico': 0.245, 'ninguna': 0.09}. Un modelo de decisión real reemplaza esos tres números fijos por una red entrenada que calcula el puntaje de cada opción a partir del ticket, pero el contrato de salida, una probabilidad por opción que suma 1, es el mismo.

⚠️ Ojo: en las pruebas de Amazon, enviar el mismo ticket con las claves del JSON en otro orden movió las probabilidades de salida hasta 0,19 puntos. Si servís un clasificador especializado detrás de una API, mandá siempre las claves en el mismo orden antes de comparar resultados entre corridas.

Casos de uso reales

El patrón de Amazon se repite en cualquier sistema que reciba mucho volumen y tenga que elegir entre pocas categorías conocidas. Estos son los escenarios donde un modelo clasificador suele rendir mejor que un LLM general:

Enrutamiento de tickets de soporte: decidir a qué equipo va un caso (facturación, bugs, cuentas) antes de que lo vea una persona.- Moderación de contenido: marcar un comentario o una imagen como spam, apropiado o que necesita revisión humana, con un catálogo fijo de categorías.- Detección de fraude en transacciones: puntuar cada transacción contra un conjunto cerrado de patrones de riesgo conocidos.- Enrutamiento entre agentes en un sistema multiagente: elegir qué agente o herramienta especializada debe atender una consulta, en vez de que un LLM grande razone esa decisión cada vez.- Triage de alertas de monitoreo: clasificar una alerta como crítica, informativa o duplicada antes de despertar a un humano.

Todos estos casos comparten tres condiciones: un catálogo de opciones que no cambia todos los días, suficiente volumen para que el ahorro por ticket se multiplique, y una ventana de contexto donde el estado de cada caso entra completo, o casi, dentro del límite del modelo elegido.

Errores comunes y buenas prácticas

El error más común es asumir que un modelo de decisión puede reemplazar cualquier tarea de clasificación sin ajustes. Si las etiquetas necesitan una explicación larga para distinguirse entre sí, o el catálogo cambia cada semana, meter todo ese contexto en una ventana de unos pocos miles de tokens no funciona: hay que simplificar las etiquetas primero, como hizo Amazon.

Otro error es saltarse la fase de comparación en paralelo. Sin un modo como DUAL, no hay forma de saber si el modelo nuevo falla justo en los casos raros que más le importan al negocio. Correr los dos modelos sobre tráfico real, aunque sea por unas semanas, es la única evaluación que de verdad importa.

Ajustar el umbral de confianza también es parte del trabajo, no un detalle menor. Amazon tuvo que calibrar qué tan segura debía estar Strands Decider antes de aplicar una etiqueta sin revisión. Un umbral muy bajo aplica etiquetas equivocadas, y uno muy alto manda demasiados casos de vuelta a revisión humana o a Sonnet, si todavía corre en paralelo.

Tampoco conviene confundir un modelo de decisión con un motor de reglas tradicional. Un motor de reglas aplica condiciones exactas escritas a mano, mientras que un modelo de decisión aprende de ejemplos y da una probabilidad, lo que le permite manejar texto ambiguo que un if/else no puede interpretar.

Sobre si el modo DUAL de Amazon sigue activo en este momento: no hay forma directa de verificar esto desde afuera, porque el valor del flag vive en la cuenta privada de AWS de Amazon, dentro de su propio AppConfig. La verificación real la hace alguien del equipo de Carr y Mehul consultando ese flag desde dentro, no un tercero desde internet.

Comparativa con alternativas

Un modelo de clasificación no es la única forma de resolver un problema de clasificación. Esta tabla resume cuándo conviene cada enfoque:
OpciónCuándo usarlaVentajaLimitaciónLLM general (Sonnet)Catálogo abierto o inestable, pocas llamadas por díaFlexibilidad total, sin reentrenarCosto y latencia altos a gran volumenModelo de clasificación (Strands Decider)Catálogo cerrado, volumen alto, latencia críticaHasta 44 veces más barato y 78% más rápidoNecesita reescribir etiquetas largas como criterios cortosReglas if/else clásicasPocas condiciones, totalmente deterministasCero inferencia, costo casi nuloNo generaliza a texto libre ni a casos ambiguosClasificador clásico (regresión logística, SVM)Volumen alto, features bien definidas, sin GPU disponibleCorre en CPU, muy barato de entrenarRequiere ingeniería de features manual

Profundizando

La cuenta de por qué Strands Decider sale tan barato no es complicada: una instancia ml.g5.xlarge cuesta $1,408 la hora y, a unos 640 ms por petición, atiende cerca de 5.600 tickets en esa hora. Dividiendo, sale a unos $0,0002514 por ticket a utilización completa, unos $250 por millón de tickets. Amazon reporta cerca de $500 por millón en producción real, el doble, porque deja margen de capacidad para picos de tráfico en vez de saturar cada instancia al 100%.

Ese margen es una decisión de diseño, no un desperdicio: una instancia siempre al límite no tiene cómo absorber un pico sin acumular cola. El endpoint de SageMaker autoescala según el tráfico, así que ese margen extra compra tiempo para que entren instancias nuevas antes de que la latencia se dispare.

La otra pieza avanzada es por qué el salto de Strands Decider 2B a la versión E4B, basada en Gemma 4, mejoró los resultados. Más parámetros en el modelo clasificador le dan más capacidad para separar etiquetas parecidas entre sí, al costo de más memoria (el endpoint usa cerca de 19 GiB) y algo más de latencia por petición. Amazon midió ambas versiones contra el mismo set de tickets de prueba antes de decidir cuál pasaba a producción, el mismo principio del modo DUAL aplicado a elegir entre dos versiones del propio decision model.

💭 Clave: el ahorro real no viene solo del modelo más chico: viene también del prompt mucho más corto. Las descripciones de las 20 etiquetas de producción ya superaban por sí solas la ventana de 4.096 tokens de Strands Decider, así que simplificarlas fue tan importante como cambiar de modelo.

📖 Resumen en Telegram: Ver resumen

Tu próximo paso: tomá 20 tickets reales de tu soporte, armá un catálogo cerrado de 10 etiquetas con una oración cada una, y medí con una regresión logística simple cuántos resuelve bien antes de pensar en reemplazar un LLM grande.

Preguntas frecuentes

¿Un modelo de decisión reemplaza siempre a un LLM como Sonnet?

No. Solo conviene cuando la tarea es elegir entre un catálogo cerrado y conocido de opciones, con volumen alto y latencia importante. Si las etiquetas necesitan explicación larga, cambian seguido, o la tarea requiere generar texto libre, un LLM general sigue siendo la mejor opción.

¿Qué pasa si el catálogo de opciones de un clasificador especializado cambia seguido?

Cada cambio de catálogo obliga a reescribir las descripciones de las etiquetas y, en muchos casos, a recalibrar el umbral de confianza. Si eso pasa cada semana, el costo de mantenimiento puede superar el ahorro en tokens, y conviene quedarse con un LLM general más flexible.

¿Cómo se despliega en producción un modelo como Strands Decider?

En el caso de Amazon, corre como un endpoint de Amazon SageMaker sobre instancias ml.g5.xlarge, con una cola SQS y una función Lambda al frente, y AWS AppConfig controlando el interruptor entre Sonnet y el modelo nuevo.

¿Un modelo de clasificación necesita reentrenarse con cada ticket nuevo?

No en el flujo normal de inferencia. El modelo se entrena, o se ajusta, una vez por versión, y después solo clasifica tickets nuevos. Solo se reentrena cuando el catálogo de etiquetas cambia de forma significativa o cuando una evaluación periódica muestra que su precisión bajó.

¿Qué pasa con la latencia de un decision model si el tráfico aumenta de golpe?

Depende del autoescalado del servicio que lo hospede. En el caso de Amazon, el endpoint de SageMaker agrega instancias nuevas a medida que sube la demanda, pero ese proceso toma tiempo, por eso el equipo deja margen de capacidad en vez de operar al límite.

¿Un LLM como Sonnet sigue siendo necesario en el mismo sistema?

Sí, para los casos que el modelo de decisión no puede resolver: tickets que no encajan en ninguna etiqueta del catálogo, o que necesitan una respuesta en texto. Muchos equipos, incluido el de Amazon, mantienen el LLM general como respaldo para esos casos.

Referencias

Strands Agents: el caso de Amazon reemplazando Sonnet 4.6 con Strands Decider, con las cifras de costo y latencia citadas en este artículo.- Documentación de Amazon SageMaker: referencia oficial sobre endpoints de inferencia como el que hospeda Strands Decider.- Documentación de Amazon Bedrock: referencia oficial del servicio donde corre Claude Sonnet en la nube de AWS.- Wikipedia: Multiclass classification: contexto general sobre clasificación entre múltiples categorías, la base matemática de un modelo de decisión.