In this article
Successful GPU management discovery is one check; compute, model readiness and request behavior need their own evidence.
Discovery is one layer of readiness
A management utility can identify an Intel GPU and report telemetry while the intended model service remains unable to run. Hardware discovery, compute-runtime access, engine compatibility, model loading and API behavior are separate checks. A successful inventory query is useful evidence at the management layer; it is not an inference acceptance test.
The Intel XPU Manager repository provides the project and management-tool context. Record the actual installed package and execution environment rather than assuming a command shown in a different release has the same fields or support on the current node.
Preserve identity and query coverage
Keep host, device identity, PCI information where exposed, tool release and relevant driver-stack information with the observation. Record supported values, unsupported features and query failures separately. A missing health field should not become a healthy result simply because the utility could enumerate the device.
The project release notes demonstrate why version context matters. For example, release 2.3.0 documents a Level Zero version requirement for reading and configuring health status. Other management operations can still work when that feature is unsupported. Apply the requirement for the installed release rather than promoting the example into a permanent rule for every version.
Check the compute path independently
Next use the selected runtime and engine’s documented compatibility information for the exact GPU and software combination. Preserve a small compute check separately from management discovery. Do not assume that a familiar NVIDIA launch command, CUDA package or device-selection variable describes the Intel execution path.
If the compute check fails while management succeeds, the result narrows the layer to investigate. It does not prove that the physical accelerator is defective. Driver dependencies, permissions, device exposure and engine support need their own evidence, especially when the service runs inside a container with a different environment from the host shell.
Validate the actual model service
Load a pinned, compatible model artifact under bounded conditions, then check readiness and a small request with defined completion behavior. Keep initialization, first-response and steady-work observations separate. A successful low-level operation cannot establish tokenizer behavior, model quality or the full application API contract.
An illustrative acceptance record may contain management discovery passed, one telemetry field unsupported and model loading failed. Those are three valid findings that should remain visible. Replacing them with one global GPU failed label discards the distinction needed for a useful investigation.
Version the telemetry interpretation
Review metric definitions when upgrading xpu-smi or the collector. Release notes can change how utilization, memory and errors are attributed or reported. Preserve raw values and the tool version so comparisons do not silently join different meanings under one chart label.
The final record should contain a layered checklist with device discovery, metric coverage, compute execution, model readiness and request validation. Each row names its own result and evidence. This establishes what the node actually demonstrated without turning a visible GPU into a promise of a production-ready LLM service.
When one layer changes, repeat the affected checks and retain the change boundary beside the earlier result.