21 lines
1.4 KiB
Markdown
21 lines
1.4 KiB
Markdown
# Placement Explainability
|
|
|
|
`PlacementPlan` is the first-class explanation for both a dry-run and a real request. Both paths call
|
|
the same planner. A plan records the requested capability/deployment, node and accelerator,
|
|
eligibility, priority, current residents, external use, reserve, authoritative envelope requirement,
|
|
headroom before and after, selected managed evictions, queue impact, verdict and typed reasons.
|
|
|
|
Verdicts are `ADMIT`, `ADMIT_AFTER_EVICTION`, `QUEUE`, `REJECT_CAPACITY`, `REJECT_HEALTH`, and
|
|
`REJECT_POLICY`. Reason codes include `INSUFFICIENT_SCHEDULABLE_VRAM`, `EXTERNAL_GPU_PRESSURE`,
|
|
`RESIDENCY_CONFLICT`, `EVICTION_NOT_ALLOWED`, `DEADLINE_CANNOT_BE_MET`, `LEASE_CONFLICT`,
|
|
`GPU_MEMORY_NOT_RECLAIMED`, and `SCHEDULER_STATE_STALE`.
|
|
|
|
The operator dry-run answers “what if I invoke this capability now?” without loading a model. The UI
|
|
shows the actual budget, pressure, residency, possible eviction, expected reclaimed bytes, cold-load
|
|
cost and final reasons. Recent placement history is capped at 500 records. It contains safe request
|
|
shape metadata only—never text, image, audio or client-supplied placement commands.
|
|
|
|
Co-residency arithmetic yields at most `EXPECTED_SAFE`. `PROVEN_SAFE` requires two exact residents
|
|
on the same worker generation, KNOWN attribution and a measured combined footprint. Promotion and
|
|
scheduling readiness remain separate lifecycle decisions.
|