KI in Moodle läuft in unserem Referenzprojekt auf dem Schulserver. Mehrere Plugins übernehmen dort unterschiedliche Aufgaben: Der mosKI-Coursebot bietet Chat mit Ollama, Speaches und Whisper. Bild-OCR nutzt Ollama Vision. Das Debatten-Dojo verbindet Ollama und Whisper für gesprochene Debatten. Die PuG-Lernreise verwendet GPUQ und Ollama für lokale Feedback-Funktionen.
Der Schulserver „Cosmo“ der MOS München zeigt, wie dieser Aufbau in der Praxis funktioniert. Panomity betreut und hostet das System mit selbst entwickelter Software. Die Moodle-5.x-Instanz „mos Kurse“, die lokalen KI-Dienste und weitere Anwendungen laufen gemeinsam auf einem gut dimensionierten Server. Docker-Container strukturieren die Dienste, während GPUQ eine GPU fair zwischen KI-Diensten und Plugins teilt.
GPUQ reiht KI-Aufträge in einer Warteschlange ein, teilt eine GPU fair zwischen Diensten und Plugins und bietet Status. Auf dem Schulserver arbeiten mehrere KI-Dienste und Moodle-Plugins mit dieser selbst entwickelten Queue. So verbindet die Architektur lokale Dienste mit einer gemeinsamen GPU-Infrastruktur.
Was bedeutet selbstgehostete KI in Moodle?
Selbstgehostete KI in Moodle bedeutet, dass Sprachmodelle, Spracherkennung und die Koordination der Rechenaufträge auf dem Schulserver laufen. Je nach Plugin kommen Ollama, Speaches mit Whisper oder GPUQ zum Einsatz. Schülerdaten verlassen den Schulserver nicht, und für diese Funktionen ist keine US-Cloud-KI nötig.
Ollama, Speaches und GPUQ laufen lokal auf derselben Schulserver-Infrastruktur wie die Moodle-5.x-Instanz. Ollama stellt lokale Sprachmodelle für Chat und Text bereit. Speaches übernimmt lokale Spracherkennung mit Whisper und Sprachausgabe. GPUQ teilt die GPU fair zwischen KI-Diensten und Plugins und bietet Warteschlange und Status.
Die Moodle-5.x-Instanz heißt „mos Kurse“. Dahinter laufen Ollama, Speaches und GPUQ auf dem Schulserver. Die Plugins nutzen je nach Aufgabe unterschiedliche Dienste: Chat und Text über Ollama, Sprache über Speaches und Whisper oder GPUQ und Ollama für die Feedback-Funktionen der PuG-Lernreise.
Wie ist die Architektur für KI in Moodle aufgebaut?
Unsere Architektur für KI in Moodle verbindet vier Ebenen: die Moodle-Instanz mit ihren Lernaktivitäten, GPUQ für faire GPU-Verteilung, Warteschlange und Status, Ollama für Chat und Text sowie Speaches für lokale Sprache. Docker-Container bündeln diese Dienste auf einem Server. GPUQ teilt dort eine GPU zwischen den KI-Diensten und Plugins.
1. Moodle stellt den didaktischen Kontext bereit
Der mosKI-Coursebot unterstützt Chat. Das Debatten-Dojo nutzt Ollama und Whisper für gesprochene Debatten. Die PuG-Lernreise nutzt GPUQ und Ollama lokal für Feedback-Funktionen. Diese Moodle-Plugins gehören zum selbst entwickelten Portfolio auf der Moodle-5.x-Instanz „mos Kurse“.
Control AI ist das Plugin für die zentrale KI-Steuerung. Daneben nutzen weitere Module die lokalen Dienste: Die Mündliche Prüfungssimulation arbeitet mit Ollama, das Debatten-Dojo mit Ollama und Whisper. Die PuG-Lernreise verwendet GPUQ und Ollama für Feedback-Funktionen.
2. GPUQ koordiniert die gemeinsame GPU
GPUQ ist unsere selbst entwickelte GPU-Job-Queue, also eine Warteschlange für GPU-Aufträge. Sie teilt eine GPU fair zwischen den beteiligten KI-Diensten und Moodle-Plugins. Zusätzlich bietet GPUQ einen Status.
Auf dem Schulserver nutzen Chat, Bildverarbeitung, Sprachaufgaben und Feedback lokale KI-Dienste. GPUQ teilt die eine GPU fair zwischen den beteiligten Diensten und Plugins und ergänzt diese Verteilung um Warteschlange und Status. Welche Komponente ein Plugin nutzt, zeigt die Zuordnung im nächsten Abschnitt.
3. Ollama verarbeitet Chat, Text und Bilder
Ollama stellt auf dem Schulserver lokale Sprachmodelle für Chat und Textaufgaben bereit. Im Referenzsystem läuft der Dienst lokal. Für diese Modellverarbeitung ist keine US-Cloud-KI nötig. Bild-OCR nutzt Ollama Vision.
Ollama ist nicht auf einen einzigen Plugin-Typ beschränkt. Der mosKI-Coursebot nutzt es für Chat, Bild-OCR verwendet Ollama Vision, und die Mündliche Prüfungssimulation arbeitet ebenfalls mit Ollama. Im Debatten-Dojo ergänzt Ollama die Spracherkennung. Auch die PuG-Lernreise und der lokale PuG KI-Helfer sind über GPUQ und Ollama angebunden.
4. Speaches und Whisper übernehmen Sprache lokal
Speaches stellt lokale Spracherkennung sowie Sprachausgabe bereit. Für die Erkennung kommt Whisper zum Einsatz. Der mosKI-Coursebot verbindet Ollama, Speaches und Whisper. Das Debatten-Dojo nutzt Ollama und Whisper für gesprochene Debatten.
Zum Portfolio gehört außerdem das KI-Plugin Audio-Transkription. Es ergänzt die lokalen Sprachfunktionen des Schulservers, sodass neben Chat und gesprochenen Debatten auch die Transkription von Audio lokal abgedeckt ist.
Welche Komponente übernimmt welche Aufgabe?
Die Architektur besteht aus klar zugeordneten Komponenten. Moodle 5.x trägt die Plugins und Lernaktivitäten. GPUQ teilt eine GPU fair und bietet Warteschlange und Status. Ollama stellt lokale Sprachmodelle für Chat und Text bereit; Ollama Vision dient Bild-OCR. Speaches liefert lokale Spracherkennung mit Whisper sowie Sprachausgabe.
| Komponente | Aufgabe | Plugin-Nutzer |
|---|---|---|
| Moodle 5.x | Kurse, Aktivitäten und didaktischer Kontext | mosKI, Control AI, Bild-OCR, Audio-Transkription, Mündliche Prüfungssimulation, Debatten-Dojo, PuG-Lernreise, PuG KI-Helfer |
| GPUQ | Faire Verteilung einer GPU, Warteschlange und Status | PuG-Lernreise und PuG KI-Helfer; gemeinsame KI-Dienste und Plugins |
| Ollama | Lokale Sprachmodelle für Chat, Text und Vision-Aufgaben | mosKI, Bild-OCR, Mündliche Prüfungssimulation, Debatten-Dojo, PuG-Lernreise, PuG KI-Helfer |
| Speaches mit Whisper | Lokale Spracherkennung sowie Sprachausgabe | mosKI; Whisper im Debatten-Dojo |
Control AI übernimmt die zentrale KI-Steuerung. Audio-Transkription gehört ebenfalls zum Portfolio der Moodle-KI-Plugins. Beide erscheinen deshalb in der Moodle-Zeile der Tabelle.
Wie nutzen die Moodle-Plugins die KI-Architektur?
Die Plugins nutzen unterschiedliche Teile der lokalen KI-Architektur. mosKI verbindet Ollama, Speaches und Whisper. Bild-OCR nutzt Ollama Vision, die Mündliche Prüfungssimulation Ollama. Das Debatten-Dojo kombiniert Ollama und Whisper. PuG-Lernreise und PuG KI-Helfer arbeiten mit GPUQ und Ollama. Control AI übernimmt die zentrale KI-Steuerung.
mosKI und Control AI
mosKI ist der Coursebot der Moodle-Instanz. Für seinen Chat greift er auf Ollama zurück; außerdem nutzt er Speaches und Whisper. Control AI dient der zentralen KI-Steuerung. Beide gehören zum Portfolio der selbst entwickelten Moodle-KI-Plugins.
Bild-OCR und Audio-Transkription
Bild-OCR nutzt Ollama Vision. Audio-Transkription gehört ebenfalls zum Portfolio der selbst entwickelten Moodle-KI-Plugins. Damit enthält das Portfolio neben Chat- und Feedback-Funktionen auch Bild-OCR und Audio-Transkription.
Prüfungssimulation und Debatten-Dojo
Die Mündliche Prüfungssimulation nutzt Ollama. Das Debatten-Dojo kombiniert Ollama mit Whisper und ermöglicht gesprochene Debatten. Für beide Plugins ist damit die Verbindung zu Ollama belegt; beim Debatten-Dojo kommt Whisper für die Spracherkennung hinzu.
KI-Feedback in der PuG-Lernreise
Die PuG-Lernreise führt Lernende durch Stationen und speichert Lösungen, Entwürfe, Feedback und Fortschritt in eigenen Datenbanktabellen. Für Feedback-Funktionen nutzt das Aktivitätsmodul GPUQ und Ollama lokal. Die KI dient als Feedback-Helfer nach dem Prinzip „Hilfe zur Selbsthilfe“ und nicht als Automat, der fertige Lösungen ausgibt.
Warum braucht eine GPU eine Warteschlange?
GPUQ reiht Rechenaufträge ein und teilt die eine vorhandene GPU fair zwischen KI-Diensten und Plugins. Die selbst entwickelte Komponente bietet dafür eine Warteschlange und Status. Auf dem Schulserver arbeiten so mehrere lokale KI-Funktionen hinter Moodle gemeinsam mit derselben dort vorhandenen GPU-Infrastruktur.
Der entscheidende Architekturgedanke lautet nicht „eine GPU pro Anwendung“, sondern „eine koordinierte GPU für viele Aufgaben“. Das passt zu einem Schulserver, auf dem nicht nur Moodle läuft. Auch Perplexica, Open Notebook, das zugangsgeschützte OpenClaw-Assistenzportal, n8n, OnlyOffice und Vaultwarden gehören zu den weiteren selbstgehosteten Diensten am Standort.
GPUQ kombiniert eine Warteschlange mit Status und teilt eine GPU fair zwischen KI-Diensten und Plugins. Damit steht dieselbe selbst entwickelte GPU-Queue für die lokalen KI-Funktionen hinter Moodle bereit.
Was bedeutet Self-Hosting für Schülerdaten?
Beim beschriebenen Self-Hosting bleiben Schülerdaten auf dem Schulserver. Ollama, Speaches und GPUQ laufen dort als lokale Dienste in Docker-Containern. Eine US-Cloud-KI ist für diese Funktionen nicht nötig. Die Architektur verbindet damit lokale KI-Dienste auf dem Schulserver mit Moodle; Schülerdaten verlassen den Schulserver nicht.
Datenschutz durch Selbsthosting bedeutet hier: Schülerdaten verlassen den Schulserver nicht. Ollama stellt dort lokale Sprachmodelle bereit, Speaches lokale Sprachfunktionen, und GPUQ teilt die GPU fair zwischen den KI-Diensten und Plugins. Eine US-Cloud-KI ist nicht nötig.
Die technische Aussage bleibt bewusst präzise. Wir behaupten weder einen Betrieb ohne Internet noch eine pauschale rechtliche Zertifizierung. Belegt ist: Schülerdaten verlassen den Schulserver nicht, und für die beschriebenen KI-Funktionen ist keine US-Cloud-KI nötig. Diese beiden Eigenschaften bilden das Datenschutzargument des Aufbaus.
Warum läuft GPUQ auch hinter dem KI-Concierge?
GPUQ ist nicht an Moodle gebunden. Die selbst entwickelte Queue läuft auch auf dem Panomity-Server für CMS4VR. Die VR-Tour-Plattform nutzt einen selbstgehosteten KI-Concierge mit Ollama und Whisper-Spracherkennung. Damit ist GPUQ sowohl hinter Moodle auf dem Schulserver als auch im CMS4VR-Kontext im Einsatz.
CMS4VR und der Schulserver sind zwei getrennte Einsatzumgebungen. In der VR-Plattform verbindet der selbstgehostete KI-Concierge Ollama und Whisper-Spracherkennung mit virtuellen Touren. Hinter Moodle verbindet GPUQ dieselbe Architekturidee mit Coursebot, Debatten, Bildverarbeitung und Feedback. Die wiederverwendbare Komponente ist die Queue, nicht der fachliche Anwendungsfall.
Panomity liefert Entwicklung und Hosting für Moodle, VR und KI-Infrastruktur aus einer Hand. GPUQ ist dabei ein selbst entwickelter Baustein in zwei belegten Umgebungen: auf dem Schulserver hinter Moodle und auf dem Panomity-Server für CMS4VR.
Welche Serverbasis trägt die lokale KI?
Die lokalen KI-Dienste laufen mit der Moodle-Instanz auf einem Schulserver in Docker-Containern. Ollama stellt lokale Sprachmodelle bereit, Speaches lokale Sprachfunktionen, und GPUQ koordiniert eine GPU mit Warteschlange und Status. Ein gut dimensionierter Server mit Docker und GPU-Queue reicht für das vollständige EdTech-Ökosystem der Schule.
Docker-Container ordnen mehrere Dienste auf dem einen Server. Dazu gehören Moodle, lokale KI-Dienste und weitere selbstgehostete Werkzeuge am Standort. GPUQ koordiniert dabei den Zugriff der KI-Dienste und Plugins auf eine GPU und ergänzt diese Verteilung um Warteschlange und Status.
Häufige Fragen zu KI in Moodle
Braucht selbstgehostete KI in Moodle eine eigene GPU pro Plugin?
Nein. Im Referenzprojekt teilen sich die lokalen KI-Dienste und Moodle-Plugins eine GPU. Die selbst entwickelte Job-Queue GPUQ bietet eine Warteschlange und Status und verteilt die GPU fair. Dadurch nutzen Coursebot, Feedback-, Bild- und Sprachfunktionen dieselbe GPU-Infrastruktur, statt für jedes Plugin eigene Hardware vorauszusetzen.
Welche Aufgaben übernimmt Ollama hinter Moodle?
Ollama stellt lokale Sprachmodelle für Chat und Textaufgaben bereit. Im Referenzsystem nutzt der mosKI-Coursebot den Dienst für Chat. Bild-OCR greift auf Ollama Vision zu, die Mündliche Prüfungssimulation auf Ollama. Auch Debatten-Dojo, PuG-Lernreise und PuG KI-Helfer verwenden Ollama in ihren jeweils belegten lokalen KI-Funktionen.
Wie funktionieren gesprochene Debatten im Debatten-Dojo?
Das Debatten-Dojo verbindet Ollama mit Whisper. Whisper übernimmt im lokalen Aufbau die Spracherkennung, sodass das Moodle-Aktivitätsmodul gesprochene Debatten verarbeitet. Ollama und die Whisper-Spracherkennung kommen dabei lokal auf dem Schulserver zum Einsatz. Schülerdaten verlassen den Schulserver nicht, und für diese Funktion ist keine US-Cloud-KI nötig.
Verlassen Schülerdaten für die KI-Verarbeitung den Schulserver?
Nein. In der beschriebenen selbstgehosteten Architektur bleiben Schülerdaten auf dem Schulserver. Ollama verarbeitet Chat-, Text- und Vision-Aufgaben lokal, Speaches stellt lokale Sprachfunktionen bereit, und GPUQ koordiniert die GPU-Aufträge. Für diese Moodle-Funktionen muss die Schule deshalb keine Daten an eine US-Cloud-KI übertragen.
Kann GPUQ auch außerhalb von Moodle eingesetzt werden?
Ja. GPUQ läuft auch auf dem Panomity-Server für die VR-Plattform CMS4VR. Dort wird die selbst entwickelte Queue hinter der selbstgehosteten KI-Infrastruktur des KI-Concierge eingesetzt. CMS4VR nutzt einen selbstgehosteten Concierge mit Ollama und Whisper-Spracherkennung. Damit ist GPUQ sowohl im Moodle- als auch im VR-Kontext belegt.
Fazit: KI in Moodle aus Entwicklung und Hosting
Der Architekturaufbau verbindet Moodle-Plugins mit Ollama, Speaches, Whisper und GPUQ auf dem Schulserver. Eine GPU wird fair zwischen den KI-Diensten und Plugins geteilt; GPUQ bietet Warteschlange und Status. Coursebot, Bild-OCR, Prüfungssimulation, gesprochene Debatten und lokales Lernreise-Feedback nutzen diese gemeinsame technische Basis.
Panomity entwickelt und hostet EdTech aus einer Hand: Moodle, maßgeschneiderte Plugins und die zugehörige KI-Infrastruktur. Wenn Du eine selbstgehostete Architektur für Deine Lernplattform planst, erfährst Du mehr über unser Hosting und unsere IT-Infrastruktur aus München.
0 Kommentare