UMAMI makes learning AI an infrastructure issue
In August 2026, Egypt-based UMAMI E-Learning Solutions launched its AI-powered Learning Operating System, or LOS, with an investment plan exceeding EGP 50 million, roughly $1 million, according to Wamda. UMAMI positioned LOS as intelligent learning infrastructure for governments, ministries and large institutions across MENA.
That matters to GPU operators because the buyer named in the announcement is not a single SaaS team running one model endpoint. It is the kind of institution that holds student records, assessments, teacher performance data, workforce training history, content libraries, speech and video submissions, and analytics that may fall under national data residency rules. In MENA, especially for government-linked education and workforce programmes, the default question is not only whether the model works. It is where the data sits, who can administer the platform, how tenants are separated, and whether utilisation can support the business case.
For a quarter rack to a few racks of GPUs, LOS-like platforms create a very practical bottleneck: many sensitive tenants want the same constrained hardware at uneven times. One ministry wants inference for a national learning assistant. A university wants a private fine-tuning window. A training authority wants exam-week capacity. A content team wants video transcription, embeddings and search indexing overnight. The operator cannot solve that with a spreadsheet and a few hand-built servers. The estate needs tenancy, GPU partitioning, storage isolation, policy and metering from the first deployment.
ClastIQ is built for this class of estate: real hardware owned by an operator, not an abstract cloud region. It combines bare-metal provisioning through MAAS and Juju, Kubernetes and VM tenancy on the same fleet, GPU partitioning by MIG where available and time-slicing where appropriate, Ceph storage, per-tenant metering and chargeback, quotas, policy engineering, air-gap options and local support. The goal is not to copy a hyperscaler interface. It is to make a small or mid-size sovereign GPU estate governable enough to sell and operate.
The bottleneck is not only model serving
Education AI platforms are mixed workload systems. A typical LOS-style stack may include:
- real-time inference for tutors, lesson assistants and administrative copilots;
- batch inference for grading, summarisation and curriculum analytics;
- vector databases and embedding pipelines;
- speech-to-text or video analysis for recorded lessons;
- fine-tuning or adapter training for local curricula and language variants;
- relational databases, object storage and backup stores;
- integration services for identity, student information systems and payment or procurement workflows.
The GPU estate will feel the problem in three places.
First, GPU demand is bursty. Daytime inference has latency targets. Night-time indexing can tolerate queues. Fine-tuning jobs can consume whole GPUs for hours. Exam periods or national training cohorts can double demand for a few weeks. If everything is deployed as one shared cluster with weak limits, the noisiest workload wins.
Second, the data classes differ. A public content recommendation job should not share the same administrative boundary as identifiable student records or ministry workforce data. Even if all tenants are inside the same country, the operator still needs hard operational separation: namespaces, storage pools, network policy, identity boundaries, audit trails and administrator controls.
Third, small estates cannot afford idle isolation. Giving each tenant a dedicated GPU node may be politically simple, but it wastes capital and power. A few racks must run like a pooled utility while still proving that tenants are separated and billed correctly.
That is the design space for ClastIQ: one physical fleet, multiple controlled consumption models.
What an operator-grade layout looks like
A practical MENA learning infrastructure deployment should start by separating control planes, tenant planes and storage classes. On a small estate, the same hardware pool may support both Kubernetes and VMs, but the operator should not blur operational responsibilities.
| Layer | Operator decision | Why it matters for LOS workloads |
|---|---|---|
| Bare metal | Provision and rebuild nodes consistently | Keeps GPU, CPU and storage nodes reproducible across sites |
| Tenancy | Use namespaces, projects and VM boundaries | Separates ministries, universities, vendors and internal teams |
| GPU sharing | Apply MIG, time-slicing or whole-GPU allocation | Matches small inference, batch jobs and training windows to the right slice |
| Storage | Use Ceph pools and access policy | Keeps records, models, embeddings and backups inside approved boundaries |
| Metering | Record GPU-hours, CPU, RAM, storage and network | Enables chargeback and prevents political allocation by anecdote |
| Quotas | Enforce per-tenant limits and priorities | Stops one programme from starving another during peak periods |
For NVIDIA estates, MIG can split supported GPUs into hardware-isolated instances suitable for smaller inference services. For AMD or mixed GPU fleets, the same operating principle still applies: classify workloads, schedule them onto compatible devices, and use time-slicing or whole-device allocation where hardware partitioning is not available. Hardware-agnostic does not mean pretending every accelerator behaves identically. It means the platform exposes a common operating model while respecting the actual device capabilities.
VM tenancy remains important. Some institutions will bring legacy applications, vendor appliances, Windows-based tools, or regulated database patterns that do not fit cleanly into Kubernetes on day one. Others will need Kubernetes-native model serving and data pipelines. Running both on the same fleet is useful only if the operator can meter, quota and isolate both consumption paths.
ClastIQ’s role is to make that a managed substrate rather than a custom build for each tenant. MAAS and Juju handle repeatable provisioning and service composition. Kubernetes handles containerised workloads. VM tenancy supports workloads that need machine boundaries. Ceph provides storage that can be carved into pools and classes. Metering and policy connect the technical estate to the commercial model.
A worked example: 16 GPUs, one national learning platform
Consider an operator in the GCC or North Africa hosting a sovereign learning platform for three tenants: a ministry programme, a university consortium and a private training provider. The initial estate is modest: 16 GPUs in a few dense servers, with supporting CPU, memory, NVMe and Ceph storage.
Assume a 30-day month.
- Raw GPU capacity: 16 GPUs × 720 hours = 11,520 GPU-hours per month.
- Before orchestration, average useful utilisation is 28 percent because tenants reserve whole nodes, batch jobs wait for manual windows, and inference is overprovisioned.
- Useful GPU-hours at 28 percent: 11,520 × 0.28 = 3,226 GPU-hours.
- After partitioning, quotas and scheduled batch windows, useful utilisation rises to 62 percent.
- Useful GPU-hours at 62 percent: 11,520 × 0.62 = 7,142 GPU-hours.
Now add a simple cost model. The 16 GPUs draw 11.2 kW at 700 W each under load. CPUs, memory, storage and network add 8.8 kW, so the rack load is 20 kW. Over 30 days, that is 14,400 kWh of IT energy. With facility overhead at 1.35 PUE, billed energy is 19,440 kWh. At $0.10 per kWh, electricity is $1,944 per month. Add $12,000 per month for hardware amortisation, support, space, spares and operations. Total monthly cost is $13,944.
At 62 percent utilisation, cost per useful GPU-hour is:
$13,944 ÷ 7,142 = $1.95 per useful GPU-hour.
If the operator charges an internal or external blended rate of $3.20 per GPU-hour, monthly GPU revenue is:
7,142 × $3.20 = $22,854.
At the old 28 percent utilisation, revenue at the same rate would be:
3,226 × $3.20 = $10,323.
The difference is not a pricing trick. It is the result of selling the same electrical and capital envelope more effectively. The revenue per MW also changes. At 20 kW IT load, $22,854 per month equals $1.14 million per MW-month, or about $13.7 million per MW-year. At 28 percent utilisation, the same estate produces about $6.2 million per MW-year. For operators constrained by power allocation, transformer capacity or data hall space, utilisation is not a dashboard vanity metric. It is the business model.
This example intentionally excludes many real costs: financing, software subscriptions, remote hands, taxes, cross-connects and replacement reserves. Operators should add them. The point is that metering and allocation discipline can be the difference between an estate that funds expansion and one that becomes a subsidised lab.
How to express tenancy without handwork
A small GPU cloud often starts with informal allocation: this server belongs to the AI team, this one is for the university, this one is for demos. That breaks down as soon as sovereign education workloads arrive. Operators need a repeatable way to create a tenant, assign GPU shapes, attach storage, enforce quotas and produce a bill.
The actual command surface will differ by deployment, but the runbook should be this explicit:
# Create an isolated tenant boundary
kubectl create namespace tenant-ministry-los
# Apply a quota for CPU, memory and accelerator claims
kubectl apply -n tenant-ministry-los -f quota-ministry-los.yaml
# Label nodes that are approved for sensitive education workloads
kubectl label node gpu-node-07 data-class=education-sensitive
kubectl label node gpu-node-08 data-class=education-sensitive
# Confirm current GPU allocation before opening the tenant window
kubectl get pods -A -o wide | grep gpu
That is not enough by itself. The platform also needs admission controls, storage policies, node labels that cannot be casually changed by tenant admins, and audit logs. For air-gapped or sovereign deployments, the operator must also maintain a local image registry, package mirrors, model artifact repositories and an update process that does not depend on live internet access.
ClastIQ packages those concerns into the estate design. The operator can define a tenant profile for a ministry workload, another for a university research group, and another for a commercial training provider. Each profile should state allowed hardware, maximum GPU-hours per month, storage class, backup schedule, network egress rules, administrator role, and reporting format.
GPU partitioning decisions for LOS workloads
Not every LOS component deserves a whole GPU. Operators should map workload type to allocation mode.
Real-time chat or tutoring inference may run efficiently on a fraction of a supported GPU if the model size and latency target allow it. MIG, where available, is useful for this because it provides stronger hardware-level separation than simple process sharing. Smaller embedding jobs may also fit into slices.
Batch summarisation and content indexing can use time-sliced GPUs if throughput matters more than tail latency. These jobs can be scheduled overnight or during lower classroom usage. If the operator meters by actual GPU-time consumed and not merely by reservation, tenants have an incentive to batch efficiently.
Fine-tuning, speech models and video processing may need full GPUs or groups of GPUs, especially when memory capacity and interconnect topology matter. Those jobs should be booked into windows with preemption rules and clear quota impact.
The platform should expose these as products or classes, not as ad hoc technical exceptions. For example: inference-slice, batch-shared, full-gpu, and reserved-training. Each class maps to hardware capabilities, scheduling policy and price. A tenant should not need to know every node SKU. The operator, however, must know exactly which workloads can safely share a device.
Storage and data sovereignty are first-order issues
A learning platform is a data platform before it is an AI platform. Student records, transcripts, prompts, generated feedback, teacher notes, voice recordings and behavioural analytics may be more sensitive than the model weights. In GCC and MENA deployments, the expected posture for government and large institutions is often national hosting, controlled administration and clear data lifecycle management.
Ceph helps because it gives the operator a way to build software-defined storage across the same estate or adjacent storage nodes. The important part is not simply having a storage cluster. It is designing pools and policies around data classes.
A ministry tenant may need encrypted object storage for submissions, block volumes for databases, a separate pool for embeddings, immutable backups, and a retention schedule approved by the institution. A university tenant may need research workspaces with different retention and sharing rules. A commercial provider may need strict cost controls and faster deletion.
Operators should meter storage as carefully as GPUs: allocated capacity, consumed capacity, IOPS-heavy classes, backup copies and data transfer between zones or sites. Otherwise, GPU chargeback will look precise while storage becomes the hidden subsidy.
Power, cooling and quota policy belong in the same meeting
In a few-rack estate, power is not an abstract facilities number. If the site has 40 kW of usable IT load and 20 kW is already committed to one GPU pod, every tenant promise is a power promise. Operators should connect quota policy to power envelopes.
For example, a ministry may receive a monthly entitlement of 3,000 GPU-hours with a peak concurrency limit of eight GPUs. A university consortium may receive 2,000 GPU-hours but only four concurrent GPUs during weekday daytime. A training provider may buy lower-cost overnight batch capacity. These rules are business terms, but they must be enforced by the scheduler and reflected in metering.
This is where small estates can outperform their size. They can offer locally governed capacity, Arabic and regional language support patterns, on-prem installation, and direct operational accountability. But only if the fleet is not operated as a pile of special cases.
Where ClastIQ fits
ClastIQ is not tied to one accelerator vendor. It is intended for NVIDIA, AMD and mixed CPU/GPU estates, from a quarter rack to a few racks. For a UMAMI LOS-like deployment, the value is the operating model:
- provision bare metal consistently instead of hand-building nodes;
- run Kubernetes and VMs on the same physical fleet;
- partition or share GPUs according to workload and hardware capability;
- keep tenant data on operator-owned infrastructure inside the required jurisdiction;
- meter GPU-hours, CPU, memory, storage and tenant consumption;
- enforce quotas and policy before disputes reach the finance team;
- support air-gapped and sovereign deployments where internet dependency is not acceptable.
The operator still owns the hard decisions: site design, network routing, legal commitments, backup policy, incident response and pricing. ClastIQ gives those decisions a technical control plane and a support model that fits local hardware ownership.
UMAMI’s LOS announcement is one example, but the same pattern is visible across MENA software companies building AI into finance, health, tax and institutional workflows. As these systems move from pilots to national or enterprise infrastructure, regional GPU operators will be asked for more than raw cards. They will be asked for governed compute.
What to do this week
- Inventory your GPU estate by device type, memory size, partitioning capability, power draw and current tenant ownership. Do not plan quotas from purchase orders; plan from live hardware.
- Define three workload classes for learning AI: latency-sensitive inference, batch processing and full-GPU training or tuning. Assign each class a scheduling and metering rule.
- Build a tenant template covering namespace or VM boundary, Ceph pool, network policy, image source, administrator roles, quota and monthly report format.
- Run a 30-day utilisation model using your real power cost, facility overhead and amortisation. Calculate cost per useful GPU-hour at current utilisation and at a target utilisation.
- Test one sovereign operations path: local registry, offline update bundle, backup restore and audit log export without depending on public internet access.
- Convert one institutional requirement into a policy object, not a manual promise: data locality, maximum concurrency, backup retention or no-egress networking.
ClastIQ runs this model on the operator’s own hardware — request a demo.