Lemonade von AMD: ein schneller lokaler Open-Source-LLM-Server mit GPU ...

Lemonade von AMD: Ein schneller lokaler Open-Source-LLM-Server mit GPU und NPU

Ein praxistauglicher lokaler LLM-Server hört in dem Moment auf, „lokal“ zu sein, in dem er 18 Sekunden braucht, um auf einen Prompt mit 20 Tokens zu antworten. Ich habe dieses Muster auf Entwickler-Laptops immer wieder gesehen: Das Modell läuft technisch gesehen, die CPU-Auslastung verharrt bei 700 %, die Lüfter drehen hoch, und das erste Token erscheint erst, nachdem der Nutzer den Kontext bereits verloren hat.

Genau dieses technische Problem versucht Lemonade zu lösen: Lokale Inferenz soll sich wie ein echter Dienst anfühlen, nicht wie ein Demo-Skript.

Lemonade von AMD ist ein lokaler Open-Source-LLM-Server, der Sprachmodelle auf Client-Hardware ausführen soll, insbesondere auf AMD-Systemen mit GPU- und Ryzen AI NPU-Beschleunigung. Das Interessante ist nicht nur, „ein Modell lokal auszuführen“. Dafür gibt es bereits mehrere Möglichkeiten. Interessant ist die Serverarchitektur: lokale Modelle über eine API bereitstellen, Inferenz über verfügbare Beschleuniger ausführen und sie aus normalem Anwendungscode nutzbar machen.

Für Entwickler, die lokale Copiloten, private Dokumentenassistenten, Agenten-Sandboxes oder Workflows für Offline-Inferenz entwickeln, ist dies die richtige Abstraktion. Sie möchten nicht, dass jede Anwendung wissen muss, wie sie ein Modell lädt, Gewichte quantisiert, Ausführungsanbieter auswählt, Speicher fixiert, Tokens streamt und Sitzungen verwaltet. Sie möchten einen lokalen Inferenzdienst.

Wofür Lemonade tatsächlich gedacht ist

Grundsätzlich ist Lemonade ein lokaler Modellserver. Er sitzt zwischen Ihrer Anwendung und der Hardware.

Statt die Inferenzlogik direkt in Ihre App einzubetten, führen Sie einen lokalen Daemon aus:

lemonade-server serve

Ihre Anwendung kommuniziert dann über HTTP mit ihm, häufig über eine Chat-Completions-API im Stil von OpenAI:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/api/v1",
    api_key="not-needed-for-local"
)

response = client.chat.completions.create(
    model="llama-3.1-8b-instruct",
    messages=[
        {"role": "system", "content": "You are a concise coding assistant."},
        {"role": "user", "content": "Write a Python function to chunk text by tokens."}
    ],
    temperature=0.2,
    stream=True,
)

for chunk in response:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

Die Struktur der API ist wichtig. Wenn Ihr Backend bereits GPT-5.5, Claude Sonnet 4.6, Gemini 3 oder einen Endpunkt für ein offenes Modell unterstützt, können Sie dieselbe Client-Abstraktion häufig für die lokale Ausführung auf Lemonade ausrichten. So können Sie Modell-Routing, datenschutzsensible Funktionen und Offline-Workflows testen, ohne Ihre App für ein neues SDK umzuschreiben.

In der Praxis behandle ich einen lokalen LLM-Server als Infrastrukturkomponente:

App / IDE / Agent Runtime
        |
        | HTTP streaming chat API
        v
Lemonade local server
        |
        | model loader + scheduler
        v
Execution backend
        |
        | GPU / NPU / CPU fallback
        v
AMD client hardware

Diese klare Trennung macht den Ansatz in realen Systemen nutzbar.

Warum sowohl GPU als auch NPU wichtig sind

Die meisten Entwickler verstehen bereits, warum GPU-Beschleunigung für LLM-Inferenz wichtig ist: Matrixmultiplikationen dominieren die Laufzeit, und GPUs sind für parallele Berechnungen ausgelegt. Der NPU-Aspekt ist neuer und wird leichter missverstanden.

Eine NPU ist keine „kleinere GPU“. Sie ist ein spezialisierter Beschleuniger, der für neuronale Netzwerkoperationen unter engen Energie- und Temperaturgrenzen optimiert ist. Auf einem Laptop ist das wichtig. Der beste lokale Inferenz-Stack ist nicht immer derjenige, der in einem 30-Sekunden-Benchmark die höchste Spitzenrate an Tokens pro Sekunde erreicht. Oft ist es derjenige, der reaktionsfähig bleibt, während der Nutzer Slack, einen Browser, VS Code und Docker ausführt.

Ein hilfreiches Denkmodell:

• GPU: besser für größere Modelle, höheren Durchsatz und umfangreichere parallele Berechnungen.
• NPU: attraktiv für kleinere oder optimierte Modelle im stromsparenden Dauerbetrieb.
• CPU: zuverlässige Ausweichoption, aber meist mit hohen Latenzen bei interaktiver LLM-Nutzung.
• Hybride Systeme: nützlich, wenn Aufgaben anhand von Modellgröße, Quantisierung und Verfügbarkeit verteilt werden.

Ein lokaler Assistent könnte beispielsweise Folgendes verwenden:

{
  "routes": {
    "autocomplete": {
      "model": "small-code-model",
      "device": "npu",
      "max_tokens": 64
    },
    "chat": {
      "model": "llama-3.1-8b-instruct-q4",
      "device": "gpu",
      "max_tokens": 1024
    },
    "summarization": {
      "model": "compact-instruct",
      "device": "auto",
      "max_tokens": 512
    }
  }
}

Diesen Ansatz schätze ich: Legen Sie sich nicht dogmatisch auf einen Beschleuniger fest. Wählen Sie für jede Arbeitslast das passende Ausführungsziel.

Wo Lemonade unter den lokalen LLM-Servern einzuordnen ist

Inzwischen gibt es mehrere ausgereifte Optionen für lokale Inferenz. Lemonade zeichnet sich durch seinen Fokus auf lokale Beschleunigung mit AMD aus, insbesondere bei Systemen, auf denen sowohl GPU als auch NPU Teil der Client-Plattform sind.

Lemonade ist kein direkter Ersatz für jeden Inferenz-Stack. Wenn Sie Hunderte gleichzeitiger Nutzer über Rechenzentrums-GPUs bedienen, ist kontinuierliches Batching nach dem Vorbild von vLLM meist die passendere Architektur. Wenn Sie eine möglichst breite Portabilität über unterschiedlichste Rechner hinweg benötigen, bleibt llama.cpp schwer zu schlagen.

Lemonade wird interessant, wenn das Zielgerät ein AMD-Laptop, eine Workstation oder ein Edge-Gerät ist und Ihnen ein vollwertiger lokaler Server wichtiger ist als ein einmalig verwendetes Python-Skript.

Eine praxistaugliche lokale Architektur

Hier ist ein Muster, das sich für lokale KI-Anwendungen bewährt:

┌──────────────────────────────┐
│ Desktop App / Backend Service │
└───────────────┬──────────────┘
                │ OpenAI-compatible client
                v
┌──────────────────────────────┐
│ Local Model Gateway           │
│ - retries                     │
│ - model routing               │
│ - prompt templates            │
│ - telemetry                   │
└───────────────┬──────────────┘
                │ localhost HTTP
                v
┌──────────────────────────────┐
│ Lemonade Server               │
│ - model loading               │
│ - streaming responses         │
│ - device selection            │
│ - accelerator backend         │
└───────────────┬──────────────┘
                │
       ┌────────┴────────┐
       v                 v
   AMD GPU            Ryzen AI NPU

Ich ergänze in der Regel ein schlankes Gateway, selbst wenn der lokale Server bereits eine saubere API bereitstellt. Das Gateway bietet Ihnen einen stabilen internen Schnittstellenvertrag und ermöglicht den Wechsel zwischen lokalen und entfernten Modellen.

Zum Beispiel:

import os
from openai import OpenAI

def build_llm_client():
    if os.getenv("LLM_MODE") == "local":
        return OpenAI(
            base_url="http://localhost:8000/api/v1",
            api_key="local"
        )

    return OpenAI(
        base_url=os.environ["REMOTE_LLM_BASE_URL"],
        api_key=os.environ["REMOTE_LLM_API_KEY"]
    )

client = build_llm_client()

Dann spielt es für Ihre Anwendungslogik keine Rolle, ob die Anfrage an Lemonade, GPT-5.5, Claude Opus 4.8, Gemini 3 oder ein gehostetes offenes Modell geht. Diese Flexibilität ist wertvoll, wenn Sie Qualität, Latenz, Datenschutz und Kosten bewerten. Wenn Ihr Team einen API-Anbieter für mehrere Modelle wie AI Prime Tech als Cloud-Fallback nutzt, halten Sie den lokalen und den entfernten Pfad hinter derselben Schnittstelle.

Modellauswahl: Kleinere Modelle schlagen theoretische Intelligenz

Der häufigste Fehler bei lokalen LLM-Servern besteht darin, ein Modell auszuwählen, weil es auf einer Rangliste gut abschneidet, statt weil es zum Rechner passt.

Bei lokaler Inferenz hängt alles davon ab, ob das Modell passt:

• Passt das quantisierte Modell in den verfügbaren Beschleunigerspeicher?
• Ist die Kontextlänge für die Arbeitslast realistisch?
• Wie lange dauert es bis zum ersten Token?
• Streamt es unter den normalen thermischen Bedingungen eines Laptops flüssig?
• Kann die App einen gelegentlichen Rückfall auf die CPU tolerieren?
• Ist die Qualität für die Aufgabe ausreichend?

Ein auf 4 Bit quantisiertes 7B- oder 8B-Instruct-Modell ist lokal oft nützlicher als ein deutlich größeres Modell, das ständig Daten auslagert, ins Stocken gerät oder eine starke Kürzung des Kontexts erzwingt. Für Programmieraufgaben können offene Modelle auf Basis von Qwen, DeepSeek, Llama, MiniMax und Kimi je nach Lizenz, Formatunterstützung und Backend-Kompatibilität geeignete Kandidaten sein.

Der richtige Arbeitsablauf ist empirisch:

# Example benchmark flow; adapt names to installed Lemonade commands/models.
lemonade-server pull llama-3.1-8b-instruct-q4
lemonade-server serve --host 127.0.0.1 --port 8000

Führen Sie dann einen wiederholbaren Prompt aus:

import time
from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/api/v1", api_key="local")

prompt = "Explain how an LRU cache works, then implement one in Python."

start = time.perf_counter()
first_token_at = None
tokens = 0

stream = client.chat.completions.create(
    model="llama-3.1-8b-instruct-q4",
    messages=[{"role": "user", "content": prompt}],
    stream=True,
    temperature=0.1,
    max_tokens=400,
)

for chunk in stream:
    text = chunk.choices[0].delta.content or ""
    if text and first_token_at is None:
        first_token_at = time.perf_counter()
    tokens += len(text.split())

end = time.perf_counter()

print({
    "time_to_first_token_s": round(first_token_at - start, 3),
    "total_time_s": round(end - start, 3),
    "rough_word_rate_per_s": round(tokens / (end - start), 2)
})

Das ist kein wissenschaftlich perfekter Benchmark. Es ist ein praktischer Smoke-Test. Er zeigt Ihnen, wie sich die Anwendung für Ihre Nutzer anfühlen wird.

Geräteauswahl und Fallbacks

Ein guter lokaler Server sollte die Geräteauswahl so explizit machen, dass Entwickler Fehler nachvollziehen können. „Auto“ ist bequem, bis ein Modell unbemerkt von der GPU auf die CPU wechselt und Ihre Latenz um 8x steigt.

Bei produktionsnahen lokalen Bereitstellungen bevorzuge ich eine unspektakuläre und überprüfbare Konfiguration:

{
  "server": {
    "host": "127.0.0.1",
    "port": 8000
  },
  "models": [
    {
      "name": "local-chat",
      "path": "./models/llama-3.1-8b-instruct-q4",
      "device": "gpu",
      "context_length": 8192
    },
    {
      "name": "fast-draft",
      "path": "./models/small-instruct-npu",
      "device": "npu",
      "context_length": 4096
    }
  ],
  "fallback": {
    "allow_cpu": false,
    "on_failure": "return_error"
  }
}

Die konkreten Konfigurationsmöglichkeiten von Lemonade können je nach Version variieren, aber das Prinzip bleibt: Vermeiden Sie unbemerkte Leistungseinbußen. Wenn der GPU-Pfad ausfällt, soll die App davon erfahren. Bei interaktiven Anwendungen ist eine klare Fehlermeldung oft besser, als Nutzer 90 Sekunden auf eine CPU-Antwort warten zu lassen.

Ein häufiger Stolperstein: Treiber und Laufzeitbibliotheken sind genauso wichtig wie das Modell. Wenn die GPU- oder NPU-Beschleunigung nicht greift, kann der Server weiterhin „funktionieren“, nur eben langsam. Prüfen Sie beim Start immer den aktiven Ausführungsanbieter in den Logs.

Nützliche Prüfungen beim Start:

lemonade-server serve --log-level debug

Achten Sie auf:

loaded model: local-chat
selected device: gpu
execution provider: <accelerated backend>
context length: 8192
quantization: q4

Wenn die Logs den Beschleunigerpfad nicht eindeutig zeigen, gehen Sie davon aus, dass Sie die Beschleunigung noch nicht verifiziert haben.

Streaming ist nicht optional

Für die Nutzererfahrung mit lokalen LLMs ist Streaming eine Voraussetzung. Selbst wenn die gesamte Fertigstellungszeit unverändert bleibt, wirkt die App durch Streaming deutlich schneller, weil Nutzer den Fortschritt sehen.

Ihr Server sollte Token-Streaming unterstützen, und Ihr Client sollte es korrekt verarbeiten:

def stream_answer(client, model, messages):
    stream = client.chat.completions.create(
        model=model,
        messages=messages,
        stream=True,
        temperature=0.2,
        max_tokens=700,
    )

    for event in stream:
        piece = event.choices[0].delta.content
        if piece:
            yield piece

In der Praxis hilft Streaming auch bei der Fehlersuche. Wenn die Latenz bis zum ersten Token hoch ist, die Generierung danach aber schnell läuft, kann der Engpass beim Laden des Modells, der Prompt-Verarbeitung oder der Kontextlänge liegen. Wenn das erste Token schnell eintrifft, die Generierung aber nur schleppend vorankommt, können Speicherbandbreite, thermische Drosselung oder ein Rückfall auf die CPU die Ursache sein.

Messen Sie diese Werte getrennt:

• Kaltstartzeit: vom Serverstart bis zur Bereitschaft des Modells.
• Prompt-Verarbeitungszeit: vom Eingang der Anfrage bis zum ersten Token.
• Dekodiergeschwindigkeit: vom ersten bis zum letzten Token.
• Ende-zu-Ende-Latenz: von der Anfrage der Anwendung bis zur vollständigen Antwort.
• Thermische Stabilität: derselbe Test nach fünf Minuten Nutzung.

Der letzte Punkt wird leicht übersehen und kann in realen Produkten schmerzhaft werden.

Kontextlänge: Der unbemerkte Latenzmultiplikator

Lange Kontextfenster sind nützlich, aber nicht kostenlos. Ein Modell, das einen Kontext von 8192 oder 32768 Token unterstützt, kann trotzdem unangenehm in der Nutzung werden, wenn Sie jede Anfrage mit Logs, Dokumenten und Chatverlauf vollpacken.

Bei lokalen Systemen setze ich Kontextbudgets in der Regel am Gateway durch:

MAX_PROMPT_CHARS = 18_000

def trim_context(system_prompt, history, new_user_message):
    packed = [
        {"role": "system", "content": system_prompt},
        *history[-8:],
        {"role": "user", "content": new_user_message},
    ]

    total = sum(len(m["content"]) for m in packed)
    while total > MAX_PROMPT_CHARS and len(packed) > 2:
        removed = packed.pop(1)
        total -= len(removed["content"])

    return packed

Das ist grob, aber wirksam. Eine ausgereiftere Variante nutzt Token-Zählung, semantische Komprimierung und Retrieval. Entscheidend ist, dass die Kontextverwaltung in Ihre Anwendungsschicht gehört und nicht auf der vagen Hoffnung beruhen sollte, dass der Server schnell bleibt.

Wenn Sie ein Modell mit großem Kontext wie Fable 5 mit einem Kontext von 1M in einer Cloud-Umgebung verwenden, verändert das den Gestaltungsspielraum. Auf einem lokalen GPU-/NPU-System sollten Sie davon ausgehen, dass Kontext kostspielig ist, solange Ihre Messungen nichts anderes zeigen.

Bewährte Vorgehensweisen für lokale Bereitstellung nach dem Vorbild von Lemonade

Halten Sie den Server betriebsbereit

Das Laden eines Modells beim Kaltstart ist einer der größten Störfaktoren für die Nutzererfahrung. Starten Sie den Server zusammen mit der App, laden Sie das Standardmodell frühzeitig und stellen Sie die Bereitschaft getrennt vom Prozesszustand bereit.

curl http://127.0.0.1:8000/health
curl http://127.0.0.1:8000/models

Ihre App sollte unterscheiden zwischen:

• Serverprozess läuft
• Modell ist geladen
• Beschleuniger ist aktiv
• Anfragepfad funktioniert ordnungsgemäß

Modellversionen festlegen

Lassen Sie nicht zu, dass sich „latest“-Modelle in einer Desktop-App unbemerkt ändern. Legen Sie Modellnamen, Quantisierung und erwartete Kontextlänge fest.

{
  "model": "llama-3.1-8b-instruct-q4",
  "revision": "2025-02-local-tested",
  "expected_device": "gpu"
}

Schon kleine Änderungen am Tokenizer, an der Chatvorlage oder an der Quantisierung können das Verhalten verändern.

Qualitätstests von Geschwindigkeitstests trennen

Ein schnelles lokales Modell, das auf subtile Weise schlechte Antworten liefert, ist für viele Arbeitsabläufe schlechter als ein langsameres. Ich pflege gerne zwei Testsätze:

evals/
  latency_prompts.jsonl
  task_quality_prompts.jsonl

Beispiel für einen Qualitätstestfall:

{
  "id": "python_exception_summary_01",
  "messages": [
    {
      "role": "user",
      "content": "Summarize this stack trace and identify the likely bug: ..."
    }
  ],
  "must_include": ["None", "attribute", "guard"],
  "must_not_include": ["database outage"]
}

Das ersetzt keine formale Evaluation, deckt aber Regressionen auf, wenn Sie das Modell, die Quantisierung oder den Gerätepfad ändern.

Remote-Fallback einplanen

Lokale Inferenz scheitert an unspektakulären Ursachen: Energiesparmodus des Laptops, Treiberupdates, fehlende Modelldateien, nicht unterstützte Quantisierung, thermische Drosselung. Wenn die Aufgabe wichtig ist, planen Sie einen Fallback ein.

try:
    answer = call_local_model(messages, timeout_s=20)
except Exception:
    answer = call_remote_model(messages, timeout_s=30)

Legen Sie den Datenschutz ausdrücklich fest. Manche Prompts sollten den Rechner niemals verlassen. Brechen Sie in diesen Fällen bei einem Fehler ab, ohne Daten nach außen zu übertragen.

Einschränkungen und Kompromisse

Lemonade entfaltet sein Potenzial am stärksten auf kompatiblen AMD-Systemen mit dem passenden Laufzeit-Stack. Das bedeutet auch, dass im Betrieb die Fähigkeiten der Hardware, der Treiberzustand, die Unterstützung von Modellformaten und der Reifegrad des Beschleuniger-Backends berücksichtigt werden müssen.

Die wichtigsten Kompromisse:

• Portabilität: Eine auf AMD ausgerichtete Beschleunigung ist wertvoll, aber heterogene Geräteflotten benötigen möglicherweise mehrere Backends.
• Modellverfügbarkeit: Nicht jedes offene Modell ist für jeden Ausführungspfad paketiert oder optimiert.
• Einschränkungen von NPUs: NPUs eignen sich hervorragend für effiziente Inferenz, aber nicht jede Modellarchitektur oder Kontextlänge passt gut zu ihnen.
• Beobachtbarkeit: Lokale Server benötigen ebenso Logs und Metriken wie Cloud-Dienste.
• Parallelität: Der Laptop eines einzelnen Entwicklers ist kein mandantenfähiger Inferenzcluster.

Eine ehrliche Einordnung: Lemonade liefert keine Kapazität wie durch Zauberhand. Es bietet eine bessere lokale Bereitstellungsschicht auf Client-Hardware mit begrenzten Ressourcen. Der Leistungsgewinn entsteht durch das passende Modell, die passende Quantisierung, den passenden Beschleuniger und eine Server-API, die diese Details von Ihrer Anwendung fernhält.

Praktische Empfehlungen

• Verwenden Sie Lemonade, wenn Sie einen AMD-beschleunigten lokalen LLM-Server nutzen möchten, statt die Inferenz direkt in Ihre App einzubetten.
• Betrachten Sie GPU, NPU und CPU als unterschiedliche Ausführungsziele mit jeweils eigenen Profilen hinsichtlich Latenz, Stromverbrauch und Modelleignung.
• Bevorzugen Sie kleinere quantisierte Modelle, die zuverlässig interaktive Latenzen liefern, gegenüber größeren Modellen, die gerade noch in den Speicher passen.
• Überprüfen Sie die Beschleunigung anhand der Logs; ein „funktionierender“ Server läuft möglicherweise dennoch auf der CPU.
• Streamen Sie Antworten, messen Sie die Zeit bis zum ersten Token und testen Sie unter anhaltender thermischer Last.
• Implementieren Sie Routing, Fallback, Prompt-Kürzung und Datenschutzrichtlinien in Ihrem Anwendungs-Gateway.
• Fixieren Sie Modellversionen und pflegen Sie kleine Evaluierungsdatensätze für Latenz und Qualität, bevor Sie lokale KI-Funktionen ausliefern.