Modelos locales en tu propio stack

Hasta ahora este nivel ha tratado de portabilidad. La misma memoria en Claude, Cursor y Codex, las mismas herramientas sobre un protocolo abierto. Esta lección lleva la línea hasta el final, porque la portabilidad no termina en el proveedor. Termina en la pregunta de si tiene que haber un proveedor implicado siquiera.

Por qué esta es la verdadera prueba del estándar

Un protocolo es abierto cuando puedes ejecutarlo contra algo que su creador no previó. MCP viene de Anthropic. Si los mismos servidores trabajan contra un modelo que está en tu escritorio y no tiene nada que ver con Anthropic, la apertura queda demostrada y no solo afirmada.

Justo eso funciona. Es el mismo software de servidor, la misma herramienta de memoria, solo otro modelo detrás. Lo que cambia es la capacidad del modelo para usar las herramientas con criterio, y de eso trata el resto de esta lección. Que PUEDAS usar los mismos servidores, por cierto, no significa que debas registrarlos en todas partes; al final se detalla.

Separar los papeles con limpieza

En Claude Desktop dos cosas se difuminan en una sola aplicación, y eso genera confusión en cuanto las separas.

El protocolo conoce host, cliente y servidor. El host es la aplicación en la que estás; arranca un cliente por conexión, y cada cliente habla con un servidor que proporciona las herramientas. El modelo no participa en el protocolo: el host le presenta la lista de herramientas y ejecuta lo que quiera llamar.

Esa separación es justamente la razón de que el mismo software de servidor funcione detrás de cualquier modelo. En un montaje local el modelo vive en un entorno de ejecución como Ollama, y el host es un programa aparte, por ejemplo una interfaz web. Sustituyes una capa, no el montaje. Eso solo significa que PODRÍAS usar los mismos servidores. Cuáles registras en cada entorno es una decisión de seguridad, más abajo se detalla. Lo que sí debes comprobar es el transporte: una entrada de servidor configurada como proceso local no se copia sin cambios a una interfaz web.

Dónde está el límite

Aquí está la diferencia que cuenta en la práctica. Comprueba primero el montaje: plantilla de chat, descripciones de herramientas, cuantización, si la interfaz llega a pasar las llamadas. Si el comportamiento persiste, es el modelo, y esa parte no se configura para que desaparezca.

Un modelo grande decide de forma fiable si una pregunta necesita una herramienta. Un modelo local pequeño no siempre. A veces responde con su propio conocimiento aunque la herramienta adecuada esté ahí. A veces echa mano de la equivocada. Y cuando una tarea necesita tres herramientas en el orden correcto, pierde el hilo más a menudo.

Elegir herramienta es una tarea de razonamiento, pero a diferencia de la comprensión de texto aquí no decide en primer lugar el tamaño. Por debajo de unos siete mil millones de parámetros la capacidad falta en buena medida. Por encima cuenta sobre todo si el modelo fue entrenado expresamente para llamar herramientas: en comparativas, modelos de 8B y 14B con ese entrenamiento quedan muy cerca, y un modelo bastante mayor sin él puede rendir peor que uno pequeño con él. Elegir solo por número de parámetros falla aquí con regularidad.

Qué se deduce para tu montaje

Tres consecuencias, todas en la misma dirección.

Menos herramientas a la vez. Tres bien descritas ganan a veinte. Con modelos grandes una lista larga es inofensiva, con los pequeños la tasa de acierto cae con cada entrada añadida.

Descripciones que expliquen el cuándo. "Busca en la base de datos" le basta a un modelo potente. Uno local necesita "úsala cuando se pregunte por un cliente, una factura o un expediente". Con modelos locales la descripción no es adorno, es la palanca más importante.

El menor acceso posible, en ambos lados. Que un modelo que de vez en cuando se equivoca pueda borrar o enviar es la mala combinación evidente, y para eso sirve la confirmación obligatoria. La parte infravalorada es la lectura: una herramienta de lectura con alcance demasiado amplio trae claves y datos de clientes al contexto y a los registros, y en cuanto esa misma interfaz corra una vez contra un modelo en la nube, ese es el camino hacia fuera. Así que un único directorio en vez de la carpeta de usuario, y confirmación para todo lo que escriba.

Por qué la memoria importa aún más en local

En este nivel la tesis ha ido así hasta ahora: un modelo que conoce tu contexto gana a uno más potente que tiene que adivinar. Con modelos locales eso deja de ser una optimización y pasa a ser la condición para que el montaje sirva de algo.

Un modelo pequeño sabe poco del mundo y nada de ti. Lo que no sabe solo puede inventarlo. Dale acceso a tus notas, decisiones y estados de proyecto y ya no tiene que adivinar, solo consultar y formular. Consultar y formular es justo la disciplina en la que los modelos pequeños son buenos.

La desventaja de tamaño se desplaza así de "no lo sabe" a "tiene que ir a buscarlo". Y ese es un problema que resuelven las herramientas.

El montaje mixto

En la práctica casi nadie se decide por un solo lado, y tampoco hace falta.

Todo lo que lleva datos sensibles y todo el trabajo en masa corre contra el modelo local. Todo lo difícil va a la nube. Como es el mismo software de servidor en ambos casos, montar el segundo entorno cuesta poco.

Va con ello un límite, si no el montaje mixto anula justo la privacidad por la que existe: dos instalaciones separadas, ni dos ventanas ni dos perfiles de la misma interfaz. Allí los servidores y las credenciales de modelo suelen estar registrados de forma global, así que un segundo perfil no es un límite. Si una herramienta de lectura ha traído claves o datos de clientes al historial y luego cambias al modelo en la nube, ese historial se va contigo. Por tanto: los servidores sensibles solo en la instalación local, el acceso a la nube solo en la otra.

Para que siga siendo así, mantén la elección del modelo en un sitio dentro de cada uno de los dos entornos, en vez de repartida por scripts. Entonces cambiar de modelo allí es una línea y no un proyecto. Es el mismo principio que en las migraciones de modelo dentro de un proveedor, solo que un nivel más arriba. Entre los dos entornos no se conmuta por línea, se cambia.

Qué significa esto para tu independencia

El efecto secundario es estratégico. Quien mantiene su montaje de forma que un modelo local pueda entrar está asegurado frente a toda una clase de incidencias: cambios de precio, modelos retirados, bloqueos, caídas del proveedor.

El modelo local no tiene que ser igual de bueno para eso. Solo tiene que ser lo bastante bueno para que el trabajo continúe. Ese modo de pensar es el mismo que se mostró en el nivel 1 con el episodio de Fable: construye de forma que la desaparición de un solo modelo no te tumbe.

Entrada práctica

El procedimiento técnico está en el playbook MCP con modelos locales, desde el entorno de ejecución hasta la primera herramienta pasando por la interfaz. Si aún no corre ningún modelo, Tu primer modelo de IA local en 30 minutos es el punto de partida. Y antes de enganchar servidores ajenos a un montaje que es local expresamente por privacidad, entre medias va Revisar servidores MCP ajenos con seguridad.

Quiz

1. ¿Qué se mantiene igual al cambiar de un modelo en la nube a uno local?

• A) El software de servidor y la herramienta de memoria
• B) La calidad en tareas de razonamiento duras
• C) La fiabilidad al elegir herramienta

La correcta es A. Ese es justamente el valor del protocolo abierto: es el mismo software. Qué servidores registras luego en un entorno de nube sigue siendo una decisión aparte. B y C empeoran, ese es el precio.

2. ¿Por qué baja la tasa de acierto con modelos locales cuantas más herramientas están activas?

• A) El entorno de ejecución se vuelve más lento
• B) Elegir herramienta es una tarea de razonamiento, y los modelos pequeños están limitados en eso
• C) MCP solo permite un número limitado de servidores

La correcta es B. No es un límite técnico sino un límite de capacidad del modelo.

3. ¿Por qué es especialmente valiosa la memoria con un modelo local pequeño?

• A) Hace el modelo más rápido
• B) Sustituye a las descripciones de las herramientas
• C) El conocimiento no tiene que estar dentro del modelo, se consulta

La correcta es C. Consultar y formular se les da bien a los modelos pequeños, cargar con el conocimiento se les da mal.

Source

• Model Context Protocol, especificación: modelcontextprotocol.io
• Ollama, modelos con soporte de herramientas: ollama.com/search?c=tools
• Open WebUI, conexión MCP: docs.openwebui.com