Visión general

1.1 Resumen

El Local Model Service Protocol (LMSP) define cómo los clientes encuentran y usan servicios de modelos de lenguaje que se ejecutan en el propio dispositivo o en la red local del usuario. Especifica el descubrimiento de servicios, un catálogo de modelos, la generación síncrona y en streaming, y tareas asíncronas que sobreviven a los reinicios. También define cómo un mismo servicio ofrece una interfaz compatible con OpenAI junto a la interfaz LMSP, de modo que los clientes existentes sigan funcionando.

LMSP no sustituye a la API de OpenAI, a Ollama ni a MCP. Combina sus puntos fuertes en una capa de protocolo pensada para un servicio local residente.

1.2 Estado de este documento

Este es el primer borrador público de LMSP 1.0, publicado el 2026-11-08. «LMSP» es un nombre provisional. El texto está abierto a comentarios y puede cambiar de forma incompatible hasta que 1.0 sea definitivo.

El texto en inglés es normativo. Las traducciones se ofrecen por comodidad; si difieren, prevalece el texto en inglés.

1.3 Base del diseño

LMSP reutiliza diseños probados en lugar de inventar otros nuevos:

• API OpenAI Responses. Elementos de salida estructurados, eventos semánticos enviados por el servidor y ejecución en segundo plano con consulta y cancelación para el trabajo de larga duración. Es la referencia de la interfaz de conversación principal de LMSP. Consulta respuestas en streaming y modo en segundo plano.
• Ollama. Sirve los endpoints compatibles con OpenAI /v1/models, /v1/chat/completions y /v1/responses, lo que demuestra que un servicio más una capa de adaptación a OpenAI reduce drásticamente el coste de adopción. Consulta la compatibilidad de Ollama con OpenAI.
• Model Context Protocol (MCP). Su diseño más reciente pasa de la inicialización obligatoria de sesión al descubrimiento sin estado: cada solicitud lleva su propia información de versión, y los clientes conocen las capacidades mediante una interfaz de descubrimiento. Eso encaja con los servicios locales, donde los reinicios, los fallos de los clientes y las conexiones interrumpidas no deben corromper el estado del protocolo. Consulta MCP.
• Agent2Agent (A2A). Las tarjetas de servicio, los estados explícitos de las tareas, la suscripción a tareas y la cancelación inspiran la descripción del servicio y el modelo de tareas asíncronas de LMSP. Consulta A2A.

1.4 Arquitectura

LMSP se organiza en tres capas, sobre los adaptadores que hablan con los entornos de ejecución de modelos:

+---------------------------------------------------------------+
| Discovery      mDNS / DNS-SD + well-known service document    |
+---------------------------------------------------------------+
| Core           model catalog, responses, SSE, async tasks     |
+---------------------------------------------------------------+
| Compatibility  OpenAI API, optional Ollama API                |
+---------------------------------------------------------------+
| Adapters       llama.cpp, Ollama, vLLM, custom runtimes       |
+---------------------------------------------------------------+

• Descubrimiento. mDNS/DNS-SD y un documento de descripción del servicio en una dirección conocida (página 3).
• Núcleo. El catálogo de modelos, las respuestas síncronas, los eventos enviados por el servidor y las tareas asíncronas (páginas 5 a 7).
• Compatibilidad. Una API compatible con OpenAI y, opcionalmente, una API compatible con Ollama (página 8).
• Adaptadores. Puentes hacia llama.cpp, Ollama, vLLM o un entorno de ejecución propio.

El principio rector es un único núcleo de ejecución de modelos, dos familias de interfaces. Un servicio ofrece la interfaz LMSP y la interfaz OpenAI sobre el mismo núcleo, de modo que hay un único lugar donde se cargan los modelos, se ejecutan las solicitudes y se hace el seguimiento de las tareas.

1.5 Lenguaje de conformidad

Las palabras clave DEBE/DEBEN (MUST), NO DEBE/NO DEBEN (MUST NOT), OBLIGATORIO (REQUIRED), DEBERÍA/DEBERÍAN (SHOULD), NO DEBERÍA/NO DEBERÍAN (SHOULD NOT), RECOMENDADO (RECOMMENDED), PUEDE/PUEDEN (MAY) y OPCIONAL (OPTIONAL) de este documento se interpretan como se describe en BCP 14 (RFC 2119, RFC 8174) cuando, y solo cuando, aparecen en negrita y en mayúsculas. Fuera de ese caso son palabras corrientes.

Cada página está marcada como normativa o informativa. Las páginas normativas definen requisitos; las informativas ofrecen orientación. Los ejemplos son informativos. JSON se codifica en UTF-8 y los nombres de campo usan snake_case.

1.6 Terminología