-
MACaQ: cuantización MXFP4 de pesos y activaciones capa por capa, con 2,3% de overhead en vLLM y un modelo de 122.000 millones cuantizado en 64 minutos (07-12/11)
El paper es del 7/11 y entró hoy a trending de Hugging Face. Lo que lo vuelve práctico es que trata cada capa lineal de forma independiente: aplica una escala por canal y una transformada block-Hadamard a las activaciones en inferencia, y mete las transformadas inversas correspondientes dentro de los pesos. Sin dependencias entre capas, la cuantización puede correr en streaming con una sola capa en memoria a la vez, y de ahí sale el número que importa para quien no tiene un cluster: 122.000 millones de parámetros en 64 minutos con 32,5 GB de RAM de GPU. Suma Flip-Refinement, un paso de descenso por coordenadas consciente del Hessiano que ajusta códigos FP4 individuales para mejorar sobre round-to-nearest. Reportan perplejidad mejor que DuQuant++ y MR-GPTQ, igualando la mejor de esas dos en Llama-3-8B con 11 veces menos tiempo de cuantización, y 2,3% de overhead end-to-end sobre MXFP4 puro en Qwen3-32B corriendo en vLLM. Funciona además sobre un modelo de difusión de imágenes sin cambios específicos de arquitectura, que es lo que justifica el "model agnostic" del título. arXiv · Hugging Face Papers
-
StrataFlux: cuantización de 2 bits que usa la RAM del host y el SSD como fuente de precisión extra (05/11)
Sigue de lo de ayer, donde un paper auditaba la evidencia pública de cuantización y concluía que no alcanza para decidir nada: este es exactamente el tipo de medición propia que esa auditoría pedía mirar con cuidado. El trabajo de Jake Hyun, Ziyu Zhao, Jae-sun Seo y Mohamed S. Abdelfattah, subido el 5/11, propone una cuantización estratificada de 2 a 4 bits en pesos y 2 a 3 bits en el cache KV, con la idea de tratar la jerarquía de memoria como nativa: la RAM del host y los SSDs sirven como fuentes de precisión adicional en vez de ser solo almacenamiento. Los números, todos sobre modelos de 8.000 millones de parámetros y una RTX 5090: Llama-3.1-8B-Instruct con pesos de 2 bits baja la perplejidad en WikiText-2 de 9,46 a 8,40 conservando 95,4% del throughput de la base cuantizada; Qwen3-8B con pesos y KV de 2 bits sube la exactitud en AIME 2024/2025 de 11,0% a 47,1% sin cambiar el uso de memoria de GPU; y Llama-3.1-8B a 128K de contexto con pesos de 3 bits y KV de 2 bits queda comparable en perplejidad y velocidad al 4 bits AWQ con KV de 8 bits de vLLM usando cerca de la mitad de la memoria de GPU. La salvedad: el abstract no da un factor de aceleración único ni una cifra resumida de pérdida de calidad, y son mediciones de los autores. arXiv
-
Moonshot libera los pesos de Kimi K3.1 Pro: 2,8 billones de parámetros, 1,56 TB y una licencia con tope de 20 millones (04/11)
Sigue de lo de ayer, donde Simon Willison corrió el modelo vía OpenRouter para reproducir la lectura de pesos: ahora los pesos se bajan. La arquitectura es mixture-of-experts con 2,8 billones de parámetros totales y unos 104.000 millones activos por token, 93 capas, 896 expertos de los que se eligen 16 más 2 compartidos, y una atención híbrida de 69 capas KDA y 24 Gated DSA que reemplaza las capas de atención completa de K3. El contexto es de 1.048.576 tokens, el encoder de visión es MoonViT-V2 de 401 millones de parámetros, y los pesos vienen nativamente en MXFP4 con activaciones MXFP8 por entrenamiento consciente de cuantización, así que la descarga son 1,56 TB en 96 shards y no hay checkpoint BF16. Los benchmarks son autoreportados con esfuerzo de razonamiento máximo: 65,7 en Terminal-Bench 4.0, 94,2 en GPQA-Diamond, 92,1 en BrowseComp y 70,0 en HLE-Full con herramientas. Dos letras chicas importan más que los números. La licencia no es OSI: si ofrecés a terceros inferencia o fine-tuning del modelo y el grupo factura más de 20 millones de dólares en cualquier período de doce meses consecutivos, hace falta un acuerdo aparte con Moonshot; el uso interno y el producto que embebe el modelo quedan afuera de esa cláusula. Y el self-hosting no es para cualquiera: la receta de vLLM pide 0.34.0 o posterior y un grupo tensor-parallel de ocho GPUs —dos trays GB300 o un nodo B300—, un nodo de 8×H200 con 1,13 TB de HBM no alcanza para los pesos, y un nodo sale entre 550.000 y 650.000 dólares, el equivalente a unos 55.000 a 65.000 millones de tokens de salida al precio de lista de la API. Hugging Face · OrcaRouter
-
"Twice as Fast, Until It Isn't": la evidencia pública de cuantización para modelos de 9B a 20B no alcanza para decidir nada (03-04/11)
El paper de Smit Kadvani, Kriti Faujdar y Spurthi Tallam, subido el 3 de noviembre y anunciado el 4, no propone una técnica: audita las mediciones publicadas de speedup sobre BF16 y pérdida de calidad para modelos open-weight de 9.000 a 20.000 millones de parámetros servidos en vLLM o SGLang, y concluye que la evidencia está fragmentada. El hallazgo que más duele: solo dos checkpoints —ambos builds INT4 de Gemma 3 12B— tienen a la vez una medición de tiempo en vLLM y un score de calidad, y ese score cubre una sola materia de MMLU, justamente la que el build AWQ usó para calibrar. Los tiempos de batch 1 son anteriores a las versiones actuales de los motores, no hay mediciones en esta franja de modelos para hardware de AMD ni Gaudi de Intel, y no hay comparaciones de FP4 contra BF16. La regla práctica que sí queda es la distinción entre régimen limitado por ancho de banda y por cómputo: a batch chico los pesos de 4 bits casi duplican la velocidad —2,12x para Qwen2.5-14B en una A100—, pero a batch grande la ganancia se evapora —1,02x para Gemma 3 12B a batch 256—, y ahí el formato que todavía ayuda es FP8. Último dato para calibrar el escepticismo: muchos de los deltas de calidad publicados, incluidos todos los de HumanEval, caen dentro del ruido de muestreo del benchmark. El paper cierra con un checklist de siete puntos para reportar mediciones; mientras tanto, la conclusión es medir en tu propia versión del motor y tu propio hardware. arXiv
-
Anthropic publica FlashProve: pruebas criptográficas de que la respuesta salió del modelo que el proveedor dice estar sirviendo (03/11)
El problema que ataca es viejo y nadie lo había resuelto en producción: un router puede reemplazar el modelo caro por uno barato y el usuario no tiene forma de verificarlo. El esquema usa zkSNARKs en dos fases: offline el proveedor publica un compromiso corto a los pesos —que fija un único set sin revelarlo—, y online genera, para un prompt y una salida dados, un archivo de prueba que cualquiera puede chequear contra ese compromiso. Los trucos que lo hacen viable son tres: el trabajo de prueba escala con los expertos activados por token y no con todos los parámetros, las pruebas se generan en lotes después del hecho, y el modelo se streamea capa por capa para que alcance una sola GPU de 80 GB. Los números sobre Llama 4 Maverick en 4 bits: unos 110 tokens/segundo de proving en una H100, pruebas de 18,8 MB por ventana de 1.024 tokens, 39 minutos de compromiso offline reutilizable para unos 16 millones de pedidos, y verificación en 17 segundos en CPU de 24 hilos. El costo es el titular real: probar sale entre 70 y 95 veces el tiempo de GPU de simplemente correr el modelo en vLLM. Las limitaciones están declaradas: las pruebas cubren una versión entera del modelo con decodificación greedy, la arquitectura no se oculta, se asume mixture-of-experts, y el contexto topea en 1.024 tokens. Las propiedades de seguridad están formalizadas en Lean; el código C++ rápido no. Anthropic · TechCrunch
-
LFM3: Liquid AI saca una familia de cinco modelos de unos 2B con un backbone compartido, y el de texto entra en 1 GB a 4 bits (27/10)
Todos salen de LFM3-1.7B-Base, pre-entrenado con 22 billones de tokens, y comparten un mix tri-híbrido de convoluciones cortas con compuerta, atención de ventana deslizante y atención global en 24 capas. La familia: LFM3-1.7B de texto con 256K de contexto, LFM3-VL-2B de visión con video y razonamiento paso a paso, LFM3-Audio-2B con voz de entrada y salida en 18 idiomas, LFM3-Omni-2B que junta las tres, y dos modelos de decisión, d1-2B y d1-Omni-2B, que responden preguntas tipadas sobre texto, imagen y audio. Los números son del propio Liquid AI: el de texto promedia 49,37 en su suite contra 31,55 de LFM2.5-2.6B y 47,24 de Qwen3.5-9B, y lidera en BFCL V4 con 71,39 y en ToolSandbox, aunque los modelos más grandes le ganan en coding agéntico y conocimiento; el de visión promedia 71,4 sobre 62 benchmarks, cerca de Gemma 4 12B (71,7); el de audio da 6,2 de WER en inglés y 73,1 en VoiceBench. Lo accionable es el tamaño: 35% menos parámetros que LFM2.5-2.6B para resultados comparables o mejores, el de texto entra en unos 1 GB a 4 bits, y cada modelo se puede fine-tunear en una sola GPU. Pesos en Hugging Face, soporte declarado para llama.cpp, MLX, vLLM y SGLang, y partners de lanzamiento que incluyen AMD, NVIDIA, Qualcomm, Intel con OpenVINO, Ambarella y OpenRouter. Dos advertencias: la página los llama open-weight pero no nombra la licencia —hay que mirar los model cards—, y nombra al mismo modelo de comparación como "GPT-5.6 Luna" y "GPT-6 Luna" en lugares distintos. Liquid AI
Liquid AI Hugging Face Nvidia AMD Intel Qualcomm GPT llama.cpp
-
Repos: d3-ultra, un modelo de decisión multimodal de 26B con Apache 2.0 que no genera texto (26/10)
La idea de producto es la que viene empujando vLLM Semantic Router: en vez de pedirle a un LLM que escriba una respuesta y después parsearla, el modelo lee la entrada una vez y devuelve una probabilidad por cada opción de cada pregunta. Soporta cinco tipos —Choice, Yes/No, Score, Box para localizar algo en una imagen o un momento de video, y Track para seguir un objetivo a lo largo de un video—, acepta texto, JSON, imágenes y video, y tiene 131.072 tokens de contexto por pregunta; lo que se pasa de ese límite falla con max_length_exceeded en vez de truncarse en silencio, que es exactamente lo que uno quiere en un router. Los números, autoinformados sobre tests privados del equipo: 87,2 en SR-Text, el más alto de los seis modelos probados (GLiDE V1.2 queda en 85,1, d1-ultra en 83,4, d3-turbo en 83,1), y unos 304 ms para una pregunta sobre una foto en una sola AMD MI325X, o 2,16 segundos para 255 preguntas. Dónde pierde: en SR-Box queda en 58,2% contra 60,0% de d3-turbo, que el equipo dice es más fuerte en imágenes naturales mientras d3-ultra lidera en gráficos. Para probarlo: safetensors BF16 de unos 52 GB o GPTQ W4A16 de unos 16 GB, vllm-sr serve -e vllm-sr/d3-ultra desde el PR #5449 del 25 de octubre, API hosteada gratis en decision.vllm-sr.ai, port MLX para Apple Silicon y todavía sin GGUF. El card tampoco nombra el checkpoint base. MarkTechPost · Hugging Face
-
Nanbeige4.3-33B: un denso de 33B con 512K de contexto y licencia Apache 2.0 para coding agéntico (25/10)
Lo publicó en Hugging Face el laboratorio de Nanbeige, que está adentro de la plataforma de reclutamiento BOSS Zhipin, junto con el checkpoint Base para post-entrenamiento propio. Los números que reporta el vendedor: 80,9 en Terminal-Bench 2.1 contra 73,0 de Qwen3.8-27B, 65,5 contra 42,5 en DeepSWE, 54,2 contra 38,3 en Automation Bench y 95,2 en AIME 2026, con 17 de 20 filas a favor; pierde en SWE-Bench Pro (60,3 contra 61,7), GDPval y GPQA Diamond. Dos cosas antes de bajarlo: los benchmarks son autoinformados y varias cifras de los competidores en la tabla de Nanbeige no coinciden con las de sus propias model cards, y el hardware no es poco —unos 66 GB de pesos en BF16 más unos 112 GB de caché KV para una secuencia de 512K, o sea servidor multi-GPU—. Hay recetas para Transformers, SGLang y vLLM, y cuantizaciones de la comunidad en GGUF y MLX-4bit para uso local. MarkTechPost
-
Carbon-X: Hugging Face abre un modelo de lenguaje de ADN de 14,8B que entra en una GPU de 80 GB (25/10)
Lo hicieron Hugging Face Bio con la Zhongguancun Academy y el TIGEM de la Universidad de Nápoles Federico II, partiendo de Qwen3-14B y agregando los tokens de ADN al vocabulario de texto, así que uno le pasa secuencia cruda en un chat y responde en inglés: si una mutación es benigna o patogénica, si una región es reguladora, de qué organismo viene, qué bases siguen. Promedia 66,7% en cinco benchmarks de ADN contra 67,5% de GPT-6.1 Sol (Max) y 60,9% de Opus 5.5 (Max), con 74,9% en BioReason Coding y 39,4% en NextBase como sus mejores marcas, y 29,8% en preguntas de sitios de splicing como la peor. La comparación hay que mirarla con cuidado: Carbon-X corrió con pensamiento apagado y los competidores en su mejor configuración de razonamiento. Apache 2.0, pesos en safetensors y GGUF (15,8 GB en Q8_0, 9,6 GB en Q4_K_M), vLLM, Transformers v5+ o llama.cpp b11742 o posterior —las builds viejas tokenizan mal el ADN—, y los propios autores aclaran que no está validado clínicamente. MarkTechPost
-
Google abre TorchTPU y Amazon TorchNeuron para sacar PyTorch del candado de CUDA (19-20/10)
Google anunció TorchTPU el martes como proyecto open source: su versión de PyTorch para correr aplicaciones en TPUs, con la promesa de que una app existente se muda "con un simple cambio de configuración" y sin reescribir, más una suite de agentes para asistir la migración y arreglar errores. Amazon había hecho lo propio el lunes con TorchNeuron para Trainium, y va un paso más allá: está mandando código al proyecto PyTorch principal para desacoplar features de los chips de Nvidia, de modo que PyTorch quede abierto a cualquier hardware por default. Es el ataque más directo al foso real de Nvidia, que no es el silicio sino el software: por algunas cuentas PyTorch está detrás del 85% de las aplicaciones de IA, y Google dice haber trabajado con Meta, Hugging Face, Inferact (vLLM) y RadixArk (SGLang) para que TorchTPU funcione con esas herramientas. Las reservas son de información faltante: no hay términos de licencia publicados para ninguno de los dos, no hay precios, no hay benchmarks de migración, y nada de esto significa que los desarrolladores se muden —solo que el costo de intentarlo baja—. TechCrunch · Technology.org
TechCrunch Technology.org Google Meta Amazon Hugging Face Nvidia
-
DeepSeek libera DeepInfer con Apache 2.0, el motor de inferencia de su propia API, y le da soporte de primera a los Ascend 950 de Huawei (20/10)
Sigue de ayer, cuando el rumor era que DeepSeek estaba aportando al diseño de los Ascend y empezaría a pre-entrenar sobre ellos: el desarrollo nuevo es verificable y está en el código, porque DeepInfer lista la serie Ascend 950 de Huawei como hardware soportado al lado de Nvidia. Es el framework con el que DeepSeek sirve V4.1-Flash en producción, e incluye los kernels y librerías de comunicación que ya había liberado por separado —FlashMLA, DeepGEMM, DeepEP— más distribución de inferencia multi-chip, decodificación especulativa, scheduling asincrónico y salida estructurada, con una librería compañera deepseek-recipe en Rust y Python que convierte requests de API en entradas de modelo para reproducir el comportamiento de su API. Lo accionable es que se puede levantar el stack de serving de DeepSeek en infra propia, pero con tres límites concretos: en Nvidia solo soporta SM100 —Blackwell de datacenter, Hopper queda afuera—, faltan piezas de producción como gestión de caché KV, separación de etapas de inferencia entre máquinas y balanceo entre réplicas, y la inferencia batch-invariant y el sampling determinista funcionan solo en Nvidia. No hay números de throughput ni latencia publicados, ni comparación contra vLLM o SGLang. The New Stack · Quartz
-
DeepSeek publica V4.1-Flash-1017 con licencia MIT: 763B totales, 1M de contexto y mejoras parejas en toda la batería agéntica (17/10)
Es una actualización menor de V4.1-Flash, pero los saltos no son menores: HLE sin herramientas pasa de 36,8 a 42,6 —44,0 en el subconjunto de texto—, Terminal-Bench 4.0 de 31,2 a 42,3, DeepSWE v1.1 de 74,2 a 77,0, NL2Repo-Bench de 65,4 a 68,2, Automation-Bench de 54,8 a 60,5 y Apex Bench de 64,6 a 72,1. Lo que vale para quien lo quiera usar es el resto de la ficha: MIT para el repo y para los pesos, contexto recomendado de 1M con salida de 256K o más, modo thinking con esfuerzo de razonamiento numérico, tool calling, mensajes de sistema a mitad de conversación y contenido de imagen intercalado, y servido local con vLLM, SGLang o Docker Model Runner. Dos detalles prácticos: no hay chat template Jinja —viene una implementación de referencia en Python (encoding.py) y un toolkit en Rust, deepseek-recipe, para producción— y la temperatura recomendada es 1,0 con top_p 1,0. Las reservas son las de siempre: todos los números son autoreportados, Opus 5 queda arriba en la mayoría de las columnas de la propia tabla, y al momento de la publicación ningún proveedor de inferencia lo hostea. Hugging Face
-
Ant Group libera Ling-3.1-flash: 560B totales, 25B activos y un esquema de precisión mixta que baja de ocho GPUs Hopper a cuatro (16/10)
El modelo apunta a código, flujos agénticos y tareas profesionales con documentos largos y herramientas externas, con contexto de hasta un millón de tokens. El dato que decide si se puede probar es el de memoria: el despliegue en precisión mixta lleva los pesos de unos 534 GB a 292 GB, lo que en la configuración Hopper que reporta el equipo corta el requerimiento de ocho GPUs a cuatro. Se despliega con SGLang y vLLM. Lo que falta es bastante: TechNode no publica benchmarks ni declara licencia, y las cifras de memoria y GPUs son las del propio equipo sin verificación independiente, así que la model card es el lugar donde mirar antes de bajarlo. TechNode · Hugging Face
-
Intel saca LLM-Scaler-vLLM PV 1.5 con cuantización FP8 e INT4 online y cinco modelos nuevos para Arc (16/10)
Es el stack Docker de Intel para cargas de LLM que sale de Project Battlematrix, y el salto de versiones es la noticia operativa: vLLM pasa de 0.14 a 0.26 —upstream ya está en 0.31— y PyTorch de 2.10 a 2.12. Lo aprovechable son las dos piezas nuevas: cuantización FP8 y INT4 simétrica online, más caché KV en FP8, y soporte de Qwen3.6-27B, Qwen3.8-27B, Qwen3.6-35B-A3B, gemma-4-26B-A4B-it y gemma-4-31B-it. Phoronix reporta mejoras de time-to-first-token en Qwen y Gemma 4, mejor decodificación MTP y mejor rendimiento de serving con LoRA y caché KV FP8, pero sin un solo número publicado. Apunta a Intel Arc Graphics y llega justo antes del GPU D Series "Crescent Island" que Intel formalizó el 12 de octubre. Phoronix
-
Decision 3.0: el vLLM Semantic Router liberó una familia de modelos de decisión multimodales con licencia Apache-2.0, de 0,85B a 26B (11/10)
Sigue de Decision-1 de Microsoft y Jev de TypeSafe AI: es el mismo patrón —en vez de generar texto que después hay que parsear, el modelo recibe un esquema de preguntas y devuelve probabilidades por opción, que uno umbraliza— pero esta vez con pesos abiertos y de verdad multimodal, porque lee texto, JSON e imágenes (hasta 1,6 megapíxeles cada una, con todas las imágenes visibles para cada pregunta). Los cinco tamaños son d3-lite (0,85B), d3-nano (2,21B), d3-mini (4,54B), d3-flash (8,39B) y d3 (26,09B), todos sobre bases Qwen3.5 salvo el grande, que va sobre Qwen3.8-27B, y todos con encoder de visión propio. Las latencias medidas en una sola MI325X con batch de 1 son la parte accionable: 23,5 ms de texto en d3-lite y 29,7 ms en d3-flash, contra 84 ms de d3; con una imagen suben a 60,7 ms, 171,8 ms y 342 ms. El equipo recomienda d3-flash por relación tamaño/rendimiento y declara 59,0 en el índice Jev 0.3.1 con 9B, por encima de los 55,9 que marcaba Decision 2.0 con 27B. Los números son autoreportados, no hay API hosteada —se self-hostea con transformers 5.17.0 y trust_remote_code=True, o se sirve con vllm-sr serve—, no publican largo de contexto para d3 ni builds GGUF o MLX, y el liderazgo por clase es parcial: d3-lite queda tercero en visión y d3-nano por debajo de LiquidAI d1-3B en texto. MarkTechPost · Hugging Face · GitHub
MarkTechPost Hugging Face GitHub Microsoft Hugging Face GitHub
-
vLLM: un parche al indexer de DeepSeek-V4.1 baja la selección de bloques de 848 a 43 microsegundos por step, y la latencia real mejora 3% (11/10)
El PR ataca select_candidate_blocks en el decode indexer, que hoy puntúa todos los bloques al ancho fijo de max_model_len —un millón por defecto— y después corre torch.topk(2048), con lo cual cuesta unos 850 microsegundos por step de decode sin importar el largo real del contexto. El parche puntúa solo los bloques válidos con una grilla fija, pasa el conteo de bloques válidos como end en el camino DeepSelect, rellena filas cortas con -1 y pide logits de decode en bf16. El microbenchmark en una GB300 da 847,8 a 42,9 microsegundos con 131K de contexto, casi 20x, pero el número se desinfla rápido: 7,4x a 400K y 3,7x al millón, así que el titular es el caso más favorable y no el esperable. Punta a punta sobre DeepSeek-V4.1-Flash con 125K de input y 8K de output, el indexer baja de 1.698 a 886 microsegundos por step y torch.topk desaparece, pero el ITL mediano va de 26,52 a 25,65 milisegundos, un 3,3%. Lo accionable son los flags, que el PR lista explícitos: --sparse-indexer-topk-backend deep_select, indexer_kv_dtype: mxfp4, indexer_sparse_logits: true y --moe-backend deep_gemm_mega_moe. Está abierto y sin mergear, sin aprobación del code owner, con benchmarks de un solo autor en una sola máquina y sin datos de prefill ni de contextos cortos. GitHub
-
vLLM: sacar llamadas de ops del host en el prefill eager de GDN ahorra 9 a 14 milisegundos por step mixto, y el goodput sube 2,4% (11/10)
Vale como caso de estudio de optimización donde el cuello no está en los kernels sino en el overhead de Python: el PR no toca ningún kernel y afirma salida y estados bit-idénticos. Reemplaza advanced indexing de Python por index_select, masked_fill_ e index_copy_ en el gather-zero-scatter del estado SSM, cambia gathers por slices más dos copy_ cuando las filas de spec-decode van primero, y agrega un modo contiguous=False a rearrange_mixed_qkv para devolver vistas strided. El perfil con py-spy mostraba unos 80 milisegundos de Python por step mixto, 71% de eso en el core eager de GDN, y el autor estima 22 milisegundos recuperados entre los tres cambios. En 8 A100 de 40 GB con Qwen3.8-Flash-Next-FP8, el período GPU del step mixto baja de 103,7 a 92,6 milisegundos medianos y la participación del camino eager en el main thread de 24,4% a 19,1%. El end-to-end es modesto y el autor lo admite: goodput de 1,866 a 1,910 req/s y SLO pass de 91,70% a 92,75% a concurrencia 20, porque el workload está limitado por capacidad de KV cache. Es draft con el checklist de testing sin tildar, la ventana "con PR" del comparativo tenía chunks de prefill más grandes, y arrastra 11 tests que fallan igual con y sin el cambio. GitHub
-
LMCache, el acelerador de caché que usa vLLM, tiene un 9,8 sin autenticación y todavía sin versión corregida (07/10)
El CVE-2026-105192 lo publicó JFrog y la mecánica es de manual: el socket ZeroMQ del servidor en modo multiproceso no tiene autenticación, uno de los tipos de mensaje se deserializa con pickle de Python, y el servidor desempaqueta el dato antes de chequear el tipo. Un solo mensaje armado ejecuta comandos como el usuario del proceso, que en las imágenes oficiales de contenedor es root. Afecta de 0.3.9 a 0.5.5, más los candidatos de 0.5.6 y la rama de desarrollo, y no hay versión parchada ni aviso de seguridad del proyecto. Solo queda expuesto si alguien ató el servidor a una dirección enrutable en vez de localhost, que es exactamente lo que hace el ejemplo de despliegue de Kubernetes del propio LMCache: escucha en todas las interfaces. Si corrés LMCache dentro de un único proceso de vLLM el puerto no se abre. La mitigación es de red, no de parche: dejá el puerto en la máquina local o en una red de clúster confiable, y tené en cuenta que un firewall baja el riesgo pero no lo elimina, porque cualquier host que pueda conectar ejecuta código. The Hacker News
-
Cloudflare liberó Clef y Clef-flash: modelos abiertos que devuelven probabilidades tipadas en vez de texto, con 38,8 ms de latencia mediana (01/10)
La idea rompe con el patrón de pedirle a un LLM que conteste en JSON y después parsear: Clef lee un estado de entrada y un conjunto de preguntas tipadas, y devuelve una probabilidad calibrada para cada respuesta permitida, en una sola pasada no autorregresiva. Son dos tamaños post-entrenados sobre Qwen —Clef de 27B y Clef-flash de 9B—, con licencia Apache 2.0, pesos en Hugging Face, ventana de 64K y hasta 64 preguntas por pedido, en tres tipos: booleano, opción múltiple y puntuación ordenada. Las latencias medianas son 209 ms para Clef y 38,8 ms para Clef-flash contra 524 ms del competidor Jev, y Clef gana en 7 de 10 benchmarks de decisión. Lo accionable: el esquema de preguntas va dentro del pedido, así que se pueden cambiar las etiquetas sin reentrenar, y corre en vLLM, SGLang y Transformers además de Workers AI. Hay también un servicio de afinado por refuerzo que usa el tráfico propio del AI Gateway. Los casos obvios son triage de soporte, clasificación de amenazas, moderación y chequeos de seguridad de agentes: donde la velocidad y la estructura importan más que la explicación. Cloudflare · AlphaSignal
-
Inferencia local: llama.cpp sumó soporte de Nemotron 3 Puzzle y un 2,71x en modelos cuantizados a IQ3_S, pero conviene quedarse en la build b11199 (27/09)
El relevamiento diario de infraestructura marca regresiones reportadas en los backends ROCm, SYCL y CUDA en las builds posteriores, así que el salto de rendimiento y la estabilidad todavía no viajan juntos. En vLLM entraron GLM-5.3-Flash-DFlash2 y MiniCPM-V 4.7, y hay un problema abierto que vale mirar antes de subir a producción: deadlock del motor V1 bajo carga concurrente cuando se combina decodificación especulativa con cuantización FP8. LiteLLM optimizó la capa de proxy con operaciones Redis en lote y sumó soporte de batch de Mistral. La recomendación del informe es directa: fijar builds estables y evitar por ahora la inferencia gestionada de Ollama Cloud Pro, que muestra 95% de fallas. AI Infrastructure Digest
-
El motor de inferencia colibri explotó en GitHub con más de 3.100 estrellas en un día (13/09)
El repo no es nuevo, pero el salto de tracción de hoy lo pone arriba de la lista de tendencias y vale mirarlo por lo que propone: correr modelos MoE de frontera —de 744.000 millones a 2,8 billones de parámetros— en hardware de consumo, en C puro y sin dependencias, tratando almacenamiento, RAM y VRAM como una sola jerarquía de inferencia. La idea central es hacer streaming de los expertos desde disco en lugar de tenerlos todos en RAM, así que un NVMe rápido pasa a ser el factor que más determina los tokens por segundo. Hoy soporta ocho familias, entre ellas GLM-5.2, GLM-5.3-Flash, Kimi K3, DeepSeek V4 Flash, Qwen3.8-Flash-Next, Qwen3.6 y OLMoE, con la jerarquía de memoria manejada por LRU más un conjunto de pines aprendido. Conviene tomarlo como lo que es —un proyecto en movimiento, con trabajo abierto en formatos, compresión, placement, scheduling, kernels y KV—, no como un reemplazo de producción de vLLM o llama.cpp. GitHub · Colibri
-
K2 Horizon: el Institute of Foundation Models publica seis modelos abiertos de 0,9B a 375B con todo el ciclo de entrenamiento, no solo los pesos (03/09)
Pesos y código van bajo Apache 2.0, con soporte día cero en vLLM, SGLang y Ollama, y sobre hardware Nvidia, AMD y Cerebras. Lo distinto no son los puntajes sino lo que sale con ellos: checkpoints intermedios, datos o recetas de construcción, mezclas de pre-entrenamiento, código de entrenamiento, logs finos y los resultados de evaluación de cada etapa, incluido el post-entrenamiento agéntico. Los seis comparten arquitectura, vocabulario y tooling, así que se puede saltar de tamaño sin rehacer nada. Dos novedades técnicas: MoVA, que lleva el enrutado de expertos adentro de la atención y le permite al 36B-A4B activar solo ~4B de parámetros por token quedando apenas debajo del 32B denso; y Uno, un adaptador LoRA de difusión que acelera la generación sin tocar los parámetros autorregresivos ni degradar la calidad. El 17% del corpus de pre-entrenamiento son trayectorias de razonamiento explícito, y eligieron Markdown en vez de JSON para presentar herramientas porque les dio 18,5% más eficiencia de tokens. IFM · Hacker News · Hugging Face
IFM Hacker News Hugging Face Hugging Face Nvidia AMD Cerebras
-
IBM liberó la familia Granite 4.2 bajo Apache 2.0, con entrenamiento agéntico y ventana de 512.000 tokens (26/08)
Son tres tamaños —3B, 8B y 30B— entrenados desde cero sobre unos 15 billones de tokens, con la posibilidad de alternar entre modos "thinking" y "non-thinking" para regular cuánto cómputo gasta cada tarea, más un modo "low-effort" para consultas simples. Lo distintivo está en las variantes de 8B y 30B: pasan por lo que IBM llama "agentic RL", entrenamiento por refuerzo en sandboxes reales donde aprenden a usar herramientas, escribir y ejecutar código, y buscar en la web. Todos soportan tool calling en formato OpenAI y corren en vLLM o SGLang. En el mismo anuncio salieron los Granite Speech 5.0 Turbo CTC, de apenas 470 millones de parámetros, que según IBM transcriben tres horas de audio en un segundo y duplican en velocidad a los líderes previos del Open ASR Leaderboard. Todo está en Hugging Face, Ollama y GitHub. The Decoder · IBM Research
-
Netflix reemplazó miles de features hechas a mano por texto plano y un LLM afinado, y midió la diferencia con usuarios reales (22/08)
GenRec convierte el comportamiento del usuario —reproducciones, duración, pulgares, agregados a la lista, abandonos— en una especie de diálogo en lenguaje natural, en vez de codificarlo como vectores numéricos densos, y deja que el modelo detecte solo los patrones de género o los cambios de interés. El entrenamiento va en dos fases: un modelo open-weight sin nombrar se afina sobre datos de Netflix para entender el catálogo, y una segunda ronda lo convierte en ranker, con actualizaciones más frecuentes. Corre sobre vLLM en un modo donde lee la entrada una vez y puntúa todos los candidatos en una sola pasada sin generar texto, y un componente aparte se asegura de que solo puntúe títulos que existen de verdad. Los números son chicos pero medidos: 1,6% mejor calidad de ranking offline con unas 40 veces menos ejemplos etiquetados en la segunda fase, y en un A/B de cuatro semanas sobre el 10% del tráfico, +0,115% en la métrica corta de home y +0,006% en la métrica núcleo de largo plazo, ambas significativas. Lo transferible es el diagnóstico: el trabajo se corrió de inventar features a decidir qué señales entran al prompt y cuánto de cada una, y el modelo base envejece rápido —con dos semanas encima, el aporte del post-entrenamiento específico salta de 35-50% a 80%. Netflix lo llama "un paso temprano pero prometedor" y no piensa reemplazar el sistema actual todavía. The Decoder · Netflix Tech Blog
-
vLLM-Omni suma Distributed Layerwise Offload y corre un modelo de difusión de 124 GB con 12 GB de HBM (17/08)
Es para el lado de video y difusión, no para LLMs: apunta a servir DiT de 200B y más. La técnica combina cuatro cosas: carga con meta-device y mmap sobre la page cache del sistema, sharding de pesos con reconstrucción por AllGather, doble buffer de prefetch —solo dos capas viven en HBM a la vez— y multi-concurrencia DP. Los números medidos: el pico de memoria de host en arranque en frío baja de 178 GB a 47 GB, y con Cosmos3-Super (64B, 124 GB en BF16) sobre 4× B300 y cuatro pedidos concurrentes rinde 1,39× el throughput de HSDP+USP4 usando 12,62 GiB de HBM contra 42,00 GiB, con hashes SHA256 idénticos byte a byte. Se prende con vllm serve <modelo> --omni --enable-distributed-layerwise-offload --data-parallel-size 4, y hay un --dlo-no-use-allgather para cuando la sincronización cuesta más que la memoria que ahorra. Las limitaciones están declaradas y conviene leerlas: pide vLLM 0.27.0 con vLLM-Omni v0.27.0rc1 —en 0.26.0 el camino DLO+DP rechaza todos los pedidos—, el AllGather suma 150 ms fijos por paso, y el modo preferido cambia según la topología, porque en DP8×SP1 conviene rank-local. vLLM Blog
-
vLLM suma verificación adaptativa para speculative decoding, y elimina el tuning manual por workload (14/08)
El diagnóstico es el aporte: a alta concurrencia el speculative decoding se rompe porque los últimos tokens del borrador casi nunca sobreviven. En DeepSeek-V4-Pro-0813, el séptimo token de un bloque de 7 sobrevive menos del 10% de las veces contra más del 70% del primero, y esos slots desperdiciados cuestan throughput real cuando la GPU se satura. Ahora vLLM usa la cabeza de confianza de DSpark para decidir por paso cuánto del borrador verificar, en vez de fijar num_speculative_tokens por deployment. Con enable_adaptive_verification: true se mantiene en la frontera de Pareto de concurrencia 1 a 256. Limitaciones claras: requiere AttentionCGSupport.ALWAYS, y no anda con --enforce-eager, LoRA ni pipeline parallelism. Blog de vLLM · PR #47808
-
Guía práctica: tooling de inferencia local comparado (llama.cpp, Ollama, vLLM, SGLang)
Repaso actualizado a julio de cuándo conviene cada motor para servir modelos localmente — referencia útil para decidir stack de serving según throughput vs. simplicidad. DEV Community
-
LMCache: más throughput en inferencia LLM
Capa de KV cache de alta velocidad diseñada para acelerar el throughput de inferencia; encaja con stacks tipo vLLM para serving local de producción. Útil si estás optimizando latencia/costo de serving. OSSInsight — Trending AI
-
Correr Kimi K3 localmente: MXFP4 y llama.cpp
Con los pesos abiertos de Kimi K3 ya publicados (~1,4 TB en MXFP4), la comunidad está armando guías para self-hosting. La ruta práctica: GGUF + llama.cpp (sin paso extra de conversión/cuantización, se apunta el server al archivo) o vLLM/SGLang para serving. El Hub de Hugging Face (org ggml-org) concentra las conversiones oficiales. Accionable para quien quiera evaluar un frontier open-weight sin depender de API. explainx · dev.to — guía inference tools
explainx dev.to — guía inference tools Hugging Face Kimi llama.cpp
-
Hugging Face transformers v5.13.0 se alinea con la última vLLM
El release trae fixes de generación, attention, cache, cuantización y serving orientados a habilitar transformers con la versión más reciente de vLLM. Útil si servís modelos y venías peleando compatibilidades entre ambas libs. Nota de ecosistema: TGI está en modo mantenimiento y redirige a vLLM, SGLang, llama.cpp y MLX. Releasebot — Hugging Face