Guías

Escribís un prompt vago ("hazme un análisis de X") y te devuelve algo genérico que tenés que reescribir igual.

Dale al modelo: (1) rol/contexto concreto, (2) el formato exacto de salida que querés, (3) 1-2 ejemplos de qué SÍ y qué NO. Los tres modelos responden mejor a instrucciones estructuradas que a prosa suelta.

En vez de "resume este contrato": "Sos un abogado revisando este contrato de arrendamiento. Devolveme una lista de máximo 5 cláusulas riesgosas, cada una en una línea: [cláusula] — [por qué es riesgosa] — [qué pedir en su lugar]."

Tenés acceso a varios modelos y no sabés cuál usar para qué — terminás usando siempre el mismo por costumbre, no por criterio.

Preguntate tres cosas en orden: (1) ¿el dato es sensible? → si sí, local primero. (2) ¿la tarea es código de formato largo/agéntico? → Claude Opus/GPT-5.3-Codex. (3) ¿necesitás contexto enorme (documentos largos)? → Gemini. Todo lo demás (chat, resúmenes, tareas cortas) → el modelo local más barato que resuelva bien.

Revisar un contrato con datos personales de un cliente: modelo local (nunca sale de tu servidor). Refactor grande de un repo: Claude Opus o GPT-5.3-Codex-Max. Resumir 300 páginas de un informe: Gemini por la ventana de contexto.

Querés probar un modelo local pero no sabés qué hardware necesitás ni por dónde empezar.

Para Qwen3.6 27B (denso, el punto dulce de este momento): mínimo una GPU de 16-24GB VRAM en Q4. Instalá llama.cpp o Ollama, bajá el GGUF cuantizado (Q4_K_M es el balance estándar calidad/tamaño), corré el servidor local, apuntá cualquier cliente compatible OpenAI a `http://127.0.0.1:8080/v1`.

`ollama pull qwen3.6:27b` → `ollama run qwen3.6:27b "explicame qué es RAG en 3 líneas"`. Primer output en minutos, no horas.

Los dos son gateways de chat (WhatsApp/Telegram/etc.) a agentes de IA — ¿cuál elegís y por qué?

La pregunta real no es 'cuál es mejor' sino 'dónde querés que viva el modelo'. OpenClaw es open-source pero BYO-API-key — por defecto tus mensajes pasan por la nube de un tercero (Claude/GPT/Gemini) aunque el gateway corra en tu máquina. Imaginclaw corre sobre modelos locales (Hera) por default, nube solo como fallback explícito.

Si te importa que ningún mensaje salga de tu infraestructura (legal, salud, datos de clientes): Imaginclaw o un OpenClaw configurado exclusivamente con Ollama local. Si querés la capacidad frontier sin montar infraestructura propia: OpenClaw con API de Claude/GPT.

No es obvio cuándo la diferencia entre 'local' y 'nube' es solo preferencia técnica y cuándo es una decisión real de riesgo.

Preguntate: si esta conversación se filtrara mañana, ¿a quién le hace daño? Datos personales de terceros (clientes, pacientes, empleados), secretos comerciales, o cualquier cosa con obligación legal de confidencialidad → local es la respuesta correcta, no una preferencia. Para todo lo demás, la nube es más simple y suele bastar.

Un despacho de abogados procesando expedientes de clientes: local, sin discusión (y en Colombia, con implicancia real bajo la Ley 1581 de 2012 de protección de datos). Escribir un borrador de post de blog: cualquiera de los dos.

Cada release nuevo dice 'supera a X en benchmarks' — y casi nunca es información que te sirva para decidir si te conviene a vos.

Ignorá el benchmark del vendor. Armá 5-10 tareas REALES de tu propio trabajo (no genéricas), corrélas contra el modelo actual y el nuevo, comparalas a ciegas. Si no ves diferencia real en tus tareas, no migres solo por el número del benchmark.

Antes de migrar de un modelo a otro para revisión de contratos: agarrá 10 contratos ya revisados por un humano, corré ambos modelos, contá cuántos errores reales (no de estilo) comete cada uno.

La jerga de IA está llena de términos que suenan importantes pero que nadie te explica en una frase útil.

20 términos, una línea cada uno: **Token** — la unidad mínima de texto que procesa un modelo (no es una palabra exacta). **Contexto** — cuánto texto puede "ver" el modelo a la vez. **Cuantización (Q4/Q8)** — comprimir un modelo para que ocupe menos VRAM, con pequeña pérdida de calidad. **VRAM** — memoria de la GPU, el cuello de botella real para correr modelos locales. **MoE (Mixture of Experts)** — un modelo grande que solo activa una parte de sí mismo por token (más rápido que un modelo denso del mismo tamaño total). **Fine-tuning** — reentrenar un modelo con tus propios datos. **RAG** — buscar información real antes de responder, en vez de confiar en lo que el modelo "recuerda". **Agente** — un modelo que puede usar herramientas (buscar, ejecutar código, navegar) en un loop, no solo responder texto. **Alucinación** — el modelo inventa un hecho con total confianza. **Temperatura** — cuánta aleatoriedad tiene la respuesta (0 = determinista, más alto = más variado). **System prompt** — la instrucción invisible que fija el comportamiento del modelo antes de tu mensaje. **Ventana de contexto** — el límite total de tokens (tu prompt + la respuesta) que el modelo puede manejar en un turno. **Embedding** — convertir texto en números para poder compararlo por similitud. **Zero-shot / few-shot** — pedirle una tarea sin ejemplos vs. con 1-2 ejemplos en el prompt. **Open-weight** — los pesos del modelo son descargables (no significa que sea liviano ni fácil de correr). **API** — cómo tu código le habla a un modelo que corre en otro servidor. **Latencia** — cuánto tarda en responder. **Throughput** — cuántas requests puede atender en paralelo. **Prompt injection** — un ataque donde texto malicioso dentro del contenido que el modelo procesa lo hace desviarse de sus instrucciones. **Guardrail** — una regla externa al modelo que bloquea o corrige su output.

"Este modelo tiene 262K de contexto" = puede ver ~200,000 palabras de una sentada, no que "es más inteligente".

El modelo "se olvida" de algo que le dijiste antes en la misma conversación, o te corta la respuesta a mitad.

Todo lo que entra y sale de un modelo se mide en tokens (aprox. ¾ de una palabra en español/inglés). La ventana de contexto es un límite TOTAL compartido entre tu prompt + el historial + la respuesta — no son cupos separados. Si te acercás al límite, el modelo empieza a perder detalle de lo que quedó más atrás.

Un modelo con 128K de contexto y una conversación de 100K tokens de historial solo tiene 28K libres para tu próximo mensaje + la respuesta — si pedís un documento largo ahí, te lo va a cortar o resumir de más.

Querés que el modelo "sepa" algo específico de tu negocio y no es obvio cuál de las tres técnicas usar.

**Prompting** (poné la info directo en el prompt) — para datos chicos, que cambian seguido, sin infraestructura. **RAG** (buscar y traer info relevante antes de responder) — para bases de conocimiento grandes que cambian con frecuencia (documentos, políticas, catálogos). **Fine-tuning** (reentrenar el modelo) — solo cuando necesitás cambiar el ESTILO/comportamiento del modelo, no agregarle datos — es más caro y no es la forma correcta de "enseñarle hechos".

Un bot que responde sobre 500 productos de un catálogo que cambia cada semana: RAG, no fine-tuning. Un bot que debe responder siempre en un tono legal específico sin importar el tema: ahí sí fine-tuning tiene sentido.

Los tres son "open-weight" pero tienen requisitos de hardware completamente distintos — la etiqueta no te dice si podés correrlos vos.

Qwen3.6 27B denso: corre en 1-2 GPUs de consumo (16-24GB VRAM en Q4) — el único de los tres realmente accesible para self-hosting individual hoy. Kimi K3 (2.8T params) y DeepSeek V4 (hasta 1.6T): pesos abiertos, pero escala de datacenter — cientos de GB de VRAM incluso cuantizados, pensados para servirse vía API de un proveedor o un cluster propio, no para tu escritorio.

Si tenés 1-2 GPUs y querés correr algo YA: Qwen3.6 27B. Si querés la capacidad máxima open-weight y no te importa pagarle a un proveedor que lo hostee: Kimi K3 o DeepSeek V4 vía API.