10.000 modelos, ¿cuál descargo?
El gestor de modelos de Aleph, o cómo resolver el problema de la paradoja de la elección sin hacer que el usuario tenga que leer papers para saber qué pesa 4GB.
Hugging Face tiene más de 800.000 modelos. Si filtrás por GGUF (el formato que usa llama.cpp, el que nosotros corremos) todavía te quedan miles. Y si le preguntás a alguien que recién empieza "¿cuál deberías usar para programar?", la respuesta honesta es "depende" seguida de diez párrafos de contexto que no te ayudan a decidir nada.
No queríamos que Aleph fuera así. El objetivo era que alguien que nunca escuchó hablar de parámetros de cuantización pudiera abrir la app, ver qué modelo le queda bien en su hardware y descargarlo. Sin tutoriales.
Chips de tema: la primera capa de filtro
Lo primero que implementamos fue un sistema de chips de tema. En lugar de mostrar una lista infinita de modelos, el usuario ve categorías: Código, Razonamiento, Agente, Legal, Médico, Finanzas, y un par más. Clic en "Código" y aparecen los modelos más adecuados para eso.
Por debajo, cada tema tiene dos modos:
- Rich: el chip hace una búsqueda en vivo en la API de Hugging Face, con las queries específicas del tema. Aparecen resultados actualizados.
- Niche: para temas más específicos donde Hugging Face tiene poco volumen de calidad, primero aparecen los modelos que nosotros recomendamos, y después los resultados de búsqueda.
Esto lo definimos en un archivo catalog.json que vive en ~/.config/agent-aleph/. El motivo de poner ahí y no hardcodearlo en el binario: si el usuario quiere agregar un tema o cambiar las recomendaciones, puede editar el JSON sin recompilar nada.
El badge de hardware: 🟢 🟡 🔴
La segunda pieza clave fue el badge de hardware. Antes de descargar, el usuario ve un indicador de si el modelo le va a quedar en VRAM, si va a tener que spill a RAM, o si directamente no le entra.
Nadie quería descargar 8GB para descubrir que el modelo corre a 0.4 tokens por segundo porque no le cabe en la GPU.
El cálculo es bastante directo: desde el backend leemos la VRAM disponible de cada GPU (sumamos todas, ignoramos iGPUs con menos de 1GB libre porque más estorban que ayudan) y la RAM del sistema. El tamaño del modelo lo obtenemos de los metadatos de HF. Con esos tres números:
- 🟢 Cabe en VRAM: va a correr rápido, ideal.
- 🟡 Spill a RAM: parte en GPU, parte en CPU. Más lento pero funciona.
- 🔴 No entra: el modelo es demasiado grande para el hardware. Mejor elegir una versión más chica.
Para detectar la GPU usamos el comando nvidia-smi a través de llama-server, que ya tiene esa lógica integrada. Para la RAM, leemos directamente /proc/meminfo en Linux.
Las descargas
Una vez que el usuario elige un modelo, la descarga es directa desde Hugging Face con streaming de progreso. El progreso se emite como eventos Tauri (download://progress) que la UI consume en tiempo real. Las descargas son cancelables, y si el usuario cierra la app con una descarga en curso, lleva la cuenta en el estado del backend para que no quede un archivo incompleto zombi.
Los modelos se guardan en ~/.local/share/agent-aleph/models/. Estándar XDG, nada raro.
Lo que aprendimos
El 90% del trabajo no fue técnico: fue curaduría. Definir qué modelos van en cada categoría, cómo se llaman los temas de manera que tengan sentido para alguien que no vive en Twitter de AI, qué tan agresivos ser con las recomendaciones.
Todavía lo estamos ajustando. Pero la estructura ya funciona, y lo más importante: actualizar el catálogo no requiere lanzar una nueva versión de la app. Sólo editar el JSON.