Evaluación de modelos de IA

Contexto

El jefe (Electrosystems) quiere ver qué modelos de IA pueden correr en laptop-ia y cuáles dan calidad útil para futuros proyectos de la empresa — más allá del agente de WhatsApp de projects-hub. La premisa es: probar local primero, sin servicios cloud, sobre la infraestructura que ya existe (RTX 4060 Mobile 8 GB VRAM, 62 GB RAM, i9-13900HX).

Este proyecto es el lugar para capturar cada experimento: qué modelo, cuánto pesa, cuánto rinde en este hardware, qué tan buena es la respuesta, y para qué tipo de tarea sí o no sirve. Las decisiones de qué modelo usar en producción (en projects-hub o en proyectos futuros) salen de aquí.

Tareas pendientes

• #103 📅 2026-06-09 — Probar gemma4:26b en tareas multimodales (mandarle una imagen — foto de un equipo de red, screenshot, diagrama — y medir calidad).
• (2026-05-13) Investigar si Gemma 4 permite desactivar el thinking — OpenClaw expone reasoning: false en el model entry; ver bitácora 2026-05-13.
• (2026-05-13) Probar tool/function calling con gemma4:26b — funcionó vía OpenClaw con 19 tools registrados, contestó OK al bot de Telegram.
• #102 📅 2026-06-11 — Comparativa de latencia y calidad: qwen2.5:14b-instruct vs gemma4:26b con el mismo prompt en español, con num_ctx=8192 en ambos.
• #105 📅 2026-06-13 — Decidir si vale la pena instalar también gemma4:31b dense para tener referencia de techo de calidad (a costa de latencia muy alta).
• (2026-05-13) Documentar techo de hardware de laptop-ia — ver sección “Techo real de gemma4:26b en este host” abajo.
• #101 📅 2026-06-15 — Aplicar Tier 3 en Ollama (OLLAMA_FLASH_ATTENTION=1 + OLLAMA_KV_CACHE_TYPE=q8_0) — necesita sudo, no aplicado. Esperar ventana con Sergio en sesión local.
• #104 📅 2026-06-18 — Caracterizar gemma4:latest (4B edge) como fallback rápido para chat conversacional cuando no se necesite razonamiento multimodal.

En progreso

• gemma4:26b configurado como modelo principal de un agente OpenClaw conectado a Telegram (proof-of-concept de assistant local con tools).
• Caracterización de performance real de gemma4:26b bajo carga de agente (vs smoke test plano de 2026-05-12).

Notas técnicas

Hardware disponible (laptop-ia)

• CPU: i9-13900HX (32 threads)
• GPU: RTX 4060 Mobile, 8 GB VRAM ← el cuello de botella
• RAM: 62 GB + 8 GB swap
• Storage: 1.5 TB NVMe, ~78 GB usado (al 2026-05-12)
• Runtime: Ollama 0.20.4

Techo práctico en este host:

• Densos hasta ~14B caben casi enteros en VRAM → fluido (~30–50 tok/s).
• MoE 20–30B (tipo Gemma 4 26B A4B) funcionan con offload parcial → 10–15 tok/s.
• Densos 27–70B corren pero lentos (3–6 tok/s) — útiles para batch, no para chat.
• >100B no son viables en este hardware sin pasar todo a CPU (1–2 tok/s).

Modelos evaluados

Techo real de gemma4:26b en este host (medido 2026-05-13)

• Pesos Q4_K_M en memoria: ~17 GB. KV cache para 8K ctx: ~1-2 GB. Total residente: ~19 GB.
• VRAM utilizable de la RTX 4060 Mobile: ~7.5 GB de 8 GB (resto se lo come desktop + drivers).
• Resultado: Ollama reporta 83% CPU / 17% GPU para gemma4:26b @ num_ctx=8192. No es problema de config — es VRAM insuficiente. No hay manera de bajar el porcentaje de CPU offload sin (a) reducir el modelo o (b) más VRAM.
• Margen restante por software: Tier 3 (OLLAMA_FLASH_ATTENTION=1 + OLLAMA_KV_CACHE_TYPE=q8_0) puede liberar ~50% del KV cache y dar +20-30% tok/s. Requiere sudo; no aplicado todavía.

Mensaje para el jefe: gemma4:26b corre en laptop-ia y responde con calidad, pero la velocidad nativa de este modelo (40-60 tok/s) requiere ≥20 GB de VRAM. En la RTX 4060 Mobile (8 GB) el techo realista es 10-15 tok/s en uso plano y 2-5 tok/s bajo carga de agente con tools. Para velocidades de producción → hardware con RTX 3090/4090/A5000 o equivalente.

Conexión a laptop-ia

• SSH alias: laptop-ia (configurado en ~/.ssh/config local).
• Usuario: gchavira. Sin passwordless sudo.
• Ollama API local: http://localhost:11434 (loopback, no expuesta).
• Para correr inferencia: ssh laptop-ia 'ollama run <tag> "..."' o vía la API HTTP.

Comandos útiles

# Listar modelos instalados
ssh laptop-ia 'ollama list'

# Metadata de un modelo (capabilities, context length, cuantización)
ssh laptop-ia 'ollama show <tag>'

# Smoke test con timing
ssh laptop-ia 'ollama run --verbose <tag> "prompt"'

# Liberar VRAM/RAM si se quedó cargado
ssh laptop-ia 'ollama stop <tag>'

# Eliminar un modelo del disco
ssh laptop-ia 'ollama rm <tag>'

Ver también

• projects-hub/STACK.md — stack actual que consume modelos locales.
• ~/agy/electrosystems/servers/laptop-ia/fixes.md — log operativo de cambios en el host (instalaciones, smoke tests con métricas crudas).

Bitácora

2026-05-12 — Instalación y smoke test de gemma4:26b

• Origen del pedido: el jefe vio Gemma 4 en redes sociales (TikTok) y la captura del gráfico “Model Performance VS Size” de deepmind.google que muestra gemma-4-31B-thinking y gemma-4-26B-A4B-thinking. Quería evaluar capacidades para futuros proyectos de IA en la empresa, no específicamente para projects-hub.
• Decisión: instalar la variante MoE 26B en lugar de la dense 31B porque calza mucho mejor con la VRAM de la RTX 4060 Mobile (8 GB). El 31B local sería funcional pero frustrante por latencia. Cloud (gemma4:31b-cloud) descartado por la regla “solo local”.
• Pull: ollama pull gemma4:26b en tmux en laptop-ia. Bajada de ~10 min, 17 GB, sha256 verify limpio.
• Metadata confirmada: 25.8B params totales (4B activos por token), Q4_K_M, contexto 256K, capabilities completion + vision + tools + thinking, Apache 2.0.
• Smoke test: prompt en español (“¿qué es una red WAN y cómo difiere de una LAN?”, máximo 4 oraciones). Resultado:
  • Velocidad de generación: 13.67 tok/s (más baja que la estimada de 25–40, por overhead de routing entre experts cuando no cabe entero en VRAM).
  • Total: 65 s para 4 oraciones porque el thinking generó ~840 tokens internos (planteó el problema, hizo dos drafts, verificó conteo de oraciones, hizo “Revised Final”).
  • Calidad de respuesta: correcta, técnica, exactamente 4 oraciones en español.
• Lectura:
  • No reemplaza a qwen2.5:14b-instruct para el agente de WhatsApp. Latencia ~1 min vs ~3–5 s — la diferencia se sentiría.
  • Sí es candidato para cargas async/batch: resúmenes multi-proyecto, análisis de documentos, generación de reportes semanales, evaluación de imágenes (es multimodal).
  • El modo “thinking” es la fuente principal de la latencia. Si se puede desactivar (como el /no_think de Qwen) cambia toda la ecuación. Pendiente investigar.
• Detalle operacional crudo (comandos, log del pull, montaje en tmux, problemas con tee/escape codes): ~/agy/electrosystems/servers/laptop-ia/fixes.md entrada 2026-05-12.

2026-05-13 — OpenClaw + Telegram + tuning de gemma4:26b bajo carga de agente

Pedido inicial: Sergio quería usar la opción “Launch OpenClaw” del menú de ollama pero el bot de Telegram que había conectado se quedaba en “Typing…” sin responder.

Hallazgos:

• OpenClaw es una integración nueva de Ollama (no un modelo). Subcomando ollama launch openclaw (alias clawdbot, moltbot) — Ollama 0.20.4 introduce un selector de integraciones: claude, cline, codex, droid, opencode, openclaw, pi, vscode.
• OpenClaw vive en /usr/bin/openclaw (v2026.5.7), state en ~/.openclaw/, gateway en 127.0.0.1:18789, web UI con token de auth en el URL.
• El config se persiste en ~/.openclaw/openclaw.json sea que se lance vía ollama launch openclaw o vía openclaw gateway directo — es el mismo backend.

Diagnóstico de la falla original (Bedrock sin credenciales):

• El trajectory de la sesión f58c832e-… mostró que la sesión de Telegram se ruteó a Amazon Bedrock (google.gemma-3-27b-it), no a Ollama. Sergio había corrido openclaw onboard antes y dejó Bedrock como primary.
• Error real: Could not load credentials from any providers. Telegram mostraba “Typing…” porque el bot manda sendChatAction(typing), intenta llamar Bedrock, falla con 0 tokens, no contesta.
• UI message: [assistant turn failed before producing content] — es error, no warning.

Cleanup aplicado (autorizado, “opción A — quitar Bedrock”):

plugins.allow                              ["telegram","amazon-bedrock","openclaw-web-search","ollama"] → ["telegram","ollama"]
plugins.entries.amazon-bedrock             removed
plugins.entries.openclaw-web-search        removed (se auto-reagrega al relanzar el TUI — paquete instalado sin compilar; warning inocuo)
agents.defaults.models                     { "amazon-bedrock/google.gemma-3-27b-it": {} } → {}

Backups: ~/.openclaw/openclaw.json.pre-cleanup.<ts> + el .bak rotativo que mantiene OpenClaw.

Segundo problema: lentitud extrema en Ollama (~0.6 tok/s).

• Después del cleanup, primary cambió a ollama/qwen2.5:14b-instruct. La primera respuesta llegó pero tardó ~64s para 37 tokens.
• Causa: contextWindow: 32768 en el config → KV cache ~6 GB + pesos 9 GB = 15 GB demand vs 8 GB VRAM → Ollama tira 81% CPU / 19% GPU. Esto es ortogonal a OpenClaw — es Ollama auto-deciding offload.

Tercer problema: el contextWindow no se traduce a num_ctx.

• Bajar contextWindow: 8192 no cambió el reporte de ollama ps (siguió en CONTEXT 262144, 100% CPU). El campo es metadata para budget de prompts en OpenClaw, no se envía a Ollama.
• Knobs reales del schema (openclaw config schema | jq …models.items.properties):

  contextWindow   integer   budget para OpenClaw, NO se envía a Ollama
  contextTokens   integer   ESTE sí va al runtime como num_ctx
  params          object    passthrough crudo de parámetros del provider
  reasoning       boolean   activa/desactiva el "thinking output" del modelo

• Solución redundante (3 capas) en el entry de gemma4:26b:

  "contextWindow": 8192,
  "contextTokens": 8192,
  "params": { "num_ctx": 8192 },
  "reasoning": false

• IMPORTANTE: después de cambiar num_ctx, hay que desalojar el modelo cacheado en Ollama (ollama stop gemma4:26b); de lo contrario Ollama mantiene la versión con el ctx anterior cargada en memoria y no recarga.

Resultado de la optimización:

• ollama ps después: gemma4:26b 20 GB 83%/17% CPU/GPU CONTEXT 8192.
• Tiempo de respuesta a “Hola” en Telegram: ~30s (vs 60s+ antes, y vs infinito en el caso Bedrock).
• El 83% de CPU offload es el techo de VRAM, no se mejora con config — ver “Techo real de gemma4:26b en este host” arriba.

Cuarto problema: el agente respondía en inglés.

• ~/.openclaw/workspace/USER.md, IDENTITY.md, SOUL.md estaban con el boilerplate inglés de la instalación. Sin context del usuario, Gemma 4 default a inglés.
• Edité USER.md con info de Sergio (nombre, timezone Cd. Juárez, idioma ES por default, tono directo sin relleno, contexto Electrosystems) + directriz explícita: “Responde siempre en español por default. Solo cambia a inglés si Sergio lo pide explícitamente o si el contexto técnico lo demanda”.
• El agente lee USER.md/IDENTITY.md/SOUL.md/AGENTS.md en el bootstrap de cada sesión (ver ~/.openclaw/workspace/AGENTS.md sección “Session Startup”).

Lo que queda pendiente:

• Aplicar Tier 3 (FA + KV quant) → necesita sudo en laptop-ia. Snippet listo:

  sudo systemctl edit ollama
  # En el editor:
  [Service]
  Environment="OLLAMA_FLASH_ATTENTION=1"
  Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
  # Guardar, salir, luego:
  sudo systemctl daemon-reload && sudo systemctl restart ollama
  ollama stop gemma4:26b   # desalojar para que recargue con FA + KV cuantizado

• Caracterizar gemma4:latest (4B edge) como fallback rápido para chat conversacional puro sin tools — debe caber entero en VRAM y dar 30+ tok/s.

Config final de OpenClaw (al cierre del día) — para replicar:

# Lanzar headless con modelo específico (evita el TUI interactivo):
ollama launch openclaw --yes --model gemma4:26b

# Donde vive el config:
~/.openclaw/openclaw.json

# Knobs por modelo en plugins.providers.ollama.models[]:
#   contextTokens / params.num_ctx → num_ctx real a Ollama
#   reasoning false                → sin <think> en la salida
#   contextWindow                  → solo budget interno de OpenClaw

# Identity files (leídos al inicio de cada sesión):
~/.openclaw/workspace/USER.md       ← preferencias del usuario, idioma, tono
~/.openclaw/workspace/IDENTITY.md   ← personalidad del agente
~/.openclaw/workspace/SOUL.md       ← guías de comportamiento
~/.openclaw/workspace/AGENTS.md     ← cómo trabaja con su workspace

Decisión operacional:

• OpenClaw queda como proof of concept funcional de agente local con tools sobre Ollama. Útil para mostrar al jefe que se puede tener un agente conectado a Telegram que use modelos locales.
• No es el camino para projects-hub productivo — la velocidad bajo carga de agente (2-5 tok/s) es inaceptable para un bot que conteste a clientes. Para eso se sigue usando qwen2.5:14b-instruct con prompt directo (sin tools complejos), o se espera a tener hardware mejor.
• gemma4:26b sí queda perfilado para tareas async (resúmenes, análisis de imágenes, batch) donde 30-60s de latencia no importa.