AI infrastructure · Multi-tenant compute · Delivery
Planning, building and operating
AI data centres and enterprise compute.
We provide strategy, architecture, systems integration, multi-tenant control plane build, metering and billing, incident handling and operational handover, taking enterprise AI projects from pilot through to live operation.
01Industry position
Investment in AI keeps growing. The ability to land it lags behind.
According to the Artificial Intelligence Foundation, Taiwan's industry AI index rose from 36.77 to 46.32 in a single year. The growth came mainly from more people using AI, while change to core processes remains limited.
6.6%
of enterprises have integrated AI into a core process
Most of the rest remain at the tool-trial stage
61.8%
of AI use happens outside organisational governance
Usage records and cost attribution both still to be established
29.17
talent strategy score, lowest of the six dimensions
44.7% of enterprises have yet to establish AI training
Source: Artificial Intelligence Foundation (AIF), 2026 Taiwan Industry AI Adoption Survey
On the compute side the problem is more concrete.
Usable compute rests on five mechanisms: access rights, quota ceilings, current-period usage, cost attribution and fault handling. With all five in place, a facility can answer the most basic question of cost attribution: which department, which project and which training run produced this month's spend.
02What we do
We own the last mile of AI delivery.
Whether an AI project lands turns mostly on whether a single party takes on the implementation once the diagnostic is finished and the tooling is in place.
Strategy firms
Deliver a diagnostic, then hand over
Roadmaps, maturity assessments and investment cases, all to a professional standard, with the deliverable ending at the document. Implementation risk sits with the client.
Technology vendors
Supply tools, then hand over
GPUs, clusters, model serving and monitoring platforms, each supplied as a discrete product. Integrating them into a system that can be operated, billed and audited usually falls outside the contract.
Acumina Computing
Stay until the system is live
We provide architecture, systems integration, tenant isolation, compliance and audit, metering and billing, incident handling and team handover, taking the project from pilot to live operation and transferring operational capability to the client.
We focus on systems integration and operational capability. What we deliver is a system the client can run independently, together with the documentation, tests and training that keep it running. The capability stays with the client.
03Delivery tiers
Three delivery tiers, matched to project scale.
We use three tiers to align expectations, staffing and timelines. The tier follows the number of organisational units a project crosses; the more units involved, the more often the binding constraint turns out to be coordination.
Single workflow optimisation
Suited to a single department, a single process and one clear metric. Results within 8 to 12 weeks at controlled risk, which makes it a sound starting point and a reference case for the organisation.
Cross-functional process improvement
Spans two or more units and touches data ownership and KPI allocation. Moderate technical difficulty; the substantial work lies in defining accountability and negotiating interfaces.
Enterprise-wide transformation
Covers shared compute, unified data and model governance, and a cost allocation mechanism. This tier requires infrastructure first, otherwise each project rebuilds the same foundation.
04AI data centre
The multi-tenant AI data centre platform
This platform is the infrastructure that enterprise-wide transformation requires, and our principal product. A single control plane lets multiple tenants and multiple workload classes share the same GPU capacity, while managing isolation, quota, metering and audit.
Core design principle
The first deliverable is the control plane. Platform administrators, tenant administrators, developers, NOC staff, finance and audit all need to complete their own work within it. Backend engines can be replaced later; the control plane is worth getting right the first time.
Five execution layers, facility through automated operations
Every service runs on the same five-layer base, from the bottom up: facility, physical servers, resource pools, workload scheduling, and monitoring with automated operations. Each layer carries its own duties, metrics and operating rule.
Layer 5 · Monitoring and automated operations
- Duty
- Ingest service indicators and events, converge alerts, run closed-loop automation and on-call
- Metrics
- Process: time to acknowledge, time to restore, alert noise ratio, automation success rate
- Invariant
- Every automated action retains a full observe, decide, approve, act and verify record, and supports replay
Seven deliverable service classes
The seven classes differ considerably in character, yet share one set of identity, metering, eventing and infrastructure. Each request is first resolved by the tenant catalogue into tenant, service plan, deployment unit and isolation policy, then composed into a workload specification by the relevant service strategy and passed to the matching adapter.
| Service | Layers spanned | Execution chain | Metering unit |
|---|---|---|---|
| AI training and inference | Resource pools → monitoring | Tenant and quota resolution → Kueue／Volcano／Slurm → vLLM／SGLang | GPU hours, tokens, first-token latency |
| HPC | Physical servers → monitoring | Bare-metal baseline → Slurm／MPI → Lustre | Node hours, queue wait |
| IaaS | Facility → monitoring | Power envelope → Ironic／OpenStack／Kubernetes | vCPU hours, storage, bandwidth |
| Data processing and ETL | Resource pools → monitoring | Object storage and table formats → Airflow／Argo → Spark／Ray | Bytes scanned, task hours |
| Edge AI | Physical servers → monitoring | Zero-touch provisioning → K3s／KubeEdge → inference runtime | Device count, connected hours |
| Security and model protection | Physical servers → monitoring | Confidential computing → model encryption and signing → access audit | Protected models, audit events |
| Automated operations | Facility → monitoring | Signal convergence → runbook controller → adapter actuation | Incidents, manual intervention rate |
Four shared interfaces
The control plane exposes four interfaces, shared by all seven service classes. Divergence is permitted in two places only: how a workload specification is composed, and how the adapter translates it for a backend.
Tenant context (ITenantContext)
Resolves tenant, service plan, deployment unit and isolation policy
Shared, tenant resolution stays a single piece of logic and authorisation only has to be proven correct once.
Quota policy (IQuotaPolicy)
Quota, priority and budget decisions
Shared, quota sums across services and each tenant stays within one ceiling.
Metering (IMetering)
Unified usage record posting
Shared, invoices reconcile in full and total spend per tenant is available at any time.
Incident (IIncident)
Event normalisation, deduplication and routing
Shared, one failure converges into a single incident and the on-call path stays consistent.
Isolation is graded, not binary
Standard and high isolation are two service plans on one platform, with an identical control plane and API and a difference only in isolation depth. The decision to upgrade is also taken layer by layer. A common configuration keeps standard isolation at the resource pool layer and above, with dedicated physical servers and facility, since regulatory requirements usually land at the physical layer.
| Layer | Standard isolation | High isolation | When to upgrade |
|---|---|---|---|
| Layer 5 Monitoring and automated operations | Service indicators and incidents filtered by tenant label; shared alert routing | Dedicated dashboard organisation; independent alert routing and escalation | The tenant runs its own on-call process, or incident data must not appear alongside another tenant's |
| Layer 4 Workload scheduling and resource allocation | Shared cluster queues, quota and priority, fair-shared with other tenants | Dedicated queues and reserved capacity; gang scheduling and topology guarantees | A committed completion time, or training work that needs many nodes to start together |
| Layer 3 Resource pools and provisioning | Namespaces and network policy; shared database schema | Dedicated node pool or cluster; per-tenant virtual network and segment | Regulation prevents data and compute sharing a physical host with another party |
| Layer 2 Physical servers and firmware | Shared node pool, wiped before transfer to the next tenant | Dedicated hardware, never rotated to others; firmware version pinned with audit evidence retained | Proof is required that the hardware has never been used by another party, or firmware must be pinned |
| Layer 1 Facility and power | Shared rack power envelope, capacity apportioned by quota | Dedicated racks and power allocation; independent cooling and supply circuits | Draw large enough to affect neighbouring racks, or a contractual power availability commitment |
!Resources, events and usage at every layer remain traceable to a tenant identifier.
Cross-tenant operations run only through explicitly granted platform-level permission, and the operation itself retains an audit record. The tenant identifier is a required field on every table, event and usage record, injected by the system at the query layer.
!Namespaces alone are insufficient as isolation at the compute layer.
A Kubernetes namespace provides a logical boundary; the security boundary comes from network-layer and host-layer isolation, since containers on one host share an operating system kernel. High isolation provides both, and keeps the control plane separate from the tenant data plane.
Metering and billing on a common basis
GPU, tokens, storage, network, power and incident handling cost all post as immutable usage records, then price against a versioned plan. Operations and finance work from one set of figures.
One event posts once
Each usage record is keyed on source system, resource class, meter and source reference. The same entry resent ten times still posts once.
Three timestamps kept separately
Metered time, received time and settled time stay independent. Late-arriving data enters the next period under the close policy, or raises a correction, leaving historical records as they stand.
Price plans are versioned
A price change creates a new version with an effective window. Any period can be recomputed against the price version that applied, giving the same result.
The GPU-hour denominator is defined up front
Nominal capacity, allocated capacity, actual execution, effective throughput and power-capped capacity are five distinct figures, each matching a different billing situation. Defined clearly, margin and invoices reconcile line by line.
Usage is corrected by reversing entry
A usage record is fixed once received, and later adjustment posts as a reversing entry. Period-close snapshots are written to tamper-evident storage for audit.
Incident management and automation
The value of this subsystem lies in signal convergence and in keeping automation within a controlled scope. Sending notifications is the most basic part of it.
Alerts and incidents stay separate
An alert is the convergence unit at the signal layer, merged on a deduplication key. An incident is the handling unit for people and automation, and can contain many alerts. Where the two are conflated, one failure opens dozens of incidents, or an incident closes while the underlying alerts keep firing.
Callbacks emit an action request only
A notification callback stops at issuing an action request. The runbook controller then validates the allowlist, tenant and deployment unit scope, cooldown and current state before calling the adapter with a short-lived credential. Control of the production environment therefore stays on an audited path.
Recovery is confirmed by re-observing indicators
Once an action completes, indicators are observed again, and only a confirmed recovery closes the incident under the same deduplication key. This step is a required transition in the state flow.
Automation ships in advisory mode first
It goes live advising only, and moves to acting once its judgements are confirmed, with hysteresis, cooldown, floors, human approval and full audit. This keeps the reach of automation within a predictable range.
Physical network infrastructure
The software platform presents the facility layer as a single figure for available power. That figure originates in the engineering design of the physical network, and we take on the design and drawing deliverables for that stage as well.
- Requirements
- Design (AutoCAD)
- Bill of materials
- Construction
- As-built
- Facility records
- Available capacity
- Scheduling decisions
Four design deliverables
Rack elevation, fibre backbone single-line diagram, cable schedule and bill of materials. Every build or expansion produces all four, so the design stage covers everything construction needs.
The bill of materials is a completeness check
Every line maps to a drawing number, aligning drawings and procurement item by item. Gaps in the design therefore surface at the procurement stage.
Five validation rules
Optics count is ports times two and includes A and B paths; the optical power budget is verified link by link, with SR4 over OM4 capped at 100 metres; fibre utilisation at handover stays under 60%; spares run 5 to 10% for common parts and 25% for long-lead items.
Path separation holds through construction
Both paths run in independent trays end to end, which is what makes the dual-path availability commitment stand. This is confirmed at handover inspection.
Delivery milestones
Five stages run from modelling to live operation, each with an agreed acceptance result. Every stage passes automated tenant isolation and metering consistency tests before the next begins.
- 0Modelling and baseline2 weeksDomain vocabulary, UML drawings, architecture decision records, tenant isolation threat model, interface information architecture
- 1Multi-tenant console and control plane8 weeksLogin, tenants, projects, roles, resource catalogue, quota, core workload flow
- 2Metering and operations8 weeksGPU and token metering, invoice preview, service level objectives, alerting, incidents and audit
- 3Multiple engines and automation10 weeksKubernetes, Slurm and inference adapters, reservations, advisory-mode automated operations
- 4Productionisation8–12 weeksHigh availability, disaster recovery, performance, security, payments, dedicated tenants and live operation
05Approach
Four stages, each with a defined deliverable.
Every stage carries a concrete output. At the close of each one, the client holds work that can be reviewed independently and handed to someone else to continue.
Diagnose
Survey current workflows, data assets and compute, and identify where value density is highest. Delivered: current-state architecture, bottleneck list and prioritised value map.
Prioritise
Select two or three use cases and set success as measurable acceptance criteria. Delivered: use-case specifications, acceptance criteria and architecture decision records.
Build
Carry out systems integration, tenant isolation, metering, compliance and audit, and establish the on-call process. Delivered: a running system, contract tests and runbooks.
Scale
Move from pilot to production, covering high availability, disaster recovery, performance tuning, cost model and team handover. Delivered: a live environment and a team able to operate it independently.
06Who we serve
AI data centre operators, and enterprises building their own compute.
Both face the same underlying technical problem: expensive, supply-constrained GPU capacity has to serve several mutually untrusting users at once, with every kilowatt-hour and every token attributable. The difference is only whether the tenant is an external customer or an internal unit.
First
AI data centre operators
Colocation providers, telecommunications operators, cloud providers and special purpose vehicles selling compute. Tenants are paying customers, so billing accuracy and proof of isolation bear directly on revenue and contractual risk. These clients need a control plane that can issue invoices, withstand audit and support an external service commitment.
Second
Enterprises building their own compute
Manufacturing, financial services, healthcare, research institutes and government. Tenants are internal business units and research teams, and the central questions are fair allocation of shared GPU capacity, priority, cost apportionment, and whether audit can be shown that data stayed within its department.
The scale of compute Taiwan will build is already quantified
303 → 468 MW
Taiwan data centre installed capacity
2026 to 2031, compound annual growth of 9.09%
450 MW
Taiwan AI data centre scale, projected for 2029
National Science and Technology Council estimate
US$1.6B
Taiwan data centre market, 2030
US$810M in 2025, compound annual growth of 14.6%
Sources: Mordor Intelligence, Taiwan Data Center Market; National Science and Technology Council
Services
We provide the ten services below, priced by deliverable and accepted item by item. They divide in two: tenant-facing operational services, which support invoicing and external service commitments, and facility-facing platform services, which support offering the same GPU capacity safely to several customers.
Operations Tenant-facing
Tenant onboarding and quota management
CoreSelf-service requests, service plan selection, quota issue and budget ceilings. Onboarding shortens from weeks to hours, with a record retained at each step.
Compute billing and invoicing
GPU hours, tokens, storage, network and energy priced separately. Prices are version-managed, so any period recomputes to the same result.
Workload submission and queue visibility
Console, SDK and API entry points. Queue position, estimated wait, estimated cost and the reason for any block are all shown explicitly.
Service commitments and tenant status
Service level objectives, degradation strategy and incident timeline. Detail is open only to affected tenants, while the platform sees aggregate figures with tenant identities kept separate.
Isolation evidence and audit reporting
From shared namespaces through to dedicated hardware, every tier produces isolation evidence and proof of erasure suitable for compliance and for customers.
Platform Facility and operations centre
Capacity and power planning
CoreA capacity model across power, cooling, space and fibre, with the facility management system as the single source of truth. The as-built write-back procedure is included in delivery.
Scheduling and resource pool governance
Fair sharing, priority, gang scheduling and topology-aware placement. The power ceiling passes from the facility layer into scheduling, so work lands on racks with sufficient supply.
Incident convergence and on-call
Signal deduplication, incident grouping, escalation policy and runbooks, converging hundreds of alerts into a handful of incidents so on-call staff can work effectively.
Closed-loop automated operations
Judgements are confirmed in advisory mode before automation begins acting. Hysteresis, cooldown, floors and human approval are all in place, and the decision chain supports replay.
Hardware lifecycle and offboarding
Provisioning, firmware baselines and health checks, through to clearing disks, GPU memory, management controller credentials and ephemeral keys at offboarding, with proof of erasure retained.
07About
Strategy, AI expertise and engineering in one team.
Acumina Computing works across AI infrastructure and delivery. We hold consulting-grade problem definition and infrastructure-grade implementation in the same team, so strategy and execution meet in one place.
Model first, then build
Multi-tenant systems succeed or fail on how clearly tenant boundaries, state machines and compensation flows are defined. We therefore start from UML, establishing each role's permissions, data ownership and invariant conditions, and how the control plane passes work to each data plane.
Vendor-neutral architecture
Kubernetes, Slurm, OpenStack and vLLM all sit behind adapters, leaving the core domain neutral. When a client changes backend engine, the control plane and billing logic carry over intact.
Systems that stand up to audit
Every automated action, every usage record and every cross-tenant operation retains evidence. At a post-incident review, the system can account in full for who did what under which conditions.
Operational capability transferred
We work towards completed handover. At close, we deliver documentation, contract tests, runbooks and a trained team able to operate the platform independently.
- ·Production capability is judged on results from production
- ·Abstraction waits until a second implementation exists
- ·Start as a modular monolith, keeping room to split later through events and adapters
- ·Every long-running flow has a workflow view: current state, what it waits on, why it failed, what can be retried
- ·When quota runs out, state the applicable policy and the route to request more
08Contact
Talk to us about your delivery requirements.
If you are planning an AI data centre, evaluating a multi-tenant compute platform, or holding an AI project between pilot and launch, please get in touch. A first conversation needs no deck, only the specific problem you are facing.
- Company
- Acumina Computing 睿算
- Practice
- AI data centre platforms · Enterprise compute delivery
- Location
- Taiwan