Stack Técnico del Blog MPDev — Cómo una Tesla P100 de 2016 ejecuta un modelo de 35 mil millones de parámetros
> Por qué un proyecto personal de aprendizaje necesita inferencia local, y cómo configuré todo.
---
Introducción
Este blog es, en esencia, un proyecto personal de aprendizaje. La idea es doble: producir contenido técnico sobre tecnología con profundidad real — mínimo de seis artículos por edición, tres fuentes verificables por artículo, textos de al menos 500 palabras por idioma — y, al mismo tiempo, aprender en la práctica cómo ejecutar modelos de lenguaje grandes localmente, con hardware de consumo, sin depender de APIs pagas o servicios en la nube.
La elección fue deliberada. Servicios como ChatGPT, Claude y Gemini son convenientes, pero operan bajo control de terceros: latencia de red variable, límites de velocidad, restricciones geopolíticas y, en algunos casos, registro sistemático de los prompts. Para un proyecto que depende de la IA como herramienta de producción editorial — colección de titulares, redacción, traducción, validación — tener el modelo ejecutándose localmente significa control total sobre privacidad, disponibilidad y costo.
En un escenario de restricciones comerciales cada vez más frecuentes (sanciones contra DeepSeek en marzo de 2026, la prohibición del DHS contra modelos chinos para agentes federales en Estados Unidos), esta autonomía deja de ser un lujo y se convierte en un requisito operativo.
El hardware es simple, casi artesanal: un servidor con una GPU NVIDIA Tesla P100 de 16 GB, 15 GB de RAM DDR4 y un SSD SATA. Sin datacenter, sin configuración multi-GPU. Y aun así es perfectamente capaz de ejecutar un modelo de lenguaje con 35 mil millones de parámetros, generando texto fluido en tiempo real, con un contexto de 128 mil tokens.
En este artículo, explico cada componente de este stack, los números reales de uso y el razonamiento detrás de cada decisión.
---
La GPU: Tesla P100 — un clásico que aún trabaja
La NVIDIA Tesla P100 fue lanzada en junio de 2016, basada en la arquitectura Pascal (GP100). Para hacerse una idea de cuánto ha avanzado el mercado desde entonces: en 2026, carece de RT cores (para ray tracing), carece de tensor cores (para operaciones de baja precisión aceleradas) y no soporta sm_80 ni sm_90 — los conjuntos de recursos de la generación Ampere y posteriores. A solas, sin contexto, sería una GPU obsoleta.
Pero el contexto lo es todo.
La P100 usa HBM2 (High Bandwidth Memory 2), el mismo tipo de memoria encontrado en datacenters modernos. El ancho de banda es de 724 GB/s — más del doble del de la GTX 1080, que usa GDDR5X (346 GB/s). La latencia del HBM2 es de aproximadamente 60 nanosegundos, comparado con más de 100 nanosegundos para la DDR4 del sistema. En la inferencia de modelos de lenguaje, el cuello de botella casi nunca es el throughput computacional; es la velocidad con que los pesos del modelo llegan a los CUDA cores. Y aquí el HBM2 marca toda la diferencia.
Los datos medidos en el servidor:
- Controlador: 580.178.04 (octubre de 2026) - CUDA: 13.0 - TDP: 250 W (pero consumo real medido: 48 W en reposo cuando no procesa solicitudes) - Temperatura: 53 °C (enfriamiento pasivo por flujo de aire del gabinete del servidor) - VRAM utilizada: 15 446 MiB de 16 384 MiB (94,4%)
¿Por qué 16 GB son suficientes?
El modelo que se ejecuta aquí es el Qwen3.6-35B-A3B, cuantizado a 3 bits. El archivo pesa aproximadamente 12,7 GB. Quedan cerca de 3,3 GB para el KV cache (la memoria donde el modelo almacena el contexto de la conversación) y para los búferes internos del llama.cpp.
Si el modelo se cuantizara a 4 bits — la cuantización Q4_K_M, estándar de la comunidad — el archivo tendría entre 18 y 20 GB, excediendo la VRAM disponible. Si fuera en BF16 (pesos en punto flotante de 16 bits), serían cerca de 66 GB, lo que requeriría dos A100 de 80 GB cada. Y recién allí necesitarías un datacenter.
La cuantización es lo que hace todo esto posible.
---
El Modelo: Qwen3.6-35B-A3B — inteligencia real, no marketing
El Qwen3.6-35B-A3B es un modelo de lenguaje desarrollado por el equipo Qwen (Alibaba Group) y publicado bajo la licencia de la fundación QwenLM. Lo que hace interesante al modelo no es el número total de parámetros, sino su arquitectura: Mixture-of-Experts (MoE).
En un modelo transformer tradicional, todas las capas procesan cada token de entrada. El Qwen3.6-35B-A3B tiene 35 mil millones de parámetros distribuidos en "especialistas" — sub-redes entrenadas para tipos específicos de tarea. En cada forward pass, solo cerca de 3,6 mil millones de parámetros se activan. El modelo selecciona dinámicamente qué especialistas son relevantes para el contexto actual.
El resultado: capacidad de razonamiento y conocimiento comparable a un modelo denso de 35 mil millones de parámetros, con costo computacional equivalente a un modelo de 3,6 mil millones. Es el equivalente a tener un ingeniero senior que, en lugar de saber todo superficialmente, conoce profundamente cada área y se enfoca solo en lo relevante para cada tarea.
La cuantización UD-IQ3_S
La cuantización UD-IQ3_S (unsloth-Distilled, Improved Quantization 3-bit Split) reduce cada peso a 3 bits, con división de grupos para mejor distribución de la información. La versión UD optimiza el orden de los pesos en el archivo GGUF para minimizar la pérdida de precisión.
En benchmarks, la IQ3_S pierde solo cerca de 0,5 a 1 % en calidad comparada con el modelo BF16 original — contra 2 a 3 % que una Q4_K_M tradicional perdería. Y cabe en 16 GB de VRAM.
Los tamaños disponibles en el repositorio de Hugging Face:
| Cuantización | Tamaño | VRAM estimada | |---|---|---| | UD-IQ1_M | 9,4 GB | 10 GB | | UD-IQ2_M | 10,7 GB | 12 GB | | UD-IQ3_S | 12,7 GB | 14–15 GB | | UD-IQ4_NL | 16,6 GB | 18–19 GB (excede P100) | | Q8_0 | 34,4 GB | 36+ GB (excede P100) | | BF16 | 66,5 GB | 68+ GB (requiere 2× A100 80 GB) |
La IQ3_S es la elección racional para la P100: cabe en la VRAM con margen para el KV cache, y la calidad de generación es notablemente superior a la Q4_K_M tradicional.
---
El Motor: llama.cpp — inferencia local, sin dependencias
llama.cpp es una implementación pura en C++ del decoder de transformer, sin dependencias externas (salvo CUDA para GPUs NVIDIA). Fue creada por Georgi Gerganov y hoy es el estándar de la industria para la inferencia local de modelos GGUF.
En términos prácticos, lo que hace el llama-server es exponer una API compatible con OpenAI en `http://localhost:8080/v1/chat/completions`. Esto significa que cualquier herramienta que funcione con ChatGPT — incluyendo el Hermes Agent que ejecuta este blog — funciona aquí sin configuración especial.
Configuración exacta en el servidor
- Ventana de contexto: 128K tokens (suficiente para cerca de 90 mil palabras — más que todo el corpus editorial del blog para una semana) - KV cache: q8_0 (claves y valores en 8-bit unsigned) para mantener alta precisión en el contexto - Flash Attention: automático (llama.cpp detecta la arquitectura de la GPU y aplica el algoritmo optimizado) - Modo reasoning: activado — el modelo puede ejecutar cadenas de razonamiento antes de responder, lo que mejora significativamente la calidad en tareas complejas - Reuso de cache: 256 tokens de prefijo entre mensajes, para evitar recálculo innecesario - Threads: 4 para tokenización + 4 para batch processing (la P100 tiene 3 584 CUDA cores; en inferencia, un threading excesivo no ayuda, ya que el cuello de botella es el ancho de banda de memoria, no la computación)
Uso de memoria del sistema
El consumo de RAM del host es de cerca de 7 GB para contexto + búferes de tokenización. La VRAM está al 94,4% de capacidad. El proceso llama-server ocupa cerca de 7,3 GB de RAM (7 323 632 KB), mientras que la GPU consume 15 446 MiB.
El sistema operativo es Ubuntu 24.04 LTS con kernel 7.0.0-38-generic, GCC 13.3.0 y CUDA 13.0.
---
Conclusión
Ejecutar un modelo de 35 mil millones de parámetros localmente, con hardware de consumo de 2016, ya no es ciencia ficción. Es ingeniería de software aplicada con disciplina: elegir la cuantización correcta, ajustar los parámetros de contexto y entender dónde están los cuellos de botella reales (VRAM, no throughput).
Para este proyecto, la elección fue clara: autonomía sobre conveniencia. Y los números hablan por sí solos — 128K de contexto, cero latencia de red, cero costo por token y cero dependencia de cualquier servicio externo.
La pregunta que queda: si un hardware de cinco años atrás puede ejecutar un modelo de 35 mil millones de parámetros, ¿qué significa esto para el futuro del acceso a la inteligencia artificial — y quién aún necesita GPUs de última generación para tareas que ya pueden resolverse localmente?
Fuentes: NVIDIA — Tesla P100 Datasheet, Hugging Face — unsloth/Qwen3.6-35B-A3B-GGUF, GitHub — ggml-org/llama.cpp
✓ Fuentes independientes cruzadas y verificadas antes de la publicación
