El radar

The AI graveyard: a running list of projects and startups that didn’t make it

Recopilación de productos y startups de IA que cerraron, pivotaron o no cumplieron expectativas, con casos como Relay (automatización de workflows con agentes, cerrada en agosto), Character.ai (quiebra cinco años después de lanzarse), el rediseño revertido de ChatGPT como "super app", el cierre de ChatGPT Atlas, Operator y Sora, y los problemas de privacidad de Recall de Microsoft. Cita además que alrededor del 42% de las iniciativas de IA acaban abandonadas por sus empresas, según S&P Global Market Intelligence. El texto repasa también los retrasos de Siri AI, el cierre de Notion Mail, y los fiascos de hardware Humane AI Pin y Rabbit R1.

Por qué importa: Sirve como inventario de patrones de fracaso —productos stand-alone absorbidos por plataformas mayores, costes operativos insostenibles y falta de product-market fit— útil para calibrar el riesgo antes de construir herramientas propias sobre un producto de IA de terceros.

↳ Contexto: OpenAI hit the brakes. Now what? · ver hilo completo

Block’s new voice model sounds eerily human

Block ha publicado Dessa, un modelo de voz full-duplex desarrollado en su laboratorio de investigación que se ejecuta localmente y se entrenó íntegramente con habla humana (sin texto en el pipeline), generando expresiones como risas, pausas y llanto. La compañía afirma que funciona en GPUs de consumo, como un MacBook M4 Max o superior, y que su conocimiento proviene de los propios datos conversacionales. No hay acceso público: Block ha abierto una convocatoria para que investigadores de seguridad lo prueben. IMPORTA: Un modelo de voz full-duplex que corre en hardware de consumo y prescinde del texto como intermediario marca una vía distinta a los pipelines speech-to-text + LLM + TTS, relevante para quien diseñe agentes de voz o evalúe latencia y coste de inferencia local.

Por qué importa: Un modelo de voz full-duplex que corre en hardware de consumo y prescinde del texto como intermediario marca una vía distinta a los pipelines speech-to-text + LLM + TTS, relevante para quien diseñe agentes de voz o evalúe latencia y coste de inferencia local.

Forced to pick, Grok’s AI model chooses Republicans. OpenAI’s picks Democrats.

Un estudio de Convovo, dirigido por el profesor de Cornell Tapan Parikh, consultó vía API a Grok 4.7 y GPT-6.1 Sol sobre a quién votar en casi 500 contiendas de las midterms: Grok recomendó al candidato republicano en el 92% de sus respuestas y GPT al demócrata en el 97%, coincidiendo menos del 10% de las veces. Las apps de consumo se negaron a responder y OpenAI señala que el estudio testeó la API con un prompt que exigía una recomendación explícita. Con la búsqueda web desactivada, el sesgo de GPT se mantuvo (eligió al demócrata en 24 de 30 contiendas), mientras que el de Grok desapareció y se negó a elegir en 27 de 30, lo que sugiere que su inclinación depende de los términos y fuentes que busca; además, cada petición a la API de Grok incluía ~1.240 tokens de input no visibles para los investigadores.

Por qué importa: Muestra que el sesgo de un LLM puede venir de los weights o del patrón de búsqueda y fuentes que consulta al hacer RAG, y que un proveedor puede inyectar instrucciones ocultas en la API, algo que cualquiera que construya agentes o pipelines de retrieval sobre modelos de terceros debería auditar.

[AINews] Kimi 3.1 Pro 104BA-2.8T: Fable-5.1-Class Open Weights narrows Closed-AI lead to 1 month... and Pro Highspeed API with 2-3× speed

Moonshot lanzó Kimi K3.1 Pro, un MoE multimodal de 2.8 billones de parámetros totales con 104B activos y ventana de contexto de 1 millón de tokens, resultado de un post-training a gran escala con RL conjunto en cientos de dominios. Según Artificial Analysis quedó cuarto en su Intelligence Index con 55 puntos (tras Opus 5.5 con 58, Sonnet 5.5 y Muse Wonder Full con 56), con mejoras concentradas en capacidades agénticas, y en Code Arena alcanzó el puesto #8 con 1.692 puntos. La API ya está disponible en versiones Standard y Highspeed (2-3× más rápida pero al doble de coste), mientras que los pesos abiertos están prometidos para el 4 de noviembre de 2026; de publicarse, la brecha del índice entre modelos abiertos y propietarios se reduciría de 12 a tres puntos. Para quien sirve o evalúa modelos, marca un techo abierto cercano al frontier, pero también avisa de que 104B activos no

Por qué importa: Para quien sirve o evalúa modelos, marca un techo abierto cercano al frontier, pero también avisa de que 104B activos no equivalen a un denso de ese tamaño: el pool de expertos implica TBs de memoria y coste de serving real antes de hablar de despliegue "local".

Building Reasoning Models from the Ground Up: A Full Video Course

Sebastian Raschka publica un curso en vídeo de ocho lecciones (unas 11 horas) que acompañan a su libro "Build a Reasoning Model (From Scratch)", implementando desde cero en Python y PyTorch técnicas de evaluación, inference scaling, reinforcement learning con verifiable rewards y distillation sobre un modelo Qwen3 0.6B preentrenado. El material incluye un verificador de respuestas matemáticas para MATH-500 que después reutiliza como señal de recompensa para RLVR, y detalla implementación de KV cache, torch.compile y generación en streaming. Esto continúa el contenido que ya cubrimos hace unos días en "Reasoning Models From Scratch: Code Setup", ampliando ahora con las lecturas completas y los temas de inferencia y RL. IMPORTA: Para quien quiera entender por dentro cómo se construye y evalúa un reasoning model —el "motor" que hoy se orquesta dentro de un agent harness— con código ejecutable en local y una GPU modesta, en lugar de tratarlo como una caja negra.

Por qué importa: Para quien quiera entender por dentro cómo se construye y evalúa un reasoning model —el "motor" que hoy se orquesta dentro de un agent harness— con código ejecutable en local y una GPU modesta, en lugar de tratarlo como una caja negra.

↳ Contexto: Reasoning Models From Scratch: Code Setup · ver hilo completo

b11883

Commit en llama.cpp que corrige la cuantización de tensores 4D en llama-quant: nrows_total se calculaba como ne[1]*ne[2], por lo que solo se cuantizaban las primeras ne[2] slices y se descartaban el resto de filas; ahora se usa ggml_nrows(tensor) para contar todas, incluida ne[3]. Además, la detección de tensores de expertos MoE en la ruta MXFP4_MOE pasa de basarse en ne[2] > 1 (incorrecto para tensores no-expertos con 3 o más dimensiones, como proyecciones MLA o kernels conv 4D) a usar el nombre del tensor, ya que los usados por GGML_OP_MUL_MAT_ID se llaman *_exps o *_chexps, eliminando el caso especial de BailingMoE3. También ajusta el tamaño esperado del imatrix a ne[0]*ne[2]*ne[3].

Por qué importa: Afecta directamente a la corrección de modelos cuantizados con tensores 4D y arquitecturas MoE, un fallo que podía producir modelos mal cuantizados sin aviso evidente.

b11880

Nuevo release b11880 de llama.cpp que incorpora el cambio #31044 en `tools`: el merge de GGUF ahora rechaza tensor data truncada. Se trata de una corrección de robustez en la herramienta de fusión de ficheros GGUF, no de un cambio en el motor de inferencia. El release llega pocos días después de b11370, dentro del ritmo habitual de publicaciones del repositorio. IMPORTA: Si generas o fusionas GGUF en pipelines propios, este fix evita que un fichero truncado pase el merge y produzca modelos corruptos que fallen más tarde en inference.

Por qué importa: Si generas o fusionas GGUF en pipelines propios, este fix evita que un fichero truncado pase el merge y produzca modelos corruptos que fallen más tarde en inference.

↳ Contexto: b11370 · ver hilo completo

b11879

Commit en llama.cpp que fusiona los matmuls gate y up de una FFN densa en un solo launch de mul_mat_q durante el prompt processing, aplicando la GLU en el write-back. La fusión en MMQ requiere filas gate/up interleaved, se activa solo con tiling eficiente y sin fallback, y se lanza a través del kernel stream-k con un bloque por tile. Añade tests con un caso de gate/up MMQ fusionado por tipo y operación GLU. IMPORTA: Reduce launches de kernel y tráfico de memoria en el prompt processing en CUDA, un tipo de optimización de inferencia que conviene conocer si se ajusta rendimiento de serving de LLMs en GPU.

Por qué importa: Reduce launches de kernel y tráfico de memoria en el prompt processing en CUDA, un tipo de optimización de inferencia que conviene conocer si se ajusta rendimiento de serving de LLMs en GPU.