Presentamos AutoThink: cómo mejorar el rendimiento de los LLM locales con razonamiento adaptativo

• AutoThink puede mejorar el rendimiento de los modelos de lenguaje grandes (LLM) en entornos locales mediante tecnología de razonamiento adaptativo
• Este proyecto permite usar LLM de alto rendimiento incluso en entornos con recursos de GPU limitados
• Ofrece ventajas en velocidad y calidad de respuesta frente a la operación tradicional de LLM
• En comparación con soluciones de LLM en la nube como la API de OpenAI, permite proteger la privacidad y reducir costos
• Es útil para desarrolladores e investigadores de IA al desplegar y experimentar con sus propios LLM

---

Introducción al proyecto open source AutoThink

AutoThink es un framework de razonamiento adaptativo diseñado para maximizar el rendimiento de los modelos de lenguaje grandes (LLM) que se ejecutan en entornos locales. Sus principales características y ventajas competitivas son las siguientes.

Por qué AutoThink es importante

• La mayoría de las soluciones para potenciar LLM dependen de nubes externas, como la API de OpenAI o HuggingFace Spaces
• Los servicios de LLM en la nube presentan problemas de exposición de datos personales, costos y dependencia de la red
• AutoThink ayuda a asegurar la mejor calidad de respuesta posible mediante una estructura de inferencia optimizada, incluso en GPU o PC de bajos recursos
• Su estructura adaptativa analiza en tiempo real la situación operativa y la dificultad del problema, y selecciona dinámicamente la ruta y la estrategia de inferencia más adecuadas

Funciones y beneficios principales

• Introducción de razonamiento multietapa: aplica automáticamente varias etapas de inferencia según el problema de entrada, mejorando la calidad de respuesta incluso ante preguntas complejas
• Ajuste automático del rendimiento: ajusta el proceso de inferencia y los recursos según condiciones como el hardware disponible, el tiempo y la dificultad
• Experimentación rápida: está diseñado para que investigadores de IA y desarrolladores puedan probar LLM rápidamente en distintos entornos de infraestructura
• Diseño modular: permite separar la estrategia de inferencia del motor LLM, facilitando la integración con distintos motores

Ventajas frente a proyectos competidores

• Hasta ahora, lo habitual ha sido usar estructuras de inferencia fijas pensadas para la nube o hardware de gran escala
• AutoThink se distingue por su enfoque en el entorno local, su ligereza, el equilibrio entre precisión y velocidad, y su estructura adaptativa
• Destaca en la protección de datos propios e información sensible

Ejemplos de uso

• Es eficiente al adoptar un LLM para uso interno en entornos con recursos de GPU limitados, como startups pequeñas o laboratorios de investigación
• Permite aplicar rápidamente experimentos repetitivos y ciclos de mejora funcional

Conclusión

AutoThink es un innovador proyecto open source que ofrece una estructura ligera y flexible de optimización de inferencia, ayudando a desarrolladores y especialistas en IA a operar eficazmente sus propios modelos LLM en local. Supera los problemas de costos y privacidad de las soluciones de LLM basadas en la nube, y se presenta como una alternativa práctica para aumentar la aplicabilidad real en el trabajo en distintos entornos.

[GN⁺]

Comentario de Hacker News

• Aclaro que la motivación de AutoThink surgió al ver cómo los modelos de razonamiento existentes desperdician recursos de cómputo: era evidente la ineficiencia de gastar la misma “cantidad de tiempo pensando” en una pregunta facilísima como “¿cuánto es 2+2?” que en una demostración matemática compleja. Lo sorprendente fue que, al combinar dos cosas que estaba probando por separado —clasificación adaptativa (capaz de aprender nuevas categorías sin reentrenamiento) y Pivotal Token Search, liberado como open source en el paper de Microsoft sobre Phi-4— y aplicar además una asignación dinámica de presupuesto de tokens, la mejora de rendimiento fue mucho mayor de lo esperado. De hecho, el número promedio de tokens usados bajó, porque las consultas simples realmente terminan mucho más rápido y el cómputo extra solo se asigna a las consultas complejas. Algunos puntos técnicos: el steering vector es pequeño, menos de 1 MB por patrón, así que el overhead de memoria es casi nulo; el proceso de clasificación solo añade unos 10 ms de latencia, algo despreciable; y la elección de la target layer importa bastante (en la mayoría de los modelos, las capas intermedias 15~20 dieron los mejores resultados). Me gustaría recibir comentarios sobre esto: si alguien ha probado enfoques adaptativos parecidos, qué patrones de razonamiento serían más útiles para hacer steer, e ideas sobre cómo detectar automáticamente la target layer óptima. Si tienen dudas sobre la implementación o los resultados, con gusto las respondo

  • Ya no necesariamente es así. Pregunto si has usado Gemini 2.5 Pro: con preguntas simples casi no “piensa”, mientras que en preguntas de programación escribe respuestas largas como un ensayo de lógica. o3 parece comportarse parecido

  • ¡Felicidades! Todo intento de hacer más eficientes los LLM es más que bienvenido. Hasta ahora yo había hecho una optimización perezosa: en una Mac Mini M4 corro solo consultas simples con modelos en MLX, y las complejas las mando a una Nvidia 4090. La eficiencia del M4 comparada con Nvidia es realmente sorprendente. Creo que Apple va por el camino correcto con MLX. Pienso leer más sobre AutoThink e integrarlo a mi flujo de trabajo personal

  • Creo que valdría la pena probar insertar después del prompt del usuario una “respuesta de un modelo sin razonamiento”, por ejemplo: “Lo siguiente es lo que pensó un modelo sin razonamiento: ... ¿es esto lo que quiere el usuario?”. Cuando la versión no razonadora sea suficiente, el modelo de razonamiento también podría llegar más rápido a la respuesta

  • Incluso Claude Sonnet 3.5 (ni siquiera la versión más reciente 3.7 o 4) muestra diferencias claras en tiempo de procesamiento según la complejidad de la consulta: sí se ve un ajuste dinámico del tiempo de procesamiento

• Me pregunto cómo se puede clasificar una pregunta como “compleja” o “simple”. Una pregunta que parece simple también puede ser en realidad muy difícil. Por ejemplo, la solución entera de x³+y³+z³=42 fue un problema que consumió más de 100 años de recursos computacionales. O una ecuación como x/(y+z)+y/(z+x)+z/(x+y)=4 puede verse simple a primera vista, pero tiene soluciones gigantescas que requieren teoría de curvas elípticas. Ver enlace de la solución

  • Clasificar la dificultad de un problema es, en sí mismo, una técnica aparte: es una habilidad que puede aprenderse por separado de la resolución real. Por ejemplo, al ver la ecuación de arriba, uno debería notar enseguida tres dificultades: el dominio entero, tres variables y una ecuación cúbica. Cuando esos tres factores se juntan, la dificultad se dispara. Si fueran números reales o complejos, o hubiera menos variables, o el grado fuera más bajo, sería mucho más fácil. Claro, eso no significa que necesariamente sea difícil, pero sí que podría tratarse de un problema no resuelto. Yo no tengo la capacidad real para resolverlo, pero sí me he entrenado para saber dónde buscar información, así que puedo detectar de inmediato la sensación de “esto es muy difícil”. Pienso que un LLM también podría aprender este tipo de pistas y desarrollar la capacidad de clasificar la dificultad de un problema sin resolverlo realmente (o quizá ya la haya aprendido)

  • En este caso, la dificultad de la consulta se define con base en cuántos tokens consumió el modelo para producir una respuesta correcta en datasets con respuesta correcta conocida (GSM8k, etc.). El clasificador adaptativo se entrena con ese dataset y luego lo usa para clasificar durante la inferencia

• Cuando salió el toggle de extended thinking en Claude 3.7, yo también hice un POC parecido a autothink; de hecho, hasta se llama autothink
  github.com/NiloCK/autothink
  blog think-toggles-are-dumb
  Mi versión hace un primer pase donde el LLM califica la dificultad de la consulta con una puntuación de 0 a 100, y según esa puntuación asigna linealmente el presupuesto de pensamiento. Obviamente es más simple que el trabajo del OP, pero me da muchísimo gusto ver resultados cuantitativos: ¡está muy bien hecho!

• Me parece una optimización obvia y me sorprende que el cambio no haya ocurrido ya. Está muy bien explicado y muy impresionante que además lo hayas implementado

• En modelos de razonamiento como QwQ o Qwen 3, sinceramente no he dedicado mucho tiempo a mejorar resultados, solo he intentado restringir la salida de tokens de razonamiento con distintos prompts. Gemma 3 27B QAT no es un modelo de razonamiento, pero al usarlo en cadenas o rutas de LLM sigue instrucciones muy bien, así que puede servir para preclasificación u optimización de idioma y luego dejar el razonamiento real para una etapa posterior. También se puede intercalar una respuesta intermedia entre varias thinking tags. En experimentos con este tipo de modelos, defino los “tokens de pensamiento” no por separado de la conclusión, sino como todos los tokens que sirven de peldaño en cada etapa de resolución del problema. Mi experiencia ha sido que instruir al modelo para priorizar ciertos tokens o expresiones suele mejorar los resultados, y la forma en que AutoThink usa automáticamente los tokens con mejor desempeño en el dataset podría convertirse en una optimización más general y efectiva. Dicho eso, si se usan demasiados pivot tokens existe el riesgo de sobreajustarse solo a preguntas del benchmark, así que me interesa ver qué tanto generaliza este enfoque. Personalmente, veo la selección cuidadosa de palabras/tokens como una optimización de bajo costo y alta eficiencia que mejora mucho la calidad de los resultados, y tengo expectativas sobre la capacidad de generalización de AutoThink

• Es genial que, gracias a los modelos pequeños, equipos pequeños e investigadores individuales ya puedan demostrar con facilidad enfoques o experimentos innovadores sin tener nada que envidiar a los grandes laboratorios de IA. A medida que crece la competitividad de los SML (Small Language Model), también se expande mucho más de lo imaginable lo que puede implementarse on-device

  • Creo que el término correcto es SLM y no "small language models (SML)"

• Si alojas un modelo para otras personas, también está bien ahorrar cómputo en preguntas muy simples. En ese caso, puede existir la desventaja de que el modelo trate con menos cuidado las preguntas fáciles de identificar, pero ese costo no lo asumo yo. En cambio, si uso el modelo directamente en mi PC, después de haber invertido bastante en una GPU quiero aprovechar al máximo esos recursos; no necesariamente quiero reducir cómputo incluso en consultas simples

• ¡Da mucho en qué pensar! Nosotros también vamos a discutir internamente si, al diseñar un crawler de IA, debemos reconocer dinámicamente en qué sitios conviene lanzar más consultas y en cuáles menos. Como referencia, somos samaritanscout.org, un proyecto de motor de búsqueda que reúne todas las oportunidades locales de voluntariado publicadas en distintos sitios de organizaciones sin fines de lucro

• Soy muy nuevo en el mundo de los LLM y la IA, pero este proyecto me interesa mucho. Me resulta muy intuitivo e impresionante que AutoThink ajuste el esfuerzo computacional para que la IA “piense de forma más inteligente” según la dificultad del problema: se puede comparar con cómo una persona resuelve al instante algo como 2+2 y solo se detiene a pensar de verdad en problemas difíciles. No entiendo bien los aspectos técnicos como el presupuesto de tokens o el steering vector, pero me atrae mucho esta idea de volverse al mismo tiempo más rápido y más inteligente. Voy a seguirlo de cerca

• Creo que sería mejor no usar términos como “pensar” o “razonamiento” en el contexto de los LLM: ambas palabras tienen significados específicos y una carga filosófica, cuando en realidad los LLM no piensan ni razonan así, sino que más bien generan resultados mediante más cómputo (tiempo de procesador)

  • Ese barco ya zarpó. Igual que antes la palabra “computadora” se refería a personas que hacían cálculos y ahora pasó completamente a las máquinas, aquí también cambió el significado del término

  • Lo comparo con “ping”: cuando haces ping a una dirección IP no estás enviando ondas sonoras a un casco metálico, pero se usa en sentido figurado porque encaja con la función real. Si una metáfora es útil, se usa cotidianamente aunque no coincida 1:1 con la realidad

  • Mi visión del mundo es materialista en principio y determinista. Pero en la vida diaria también le sumo existencialismo y hasta cierta sensibilidad espiritual. Desde una perspectiva práctica, atribuir temporalmente cualidades antropomórficas a este tipo de herramientas facilita la conversación y ayuda a entenderlas intuitivamente. A veces ese enfoque muestra sus límites, pero cuando pasa creo que siempre se puede cambiar con facilidad a un marco más analítico