Im vorherigen Teil dieser Serie haben wir uns grundsätzlich angeschaut, wie litellm und die Theia-IDE dafür genutzt werden können, um die Möglichkeiten der KI-basierten Software-Entwicklung zu nutzen und parallel die volle Kontrolle über die eigenen Daten und die Kosten zu behalten. In diesem Beitrag soll es darum gehen, wie das Setup optimiert werden kann. Der Fokus soll dabei auf einem möglichst einfachen Betrieb liegen.
litellm as a service – nur eben lokal
Der erste Schritt besteht darin, litellm grundsätzlich immer automatisch beim Systemstart zu starten und im Hintergrund laufen zu lassen. Dies lässt sich auf Linux am Besten mit einem systemd-Service umsetzen. Aber auch für Windows und MacOS gibt es Möglichkeiten. Solltet ihr litellm als Docker-Container laufen lassen, so können auch diese automatisch gestartet werden. Seht es mir nach, dass ich im Rahmen dieses Blog-Eintrages nicht jedes Setup abdecken kann.
Wie im letzten Teil erwähnt, habe ich mich dafür entschieden, die litellm-Konfiguration so weit wie möglich über die „config.yaml“ umzusetzen. Da ich diese gerne in einem Git-Repository sichern möchte, habe ich im ersten Schritt die geheimen Daten durch Umgebungsvariablen ersetzt.
model_list:
- model_name: MistralSmall24BInstruct
litellm_params:
model: openai/mistralai/Mistral-Small-24B-Instruct
api_base: https://openai.inference.de-txl.ionos.com/v1
api_key: "os.environ/LITELLM_IONOS_API_KEY"
input_cost_per_token: 12e-08
output_cost_per_token: 35e-08
general_settings:
master_key: "os.environ/LITELLM_MASTER_KEY"
salt_key: "os.environ/LITELLM_SALT_KEY"
database_url: "os.environ/LITELLM_DATABASE_URL"Um litellm nun automatisch nach dem Systemstart zu starten, wird als nächstes ein systemd-Service benötigt. Dieser muss neben dem Aufruf selbst, natürlich noch die Umgebungsvariablen beinhalten. Zudem sollte der Service nicht mit root-Rechten laufen. Die Logs von litellm werden im Beispiel unten in einem „logs“-Ordner neben der litellm-Installation abgelegt.
[Unit]
Description=LiteLLM Service
After=network.target
[Service]
User=benutzer
Group=benutzer
WorkingDirectory=/home/benutzer/workspace/litellm
Environment="LITELLM_IONOS_API_KEY=mein_ionos_api_key"
Environment="LITELLM_MASTER_KEY=sk-mein_sehr_sicherer_master_key"
Environment="LITELLM_SALT_KEY=sk-mein_sehr_sicherer_salt_key"
Environment="LITELLM_DATABASE_URL=meine_sehr_sichere_datenbank_url"
ExecStart=/home/benutzer/workspace/litellm/bin/python3 /home/benutzer/workspace/litellm/bin/litellm --config config.yaml
StandardOutput=append:/home/benutzer/workspace/litellm/logs/litellm.log
StandardError=append:/home/benutzer/workspace/litellm/logs/litellm.log
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
Nach dem Erstellen der Datei sollten zunächst die Zugriffsrechte angepasst werden. Außerdem muss der Service selbst natürlich aktiviert und gestartet werden.
sudo chown root:root /etc/systemd/system/litellm.service
sudo chmod 600 /etc/systemd/system/litellm.service
sudo systemctl daemon-reload
sudo systemctl enable litellm.service
sudo systemctl start litellm.serviceAnpassen der Budgetierung
Aktuell haben wir nur einen Benutzer in litellm, dem ein Budget zugewiesen wurde, ein maximal verfügbares Budget wird ihm aber nicht angezeigt. Hierzu muss ein Team angelegt und der Nutzer selbigem zugewiesen werden. Außerdem kann der Anwender aktuell noch zusätzliche Modelle anlegen und den Kostenrahmen so weiter eskalieren lassen. Beides wollen wir nun ändern. Als erstes erstellen wir ein Team und fügen den momentanen Benutzer hinzu. Dazu gehen wir auf den Tab „Teams“ im WebUI und erstellen ein neues Team. Hier können wir wieder Budget und verfügbare Modelle konfigurieren. Dies hat den Vorteil, das wir die Budgetierung für einzelne Benutzer – oder in unserem Fall Tools – anpassen können. So können wir beim experimentieren mit neuen Tools sicherstellen, dass wir trotzdem in unserem gesetzten Kostenrahmen bleiben.
Nachdem das Team erstellt wurde, können wir unseren Theia-Nutzer als Mitglied hinzufügen. Dazu wählen wir das Team aus und gehen auf „Add Member“, suchen per E-Mail und beenden den Vorgang mit einem Klick auf „Add Member“. Die Berechtigungen zum Anlegen eines neuen Modells erledigen sich hier dann ebenfalls von allein. Zwar wird der Menüpunkt dem Nutzer in der aktuellen litellm-Version noch angezeigt, ein Versuch ein neues Modell hinzuzufügen, scheitert aber an einer Fehlermeldung, die im Browserfenster angezeigt wird.
Unterschiedliche Modelle für die verschiedenen Agenten
Da für die Verwendung der verschiedenen KI-Modelle, die der IONOS-Model-Hub zur Verfügung stellt, auch unterschiedliche Kosten anfallen, lohnt sich hier eine Optimierung.
Die Theia-IDE stellt verschiedene Agenten bereit, die sicherlich nicht alle das teuerste Modell benötigen. Noch spannender ist die Möglichkeit, Modelle anderer Cloud-Anbieter und vielleicht sogar lokale Modelle zu kombinieren. Im Folgenden konzentriere ich mich auf das How-To der Konfiguration. Zu einem späteren Zeitpunkt ist es sicherlich aber auch interessant, die Eignung der verschiedenen Modelle für die unterschiedlichen Agenten zu testen. Wirft man einen Blick auf die obige Tabelle, so spring einem vor allem die beiden Coding-Agenten von Theia und das „Code Llama 13b Instruct HF“-Modell von IONOS ins Auge. Um ein neues Modell in unsere Umgebung einzupflegen, müssen wir als Erstes die Konfiguration von litellm (config.yaml) um ein weiteres Modell erweitern:
- model_name: CodeLlama13BInstruct
litellm_params:
model: openai/meta-llama/CodeLlama-13b-Instruct-hf
api_base: https://openai.inference.de-txl.ionos.com/v1
api_key: "os.environ/LITELLM_IONOS_API_KEY"
input_cost_per_token: 52e-08
output_cost_per_token: 52e-08Auch hier ist zu beachten, das litellm in US-Dollar kalkuliert. Der Token-Preis von 0,45€ entspricht dabei ungefähr 0,52 US-Dollar. Als Nächstes muss litellm mit den bekannten Kommandos neu gestartet werden und die Modelle sowohl dem Team als auch dem Nutzer zugewiesen werden.
Nun müssen wir in der Theia-IDE dem Code-Agenten noch das neue Modell in der „settings.json“-Datei zuweisen. Dazu muss im ersten Schritt das Modell selbst in der Datei festgelegt werden. Wichtig sind dabei vor allem die Werte „model“ und „id“. Beide müssen für das Code-Llama-Modell angepasst werden. Die restlichen Werte bleiben identisch.
{
"window.titleBarStyle": "native",
"redhat.telemetry.enabled": false,
"ai-features.AiEnable.enableAI": true,
"ai-features.openAiCustom.customOpenAiModels": [
{
"model": "MistralSmall24BInstruct",
"url": "http://0.0.0.0:4000",
"id": "IONOS Mistral Small 24b Instruct",
"apiKey": "sk-api-key-des-theia-nutzers",
"developerMessageSettings": "user"
},
{
"model": "CodeLlama13BInstruct",
"url": "http://0.0.0.0:4000",
"id": "IONOS Code Llama 13b Instruct",
"apiKey": "sk-api-key-des-theia-nutzers",
"developerMessageSettings": "user"
},
],
"ai-features.languageModelAliases":{
"default/code": {
"selectedModel": "IONOS Code Llama 13b Instruct"
},
"default/code-completion": {
"selectedModel": "IONOS Code Llama 13b Instruct"
},
"default/summarize": {
"selectedModel": "IONOS Mistral Small 24b Instruct"
},
"default/universal": {
"selectedModel": "IONOS Mistral Small 24b Instruct"
},
},
}Mehr Informationen zu den gesendeten Anfragen
Gerade bei der Arbeit mit unbekannten Anwendungen, kann es interessant sein, die eigentlichen Anfragen und nicht nur ihre Logs in der Datenbank abzuspeichern. Hierzu müssen zwei neue Werte in der „config.yaml“-Datei hinzugefügt werden:
general_settings:
...
store_model_in_db: true
store_prompts_in_spend_logs: true
...Unter dem Abschnitt „Logs“ im Web-UI tauchen nun nicht nur die Kosten und die genaue Anzahl der verbrauchten Token für eine Anfrage auf, sondern eben auch die komplette Anfrage selbst. Läuft litellm als Service, muss es allerdings erst neu gestartet werden, damit die Änderungen übernommen werden:
sudo systemctl daemon-reload
sudo systemctl restart litellm.service Etwas verwirrend ist dabei, das litellm im Interface unter anderem für einzelne Anfragen Werte in Höhe von 0.00 USD, da nicht genug Token verbraucht wurden, um über die zweite Nachkommestelle hinaus relevant zu sein.
Durch Caching Geld sparen
Eine weitere Möglichkeit, die sich recht schnell umsetzen lässt, ist durch die Verwendung eines Caches Geld zu sparen. Die selbe Anfrage wird dann nicht mehrfach an das LLM gesendet, sondern aus dem Speicher beantwortet. Zwar dürfte das wiederholen einen Frage in der Software-Entwicklung recht selten vorkommen, doch litellm macht es einem sehr leicht, den Cache zu aktivieren. Dabei stehen verschiedene Möglichkeiten von einem Redis-, über einen Cloud- bis hin zu zwei lokalen-Caches bereit. Da wir Kosten sparen wollen, fallen die Cloud-basierten Dienste heraus. Zusätzlich zu der PostgreSQL-Datenbank noch einen Redis-Server aufzusetzen ist zwar möglich, aber irgendwie zu viel des Guten. Da mein Notebook aktuell lediglich nur acht Gigabyte Arbeitsspeicher hat, fällt auch der lokale In-Memory-Cache weg. Stattdessen entschließe ich mich für den Cache vom Typen „Disk“. Hierzu muss noch das „caching“-Paket von litellm nachgeladen werden. Wichtig dabei ist, dass „pip3“ aus der virtuellen Python-Umgebung verwendet werden muss.
/home/benutzer/workspace/litellm/bin/pip3 install 'litellm[caching]' Nach der erfolgreichen Installation, muss noch ein neuer Abschnitt in der „config.yaml“-Datei hinzugefügt und der Service mit den selben Kommandos wie oben, neu gestartet werden.
litellm_settings:
cache: True
cache_params:
type: diskIn meinen Tests mit der Theia-IDE wurden die Antworten, trotz der gleichen Anfrage, jedoch nicht aus dem Cache beantwortet. Für einen späteren Einsatz, zu dem ich später noch einen Artikel veröffentlichen werde, ist ein Cache aber dennoch hilfreich.
