El radar

Accelerating Dropless MoE Training in JAX with NVIDIA Transformer Engine

NVIDIA detalla optimizaciones en Transformer Engine con JAX para entrenamiento dropless de MoE, logrando un aumento de 10.4x en throughput (de 103 a 1,068 TFLOPS/GPU) entrenando DeepSeek-V3 sobre hardware GB200/GB300 NVL72. El stack combina kernels grouped GEMM para manejar conteos de tokens variables por experto sin padding ni descarte, NCCL EP para acelerar dispatch/combine fusionando etapas y deduplicando tokens, más host offloading en JAX y multistreaming de colectivos en XLA. A 1,024 GPUs sostiene 97% de eficiencia de escalado entrenando DeepSeek-V3 671B. IMPORTA: Para quien entrena o sirve MoE a escala, este desglose de kernels (grouped GEMM, NCCL EP, solapamiento de colectivos NVLink/InfiniBand) marca el estado del arte en infraestructura JAX y da palancas concretas para atacar el cuello de comunicación que hoy domina el entrenamiento de modelos sparse. MOT

Por qué importa: Para quien entrena o sirve MoE a escala, este desglose de kernels (grouped GEMM, NCCL EP, solapamiento de colectivos NVLink/InfiniBand) marca el estado del arte en infraestructura JAX y da palancas concretas para atacar el cuello de comunicación que hoy domina el entrenamiento de modelos sparse.

↳ Contexto: TEXAS: Task-Expert-Aware Supervision for Downstream Mixture-of-Experts LLM Adaptation · ver hilo completo

From fine-tuned model to cheaper and faster inference: Speculator training on Red Hat OpenShift AI with Kubeflow

Red Hat detalla cómo entrenar draft models personalizados para speculative decoding sobre OpenShift AI usando Kubeflow y la librería open source Speculators del proyecto vLLM, con el método EAGLE3 publicado en NeurIPS 2025. El problema que resuelve: un draft model solo acelera la inferencia si su distribución de tokens coincide con la del verifier, por lo que al hacer fine-tuning o cambiar de modelo base hay que reentrenar el draft model para recuperar el speedup. Con un draft model bien alineado, EAGLE3 reporta 4x-6x de speedup a temperatura 0 y despliegues reales en vLLM logran reducciones de 2.5x-3.5x en latencia inter-token sin pérdida de exactitud, gracias a rejection sampling. IMPORTA: Cierra el hueco operativo de que speculative decoding solo era práctico para modelos base: ahora cualquier equipo que sirva un LLM con fine-tuning propio puede recuperar el speedup de inferencia sin degradar la salida, atacando la partida que consume el 70-80% del gasto en IA.

Por qué importa: Cierra el hueco operativo de que speculative decoding solo era práctico para modelos base: ahora cualquier equipo que sirva un LLM con fine-tuning propio puede recuperar el speedup de inferencia sin degradar la salida, atacando la partida que consume el 70-80% del gasto en IA.

↳ Contexto: The Checking Problem: What must be true before AI ships in a regulated firm · ver hilo completo

From bare metal to diverse AI revenue streams: Navigating the GPU cloud platform challenge

Artículo de Red Hat sobre el reto de los "neoclouds": operadores que ya tienen GPUs y necesitan convertirlas en un servicio cloud vendible, no solo integrarlas en Kubernetes. Detalla requisitos operativos como scheduling topology-aware (NVLink/NVSwitch), RDMA y GPUDirect para no ahogar el rendimiento de training, aislamiento multi-tenant que llega hasta memoria de GPU y dominios NVLink, cumplimiento (FIPS, FedRAMP, ISO 27001, BSI C5, GDPR) y actualización de firmware en flotas activas. Menciona acuerdos multimillonarios (Nebius-Microsoft por 17.400 millones, CoreWeave con Microsoft y OpenAI) y el caso de NxtGen Cloud Technologies, que adoptó un enfoque platform-based para acelerar su time-to-revenue. IMPORTA: Para quien opera plataformas de IA, el mensaje es que la GPU es la parte fácil: el valor está en resolver scheduling topology-aware, aislamiento a nivel de GPU y cumplimiento multi-tenant, y comprar esa capa en vez de construirla puede ser la diferencia entre

Por qué importa: Para quien opera plataformas de IA, el mensaje es que la GPU es la parte fácil: el valor está en resolver scheduling topology-aware, aislamiento a nivel de GPU y cumplimiento multi-tenant, y comprar esa capa en vez de construirla puede ser la diferencia entre meses de coste sin ingresos y tener servicio en producción.

AutoRAG advances in Red Hat OpenShift AI 3.5

Red Hat presentará en el advanced technical preview de AutoRAG dentro de OpenShift AI 3.5 un sistema de evaluación y tuning automático de hiperparámetros para pipelines RAG, construido sobre Kubeflow Pipelines y el motor open source IBM ai4rag. AutoRAG genera artefactos listos para producción (pipeline de ingesta como Kubeflow Pipeline y endpoint de consulta como configuración de Responses API vía Open GenAI Framework) tras seleccionar el patrón ganador en su leaderboard, e incorpora soporte multilingüe nativo con un preselector de modelos basado en LLM (inicialmente alemán, español y japonés) y una representación visual del pipeline para explicar cada patrón probado. También apunta a permitir reutilizar PostgreSQL con pgvector como almacenamiento vectorial. IMPORTA: Automatiza una de las partes más costosas y manuales de operar RAG en producción —elegir chunking, modelo de embeddings y configuración de indexado— y convierte el resultado directamente en pipelines de Kubeflow y endpoints desplegables en OpenShift, algo relevante para quien mantiene plataformas de IA

Por qué importa: Automatiza una de las partes más costosas y manuales de operar RAG en producción —elegir chunking, modelo de embeddings y configuración de indexado— y convierte el resultado directamente en pipelines de Kubeflow y endpoints desplegables en OpenShift, algo relevante para quien mantiene plataformas de IA sobre Kubernetes.

↳ Contexto: Less can be More: Relieving RAG Bottlenecks via Evidence Frontloading and Pressure-Adaptive Budgeting · ver hilo completo

Performance, Efficiency and Collapse -- Advantages and Challenges in Offline Post-training of Code LLMs

Paper de arXiv (cs.LG) titulado "Performance, Efficiency and Collapse -- Advantages and Challenges in Offline Post-training of Code LLMs", de Abhinav Anand y otros tres autores, que aborda el post-training offline de LLMs de código y menciona tanto ventajas como un fenómeno de "collapse". No se detallan en el texto extraído cifras, metodología ni resultados concretos. IMPORTA: Para quien entrena o hace fine-tuning de modelos de código, el aviso de "collapse" en post-training offline es un riesgo a vigilar en sus propios pipelines, aunque sin datos concretos en el extracto conviene ir al PDF antes de sacar conclusiones.

Por qué importa: Para quien entrena o hace fine-tuning de modelos de código, el aviso de "collapse" en post-training offline es un riesgo a vigilar en sus propios pipelines, aunque sin datos concretos en el extracto conviene ir al PDF antes de sacar conclusiones.

↳ Contexto: Training Skills Like Parameters via Self-Supervised Semantic Diffusion · ver hilo completo

Look Before You Leap: Pre-Action Verification for LLM Agents

Paper de arXiv que propone la verificación determinista pre-acción como forma de supervisión de agentes LLM, estudiada en dos modalidades: comandos shell y edición de código. Un verificador estático sobre 9930 comandos y 482 herramientas detecta el 95.8% de comandos inválidos con 10.0% de falsos positivos, mientras que en edición de código un benchmark de 640 ediciones sobre 224 archivos muestra que los formatos anclados en contenido (search/replace, diff) fallan de forma limpia, pero los anclados en ubicación fallan en silencio: los números de línea corrompen el 99.1% de los archivos ante un desplazamiento de una línea y las ediciones por nombre de función aciertan la función equivocada el 12.7% de las veces. Una política de "rechazar si hay duda" (selective grounding: 0.958 recall con 7.0% de falsos positivos) y un applier de anchor-and-verify (1 error silencioso en 8320 intentos) convierten fallos silenciosos en recuperables; se publican ambos benchmarks,

On-Device Language Models for Privacy-Preserving Stress Prediction: A Multimodal Evaluation on Mobile Health

Un paper de arXiv evalúa modelos de lenguaje on-device (ODLMs) para la predicción multimodal de estrés en salud móvil mediante zero-shot prompting, midiendo precisión predictiva junto con latencia y throughput. Los resultados muestran que las features objetivas de sensores superan marginalmente a los auto-reportes subjetivos en promedio, y que modelos ligeros de menos de 2B parámetros logran baja latencia con uso de recursos predecible. Los autores destacan tanto el potencial como las limitaciones prácticas de los ODLMs para salud mental móvil.

Por qué importa: Aporta evidencia empírica sobre latencia y consumo de recursos de modelos sub-2B en inference local bajo restricciones de dispositivo, un dato útil para quien diseña despliegues on-device donde el presupuesto de cómputo y la privacidad son límites duros.

b10956

El backend SYCL de llama.cpp rechazaba GGML_OP_TOP_K para k > 32 y caía a CPU, por lo que se añade un radix select para k grandes cuyo footprint en SLM es independiente de k (guarda el histograma, no los candidatos). Además se paraleliza una fila sobre varios work-groups cuando hay pocas filas para cubrir el dispositivo, y se mueve el gate scan-merge/radix al punto donde ambos caminos se cruzan. Medido, logra hasta 118x en distintas shapes frente al fallback a CPU y mantiene la perplejidad de wikitext-2 sin cambios. IMPORTA: Desbloquea top_k con k grandes (como los 2048 de un indexer de atención dispersa) directamente en GPU SYCL en lugar de un round-trip a CPU por llamada, lo que importa a quien corre inference local en hardware Intel y a quien diseña kernels con footprint acotado en memoria local compartida.

Por qué importa: Desbloquea top_k con k grandes (como los 2048 de un indexer de atención dispersa) directamente en GPU SYCL en lugar de un round-trip a CPU por llamada, lo que importa a quien corre inference local en hardware Intel y a quien diseña kernels con footprint acotado en memoria local compartida.

b10955

Release b10955 de llama.cpp desactiva el PCH de ggml-cpu y elimina la rama basada en std::hardware_destructive_interference_size de CACHE_LINE_SIZE. El PCH forzaba la inclusión de ggml-impl.h antes de ops.h, haciendo que los kernels C++ usaran CACHE_LINE_SIZE = 256 mientras el código C de dimensionado del work buffer usaba 64, lo que subdimensionaba el buffer de trabajo de rope y provocaba un heap-buffer-overflow con corrupción de heap y crash posterior en ggml_compute_forward_rope_flt. Con el cambio se restaura el orden natural de includes y el valor queda determinista. Es un bug de corrupción de memoria en el backend ggml-cpu de llama.cpp que podía tumbar o corromper cualquier despliegue de inference en CPU.

Por qué importa: Es un bug de corrupción de memoria en el backend ggml-cpu de llama.cpp que podía tumbar o corromper cualquier despliegue de inference en CPU, así que conviene actualizar si sirves modelos con llama.cpp sobre CPU.

b10950

Release b10950 de llama.cpp introduce un cambio en ggml-cuda que hace fallback a F32 en dispositivos sin aceleración hardware de BF16, aplicable a GPUs Nvidia a partir de arquitectura AMPERE y AMD a partir de RDNA3 o CDNA. El PR fue coautorizado por Johannes Gäßler.

Por qué importa: Afecta directamente a la elección de precisión y al rendimiento esperado al servir modelos cuantizados en distintos tipos de GPU, algo clave para quien dimensiona infraestructura de inference.