Sage-A1.5 en una tarjeta de 24 GB: 136 tokens/s y un modo de verificación que dobla el trabajo en preguntas fáciles

35B parámetros en disco, unos 3B trabajando en cada palabra. Esa diferencia es la razón por la que Sage-A1.5, un agente de investigación abierto del Shanghai AI Laboratory, entra en una sola tarjeta gaming. Ejecutamos el fichero comprimido de los propios autores en una RTX 4090, una tarjeta gaming de 24 GB, en nuestra nube (InferenceKey Cloud), con software abierto de serie. Su maquinaria de agente funcionó: repartió tareas, pidió a nuestro código que buscara y respondió. Escribió unos 136 tokens por segundo, una respuesta larga en 11 segundos, y acertó nuestra única pregunta de investigación en tres partes en las tres ejecuciones de prueba. Su nuevo Verification Mode, que le hace revisar su propio trabajo, dio las mismas respuestas correctas en preguntas fáciles, pero tardó 2,2 veces más y gastó el doble de tokens. El modelo corre en un worker de GPU que controlas tú, y las herramientas corren en tu propio código. Deja el modo de verificación apagado para consultas sencillas y pruébalo con tus casos difíciles.

La imagen muestra una pregunta hecha dos veces en la misma tarjeta: en qué ciudad se descubrió el hafnio y quién lo descubrió. Las dos ejecuciones acertaron, y la que tenía el modo encendido siguió comprobando datos que ya había leído.

35B parámetros, 3B despiertos en cada palabra

Sage-A1.5 es grande en disco y pequeño en movimiento, y por eso una tarjeta gaming puede servirlo. Es un modelo mixture-of-experts. Imagina un equipo de 256 especialistas, más un generalista que siempre está en la sala. Por cada palabra que escribe, el modelo consulta a 8 especialistas. El resto espera. Así que de 35B parámetros solo unos 3B trabajan en cada paso, según la página del proyecto. La velocidad depende de los 3B, y la factura de memoria, de los 35B.

El modelo está reentrenado a partir de otros dos: el modelo abierto de 35B del equipo de Qwen y Agents-A1, el agente anterior del propio laboratorio, publicado en junio. El paper, de Wenjie Lou y 98 coautores, salió el 20 de octubre. El modelo completo y el fichero comprimido, de unos 22 GB, son Apache-2.0: libres para uso comercial y descargables sin formulario. Un pequeño fichero extra permite al modelo leer imágenes, y dos modos que activas tú lo convierten en un agente:

• Agentic Orchestration. Le das al modelo una herramienta que reparte tareas. El modelo divide entonces una pregunta en tareas y entrega cada una a un subagente, que busca y lee por su cuenta y vuelve con lo que ha encontrado. Es un investigador principal que manda a tres ayudantes a la biblioteca a la vez.
• Verification Mode. Una línea añadida a las instrucciones del modelo le dice que revise su propio trabajo antes de responder. Los autores dicen que no hace falta instalar nada más.

Las puntuaciones de los autores son del modelo sin comprimir y no las reprodujimos

En BrowseComp, que pide datos difíciles de encontrar en la web, los autores dan 81,7 sobre 100, frente a 91,2 de Kimi-K3, el mejor modelo de su tabla. En una prueba aparte, con el modo encendido y apagado sobre las 1.266 preguntas de BrowseComp, Verification Mode subió la puntuación del 72,5 % al 82,9 %. No sabemos si el 81,7 ya incluye esa mejora. Sus otras puntuaciones están en el apéndice.

Nuestra prueba: una RTX 4090, el fichero de los autores, nuestras preguntas

Primero el límite: un puñado de preguntas fáciles, respaldadas por Wikipedia, en una tarjeta, con un agente cada vez. Eso comprueba la maquinaria (llamadas a herramientas, reparto de tareas, respuestas que vuelven), no la amplitud de su investigación.

Servimos el fichero comprimido de los autores con llama.cpp, el software abierto que ejecuta modelos en una sola máquina, en una RTX 4090 de nuestra nube. Usamos los ajustes recomendados por los autores. Todas las peticiones pasaron por nuestra plataforma, como las haría una aplicación, y además comprobamos la velocidad contra llama.cpp directamente.

Las preguntas eran nuestras. Cada una necesitaba unos pocos datos de Wikipedia: quién descubrió el renio y dónde, a qué ciudad debe su nombre el hafnio, cuándo se encontró el tecnecio. El modelo buscó y leyó páginas en vivo a través de dos herramientas que escribimos nosotros. Para la orquestación hicimos una sola pregunta, ejecutada tres veces: cuántos años pasaron entre los descubrimientos de tres elementos, de modo que cada subagente se encargó de uno.

Unos 136 tokens por segundo y una pregunta de investigación correcta en las tres ejecuciones

En una RTX 4090 el modelo escribió unos 136 tokens por segundo con una petición, y el primer token llegó en aproximadamente un cuarto de segundo. Pasar por nuestra plataforma no añadió ningún retraso medible: llama.cpp solo dio la misma velocidad. Una respuesta de 1.489 tokens tardó unos 11 segundos.

También lee rápido los prompts largos. Escondimos una etiqueta inventada, 7342-ORCHID, dentro de un prompt de 92.662 tokens, más o menos la longitud de una novela. El modelo lo leyó entero en 31 segundos y encontró la etiqueta.

La pregunta de investigación volvió correcta todas las veces. En cada una de las tres ejecuciones de prueba, el modelo repartió tres tareas a la vez, una por elemento. Los tres subagentes buscaron en Wikipedia y devolvieron lo que encontraron. Después el modelo principal escribió la respuesta: hafnio en 1923, renio en 1925, tecnecio en 1937, 14 años del primero al último. Todas las llamadas a herramientas salieron exactamente en el formato que nuestro código necesitaba para ejecutarlas. Una prueba más sencilla, con una sola llamada de búsqueda, salió limpia 3 de 3 veces, en menos de un segundo cada una.

El tiempo depende de si los subagentes corren en paralelo, y el valor por defecto de nuestra plataforma los pone en cola. Tras un despliegue, la plataforma manda al modelo una petición cada vez, así que los tres subagentes esperaron su turno y la ejecución tardó 72,0 segundos. Una llamada a la API subió el límite a dos, y entonces las ejecuciones tardaron 50 y 56 segundos. Estado: el valor por defecto sigue siendo uno, y la llamada está en el apéndice.

La parte de visión también funciona. Le enseñamos la gráfica de benchmarks de los propios autores y le pedimos un valor. Leyó 80,0 en la barra correcta, y 50,0 como el mejor de los modelos más grandes, las dos cosas bien.

La pega es cuánto piensa. Este modelo razona largo y tendido antes de responder. Una definición de dos frases tardó 14,4 segundos, porque antes razonó durante 1.905 tokens. Incluso 17 x 23 le costó 336 tokens de razonamiento. A 136 tokens por segundo eso vale para una tarea de investigación, y es lento para un chat.

Verification Mode dobló el trabajo en preguntas fáciles y no cambió ninguna respuesta

En nuestras preguntas fáciles, Verification Mode no aportó nada que pudiéramos medir. Las 12 respuestas fueron correctas con el modo apagado y con el modo encendido.

El trabajo extra fue sobre todo repetición. Con el modo encendido, el razonamiento se llenó de turnos de "Let me verify" cuando los datos ya estaban confirmados. La diferencia varió: en la otra ejecución del hafnio, el modo encendido hizo una llamada a herramientas menos que el apagado. Una ejecución tardó 52,7 segundos porque una búsqueda en Wikipedia agotó el tiempo de espera y el modelo lo volvió a intentar.

Eso no contradice a los autores. Su mejora llegó en BrowseComp, donde los datos son difíciles de encontrar y es habitual que la primera pista sea falsa.

Qué GPU: una tarjeta real de 24 GB a plena velocidad, y por debajo una quinta parte de la velocidad o menos

La tarjeta más pequeña que movió Sage-A1.5 a plena velocidad fue una RTX 4090 real de 24 GB. Con los ajustes de nuestro ejemplo, espacio para 32.768 tokens de conversación y dos peticiones a la vez, usó 21,3 de los 23,5 GiB de la tarjeta. La configuración de la propia ficha del modelo, 64K tokens con visión, llegó a un pico de 23,1 GiB. Con 128K tokens, solo texto, el pico fue de 23,4 GiB, con la tarjeta casi llena. Todas entraron, sin perder velocidad.

Por debajo de 24 GB, el modelo solo funciona si parte de él pasa a la memoria principal del ordenador. Llama.cpp puede aparcar ahí algunos especialistas y dejar que los ejecute el procesador, que es mucho más lento. Simulamos tarjetas más pequeñas en la misma 4090, sacando especialistas hasta que la memoria de la tarjeta se quedó por debajo de cada límite.

• 16 GB simulados: 14,4 GiB en la tarjeta, unas 5,6 veces más lento, y la pregunta de investigación siguió saliendo bien, en 98 segundos.
• 12 GB simulados: 10,8 GiB en la tarjeta, y la pregunta salió bien en 93 segundos.
• 8 GB simulados: 3,0 GiB con todos los especialistas en memoria principal. Una de dos ejecuciones de investigación agotó su límite de 12 pasos tras 270 segundos sin respuesta. El reintento acertó.
• Sin probar: tarjetas reales de 16 y 12 GB, la RTX 3090, tarjetas de 32 GB, el modelo sin comprimir.

Las velocidades simuladas dependen del procesador y la memoria del ordenador, así que tómalas como una tendencia, no como una promesa. Los ajustes más pequeños también necesitan memoria principal libre para los especialistas aparcados, hasta unos 17 GB cuando se mueven todos.

En InferenceKey: listo en 104 segundos, tras un arreglo en el comando de la ficha del modelo

Un modelo de agente de 35B no debería necesitar un motor a medida, y este no lo necesitó. De la llamada de despliegue a estar sirviendo pasaron 104,1 segundos, con la versión de llama.cpp que nuestra plataforma ya trae: descargar el fichero de 21,7 GB, cargarlo, responder. Nuestra plataforma ejecuta un modelo en un worker, una máquina con GPU propia o alquilada que conectas a ella, y su llama.cpp por defecto cargó Sage-A1.5 sin cambios. La primera vez en una máquina nueva, además hay que compilar llama.cpp para la tarjeta, y eso tardó diez minutos y medio. Después, un reinicio tarda de 4 a 7 segundos.

El único problema con el que te vas a encontrar está en la propia ficha del modelo. Su comando de llama.cpp usa un ajuste de razonamiento llamado deepthink, que llama.cpp no tiene. El servidor se cierra al arrancar con "Unknown reasoning format: deepthink". Lo comprobamos también en una versión mucho más reciente de llama.cpp, y ahí tampoco existe. El arreglo es escribir deepseek en su lugar. Estado: arreglado en nuestro ejemplo, sigue en la ficha de los autores.

Un segundo hueco es nuestro. Los autores activan Verification Mode con un ajuste que nuestra plataforma todavía no le pasa al modelo. Nuestro ejemplo añade en su lugar la misma línea de activación a las instrucciones del modelo. Comprobamos que el modelo ve exactamente el mismo prompt por las dos vías. Estado: abierto por nuestra parte, resuelto con un apaño en el ejemplo.

¿Merece la pena probarlo? Sí, en una tarjeta de 24 GB: la maquinaria de agente funcionó

• Si quieres un agente que busque, lea e informe en tu propio hardware, pruébalo.
• Si te importa la precisión en preguntas difíciles, prueba Verification Mode con tus propios casos difíciles.
• Si necesitas respuestas rápidas de chat, busca otra cosa. Piensa durante cientos o miles de tokens antes de dar respuestas cortas.
• Si tu tarjeta tiene 16 GB o menos, cuenta con una fracción de la velocidad, y solo con mucha memoria principal.

Para hacerle a Sage-A1.5 la misma pregunta de investigación en tu propia tarjeta, con subagentes y con Verification Mode apagado y encendido, ejecuta python main.py desde el ejemplo del SDK de Sage-A1.5. Necesita un proyecto de InferenceKey con un token del SDK y una API key, y un worker NVIDIA privado con 24 GB o más. Al terminar, borra el despliegue.

llama-server -hf InternScience/Sage-A1.5-Q4_K_M-GGUF --hf-file Sage-A1.5-Q4_K_M.gguf \
  --no-mmproj --alias sage-a1.5 -ngl 99 -fa on -c 32768 -np 2 --kv-unified \
  --jinja --reasoning-format deepseek \
  --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0 --presence-penalty 1.5

system = "You are a careful research assistant." + "\n\nVerification protocol: enabled"