Feasibility, evidence and advantages of the cloud compute tier — EU regions, redacted-only inference, and burst capacity.
Riotouch Cloud · Deployment series, part 2 of 4. Series: 1 On-Premise Compute · 2 Cloud Compute · 3 Cloud Services · 4 Applications.
Quick answer. The Riotouch cloud compute tier is the same platform as part 1, hosted in an EU region: cloud AI inference through Azure OpenAI (EU), Mistral AI (France) and AWS Bedrock (EU), with SOC 2 and GDPR agreements signed, the EU Data Boundary enforced, and usage metered per request. It exists for three jobs — supplementing a local model when a task is beyond it, absorbing elastic peaks (exam season, enrolment drives) without buying GPUs for the worst week of the year, and serving schools that have no server room or IT team at all. The feasibility argument is the strongest one available, because hyperscale AI infrastructure is the most heavily benchmarked computing system in the industry; this article cites that record and then states plainly what it buys — and costs. Compare it with the other two modes in the Riotouch Cloud Solution overview.
| Component | What it provides | Notes |
|---|---|---|
| Cloud AI Engine | Advanced reasoning, creative generation and multimodal tasks beyond local capacity | Azure OpenAI (EU region), Mistral AI (France), AWS Bedrock (EU region) |
| Compliance posture | SOC 2 and GDPR agreements signed; EU Data Boundary enforced; per-request metering | Redacted data only — the AI Gateway decides what may leave |
| Model pool | 40+ model families (compatible models, model pool, domestic/China models) | Swappable without client changes |
| Burst capacity | Extra GPU capacity during peaks, released afterwards | The economic reason clouds exist |
| Regional hosting | EU-region reference layout | Data-residency options per school |
The cloud tier never handles raw student data. Every request passes the AI Gateway (smart routing, PII redaction, audit logging, degradation, token metering) before it goes out — which is why the cloud tier is compatible with the on-premise tier rather than a replacement for it.
The claims a school actually needs validated are narrow: (a) can AI inference and training run at arbitrary scale in a cloud, and (b) does elasticity deliver economic value rather than just technical elegance. Both have public evidence.
Scale is a benchmarked fact, not a marketing line. Microsoft's own engineering report on MLPerf 3.1 Training results presents Azure's cloud supercomputing infrastructure setting a scale record in large language model training, the same infrastructure that powers Microsoft Copilot, Bing and Azure OpenAI Service [1]. Azure's elastic GPU families are offered "in sizes ranging from eight to thousands of NVIDIA H100 GPUs interconnected by NVIDIA Quantum-2 InfiniBand" [2][3] — the mechanism that lets a deployment add capacity for a two-week exam period and give it back.
Google's AI-optimised cloud is a documented product line. Google Cloud TPU and the AI Hypercomputer stack are published, supported services for training and serving large models, with reference samples for distributed training of models such as Llama 3-8B across hosts [4][5]. The research community has also demonstrated the outer edge of cloud scale: MegaScale-trained models on more than 10,000 GPUs, presented at USENIX NSDI [6], and Berkeley's Sky Computing agenda formalises the idea that cloud capacity should be fungible across providers [7].
Elasticity is the definitional property of cloud, not an add-on. NIST's canonical cloud definition lists rapid elasticity and measured service as essential characteristics, and the AI-native reframing of cloud computing in 2024 keeps elasticity at the centre of the architecture for generative workloads [8][9]. In practice this is what lets a school pay for 1,000 students' worth of inference on 51 weeks and 1,000 students plus a district-wide exam week in the 52nd.
Cost is real and now studied. Peer-reviewed analysis of LLM environmental and operational cost makes the trade-offs explicit: model size, hardware generation and utilisation dominate the bill [10]. Riotouch's answer is architectural rather than aspirational — route only what needs the big model, redact first, and meter every request so the school can see the split between local and cloud work.
| Advantage | What it means in a school | Supporting evidence |
|---|---|---|
| No capacity ceiling | Tasks beyond the local model (heavy reasoning, large multimodal jobs, creative generation) still complete — one step up, not a dead end | Azure AI infrastructure scales from 8 to thousands of H100 GPUs [2][3]; Google AI Hypercomputer / Cloud TPU for large-model serving [4][5] |
| Peak handling without peak capex | Exam weeks, enrolment drives and district events use burst capacity that is released afterwards | Rapid elasticity and measured service are definitional cloud characteristics [8][9] |
| Faster access to newer models | New frontier models arrive without a hardware refresh | Hyperscaler model portfolios and reference stacks are continuously updated [4][1] |
| EU data residency available | Schools with European data-protection obligations can keep processing inside the EU, with the EU Data Boundary enforced | Azure OpenAI / Bedrock EU regions and EU Data Boundary as documented controls [1][2] |
| Zero on-site infrastructure | Schools with no server room and no IT team can still run the platform | This is also the cloud tier’s role in hybrid (part 1 vs part 3), plus documented large-scale device management (Microsoft Intune for Education, part 3 ref) |
| Cost transparency | Per-request metering, plus a local/cloud split that shows what on-premise would have absorbed | Metering is a first-class gateway function; LLM cost drivers are analysed in the literature [10] |
| Situation | Recommendation |
|---|---|
| Reliable internet, no server room, small or no IT team | Cloud tier as the primary compute tier |
| Exam-season and enrolment peaks, local baseline already in place | Cloud burst on top of Plan A1/A2 (hybrid) |
| Tasks beyond the local model’s capacity | Route redacted requests to the cloud tier via the AI Gateway |
| Data-protection rules require EU processing | EU-region hosting with the EU Data Boundary enforced |
Pair the cloud tier with the display and local layers it serves: the interactive flat panel in the classroom, an RK3588 smart board or OPS module for panel-side compute, and the Aether Orb Edge AI Box for classroom-level offload when the local model is sufficient. Full interface and power numbers are published on the product specifications page.
Next in the series: part 3 covers the cloud services layer — device management, content management, resource management, teaching management, live streaming, the AI-Gen platform and PWA — and the evidence behind running them centrally for a whole fleet.
All links verified live on 2026-10-10. Deployment specifications in section 1 are Riotouch's published configurations and are subject to change with hardware generations.
Riotouch Cloud Solution — one platform, three deployment modes for interactive flat panels. Hardware: RK3588 Smart Board · OPS modules · Aether Orb Edge AI Box.
Tell us what you're looking for and we'll tailor a quote to your requirements — with pricing, lead time, and expert advice.