Contenido detallado
📏 Ventana de contexto en la práctica
A ventana de contexto es cuánto contenido «lee de una vez» el modelo antes de responder: tu pregunta, el historial del chat y cualquier texto que pegues. Si la ventana es pequeña, el modelo «olvida» el comienzo de la conversación. Si es demasiado grande, consume memoria sin necesidad.
🆕 ¿Eres nuevo por aquí?
"Ventana de contexto" = el límite de tokens que entran de una vez (p. ej., 8192 = ~6 mil palabras). En Ollama, este es el parámetro num_ctx. "Token" = un fragmento de una palabra; ~4 caracteres en promedio. "KV cache" = la memoria de trabajo que el modelo construye para cada token del contexto; crece junto con num_ctx y es lo que hace que un contexto largo pese en la VRAM.
Decidir el tamaño de la ventana es un equilibrio en tres pasos:
Empieza por el estándar
Muchos modelos vienen con num_ctx de 2048 o 4096. Para el chat y las preguntas cortas, eso ya basta: no lo cambies solo por cambiar.
Aumenta cuando la tarea lo requiera
¿Vas a pegar un documento largo, mucho código o un historial extenso? Sube a 8192, 16384 o más, siempre que el modelo admita ese límite.
Paga el precio en memoria
Duplicar la ventana ≈ duplicar la caché KV. Si se agota la VRAM, el modelo descarga capas a la CPU y se vuelve lento, o simplemente da sin memoria.
💡 Consejo práctico
No actives 128k de contexto «por si acaso». Si normalmente haces preguntas cortas, una ventana de 4k–8k responde más rápido y libera VRAM para las capas del modelo — que es lo que más importa para la calidad.
🌡️ Temperatura, top_p y top_k
Con cada token, el modelo tiene varias palabras candidatas. Temperatura, top_p e top_k deciden cuánto se arriesga al elegir. Estos tres botones controlan el eje preciso ⟷ creativo.
🆕 ¿Eres nuevo por aquí?
- Temperatura — qué tan «creativo/aleatorio» es el modelo. Un valor bajo (0–0.3) = determinista y repetible; uno alto (0.8–1.2) = diverso y sorprendente.
- top_p (nucleus) — recorta la cola: solo considera las palabras que suman, por ejemplo, el 90% de la probabilidad (top_p 0.9).
- top_k — limita la elección a las k palabras más probables (top_k 40). Ajusta primero la temperatura; top_p/top_k son ajustes finos.
📋 Recetas por tarea
| Tarea | temperatura | top_p | Por qué |
|---|---|---|---|
| Código / SQL | 0.1–0.2 | 0.9 | precisión y respuestas reproducibles |
| Extracción / JSON | 0.0–0.2 | 0.8 | formato rígido, sin inventar campos |
| Chat / explicación | 0.5–0.7 | 0.9 | natural, pero aún enfocado |
| Lluvia de ideas / creativo | 0.9–1.2 | 0.95 | diversidad, ideas inesperadas |
✓ Para qué sirve una temperatura baja
- ✓Generar código que debe compilar
- ✓Extraer datos en un formato fijo
- ✓Respuestas que siempre deben ser iguales
- ✓Clasificación y enrutamiento
✓ Para qué sirve una temperatura alta
- ✓Generar muchas variaciones de una idea
- ✓Textos de marketing y títulos
- ✓Romper la repetición y las respuestas «rígidas»
- ✓Ficción y guiones
🎭 System prompt: dirigiendo el modelo
Antes de cualquier pregunta, el system prompt le dice al modelo quién es e cómo debe responder. Es la herramienta más barata para mejorar la calidad: si está bien escrito, corrige la verbosidad, el formato y el tono sin que tengas que cambiar de modelo.
🆕 ¿Eres nuevo por aquí?
"System prompt" es una instrucción fija, separada de tu mensaje, que se aplica a toda la conversación. Piensa en ella como el «cargo y las reglas del empleado»: define papel (qué es), formato (cómo entrega) y restricciones (qué no puede hacer).
🧱 Los tres bloques de un buen system prompt
- •Rol: "Eres un asistente técnico conciso para desarrolladores."
- •Formato: "Responde en un máximo de 5 líneas. Usa viñetas al enumerar pasos."
- •Restricciones: "Si no lo sabes, di que no lo sabes. No inventes comandos."
⌨️ Ejemplo práctico: un «asistente técnico conciso»
Objetivo: un system prompt reutilizable que pegas en cualquier modelo (Ollama, Open WebUI, API) para obtener respuestas cortas y directas. Guárdalo como system.txt o úsalo en el Modelfile.
Cómo usarlo en Ollama (Modelfile):
Cómo verificar: haz la misma pregunta al modelo base y al técnico. El segundo debería responder de forma mucho más breve y directa, sin el "¡Claro! Aquí está...".
🧩 Offload de GPU/CPU y capas
Un modelo es una pila de capas. Lo ideal es que todas quepan en la GPU, donde se ejecutan rápido. Cuando no caben, el runtime se desborda las que quedan para la CPU — y esas son mucho más lentas. El parámetro que controla esto es el num_gpu.
🆕 ¿Eres nuevo por aquí?
"Offload" = trasladar parte del trabajo de la GPU a la CPU. "num_gpu" (en Ollama) = cuántas capas del modelo se colocan en la GPU; el resto va a la CPU/RAM. Más capas en la GPU = más rápido, desde que que quepan en la VRAM. Si fuerzas demasiadas capas y la VRAM se desborda, se convierte en sin memoria.
Lee de izquierda a derecha: las 7 primeras capas (morado) cupieron en la GPU y vuelan; las 3 que sobraron (cian) se desbordan hacia la CPU y reducen la velocidad. Sube num_gpu mueve el límite hacia la derecha — hasta que se llene la VRAM.
✓ Offload equilibrado
- ✓Caen todas (o casi todas) las capas en la GPU
- ✓Queda VRAM para la KV cache del contexto
- ✓Eligió una cuantización (Q4_K_M) que cabe holgadamente
- ✓tokens/s estable y predecible
✗ Offload mal ajustado
- ✗La mitad de las capas terminó en la CPU
- ✗num_gpu demasiado alto → falta de memoria
- ✗El modelo es demasiado grande para la VRAM disponible
- ✗La velocidad cae con cada token
💡 Consejo práctico
Ollama intenta detectar el offload automáticamente — en la mayoría de los casos, déjalo en automático. Solo ajusta num_gpu manualmente si quieres que quepa un modelo un poco más grande (reduciendo algunas capas a propósito) o si ejecutas dos cosas en la misma GPU.
⚡ Caché KV, batch y rendimiento
La velocidad no depende solo de tener una "buena GPU". Tres cosas afectan la tokens/s: cuánta memoria consume el KV cache, el tamaño del batch y dónde están las capas. Aquí reúnes los parámetros en un solo lugar — mediante API.
📊 Qué acelera × qué ralentiza
- ✓Modelo que cabe por completo en la GPU
- ✓Ventana de contexto del tamaño justo
- ✓Cuantización de la caché KV (q8/q4) para liberar VRAM
- ✓Mantener el modelo «caliente» (cargado) entre llamadas
- ✗Capas que se desbordan hacia la CPU
- ✗num_ctx gigante "por si acaso"
- ✗Intercambio en disco cuando se llena la RAM
- ✗Recargar el modelo en cada solicitud
🆕 ¿Eres nuevo por aquí?
"Batch" = cuántos tokens procesa el modelo de una vez durante la fase de lectura del prompt; un batch más grande acelera los prompts largos, pero usa más memoria. "Cuantización de la caché KV" = almacenar la memoria de trabajo con menor precisión (p. ej., q8_0) para que quepa más contexto en la misma VRAM, con una pérdida mínima.
⌨️ Ejemplo práctico: parámetros mediante la API de Ollama
Objetivo: ejecutar una generación controlada, pasando la temperatura y la ventana de contexto juntas en el campo options. Pégalo en la terminal (Ollama debe estar en ejecución).
Cómo verificar: ejecuta el mismo comando dos veces. Con temperature:0.2 las respuestas salen casi idénticas (determinista). Cámbialo a 1.0 y repite: ahora varían mucho más. El campo eval_count / eval_duration la respuesta JSON te da los tokens/s.
🩺 Diagnóstico: ¿por qué está lento o funciona mal?
Cuando el resultado decepciona, el problema casi siempre es uno de estos cuatro sospechosos: un modelo demasiado grande, una cuantización demasiado agresiva, un contexto enorme o el uso de swap en disco. Esta lista de verificación distingue entre «está lento» y «está mal».
✗ Síntoma: está LENTO
- ✗Modelo demasiado grande → capas en la CPU
- ✗num_ctx enorme → el KV cache agotó la VRAM
- ✗RAM llena → intercambio a disco
- ✗El modelo se vuelve a cargar en cada llamada
✓ Cómo resolver lo LENTO
- ✓Baja un tamaño (14B → 7B) o un nivel de cuantización
- ✓Reduce num_ctx a lo que exige la tarea
- ✓Cierra las apps que consumen RAM; verifica con ollama ps
- ✓Mantén el modelo cargado (keep-alive)
✗ Síntoma: está MAL
- ✗Cuantización agresiva (Q2/Q3) → respuestas frágiles
- ✗Temperatura alta en una tarea que requiere precisión
- ✗Sin prompt del sistema → el modelo «se va por las ramas»
- ✗Contexto corto → olvida el inicio
✓ Cómo resolver lo MALO
- ✓Pasa a Q4_K_M/Q5_K_M (el punto ideal)
- ✓Baja la temperatura a 0.1–0.2
- ✓Agrega un system prompt claro (tema 3)
- ✓Aumenta num_ctx lo suficiente para la conversación
Autoevaluación (opcional): necesitas generar SQL que siempre sea igual y correcto. ¿Qué ajuste tiene más sentido?
📌 Resumen del módulo
Siguiente módulo:
3.5 — Sirviendo mediante API local