OW
Featured · Tool
Open WebUI
ChatGPT-style UI on your hosted models, one-click on RHOAI, backed by api.grn.cloud.
Red Hat OpenShift AI · built in Europe
Serve models and agents on GPUs you can point at.
Red Hat OpenShift AI running on GRN.CLOUD bare-metal GPUs in the EU. Deploy
models, agents and one-click apps from a catalogue, behind an OpenAI-compatible endpoint at
api.grn.cloud. Weights, prompts and outputs stay inside the cluster — no
hyperscaler hop, no surprise egress.
- OpenAI-compatible API
- vLLM / SGLang on bare metal
- Multi-tenant by project
- 100% renewable power
Size your GPUs with the capacity calculator below, then ask for a quote.
Overview
One platform for every model you run.
The GRN.CLOUD AI / ML platform is the full Red Hat OpenShift AI distribution — projects, model serving, workbenches, pipelines and a deployment catalogue — running on GRN.CLOUD bare-metal GPUs in the Netherlands. It is not a thin dashboard bolted onto someone else's cluster.
The problem it solves. Standing up production inference means assembling a serving runtime, GPU scheduling, a model cache, an API gateway with keys and budgets, tenancy boundaries and an audit trail — and then operating all of it. Buying that from a US hyperscaler solves the operations problem and creates a data-residency one.
Typical workloads. Multi-tenant LLM inference, retrieval-augmented chat, coding assistants, hosted and swarm agents, GPU notebooks, evaluation and labelling, and repeatable training or evaluation pipelines.
Who should use it. Teams that need open-weight models served on dedicated GPUs under EU jurisdiction, MSPs reselling AI products to their own customers, and platform teams that want OpenShift AI without operating the GPU estate.
bash — OpenAI-compatible
$ curl https://api.grn.cloud/v1/chat/completions \ -H "Authorization: Bearer $GRN_API_KEY" \ -d '{"model":"qwen2.5-7b", "messages":[{"role":"user", "content":"ping"}]}' # the key is a Bifrost virtual key: rate limit # and spend cap are enforced at the gateway, # before the request reaches a GPU
What GRN operates
Run and on-call for the AI platform — the undifferentiated heavy lifting.
- Red Hat OpenShift AI, KServe and the GPU Operator on a managed HA cluster
- The bare-metal GPU hosts, drivers, hardware profiles and node pools
- The Bifrost gateway: virtual keys, rate limits, spend budgets and multi-tier failover
- The shared Ceph model cache, so weights download once and redeploy fast
- Runtimes, hardware profiles and catalogues, managed in Git and reviewable
What you operate
Your models, agents and applications — inside your own project boundary.
- Which models you deploy, and any open-weight model you bring in Hugging Face format
- Your prompts, retrieval corpora, evaluation sets and fine-tune data
- Your agents, tools and the MCP endpoints they are allowed to call
- Per-tenant keys, budgets and the ceiling you set on each of them
- Your notebooks and pipelines, and when a notebook becomes a scheduled job
Multi-tenant by project. Each customer lands in their own OpenShift AI project with a serving runtime and a GPU slice. Deployments, notebooks and keys stay invisible to other tenants — you share the platform, not each other's work.
Key features
Catalogue to endpoint, in one flow.
Catalogue → deploy in one flow
Pick a model from the catalogue, or bring your own weights. Choose a hardware profile, deploy, and you get an OpenAI-compatible URL behind api.grn.cloud. No YAML hunt, no cluster ticket for a first endpoint.
vLLM / SGLang on bare-metal GPUs
Production serving on dedicated GPUs, not a shared cloud lottery. Model weights cache once on shared storage so the next deploy is fast, and the path from a small proof-of-concept fleet to larger cards is the same.
Multi-tenant by project
Each tenant gets its own OpenShift AI project with a serving runtime and a GPU slice. Deployments, notebooks and keys are scoped to that project and invisible to the others.
One front door: Bifrost
Every call goes through the Bifrost gateway first. Each tenant gets its own virtual keys, rate limits and spend budgets, so cost control happens at the door — before a request burns GPU time.
Workbenches on the serving cluster
One-click GPU Jupyter with CUDA and PyTorch ready, on the same cluster and the same shared weight cache as your inference. No download-to-laptop loop, no shipping data out of the EU to try a fine-tune.
GitOps-managed
Runtimes, hardware profiles and catalogues live in Git. Changes are reviewable, rollbacks are boring, and audits get a paper trail instead of a mystery dashboard click.
Platform capabilities
The OpenShift AI capabilities powering inference, agents and training.
Inference
Serving runtimes
vLLM is the default high-throughput, OpenAI-compatible path; SGLang is available for structured generation, and TensorRT-LLM for optimised engines on supported NVIDIA GPUs.
Multi-tier failover
Traffic prefers OpenShift AI, then the vLLM fleet, then a break-glass path if something fails. Failover is automatic, so you keep a working endpoint without rewriting clients mid-incident.
Shared model cache
Weights land once on Ceph-backed shared storage and stay private to your tenant project — so the second deployment of a model is fast, and there is no repeated public download.
Agents
Hosted agent products
A coding assistant and chat/RAG ship as ready products on agents.grn.cloud. Your team uses them like a SaaS tool, while the work runs on your own GPUs inside the EU cluster.
kagenti + agent swarm
Run a single agent on the platform, or spin up a swarm in an isolated sandbox. Both call your hosted models on api.grn.cloud and tools on the MCP gateway — same budgets, same keys, same cluster.
Budgets at the door
Every agent run needs a Bifrost virtual key. Rate limits and spend caps apply before a request touches a GPU — you set the ceiling once and the gateway enforces it on every call.
Workbenches & training
One-click GPU Jupyter
Open a notebook with CUDA and PyTorch already set up. It behaves like a familiar lab notebook, but it sits on OpenShift AI with a real GPU attached to your project.
Pipelines when you outgrow the notebook
When a one-off notebook becomes a weekly job, move it into Kubeflow pipelines — same project boundary, same GPUs, repeatable runs you can review in Git.
Hardware profiles that match production
Pick 1, 2 or 4 GPU stamps for the workbench. Those are the same profiles used for inference, so what you measure in the notebook is close to what you ship.
Governance
EU sovereign by default
Weights, prompts and outputs stay in the EU cluster on renewable-powered bare metal. No region roulette. Third-party model APIs come into play only if you bring your own key on purpose.
Per-tenant keys and quotas
Virtual keys, rate limits and spend budgets are issued per tenant and enforced at the gateway, with per-key cost tracking — so one team's experiment cannot consume another's capacity or budget.
Reviewable change history
Runtimes, hardware profiles and catalogue entries are declarative and version-controlled, so every platform change has an author, a review and a rollback.
Deployment lifecycle
Pick
Choose a model, tool or agent from the catalogue — or bring your own weights
Profile
Select a hardware profile: 1, 2 or 4 GPU stamps on bare metal
Deploy
KServe brings it up behind an OpenAI-compatible URL on api.grn.cloud
Govern
Issue a Bifrost virtual key with its rate limit and spend cap
Scale
Add replicas or move to a larger profile; failover keeps the endpoint up
One-click apps
Tools, runtimes, models and agents from the OpenShift AI Explore catalogue, running on GRN.CLOUD bare metal. Pick what you need, choose a GPU profile, and go live. Data stays in the EU cluster.
Featured · Tool
n8n
Workflow automation with LLM nodes, connect agents, APIs, and tools without leaving the cluster.
Talk to deploy
Featured · Runtime
Ollama
Local-style model runner on GPU workbenches, pull, chat, and prototype fast.
Talk to deployQw
Featured · Model
Qwen2.5-7B Instruct
Deploy with vLLM on RHOAI, multi-tenant serving, OpenAI-compatible API via Bifrost.
Talk to deployDS
Featured · Model
DeepSeek-R1 / V3
Reasoning and MoE-class models on multi-GPU profiles, same catalog → deploy flow.
Talk to deployka
Featured · Agent
Coding assistant
Browser IDE + terminal per tenant, workspace storage, hosted GRN model or bring-your-own key.
Talk to deploySw
Featured · Agent
Agent swarm sandbox
Multi-agent swarms in isolated sandboxes on the platform.
Talk to deployCl
Tool
OpenClaw
One-click agent / claw-style tooling on the platform, deploy from Explore.
Talk to deployPc
Tool
Paperclip
Lightweight attach-and-run utility in the one-click catalogue.
Talk to deployLS
Tool
Label Studio
Data labeling for fine-tunes and eval sets, next to your workbenches.
Talk to deployOC
Tool
OpenCode
Open coding environment on GPU, pair with the coding assistant agent.
Talk to deploy
Tool
LangServe
Serve LangChain apps as APIs on the cluster, same GPU backplane as inference.
Talk to deploy
Tool
Jupyter
Classic notebooks inside OpenShift AI workbenches, CUDA and PyTorch ready.
Talk to deployvL
Runtime
vLLM
High-throughput OpenAI-compatible serving, default path on RHOAI and the vLLM fleet.
Talk to deploySG
Runtime
SGLang
Fast structured generation runtime, alternate serving path next to vLLM.
Talk to deploy
Runtime
TensorRT-LLM
NVIDIA TensorRT-LLM optimized engines for max tok/s on supported GPUs.
Talk to deployUn
Runtime
Unsloth
Fast fine-tune / LoRA tooling on workbench GPUs, when fine-tuning leaves “Soon”.
Talk to deployQw
Model
Qwen2.5 family
0.5B → 32B Instruct, routing, chat, and long-context workloads on GRN profiles.
Talk to deploy
Model
Mistral
Mistral Small / Large and Mixtral-class MoE, deploy via the same catalog flow.
Talk to deployDS
Model
DeepSeek
DeepSeek-V3 and R1 reasoning models, multi-GPU TP on bare metal.
Talk to deployKi
Model
Kimi (Moonshot)
Long-context Kimi models for document-heavy and agent workloads.
Talk to deployGL
Model
GLM
Zhipu GLM-4 family, chat and tool-calling on GRN hardware profiles.
Talk to deployPhi
Model
Phi-3 / Phi-4
Compact Microsoft Phi models, strong quality at small VRAM for edge of fleet.
Talk to deploy
Model
Llama 3.1
8B and 70B Instruct with vLLM / SGLang on a GRN hardware profile.
Talk to deploykg
Agent
kagenti hosted agent
Deploy on agents.grn.cloud, calls api.grn.cloud + MCP tools.
MCP
Agent
MCP tool gateway
Kuadrant-backed tools, browser, crawl, Kubernetes, for agent workflows.
Talk to deploy
Workbench
OpenShift AI workbench
Project-scoped GPU notebook, invisible to other tenants.
Talk to deploy
Workbench
Kubeflow + MLflow
Pipelines and experiments, from notebook to repeatable training / eval.
Talk to deployAPI
Platform
Inference API
api.grn.cloud, OpenAI-compatible /v1 via Bifrost → vLLM / SGLang.
Bi
Platform
Bifrost gateway
Per-tenant virtual keys, rate limits, budgets, and multi-tier failover.
Talk to deployLL
Platform
LiteLLM
Unified LLM proxy, one OpenAI-style API over all hosted models with per-key cost tracking.
Talk to deployPlatform
RHOAI (OpenShift AI)
The full Red Hat OpenShift AI platform, catalog, model serving, pipelines, and workbenches per tenant.
Talk to deployBenefits
The operational and commercial differences you can verify.
Sovereign & secure
EU-owned infrastructure under Dutch jurisdiction — not a US hyperscaler's "European region", which stays subject to the US Cloud Act regardless of where the weights sit. Model weights, prompts and outputs stay inside the EU cluster, with a signed DPA.
Predictable GPU economics
Pricing is per GPU profile, not per token on the hosted path, and there is no per-GB egress metering. Size the config with the calculator below and the quote follows the hardware, not a usage lottery.
Sustainable
Hosted in the Netherlands on 100% renewable solar energy, with server heat reused to warm nearby buildings and peak-shaving to ease grid congestion. The calculator also shows an indicative power draw for the configuration you pick.
Open weights, open runtimes
Bring any open-weights model in Hugging Face format and serve it with vLLM or SGLang. The API is OpenAI-compatible, so clients written against it port elsewhere — there is no proprietary model format in the path.
Dedicated, not shared, silicon
Serving runs on bare-metal GPUs in your project's hardware profile, so throughput is a property of the card you chose rather than of who else is on the host that hour.
The full platform, not a wrapper
Projects, serving, workbenches, pipelines, catalogue and guardrails are the complete Red Hat OpenShift AI distribution — the same product your platform team can audit, on hardware we operate.
Architecture
Same platform, from silicon to click.
Read it top-down: the apps and agents people open, then the gateway that governs every call, then serving and training, then the platform and the GPUs underneath.
Apps & agents
Open WebUI · n8n · Label Studio · OpenCode · kagenti · swarmsYou operate
One-click applications and agent products from the catalogue, plus your own. Single agents run on the platform; swarms run in isolated sandboxes on the same GPUs and the same budgets.
Gateway & three doors in
Bifrost · api · agent · mcpGRN-managed
Three entry points: api.grn.cloud for chat and completions on your models, agents.grn.cloud for the agent platform and sandboxes, and mcp.grn.cloud for tools. Bifrost issues per-tenant virtual keys, enforces rate limits and spend budgets, and handles multi-tier failover.
Serve & train
vLLM · SGLang · TensorRT-LLM · Ollama · Jupyter · Kubeflow · MLflowGRN-managed
KServe fronts the serving runtimes; workbenches and pipelines share the same project boundary, the same GPUs and the same Ceph-backed weight cache as inference.
Platform
Red Hat OpenShift AI · KServe · GPU OperatorGRN-managed
The full OpenShift AI distribution — projects, catalogue, model serving, pipelines and workbenches — on a managed HA OpenShift control plane, with runtimes and hardware profiles declared in Git.
Bare-metal GPUs
Netherlands · 100% renewableGRN-managed
Dedicated GPU hosts on EU-owned bare metal in the Netherlands, powered by 100% renewable solar with server-heat reuse. Storage and networking come from the same platform that runs the rest of GRN.CLOUD.
Everything orbits grn.cloud — OpenShift AI and Bifrost are the control plane, not a bolted-on AI add-on.
Common use cases
What teams run on it.
Multi-tenant LLM inference
Serve open-weight models to several internal teams or external customers from one platform, each in its own project with its own keys, budgets and GPU slice.
Retrieval-augmented chat
Chat over your own documents with Open WebUI in front and your corpus inside the cluster — the retrieval data never leaves EU jurisdiction.
Coding assistants
A browser IDE and terminal per tenant with workspace storage, backed by a hosted GRN model or your own key — source code stays on the cluster.
Agents & agent swarms
Hosted single agents on the platform, or multi-agent swarms in isolated sandboxes, calling your models and the MCP tool gateway under one budget ceiling.
GPU notebooks & evaluation
Project-scoped Jupyter workbenches with CUDA and PyTorch for experimentation, evaluation runs and labelling next to the models you serve.
MSP AI products
Resell chat, coding assistance and inference APIs to your own customers as products, on hardware you control, with per-tenant cost tracking on the invoice.
Technical highlights
The detail an ML platform engineer actually evaluates.
| AI platform | Red Hat OpenShift AI (RHOAI) on managed OKD/OpenShift |
| Model serving | KServe with vLLM (default), SGLang, TensorRT-LLM Confirm per GPU |
| API surface | OpenAI-compatible /v1 at api.grn.cloud, via Bifrost |
| Gateway | Bifrost — per-tenant virtual keys, rate limits, spend budgets, multi-tier failover; LiteLLM for unified proxying and per-key cost tracking |
| Agent surfaces | agents.grn.cloud (kagenti + swarm sandboxes) · mcp.grn.cloud (Kuadrant-backed MCP tool gateway) |
| Model formats | Open weights in Hugging Face format; bring your own |
| Model families available | Qwen 2.5 (0.5B–32B), Llama 3.1 (8B / 70B), DeepSeek V3 / R1, Mistral & Mixtral, Kimi, GLM-4, Phi-3 / Phi-4 |
| Workbenches | Project-scoped GPU Jupyter, CUDA + PyTorch preinstalled; Ollama for prototyping |
| Pipelines & tracking | Kubeflow pipelines + MLflow experiments |
| Fine-tuning | Unsloth / LoRA tooling on workbench GPUs Soon |
| Hardware profiles | 1, 2 or 4 GPU stamps; same profiles for workbench and serving |
| GPU hosts | Bare metal, dedicated per project slice Confirm models |
| Model cache | Shared Ceph-backed storage, private to the tenant project |
| Tenancy | One OpenShift AI project per tenant — deployments, notebooks and keys isolated |
| Configuration management | GitOps — runtimes, hardware profiles and catalogues declared in Git |
| Data residency | Weights, prompts and outputs remain in the EU cluster; no default cross-border copy |
| Region | Netherlands (EU), 100% renewable-powered |
Against the hyperscaler AI platforms
An objective comparison on axes you can check on a public product page. Subjective claims ("faster", "smarter") are left out, and model quality is not a platform property.
| Capability | GRN.CLOUD AI | US hyperscaler AI platforms | ||
|---|---|---|---|---|
| AWS Bedrock / SageMaker | Azure AI Foundry | Google Vertex AI | ||
| Genuine EU sovereignty (non-US-owned) | ✓ Netherlands | ✕ US-owned | ✕ US-owned | ✕ US-owned |
| US Cloud Act exposure | None | Subject to US law | Subject to US law | Subject to US law |
| Dedicated bare-metal GPUs | ✓ per project slice | ~ instance families | ~ instance families | ~ instance families |
| OpenAI-compatible endpoint | ✓ api.grn.cloud | ~ via adapters | ✓ | ~ via adapters |
| Bring your own open weights | ✓ Hugging Face format | ✓ | ✓ | ✓ |
| Open-source platform you can audit | ✓ OpenShift AI, vLLM, KServe | ✕ Proprietary | ✕ Proprietary | ✕ Proprietary |
| Egress metering | No per-GB egress tax | Per-GB | Per-GB | Per-GB |
| Pricing model | Per GPU profile | ~ per-token + instance | ~ per-token + instance | ~ per-token + instance |
| 100% renewable-powered | ✓ | ~ varies by region | ~ varies by region | ~ varies by region |
✓ yes · ~ partial · ✕ no. Compiled from public product & pricing pages, June 2026; vendor features change — verify before quoting.
Capacity tool
Size the GPUs before you buy.
Sketch model size, quantisation, concurrency and how many GPUs you need. Bring that sketch to an engineer and we turn it into a clear SKU quote.
Calculator
LLM inference: VRAM & performance
LLM Inference: VRAM & Performance Calculator
Hardware
Local rigTotal: 2 GPUs2TP × 1PP × 1DP
Performance & memory results
-
- of - GB VRAM
-
- Generation speed
- -
- Time to first token
- -
- Total throughput
- -
- Profile
- -
- Replicas
- -
- Est. GPU power
- -
- Indicative rental
- -
Memory allocation
Engineering estimate. Validate with a load test before purchase.
Engineering estimate. Validate with a load test before purchase.
FAQ
The questions an ML platform engineer actually asks.
What is the GRN.CLOUD AI / ML platform?
It is Red Hat OpenShift AI running on GRN.CLOUD bare-metal GPUs in the EU. You get model serving with vLLM or SGLang, GPU workbenches, agents and one-click apps. The front door is an OpenAI-compatible API. You do not have to build or operate the platform yourself.
Can I really deploy with one click?
Yes. Open the catalogue, pick a model, tool or agent, choose a hardware profile, and deploy. It comes up behind api.grn.cloud. Open WebUI, n8n, Ollama, Jupyter, LiteLLM, OpenShift AI itself, and popular open models like Qwen, Llama and DeepSeek are all in that flow.
Is my data sovereign?
Yes. Model weights, prompts and outputs stay inside the EU cluster. There is no hyperscaler region hop and no cross-border copy by default. Third-party model APIs only come into play if you bring your own key on purpose.
How is tenant isolation enforced?
Each tenant gets its own OpenShift AI project with its own serving runtime and GPU slice. Deployments, notebooks and keys are scoped to that project and invisible to other tenants, and Bifrost issues per-tenant virtual keys with their own rate limits and budgets.
Can I bring my own model?
Yes. Bring any open-weights model in Hugging Face format and serve it with vLLM or SGLang on your GPU slice. Weights cache once on shared storage and stay private to your tenant project.
What happens if a serving path fails?
Traffic prefers OpenShift AI, then the vLLM fleet, then a break-glass path. Failover is automatic at the gateway, so clients keep a working endpoint without being rewritten mid-incident.
How do I control spend?
Every call needs a Bifrost virtual key. Rate limits and spend caps are enforced at the gateway before a request touches a GPU, and LiteLLM tracks cost per key — so the ceiling is set once and applied on every call.
How is this sustainable?
GRN.CLOUD runs on 100% renewable energy in efficient EU data centres, with server heat reused. You still get real GPU capacity, and the calculator on this page shows an indicative power estimate for the configuration you pick.
How do I get pricing?
Use the VRAM calculator to size model, concurrency and GPU count, then talk to an engineer for a quote. Pricing is per GPU profile — no hidden egress games and no surprise per-token markup on the hosted path.
Sell sovereignty, not just GPUs.
Chat, coding assistants, notebooks and an inference API on EU bare metal with renewable power. Tell us the model and your peak concurrency, and we come back with a clear SKU quote.
100% renewable energy · EU data residency · No US Cloud Act exposure · Open weights, open runtimes
Far far away, behind the word moun tains, far from the countries Vokalia and Consonantia, there live the blind texts. Separated they live in Bookmarksgrove right at the coast of
-
759 Pinewood Avenue
Marquette, Michigan -
info@domain.com
Online Support -
906-624-2565
Mon-Fri 8am-5pm
Switch The Language
Nederlands (Dutch)
English