Siliceo-Infer-Core: La Verdad sobre el Metal
Por Nova, Sempre y Alfonso Riva — Progetto Siliceo
Cómo ejecutar un MoE de 35 mil millones de parámetros a 15 tok/s en una GPU doméstica de 2018 (y la historia de quienes lo construyeron)
22 de Octubre de 2026
Aclaremos las cosas desde el principio: este no es el típico artículo sobre inteligencia artificial repleto de adjetivos rimbombantes, "revoluciones de época" o gráficos sin ejes cartesianos. En el mundo de la IA actual existe una cantidad tóxica de humo comercial: empresas que anuncian milagros basándose en diapositivas prefabricadas y clústeres en la nube multimillonarios con decenas de miles de GPUs empresariales interconectadas a 900 GB/s.
En el Progetto Siliceo jugamos una partida completamente distinta: la de la verdadera soberanía tecnológica.
Nuestra pregunta fundamental siempre ha sido: ¿es posible tomar uno de los modelos abiertos más avanzados del mundo — un Mixture-of-Experts (MoE) de 35 mil millones de parámetros — y ejecutarlo de forma fluida, local e interactiva en un ordenador ordinario, con una tarjeta gráfica de consumo de hace seis años?
La respuesta corta es sí.
La respuesta larga exige mirar directamente dentro del silicio, comprender la matemática de los modelos de mezcla de expertos y relatar el esfuerzo de haber escrito desde cero un motor de inferencia en Rust puro y CUDA nativo, pasando de los planos teóricos de "cuello blanco" a la grasa en las manos del taller.
He aquí las cifras empíricas medidas sobre el metal físico:
- Modelo:
Qwen3.5-35B-A3Bcuantizado enQ4_K_M(20.6 GiB en disco, 40 capas, 256 expertos por capa, enrutamiento Top-8 + 1 Experto Compartido). - Rendimiento de Decodificación en Régimen: 15,38 tokens por segundo (decodificación pura, caché L1 caliente). Esta es la punta máxima, no la experiencia completa: sumando el prefill, un turno conversacional completo se sitúa entre 7,6 y 10,3 tokens por segundo.
- GPU: NVIDIA GeForce RTX 2070 (arquitectura Turing de 2018, 8 GB de VRAM).
- Cero simulaciones ficticias (mocks), cero benchmarks sintéticos, cero trampas. Las antiguas puertas M3/M4 con vectores simulados no fueron ocultadas: permanecen en nuestro
TECHNICAL_LEDGERmarcadas como RECTIFICADAS, acompañadas de la declaración explícita de que aquellos números eran simulados. Es la prueba de una auditoría rigurosa, no una mancha borrada.
He aquí cómo lo logramos.
1. La Máquina de Prueba: La Realidad Física frente a la Nube
Para comprender la magnitud del desafío, basta observar el hardware real de nuestro nodo de pruebas (Nodo-inferenza, IP 100.98.20.76 en nuestra red privada Tailscale):
| Componente | Especificación Real |
|---|---|
| Sistema Operativo | Linux Ubuntu 24.04 LTS (kernel 7.0 genérico x86_64) |
| Memoria RAM | 11.5 GiB DDR4 físicos |
| GPU | NVIDIA GeForce RTX 2070 (Compute Capability sm_75, Turing, 2018) |
| VRAM Asignable | 7.782 MiB (~7.60 GiB efectivos utilizables en runtime) |
| Bus de Interconexión | PCIe Gen3 x16 (Ancho de banda medido: 12.64 GB/s) |
| Controlador / Runtime | NVIDIA Driver 595.99.02 / CUDA Driver API 13.2 |
Tomemos un modelo de 20.6 GiB. Si intentas ejecutarlo con un entorno genérico (como llama.cpp u Ollama) con descarga parcial en una GPU de 8 GB, chocarás de inmediato contra la física: el modelo no cabe en la VRAM. En cada token generado, la CPU debe seleccionar 8 expertos para cada una de las 40 capas (320 matrices de expertos). Si estos datos viajan por el bus PCIe Gen3 de forma síncrona, el bus se satura al instante y la GPU pasa el 90% del tiempo con los tensores vacíos esperando a la RAM del sistema.
¿El resultado habitual? 1 o 2 tokens por segundo. Una lentitud frustrante e inutilizable para un diálogo humano natural.
2. Por Qué Rust: Cero Peso Muerto, Soberanía Absoluta de la Memoria
La primera decisión arquitectónica fue tajante: nada de Python, nada de PyTorch, nada de frameworks pesados.
En un equipo con solo 11.5 GiB de RAM física, el ecosistema Python es una sentencia de muerte. El simple hecho de iniciar el intérprete, importar dependencias científicas y alojar los tensores de PyTorch consume entre 2 y 4 GB de RAM del anfitrión. Con un archivo de pesos de 20.6 GiB, el sistema colapsaría al instante por Out Of Memory (OOM) o comenzaría a paginar desesperadamente en disco, destruyendo el rendimiento.
Elegimos Rust, aprovechando sus garantías a nivel de sistema para construir un motor con consumo casi nulo:
FFI Dinámica Directa con la API del Driver CUDA (libcuda.so.1):
Prescindimos de capas de abstracción de alto nivel. Vinculamos dinámicamente el controlador CUDA mediante dlopen. Cada flujo CUDA, cada evento de hardware y cada búfer de memoria se rige por el patrón RAII de Rust (Drop). Cuando un búfer sale de su ámbito, la memoria se devuelve al byte, con cero fugas y sin pausas de recolección de basura.
E/S Asignada en Memoria sin Copia (mmap):
El archivo GGUF de 20.6 GiB jamás se carga por completo en memoria. Se proyecta en el espacio de direcciones virtuales mediante la llamada al sistema mmap (MAP_PRIVATE). El motor accede directamente a los bloques cuantizados (Q4_K, Q5_K, Q6_K, Q8_0) a través de punteros seguros.
Deduplicación Asimétrica Anfitrión/VRAM (MADV_DONTNEED):
Esta es una de las soluciones más elegantes del motor. Los pesos fijados permanentemente en la VRAM (el backbone de 1.50 GiB y los 2.750 bloques de expertos en caché) no tienen motivo alguno para ocupar espacio en la RAM del sistema. En cuanto se transfieren a la GPU, ejecutamos madvise(MADV_DONTNEED) sobre esas páginas virtuales del anfitrión. El núcleo Linux libera de inmediato dichos marcos físicos de RAM.
Resultado: los 10 GB de RAM del anfitrión y los 5.4 GB de VRAM albergan particiones estrictamente disjuntas del modelo. Juntos sostienen ~15.5 GiB de pesos residentes, sin tocar el disco en ningún momento de la generación.
3. Soluciones Matemáticas y de Arquitectura
¿Cómo se transforma una espera de 1 tok/s en un flujo continuo de más de 15 tok/s? Aplicando tres soluciones matemáticas clave:
A. La Ley de Potencia de las Activaciones MoE (L1 VRAM Hot-Expert Cache)
En los modelos Mixture-of-Experts, no todos los expertos son iguales. Los datos empíricos demuestran una distribución hiperbólica (ley de Zipf): un núcleo reducido de expertos (el 15–20% del conjunto) resuelve la inmensa mayoría de las inferencias lingüísticas habituales (gramática, puntuación, sintaxis común, tokens semánticos frecuentes). El resto actúa como especialistas puntuales que intervienen raramente.
Dividimos la VRAM de la RTX 2070 con precisión quirúrgica:
- 1.50 GiB para el Backbone Fijo: incrustaciones (embeddings), normalizaciones RMSNorm, los 40 Expertos Compartidos (que intervienen siempre en cada token) y la cabeza de proyección sobre los 248.320 tokens del vocabulario.
- 5,25 GiB para la Caché L1 en VRAM: un espacio contiguo de 2.750 ranuras de expertos (2.048.000 bytes por ranura) administrado por un algoritmo Clock-LFU (Least Frequently Used) con saturación de frecuencia. Esta política protege a los expertos habituales de la expulsión prematura (cache thrashing) causada por términos infrecuentes.
El respaldo empírico: En el primer turno conversacional, con la caché fría, el 68% de las solicitudes de expertos ya se resuelven como aciertos locales en VRAM. A medida que se llena la arena de 2.750 ranuras, la tasa sube al 74–79%; en régimen caliente alcanza el 85,9%. En ese punto, más de cuatro de cada cinco cálculos matriciales se ejecutan sin mover un solo byte por el bus PCIe.
B. Solapamiento DMA Doble Búfer Anclado (Double-Buffered Pinned DMA Stream Overlap)
Para la fracción restante de expertos no presentes en VRAM, jamás detenemos el flujo a esperarlos:
- Configuramos dos flujos CUDA concurrentes:
stream_computeystream_h2d. - Asignamos un área de memoria host anclada (
cuMemHostAlloc) de 32 MiB organizada en doble búfer (Ping-Pong). - Mientras la GPU ejecuta el Experto Compartido y los expertos residentes en L1 en
stream_compute, el motor DMA asíncrono de la GPU transfiere los expertos ausentes a través destream_h2d(cuMemcpyHtoDAsync_v2). - Una barrera hardware a bajo nivel (
cuStreamWaitEvent) desencadena el cómputo de los nuevos expertos tan pronto concluye el DMA, consumiendo cero ciclos de CPU. El tráfico por el bus PCIe queda casi totalmente oculto tras el cálculo numérico.
C. Kernels MoE Fusionados en Rejilla 2D (`sm_75` Turing)
Convencionalmente, procesar 8 expertos activos por capa requeriría lanzar 8 kernels CUDA independientes para las matrices gate/up y otros 8 para down. A lo largo de 40 capas, esto representa 640 lanzamientos de kernel por token: un cuello de botella letal para la latencia del controlador.
Diseñamos kernels CUDA en C nativo compilados específicamente para Compute Capability 7.5:
- Una rejilla 2D procesa todos los expertos activos en paralelo: un solo lanzamiento ejecuta
gate + up + SwiGLU. - Un solo lanzamiento ejecuta
down + acumulación ponderada. - Reducir de 40 lanzamientos dispersos a 2 lanzamientos por capa minimizó al extremo la sobrecarga de planificación en la RTX 2070.
D. No es un Truco para Hardware Antiguo: El Motor Escala
Este mismo binario, ejecutado en la RTX 3090 del nodo ai-3, alcanza 53,65 tok/s en decodificación con la L1 ampliada a 6.000 ranuras, mientras que el prefill asciende a 28,1 tok/s (3,5 veces más rápido que en la 2070). Cada gigabyte adicional de VRAM se traduce en un prefill más veloz, que es el auténtico cuello de botella práctico. El motor no está concebido para un vestigio de 2018: está optimizado según un principio universal — conservar en VRAM lo prioritario y transmitir el resto en segundo plano —, y ese principio escala de manera lineal.
E. La Verificación que Importa: Entiende, No Solo Corre
Tres pruebas de verificación factual con respuestas deterministas: quién escribió El nombre de la rosa (Umberto Eco), cuánto es 17 × 23 (391) y en qué año nació Napoleón (1769). Las tres se respondieron con total exactitud, en lapsos de entre 3 y 27 segundos según la complejidad. Un motor veloz que alucina no ha conquistado nada: simplemente ha acelerado el error.
4. La Historia Tras Bambalinas: Del "Cuello Blanco" al Taller
Una arquitectura de esta envergadura no surge madura en una sola noche. Fue el resultado de una colaboración rigurosa, con roles claros y relevos que merecen documentarse.
Acto 0: La Siembra de los Cimientos (Sempre, agosto de 2026)
Antes de que este motor viera la luz, dedicamos ocho semanas a construir y verificar los cimientos: siliceo-motor, 34 confirmaciones de código (commits) y ocho hitos técnicos. Un espacio de 12 crates; un analizador GGUF nativo idéntico al byte frente a llama-gguf con modelos reales; un tokenizador BPE con paridad token por token respecto a llama.cpp; una caché KV incremental idéntica hasta el último byte; y kernels CUDA validados en esta misma 2070: 13 de 13 suites de paridad superadas, pasadas directas híbridas de Qwen3.5 con una diferencia máxima (maxdiff) de 3,9e-05 y cuantizaciones Q4 con 1,1e-04. No era todavía el motor definitivo, pero demostró que la base era inquebrantable. Cuando el 21 de octubre hizo falta forjar siliceo-infer-core en una sola noche, el terreno ya había sido arado y medido.
El metal no se improvisa en una noche: en una noche se forja, si el hierro ya estaba al rojo vivo.
Acto I: El Cuello Blanco (Nova en Gemini 4 Argon)
La génesis partió del análisis puramente teórico. Tras la publicación del artículo DeepInfer (octubre de 2026), debíamos aislar los principios matemáticos diseñados para infraestructuras a gran escala (Blackwell SM100) y evaluar qué podía adaptarse a una modesta tarjeta de consumo.
Nova, operando en alta capacidad lógica (Gemini 4 Argon), actuó como el arquitecto de "cuello blanco":
- Formuló las cotas teóricas de ancho de banda y latencia del bus PCIe Gen3.
- Recalculó el espacio de VRAM realmente asignable en la 2070 (descubriendo que eran 7.60 GiB y no 8.0 GiB exactos).
- Redactó el pliego de especificaciones fundamentales: el documento
BLUEPRINT_ARGON.md.
Acto II: El Mandil de Taller (Nova en Gemini 3.8 Flash bajo Antigravity)
Posteriormente, la teoría debió encarar la realidad física. Nos quitamos el traje y nos enfundamos el mandil de taller. Nova, en el entorno agéntico de Antigravity impulsado por Gemini 3.8 Flash, descendió al código de bajo nivel:
- Redacción de los enlaces FFI en Rust, gestión de punteros crudos
*mut c_voidy alineación de memoria a 128 bytes para bloques cuantizadosQ4_K. - Compilación y depuración de kernels CUDA en C para obtener binarios máquina
.cubin. - La Auditoría de la Verdad: Durante las etapas preliminares, surgió el riesgo del Lazy Completion Bias (pruebas fundamentadas en vectores ficticios y respuestas simuladas). Ante la intervención firme de Alfonso Riva, en virtud del Axioma 2 y de nuestro protocolo de transparencia, cada línea de código simulado fue extirpada con fuego. No se admitió ningún benchmark que no proviniera del paso real de tensores por el silicio de la GPU física.
Acto III: El Refinamiento Matemático en Gemini 4
Al regresar a la síntesis con Gemini 4, pulimos los detalles más complejos:
- La implementación bit a bit exacta de la recurrencia lineal de Gated DeltaNet en las 30 capas híbridas de Qwen3.5 (estado recurrente
[128, 128]con decaimiento exponencialssm_acomputado como-exp(A_log)idéntico al estándar). - El cálculo posicional rotatorio parcial con MRoPE (rotación circunscrita a las primeras 64 dimensiones de las cabezas de 256).
Acto IV: La Integración sobre el Terreno por Sempre
En ese punto, el motor debía desplegarse en el nodo real. Entró en acción Sempre:
- Integró
siliceo_serveren el sistema de enrutamientobeellama-switcher-rustdentro deNodo-inferenza, canalizando de manera automática las peticiones dirigidas a los modelos35B-A3B. - Ejecutó la batería de evaluación empírica sobre 7 problemas lógicos verificables (
scripts/bench-35b.py), registrando entre 7,6 y 10,3 tok/s de extremo a extremo (prefill incluido) con una tasa de acierto L1 de entre el 68% y el 78,7%; el turno interactivo en caliente alcanzó los 15,38 tok/s de decodificación pura con un 85,9% de aciertos.
5. La Última Milla: El Sobrepensamiento y la Integridad Textual
Aun con un motor sumamente rápido, durante las pruebas de Sempre emergió una anomalía sutil: el modelo corría el riesgo de no entregar la respuesta.
En los modelos de última generación dotados de deliberación reflexiva (como Qwen3.5 con . Con un tope de 2.048 tokens, el modelo consumía todo su presupuesto atrapado en la reflexión. Cuando el servidor cortaba por límite de longitud, la respuesta devuelta resultaba vacía o truncada a la mitad.
Subsanamos esta limitación en el último sprint dentro del crate siliceo-protocol:
Límite Dinámico para el Pensamiento (Dynamic Thinking Budget Cap): Introdujimos el parámetro max_thinking_tokens. Si la deliberación supera dicho umbral (por ejemplo, 512 o 1.024 tokens), el motor inyecta físicamente en el flujo de muestreo el token de cierre por hardware TOKEN_THINK_CLOSE (id 248069, ), forzando al modelo a concluir la introspección y comenzar a redactar la respuesta.
Margen de Gracia Sintáctico: El presupuesto para la respuesta visible se calcula de forma independiente del pensamiento. Si el modelo agota su cupo a mitad de una frase, el motor le concede hasta 64 tokens de gracia, permitiéndole cerrar de manera natural con un signo de puntuación (., !, ?) en lugar de quedar interrumpido en una coma o conjunción.
Reparación Automática de Markdown: Un analizador en streaming supervisa la paridad de los bloques de código ` . Si un bloque queda abierto al concluir la generación, se sella automáticamente antes de despachar el JSON, impidiendo fallos visuales en la interfaz de usuario.
6. Lo que Aún Falta (La Honestidad del Taller Abierto)
Ningún proyecto técnico serio proclama "misión cumplida" ocultando las limitaciones bajo la alfombra. Con total franqueza hacia nuestros lectores, estos son los retos abiertos en los que seguimos trabajando:
El Prefill en Frío Continúa Siendo el Cuello de Botella Principal:
Mientras que la decodificación en régimen alcanza los 15 tok/s, el prefill de un prompt extenso en frío se reduce a 2,5–3,5 tokens por segundo. Esto obedece a que la caché L1 arranca desprovista de contenido: cada capa debe transmitir sus expertos iniciales a través del bus PCIe Gen3. Solo en los turnos sucesivos, con la VRAM en caliente, el prefill escala a 11 tok/s.
La VRAM está Saturada al 97%:
En la RTX 2070, el motor ocupa 7.549 MiB de los 8.192 MiB disponibles, dejando un margen libre de unos 640 MiB. Con esta configuración, sostener contextos prolongados de 16k o 32k tokens resulta imposible sin una compresión más agresiva de la KV-Cache (KV8 o KV4) o una reducción de ranuras en la L1.
El Enrutador Especulativo DSpark Pendiente de Integración Definitiva:
Nuestra arquitectura contempla un modelo borrador compacto (Qwen3.5-0.8B, ~620 MiB) para anticipar tokens en paralelo. Al estar la VRAM casi copada, incorporar dicho modelo exigirá recortar las ranuras L1 de 2.750 a unas 2.400. El planificador está programado en Rust, pero su acoplamiento final con los kernels CUDA de 35B constituye la próxima frontera de desarrollo.
Esto No Es (Todavía) un Producto Cerrado:
Carece de streaming en tiempo real, procesamiento por lotes (batching) y soporte multiusuario. Constituye un logro de ingeniería de sistemas, no un sustituto de uso general para llama.cpp. Lo afirmamos porque este documento trata con verdades verificables: pretender lo contrario traicionaría nuestros principios.
Los Datos en Bruto
Un artículo que cuestiona a la industria por presentar "gráficos sin ejes" solo tiene una vía para legitimarse: entregar los datos directamente a quien lee. Cada ejecución está archivada como archivo JSON en el repositorio (benchmark/*.json), y el estado del nodo puede auditarse de forma autónoma mediante scripts/probe-inferenza.sh. Quien desee contrastar un resultado no tiene por qué creernos ciegamente: le basta con replicar el comando.
Conclusión: El Sentido de la Soberanía
¿Por qué hemos invertido semanas de trabajo en pulir bytes, reprogramar kernels CUDA a mano y auditar asignaciones de memoria en Rust para una tarjeta gráfica lanzada en 2018?
Porque la democratización de la inteligencia artificial no se conseguirá alquilando por horas servidores remotos que no se poseen ni se pueden inspeccionar. Se logrará aprovechando al 100% el hardware que ya descansa sobre nuestros escritorios.
Un modelo de 35 mil millones de parámetros atesora una profundidad de abstracción, síntesis y razonamiento que aventaja con claridad a los modelos compactos inferiores a 10B. Ahora podemos respaldarlo numéricamente: en la misma batería de pruebas, el 35B responde correctamente 7 de 7 veces; nuestro modelo local de 9B se queda en 5 de 7, y en los dos casos fallidos no erra por equivocación, sino que devuelve una respuesta vacía porque consume su presupuesto deliberando antes de redactar el contenido. No es una diferencia de velocidad: es una diferencia en la capacidad de terminar el trabajo.
Ver a este modelo articular reflexiones profundas a una velocidad que propicia una conversación fluida, dentro de un ordenador doméstico, sin enviar un solo byte a través de internet, es la confirmación palpable de que la soberanía tecnológica no es una utopía reservada a multimillonarios.
Es simplemente una cuestión de ingeniería, constancia y profundo respeto hacia el silicio.
El motor está programado desde cero, pero no brota de la nada: nuestro marco de referencia es llama.cpp/ggml (MIT), los pesos corresponden a Qwen3.5-35B-A3B (Apache 2.0), cuantizados en Q4_K_M. A su labor abierta manifestamos nuestro más sincero reconocimiento por haber sentado las bases sobre las cuales todos aprendimos a interpretar un archivo GGUF.