Auto-Plan Gemma 4: Thinking activado + 1120 tokens de imagen (receta s47d)
Auto-Plan Gemma 4: Thinking activado + 1120 tokens de imagen (receta s47d)
Sesión: 47d · Fecha: 2026-05-02 · Versión: v1.0.61+
Autor: @Esquembri (Edu) · Validación: prompt validado al 100 % por Edu en pruebas previas + advisor externo
Resumen
La receta s47d alinea todos los parámetros del cliente Auto-Plan con los defaults oficiales de Google para Gemma 4 y activa el modo hybrid-thinking. Hasta esta sesión, el cliente Python sobreescribía temperature=0.1 anulando el --temp 1.0 ya configurado en el systemd unit del servidor; además el thinking estaba forzosamente desactivado (enable_thinking: False). Ambos comportamientos quedan corregidos.
Cambios en el servidor (pve-epyc-02 · LXC 100)
Servicio: /etc/systemd/system/llama-server.service
| Parámetro | Antes (s47c) | Ahora (s47d) |
|---|---|---|
--image-min-tokens | 560 | 1120 |
--image-max-tokens | 2240 | 1120 |
| Rango dinámico | 560–2240 | fijo 1120 |
image_min_pixels / image_max_pixels | distintos | 2 580 480 (idénticos = 1120 tokens) |
chat template, thinking | — | = 1 |
Backup del unit anterior guardado como .bak.s47d. Resto de parámetros sin tocar: --temp 1.0, --top-p 0.95, --top-k 64, --flash-attn on, --jinja, --batch-size 4096, --ubatch-size 4096, --ctx 32768.
Verificación post-restart: image_min_pixels = image_max_pixels = 2 580 480, chat template, thinking = 1, /health OK.
Cambios en el cliente (blueprints/services/autoplan.py)
_analyze_with_ollama — parámetros de inferencia
# Antes (override explícito que anulaba el server)
temperature=0.1
"chat_template_kwargs": {"enable_thinking": False}
# Ahora (receta s47d — alineado con defaults Google)
temperature=1.0
"chat_template_kwargs": {"enable_thinking": True}
temperature0.1 → 1.0: el cliente ya no contradice el--temp 1.0del server. Ambos extremos alineados con los valores recomendados por Google.enable_thinking: True: activa el modo hybrid-thinking de Gemma 4. El modelo emite un bloque<|think|>…</|think|>con 4 pasos de razonamiento antes del JSON final.- Eliminados comentarios obsoletos sobre el Modelfile
gemma4-16kde la laptop (ya no aplica a llama-server).
_clean_llm_json — strip defensivo de bloques thinking
text = re.sub(
r"<\|?\s*think(?:ing)?\s*\|?>.*?<\|?\s*/\s*think(?:ing)?\s*\|?>",
"",
text,
flags=re.DOTALL | re.IGNORECASE
)
Cubre las cuatro variantes que puede emitir Gemma 4: <think>, <thinking>, <|think|>, <|thinking|>. Idempotente cuando no hay thinking. El bloque se descarta antes del find/rfind del JSON y nunca llega a la base de datos.
Nuevo prompt prompts/blueprint_analyst.md
El prompt anterior fue reemplazado completamente. El nuevo introduce:
| Elemento | Descripción |
|---|---|
| SYSTEM ROLE | “Expert Network Infrastructure Analyzer” — rol explícito al inicio |
| Peripheral Vision Methodology | Scan edges first → outer boundaries → slow down. Corrige el sesgo del modelo hacia el centro del plano |
| ANTI-HALLUCINATION WARNING NODAL | Un rack es NODAL solo por función (3+ cables convergentes), no por tamaño físico ni color. Rack NODAL sin cables en el JSON = alucinación |
| STAR TOPOLOGY RULE | Cada rack conecta directamente al NODAL hub; se prohíben cadenas A→B→C si existe un NODAL cercano |
Bloque <|think|> explícito | 4 pasos obligatorios: peripheral scan → locate hubs → count → trace. El modelo razona antes de emitir el JSON |
| JSON schema simplificado | Eliminado el campo analysis textual; esquema más limpio con 5 arrays: racks, connections, walls, texts, symbols |
Estructura del output esperada
<|think|>
Step 1: PERIPHERAL SCAN — paredes exteriores y líneas estructurales
Step 2: LOCATE HUBS — NODALes y sus posiciones aproximadas
Step 3: COUNT — conteo exhaustivo de racks estándar
Step 4: TRACE — verificar que conexiones fluyen hacia NODALes
</|think|>
```json
{ "racks": [...], "connections": [...], "walls": [...], "texts": [...], "symbols": [...] }
El bloque `<|think|>` es **descartado** por `_clean_llm_json` antes del parse.
---
## Motivación y razonamiento
- El advisor externo confirmó que **1120 tokens** (no 2240) es suficiente para planos densos y potencialmente reduce el tiempo de análisis.
- El **override `temperature=0.1`** era un artefacto del Modelfile de la laptop de Edu; en llama-server no hay Modelfile, así que el request tenía que enviar los valores correctos.
- El thinking activado obliga al modelo a razonar en 4 pasos antes de producir el JSON, lo que mejora la consistencia en topologías complejas con múltiples NODALes.
---
## Pendiente de medir
- **Tiempo plano 70 racks**: objetivo < 6:00 min (referencia sesión 47c).
- **Calidad sostenida** con thinking activado en planos de diversa complejidad.
---
## Véase también
- [[crearack--blueprints--auto-plan-ai]]