AIdea Server: ein Go-Backend für Chat- und Bildmodelle, mit Selfhosting-Option

Welches Problem der Server löst und für wen er gedacht ist

Ein einzelner Client, der GPT, Qwen, Wenxin Yiyan sowie Stable Diffusion, SDXL 1.0, Upscaling und Bildkolorierung ansprechen soll, braucht eine Vermittlungsschicht. Genau diese Rolle übernimmt aidea-server: Er nimmt Anfragen der AIdea-App entgegen, übersetzt sie in die jeweiligen Anbieter-Protokolle und reicht Ergebnisse zurück. Die Zielgruppe ist damit enger, als der Name vermuten lässt. Angesprochen sind Betreiber, die die zugehörige App aus dem Repository mylxsw/aidea ausliefern und den Backend-Teil nicht dem gehosteten Dienst unter ai.aicode.cc überlassen wollen. Das README nennt zwei Wege: das Deployment nach der Anleitung in docs/deploy.md oder eine assistierte Installation über docs/deploy-vip.md. Ein generisches LLM-Gateway für beliebige Anwendungen ist das Projekt nicht, auch wenn der Ordner api laut README OpenAI-kompatible Endpunkte bereitstellt, die fremde Software direkt nutzen kann.

Chat-Modelle hinter einem einzigen Stream-Protokoll

Der interessanteste Teil der Architektur liegt unter pkg/ai/chat. Dort liegt laut README eine abstrakte Chat-Schnittstelle, und alle Chat-Modelle werden so gekapselt, dass sie mit dem OpenAI-Chat-Stream-Protokoll kompatibel sind. Für den Client bedeutet das: Er implementiert das Streaming einmal und bekommt trotzdem Antworten von Modellen unterschiedlicher Hersteller. Die Anbieter-Implementierungen sitzen in pkg/ai, daneben liegen Integrationspakete für Alibaba Cloud (SMS und Content-Safety), Tencent (Speech-to-Text und SMS), Youdao (Übersetzung), DingTalk-Benachrichtigungen und Qiniu für Datei-Uploads. Das ist keine Sammlung von SDK-Wrappern, sondern eine Vermittlungsschicht mit eigener Zuständigkeit: Rate Limiting in pkg/rate, ein SOCKS5-Proxy in pkg/proxy, JWT-Handling in pkg/token. Asynchron laufende Arbeit liegt in internal/queue mit den Consumern unter internal/queue/consumer, während pkg/jobs zeitgesteuerte Aufgaben wie die tägliche Token-Verbrauchsstatistik enthält. Wer den Code liest, sollte die Namenshinweise im README ernst nehmen: Room und Advisory Group im Code bezeichnen beide dasselbe Konzept, das heute Digital Persona heißt. Gleiches gilt für Creation Island, dessen v1 nur bis App-Version 1.0.1 reichte und ab 1.0.2 durch v2 ersetzt wurde.

Zwei hauseigene Frameworks als Einstiegshürde

Der Server steht auf Glacier, einem internen modularen Framework mit Dependency Injection über den go-ioc-Container, und nutzt Eloquent als codegenerierungsbasiertes ORM nach Vorbild von Laravel, mit Unterstützung für MySQL. Beide Bibliotheken stammen vom selben Autor wie das Projekt. Das hat eine praktische Konsequenz: Wer den Code anpassen will, muss sich in zwei Frameworks einarbeiten, für die es außerhalb dieses Ökosystems wenig Referenzmaterial gibt. Die Datenmodelle liegen in pkg/repo/model, die Datenbankoperationen in pkg/repo, die Geschäftslogik in pkg/service. Diese Dreiteilung ist nachvollziehbar, aber sie verlangt Disziplin, weil das README selbst einräumt, dass Codekommentare und technische Dokumentation derzeit begrenzt sind und erst nach und nach ergänzt werden sollen. Für eine Bewertung heißt das: Die Struktur ist lesbar, die Absicht hinter einzelnen Entscheidungen oft nicht. Wer auf Fehlersuche in der Modellschicht geht, arbeitet ohne erklärende Dokumentation.

Inbetriebnahme: Konfiguration, Migrationen, Deployment

Im Wurzelverzeichnis liegen die Vorlagen, die den Betrieb tragen: config.yaml als Beispielkonfiguration, coins-table.yaml als Beispiel-Preistabelle, nginx.conf als Beispiel für den vorgelagerten Webserver und systemd.service als Unit-Vorlage. Der Einstiegspunkt der Anwendung liegt unter cmd, die SQL-Migrationen unter migrate. Ein Deployment besteht damit aus mindestens vier Schritten: Datenbank anlegen und Migrationen aus migrate einspielen, config.yaml an die eigenen Zugangsdaten anpassen, coins-table.yaml mit der gewünschten Preislogik füllen, Dienst über systemd.service starten und nginx.conf als Reverse Proxy davor setzen. Ein Docker-Weg existiert im separaten Repository mylxsw/aidea-docker. Welche Konfigurationsschlüssel in config.yaml tatsächlich Pflicht sind, lässt sich aus dem Material nicht ableiten; dazu müsste der Leser die Datei selbst öffnen. Das ist eine konkrete Lücke in der Außendarstellung, denn ohne belegte Pflichtfelder bleibt der erste Start ein Ausprobieren.

Bezahlung, Kontingente und der Preis für die Integration

Unter internal/payment liegen die Implementierungen für Online-Zahlungen, genannt werden Alipay und Apple. internal/coins enthält die Preis- und Abrechnungslogik, gesteuert über coins-table.yaml. Zusammen mit den Token-Statistiken aus pkg/jobs ergibt das ein Produkt mit Kontingenten und Abrechnung, nicht nur eine API-Fassade. Diese Teile sind es, die den Server von einem reinen Modell-Proxy unterscheiden, und sie sind gleichzeitig der Grund, warum ein Umstieg auf eine schlankere Lösung Arbeit bedeutet: Wer aidea-server einsetzt, übernimmt Zahlungsabwicklung, Guthabenlogik und Verbrauchszählung mit. In der Release-Notiz zur Version 202404071800 taucht Stripe auf, was auf weitere Zahlungsanbindungen hindeutet. Ob und wie diese Integration konfiguriert wird, geht aus dem vorliegenden Material nicht hervor.

Grenzen: dünne Dokumentation und ein Namensproblem

Die größte Einschränkung steht im README selbst. Kommentare und technische Dokumentation seien begrenzt, und die Namensgeschichte zeigt, wie sehr das den Einstieg erschwert: Room, Advisory Group und Digital Persona meinen dieselbe Sache, und Creation Island existiert in zwei fachlich verschiedenen Versionen. Wer die Datenbank oder die API anhand alter Begriffe durchsucht, landet schnell im falschen Zweig. Ein zweiter Punkt betrifft die Ausrichtung: Der Server ist auf einen bestimmten Client zugeschnitten. Die Endpunkte unter server sind laut README für die AIdea-App gedacht, nicht als öffentliche Schnittstelle für Dritte. Der OpenAI-kompatible Teil unter api mildert das ab, ersetzt aber keine stabile, versionierte Fremd-API. Und schließlich das Lizenzthema: Das Repository weist keine Lizenz aus. Ohne Lizenzangabe ist die rechtliche Grundlage für Weitergabe oder kommerziellen Betrieb unklar, und das ist bei einem Projekt, das Zahlungen und Guthaben verwaltet, kein Nebenaspekt. Diese Frage sollte vor jedem produktiven Einsatz mit dem Repository-Inhaber geklärt werden, nicht durch Vermutungen.

Alternative: reiner Proxy statt vollständiger Anwendung

Wer nur mehrere Modellanbieter hinter einer OpenAI-kompatiblen Schnittstelle bündeln will, fährt mit LiteLLM anders. LiteLLM ist auf genau diese Vermittlung spezialisiert: Modellnamen werden auf Anbieter gemappt, Budgets und Schlüssel lassen sich pro Nutzer setzen, und die Konfiguration besteht aus einer YAML-Datei, ohne ORM, ohne Datenbankmigrationen, ohne Zahlungslogik. Der Unterschied liegt nicht im Umfang der Modellliste, sondern in der Zuständigkeit. aidea-server bringt eine vollständige Produktlogik mit: Nutzerkonten, Guthaben, Preistabellen, asynchrone Jobs, Benachrichtigungen. LiteLLM bringt diese Dinge bewusst nicht mit und überlässt sie der umgebenden Anwendung. Wer die AIdea-App ausliefern will, braucht den Server, weil die Client-Endpunkte dort definiert sind. Wer lediglich eigene Dienste an verschiedene Modelle anbinden möchte, trägt mit aidea-server deutlich mehr Betriebslast als nötig.

Wartung, Upgrade und was vor dem Start zu prüfen ist

Der letzte Push liegt laut Repository-Angaben im März 2026, die jüngste aufgeführte Release stammt vom 7. April 2024 mit den Stichpunkten Stripe, gestoppte Ausgabe und Modellkanäle. Zwischen diesen beiden Daten liegen keine im Material genannten Veröffentlichungen, was für die Planung bedeutet, dass die Release-Historie als Grundlage für ein Upgrade-Versprechen nicht taugt. Erschwerend kommt die Kopplung an den Client hinzu: Ändert sich das Datenmodell, wandern die Migrationen unter migrate mit, und der Client muss zur Schemaversion passen. Ein Upgrade ist deshalb kein isolierter Servervorgang. Vor dem ersten Deployment sollten Interessierte drei Dinge konkret prüfen: welche Schlüssel config.yaml zwingend verlangt, ob die Lizenzfrage geklärt ist, und ob die eigene Client-Version zu den Migrationen unter migrate passt. Wer diese drei Punkte beantwortet hat, weiß, ob der Betrieb trägt.

Redaktionelles Fazit

Wer eine fertige Client-App sucht und den Server ohnehin selbst hosten möchte, findet in aidea-server eine zusammenhängende Codebasis mit Docker- und Systemd-Vorlagen. Wer dagegen eine schlanke API-Schicht ohne Payment, Billing und Datenbankmigrationen braucht, ist mit einem reinen Proxy wie LiteLLM besser bedient, weil dort keine Geschäftslogik mitkommt. Vor dem ersten Deployment sollten zwei Dinge geklärt werden: die Lizenz, die das Repository nicht ausweist, und der Zustand der Migrationen unter migrate, weil das Schema an die mitgelieferte Client-Version gekoppelt ist.

Offizielle Quellen

1. Issues
2. mylxsw/aidea-server on GitHub
3. Project website
4. README
5. Releases