-
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