Visão geral

1.1 Resumo

O Local Model Service Protocol (LMSP) define como os clientes encontram e usam serviços de modelos de linguagem executados no próprio dispositivo ou na rede local do usuário. Ele especifica a descoberta de serviços, um catálogo de modelos, a geração síncrona e em streaming, e tarefas assíncronas que sobrevivem a reinicializações. Também define como um mesmo serviço oferece uma interface compatível com a OpenAI ao lado da interface LMSP, para que os clientes existentes continuem funcionando.

O LMSP não substitui a API da OpenAI, o Ollama nem o MCP. Ele combina os pontos fortes de cada um em uma camada de protocolo pensada para um serviço local residente.

1.2 Status deste documento

Este é o primeiro rascunho público do LMSP 1.0, publicado em 2026-11-08. “LMSP” é um nome provisório. O texto está aberto a comentários e pode mudar de forma incompatível até que a 1.0 seja definitiva.

O texto em inglês é normativo. As traduções são oferecidas por conveniência; se houver divergência, prevalece o texto em inglês.

1.3 Base do projeto

O LMSP reaproveita projetos comprovados em vez de inventar novos:

• API OpenAI Responses. Itens de saída estruturados, eventos semânticos enviados pelo servidor e execução em segundo plano, com consulta e cancelamento, para trabalhos de longa duração. É a referência da interface de conversa principal do LMSP. Veja respostas em streaming e modo em segundo plano.
• Ollama. Serve os endpoints compatíveis com a OpenAI /v1/models, /v1/chat/completions e /v1/responses, o que mostra que um serviço mais uma camada de adaptação à OpenAI reduz drasticamente o custo de adoção. Veja a compatibilidade do Ollama com a OpenAI.
• Model Context Protocol (MCP). Seu projeto mais recente deixa a inicialização obrigatória de sessão e passa à descoberta sem estado: cada requisição carrega suas próprias informações de versão, e os clientes conhecem as capacidades por meio de uma interface de descoberta. Isso combina com serviços locais, em que reinicializações, falhas de clientes e conexões interrompidas não devem corromper o estado do protocolo. Veja o MCP.
• Agent2Agent (A2A). Cartões de serviço, estados explícitos de tarefa, assinatura de tarefas e cancelamento inspiram a descrição do serviço e o modelo de tarefas assíncronas do LMSP. Veja o A2A.

1.4 Arquitetura

O LMSP é organizado em três camadas, sobre os adaptadores que conversam com os ambientes de execução dos 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       |
+---------------------------------------------------------------+

• Descoberta. mDNS/DNS-SD e um documento well-known de descrição do serviço (página 3).
• Núcleo. O catálogo de modelos, as respostas síncronas, os eventos enviados pelo servidor e as tarefas assíncronas (páginas 5 a 7).
• Compatibilidade. Uma API compatível com a OpenAI e, opcionalmente, uma API compatível com o Ollama (página 8).
• Adaptadores. Pontes para o llama.cpp, o Ollama, o vLLM ou um ambiente de execução próprio.

O princípio orientador é um único núcleo de execução de modelos, duas famílias de interfaces. Um serviço oferece a interface LMSP e a interface OpenAI sobre o mesmo núcleo, de modo que há um único lugar onde os modelos são carregados, as requisições são executadas e as tarefas são acompanhadas.

1.5 Linguagem de conformidade

As palavras-chave DEVE/DEVEM (MUST), NÃO DEVE/NÃO DEVEM (MUST NOT), OBRIGATÓRIO (REQUIRED), DEVERIA/DEVERIAM (SHOULD), NÃO DEVERIA/NÃO DEVERIAM (SHOULD NOT), RECOMENDADO (RECOMMENDED), PODE/PODEM (MAY) e OPCIONAL (OPTIONAL) deste documento devem ser interpretadas conforme descrito na BCP 14 (RFC 2119, RFC 8174) quando, e somente quando, aparecem em negrito e em letras maiúsculas. Fora desse caso, são palavras comuns.

Cada página é marcada como normativa ou informativa. As páginas normativas definem requisitos; as informativas oferecem orientação. Os exemplos são informativos. O JSON usa UTF-8, e os nomes de campo usam snake_case.

1.6 Terminologia