Schnittstelle zu KI-Modellen
Das richtige Werkzeug
Veröffentlicht in Ausgabe 06/2026 - PRAXIS
Innerhalb eines KI-gestützten Entwicklerwerkzeugs ist ein dynamischer Wechsel der KI-Modelle nicht immer so ohne Weiteres möglich. Dabei wäre dies oft hilfreich – besonders in Szenarien, wo es um die Optimierung der Token-Nutzung geht. Einfache Aufgaben lassen sich so durch kostengünstige Modelle erledigen, während leistungsstärkere und somit auch teurere Modelle an komplexeren Herausforderungen knobeln. Lynkr [1] löst dieses Problem, indem die Software als Proxy zwischen einem Backend, also beispielsweise dem Entwicklerwerkzeug und dem KI-Modell eines Anbieters, typischerweise einem LLM (Large Language Model), auftritt. Das Tool erlaubt die Konfiguration vieler unterschiedlicher LLMs und leitet eingehende Anfragen basierend auf einem komplexen Routing-Mechanismus an das passende LLM weiter.
Jede Anfrage durchläuft für die Entscheidungsfindung mehrere Stufen und bekommt am Ende einen Score zugewiesen. Dieser bewegt sich innerhalb von vier unterschiedlichen Tier-Stufen (Simple, Medium, Complex und Reasoning). In der Konfiguration weisen Sie den einzelnen Stufen, basierend auf Ihren individuellen LLM-Subskriptionen, die entsprechenden AI-Modelle zu. Lynkr unterstützt ebenfalls Ollama [2], sodass Sie bestimmte Aufgaben sogar lokal, ohne einen Cloudzugang, verarbeiten können.
Tools und MCP
Ein weiteres interessantes Feature von Lynkr ist, dass Sie eine ganze Reihe an Tools entweder im Backend – also der Entwicklungsumgebung – oder auch auf dem Lynkr-Server selbst ausführen können. Somit behalten Sie die Kontrolle darüber, auf welchem System welche Aktionen stattfinden. Beispielsweise ließen sich sämtliche API-Keys zentral auf dem Lynkr-Server speichern und ein lesender Zugriff auf diese Keys gewähren. Ein schreibender Zugriff wäre auf dem Client möglich, um beispielsweise Änderungen an einem Code-Repository vorzunehmen. Die integrierten Tools lassen sich erweitern, indem Sie mithilfe des Model Context Protocols (MCP) Zugriff auch auf andere Systeme erlauben, um somit die Tools dieser Systeme in Lynkr zu registrieren.
Innerhalb eines KI-gestützten Entwicklerwerkzeugs ist ein dynamischer Wechsel der KI-Modelle nicht immer so ohne Weiteres möglich. Dabei wäre dies oft hilfreich – besonders in Szenarien, wo es um die Optimierung der Token-Nutzung geht. Einfache Aufgaben lassen sich so durch kostengünstige Modelle erledigen, während leistungsstärkere und somit auch teurere Modelle an komplexeren Herausforderungen knobeln. Lynkr [1] löst dieses Problem, indem die Software als Proxy zwischen einem Backend, also beispielsweise dem Entwicklerwerkzeug und dem KI-Modell eines Anbieters, typischerweise einem LLM (Large Language Model), auftritt. Das Tool erlaubt die Konfiguration vieler unterschiedlicher LLMs und leitet eingehende Anfragen basierend auf einem komplexen Routing-Mechanismus an das passende LLM weiter.
Jede Anfrage durchläuft für die Entscheidungsfindung mehrere Stufen und bekommt am Ende einen Score zugewiesen. Dieser bewegt sich innerhalb von vier unterschiedlichen Tier-Stufen (Simple, Medium, Complex und Reasoning). In der Konfiguration weisen Sie den einzelnen Stufen, basierend auf Ihren individuellen LLM-Subskriptionen, die entsprechenden AI-Modelle zu. Lynkr unterstützt ebenfalls Ollama [2], sodass Sie bestimmte Aufgaben sogar lokal, ohne einen Cloudzugang, verarbeiten können.
Tools und MCP
Ein weiteres interessantes Feature von Lynkr ist, dass Sie eine ganze Reihe an Tools entweder im Backend – also der Entwicklungsumgebung – oder auch auf dem Lynkr-Server selbst ausführen können. Somit behalten Sie die Kontrolle darüber, auf welchem System welche Aktionen stattfinden. Beispielsweise ließen sich sämtliche API-Keys zentral auf dem Lynkr-Server speichern und ein lesender Zugriff auf diese Keys gewähren. Ein schreibender Zugriff wäre auf dem Client möglich, um beispielsweise Änderungen an einem Code-Repository vorzunehmen. Die integrierten Tools lassen sich erweitern, indem Sie mithilfe des Model Context Protocols (MCP) Zugriff auch auf andere Systeme erlauben, um somit die Tools dieser Systeme in Lynkr zu registrieren.
Installation als npm-Paket
Lynkr ist in JavaScript geschrieben und steht somit als npm-Paket zur Verfügung. Zur systemweiten Installation rufen Sie einfach npm wie folgt auf:
npm install -g lynkr
Der Aufruf von
lynkr --version sollte Ihnen im Anschluss die korrekte Installation des Pakets bestätigen. Als Alternative können Sie natürlich auch das Git-Repository [3] klonen und eine lokale Installation auf Basis des aktuellen Codes durchführen:git clone https://github.com/ vishalveerareddy123/Lynkr.git
cd Lynkr
npm install
cp .env.example .env
npm start
Neben diesen beiden Varianten besteht ebenfalls die Möglichkeit, die Software innerhalb eines Containers oder auch als Brew-Paket zu installieren. Sämtliche Installationsmethoden sind unter [4] im Detail beschrieben.
Die Datei ".env" enthält sämtliche Konfigurationsanweisungen, die für den Betrieb des Proxy-Servers notwendig sind. Hier tragen Sie primär die API-Schlüssel für Ihre verfügbaren Large-Language-Models (LLM) ein und definieren ein passendes Routing für diese Modelle. Es bietet sich an, erst einmal ein einzelnes Modell zu konfigurieren, um die korrekte Funktionsweise des Proxies zu verifizieren. Im einfachsten Fall kann dies auch ein lokales Ollama-Modell sein. In unserem Test verwenden wir das LLM Llama3.2 mit 3 Milliarden Parametern.
Ollama für lokale Modelle
In der Datei ".env" sind die folgenden Angaben notwendig, um eingehende Proxy-Anfragen an Ollama weiterzuleiten:
MODEL_PROVIDER=ollama OLLAMA_MODEL=llama3.2:3b
Bevor Sie nun den Zugriff über den Proxy testen, stellen Sie sicher, dass ein direkter Zugriff auf das Modell funktioniert. Hierfür starten Sie zuerst das Modell und stellen dann mit curl eine einfache Anfrage an das REST-API des Providers. Ollama lauscht auf dem lokalen Port 11434 auf eingehende Anfragen:
ollama serve
curl -s -X POST http://127.0.0.1: 11434/api/chat -H "Content-Type: application/json" -d "{ "model": "llama3.2:3b", "messages": [{"role": "user", "content": "Was ist die Hauptstadt von Deutschland?"}], "stream": false }"
Leiten Sie die Ausgabe durch das Tool jq, bekommen Sie im Erfolgsfall eine hübsch formatierte JSON-Ausgabe mit der passenden Antwort angezeigt. Hat dies funktioniert, klappt der Zugriff auf Ollama und das dort hinterlegte Modell. Sollte Ollama auf einem anderen Rechner laufen, können Sie die Software auch anweisen auf allen konfigurierten IP-Adressen auf Anfragen zu reagieren. Hierfür setzen Sie einfach die folgende Umgebungsvariable mittels
export OLLAMA_HOST="0.0.0.0:11434"
Dynamischer Modellwechsel dank Tier-Routing
Um nun einen dynamischen Wechsel auf unterschiedliche Modelle zu ermöglichen, muss in der Lynkr-Konfiguration das Tier-Routing aktiviert sein. Hierfür weisen Sie in der Datei ".env" die gewünschten LLM-Provider den einzelnen Tier-Stufen zu:
TIER_SIMPLE=ollama:llama3.2 TIER_MEDIUM=openai:gpt-4o TIER_COMPLEX=openai:o1-mini TIER_REASONING=openai:o1
Natürlich sind zusätzlich auch die API-Schlüssel für den Zugriff auf die LLMs zu hinterlegen. Die Datei enthält bereits für alle unterstützten Provider eine eigene Sektion, in der Sie die Konfiguration vornehmen. Starten Sie nun Lynkr, beispielsweise durch den Aufruf von
npm start aus dem Verzeichnis, in dem das Github-Repository liegt, sollten Sie auch hier zuerst einen einfachen Test durchführen, ob der Proxy auf Anfragen reagiert:curl http://localhost:8081/health/ready
Lynkr antwortet ebenfalls im JSON-Format, welches Sie am besten direkt wieder durch jq leiten, und in der Ausgabe sollten Sie den Status als "ready" angezeigt bekommen. Hat dies geklappt, senden Sie mithilfe von curl nun eine Anfrage an den Proxy:
curl -s -X POST http://127.0.0.1: 8081/v1/chat/completions -H "Content-Type: application/json" -d "{ "model": "llama3.2:3b", "messages": [ { "role": "user", "content": "Wie viel ist 2+2?" } ] }"
In diesem Beispiel richtet sich die Anfrage an das lokale LLM (Tier-Stufe SIMPLE). Für komplexere Aufgaben kommen dann jeweils die LLMs aus den höherwertigen Tier-Stufen zum Einsatz. Die Lynkr-Dokumentation beschreibt das Tier-Routing sehr ausführlich [5]. Hat dies alles funktioniert, ist der LLM-Proxy ab nun einsatzbereit.
In Ihrem KI-gestützten Entwicklerwerkzeug tragen Sie nun den Lynkr-Proxy-Endpunkt ein. Als API-Schlüssel übergeben Sie einen Dummy-Wert, da der richtige Schlüssel ja bereits auf dem Proxy hinterlegt ist. Die Konfiguration unterscheidet sich je nach Entwicklerwerkzeug und es empfiehlt sich, hierfür einen Blick in die Dokumentation zu werfen [4]. Für Claude Code setzen Sie einfach die folgenden Umgebungsvariablen, um sämtliche Anfragen an den Lynkr-Proxy zu senden:
export ANTHROPIC_BASE_URL=http://localhost:8081 export ANTHROPIC_API_KEY=dummy
Fazit
Lynkr stellt einen zentralen Proxy für den Zugriff auf unterschiedliche LLM-Provider und deren AI-Modelle zur Verfügung. Durch Funktionen wie flexibles Routing, Toolausführung und die Integrationsmöglichkeiten von lokalen AI-Modellen entsteht eine kontrollierbare und effiziente Infrastruktur für den Einsatz von AI-Modellen. Somit bietet Lynkr die Möglichkeit, LLMs flexibel, sicher und kosteneffizient einsetzen zu können. Ein zentraler Proxy, der sämtliche API-Schlüssel bündelt, ist jedoch ein zweischneidiges Schwert: Er vereinfacht das Credential-Management erheblich, konzentriert aber auch das Angriffsziel. Wer Lynkr produktiv betreibt, sollte den Proxy-Endpunkt konsequent absichern.
(dr)
Links
[1] Lynkr: https://it-a.eu/q6pc1
[2] Ollama: https://it-a.eu/q6pc2
[3] Lynkr auf GitHub: https://it-a.eu/q6pc3
[4] Lynkr-Dokumentation: https://it-a.eu/q6pc4
[5] Lynkr-Tier-Routing: https://it-a.eu/q6pc5