11/8/26

Libro Electrónico Boox Go Gen II Lumi

 


El Libro Electrónico Boox Go Gen II Lumi es un lector electrónico de pantalla eInk monocroma de 10,3 pulgadas y resolución de 300 ppp. Utiliza Android 15 como sistema operativo, lo que permite instalar aplicaciones de terceros desde Google Play, incluyendo distintas plataformas de lectura y productividad.

Es compatible con una amplia variedad de formatos de documentos, cómics, imágenes y audio, entre ellos PDF, EPUB, MOBI, CBR, CBZ, DOCX y MP3. La versión Lumi incorpora retroiluminación ajustable en tonos cálidos y fríos.

El dispositivo cuenta con 4 GB de RAM, procesador Snapdragon 750G y 64 GB de almacenamiento interno no ampliable. Su rendimiento general es suficiente para las tareas habituales de lectura y uso de aplicaciones. Puede aparecer algo de ghosting al cambiar de página, aunque este efecto puede reducirse mediante ajustes de refresco.

En cuanto al diseño, tiene un grosor de 4,8 mm y un peso de 364 gramos. Incluye conectividad Wi-Fi, Bluetooth 5.1, puerto USB-C, certificación IPX8 de resistencia al agua, altavoces, micrófonos y compatibilidad con USB OTG. 

El lápiz incluido permite escribir, tomar notas y realizar anotaciones en documentos. Ofrece sensibilidad a la presión, aunque presenta una ligera latencia que puede afectar la sensación de escritura en tareas que requieren rapidez.  

Es caro, pues ronda los 450€.

Más información en este enlace.



9/8/26

Audiblez

 


Audiblez, de Claudio Santini, es una aplicación que permite convertir textos en audiolibros. Está basado en el software Kokoro, un TTS (Text-to-Speach), un modelo de conversión de 82 millones de parámetros que da resultados más que aceptables.

Audiblez funciona en Phyton 3.12.

Soporta varios idiomas entre los que se encuentra el español.

El código y las instrucciones puede verse en Github

También soporta el chino, como se ve en este video (¡otra cosas, es entenderlo!)





7/8/26

Titâneo

 


Titâneo, de Eduardo Kac, es un poema digital en portugués publicado en el año 2021.

En él, se deslizan versos en scroll automático que se van generando de manera automática. Le elección estética, con colores chillones y agresivos, más la animación basada en una vibración de las letras como si hubiese interferencias en la visualización, no facilita la lectura.

Puede leerse desde este enlace.







5/8/26

Viaje de Madrid a Manila en 1844

 


Viaje de Madrid a Manila en 1844, del historiador Álvaro Ruiz Cuevas, es una narración digital gráfica basada en el viaje expedicionario que en 1844 realizó el coronel Eusebio de Santos a las Filipinas, con el objetivo de encontrar una vía raóida hacia el este, una vez que, con la independencia de México, se había perdido la continuidad del galeón de Manila.

El diario de aquel viaje fue publicado bajo el largo título de Diario del viage desde Madrid a Manila, en las islas Filipinas, por la via del itsmo [sic] de Suez, que de órden del gobierno de S.M. hizo en principios de 1844 el coronel Don Eusebio de Santos.

La aplicación digiral de Álvaro Ruiz permite seguir ese viaje sobre mapas interactivos que se conjuntan con breves fragmentos del texto indicando los hechos principales ocurridos en cada localización. A medida que hacemos scroll, el mapa va cambiando y en la columna derecha se van leyendo los hechos acontecidos en esa posición geográfica.

Puede leerse desde este enlace.

En la web del propio autor puede leerse el diario original.

Eusebio de Santos ingresó en la Academia de Ingenieros de Guadalajara el 22 de noviembre de 1828, saliendo de la misma como teniente. Fue destinado al Regimiento de Zapadores Minadores, y tomó parte en la Primera Guerra Carlista, integrado en el Ejército del Norte. Obtuvo dos Cruces de San Fernando de 1ª clase. En 1843 fue destinado a las islas Filipinas como comandante de Ultramar. Fue ascendido a coronel del Ejército el 31 de diciembre de 1845. Desempeñó trabajos en diferentes provincias del archipiélago, y en 1848 pasó con licencia temporal a China. En 1852 fue nombrado jefe de la Brigada Topográfica de Ingenieros. En 1855 estuvo destinado de nuevo en el Regimiento del Arma. El viaje a Filipinas a través del canal de Suez fue llevado a cabo en 1844, pero el diario de tal aventura se publicó en 1851.





4/8/26

Nvidia Nemotron 3 Super: qué problema resuelve y cómo funciona

 


Hace unas semanas, NVIDIA presentó su nuevo Nemotron 3 Super, una familia de modelos de IA abiertos, multimodales y diseñados para permitir desarrollos de terceros.

Durante los últimos dos años, buena parte de la conversación sobre inteligencia artificial ha girado en torno a los chatbots: le escribes una pregunta, el modelo responde, fin de la interacción. Sin embargo las nuevas aplicaciones y las empresas necesitan sistemas multi-agente donde varios modelos o instancias de un mismo modelo que colaboran, se pasan información entre sí, ejecutan herramientas externas, revisan código, consultan documentos y repiten ese ciclo decenas o cientos de veces antes de entregar un resultado final. Ese tipo de flujo —pensemos en un agente que revisa un repositorio de software completo, o en un sistema que hace triaje de alertas de ciberseguridad las 24 horas— no se parece en nada a un chat típico. Genera muchísimo más texto de entrada y salida en cada ciclo. De hecho, según cifras difundidas por Nvidia en el lanzamiento de Nemotron 3, estos sistemas pueden llegar a producir "hasta quince veces el volumen de tokens que genera una conversación estándar".

¿Por qué importa esto? Porque cada token que un modelo procesa o genera cuesta dinero, energía y tiempo. Si el modelo  IA que funciona detrás del agente es uno de esos modelos "densos" —donde todos los parámetros se activan en cada cálculo—, multiplicar por quince el volumen de tokens multiplica también el costo de cómputo, la latencia y la dificultad de escalar el sistema en producción. Es lo que en la industria recibe el nombre de "impuesto al pensamiento": cuanto más piensa y opera un agente, más caro sale mantenerlo funcionando.

Ese es exactamente el problema que Nvidia dice haber abordado con Nemotron 3 Super, el modelo principal de su nueva familia Nemotron 3 (que además incluye las variantes Nano y Ultra), pensado específicamente para flujos de trabajo agénticos empresariales.

La solución que propone Nvidia es mezclar tres arquitecturas en un solo modelo.

Nemotron 3 Super tiene 120.000 millones de parámetros en total, pero —y esto es clave— solo activa unos 12.000 millones en cada pasada de cálculo. Ese diseño ya reduce significativamente el costo por token frente a un modelo denso equivalente. Además, combina tres filosofías arquitectónicas distintas que, hasta ahora, casi nunca convivían en un mismo sistema: un esqueleto híbrido Mamba-Transformer, un sistema de expertos llamado Latent Mixture-of-Experts (LatentMoE) y una técnica de generación acelerada llamada Multi-Token Prediction

¿Qué es Mamba-2 y por qué importa?

Para entender Mamba-2 conviene primero recordar cómo funciona un Transformer clásico, la arquitectura detrás de la mayoría de los modelos de lenguaje actuales (GPT, Claude, Gemini, Llama, etc.). Un Transformer usa un mecanismo llamado "atención", que compara cada token de una secuencia con todos los demás tokens anteriores para decidir en qué debe fijarse. Esto funciona muy bien, pero tiene un costo: a medida que la secuencia crece, la cantidad de comparaciones crece de forma cuadrática. Procesar una secuencia el doble de larga no cuesta el doble, sino mucho más que el doble. Además, el modelo tiene que guardar en memoria una especie de "resumen" de todos los tokens anteriores —lo que se llama la caché de clave-valor o KV cache—, y esa memoria también crece sin parar a medida que la conversación o el documento se alargan. Por eso los modelos basados solo en Transformers empiezan a volverse lentos y a consumir muchísima memoria cuando se les pide procesar ventanas de contexto enormes, como repasar un repositorio de código completo o cientos de páginas de informes financieros.

Mamba (y su evolución, Mamba-2) nace de una familia distinta de arquitecturas conocida como "modelos de espacio de estados" (state-space models). En lugar de comparar cada token con todos los anteriores, Mamba procesa la secuencia de forma más parecida a como lo haría una memoria que se va actualizando token a token, con un costo que crece de forma lineal —y no cuadrática— a medida que la secuencia se alarga. En términos prácticos, esto significa que Mamba puede recorrer secuencias muchísimo más largas sin que el consumo de memoria y de tiempo se dispare. La contrapartida es que los modelos de espacio de estados puros tienden a ser menos precisos que los Transformers a la hora de recuperar un dato muy específico que quedó "enterrado" muchos pasos atrás en la secuencia; son buenos siguiendo el flujo general, pero les cuesta más el equivalente a "encontrar la aguja en el pajar".

Aquí es donde entra la idea "híbrida" de Nemotron 3 Super. En vez de elegir entre Mamba o Transformer, el modelo alterna capas de ambos tipos. La mayor parte del procesamiento corre sobre capas Mamba-2, que actúan como una especie de autopista rápida y liviana en memoria. Pero, en puntos estratégicos, se insertan capas de atención tipo Transformer que funcionan como "anclas globales": momentos en los que el modelo sí hace una búsqueda precisa hacia atrás en toda la secuencia para recuperar un dato exacto, por ejemplo una variable definida al inicio de un archivo de código o una cifra específica mencionada al comienzo de un informe. Esta combinación es lo que le permite sostener una ventana de contexto de un millón de tokens sin que la memoria colapse, algo que un Transformer puro difícilmente podría hacer de forma eficiente.

¿Qué es LatentMoE?

El segundo concepto necesario es el de Mixture-of-Experts (MoE), una técnica que ya usan varios modelos grandes actuales. La idea de base es simple: en lugar de tener un único bloque de parámetros gigante que procesa todo, el modelo se divide en varios sub-modelos más pequeños llamados "expertos", cada uno especializado implícitamente en distintos tipos de patrones (por ejemplo, uno podría evolucionar mejor en sintaxis de código, otro en razonamiento matemático, otro en lenguaje conversacional). Para cada token, un mecanismo de enrutamiento decide a cuáles expertos enviarlo, y solo esos expertos se activan. Así se puede tener un modelo con muchísimos parámetros totales, pero sin que todos se usen en cada cálculo, lo cual reduce el costo por token.

El problema del MoE tradicional es que ese enrutamiento se hace en el espacio "completo" de representación interna del modelo, que suele tener miles de dimensiones. Enrutar tokens en ese espacio tan grande, hacia cada vez más expertos, se vuelve un cuello de botella computacional a medida que el modelo escala: comparar un token con la firma de cada experto en un espacio de altísima dimensión es costoso.

LatentMoE, la variante que introduce Nemotron 3 Super, ataca ese cuello de botella con un paso adicional: antes de decidir a qué expertos enviar un token, el modelo lo proyecta primero a un espacio "latente" mucho más comprimido —una especie de versión resumida del token— y hace el enrutamiento sobre esa versión comprimida. Esto reduce drásticamente el costo de la operación de enrutamiento y, como consecuencia, permite que el modelo consulte hasta cuatro veces más expertos por el mismo costo computacional que tendría un MoE tradicional con menos expertos. En la práctica, esa mayor variedad de "especialistas" disponibles es justo lo que necesita un agente que, dentro de un mismo turno de conversación, tiene que , por ejemplo, saltar entre escribir código Python, generar una consulta SQL y razonar en lenguaje natural. Cuantos más expertos matizados haya disponibles sin encarecer el cálculo, más fino puede ser el modelo en cada uno de esos saltos.

Cómo se combinan las piezas (y una tercera técnica: Multi-Token Prediction)

Nemotron 3 Super no se queda solo con el backbone híbrido Mamba-Transformer y con LatentMoE. Suma una tercera técnica, Multi-Token Prediction (MTP). Un modelo de lenguaje estándar genera texto prediciendo un único token a la vez, uno tras otro. MTP, en cambio, entrena al modelo para predecir varios tokens futuros de una sola vez, lo que en la práctica funciona como un "modelo borrador" incorporado: el sistema propone varios tokens por adelantado y luego los verifica, en vez de generarlos uno por uno de manera estrictamente secuencial. Esta técnica, conocida en general como decodificación especulativa, permite acelerar de forma considerable la generación de texto, especialmente en tareas de salida muy estructurada como escribir código o llamar a herramientas.

A esto se suma una decisión de infraestructura poco habitual: el entrenamiento de Nemotron 3 Super se ha realizado de forma nativa en NVFP4, un formato numérico de precisión de solo 4 bits diseñado para la arquitectura Blackwell de Nvidia, la generación de GPU más reciente de la compañía. Entrenar directamente en esa precisión reducida —en lugar de entrenar en alta precisión y luego comprimir el modelo después— permite que, al desplegarlo sobre GPU Blackwell, la inferencia sea hasta cuatro veces más rápida que la de modelos de 8 bits corriendo sobre la generación anterior (Hopper), sin una pérdida medible de precisión. El modelo puede correr en configuraciones variadas, desde una sola GPU B200 o GB200 hasta combinaciones de H100, H200 o A100, lo que le da flexibilidad a equipos con distinta infraestructura disponible.

Rendimiento

Los números que ha publicado Nvidia muestran un modelo con fortalezas muy marcadas en algunas áreas y más discreto en otras. Lidera el DeepResearch Bench, la prueba que mide la capacidad de investigar en profundidad sobre grandes volúmenes de documentos, y también domina claramente en tareas de contexto largo. Pero en benchmarks de razonamiento general puro, el panorama es más parejo o incluso desfavorable frente a Qwen3.5-122B. También, en tareas de ingeniería de software medidas con SWE-Bench, Qwen queda por delante de Nemotron, En generación de código, en cambio, Nemotron gana a Qwen en LiveCodeBench.  

La licencia: uso comercial permitido, con dos líneas rojas

El modelo se distribuye bajo el Nvidia Open Model License Agreement,  que permite el uso comercial de forma bastante amplia. Se pueden vender y distribuir productos construidos sobre el modelo bajo una licencia perpetua y libre de royalties. Nvidia no reclama ningún derecho sobre los resultados que genera el modelo, y es posible crear y quedarse con la propiedad de versiones ajustadas (fine-tuned), siempre que se incluya una nota de referencia a Nvidia.

Sin embargo, esta licencia no es tan permisiva como las que proponen MIT o Apache 2.0, porque contempla dos condiciones que la dan por terminada automáticamente. La primera es que el usuario elimine o eluda las salvaguardas de seguridad del modelo sin reemplazarlas por algo equivalente. La segunda es que el usuario inicie una demanda de propiedad intelectual contra Nvidia alegando que el modelo infringe sus derechos; en ese caso, pierde el derecho a seguir usando el modelo. Es una manera de proteger tanto el uso responsable del sistema como a la propia empresa frente a litigios.


En fin, por ahora hay una buena dosis de mrketing y deberemos ver, en los proximos meses, si esta novedosas aruitectura IA permite generar aplicaciones y agentes que realmente ofrezcan ventajas competitivas claras.




1/8/26

El genoma de las palabras

 


El genoma de las palabras (2015), de Félix Remírez aplica el concepto de autómata celular a un mundo de palabras o letras, en vez de píxeles.

Los autómatas celulares son modelos matemáticos y computacionales diseñados para estudiar cómo surgen comportamientos complejos a partir de reglas simples aplicadas de manera local. Fueron formalizados a mediados del siglo XX por el matemático John von Neumann y el lógico Stanisław Ulam, quienes buscaban comprender los procesos de autorreplicación y la organización de sistemas biológicos mediante estructuras discretas. Un autómata celular consiste, en términos generales, en una cuadrícula (que puede ser unidimensional, bidimensional o de más dimensiones) compuesta por celdas. Cada celda puede encontrarse en uno de un número finito de estados posibles. El sistema evoluciona en pasos de tiempo discretos, y en cada paso el estado de cada celda se actualiza simultáneamente según una regla fija que depende de su estado actual y del estado de las celdas vecinas. Estas reglas suelen ser simples, pero al aplicarse repetidamente pueden generar patrones sorprendentemente complejos.

Uno de los ejemplos más conocidos es el Juego de la Vida, creado por el matemático británico John Horton Conway en 1970.   Otro caso emblemático es la Regla 30, estudiada por Stephen Wolfram, quien exploró extensamente los autómatas celulares en su obra A New Kind of Science. La Regla 30 es un autómata celular unidimensional en el que cada celda puede estar en estado 0 o 1. A partir de una condición inicial simple, como una sola celda activa, la aplicación reiterada de la regla produce un patrón aparentemente caótico. Este comportamiento ha sido utilizado incluso para generar números pseudoaleatorios. Desde el punto de vista teórico, los autómatas celulares han sido estudiados como sistemas dinámicos discretos. Pueden clasificarse según su comportamiento global: algunos evolucionan hacia estados estables, otros presentan patrones periódicos, algunos generan estructuras complejas y otros muestran comportamientos caóticos. Además, ciertos autómatas celulares son capaces de realizar cómputo universal, lo que significa que pueden simular cualquier algoritmo computable, lo que los vincula conceptualmente con la teoría de la computación.

En este caso, no hay cuadrículas sino letras. Si una letra queda aislada, muere y nunca podrá formar una palabra, Si está completamente rodeada por todos lados de otras letras también muere por sobrepoblación. Si no, se reproduce y genera, poco a poco, palabras.

El lector puede usar semillas preprogramadas o introducir letras en los lugares que desee. Luego, al arrancar la evolución, verá si su patrón evoluciona y crea palabras o desaparece, verá si crea figuras alfabéticas o no, si vive o muere, si la civilización literaria se extingue o no.
Las letras nacen, viven, se reproducen y mueren en función de su entorno. Si están demasiado apretadas, mueren por falta de recursos para todas. Si están solas, mueren de soledad. Si están acompañadas justamente, viven y se reproducen. 
 
Programado en HTML5 y JavaScript, está diseñado para funciona en PC. Está probado en los navegadores Edge y Chrome. 

Puede accederse a la obra desde este enlace.