Unified Hardware-Assisted Multi-GPU Compute, Data, and Thermal Scheduling Infrastructure

A coordinated control architecture for workload placement HBM admission distributed data readiness QoS and thermal aware execution

Technology Concept Paper

Author: Christopher Soans
Date: September 2026

Download PDF

This paper proposes one authoritative hardware-assisted scheduling function per AI server, coordinated by cluster software. The design combines workload QoS, HBM capacity and bandwidth admission, distributed-data preparation, network-fabric coordination, power control, and thermal-aware GPU placement. It complements existing cluster schedulers, AI frameworks, runtimes, and native GPU execution schedulers rather than replacing them.

The principal conclusion is that GPU availability should be determined as a multi-resource condition. A GPU is eligible for a scheduled workload only when compute, HBM, data readiness, fabric bandwidth, power, and thermal headroom collectively support completion within the requested execution window.

Unified Hardware Assisted GPU Scheduling Infrastructure

Figure 1. Unified Hardware-Assisted Multi-GPU Compute, Data, and Thermal Scheduling Infrastructure

Executive Summary

AI clusters use several scheduling layers. Cluster software allocates nodes and accelerators, frameworks divide model computation, runtimes submit kernels and transfers, and GPU hardware dispatches blocks and warps. These layers are effective within their individual scopes, but no single local decision point necessarily combines job priority, computational dependencies, HBM pressure, fabric congestion, and thermal conditions at the speed required to exploit short execution gaps.

The proposed Unified Hardware-Assisted GPU Scheduler closes this coordination gap. Cluster software retains global policy, security, ownership, placement, and cost decisions. Each server receives one logical hardware scheduling authority that performs rapid local admission, dispatch, reservation, prefetch, throttling, and safe preemption. Dedicated DMA, collective, NVLink, PCIe, and DPU or SmartNIC engines move the data; the scheduler directs and tracks them rather than becoming a byte-transfer bottleneck.

The design could reduce otherwise unused compute time by running bounded, independent work during data or synchronization stalls. It cannot remove true computational dependencies, and it must avoid filling a short idle interval with work whose loading, context-switch, or recovery cost exceeds the available window. Its value therefore depends on accurate telemetry, explicit resource declarations, predictable preemption boundaries, and conservative admission control.

Design Objectives

Create one authoritative local scheduling decision path for compute, memory, data movement, QoS, power, and thermal constraints.
Allow software to coordinate distributed jobs across servers while hardware reacts to local state at low latency.
Admit work only when HBM capacity and performance support completion within a declared or predicted window.
Overlap useful computation with communication and synchronization when dependencies permit.
Preserve compatibility with existing cluster schedulers, AI frameworks, GPU runtimes, and native warp schedulers.
Use open descriptors and telemetry interfaces so the architecture can support multiple accelerator and fabric vendors.
Treat accelerator interconnect topology and communication locality as first-class scheduling resources so tightly coupled work remains within the smallest suitable high-bandwidth scale-up domain when practical.

Scope and Terminology

Term	Meaning in this paper
Cluster coordinator	Software control plane responsible for global policy, placement, identity, quotas, and distributed job coordination.
Unified hardware scheduler	One logical authority per server that admits and dispatches GPU work using real-time multi-resource telemetry.
Scheduled window	The interval within which a work unit is expected to start and complete, including required staging and synchronization.
Work unit	A bounded kernel group, microbatch, model stage, inference request, or other independently schedulable operation.
Data readiness	Confirmation that required inputs are available at an accessible location and all dependencies have completed.
Scale-up domain	A set of accelerators connected by the platform’s highest-bandwidth, lowest-latency local accelerator fabric. Its size and topology are discovered from hardware capabilities rather than assumed to be a fixed GPU count.

Problem Definition

A GPU may appear underutilized while it is waiting for a remote activation, gradient exchange, collective operation, or memory transfer. At the same time, that GPU may still be constrained by HBM occupancy, HBM bandwidth, network traffic, power, or temperature. Compute utilization alone therefore cannot establish whether another job can run safely.

Fragmented scheduling decisions

Current layer	Information available	Typical limitation
Cluster scheduler	Nodes, accelerators, quotas, queue priority, topology	Often allocates whole GPUs or large partitions and does not react to microsecond or millisecond execution gaps.
AI framework	Model graph, dependencies, parallelism strategy	Understands computation but has incomplete direct control of local thermal and memory-controller state.
Runtime and driver	Kernels, streams, allocations, transfers	Operates near hardware but may lack business priority, deadlines, and cluster-wide placement context.
Native GPU scheduler	Ready blocks, warps, execution units	Makes excellent local dispatch decisions but does not normally understand complete job intent or distributed deadlines.
Thermal controls	Temperature, clocks, fans, power limits	Protect hardware but can throttle execution without optimizing job placement around the resulting capacity change.

Design gap

The architecture needs a policy-aware mechanism close enough to the hardware to act on short-lived resource conditions, while retaining a software control plane capable of reasoning about tenants, service levels, costs, dependencies, and the wider cluster. Separate workload and thermal schedulers should not issue competing placement instructions. Thermal control instead becomes one input and enforcement domain within the unified local scheduler.

Proposed Architecture

The proposed system uses a hierarchical control model. Cluster software communicates job intent and resource policy to one logical hardware-assisted scheduler in every AI server. The local scheduler coordinates GPU execution, HBM reservations, data-movement engines, and thermal and power controls. An AI Intelligence and Control Network carries policy, readiness signals, and telemetry; the high-bandwidth data fabric carries model data and collective traffic.

Architecture layers

Layer	Primary responsibility	Representative outputs
Cluster software control plane	Global placement, identity, quotas, QoS, dependency graphs, geographic and power policy	Job descriptors, server assignments, deadlines, resource budgets
Unified server hardware scheduler	Local admission, reservations, priority queues, window scheduling, preemption and enforcement	GPU selection, dispatch order, HBM reservation, transfer commands
Data and collective engines	DMA, RDMA, NVLink, PCIe and collective execution	Prefetched inputs, completion events, collective results
GPU execution layer	Native kernel, block and warp scheduling	Completed calculations and hardware counters
Telemetry and safety layer	Temperature, HBM health, power, cooling, errors and congestion	Headroom estimates, alarms, throttling constraints

One logical scheduler with specialized internal engines

One scheduler does not require one monolithic circuit. It means that all local placement and admission decisions pass through a single policy authority. Specialized hardware engines may operate in parallel under that authority.

Internal engine	Function
Workload and QoS	Maintains priority classes, deadlines, fairness, reservations, and time-slice rules.
Dependency and readiness	Tracks predecessor completion, input availability, and collective membership.
HBM resource	Tracks capacity, bandwidth, controller pressure, fragmentation, locality, and temperature.
Data movement	Issues and observes DMA, RDMA, NVLink, PCIe, and collective transfers.
Thermal and power	Applies device, GPU-bank, cooling-zone, chassis, and power constraints.
Placement and admission	Scores candidate GPUs and commits atomically reserved resources.
Safety and recovery	Enforces hard limits, detects deadline risk, and triggers throttling, pause, retry, or escalation.
Topology and locality	Maps accelerator, HBM, NIC/DPU, switch, and scale-up/scale-out relationships; scores communication locality and identifies interconnect-domain boundaries.

End to End Scheduling Workflow

The cluster coordinator first converts an application request or training stage into bounded work units. Each unit includes policy, resource estimates, dependency metadata, and a preemption contract. The local scheduler then validates the request against current and predicted resource state before admitting it.

Step	Action	Decision owner
1	Classify the job by tenant, priority, deadline, cost policy, and security context.	Cluster software
2	Divide eligible work into kernels, kernel groups, microbatches, inference requests, or model stages.	Framework and runtime
3	Identify dependencies, required data, estimated compute, HBM, fabric, power, and thermal demand.	Framework and profiler
4	Choose candidate servers and accelerator domains using topology, data locality, policy, communication intensity, and available capacity.	Cluster software
5	Evaluate local compute, HBM capacity and bandwidth, data readiness, scale-up-domain fit, interconnect path, thermal state, and scheduled window.	Unified hardware scheduler
6	Atomically reserve required resources and initiate prefetch or collective preparation.	Unified hardware scheduler
7	Dispatch when dependencies and data are ready; fill safe gaps with eligible secondary work.	Unified hardware scheduler
8	Report completion, measured demand, deadline outcome, errors, and updated resource state.	Hardware telemetry to software

Work unit descriptor

Field group	Illustrative fields
Identity and policy	Job ID, tenant, security domain, priority class, deadline, fairness weight
Execution	Estimated duration, compute profile, eligible GPU types, kernel group, checkpoint boundary
Memory	HBM capacity, average and peak bandwidth, workspace, locality, persistence and eviction policy
Data and fabric	Input locations, transfer volume, collective type, communication intensity, scale-up-domain affinity, topology constraints, bandwidth and latency budget, and permitted scale-out boundaries
Control	Preemptible flag, maximum pause latency, retry policy, migration eligibility, completion event
Environment	Power ceiling, thermal limit, cooling-zone affinity, reliability requirement

HBM Aware Admission and Window Scheduling

HBM availability is not a single free-capacity value. A job can fit physically and still miss its deadline because the active workload has saturated memory bandwidth or particular memory controllers. The scheduler must evaluate both memory capacity and memory serviceability during the requested window.

Required HBM telemetry

Metric	Scheduling use
Allocated, reserved, and reclaimable capacity	Determines whether weights, activations, KV cache, workspace, and outputs can coexist.
Read and write bandwidth	Estimates whether concurrent memory traffic permits on-time completion.
Controller utilization and queue depth	Reveals local pressure hidden by aggregate bandwidth figures.
Cache hit and miss behavior	Estimates additional HBM traffic and interference.
Fragmentation and allocation latency	Determines whether usable regions can be committed within the window.
HBM temperature and error counters	Protects performance, reliability, and data integrity.
Page movement, eviction, and locality	Detects thrashing and quantifies the cost of staging or displacement.

Admission rule

A work unit is admitted only when hard constraints are satisfied and its predicted completion risk remains below policy. In conceptual form:

Admit = Capacity Fit AND Bandwidth Fit AND Data Ready by Start AND
Compute Available AND Topology Fit AND Interconnect Available AND
Thermal Safe AND Deadline Feasible

The scheduler reserves resources atomically after admission. Capacity reservation prevents another process from consuming memory before execution. Bandwidth and fabric reservations may be enforced as budgets or priority weights rather than absolute partitions, depending on the hardware.

Short future resource calendar

Window	HBM state	Fabric and thermal state	Example decision
Now to 2 ms	Capacity available; bandwidth highly utilized	Collective active; GPU warm	Reject opportunistic work
2 to 6 ms	Capacity reserved; moderate bandwidth headroom	Fabric clearing; stable temperature	Admit short memory-light inference
6 to 14 ms	Model data resident; high bandwidth headroom	Cooling margin available	Run scheduled microbatch
After 14 ms	Capacity uncertain	Higher-priority stage expected	Hold capacity or admit only rapidly preemptible work

Topology-Aware Compute Locality and Interconnect Domains

Accelerators with equivalent compute capacity and HBM should not automatically be treated as equivalent placement targets. A tightly synchronized workload can perform very differently depending on whether its participating GPUs communicate within one high-bandwidth scale-up domain or must cross a scale-out network. The scheduler should therefore model accelerator topology as a resource alongside compute, HBM, power, and thermal headroom.

The design must not encode a fixed boundary such as 72 GPUs. Current rack-scale systems may expose domains of that general size, but domain size is an implementation characteristic rather than a universal limit. The scheduler discovers the platform topology and capabilities at runtime. A domain may use NVIDIA NVLink/NVSwitch, AMD scale-up interconnects, UALink-compatible technology, or another vendor or standards-based fabric. The scheduling abstraction remains the same: identify the fastest communication domain and quantify the cost of crossing its boundary.

Scheduling principle

Latency-sensitive and communication-intensive workloads should preferentially remain within the smallest suitable accelerator domain that satisfies their compute, HBM, reliability, and deadline requirements. The scheduler may span domains when a workload cannot fit locally or when the workload is sufficiently loosely coupled that additional scale-out communication does not materially harm its service objective.

Topology signal	Scheduling interpretation
Scale-up domain membership	Prefer co-placement of tightly coupled stages within the same highest-bandwidth accelerator domain.
Accelerator-to-accelerator bandwidth and latency	Estimate communication cost for tensor, pipeline, expert, and collective parallelism.
Collective communication pattern	Account for AllReduce, AllGather, ReduceScatter, All-to-All, and other synchronization traffic before placement.
Scale-out boundary crossings	Treat Ethernet, InfiniBand, or other inter-domain paths as a distinct communication tier with its own latency, congestion, and bandwidth budget.
GPU-to-NIC/DPU locality	Prefer paths that minimize PCIe or fabric hops for RDMA and inter-server communication.
HBM and model-state locality	Avoid unnecessary movement of weights, activations, KV cache, expert state, or checkpoints when a suitable local domain is available.
Topology health and congestion	Reduce affinity to degraded or congested links even when nominal accelerator capacity is available.

Application and framework hints

The AI framework can provide communication-intensity and parallelism hints, but the infrastructure scheduler remains responsible for validating them against actual topology and telemetry. For autoregressive inference, a latency-critical model stage should avoid unnecessary inter-domain dependencies when they would place scale-out communication on the token-generation critical path. Training and mixture-of-experts workloads may legitimately span many domains, but placement should account for their collective or expert-communication patterns rather than considering only the number of free GPUs.

Topology-aware admission extends the earlier multi-resource rule: a GPU is available only if the required group of accelerators, memory, data, interconnect bandwidth, and synchronization path can be committed for the scheduled window. A cluster reporting 120 free GPUs therefore does not necessarily provide a 120-GPU tightly coupled resource; the scheduler must know how those GPUs are distributed across communication domains.

Distributed Data Coordination

The scheduler should coordinate data movement for GPUs, but dedicated engines should move the bytes. This separation prevents the scheduler from becoming a throughput bottleneck and leaves matrix and tensor units focused on computation.

Component	Role
GPU compute engines	Execute model calculations after readiness is confirmed.
Unified hardware scheduler	Plans transfers, reserves destinations, tracks dependencies, and releases ready work.
DMA and copy engines	Move data between host memory, local HBM, and accelerator memory.
NVLink or equivalent fabric	Moves data among local accelerators and memory domains.
DPU or SmartNIC	Handles RDMA, transport, isolation, security processing, and inter-server movement.
Collective engine or library	Executes AllReduce, AllGather, ReduceScatter, Broadcast, and related operations.

Data readiness sequence

Reserve the destination HBM region and required bandwidth budget.
Validate that all producer operations are complete or scheduled to complete before the required start.
Issue local or remote prefetch through the appropriate copy, fabric, DPU, or collective engine.
Receive hardware completion events and validate integrity and security metadata.
Mark the dependent work unit ready without requiring a round trip to cluster software.
Dispatch immediately if its compute, QoS, thermal, and power reservations remain valid.

Limits of data orchestration

A scheduler cannot eliminate a true dependency. If a required partial result has not yet been calculated, the dependent operation must wait. The scheduler can pre-position available inputs, prioritize the missing transfer, select another ready operation, and avoid unnecessary copies. Its benefit is reduced coordination overhead and better overlap, not removal of causality.

Thermal Power and Cooling Integration

The existing AI Thermal-Aware GPU Scheduling Infrastructure becomes the thermal, cooling, and power domain of the unified scheduler. This preserves its monitoring and GPU-bank rotation concepts while preventing a second scheduler from competing for control of the same resources.

Thermal-aware decisions

Condition	Unified response
GPU approaching sustained thermal threshold	Redirect the next eligible work unit to a cooler GPU or GPU bank.
HBM temperature rising faster than core temperature	Reduce memory-intensive concurrency while permitting suitable compute-heavy work.
Cooling zone near capacity	Limit aggregate server placement in that zone and notify cluster software.
Power cap constraining clocks	Recalculate completion estimates before admitting deadline-sensitive work.
Alternating GPU banks available	Drain one bank at a safe boundary while another carries eligible work.
Sensor fault or thermal anomaly	Enter a conservative safe state and escalate through the control network.

Thermal conditions should be treated as hard constraints when safety or reliability is involved and as optimization costs when the system remains within its validated operating envelope. Job priority must never override a hardware safety limit.

Quality of Service and Opportunistic Execution

The network QoS analogy is useful when applied carefully. Software establishes classes, reservations, and policy; local hardware classifies ready work, selects queues, and dispatches within those limits. GPU work differs from packets because it may carry large resident state and may not be quickly movable or preemptible.

Class	Representative workload	Treatment
Real time	Interactive voice or safety-related inference	Reserved resources, strict latency budget, immediate readiness signaling
High	User-facing inference and urgent analytics	Low-latency queue, protected bandwidth, controlled preemption
Medium	Batch inference and routine analytics	Weighted service using available reserved capacity
Low	Training, preprocessing, cache generation	Deferrable, gap-filling, and preemptible at declared boundaries

Safe gap filling

A secondary work unit should run during a synchronization stall only when its complete cost fits the predicted opening. The estimate must include context preparation, data staging, execution, completion handling, cache effects, and the time needed to yield resources back to the primary workload.

Prefer work whose model state or operands are already resident.
Use bounded kernels or microbatches with known completion or preemption points.
Reserve HBM and fabric resources needed by the primary job before admitting secondary work.
Apply a safety margin to predicted synchronization windows.
Decline work when uncertainty or cleanup cost could delay the primary job.

Control Networks and Interfaces

The AI Intelligence and Control Network should carry compact policy and telemetry rather than model payloads. This keeps the control path responsive during heavy training or collective communication and supports independent troubleshooting and security enforcement.

Control network traffic	High bandwidth data fabric traffic
Job descriptors and priority policy	Model weights and activations
Dependency and readiness events	Gradients and collective payloads
Compute, HBM, thermal, power, and error telemetry	Training data and generated outputs
Reservations, throttling commands, and health state	Checkpoint and large cache transfers
Audit, accounting, and scheduler synchronization	Bulk replication and storage movement

Open interface model

A standardized descriptor and telemetry contract would allow cluster software to express intent without depending on one accelerator vendor. Vendor-specific implementations could translate the common contract into their local queues, memory controls, copy engines, and telemetry counters. Version negotiation and capability discovery should allow firmware upgrades and backward-compatible deployment.

Failure Handling Security and Governance

Risk	Required control
Incorrect resource estimate	Measure actual demand, apply margins, revise future profiles, and stop further admissions when deadlines are at risk.
Scheduler or firmware fault	Fail to a conservative mode that preserves active reservations and permits controlled software recovery.
Control-network interruption	Continue already authorized local work within leases; block untrusted new work; reconcile after recovery.
Tenant data exposure	Enforce memory-domain isolation, secure erase or reuse controls, and authenticated descriptors.
Priority abuse or starvation	Apply authorization, quotas, aging, fairness weights, and auditable override policy.
Thermal sensor failure	Use redundant signals where possible and select conservative power and placement limits.
Data or collective timeout	Retry within policy, execute independent work, or escalate to cluster re-placement without silently violating consistency.

The hardware scheduler should receive signed or otherwise authenticated policy from trusted cluster software. It should not decide user entitlement, geography, or pricing independently. Its task is to enforce authorized policy against measurable local resources.

Compatibility and Deployment Path

The architecture is intended to complement existing systems. A staged rollout can begin with advisory telemetry and progressively add enforcement as hardware, drivers, and frameworks expose the required controls.

Phase	Capability	Change scope
1 Observe	Unified telemetry for compute, HBM, fabric, thermal, power, and errors	Firmware and driver reporting; no autonomous dispatch changes
2 Recommend	Hardware produces placement and admission recommendations	Cluster and runtime integrations consume advisory scores
3 Reserve	Enforced HBM, bandwidth, power, and priority reservations	Command descriptors, queues, and admission contracts
4 Coordinate	Prefetch, readiness tracking, collective coordination, and safe gap filling	Framework dependency metadata and DPU or fabric events
5 Optimize	Predictive windows, cross-server learning, and closed-loop tuning	Mature profiles, validation, governance, and multi-vendor standards
Interconnect-domain locality and cross-domain traffic	Measures whether tightly coupled work remains within suitable scale-up domains and quantifies communication cost when scale-out is required.

Backward compatibility

Unmodified workloads continue through the existing scheduler path with a default policy class.
Unsupported descriptor fields are rejected or ignored according to negotiated version rules, never interpreted ambiguously.
Hardware capabilities are discovered before placement so software avoids requesting unsupported isolation or preemption behavior.
Firmware upgrades can add telemetry and queue features without forcing immediate replacement of cluster software.
The system can operate in advisory mode when a GPU or server lacks enforcement support.

Evaluation Framework

The proposal should be validated against utilization, service quality, energy, thermal stability, and isolation. Higher raw utilization is not sufficient if it increases tail latency or collective jitter.

Measure	Purpose
Useful GPU compute utilization	Quantifies recovered execution time rather than merely device occupancy.
Synchronization bubble duration	Shows whether ready independent work reduces idle intervals.
Deadline success and tail latency	Protects real-time and high-priority service quality.
HBM capacity and bandwidth contention	Detects oversubscription, thrashing, and memory-controller pressure.
Collective completion variance	Ensures secondary work does not create new stragglers.
Data staging overhead	Tests whether prefetch and migration costs are justified.
Energy per completed unit of work	Measures efficiency rather than instantaneous power alone.
Temperature and throttling time	Evaluates thermal placement and GPU-bank rotation.
Preemption and recovery latency	Determines which work units are safe for gap filling.
Fairness and isolation	Confirms that priorities do not cause unauthorized starvation or interference.

Recommended experiments

Compare whole-GPU allocation with HBM-aware multi-resource admission under mixed training and inference.
Inject controlled collective delays and measure whether bounded secondary work increases useful throughput without increasing primary-job tail latency.
Test capacity-only admission against capacity-plus-bandwidth admission.
Evaluate thermal-aware placement during sustained memory-intensive workloads and alternating GPU-bank operation.
Measure control-loop behavior during telemetry loss, DPU failure, stragglers, and inaccurate execution estimates.
Validate isolation across tenants and across GPU partitions where supported.
Compare topology-blind placement with topology-aware placement for tensor-parallel, pipeline-parallel, collective-heavy, and autoregressive inference workloads.
Measure token latency, collective completion time, and useful throughput when a workload fits within one scale-up domain versus when it crosses one or more scale-out boundaries.
Validate capability discovery across different accelerator fabrics so scheduling policy does not depend on a fixed GPU count or one vendor-specific interconnect.

Benefits Limitations and Risks

Potential benefit	Qualification
Higher useful GPU utilization	Realized only when eligible work fits the complete opening, including staging and yield cost.
Reduced data-wait overhead	Prefetch helps only when dependencies and future data requirements are known early enough.
Improved deadline predictability	Requires accurate profiles, reservations, and conservative handling of contention.
Lower thermal throttling	Depends on sufficient placement alternatives and cooling headroom.
Unified control	One logical authority reduces conflicts but must avoid becoming a local single point of failure.
Better multi-tenant efficiency	Increases the importance of memory, cache, timing, and fabric isolation.

Principal technical risks

Fine-grained GPU preemption may be limited to safe kernel or microbatch boundaries.
Execution and bandwidth estimates may vary with model shape, batching, cache behavior, and competing traffic.
Moving an active workload or its state may cost more than waiting for the original GPU.
Additional hardware queues and monitoring logic consume silicon, power, verification effort, and firmware complexity.
Cross-vendor telemetry semantics and enforcement capabilities may initially differ.
Aggressive utilization targets can produce worse tail latency, collective jitter, or thermal cycling.
Topology-aware placement can create fragmentation: preserving contiguous high-bandwidth domains for future tightly coupled jobs may leave individually idle GPUs that are less useful for communication-intensive workloads.

Conclusion

A unified Hardware-Assisted GPU Compute, Data, and Thermal Scheduling Infrastructure is a credible extension to current AI cluster design. Its strongest form is hierarchical: software coordinates jobs and policy across servers, one logical hardware scheduling authority controls local admission and dispatch, and existing GPU, HBM, DMA, collective, fabric, and thermal mechanisms perform specialized work.

The design should define GPU availability as a multi-resource commitment rather than a free-compute observation. HBM capacity, HBM bandwidth, data readiness, interconnect availability, power, temperature, and the scheduled completion window must all be validated before work begins. This is particularly important when using short synchronization gaps for secondary computation. Accelerator topology and communication locality are part of that commitment: nominally free GPUs should not be treated as interchangeable when a workload would have to cross a slower scale-out boundary to use them together.

The scheduler cannot remove genuine dependencies, but it can prepare data earlier, select other ready work, reserve the resources needed by the primary job, and coordinate a faster local response than cluster software alone. A staged, backward-compatible implementation beginning with standardized telemetry and advisory decisions would provide the safest path toward hardware-enforced QoS and predictive execution-window scheduling.

This work is licensed under a Creative Commons Attribution 4.0 International License (CC BY 4.0).