How Developers Can Request Compute Without Manual Provisioning

Developers can request compute resources without manual infrastructure provisioning by submitting an approved resource specification through a workflow that checks project ownership and quota, schedules healthy compatible resources, provisions the required environment, and records the resulting allocation and usage.

The source materials already separate what the user asks for from the physical infrastructure that delivers it. The user requests a standard resource specification, and the scheduler handles heterogeneous GPU and NPU resources. The workflow handles approval, while bare-metal automation handles operating system, drivers, monitoring, and cluster registration where required.

What should a developer request?

The developer should request the resource capability needed by the workload. The source scheduling model uses standardized specifications that can include:

• Accelerator type
• Accelerator count
• CPU
• Memory
• Whole-card resource
• Sliced resource

That is much better than asking a developer to choose a server serial number, BMC address, rack, or specific GPU card. Those physical details belong to infrastructure operations. The developer describes the workload requirement, and the platform translates that requirement into a placement on healthy infrastructure.

Why are standard resource specifications important?

They create a stable contract between developers and infrastructure. The source platform manages heterogeneous accelerator vendors and models, and without a standard specification layer every request can become hardware-specific. Users then need more infrastructure knowledge, scheduling becomes harder, cost comparison becomes inconsistent, and automation becomes more fragile.

A standard resource class lets the developer ask for an approved capability while the platform retains the detailed compatibility rules underneath.

For heterogeneous scheduling, how can enterprises manage GPUs and NPUs from multiple vendors in one platform explains why abstraction and vendor-specific detail need to coexist.

How should the request identify ownership?

Every request should carry tenant and project context. The source operations model treats multi-tenancy as both a people and compute problem. Project identity is required for:

• Quota
• Task ownership
• Metering
• Cost
• Token allocation
• Audit

Assigning ownership after the workload finishes doesn't work well. The request should begin with the project, which gives the scheduler and cost system the same identity from the start.

How should quota be checked?

Quota should be checked before the request is admitted to normal scheduling. The source Q&A says quota can include:

• GPU quantity
• Accelerator memory
• CPU and memory
• Concurrent tasks
• Monthly card hours

The exact policy depends on the enterprise. If the developer asks for more than the approved project limit, the system should return a clear reason, and the request can then be reduced, wait for a quota change, or enter an approval process. The developer should not need to email the infrastructure team to discover which limit was exceeded.

How should approval work?

Approval should be part of the resource-request workflow. The source workflow engine supports dynamic approvers and multi-level approval, and a request can route based on:

• Project
• Role
• Manager
• Form field
• Resource type

The source does not define one mandatory approval chain, so it should be configured according to cost and risk. A routine development resource inside quota may need little or no manual approval, while a large production request may need additional review. The workflow should pass the same approved parameters to execution afterward.

How does the request enter the scheduler?

After authorization, the request becomes a schedulable workload or resource task. The source scheduler manages:

• Queue
• Quota
• Priority
• Preemption
• Resource specification
• Health
• Resource allocation
• Reclamation

The scheduler then selects compatible healthy resources. If no suitable resource is currently available, the request remains visible in the queue, and the queue should show why, because "no resource" can mean several different things.

What queue reasons should the developer see?

The source materials require waiting reasons to be visible. Useful reasons include:

• Quota exhausted
• Matching resource specification unavailable
• Healthy capacity insufficient
• Higher-priority tasks ahead
• Topology constraint
• Resource fragmentation

This transparency reduces unnecessary support tickets, since the developer can tell whether the issue is policy, capacity, scheduling, or health.

For quota, priority, and preemption, what are GPU quotas, reservations, priorities, and preemption, and when should each be used explains how those controls differ.

How does health-aware placement help developers?

It prevents the developer's new workload from being assigned to known degraded hardware. The source scheduler uses card-level health as an input, and degraded cards can be isolated before new work is scheduled, so "available" should mean operationally usable.

This reduces repeated workload failure and the manual back-and-forth that follows. The developer does not need to interpret ECC errors or BMC alarms, because the infrastructure health system handles that part of the resource decision.

How does bare-metal provisioning fit into the request?

Some compute requests need a complete physical server rather than a container or existing cluster resource. The source bare-metal delivery model automates:

• Hardware validation
• Operating system installation
• GPU driver
• Monitoring Agent
• Cluster registration
• Post-install health check

A developer can therefore request an approved bare-metal service profile. After approval and allocation, the workflow can trigger provisioning, and the result returns to the same request record.

For the detailed sequence, how automated bare metal provisioning works for physical servers, operating systems, GPU drivers, and monitoring agents explains the source-supported flow.

How should software images be controlled?

The request should choose from approved images or templates where the source platform provides them. The source deployment model emphasizes templates and standardized delivery, which reduces one-off manual environment creation. A developer should not need an operator to reinstall the same approved software stack every time.

The organization can control:

• Operating system
• Driver
• Monitoring
• Runtime
• Approved configuration

The source does not define a full developer image catalog schema. Its principle is to standardize repeatable delivery artifacts and connect them to the automation workflow.

How should resource allocation be returned to the developer?

The request should be updated with the delivered resource information. The source workflow design writes execution results and resource information back into the work order, which makes the request the record of delivery. The developer can see:

• Request status
• Allocated resource
• Start time
• Resource specification
• Queue history
• Usage
• Expiry or return state

The infrastructure team sees the same record from the operations side, and nobody has to send a separate email confirmation.

How should usage be metered?

Once the resource is allocated, the source metering model can record:

• Card hours
• Project
• Tenant
• Accelerator type
• Energy
• Token usage where applicable

That gives the developer or project owner visibility into consumption and lets the organization compare requested capacity with actual use. If a project repeatedly requests large resource blocks but uses them lightly, the operations team can recommend a different standard specification.

How should resources be returned?

Resource reclamation should be part of the lifecycle. The source scheduler includes allocation and reclamation, so when the task completes or the approved reservation ends, the resource should return to the pool.

The platform should also clear stale logical allocations. A physically free GPU that remains logically attached to an old task creates artificial capacity loss. Self-service provisioning is only complete when self-service release works too.

How should developers request model-serving capacity?

The same pattern can extend to MaaS. An authorized user can choose:

• Approved model
• Deployment template
• Resource specification
• Project
• Service parameters

The platform creates the inference instance and publishes the service through the gateway, so the developer receives a service endpoint rather than raw infrastructure. That can suit application teams that need AI capability but do not need to manage the underlying GPU allocation directly.

What should remain under operator control?

Physical infrastructure policy and high-risk operations should remain controlled. Developers should not automatically receive permission to:

• Change firmware
• Modify fabric configuration
• Change global quotas
• Edit other projects
• Override health isolation
• Control facility power or cooling

The source governance model uses least privilege and approval for sensitive operations. Developer self-service should simplify delivery while preserving those boundaries.

What does a good request experience look like?

The developer should be able to select a standard compute service, choose approved parameters, and see quota and cost context before submitting. After that, they should see approval if required, queue status and its reason, receive the allocated resource or endpoint, follow their usage, and release the resource when done. The infrastructure team should see the same lifecycle from the operations side.

A platform example that combines standardized resource requests, quotas, scheduling, automation, and usage records is Sensaka.

If I were reducing manual provisioning, I would measure how many developer requests still require an operator to copy information from one tool into another. Every repeated handoff is a candidate for workflow automation. The goal is to eliminate unnecessary re-entry while keeping governance in place.