Infraestructura propia para ejecutar y evaluar modelos de lenguaje de gran escala — privacidad total, costo cero por inferencia.
⚡ Mediciones propias — RTX 5060 Ti 16 GB, i5-14400F, ~31 GB RAM
La banca opera bajo restricciones regulatorias estrictas: secreto bancario, normativas de protección de datos y requisitos de auditoría. Enviar información de clientes o documentos internos a una API de terceros genera riesgos legales y de compliance que muchos equipos jurídicos no están dispuestos a asumir. Un modelo on-premise elimina esa fricción desde el origen.
| Dimensión | API en la nube | LLM on-premise |
|---|---|---|
| Privacidad de datos | Datos enviados a terceros | Datos nunca salen de la infraestructura |
| Costo por inferencia | Variable, por token | Costo fijo de hardware (amortizable) |
| Latencia | Depende de red y carga del proveedor | Determinista, sin cola de terceros |
| Control del modelo | Versión controlada por el proveedor | Versión exacta bajo control propio |
| Límites de uso | Rate limits, quotas, interrupciones | Sin límites externos |
| Alineación regulatoria | Requiere evaluación jurídica por jurisdicción | Secreto bancario y protección de datos por defecto |
El modelo pesa ~22 GB en disco. Una GPU de 16 GB no puede cargarlo íntegro. La solución combina tres tecnologías: arquitectura MoE, cuantización GGUF y offloading híbrido GPU/CPU con control fino por capa.
--n-cpu-moe N. El resto corre en GPU. N es el parámetro de control principal.
El KV cache es el recurso escaso en contextos largos. Gracias a GQA (solo 2 cabezas KV en lugar de las 16 de atención completa), el cache crece a un ritmo muy bajo — por eso 256K tokens es factible en 16 GB de VRAM.
# llama.cpp Unsloth build (CUDA 13 Blackwell)
/home/benjamin/.unsloth/llama.cpp/build/bin/llama-server \
--model /mnt/nvme/hot/models/Qwen3.6-35B-A3B-UD-Q4_K_M.gguf \
--port 8093 \
--alias qwen3.6-35b-a3b \
--ctx-size 131072 # 128K tokens
--n-gpu-layers 999 # todas las capas a GPU (excepto las MoE en CPU)
--n-cpu-moe 22 # expertos de capas 1-22 en RAM/CPU
--threads 10 # 10 cores físicos del i5-14400F
--threads-batch 16 # 16 hilos lógicos para prompt processing
--cache-type-k q8_0 # KV cache cuantizado → menor VRAM
--cache-type-v q8_0 \
--ubatch-size 2048 # micro-batch → 2.8x speedup en prompt processing
--batch-size 2048 \
--load-mode none \
--spec-type draft-mtp # speculative decoding con draft weights MTP
--spec-draft-n-max 3 \
--no-reasoning-preserve # elimina el bloque <think>
--top-p 0.95 --top-k 20 --min-p 0.0Velocidad de generación y procesamiento de prompts medidos directamente con llama.cpp sobre hardware real. Sin simulaciones.
| Perfil de contexto | --n-cpu-moe | VRAM usada | Velocidad (tok/s) |
|---|---|---|---|
| 16K tokens | 16 | 15.1 GB / 16 GB | ~64 tok/s |
| 64K tokens | 20 | ~14.8 GB / 16 GB | ~60 tok/s |
| 128K tokens | 22 | 14.2 GB / 16 GB | ~56 tok/s |
| 256K tokens | 28 | 13.5 GB / 16 GB | ~57 tok/s |
Medido el 20 de septiembre de 2026 sobre un prompt de 6,317 tokens.
Flags clave: --ubatch-size 2048 + --batch-size 2048 +
--threads-batch 16 + --load-mode none
La velocidad de generación es casi constante de 64K a 256K tokens.
Por qué: GQA con solo 2 KV heads hace que el cache crezca muy lentamente. Más contexto, casi el mismo costo de memoria.
| Configuración | Velocidad (tok/s) | Prompt de referencia |
|---|---|---|
| Baseline | ~500 tok/s | 6,317 tokens |
| Optimizado (--ubatch-size 2048) | ~1,400 tok/s | 6,317 tokens |
Un sistema propio en Python puro (sin frameworks de agentes) para comparar modelos en tareas reales de programación con gates automáticos. Reproducible, auditado y extensible a cualquier task de negocio.
Haz clic en cada nodo para ver su descripción detallada.
| Agente | Modelo | Propósito | Credencial |
|---|---|---|---|
| obrero | Qwen3.6-35B-A3B, Q4_K_M | Titular — arquitectura hexagonal multi-fase | trampas 13/13 en 65s; hexagonal 7/7; fonda y lavandería 10/10 mypy limpio |
| obrero-mtp | Qwen3.6-35B-A3B + MTP activo | A/B vs obrero — medir speedup real de speculative decoding en MoE | Experimento en curso |
| qwen38 | Qwen3.8-27B, UD-Q3_K_XL (13.15 GB) | Aspirante/challenger — arquitectura hexagonal completa | Sin examinar — banco pendiente |
| peon | Gemma 4-E2B (~2B parámetros) | Micro-tasks, sin acceso bash | banco del peon 5/5 en 19s (primer perfecto) |
| chalan | — | Tier de ayudante | — |
| qwen38-mtp | Qwen3.8-27B + MTP | A/B vs qwen38 | — |
Presiona ▶ para ver la ejecución simulada paso a paso.
Cuatro conclusiones técnicas concretas, derivadas de la experimentación directa.
35B parámetros en un GPU de 16 GB — posible porque solo 8 de 256 expertos (~3B parámetros activos) se activan por token. El router de MoE convierte un modelo gigante en uno eficiente en tiempo de inferencia. Sin esta arquitectura, este experimento no sería posible con este hardware.
Speculative decoding con los draft weights MTP embebidos en el modelo se implementó como experimento A/B (obrero vs obrero-mtp). La documentación de Unsloth advierte que los MoE normalmente no se benefician de MTP — el benchmark medirá si hay ganancia real o es neutral en este caso concreto.
Con GQA (solo 2 KV heads vs 16 de atención completa), el KV cache crece a una fracción del costo normal. Por eso 256K tokens corre a ~57 tok/s — casi idéntico a 128K (~56 tok/s). El cuello de botella no es el contexto, sino la VRAM total disponible para el modelo.
De ~500 tok/s a
~1,400 tok/s en prompts de código
(6,317 tokens) solo ajustando --ubatch-size 2048 y
--threads-batch 16. El micro-batch size controla cuántos tokens se
procesan en paralelo antes de una inferencia — un parámetro ignorado por defecto
que tiene impacto directo en el tiempo hasta primer token.
Tres vectores concretos donde esta infraestructura resuelve problemas reales del sector.
Análisis de contratos, interpretación de normativas internas, soporte a equipos legales y de riesgo con documentos sensibles — sin enviar nada fuera del perímetro corporativo. El modelo corre en infraestructura propia con acceso restringido. Secreto bancario garantizado por arquitectura, no por política.
Extracción estructurada de datos de estados de cuenta, informes regulatorios y documentación de créditos. El harness actúa como pipeline reproducible y auditado: cada ejecución tiene gates verificables, historial de turnos y conteo exacto de tokens. Trazabilidad completa para auditoría interna.
El harness como "banco de pruebas" reproducible: comparar modelos sobre tasks reales de negocio antes de adoptarlos, con métricas concretas — gates pasados, turnos utilizados, tokens consumidos, tiempo de ejecución. Decisiones de adopción basadas en datos, no en benchmarks de marketing.
AI Engineer — GenAI, ML, FastAPI, AWS
Este laboratorio documenta trabajo técnico real — no tutoriales ni demostraciones sintéticas. Cada número en este reporte fue medido en el hardware listado.
Ver portafolio completo →