AI infrastructure · Multi-tenant compute · Delivery
Closing the gap between AI ambition
and compute that actually runs.
After the strategy deck and the software licence, there is a stretch of road nobody owns. Wiring models, GPUs, quotas, invoices and on-call into one traceable chain — that is where AI value is actually decided. That stretch is our job.
01The problem
AI ambition is everywhere. Enterprise execution is not.
Taiwan's industry AI index jumped from 36.77 to 46.32 in a single year — up 26%. But what rose was usage, not operations. Only 6.6% of enterprises have actually wired AI into a core process.
6.6%
have integrated AI into a core process
The rest are still at tool trials and point solutions
61.8%
of AI usage happens outside organizational control
Shadow AI: no audit trail, no cost attribution
29.17
talent-strategy score — the lowest dimension
44.7% of firms have no AI training plan at all
Source: Artificial Intelligence Foundation (AIF), 2026 Taiwan Industry AI Adoption Survey
On the compute side, the problem is more concrete.
Buying GPUs is not the same as having compute. Who may use them, how much, how much did they use, who gets billed, and who responds when it breaks — if no system answers those five questions, the investment stalls in the machine room. The racks are powered, but nobody can say which department, which project, or which training run this month's cost belongs to.
02What we do
No one owns the last mile. We do.
AI programs rarely fail because the wrong model was chosen. They fail because between the diagnostic and the tooling, no one is accountable for making it run, making it add up, and making someone answer the pager.
Strategy firms
Give you a diagnostic, then exit
Roadmaps, maturity assessments, investment cases. The deck is good, but the deliverable stops at the document layer — and the delivery risk stays entirely with you.
Technology vendors
Give you tools, then exit
GPUs, clusters, model serving, monitoring dashboards. Each works on its own. Nobody is accountable for joining them into one operable, billable, auditable system.
Acumina Computing
Build it, all the way to production
Architecture modelling, systems integration, tenant isolation, compliance and audit, metering and billing, incident and on-call process, organizational change — pilot through to live operation, then handed back to your team.
We do not sell hardware and we do not resell cloud credits. What we deliver is a control plane you can operate yourself, plus the rules, documentation and team capability that keep it running.
03Use-case levels
Not every AI project deserves the same treatment.
We use three levels to align expectations, resources and timelines. A level is not about how capable the model is — it is about how many organizational boundaries the use case crosses. The more boundaries, the less the difficulty is technical.
Single workflow optimization
One department, one process, one clear metric. Results in 8–12 weeks, useful for building trust and an internal reference case. Low risk, but a low ceiling too.
Cross-functional process improvement
Spans two or more units and touches data ownership, accountability and KPI allocation. Moderate technical difficulty; the real work is governance and interface negotiation.
Enterprise-wide transformation
Shared compute platform, unified data and model governance, cost allocation. This level needs infrastructure first — otherwise every project rebuilds the same wheel.
04AI data center
The multi-tenant AI data center platform
The infrastructure L3 requires is exactly this. It is our core product line: a control plane that lets multiple tenants and multiple workload classes share the same GPUs, while guaranteeing isolation, quota, metering and auditability.
Core decision
The first deliverable is not "more backend services." It is a multi-tenant control plane where every role — platform admin, tenant admin, developer, NOC/SRE, finance and audit — can complete their own job. Backend engines are replaceable. The control plane must not be rebuilt.
Five execution layers
Every service runs on the same five-layer base. Each layer has its own duty, its own metrics, and its own invariant that must not be violated — measuring a layer with the wrong metric leads to confidently wrong conclusions.
L5 · Observability & AutoOps
- Duty
- Ingest SLIs and events, converge alerts, drive closed-loop automation and on-call
- Metrics
- Process metrics: MTTA/MTTR, alert noise ratio, automation success rate
- Invariant
- Every automated action records the full observe → decide → approve → act → verify chain, and is replayable
Seven deliverable service classes
The seven classes differ enormously, yet none of them owns its own identity, metering, eventing or infrastructure. Every request is first resolved by the Tenant Catalog into tenant, SKU, stamp and isolation policy, then composed into a WorkloadSpec by a service-specific strategy and handed to the matching adapter.
| Service | Layers | Execution chain | Metering unit |
|---|---|---|---|
| AI training & inference | L3–L5 | Tenant/Quota → Kueue/Volcano/Slurm → vLLM/SGLang | GPU-hour, tokens, TTFT |
| HPC | L2–L5 | Bare-metal baseline → Slurm/MPI → Lustre | Node-hour, queue wait |
| IaaS | L1–L5 | Power envelope → Ironic/OpenStack/Kubernetes | vCPU-hour, storage, bandwidth |
| Data processing & ETL | L3–L5 | S3/Iceberg → Airflow/Argo → Spark/Ray | Bytes scanned, task hours |
| Edge AI | L2–L5 | Zero-touch provisioning → K3s/KubeEdge → inference runtime | Device count, connected hours |
| Security & model protection | L2–L5 | Confidential computing → model encryption & signing → access audit | Protected models, audit events |
| Automated operations | L1–L5 | Signal convergence → RunbookController → adapter actuation | Incidents, manual intervention rate |
Four shared interfaces
The control plane exposes four interfaces. All seven service classes consume the same set; none reimplements them. Divergence is permitted in exactly two places: the service strategy (how a WorkloadSpec is composed) and the L4 adapter (how it is translated for a backend).
ITenantContext
Resolves tenant, SKU, stamp and isolation policy
If reimplemented: seven tenant-resolution paths — one wrong and the authorization hole is real
IQuotaPolicy
Quota, priority and budget decisions
If reimplemented: quota cannot be summed across services, so a tenant can consume seven times its allowance
IMetering
Unified UsageRecord posting
If reimplemented: invoices stop reconciling and "what did this tenant spend in total?" has no answer
IIncident
Event normalization, dedup and routing
If reimplemented: one failure pages you seven times, from seven systems
Isolation is a spectrum, not a switch
"Standard" and "high" isolation are not two systems. They are two SKUs of the same platform — identical control plane, identical API, different isolation strength. And the upgrade decision is made independently per layer: a common combination is standard isolation at L3 and above with dedicated L2 and L1, because compliance requirements usually land at the physical layer, not the scheduling layer.
| Layer | Standard isolation | High isolation | When to upgrade |
|---|---|---|---|
| L5 Observability & AutoOps | Tenant-label-filtered SLIs and incidents; shared alert routing | Dedicated Grafana org; independent routing and escalation | Tenant requires its own on-call process, or incident data must not share a surface with others |
| L4 Orchestration & scheduling | ClusterQueue + quota + priority, fair-shared with other tenants | Dedicated queues and reserved capacity; gang scheduling and topology guarantees | A committed completion time, or training jobs that need many nodes to start simultaneously |
| L3 Resource pools | Namespace + NetworkPolicy; shared database schema | Dedicated node pool or cluster; VPC/VLAN/VRF per tenant | Regulation forbids sharing physical nodes for data or compute |
| L2 Bare metal & firmware | Shared node pool, wiped before handover | Dedicated bare metal, never rotated to others; firmware baseline locked with audit evidence | Proof required that hardware was never used by another party, or a pinned firmware version |
| L1 Facility & DCIM | Shared rack power envelope, capacity apportioned by quota | Dedicated racks and power quota; independent cooling and power feeds | Draw large enough to affect neighbouring racks, or a contractual power-availability commitment |
!Every resource, event and usage record at every layer must be traceable to a tenantId.
Cross-tenant operations are only possible through an explicitly granted Platform Scope, and the operation itself leaves an audit record. The implementation is to make tenantId a required column on every table, every event and every usage record, and to inject it at the query layer — never to rely on caller discipline.
!Namespace-only isolation is forbidden at the compute layer.
A Kubernetes namespace is a logical boundary, not a security boundary — containers on the same node still share a kernel. A high-isolation SKU must have network-layer and node-layer isolation as well, and the control plane never reaches into a tenant data plane.
Metering and billing: UsageRecord is the common denominator
GPU, tokens, storage, network, power and incident-handling cost are all posted as immutable events, then priced by a versioned price plan. It is the only language operations and finance share.
Replays never double-post
Each usage record is keyed by provider + resourceDomain + meter + externalUsageId. Replay the same event ten times and it posts exactly once.
Three separate timestamps
Metered time, received time and settled time are tracked independently. Late-arriving data lands in the next period under the close policy, or generates a correction — history is never edited in place.
Price plans are never overwritten
A new price creates a new version with an effective window. Any invoice can be recomputed from the same priceVersion and produce byte-identical results.
Be explicit about the GPU-hour denominator
Nominal capacity, allocated capacity, actual execution, effective goodput and power-capped capacity are five different numbers. Conflating them is the main source of margin loss and customer disputes.
Usage can be reversed, never modified
Once received, a UsageRecord is immutable and can only be corrected by a reversing event. Period-close snapshots are written to WORM storage for audit.
Incident management and automation
The value of this subsystem is not in sending notifications — that is the easy part. The value is in convergence and controlled remediation.
Alert and Incident must stay separate
An Alert is the convergence unit at the signal layer, merged by dedupKey. An Incident is the handling unit for humans and automation, and may contain many Alerts. Conflate them and the symptom is either "one failure opened 50 incidents" or "the incident is closed but the alert is still firing."
A webhook may only emit an ActionRequest
Webhooks never touch resources directly. The RunbookController validates the allowlist, the tenant/stamp scope, cooldown and current state, then calls the adapter with a short-lived credential. Bypass that line and you have handed production control to an HTTP callback.
Recovery means re-observing the SLI
After an action completes, the indicator must be observed again; only then is the incident resolved under the same dedupKey. Resolving without re-observation is a forbidden state transition.
Automation ships in shadow mode first
Closed-loop automation goes live in advisory mode. It is promoted to enforcement only after its judgements are validated, and always with hysteresis, cooldown, floors, human approval and a full audit trail. Automation escalating a small incident into a large one is the worst failure mode this class of system has.
Physical network infrastructure
The software platform reduces L1 to a single number: available power. That number has a source — the engineering design of the physical network. Break that link and L4 schedules against stale capacity.
- Requirements
- Design (AutoCAD)
- BOM
- Construction
- As-built
- DCIM
- L1 capacity
- L4 placement
Four design deliverables
Rack elevation, fiber backbone single-line diagram, cable schedule and BOM. Every build or expansion must produce all four; skip one and the gap is patched during construction instead.
The BOM is a design-completeness checklist
Every BOM line must map to a drawing number. Nothing is purchased that is not on a drawing; anything on a drawing but missing from the BOM becomes a shortage on site. This rule surfaces design gaps before procurement.
Five validation rules
Optics count = ports × 2, including A/B paths; optical power budget verified link by link (SR4 over OM4 caps at 100 m); fiber utilization at handover must stay under 60%; spares at 5–10% for common parts and 25% for long-lead items.
Path separation is what gets cut first
If the two paths share a single tray for even one segment, the dual-path availability guarantee no longer holds — and that is usually discovered during the outage, not before it.
Delivery milestones
Five phases from modelling to live operation, each with an acceptable result. We do not accept "build it first and see" — every phase must pass automated tenant-isolation and metering-consistency tests before the next one starts.
- 0UML & baseline2 weeksDomain vocabulary, UML diagrams, ADRs, tenant-isolation threat model, UI information architecture
- 1Multi-tenant UI & control plane8 weeksLogin, tenants, projects, roles, resource catalog, quota, basic workload flow
- 2Metering & operations8 weeksGPU/token metering, invoice preview, SLOs, alerting, incidents and audit
- 3Multi-engine & automation10 weeksK8s/Slurm/inference adapters, reservations, shadow-mode AutoOps
- 4Productionization8–12 weeksHA, DR, performance, security, payments, dedicated tenants and live operation
05Approach
Four steps — and every one has a deliverable.
We do not run "assessment phases" that produce nothing. At the end of each step you hold something that can be reviewed independently and handed to someone else.
Diagnose
Inventory current workflows, data assets and compute reality; find where value density is highest. Output: current-state architecture, bottleneck list, prioritized value map.
Prioritize
Select 2–3 use cases and write success as measurable acceptance criteria, not as a vision statement. Output: use-case specifications, acceptance criteria and ADRs.
Build
Hands-on implementation: systems integration, tenant isolation, metering wiring, compliance and audit, on-call process. Output: a running system, contract tests and runbooks.
Scale
Pilot to production: HA, DR, performance tuning, cost model and organizational handover. Output: a live environment, and a team that can run it without us.
06Who we serve
AI data center operators, and enterprises building their own compute.
Technically these two customers have the same problem: how to make one batch of expensive, supply-constrained GPUs serve multiple mutually untrusting users, while every kilowatt-hour and every token still adds up. The only difference is whether the tenant is an external customer or an internal business unit.
Audience one
AI data center operators
Colocation providers, telcos, cloud providers and SPVs selling compute. Your tenants are paying customers, so billing accuracy and proof of isolation translate directly into revenue and contractual risk. You need a control plane that can invoice, withstand audit, and back an external SLA.
Audience two
Enterprises building their own compute
Manufacturing, financial services, healthcare, research institutes and government. Your tenants are internal business units and research teams; the problem is fairness, priority and cost allocation across a shared GPU fleet — and whether you can prove, when audit arrives, that data never crossed a departmental boundary.
Taiwan's compute gap is becoming an infrastructure problem
303 → 468 MW
Taiwan data center installed capacity
2026 → 2031, 9.09% CAGR
450 MW
Taiwan AI data center scale, projected 2029
National Science and Technology Council estimate
US$1.6B
Taiwan data center market, 2030
US$810M in 2025, 14.6% CAGR
Sources: Mordor Intelligence, Taiwan Data Center Market; National Science and Technology Council
What we actually deliver
Not "consulting services" — ten system capabilities you can accept one by one. Two sides: the operations side facing tenants decides whether you can invoice and commit to an SLA; the platform side facing the facility decides whether you can safely sell the same GPU twice.
Operations side — facing tenants
Tenant onboarding & quota management
CoreSelf-service requests, SKU selection, quota grants and budget ceilings. Onboarding drops from weeks to hours, with an audit record at every step.
Compute metering & invoicing
Multi-dimensional pricing across GPU-hour, tokens, storage, network and energy. Prices are versioned, so any period can be recomputed to the same result.
Workload submission & queue visibility
Console, SDK and API entry points. Queue position, estimated wait, estimated cost and the blocking reason are all shown — not just an error code.
SLA & tenant status page
SLO definitions, degradation strategy and incident timelines. Only affected tenants see detail; the platform can aggregate without leaking other tenants.
Isolation proof & audit reporting
From shared namespace to dedicated bare metal, every tier produces isolation evidence and attestations you can hand to compliance and to customers.
Platform side — facing the facility and NOC
Capacity & power planning
CoreA capacity model across power, cooling, space and fiber, with DCIM as the single source of truth; the as-built write-back procedure is part of delivery.
Scheduling & resource pool governance
Fair share, priority, gang scheduling and topology-aware placement. The power ceiling travels from L1 into placement, so work never lands on a rack that cannot be powered.
Incident convergence & on-call
Signal dedup, incident grouping, escalation policy and runbooks. Hundreds of alerts converge into a handful of incidents, so the pager does not fire thirty times in five minutes.
AutoOps closed-loop automation
Ships in shadow mode to validate its judgements, then promotes to enforcement — with hysteresis, cooldown, floors, human approval and a replayable decision chain.
Bare metal lifecycle & offboarding wipe
Provisioning, firmware baselines and health checks, through to wiping disks, GPU memory, BMC credentials and ephemeral keys — with an attestation left behind.
07About
Strategy, AI expertise and build — under one roof.
Acumina Computing (睿算) is an AI infrastructure and delivery company. We put consulting-grade problem definition and infrastructure-grade implementation in the same team, because AI delivery usually fails exactly at the seam between the two.
Model before you build
Multi-tenant failures are rarely screen problems. They are unclear tenant boundaries, state machines and compensation flows. So we start with UML: fix what each role may do, who owns which data and under what invariants, and how the control plane hands work to different data planes.
No vendor lock-in
Kubernetes, Slurm, OpenStack and vLLM all sit behind adapters; the core domain depends on none of them. Swapping a backend engine should never mean rewriting the control plane or the billing logic.
Systems that survive audit
Every automated action, every usage record and every cross-tenant operation leaves evidence. A system that self-heals but cannot explain who did what under which conditions becomes a new problem source at the post-incident review.
Capability handed back to you
Our goal is not a permanent residency. What we leave behind is documentation, contract tests, runbooks and a trained team — so you can keep operating without us.
- ·Never write PoC capability up as production capability
- ·No abstraction before a second implementation exists
- ·Start as a modular monolith; keep split-ability via events and adapters
- ·Every long-running flow gets a workflow view: current state, who we are waiting on, why it failed, what can be retried
- ·When quota is exhausted, show the policy and the request path — not just a 403
08Contact
Let's find your last mile.
If you are planning an AI data center, evaluating a multi-tenant compute platform, or holding an AI project stuck between pilot and production — talk to us. The first conversation needs no deck, only the specific problem you are hitting.
- Company
- Acumina Computing 睿算
- Practice
- AI data center platforms · Enterprise compute delivery
- Location
- Taiwan