Überblick

1.1 Zusammenfassung

Das Local Model Service Protocol (LMSP) legt fest, wie Clients Sprachmodell-Dienste finden und nutzen, die auf dem eigenen Gerät oder im lokalen Netzwerk des Nutzers laufen. Es spezifiziert die Diensterkennung, einen Modellkatalog, synchrone und gestreamte Generierung sowie asynchrone Aufgaben, die Neustarts überstehen. Außerdem legt es fest, wie ein Dienst neben der LMSP-Schnittstelle eine OpenAI-kompatible Schnittstelle anbietet, damit bestehende Clients weiter funktionieren.

LMSP ersetzt weder die OpenAI-API noch Ollama oder MCP. Es vereint ihre Stärken in einer Protokollschicht, die für einen dauerhaft laufenden lokalen Dienst gebaut ist.

1.2 Status dieses Dokuments

Dies ist der erste öffentliche Entwurf von LMSP 1.0, veröffentlicht am 2026-11-08. „LMSP“ ist ein Arbeitsname. Der Text ist offen für Rückmeldungen und kann sich bis zur Fertigstellung von 1.0 inkompatibel ändern.

Der englische Text ist maßgeblich. Übersetzungen dienen der Bequemlichkeit; bei Abweichungen gilt der englische Text.

1.3 Entwurfsgrundlage

LMSP greift auf bewährte Entwürfe zurück, statt neue zu erfinden:

• OpenAI Responses API. Strukturierte Ausgabeelemente, semantische Server-Sent Events und Hintergrundausführung mit Abfrage und Abbruch für lang laufende Arbeit. Sie ist die Referenz für die zentrale Konversationsschnittstelle von LMSP. Siehe gestreamte Antworten und Hintergrundmodus.
• Ollama. Es stellt die OpenAI-kompatiblen Endpunkte /v1/models, /v1/chat/completions und /v1/responses bereit, was zeigt, dass ein Dienst plus eine OpenAI-Anpassungsschicht die Einführungskosten drastisch senkt. Siehe Ollamas OpenAI-Kompatibilität.
• Model Context Protocol (MCP). Sein neuestes Design geht von der verpflichtenden Sitzungsinitialisierung zur zustandslosen Erkennung über: Jede Anfrage trägt ihre eigenen Versionsangaben, und Clients erfahren die Fähigkeiten über eine Erkennungsschnittstelle. Das passt zu lokalen Diensten, bei denen Neustarts, Client-Abstürze und abgebrochene Verbindungen den Protokollzustand nicht beschädigen dürfen. Siehe MCP.
• Agent2Agent (A2A). Service Cards, explizite Aufgabenzustände, Aufgabenabonnements und Abbruch haben die Dienstbeschreibung und das asynchrone Aufgabenmodell von LMSP geprägt. Siehe A2A.

1.4 Architektur

LMSP ist in drei Schichten organisiert, oberhalb der Adapter, die mit den Modell-Laufzeitumgebungen sprechen:

+---------------------------------------------------------------+
| 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       |
+---------------------------------------------------------------+

• Erkennung. mDNS/DNS-SD und ein Dokument mit der Dienstbeschreibung unter einer wohlbekannten Adresse (Seite 3).
• Kern. Der Modellkatalog, synchrone Antworten, Server-Sent Events und asynchrone Aufgaben (Seiten 5 bis 7).
• Kompatibilität. Eine OpenAI-kompatible API und optional eine Ollama-kompatible API (Seite 8).
• Adapter. Brücken zu llama.cpp, Ollama, vLLM oder einer eigenen Laufzeitumgebung.

Das Leitprinzip lautet ein Modell-Ausführungskern, zwei Schnittstellenfamilien. Ein Dienst bietet die LMSP-Schnittstelle und die OpenAI-Schnittstelle über demselben Kern an, sodass es genau eine Stelle gibt, an der Modelle geladen, Anfragen ausgeführt und Aufgaben verfolgt werden.

1.5 Konformitätssprache

Die Schlüsselwörter MUSS/MÜSSEN (MUST), DARF NICHT/DÜRFEN NICHT (MUST NOT), ERFORDERLICH (REQUIRED), SOLLTE/SOLLTEN (SHOULD), SOLLTE NICHT/SOLLTEN NICHT (SHOULD NOT), EMPFOHLEN (RECOMMENDED), KANN/KÖNNEN (MAY) und OPTIONAL (OPTIONAL) sind in diesem Dokument wie in BCP 14 (RFC 2119, RFC 8174) beschrieben zu interpretieren, wenn und nur wenn sie fett und in Großbuchstaben erscheinen. Andernfalls sind es gewöhnliche Wörter.

Jede Seite ist als normativ oder informativ gekennzeichnet. Normative Seiten legen Anforderungen fest; informative Seiten geben Hinweise. Beispiele sind informativ. JSON ist UTF-8, und Feldnamen verwenden snake_case.

1.6 Terminologie