In our reference project, AI in Moodle runs on the school server. Several plugins perform different tasks there. The mosKI coursebot provides chat with Ollama, Speaches and Whisper. Bild-OCR uses Ollama Vision. Debatten-Dojo combines Ollama and Whisper for spoken debates. PuG-Lernreise uses GPUQ and Ollama for local feedback functions.
The “Cosmo” server at MOS Munich shows this architecture in practice. Panomity hosts and manages the system with software we developed. Its Moodle 5.x instance, “mos Kurse,” shares one well-sized server with the local AI services and other applications. Docker containers organise the services, while GPUQ shares one GPU fairly among AI services and plugins.
GPUQ places AI jobs in a queue, shares one GPU fairly among services and plugins, and makes status information available. Several AI services and Moodle plugins use this queue on the school server. The architecture connects those local services to a shared GPU infrastructure.
What does self-hosted AI in Moodle mean?
Self-hosted AI in Moodle means that language models, speech recognition and compute-job coordination run on the school server. Depending on the plugin, the architecture uses Ollama, Speaches with Whisper, or GPUQ. Student data stays on the school server, and these functions do not require a US cloud AI service.
Ollama, Speaches and GPUQ run locally on the same school-server infrastructure as the Moodle 5.x instance. Ollama provides local language models for chat and text. Speaches supplies local speech recognition with Whisper and local speech output. GPUQ shares the GPU fairly among AI services and plugins and provides both a queue and status information.
The Moodle 5.x instance is called “mos Kurse.” Ollama, Speaches and GPUQ run behind it on the school server. Plugins use different services for their confirmed tasks: Ollama for chat and text, Speaches and Whisper for speech, or GPUQ with Ollama for feedback functions in PuG-Lernreise.
How is the architecture for AI in Moodle organised?
Our architecture for AI in Moodle connects four layers: the Moodle instance and its learning activities, GPUQ for fair GPU sharing, queueing and status information, Ollama for chat and text, and Speaches for local speech. Docker containers bring these services together on one server, where GPUQ shares a GPU among AI services and plugins.
1. Moodle provides the educational context
The mosKI coursebot supports chat. Debatten-Dojo uses Ollama and Whisper for spoken debates. PuG-Lernreise uses GPUQ and Ollama locally for feedback functions. These Moodle plugins belong to the portfolio developed for the Moodle 5.x instance “mos Kurse.”
Control AI is the plugin for central AI control. Other modules use the local services: Mündliche Prüfungssimulation, the oral examination simulation, uses Ollama. Debatten-Dojo uses Ollama and Whisper. PuG-Lernreise uses GPUQ and Ollama for feedback functions.
2. GPUQ coordinates one shared GPU
GPUQ is the GPU job queue we developed, meaning a queue for GPU work. It shares one GPU fairly among the participating AI services and Moodle plugins and also provides status information.
3. Ollama handles local chat, text and vision tasks
Ollama runs local language models for chat and text tasks on the school server. The service runs locally in the reference system, so these model functions do not require a US cloud AI service. Bild-OCR uses Ollama Vision.
Several plugins use Ollama in different ways. The mosKI coursebot uses it for chat. Bild-OCR uses Ollama Vision, and the oral examination simulation also uses Ollama. Debatten-Dojo combines Ollama with Whisper. PuG-Lernreise and the local PuG AI assistant use GPUQ and Ollama for their confirmed functions.
4. Speaches and Whisper keep speech local
Speaches provides local speech recognition and local speech output. Whisper supplies the speech recognition. The mosKI coursebot uses Ollama, Speaches and Whisper. Debatten-Dojo combines Ollama with Whisper for spoken debates.
The portfolio also includes the Audio-Transkription AI plugin. It adds to the local speech functions on the school server, so audio transcription joins chat and spoken debates as tasks handled locally.
Which component does what?
The architecture has clearly assigned components. Moodle 5.x supports the plugins and learning activities. GPUQ shares one GPU fairly and provides both a queue and status information. Ollama runs local language models for chat and text; Ollama Vision serves Bild-OCR. Speaches supplies local Whisper speech recognition and speech output.
| Component | Responsibility | Plugin users |
|---|---|---|
| Moodle 5.x | Courses, activities and educational context | mosKI, Control AI, Bild-OCR, Audio-Transkription, Mündliche Prüfungssimulation, Debatten-Dojo, PuG-Lernreise, PuG KI-Helfer |
| GPUQ | Fair sharing of one GPU, queueing and status information | PuG-Lernreise and PuG KI-Helfer; shared AI services and plugins |
| Ollama | Local language models for chat, text and vision tasks | mosKI, Bild-OCR, Mündliche Prüfungssimulation, Debatten-Dojo, PuG-Lernreise, PuG KI-Helfer |
| Speaches with Whisper | Local speech recognition and speech output | mosKI; Whisper in Debatten-Dojo |
Control AI provides central AI control. Audio-Transkription also belongs to the portfolio of Moodle AI plugins. Both therefore appear in the Moodle row of the table.
How do the Moodle plugins use the AI architecture?
The plugins use different parts of the local AI architecture. mosKI combines Ollama, Speaches and Whisper. Bild-OCR uses Ollama Vision, while Mündliche Prüfungssimulation uses Ollama. Debatten-Dojo combines Ollama and Whisper. PuG-Lernreise and PuG KI-Helfer use GPUQ and Ollama. Control AI provides central AI control.
mosKI and Control AI
mosKI is the coursebot for the Moodle instance. It uses Ollama for chat and also uses Speaches and Whisper. Control AI provides central AI control. Both belong to the portfolio of Moodle AI plugins developed for the reference system.
Bild-OCR and Audio-Transkription
Bild-OCR uses Ollama Vision. Audio-Transkription also belongs to the portfolio of Moodle AI plugins. Alongside chat and feedback functions, the portfolio therefore includes Bild-OCR and Audio-Transkription.
Oral examination simulation and Debatten-Dojo
Mündliche Prüfungssimulation, the oral examination simulation, uses Ollama. Debatten-Dojo combines Ollama with Whisper and supports spoken debates. Both plugins therefore have a confirmed Ollama connection; Debatten-Dojo additionally uses Whisper for speech recognition.
AI feedback in PuG-Lernreise
PuG-Lernreise guides learners through stations and stores solutions, drafts, feedback and progress in its own database tables. Its feedback functions use GPUQ and Ollama locally. AI acts as a feedback assistant under the principle of helping learners help themselves, not as a machine that simply supplies completed answers.
Why does one GPU need a job queue?
GPUQ lines up compute jobs and shares the one available GPU fairly among AI services and plugins. The component we developed provides both a queue and status information. Several local AI functions behind Moodle therefore use the same GPU infrastructure on the school server.
GPUQ combines queueing with status information and shares one GPU fairly among AI services and plugins. The same GPU queue is available to the local AI functions behind Moodle.
What does self-hosting mean for student data?
In this self-hosted architecture, student data stays on the school server. Ollama, Speaches and GPUQ run there as local services in Docker containers. No US cloud AI is required for these functions. The architecture connects local AI services on the school server with Moodle; student data does not leave that server.
Data protection through self-hosting means that student data does not leave the school server. Ollama provides local language models there, Speaches provides local speech functions, and GPUQ shares the GPU fairly among AI services and plugins. No US cloud AI is required.
Why does the AI concierge use GPUQ too?
GPUQ is not limited to Moodle. The queue also runs on Panomity’s server for CMS4VR. The virtual tour platform uses a self-hosted AI concierge with Ollama and Whisper speech recognition. GPUQ is therefore used both behind Moodle on the school server and in the CMS4VR context.
CMS4VR and the school server are separate deployments. In the VR platform, the self-hosted AI concierge combines Ollama and Whisper speech recognition with virtual tours. Behind Moodle, GPUQ supports coursebot, debate, vision and feedback use cases. The shared element is the queue and its architecture, not the subject matter.
What server foundation supports local AI?
The local AI services share a school server with the Moodle instance and run in Docker containers. Ollama provides local language models, Speaches provides local speech functions, and GPUQ shares one GPU fairly while providing both a queue and status information. One well-sized server with Docker and a GPU queue supports the school’s complete EdTech ecosystem.
Frequently asked questions about AI in Moodle
Does self-hosted AI in Moodle require one GPU per plugin?
No. In the reference project, local AI services and Moodle plugins share one GPU. GPUQ, the job queue we developed, provides both a queue and status information while distributing GPU access fairly. Coursebot, feedback, image and speech functions consequently use the same GPU infrastructure without dedicated hardware for every plugin.
What does Ollama do behind Moodle?
Ollama runs local language models for chat and text tasks. The mosKI coursebot uses it for chat, Bild-OCR uses Ollama Vision, and the oral examination simulation uses Ollama. Debatten-Dojo, PuG-Lernreise and the PuG AI assistant also use Ollama for their respective confirmed local AI functions.
How does Debatten-Dojo support spoken debates?
Debatten-Dojo combines Ollama with Whisper. Whisper provides speech recognition in the local architecture, enabling the Moodle activity to process spoken debates. Ollama and Whisper speech recognition are used locally on the school server. Student data stays on that server, and this function does not require a US cloud AI service.
Does student data leave the server for AI processing?
No. Student data stays on the school server in the architecture described here. Ollama processes chat, text and vision tasks locally, Speaches provides local speech functions, and GPUQ coordinates GPU jobs. The school does not need to transmit data to a US cloud AI service for these Moodle features.
Can GPUQ be used outside Moodle?
Yes. GPUQ also runs on Panomity’s server for the CMS4VR virtual tour platform. The queue is used there behind the self-hosted infrastructure of the AI concierge. CMS4VR uses a self-hosted concierge with Ollama and Whisper speech recognition. GPUQ is therefore confirmed in both Moodle and virtual reality contexts.
Conclusion: AI in Moodle, developed and hosted together
This architecture connects Moodle plugins to Ollama, Speaches, Whisper and GPUQ on the school server. One GPU is shared fairly among AI services and plugins, while GPUQ provides both a queue and status information. Coursebot, Bild-OCR, examination simulation, spoken debates and local learning-journey feedback use this common technical foundation.
Panomity develops and hosts EdTech as one connected service: Moodle, custom plugins and the AI infrastructure behind them. If you are planning a self-hosted architecture for your learning platform, explore our hosting and IT infrastructure services from Munich.
0 Comments