# OpenAI- und Ollama-Kompatibilität

> Wie ein LMSP-Dienst über eine dünne Datenkonvertierungsschicht auf einem einzigen Ausführungskern mit bestehenden OpenAI- und Ollama-Clients kompatibel bleibt und wo diese Kompatibilität endet.

Source: https://madeforagent.com/de/lmsp/1.0/compatibility/
Language: de
Specification: LMSP 1.0 (draft)
Updated: 2026-11-08

## 8.1 OpenAI-kompatible Endpunkte {#openai}

Ein Dienst **SOLLTE** neben der LMSP-Schnittstelle eine OpenAI-kompatible Schnittstelle anbieten und sie in `interfaces` mit `kind` gleich `openai` deklarieren. Um bestehende Clients abzudecken, **MUSS** ein Dienst, der das tut, mindestens diese Endpunkte unter dem Präfix `/v1` implementieren:

| Endpunkt | Hinweise |
| --- | --- |
| `GET /v1/models` | Listet die Modelle des LMSP-Katalogs auf. Jede `id` ist die LMSP-Modell-ID. |
| `POST /v1/chat/completions` | Chat Completions, mit und ohne Streaming. |
| `POST /v1/responses` | Die OpenAI-Responses-Form. |
| `POST /v1/embeddings` | Die LMSP-1.0-Kernschnittstelle hat keinen Embeddings-Endpunkt. Der Adapter stellt diesen Endpunkt direkt bereit, für Modelle, deren `capabilities.embeddings` `true` ist. |

Diese Endpunkte akzeptieren dieselben Bearer-Tokens wie die LMSP-Schnittstelle. Ein Client, der das OpenAI-Protokoll spricht, setzt das LMSP-Token als seinen API-Schlüssel.

Eine erste Implementierung kann mit `/v1/models` und `/v1/chat/completions` beginnen ([Seite 12](https://madeforagent.com/de/lmsp/1.0/mvp.md)).

## 8.2 Ollama-kompatible Endpunkte {#ollama}

Ein Dienst **SOLLTE** auch diese Endpunkte bereitstellen, damit auch für Ollama geschriebene Clients funktionieren:

| Endpunkt | Hinweise |
| --- | --- |
| `GET /api/tags` | Listet die Modelle des LMSP-Katalogs auf. |
| `POST /api/chat` | Chat. |
| `POST /api/generate` | Einfache Textgenerierung. |

Ein Dienst, der sie bereitstellt, deklariert eine Schnittstelle mit `kind` gleich `ollama`.

## 8.3 Ein Ausführungskern {#core}

Die Kompatibilitätsschicht **MUSS** nur Daten konvertieren. Sie **DARF NICHT** eine zweite Modellverwaltungslogik anlegen. Eine Anfrage an eine Kompatibilitätsschnittstelle wird auf eine LMSP-Antwort abgebildet, läuft auf demselben Kern und Adapter wie eine native Anfrage und nutzt denselben Modellkatalog und dieselbe Authentifizierung.

```text
OpenAI Chat Completions
          |  Abbildung der Anfrage
          v
     LMSP Response
          |  Backend-Anpassung
          v
llama.cpp / Ollama / vLLM / andere Laufzeitumgebungen
```

Auf den Endpunkten `/v1` und `/api` **SOLLTE** ein Dienst Fehler in dem Format melden, das die jeweilige API definiert, damit unveränderte Clients sie auswerten können. Die LMSP-Schnittstelle verwendet immer `application/problem+json`.

## 8.4 Grenzen {#boundaries}

Die Kompatibilität hat Grenzen, und es lohnt sich, sie klar zu benennen:

- Ein bestehender OpenAI-kompatibler Client braucht meist nur eine geänderte `base_url`. Er erhält die LMSP-Erkennung nicht automatisch.
- Nur Clients, die LMSP unterstützen, können einen Dienst automatisch erkennen, seine detaillierten Fähigkeiten lesen, Ereignisströme fortsetzen und asynchrone Aufgaben verwalten.
- Kein serverseitiges Protokoll kann einen Client zum Laufen bringen, der sich nicht konfigurieren lässt und nur offizielle Cloud-Adressen akzeptiert.