Nori: Connecting AI Workloads to the Right Compute

← All Articles

A single data center does not need a placement layer. When all compute lives in one place, the question of where to send a workload has one answer. Distributed infrastructure across multiple regions, hardware types, and operating states introduces a set of questions that require active reasoning: which cluster has available capacity, which hardware profile matches the workload, which region minimizes latency for the workload's users, and which reservations are already committed.

These questions are not answered by the underlying compute infrastructure. They require a software layer that maintains current visibility into physical capacity, understands workload requirements, and can connect the two in a way that respects customer commitments and infrastructure constraints. This is the problem Nori by Seabase is being developed to solve.

Nori is not a general-purpose AI router in the sense of choosing between model API endpoints. It is being designed around the requirements of physical infrastructure: dedicated hardware, reserved compute allocations, regional availability, and the placement decisions that determine which workloads run where in a distributed subsea deployment.

AI Performance Involves the Complete System

Inference benchmarks measure the performance of an accelerator in isolation: tokens per second, time to first token under a defined load, throughput at a given batch size. These metrics are useful for comparing hardware. They are incomplete as a guide to the performance that an AI workload will deliver in production.

Production AI performance is a function of the complete system: the accelerator, the network path from user to compute, the software stack managing inference, the hardware-model compatibility, the queue depth at the time of the request, and the match between the workload's memory requirements and the memory available in the selected cluster. A workload placed on a fast accelerator in the wrong region will underperform a workload placed on a moderately faster accelerator in the right region because the latency tax compounds through every network hop between user and compute.

For organizations managing persistent AI infrastructure across multiple sites, this means that placement decisions are performance decisions. Choosing which cluster to use for a given workload is not an administrative detail; it is a variable that directly affects the latency and throughput users experience. A placement layer that optimizes only for raw accelerator availability, without accounting for network position, hardware-model fit, and reservation status, will make suboptimal decisions.

Different Workloads Create Different Priorities

The range of AI workloads that organizations deploy against commercial infrastructure is wide. Real-time inference for interactive applications requires very low latency; a 50-millisecond degradation is user-visible. Batch inference for asynchronous analytics tolerates minutes of additional delay without consequence. Model training and fine-tuning are throughput-bound rather than latency-bound, and long job durations make total compute cost more important than time to first response. Embedding generation may require neither peak latency nor peak throughput but runs at high volume.

These different workload profiles create different placement priorities. A real-time inference workload should be placed in the region closest to its users, with hardware that has the per-request latency profile appropriate for interactive use. A batch workload should be placed on hardware that maximizes throughput per dollar, which may be in a region with lower cost rather than the one closest to users. A training job should be placed on hardware that can sustain high utilization over a long window without contention from latency-sensitive workloads sharing the same cluster.

A placement layer that treats all workloads identically will satisfy none of them optimally. Nori is being developed to understand workload priority profiles and to factor them into placement decisions alongside hardware availability and regional capacity. The goal is not to abstract away the placement decision but to make the relevant parameters visible and actionable.

For the case on why persistent AI workloads justify regional infrastructure commitments, see Persistent Regional AI. The workload-type reasoning described there is directly relevant to placement policy.

Infrastructure Routing Versus API Routing

Several categories of software describe themselves as AI routers. The most common variant routes requests between different model API endpoints: OpenAI for one task, Anthropic for another, a fine-tuned model for a third. These routers operate at the application layer and are entirely indifferent to the physical infrastructure on which each model runs. The routing decision is a function of model capability and cost, not of hardware, geography, or capacity state.

Conventional AI routers choose between model APIs. Nori is being developed around infrastructure-level capacity, including dedicated hardware, reserved compute, regional availability, and workload placement.

Infrastructure routing operates at a different level. The question it answers is not which model API to call but which physical compute to use for a workload, given the current state of reserved capacity, regional availability, hardware compatibility, and workload requirements. These are questions that require information about the physical infrastructure layer, not just about model capability and pricing.

For an operator of reserved bare-metal or dedicated compute, API-level routing is irrelevant to the placement decision. The customer has contracted for specific hardware in specific regions. The relevant questions are whether that hardware is operational, whether the cluster is accepting workloads, which deployment configurations are supported, and how utilization is tracking against the reserved allocation. These questions require infrastructure visibility, not model catalog awareness.

Nori is being designed around infrastructure-level routing. It maintains state about physical clusters, hardware profiles, regional operating conditions, and reservation commitments. Application-layer decisions about which model to use are the customer's domain; infrastructure-layer decisions about which cluster to use are the domain Nori addresses.

Making Physical Capacity Visible

Distributed infrastructure that customers cannot observe is infrastructure they cannot effectively manage. Visibility into the current state of physical capacity, which clusters are operational, what hardware is available in each, current utilization against reserved allocation, and any degraded or offline nodes, is a prerequisite for informed workload management.

This visibility requirement is qualitatively different for subsea infrastructure than for terrestrial deployments. A terrestrial data center operator can send a technician to inspect physical hardware. The state of hardware in a subsea cluster must be reported through instrumentation: sensors, telemetry, and monitoring systems that surface the relevant state to operators who may be hundreds of kilometers away.

Nori is designed to serve as the interface through which capacity state is visible to customers. The monitoring layer aggregates telemetry from physical clusters across regions and presents it in a form relevant to operational decisions: not raw sensor data, but the derived operational state of the infrastructure, expressed in terms of available capacity, utilization, hardware health, and regional operating status.

This visibility layer also supports customer capacity planning. An organization managing a large reserved allocation needs to understand how utilization is trending over time, whether there are patterns in workload demand that suggest rebalancing across regions or hardware types, and whether their reserved capacity is sufficient for anticipated growth. Nori's monitoring layer is designed to make this information available in a form that supports planning decisions, not just moment-to-moment operational responses.

Reservation as an Infrastructure Primitive

The reservation model, where a customer commits to a defined allocation of hardware for a defined period in exchange for guaranteed availability and defined pricing, is the primary engagement model for dedicated and bare-metal compute. Reservations are not new in cloud infrastructure; the major cloud providers have offered reserved instance pricing for over a decade. But the reservation model works differently when the underlying infrastructure is physical and regional rather than virtualized and globally pooled.

In a virtualized pool, a reservation is a scheduling priority and a billing commitment. The hardware it maps to is interchangeable with other hardware of the same specification. In a physical reserved model, the reservation maps to specific hardware in a specific region. The customer knows which cluster their workloads run on, and the infrastructure provider knows which hardware is committed to which customer. This specificity has both operational and commercial implications.

Operationally, physical reservations mean that capacity planning is a real constraint. The infrastructure operator cannot overcommit a physical cluster in the way that a virtualized pool can be lightly oversubscribed. If all modules in a cluster are reserved, there is no additional capacity to allocate until a new module is added or an existing reservation expires. This constraint is a feature for customers who need guaranteed availability: their reserved capacity is not competing with a larger pool of on-demand requests.

Nori's reservation layer is designed to manage these physical commitments explicitly. Reservation terms, hardware specifications, regional assignments, and utilization tracking are all represented as first-class objects in the system, not as billing tags applied to a shared pool. When a customer reserves compute capacity through Nori, that commitment is reflected in the physical infrastructure state, not just in a billing ledger.

Connecting Distributed Regions

A single regional cluster, however well-positioned, cannot serve all workload patterns. An organization with users in multiple coastal markets benefits from infrastructure in multiple regions: workloads can be placed closer to the users they serve, and capacity in one region provides resilience if another region is temporarily constrained.

Managing a multi-region deployment requires a control plane that presents a coherent view across regions while preserving the geographic specificity that makes regional deployment valuable. A system that aggregates all regional capacity into an undifferentiated pool loses the placement intelligence that justifies the multi-region investment. A system that treats each region as entirely separate forces customers to manage per-region deployments independently.

Nori is being developed as a unified control plane across Seabase's distributed deployment. Customers see their reserved capacity across all regions in a single interface, can deploy workloads to specific regions based on placement policy, and receive aggregate utilization monitoring across the full deployment. The geographic specificity of each cluster is preserved: the system does not abstract away which region a workload is running in, because that information is operationally and commercially relevant.

For the full architectural picture of distributed subsea infrastructure, see the infrastructure overview. The placement logic in Nori is designed to work with that physical architecture, not to abstract it away.

Geography as Part of the Decision

Placement decisions that ignore geography will systematically underperform placement decisions that account for it. The latency tax is measurable and compounds across multi-step AI pipelines. An organization whose AI workloads serve users in a specific coastal market should place those workloads in the region closest to that market. An organization whose workloads need to be co-located with specific data sources should place compute in the region where that data is resident.

These are not exotic requirements. They are the normal requirements of organizations operating AI at scale, and they require the placement layer to have a model of geography that goes beyond "which cluster has available capacity." Nori is designed to represent regional location explicitly and to factor it into placement recommendations based on customer-specified policies.

Data locality is a related concern. Workloads that process large volumes of data benefit from compute that is near the data, because moving large datasets across long network paths is expensive in both latency and cost. Organizations with data-residency requirements, where customer data cannot leave a defined geographic boundary, need placement infrastructure that can enforce those requirements rather than treating them as annotations on a shared pool.

Nori's placement model is designed to accommodate these constraints. Customers can specify placement policies that include geographic preferences, data-locality requirements, and residency constraints. The system maps these policies to physical clusters that can satisfy them, rather than requiring customers to manually manage per-region deployments to achieve the same result.

Supporting Different Hardware and Models

Commercial AI infrastructure is not homogeneous. Different hardware generations offer different performance profiles for different workloads. A cluster built around one GPU generation may excel at high-throughput batch inference but be less suited to memory-intensive large-context workloads. A newer generation may reverse those trade-offs. As Seabase's subsea infrastructure supports hardware refresh through modular replacement, the fleet will at any given time include modules with different hardware specifications.

Model compatibility is a related dimension. Large language models and other AI workloads have specific requirements: minimum GPU memory, support for particular precision formats, specific software stack versions. A placement layer that does not track hardware-model compatibility cannot reliably place workloads on hardware that will support them.

Nori maintains a hardware profile for each cluster, including GPU generation and specifications, memory capacity, precision support, and software stack version. When a workload with defined model requirements is being placed, the system can filter to clusters that satisfy those requirements before applying geographic and utilization criteria. This prevents placement decisions that route a workload to hardware that will fail to run it, which is operationally worse than a placement decision that routes it to a slightly suboptimal but compatible cluster.

The infrastructure layer's ability to support multiple hardware generations simultaneously, described in more detail in the context of modular subsea design, has a direct counterpart in the placement layer: Nori can route workloads to hardware that matches their requirements even when the fleet includes heterogeneous hardware. See also Power-Flexible AI Infrastructure for the relationship between hardware selection, power profiles, and workload placement.

Keeping Safety Separate

Nori's scope is the customer-facing infrastructure control plane: capacity discovery, reservation management, workload deployment, utilization monitoring, billing, support, and regional management. It is the software interface through which Seabase customers operate their AI workloads on Seabase infrastructure.

Subsea infrastructure involves operational safety systems that are categorically separate from the customer control plane. The physical handling of subsea modules, monitoring of structural and environmental conditions relevant to infrastructure safety, and coordination of any retrieval or maintenance operations are managed through dedicated operational systems with their own monitoring, authority, and procedures. These systems are not customer-facing and are not connected to Nori.

This separation is both a design choice and a safety requirement. Customer workload management and infrastructure safety management are different domains with different requirements, different audiences, and different failure modes. A customer adjusting their workload deployment through Nori is performing a software operation. An engineer managing the physical state of a subsea cluster is performing an operational procedure with physical consequences. Conflating the two would create risk in both directions: safety-relevant operations should not be accessible through a customer-facing API, and customer workload operations should not be dependent on safety system state.

Nori is not an autonomous subsea equipment controller. It does not manage the physical deployment, retrieval, or positioning of modules. It does not have authority over infrastructure safety systems. Its domain is software-layer management of customer workloads and capacity on infrastructure that Seabase's operational teams manage physically.

The Software Layer for a Physical Network

The term "network" in AI infrastructure is often used loosely to mean a collection of connected services. Seabase's deployment model is a physical network in a more literal sense: distinct regional clusters connected by real fiber infrastructure, positioned near coastal cable landing stations, with geography that matters to the performance of every workload that runs on it.

Physical networks require software layers that understand their physical properties. A system that treats geographically distributed clusters as interchangeable compute pools loses the value of the geographic investment. Nori is being developed as the software layer that preserves and operationalizes the geographic specificity of Seabase's physical deployment, making it visible and actionable for customers rather than abstracting it away.

The result, when fully realized, is infrastructure that customers can reason about in terms of actual compute geography: which region is closest to their users, which hardware generation suits their current models, which clusters are available for new reservations, and how utilization is distributed across their deployment. These are the questions that matter for organizations managing real AI workloads at scale, and they are the questions Nori is designed to answer.

To discuss regional and reserved capacity options or to explore how Nori supports your deployment requirements, contact Seabase. For the infrastructure layer that Nori operates against, see the infrastructure overview. For the geographic and latency case that motivates regional placement, see The Latency Tax. For the persistent workload case that defines the reservation model's value, see Persistent Regional AI.