SALT: el runner LLM basado en trie que busca contribuidores

En pocas palabras: SALT es un proyecto open source que reemplaza matrices densas por un trie para ejecutar LLMs en hardware limitado como una Raspberry Pi. Creado por oteomamo bajo licencia MIT, busca contribuidores para construir un runner de inferencia que reduzca el consumo de memoria.

SALT es un proyecto open source que busca contribuidores para construir un runner de LLM basado en trie, una estructura de datos que promete reducir drásticamente el consumo de memoria durante la inferencia. El repositorio, publicado por el desarrollador oteomamo en GitHub, está en etapa temprana y necesita manos que ayuden a darle forma. La idea de fondo es simple pero potente: reemplazar los tensores densos tradicionales por un árbol de prefijos para ejecutar modelos de lenguaje en hardware con recursos limitados, desde una Raspberry Pi hasta un servidor ARM viejo que tenés juntando polvo.

Un runner de LLM basado en trie es un motor de inferencia que organiza los pesos y las activaciones de un modelo de lenguaje como un árbol de prefijos —conocido como trie— en lugar de usar las matrices densas que dominan el ecosistema actual. Cada token posible se representa como un camino en ese árbol, y la búsqueda del siguiente token se convierte en un recorrido eficiente que solo carga en memoria las ramas necesarias. Esto significa que no necesitás mantener en RAM toda la caché KV del transformer ni las matrices de atención completas: solo los fragmentos del trie que el contexto actual está usando.

El proyecto SALT, alojado en github.com/oteomamo/SALT, es la implementación de referencia de esta idea. Está armado en Rust —un lenguaje que te da control fino sobre la memoria sin rezarle al garbage collector— y se presenta como un motor de inferencia pura, no de entrenamiento. O sea, vos traés tu modelo ya entrenado (probablemente en formato GGUF o similar, aunque esto todavía está en discusión en los issues del repo) y SALT lo ejecuta con la promesa de usar menos RAM que alternativas como llama.cpp. ¿Cuánto menos? Esa es la gran pregunta que el proyecto necesita responder con benchmarks reales, y justamente por eso están buscando contribuidores.

¿Cómo funciona un runner de LLM con estructura de trie para eficiencia de memoria?

Ponele que tenés un modelo de lenguaje chico, digamos de 1B de parámetros. En un runner tradicional, cada token que generás actualiza una caché de clave-valor (KV) que crece linealmente con la longitud del contexto —un quilombo de memoria que te obliga a tener VRAM o RAM de sobra. Con un trie, en cambio, las relaciones entre tokens se almacenan como rutas en un árbol de prefijos compartido: si dos secuencias comparten las primeras 50 palabras, el trie las representa con un solo camino ramificado, no con dos copias independientes de la caché KV.

La búsqueda del próximo token se convierte en un descenso por el árbol donde cada nodo ya tiene precalculada la distribución de probabilidad condicionada al prefijo que lo precede. No hacés multiplicaciones de matrices gigantes para cada paso de inferencia; simplemente seguís la rama correcta y el nodo ya sabe qué token viene después con qué probabilidad. Esto, en teoría, reduce la complejidad de memoria de O(n²) —donde n es la longitud del contexto, típica de los mecanismos de atención— a algo mucho más cercano a O(n log n) o incluso mejor dependiendo de cuántas ramas compartidas tengas.

Lo interesante es que el trie se construye una sola vez a partir del checkpoint del modelo y después solo hacés lookup. Subís el modelo, el trie se arma en un paso de preprocesamiento (que puede tardar, ojo), y después la inferencia vuela sin tocar disco ni saturar la RAM. ¿El costo? La construcción inicial del trie puede ser pesada y el archivo resultante es más grande que los pesos originales —estás tradeando espacio en disco por eficiencia en RAM, que para edge computing suele ser justo lo que necesitás.

Características principales del proyecto SALT

El repositorio de SALT, inspeccionado a julio de 2026, es un proyecto en estado temprano pero con la estructura clara. Está escrito en Rust y publicado bajo licencia MIT, lo que significa que podés forkearlo, usarlo en proyectos comerciales y modificarlo sin restricciones. El autor, oteomamo, abrió issues etiquetados como “good first issue” para que nuevos contribuidores puedan sumarse sin necesidad de entender todo el codebase de entrada. Esto se conecta con lo que analizamos en nuestra guía de seguridad con Intune.

• Motor de inferencia pura: SALT no entrena modelos ni hace fine-tuning. Solo ejecuta checkpoints ya entrenados, como haría llama.cpp pero con una estructura de datos diferente.
• Lenguaje: Rust con posibilidad de bindings a C y Python más adelante —hay un issue abierto discutiendo exactamente esto.
• Sin dependencias pesadas de GPU: el objetivo es correr en CPU, idealmente en ARM64 y x86_64, sin necesidad de CUDA ni aceleradores propietarios.
• Documentación en progreso: el README está armado pero varios detalles de implementación están en los issues, esperando que contribuidores ayuden a documentarlos.
• Formato de modelo: todavía está en discusión si usar GGUF, un formato propio basado en el trie preconstruido, o ambos —este es uno de los temas donde más se necesitan manos.

Lo que no está claro todavía (y el repo lo admite sin vueltas) es el rendimiento real. No hay benchmarks comparativos contra llama.cpp, Ollama o MLC LLM. La gente de SALT está buscando justamente eso: desarrolladores que quieran correr pruebas, medir latencia, consumo de RAM y velocidad de generación de tokens en hardware concreto. Si alguna vez tuviste ganas de meterte en un proyecto open source desde el principio y que tu contribución defina la dirección técnica, este es el momento.

¿Cuánta memoria ahorra realmente un runner basado en trie?

La respuesta honesta: todavía no lo sabemos con precisión, porque los benchmarks no están hechos. Y esto no es una crítica al proyecto —es justamente la razón por la que buscan contribuidores. Dicho esto, podemos hacer números de servilleta basados en la teoría de tries aplicada a modelos de lenguaje.

Pensá en un transformer tradicional con un contexto de 4096 tokens. La caché KV para un modelo de 7B parámetros te ocupa aproximadamente 2 GB solo para mantener el estado de atención —y eso antes de cargar los pesos del modelo, que son otros 14 GB en FP16. Un trie bien construido podría almacenar las distribuciones de probabilidad para cada prefijo común una sola vez: si de tus 4096 tokens de contexto, digamos 2500 son combinaciones de prefijos que ya aparecieron antes en el mismo prompt (y pasa más seguido de lo que creerías con texto natural), esos 2500 tokens no generan nuevas entradas en el trie, solo extienden ramas existentes.

El ahorro teórico puede andar entre un 30% y un 60% de RAM según qué tan repetitivo sea el lenguaje de tu dominio —pero tomalo con pinzas, es una estimación de café, no un paper revisado por pares. La comunidad de SALT necesita correr el modelo en una Raspberry Pi 5 con 8 GB de RAM, medir cuántos tokens por segundo genera con un modelo de 1B, y comparar ese número contra llama.cpp en las mismas condiciones. Ese dato no existe todavía, y si te interesa ser la persona que lo genere, el repo está esperando tu PR.

Cómo contribuir a SALT: guía paso a paso para desarrolladores

Contribuir a un proyecto en etapa temprana tiene sus ventajas: no hay procesos burocráticos, tu código toca partes centrales y aprendés una banda. Así se arranca: Más contexto en el artículo completo sobre ChatGPT.

• 1. Hacé un fork del repo en github.com/oteomamo/SALT y clonalo en tu máquina. Necesitás Rust instalado (usá rustup, es la forma más limpia).
• 2. Revisá los issues etiquetados como “good first issue” —hay varios abiertos a julio de 2026 que van desde documentar la estructura del trie hasta implementar el parser de checkpoints.
• 3. Leé el CONTRIBUTING.md (si no existe, ese es tu primer issue: crearlo). El estilo de código sigue las convenciones estándar de Rust con cargo fmt y cargo clippy.
• 4. Corré los tests locales con cargo test. Si no hay tests para el módulo que te interesa, armalos —eso también cuenta como contribución y suma una banda.
• 5. Armá tu branch, commiteá con mensajes claros y mandá el PR. El maintainer revisa bastante rápido según la actividad del repo.

No necesitás GPU para contribuir. De hecho, el proyecto está diseñado para CPU, así que con una laptop común estás bien. Si tenés una Raspberry Pi o un servidor ARM para testear, mejor todavía —hay issues específicos sobre soporte ARM64 que necesitan validación en hardware real.

Casos de uso prácticos para un LLM runner ligero

Imaginate esto: tenés un local de atención al público en una zona con internet intermitente y necesitás un chatbot que clasifique consultas sin depender de la nube. Con un runner basado en trie, podés cargar un modelo pequeño de clasificación en una Raspberry Pi 4, conectarlo a un monitor y un teclado berreta, y tener un asistente offline que responda en milisegundos sin consumir más de 2 GB de RAM.

Otro caso: edge computing en fábricas. Sensores IoT generando datos que necesitan análisis de texto en tiempo real —alertas, registros de mantenimiento, reportes de turno— procesados en el mismo dispositivo que los recolecta, sin mandar nada a la nube por temas de latencia o privacidad. Un runner liviano como SALT metido en un servidor ARM de bajo consumo podría hacer exactamente eso: correr inferencia continua sin calentarse y sin necesidad de un clúster de GPUs.

¿Un tercero? Asistentes de accesibilidad offline. Lectores de pantalla que necesitan resumir texto en voz alta, traductores que funcionan sin conexión en zonas rurales, herramientas de escritura aumentativa para personas con discapacidad. Todos escenarios donde la latencia de red te mata y el presupuesto de hardware es ajustado. Si SALT logra cumplir su promesa de eficiencia, este tipo de aplicaciones pasan de “algún día” a “esta semana”.

Diferencias clave con otros runners de código abierto

La comparación más directa es con llama.cpp, el runner que popularizó la inferencia de LLMs en CPU. La diferencia fundamental está en la estructura de datos interna: llama.cpp usa tensores cuantizados con caché KV tradicional —es rápido, está recontra optimizado y tiene años de desarrollo encima, pero el consumo de memoria escala con la longitud del contexto de forma bastante lineal. SALT propone cambiar ese paradigma: en vez de matrices, un trie; en vez de caché KV por token, caminos compartidos en un árbol de prefijos. Lo explicamos a fondo en la guía de modelos de lenguaje y razonamiento.

Lo que me gusta de SALT es que no intenta competir en velocidad pura con herramientas que ya tienen años de optimización. Va por otro lado: eficiencia de memoria en dispositivos chicos. Es un nicho que los runners mainstream medio que dejan de lado porque el foco está en servidores con GPUs y modelos cada vez más grandes. Si tu preocupación no es generar 50 tokens por segundo sino poder ejecutar un modelo útil en 4 GB de RAM sin swap, SALT apunta justo ahí.

Errores comunes al evaluar un runner basado en trie

Error 1: Asumir que el trie mágicamente comprime todo. Un trie comparte prefijos idénticos, sí, pero el lenguaje natural tiene una cola larga enorme de combinaciones únicas. Si tu dominio es muy variado (digamos, consultas abiertas de usuarios), la tasa de compartición puede ser más baja de lo que esperás y el ahorro de memoria se diluye. No es magia, es estructura de datos.

Error 2: Ignorar el costo de construcción del trie. Armar el trie a partir de un checkpoint de 7B parámetros no es instantáneo —puede llevar minutos u horas dependiendo de la implementación. Si tu caso de uso requiere cambiar de modelo seguido, el overhead de reconstrucción te come la ventaja de inferencia rápida.

Error 3: Comparar con benchmarks de GPU sin contexto. Que SALT sea más lento que un runner con CUDA en una A100 no dice nada útil. La comparación justa es en CPU de bajo consumo, con la misma carga y el mismo modelo. Si vas a medir, medí donde importa: Raspberry Pi, servidores ARM, laptops viejas. Ahí es donde el trie debería brillar (si la implementación acompaña, claro).

Error 4: Creer que reemplaza el entrenamiento o el fine-tuning. SALT es solo inferencia. No vas a entrenar un LoRA con esto ni a hacer fine-tuning distribuido. Si tu pipeline incluye ajuste de modelos, necesitás otra herramienta para esa etapa y SALT para servir el resultado. Cubrimos ese tema en detalle en nuestra guía de Google.

Preguntas Frecuentes

¿Qué es SALT y para qué sirve?

SALT es un runner de inferencia para modelos de lenguaje basado en una estructura de datos trie (árbol de prefijos), diseñado para minimizar el uso de memoria RAM durante la generación de texto. Sirve para ejecutar LLMs ya entrenados en dispositivos con recursos limitados, como Raspberry Pi, servidores ARM o hardware de edge computing.

¿Cómo contribuir al proyecto SALT en GitHub?

Hacé un fork del repositorio en github.com/oteomamo/SALT, revisá los issues etiquetados como “good first issue”, armá tu branch siguiendo las convenciones de Rust (cargo fmt, cargo clippy) y mandá un pull request. El proyecto acepta contribuciones de código, documentación, benchmarks y testing en hardware real.

¿Cuánta memoria ahorra SALT comparado con llama.cpp?

No hay benchmarks públicos todavía —el proyecto está en etapa temprana y justamente busca contribuidores que ayuden a generar esos números. Teóricamente, el ahorro puede ir del 30% al 60% de RAM en dominios con lenguaje repetitivo, pero falta validación empírica en hardware concreto.

¿SALT soporta GPU o solo CPU?

Por ahora, SALT está pensado exclusivamente para CPU, con foco en arquitecturas ARM64 y x86_64. No tiene soporte para CUDA, Metal, Vulkan ni otros aceleradores. Si tu caso de uso requiere GPU, herramientas como llama.cpp o MLC LLM son opciones.

¿Qué lenguajes de programación usa SALT?

El core está escrito en Rust. Hay discusiones en el repositorio sobre implementar bindings a C y Python en el futuro, pero por ahora contribuir requiere manejo de Rust y familiaridad con estructuras de datos como tries.

Conclusión

SALT es una idea sólida en busca de validación. La propuesta de un runner de LLM basado en trie ataca un problema real —el consumo desproporcionado de memoria en inferencia— con una solución elegante que ya funciona en otros dominios (bases de datos, motores de búsqueda, compiladores). Lo que falta es demostrar que la teoría se sostiene cuando la ponés a correr en hardware de verdad con modelos de tamaño usable.

Si sos desarrollador y te interesa la intersección entre estructuras de datos, Rust y modelos de lenguaje, este proyecto es una oportunidad poco común: meterse en algo que está arrancando, donde tu contribución define features centrales y no estás arreglando bugs de un monstruo de 100 mil líneas que ya tiene tres años de decisiones técnicas inamovibles. El maintainer está activo, los issues son accesibles y la licencia MIT te da libertad total.

Lo que no hay que hacer es esperar magia. Un trie no va a hacer que un modelo de 70B corra en un microondas. Pero si logra que un modelo de 1B o 3B funcione decentemente en hardware que hoy directamente no puede correr nada, ya es un golazo. El resto lo define la comunidad —y ese es exactamente el llamado del repo.

Fuentes

• Repositorio oficial de SALT en GitHub — Código fuente, issues abiertos y documentación en progreso del runner LLM basado en trie.