## Objetivo de la documentación
Proveer una guía exhaustiva para seleccionar e implementar modelos de lenguaje pequeños locales (sLLM) en un entorno de servidor únicamente con CPU, memoria RAM limitada (2-3 GB en picos) y 4 núcleos lógicos.  
El documento debe comparar las opciones de carga y ejecución mediante tokenizadores/PyTorch frente a Ollama, identificar los modelos open source más livianos y eficientes que compitan con los modelos Gemma-270M (base, instrucción y orientado a funciones), y presentar métricas de rendimiento, consumo de recursos y degradación de calidad en versiones cuantizadas.  
Se enfoca en tareas específicas (resúmenes, decisiones simples, listado de ítems/objetivos, categorización), no en chat general.

## Audiencia y nivel técnico
- **Perfil**: Desarrolladores, operadores de sistemas o DevOps que necesiten integrar un sLLM en servicios ligeros.
- **Conocimientos esperados**:  
  - Manejo básico de Python y terminal.  
  - Familiaridad con el concepto de tokenización y modelos de lenguaje.  
  - Conocimiento general de cuantización (int8, int4, GGUF) y de los ecosistemas Hugging Face Transformers y llama.cpp.  
  - Capacidad para seguir instrucciones de instalación y modificar scripts simples.
- **No se requiere** experiencia avanzada en ML, fine-tuning o infraestructura GPU.

## Alcance y versiones
- **Versión/contexto temporal**: Se documentan modelos y herramientas disponibles y proyectadas a principios de 2026, tomando como base el estado del arte actual y las tendencias de miniaturización.  
- **Incluye**:  
  - Modelos locales open source con ≤ ~500M parámetros, comparables o inferiores en tamaño a Gemma-270M.  
  - Cuantizaciones (GGUF, int8, int4) viables para CPU.  
  - Métodos de inferencia: PyTorch (Transformers) + tokenizador, y Ollama (basado en llama.cpp).  
  - Análisis de rendimiento en CPU de 4 núcleos, uso máximo de RAM ≤ 3 GB.  
  - Tareas: resumen breve, clasificación, extracción de listas, decisiones binarias/lógicas simples.  
  - Ventana de contexto, velocidad (tokens/s), latencia, pico de memoria y fidelidad post-cuantización.  
- **Excluye**:  
  - Modelos con GPUs, aceleradores externos o APIs en la nube.  
  - Entrenamiento, fine-tuning o RLHF.  
  - Modelos no open source o con licencias restrictivas para uso comercial si no se especifica.  
  - Evaluación de tareas de chat o generación libre de texto extenso.

## Estructura del documento
1. **Introducción y motivación**  
   Justificación del uso de sLLM en CPU, descripción del problema y objetivos.
2. **Requisitos de hardware y restricciones**  
   Especificación de la máquina de pruebas (4 CPU, 2-3 GB RAM) y cómo se simulan las condiciones.
3. **Metodología de evaluación**  
   Métricas (velocidad, memoria, fidelidad), conjunto de tareas, scripts y forma de medición.
4. **Modelos candidatos**  
   Listado de modelos ≤ 500M parámetros (SmolLM, TinyLlama reducido, Pythia, OPT-125M, MobileLLM, etc.) y sus versiones cuantizadas.
   - Incluye la familia Gemma-270M (base, -it, function-calling).
5. **Comparativa de métodos de carga e inferencia**  
   - PyTorch + Tokenizadores (código mínimo con Transformers).  
   - Ollama (importación de GGUF, ajustes de contexto y CPU).  
   Tabla resumen de pasos, complejidad y compatibilidad.
6. **Benchmarks detallados**  
   - Rendimiento bruto (tokens/s) según tarea y método.  
   - Consumo de RAM pico por modelo y técnica de cuantización.  
   - Degradación de calidad (pérdida de exactitud o coherencia) al pasar de FP16 a Q4_K_M, Q5_K_M, etc.  
   - Comparación de ventanas de contexto efectivas (hasta 2048, 4096 tokens).  
   - Resultados con tareas de categorización, resúmenes, lógica switch/listado.
7. **Guía de implementación**  
   - Instalación y configuración de Ollama con modelos GGUF.  
   - Carga de modelos con PyTorch y tokenizadores asociados.  
   - Ejemplos de código para inferencia y consumo de resultados.  
   - Consideraciones de memoria: cómo limitar picos, recomendar swap, etc.
8. **Recomendaciones y mejores prácticas**  
   - Elección óptima según tipo de tarea y prioridad (velocidad vs. calidad).  
   - Estrategia para múltiples modelos según función (uno para clasificar, otro para resumir).  
   - Plan de actualización hacia 2026.
9. **Apéndices**  
   - Scripts de benchmark completos.  
   - Enlaces de descarga de modelos GGUF y checkpoints.  
   - Referencias a artículos y fuentes de métricas utilizadas.

## Aspectos técnicos a investigar
1. **Modelos ultra pequeños**  
   - Identificar modelos open source ≤ 270M parámetros (o variantes cuantizadas que quepan en RAM) con buen desempeño en tareas de lenguaje natural, lógica simple, extracción.  
   - Verificar licencias compatibles.  
   - Obtener valores de referencia: puntaje en benchmarks como MMLU-pro-small, Hellaswag, o evaluaciones custom de resumen/completado.
2. **Versiones de Gemma-270M function-calling**  
   - Confirmar existencia de un modelo fine-tuneado para llamadas a funciones dentro de la familia Gemma-270M, o alternativas equivalentes (por ej., SmolLM con Toolformer).
3. **Cuantizaciones**  
   - Cuantizaciones GGUF estándar (Q2_K, Q3_K_M, Q4_K_M, Q5_K_M, Q8_0) y su impacto en calidad y velocidad.  
   - Cuantizaciones en PyTorch (int8 dinámico, int4 con bitsandbytes) y cómo se comparan en CPU (sin GPU).
4. **Inferencia en CPU con PyTorch vs. llama.cpp**  
   - Medir con precisión tokens/s en varios modelos en el hardware objetivo (4 núcleos, sin GPU).  
   - Overhead de tokenizadores separados vs. integrados en Ollama.  
   - Consumo de hilos y afinidad.
5. **Ventana de contexto**  
   - Capacidad real de los modelos listados (hasta 2048 o más), y cómo la cuantización la afecta.
6. **Evaluación de calidad en tareas concretas**  
   - Crear un pequeño dataset de resúmenes, decisiones switch, lista de ítems y categorización para medir precisión y fidelidad.  
   - Comparar resultados entre el modelo base y su versión cuantizada.
7. **Tendencias 2026**  
   - Proyección de nuevos modelos (Phi-1.5, TinyLlama v2) que puedan ser aun más eficientes.  
   - Herramientas como llamafile, exlamav2, o mejoras en Ollama que modifiquen el panorama.

## Convenciones
- **Formato de código**: Python con type hints visibles; Bash con `$ sudo ...`. Se usará `pip` para instalar dependencias.
- **Nomenclatura de modelos**: `Modelo-Tamaño[Variante]` (ej. SmolLM-135M, Gemma-270M-it). Las cuantizaciones se indican con sufijos GGUF (ej. `SmolLM-135M-Q4_K_M.gguf`).
- **Notas**: Bloques `> ⚠️` para advertencias sobre memoria o incompatibilidades. `> ℹ️` para aclaraciones.
- **Métricas**:  
  - Throughput: tokens por segundo en generación (token/s).  
  - RAM: pico en MB/GB medido con `psutil` o similar.  
  - Calidad: puntaje en escala normalizada (0-100%) para cada tarea.
- **Diagramas**: Se empleará Mermaid para flujos de arquitectura (carga del modelo, pipeline de inferencia) y árboles de decisión de selección de modelo.

## Entregable esperado
Un documento técnico monolítico en formato Markdown (listo para ser publicado en una wiki o repositorio) que incluya:
- Todos los capítulos detallados en la estructura.
- Tablas comparativas con valores reales obtenidos tras la investigación.
- Fragmentos de código listos para copiar y ejecutar.
- Diagramas Mermaid que expliquen los flujos de prueba y despliegue.
- Una sección de conclusiones con la recomendación fundamentada para el escenario descrito (CPU limitada, 2-3 GB RAM, tareas específicas).