Minimaler tragfähiger Umfang

12.1 Erste Version

Die erste Version muss nicht jede multimodale Funktion, jeden Modell-Download und keine Echtzeit-Sprache implementieren. Sie bildet einen nutzbaren geschlossenen Kreislauf, sobald sie Folgendes bietet:

1. Diensterkennung über /.well-known/lmsp.json.
2. Optionale LAN-Ankündigung von _lmsp._tcp.local..
3. GET /lmsp/v1/models.
4. POST /lmsp/v1/responses, sowohl synchron als auch als SSE-Stream.
5. Asynchrone Aufgaben: erstellen, abfragen und abbrechen, mit SQLite-Persistenz.
6. Fortsetzen abgebrochener Streams mit Last-Event-ID oder after.
7. Bearer-Tokens, lokale Kopplung sowie Origin- und Host-Schutz.
8. Die OpenAI-kompatiblen Endpunkte /v1/models und /v1/chat/completions.
9. Eine OpenAPI-3.2-Vertragsdatei und sprachübergreifende Konformitätstests.
10. Mindestens ein echtes Backend und eine Prüfung, dass sich Aufgaben nach einem Neustart des Dienstes korrekt erholen.

Der Kern dieses Entwurfs: LMSP liefert den vollständigen Funktionsumfang, die OpenAI-Schnittstelle liefert fertige Kompatibilität, mDNS und die Dienstbeschreibung liefern automatische Erkennung, und das SQLite-Aufgabenmodell liefert lokale Persistenz.

12.2 Was warten kann

Alles, was die obige Liste nicht erwähnt, kann in späteren Versionen folgen. Dazu gehören die optionalen Endpunkte (gespeicherte Antworten sowie Laden und Entladen von Modellen), die OpenAI-Endpunkte /v1/responses und /v1/embeddings, die Ollama-kompatible API und jeder Inhaltstyp außer Text.

Dieser Umfang ist ein Weg zu einer nutzbaren ersten Version, kein Konformitätsprofil. Ein Dienst, der LMSP 1.0 für sich beansprucht, implementiert weiterhin jeden erforderlichen Endpunkt von Seite 4 und das erforderliche Verhalten, das auf den anderen Seiten beschrieben ist.