app-service: honor limitedGpu as the HAMi nvidia.com/gpumem cap

[mvanhorn]

Summary

Derive the HAMi nvidia.com/gpumem value the app-service admission webhook injects from the manifest's limitedGpu (the runtime cap the app may use) instead of requiredGpu (the scheduling floor), falling back to requiredGpu when limitedGpu is unset. Charts that do not set limitedGpu keep their current behavior exactly.

Background

When applications.app.bytetrade.io/gpu-inject is set, the webhook injects nvidia.com/gpumem for HAMi-managed workloads. The value was computed from requiredGpu, so a chart that sets a conservative floor such as requiredGpu: 1Gi hard-caps the container at 1 GB of VRAM and silently ignores limitedGpu: 24Gi; a larger model then fails to load with no clear signal.

requiredGpu is meant to be the scheduling minimum and limitedGpu the maximum the app is allowed to consume, so the runtime memory cap should come from limitedGpu when it is set. This mirrors the existing FitLevelLimit convention in pkg/compute/scheduler.go, where targetGPU/levelMemory already prefer LimitedGPU over RequiredGPU at the limit level and the scheduler tries that level first.

Changes

• Prefer limitedGpu (when greater than zero) over requiredGpu for the injected nvidia.com/gpumem cap, still injecting nothing when neither is positive.
• Extract the byte-to-quantity derivation into a small pure helper (hamiGPUMemoryLimit) so it is unit-testable without a live admission request.
• Add table-driven tests covering the four cases: limitedGpu > requiredGpu, limitedGpu unset (falls back to requiredGpu), both zero (returns nil), and limitedGpu == requiredGpu.

Scope is limited to framework/app-service/pkg/apiserver/handler_webhook.go and a new handler_webhook_test.go.

Testing

gofmt, go vet, go build, and go test all pass for pkg/apiserver.

Related issues

Refs #3213

Note: issue #3213 also describes a second, separate problem (a hardcoded release_early_check_interval inside the proprietary libvgpu.so). That value lives only in a compiled shared object with no source in this repository, so it is out of scope here; this PR addresses only the webhook memory-cap derivation.

---

Note

Medium Risk
Changes admission-time GPU memory limits for HAMi workloads, which affects scheduling and runtime VRAM caps; behavior is unchanged when limitedGpu is unset.

Overview
For HAMi GPU injection, the gpu-limit admission webhook now sets nvidia.com/gpumem from limitedGpu when it is positive, otherwise requiredGpu, instead of always using requiredGpu. That aligns the runtime VRAM cap with the scheduler’s FitLevelLimit behavior so a low scheduling floor no longer silently caps workloads that declare a higher limit.

The byte-to-MiB conversion moves into hamiGPUMemoryLimit, which returns nil when neither GPU field is positive (no gpumem patch). HAMi mode no longer skips that helper when only the limit path would apply—the outer check is IsHAMIMode only. Table-driven tests cover limit > required, fallback, both zero, and equal values.

^{Reviewed by Cursor Bugbot for commit 016c96f. Bugbot is set up for automated code reviews on this repo. Configure here.}

[vercel]

@mvanhorn is attempting to deploy a commit to the Lucky's projects Team on Vercel.

A member of the Team first needs to authorize it.