Mismas respuestas, la mitad de tokens: ya en Hugging Face

GreenPT ya está en Hugging Face. Hemos publicado nuestros dos primeros modelos abiertos:

• GreenPT/Qwen3.5-9B-honey: adaptador LoRA sobre Qwen3.5-9B
• GreenPT/Qwen3.8-27B-honey: adaptador LoRA sobre Qwen3.8-27B

Ninguno de los dos sabe nada que el modelo base no sepa. Están entrenados para un único comportamiento: dar la misma respuesta con menos tokens. Es la misma regla que hay detrás de Honey para Mac, trasladada de la herramienta a los pesos.

Es un experimento temprano. Lo publicamos ya, con sus defectos, porque las primeras cifras han cambiado nuestra forma de pensar en la eficiencia y porque preferimos que la gente lo ponga a prueba a pulirlo en privado.

El problema que queremos resolver

Cada token que produce un modelo cuesta cómputo, dinero y energía. La mayoría de los tokens de una respuesta típica no son la respuesta. Son el preámbulo, la pregunta repetida, el “Por supuesto, aquí tienes un desglose”, el resumen final del resumen.

En un chatbot eso resulta un poco molesto. En los agentes, con modelos que llaman a modelos miles de veces al día, es puro sobrecoste, y lo pagan tanto quien envía como quien recibe.

Se puede resolver con un prompt. Lo probamos: una instrucción de estilo detallada en el prompt del sistema redujo la salida un 74 %. También hizo que cada solicitud fuera 8,3× más cara en total, porque la propia instrucción se reenvía y se vuelve a procesar en cada llamada. La brevedad era real, pero la factura iba en la dirección equivocada.

Así que la pregunta pasó a ser: ¿se puede entrenar la brevedad para que no cueste nada en la inferencia?

Qué es un adaptador LoRA (versión de 30 segundos)

Un adaptador LoRA es un pequeño conjunto de pesos adicionales entrenados sobre un modelo base congelado.

En lugar de actualizar una gran matriz de pesos W, aprendes dos matrices finas A y B y calculas W + BA. Como A y B son de rango bajo (de ahí Low-Rank Adaptation), la parte entrenable ocupa unos cientos de megabytes, no decenas de gigabytes.

Eso te da tres ventajas:

• Barato de entrenar: una GPU y unas horas, no semanas.
• Portátil: distribuyes solo el adaptador y cada persona usa el modelo base que ya tiene.
• No destructivo: lo desactivas y vuelves al modelo original.

También significa que el cambio es lo bastante pequeño para poder razonar sobre él. Y eso hace que los resultados que siguen sean más interesantes, no menos.

Las cifras

Hicimos evaluaciones A/B emparejadas: mismos prompts, misma decodificación voraz, razonamiento desactivado y adaptador activado y desactivado. Fueron 26 prompts con una respuesta verificable, repartidos entre preguntas y respuestas, explicaciones y código.

	Tokens de salida	Correctas (base / adaptador)
9B honey	−52 %	25/26 · 25/26
27B honey	−46 %	26/26 · 26/26

Por categorías, el adaptador 9B recortó un 58 % en preguntas y respuestas, un 56 % en explicaciones y un 27 % en código. El 27B llegó más lejos en preguntas y respuestas (−78 %) y se mantuvo en −47 % en explicaciones. La tasa de aciertos fue la misma en todos los casos. Cuando los dos modelos fallaron, fallaron en el mismo prompt.

La mitad de salida con los mismos aciertos, gracias a un adaptador que cabe en una memoria USB.

Lo que no funcionó

Publicar pronto también significa publicar lo malo.

El adaptador 27B es más largo con prompts de código escuetos. Pídele “escribe una función que haga X” y genera un código alrededor de un 12 % más compacto que el del modelo base, pero luego añade una sección “Cómo funciona” que el modelo base nunca escribe. Efecto neto: +24 % de tokens en ese tipo de prompt. En tareas de programación realistas (corrige este error, refactoriza esto, amplía esto, con el código en el prompt), el adaptador ahorra entre un 5 % y un 12 %, como se esperaba. Así que la regresión es limitada y sabemos de dónde viene: nuestro corpus de estilo tiene secciones explicativas en sus ejemplos de código. Se arregla en los datos de entrenamiento y es lo siguiente en la lista.

Dos trampas en las que caímos, para que no caigas:

1. Las claves del adaptador tienen que coincidir con el árbol del modelo que cargas. Nuestro entrenador guardó los pesos en model.language_model.layers…; AutoModelForCausalLM construye model.layers…. PEFT ignora sin avisar cada tensor que no coincide, así que obtienes un modelo que “funciona” pero que es solo el modelo base. Los adaptadores publicados llevan las claves reasignadas, pero si vuelves a entrenar, comprueba esto primero.
2. El token de parada del repositorio base es incorrecto para chat. Qwen/Qwen3.5-9B trae un eos_token_id de <|endoftext|>, mientras que su plantilla de chat termina los turnos con <|im_end|>. Un entorno de pruebas que herede esa configuración nunca ve detenerse al adaptador, y eso parece exactamente un adaptador roto. Genera con eos_token_id=[248046, 248044]. Nuestros repositorios de adaptadores incluyen un generation_config.json correcto.

Una nota sobre el despliegue. Ejecutar un LoRA sin fusionar cuesta alrededor de un 37 % más por token en nuestra configuración, porque cada capa adaptada hace un par adicional de pequeñas multiplicaciones de matrices. En producción, fusiona una vez el adaptador con los pesos base y sirve un modelo normal. Déjalo sin fusionar solo mientras iteras o cambias de adaptador en caliente.

Pruébalo

from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import PeftModel

adapter = "GreenPT/Qwen3.5-9B-honey"
tok = AutoTokenizer.from_pretrained(adapter)
model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen3.5-9B", torch_dtype="auto", device_map="auto")
model = PeftModel.from_pretrained(model, adapter)

msgs = [{"role": "user", "content": "Explain what a mutex is."}]
ids = tok.apply_chat_template(msgs, add_generation_prompt=True, return_tensors="pt").to(model.device)
out = model.generate(ids, max_new_tokens=512, do_sample=False, eos_token_id=[248046, 248044])
print(tok.decode(out[0][ids.shape[-1]:], skip_special_tokens=True))

Desactiva la última línea de PeftModel y ejecuta el mismo prompt para comprobar la diferencia.

Hacia dónde vamos

De este trabajo salieron dos convicciones.

La eficiencia se puede entrenar. No hemos creado un modelo nuevo. Hemos cogido un modelo que la gente ya usa y hemos abaratado su ejecución, con unos cientos de MB y unas pocas horas de GPU. Esa receta no debería ser exclusiva de Qwen. Estamos creando flujos de código abierto para ajustar cualquier modelo abierto y hacerlo más eficiente, que cubren los datos de entrenamiento, el código de entrenamiento, el entorno de evaluación y las trampas, y lo publicaremos todo. No un modelo en un benchmark, sino un proceso repetible que cualquiera puede aplicar al modelo que ya ha elegido.

La gran ventaja está entre agentes. Cuando la salida de un modelo es la entrada de otro, cada preámbulo educado se paga dos veces: una al generarlo y otra al leerlo. Creemos que unos protocolos más eficientes entre agentes importarán más que cualquier optimización de un solo modelo. Los adaptadores son nuestro primer paso: un modelo que ya habla de forma escueta es el interlocutor más fácil sobre el que construir un protocolo ligero.

Los dos modelos ya están en Hugging Face. Ejecútalos, rómpelos y cuéntanos qué encuentras.