What changed on October 8, 2026
On October 8, 2026, TechCrunch reported that Arena raised $200 million at a $3.1 billion valuation. The company is known for AI model evaluation and leaderboards, and the reported valuation nearly doubled in 10 months.
The funding number matters less to infrastructure operators than the workload signal behind it. Model evaluation is no longer only a research notebook activity or an occasional procurement exercise. It is becoming a commercial workload with its own customers, schedules, audit expectations, and service levels.
That changes capacity planning for small and mid-size GPU estates. If an operator owns a quarter rack, one rack, or a few racks, evaluation jobs cannot simply be allowed to land wherever there is a free accelerator. They are bursty, often reproducible, sometimes confidential, and frequently tied to business decisions such as model selection, promotion to production, vendor comparison, or regulatory evidence. At the same time, the same estate is usually expected to serve latency-sensitive inference, fine-tuning, notebooks, and internal platforms.
The bottleneck is not only GPU supply. The bottleneck is governable utilization. Operators need to keep production serving stable while giving evaluation teams enough isolated capacity to run repeatable benchmark and canary workloads. They need chargeback so the evaluation function can be funded instead of hidden in general inference cost. They need quotas so a leaderboard run does not starve a customer endpoint. They need storage policies so prompts, outputs, weights, logs, and test datasets remain inside the desired jurisdiction.
For GCC and MENA operators, the issue is especially practical. Many organizations are building sovereign AI capacity on owned hardware, not renting every experiment from a hyperscaler region. Ministries, banks, universities, telecoms, energy companies, and local cloud operators may all need evaluation capacity, but they also need data residency, Arabic and regional language test sets, audit trails, and local support. A small estate has to behave like a disciplined region even when it is physically only a few racks.
Why evaluation is different from ordinary batch
Evaluation looks like batch computing, but it behaves differently enough to deserve its own lane.
A benchmark run might generate thousands or millions of prompts against one or more models. Some runs are small, such as a new model candidate tested on a private regression set. Others are large, such as comparing multiple model versions across languages, safety categories, retrieval configurations, and latency targets. A canary evaluation may run continuously against live traffic samples, while a formal benchmark may run only before release.
The hard part is that evaluation has two conflicting needs.
First, it needs reproducibility. A useful evaluation must be able to say what model, dataset, prompt template, runtime image, accelerator profile, and sampling parameters were used. If a run is interrupted and rescheduled onto a different class of GPU with different precision behavior or different runtime libraries, the result may still be usable, but it is no longer the same experiment. That distinction matters for governance.
Second, it is usually bursty. A team may need 2,000 GPU-hours in three days, then almost nothing for a week. If that burst is allowed to take over the cluster, inference service levels suffer. If the burst is permanently reserved, utilization collapses when the evaluation team is idle.
This is where small estates feel pain first. A hyperscaler can absorb burst across a vast fleet. A 48 GPU or 96 GPU private estate cannot. One badly scheduled evaluation campaign can consume a visible fraction of the estate. A model comparison that occupies 16 GPUs for 36 hours is 576 GPU-hours. On a 48 GPU estate, one day of total available capacity is only 1,152 GPU-hours. The run is large enough to matter to finance, power, and customer service.
The operator problem: one fleet, multiple tenants
Most non-hyperscaler operators do not want separate clusters for every workload class. A separate production inference cluster, evaluation cluster, notebook cluster, and VM cluster may be clean on paper, but it wastes hardware. The better pattern is one governed fleet with different tenancy modes.
That fleet has to support at least four lanes:
| Lane | Typical workload | Operator requirement |
|---|---|---|
| Production inference | Customer or internal serving endpoints | Low latency, admission control, stable capacity |
| Evaluation | Benchmarks, regression tests, model comparisons | Reproducibility, metering, data isolation |
| Canary | Pre-release models, shadow traffic, safety checks | Small but protected capacity, strong logging |
| Backfill | Fine-tuning, embeddings, offline analytics | Low priority use of otherwise idle capacity |
The mistake is treating these lanes as only Kubernetes namespaces. Namespaces help, but they do not solve bare-metal provisioning, accelerator partitioning, VM tenancy, storage placement, chargeback, or power planning. Operators need the lane design to be visible from hardware install through workload accounting.
A system such as ClastIQ is built for that layer of work. It is not limited to a single accelerator vendor or only to Kubernetes. The platform combines bare-metal provisioning with MAAS and Juju, Kubernetes and VM tenancy on the same fleet, GPU partitioning through MIG where available and time-slicing where appropriate, Ceph storage, tenant metering, chargeback, quota policy, air-gap deployment patterns, and local support. The point is to make owned hardware behave like a governable cloud region without requiring the operator to become a hyperscaler.
A worked example: 48 GPUs, one evaluation lane
Consider an operator with 12 servers, each with 4 accelerators, for a total of 48 GPUs. The estate supports internal inference, evaluation, canary testing, and occasional batch jobs. The site average IT draw for the GPU estate, including servers, networking, and storage allocation, is 80 kW.
Assume a 30 day month.
Total available GPU-hours:
48 GPUs x 24 hours x 30 days = 34,560 GPU-hours
Before formal scheduling, the estate records the following useful work:
Production inference: 14,500 GPU-hours Evaluation bursts: 2,800 GPU-hours Total useful work: 17,300 GPU-hours Utilization on available GPU-hours: 17,300 / 34,560 = 50.1 percent
The utilization number is not low because nobody wants GPUs. It is low because the operator is protecting inference by leaving slack, because evaluation bursts arrive unpredictably, and because teams hesitate to run lower priority jobs when they might collide with production.
Now the operator creates a governed layout:
36 GPUs are the primary production inference pool. 8 GPUs are the primary evaluation pool. 4 GPUs are the protected canary pool. Idle capacity in any pool can be borrowed by preemptible backfill work, but only under policy.
After implementing quotas, priority classes, and metering, the monthly useful work becomes:
Production inference: 16,800 GPU-hours Evaluation: 2,400 GPU-hours Canary: 800 GPU-hours Backfill batch: 4,200 GPU-hours Total useful work: 24,200 GPU-hours Utilization on available GPU-hours: 24,200 / 34,560 = 70.0 percent
Now add cost. Suppose the all-in monthly cost allocated to this estate is:
Capital recovery: $115,200 Facilities power: 80 kW x 720 hours x $0.15 = $8,640 Operations, support, software, and spares allocation: $31,680 Total monthly cost: $155,520
Cost per available GPU-hour:
$155,520 / 34,560 = $4.50
Cost per useful GPU-hour before policy:
$155,520 / 17,300 = $8.99
Cost per useful GPU-hour after policy:
$155,520 / 24,200 = $6.43
No new GPUs were purchased in this example. The improvement came from treating evaluation as a scheduled tenant with measured consumption, then letting low priority work backfill unused capacity. If the operator charges internal tenants an average of $7.50 per useful GPU-hour, monthly recovered revenue is:
24,200 x $7.50 = $181,500
Annualized against 80 kW of IT load, that is:
$181,500 x 12 / 0.08 MW = $27.225 million per MW-year
That number is not a universal benchmark. It is a way to force the right conversation. Revenue per megawatt is improved by utilization, not by pretending every GPU can be sold every hour. Evaluation capacity should be budgeted, metered, and reported as a product lane, not hidden inside production inference overhead.
Partitioning without fragmenting the estate
GPU partitioning is useful only if it maps to workload behavior. Evaluation sometimes needs whole GPUs for throughput and reproducibility. It sometimes needs smaller slices for many parallel lightweight inference tests. Canary workloads may need a small protected slice with predictable access. Notebook users may need time-sliced access, but should not be able to disturb formal benchmarks.
On NVIDIA estates, MIG can provide hardware-backed GPU instances on supported devices. Time-slicing can increase concurrency where isolation requirements allow it. On AMD and mixed CPU/GPU estates, the operator still needs profiles, scheduling classes, and metering, even when the technical partitioning mechanism differs. Hardware-agnostic does not mean pretending every device is identical. It means exposing policy consistently while respecting what the hardware can actually enforce.
A useful operating model is to publish a small catalog of accelerator profiles rather than letting every team invent its own shape. For example:
| Profile | Intended use | Policy |
|---|---|---|
| gpu-full | Formal benchmark runs, large models | Dedicated device, metered by GPU-hour |
| gpu-slice | Parallel small evaluations, canary probes | Partitioned or time-sliced, capped concurrency |
| gpu-burst | Short evaluation campaigns | Quota-limited, expires after approval window |
| gpu-backfill | Offline jobs | Preemptible, lowest priority |
This catalog becomes the contract between infrastructure and tenants. The evaluation team requests a profile, not a mystery node. Finance receives metered GPU-hours by tenant and profile. Operations can see whether the estate is short on full GPUs, slices, storage IOPS, or power headroom.
Policy belongs close to provisioning
Evaluation governance fails when policy is added only after the cluster is already full of workloads. The bare-metal layer, Kubernetes layer, VM layer, and storage layer must share the same tenant model.
Bare-metal provisioning matters because GPU hosts are not interchangeable forever. Firmware, driver families, accelerator models, network placement, and storage proximity all affect repeatability. MAAS and Juju help make host state declarative and repeatable, which is essential when evaluation results may be challenged later.
Kubernetes matters because most inference and evaluation pipelines are containerized. VM tenancy matters because some model teams, vendors, or research groups need isolated operating system environments, licensed tools, or appliances that are not a natural fit for containers. Small estates should not have to choose between Kubernetes and VMs for the whole fleet. They should be able to place both on the same governed hardware base.
Storage matters because evaluation produces more than a score. It produces prompt sets, retrieved documents, model outputs, traces, safety labels, logs, and artifacts. Ceph gives the operator a common storage substrate for object, block, and file patterns, while keeping data under local administrative control. For sovereign or air-gapped deployments, the difference between local storage policy and external object storage is not cosmetic. It is the boundary of the system.
The policy itself should be simple enough to audit. A useful quota expression might look like this, independent of the exact control plane syntax:
tenant: model-evaluation
month: 2026-10
gpu_hour_quota: 2400
profiles_allowed:
- gpu-full
- gpu-slice
max_concurrent_full_gpus: 8
can_borrow_idle_capacity: true
borrow_priority: below-production
storage:
ceph_pool: eval-artifacts
retention_days: 90
export_allowed: false
chargeback:
full_gpu_hour: 7.50
slice_gpu_hour: 3.00
This is the operating contract. It says how many GPU-hours the evaluation tenant can consume, how much concurrency it can use, whether it can borrow idle capacity, where artifacts live, how long they are retained, and how finance will account for the work.
Canary capacity is not spare capacity
Many operators underfund canary testing because it appears small. That is a mistake. Canary capacity is the gate between evaluation and production. It should be protected from both large benchmark runs and ordinary production autoscaling.
A canary lane might use only 4 GPUs in the 48 GPU example, or even slices of those GPUs, but it needs stability. It may run shadow traffic, regional language checks, retrieval validation, safety probes, or latency comparisons against a candidate model. If this lane is starved, teams either skip canary checks or run them inside production. Both choices increase operational risk.
For GCC and MENA organizations, canary design should include local language and jurisdictional tests. Arabic dialect performance, bilingual prompts, local policy constraints, and sector-specific terminology may not be covered by generic public benchmarks. Evaluation capacity is where those tests are run. Canary capacity is where the operator confirms that a model can behave under live-like conditions without moving sensitive data outside the estate.
Metering is the governance layer finance understands
The technical team may care about queue depth, SM occupancy, memory pressure, and pod placement. The CFO or business unit owner usually cares about a smaller set of questions.
Who used the GPUs? For what workload class? How many GPU-hours were consumed? What was the cost per useful GPU-hour? Which tenant exceeded quota? Which workloads improved revenue per megawatt?
Per-tenant metering and chargeback make evaluation visible. They also reduce conflict. Without metering, production teams see evaluation as interference. Evaluation teams see production as an excuse for delays. With metering, both become tenants of the same estate, each with budget, quota, service expectations, and escalation paths.
The key is to meter at the level operators can act on. GPU-hours by tenant are necessary but not sufficient. Add profile, priority class, storage usage, network egress where relevant, and power allocation if the facility model supports it. For sovereign deployments, also record data location and export policy. That audit trail is useful for internal governance even when there is no external certification claim.
Power and cooling are part of scheduling
Evaluation workloads can create power bursts. A formal benchmark may drive accelerators harder than typical production inference, especially if production uses batching limits or latency caps. If a small estate is near its power envelope, scheduling evaluation is also scheduling watts.
Operators should connect workload policy to facility limits. If a rack has 30 kW available and the evaluation run would push it above the safe envelope, the scheduler should queue, spread, or reduce concurrency. Buying more GPUs without this control can worsen reliability. The estate needs to optimize revenue per megawatt, not only peak tokens per second.
This is another reason to avoid isolated manual clusters. If evaluation hardware sits idle most of the week, the operator loses utilization. If evaluation shares blindly with inference, the operator risks service incidents. A governed fleet with quotas, priority, profiles, and power-aware placement gives a better middle path.
What ClastIQ changes for the operator
ClastIQ is aimed at operators who own the hardware and need a cloud-like operating model at a smaller physical scale. In the evaluation use case, the practical changes are:
One fleet can serve Kubernetes and VM tenants, rather than forcing every model team into one runtime. Bare-metal state can be provisioned and rebuilt consistently with MAAS and Juju. GPU partitioning can be exposed through a catalog that fits the actual hardware, including NVIDIA, AMD, and mixed CPU/GPU estates. Ceph can keep evaluation artifacts, datasets, and tenant storage under operator control. Quotas and chargeback can turn evaluation from an unmanaged interruption into a funded workload. Air-gap and sovereign deployment patterns can keep sensitive model tests inside local boundaries. Human-led local support can matter when the operator has a small team and no hyperscaler operations bench behind it.
None of this removes the need for capacity planning. It makes capacity planning measurable. Arena's funding round is a reminder that evaluation is becoming a workload category with economic weight. Operators should now decide where that workload lives, how it is isolated, how it is priced, and how it improves utilization rather than damaging it.
What to do this week
- Inventory evaluation demand separately from inference. Count benchmark, regression, canary, safety, and vendor comparison GPU-hours for the last 30 to 90 days.
- Create an evaluation tenant model. Define allowed accelerator profiles, monthly GPU-hour quota, maximum concurrency, storage pool, artifact retention, and export policy.
- Reserve protected canary capacity. Keep it small if necessary, but do not let production autoscaling or benchmark bursts consume it.
- Add backfill policy. Let low priority jobs borrow idle production or evaluation capacity, with preemption rules that are written down and tested.
- Report cost per useful GPU-hour and revenue per MW. Use these numbers in capacity reviews before buying more hardware.
- Validate sovereignty controls. Confirm where prompts, outputs, logs, datasets, and model artifacts are stored, especially for GCC and MENA regulated workloads.
ClastIQ runs this operating model on the operator's own hardware. request a demo
Sources
TechCrunch: Popular AI leaderboard Arena nearly doubles valuation to $3.1B in 10 months