Red Hat OpenShift AI Quickstarts — Independent Hands-On Review

A first-hand evaluation of three Red Hat OpenShift AI quickstarts from the rh-ai-quickstart family. Each was assessed by (a) a multi-agent static review of its repo, charts, docs, datasets, and upstream fidelity, and (b) live deployment onto a real OpenShift cluster built from a blank AWS account (OpenShift 4.19.24 + RHOAI 3.4.1 + NVIDIA GPU Operator), driving the platform to live inference.

Goal: answer, for each — is it as simple as it looks? what are the pitfalls? pros/cons? can a company actually adopt it? — and compare the family.

---

The three quickstarts

#	Quickstart	What it is	GPU?	Runnable by a typical user?	Polish
1	aml-rag-nvidia	RAG app for anti-money-laundering investigations	On-cluster, scarce Ada/Hopper + MIG	❌ No	2–3/5
2	maas-code-assistant	Self-hosted Models-as-a-Service code assistant (IDE)	On-cluster, 2× ≥48 GB Ada/Hopper	❌ No	3/5
3	rh-research	NVIDIA AI-Q deep-research agent	None (NVIDIA cloud, default)	✅ Yes (cloud path) — proven live	4/5

➡️ Full cross-comparison & family maturity verdict: COMPARISON.md

---

Headline findings

1. The underlying Red Hat AI platform works — demonstrated live. maas's gpt-oss-20b served + generated code on L40S (artifact); rh-research produced an accurate, cited research report via file-RAG on NVIDIA cloud (artifact); AML's 3 InferenceServices reached Ready + exposed the OpenAI routes on A100 (artifact; the inference responses were observed in-session, not archived). The quickstarts' problems are their assumptions/packaging, not the platform. (One live failure: maas's Mamba-hybrid MoE FP8 Nemotron failed vLLM engine-core init under a bare runtime — its tuned chart path was not tested.)
2. Zero of the three deliver the "quickstart" promise (clone → follow README → working demo) on a stock OpenShift trial cluster.
3. The FP8 / sm_89 trap is the single most important gotcha: the serving quickstarts use FP8/modelopt models that require Ada (L40S, sm_89) or Hopper (H100, sm_90) and silently fail on the common A100 (sm_80) — undocumented and unchecked. We confirmed both directions live (A100 hard-fails at the modelopt gate; L40S/sm_89 accepts the same FP8).
4. GPU capacity is a real barrier — on-demand multi-GPU instances were repeatedly unavailable across AZs over two days; Spot was SCP-blocked.
5. No NVIDIA-provided datasets in any of the three despite NVIDIA branding — all use public/synthetic data. NVIDIA provides models/APIs, not data.
6. Recurring anti-patterns: personal-account container registries (2/3), hardcoded secrets, invasive cluster mutations, doc-vs-config drift, and weak OpenShift-native ingress.

Family maturity: ~2.5/5 — strong platform, promising reference architectures, but the quickstart packaging is expert-level, not turn-key.

---

Repository contents

.
├── README.md                          # this file
├── COMPARISON.md                      # 3-way comparison + family maturity verdict
├── aml-rag-nvidia/
│   ├── REVIEW.md                      # full review: build, changes, outcomes, pros/cons
│   ├── static-review.md              # 15-agent static review (charts/docs/dataset/upstream)
│   └── build-log.md                  # chronological live-build log (29 first-hand findings)
├── maas-code-assistant/
│   └── REVIEW.md
└── rh-research/
    └── REVIEW.md

How it was tested

• Cluster: IPI-installed OpenShift 4.19.24 on AWS (single-AZ base + on-demand GPU MachineSet scaled 0↔1 for cost control), RHOAI 3.4.1, NVIDIA GPU Operator, KServe RawDeployment.
• GPUs exercised: NVIDIA A100 40 GB (p4d.24xlarge) and L40S 48 GB (g6e.12xlarge), after extensive capacity hunting across AZs.
• Cost discipline: GPU nodes live only during tests (~$33/hr) then scaled to 0; base cluster hibernated overnight.
• Credentials (AWS, NGC, HF, pull secret, kubeconfig) are never committed here — see .gitignore.

Evidence & integrity

This repo was adversarially self-reviewed (a red-team pass that tried to refute every claim against the source files, the captured command outputs, and the cluster). The corrections from that pass are applied. Evidence is now tagged by provenance so readers can weigh it:

• [artifact] — backed by a saved command/log output that can be re-checked.
• [observed in-session] — seen live in command output during testing but not archived to a file (so not independently reproducible here; e.g. some inference responses and a few vLLM startup logs from now-terminated GPU nodes).
• [inferred] — reasoned from code/CHANGELOG/spec, not directly executed.

Static/code-review findings (file:line) are kept distinct from live outcomes. Known limitation: a few headline live numbers and one failed-model root-cause log were observed in-session but not saved before the GPU nodes were torn down — these are labelled accordingly rather than presented as reproducible artifacts.

Independent review for evaluation purposes. Not affiliated with Red Hat or NVIDIA.