From the Research Universities edition of September 25, 2026
Berkeley Lab ScienceIT launches Berkelium: Kubernetes platform for containers, AI model serving, and reproducible scientific services
Lawrence Berkeley National Laboratory (ScienceIT) · National laboratory research computing · United States (Berkeley, CA)
- Publisher
- Berkeley Lab IT / ScienceIT
- Original publication
- September 25, 2026
- Source retrieved
- 2026-09-26
- Event date
- 2026-09-25
What happened
On 25 Sep 2026 ScienceIT announced Berkelium, a new Kubernetes cluster for building, testing, automating, and sharing scientific work. It complements traditional HPC (Lawrencium) for interactive apps, automated workflows, persistent services, and containerized environments that support reproducibility. Documented use cases include AI training and model serving (CBorg already runs services on Berkelium), automated instrument-to-workflow data pipelines, and browser-shared results. Training is scheduled 15 Oct 2026.
Why it matters
University and lab research computing teams adopting AI agents need a service/Kubernetes tier beside batch HPC so model endpoints, persistent workflows, and containerized reproducibility are first-class—not bolted onto Slurm alone.
Evidence and measured results
ScienceIT announcement page dated September 25, 2026 opened via HTTPS; complementarity to Lawrencium, container reproducibility language, and CBorg-on-Berkelium stated in body.
Limitations and uncertainty
Announcement/launch article without measured throughput or failure rates; hardware counts on related portal pages not used as primary evidence here; training still upcoming.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-09-26; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Modern science needs persistent AI services and containerized workflows that traditional batch HPC queues handle poorly.
- Stakeholders
- ScienceIT/research computing
- Lab CIO
- AI platform owners (e.g., internal LLM services)
- Instrument facility leads
- Reproducibility/compliance staff
- Discovery questions
- Which services need 24/7 endpoints vs batch jobs?
- Where do instrument pipelines break today?
- What identity and quota model exists?
- Who owns model-serving SLOs?
- Value hypothesis
- A Kubernetes science platform beside HPC can host AI model serving and automated pipelines with container-level reproducibility, if access and training are funded.
- Potential engagement
- Pilot migration of one internal AI service and one instrument pipeline onto a research Kubernetes cluster with training.
- Unsupported claims
- Replaces Lawrencium-class HPC
- Measured discovery speedup
- Guaranteed multi-lab portability
- Fully specified security accreditation
Pre-sales engineering
Role takeaway
- Fit
- Kubernetes research cluster for containers, persistent services, AI training/serving, and instrument pipelines complementary to batch HPC.
- Architecture and integration
- Connect identity (OneID-class), GPU operators, registries, storage classes, and ingress for model endpoints; keep heavy MPI on HPC.
- Prerequisites
- GPU node pool
- Institutional auth
- Container registry
- Storage classes
- Ops on-call for persistent services
- Constraints
- Launch announcement without capacity KPIs
- Training still scheduled
- Single-lab context
- Security model not fully public
- Security
- Enforce namespace isolation, secret management, egress controls for model APIs, and data classification for instrument feeds.
- Proof of value
- Service uptime for AI endpoints
- Successful container reuse across users
- Pipeline latency from instrument to store
- User completion of onboarding training
Delivery
Role takeaway
- Work
- Launch cluster access, publish HPC-vs-K8s guidance, run training, migrate pilot services.
- Dependencies
- Identity provider
- GPU capacity
- Facility networking
- Service owners for CBorg-like apps
- Training staff
- Ownership
- ScienceIT owns platform; service owners own app SLOs; facilities own instrument data feeds.
- Skills and adoption
- Teach researchers container packaging and when to use Kubernetes vs batch HPC; train ops on GPU serving.
- Governance checkpoints
- Access policy
- Data egress review for model APIs
- Pilot go-live review
- Acceptance criteria
- Onboarding path live
- At least one AI serving or pipeline pilot in production
- Documented placement rules
- Risks
- Researchers misuse K8s as unmanaged VMs
- GPU contention with batch AI
- Credential sprawl on persistent services
- Overpromise reproducibility without image provenance
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Two-tier research platform: Lawrencium-class batch HPC for heavy simulation plus Kubernetes (Berkelium) for containers, persistent services, AI endpoints, and instrument pipelines.
Governance
Who approves, reviews and stays accountable for outcomes?
Launching a shared Kubernetes science platform implies access control, OneID-style auth, and training before researchers treat persistent AI services as production.
Security and privacy
What data, permissions and controls need testing?
Persistent model-serving and instrument pipelines raise credential, data-egress, and multi-tenant isolation requirements beyond batch job sandboxes; announcement does not publish a full security model.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
October training and container self-service can widen who can run modern AI/service workloads; skill barrier shifts from cluster modules to container literacy.
Procurement
What should contracts, pricing and exit terms secure?
Budget Kubernetes ops, GPU serving, and training alongside HPC refresh—not only more batch nodes.
Operating model
Which teams own the service once it runs?
Explicit two-tier operating model (batch HPC + Kubernetes science platform) with ScienceIT ownership of the service tier.
Publication history
- 2026-09-25Research Universities · Issue 194 resources
Stable resource ID: lbl-berkelium-kubernetes-science-platform-20260925