Get an accelerator
Returns one accelerator held by the tenant selected by the X-CostGraph-Tenant-ID header: its model, vendor and provider, where it sits, its cost_summary where the catalog prices it, whether it is carved into MIG partitions with how many of them ran no compute, its compute and memory utilisation, its MIG partitions with the ones that ran no compute marked idle, and reports carrying every measurement recorded against it with a row per partition where the card is carved up. Every measured field is null rather than zero where nothing was measured, and every field the card also carries in the list carries the same name and the same value here. placement says where the accelerator sits and carries the ids a caller links on: placement.instance_id always, and placement.cluster_id, placement.node_id and placement.node_name where the machine is a Kubernetes node we hold, which is also what makes placement.kind workload rather than instance. cost_summary carries the currency every amount is in, and the hourly and projected monthly rate the catalog prices the card at; mtd and change_percent are always null with mtd_reason saying why, since spend to date is billed for the whole machine, so it is never attributed to one accelerator and never rendered as zero. A uuid the tenant has never reported gets a 404, and the accelerators on a machine that have not reported are only ever counted in the list’s aggregate item, so they have no detail of their own. Where the same uuid has reported against more than one machine, the card the list ranks first wins and its reports are the ones from that same machine; filter the list by instance_id to reach the others. serving names the model-serving deployment running on the card, resolved from the pod the accelerator itself reports rather than from any name: serving.deployment_id is set only in state resolved, and addresses the same deployment /ai/deployments lists, so its serving series can be read from /ai/deployments//metrics. Every other state leaves deployment_id null and says why in serving.reason - shared when more than one serving deployment holds the card, not_serving when the pod holding it serves no model, unheld when no pod reported against it, partitioned when the card is carved up and its partitions report no pod, and unavailable when the lookup could not be made at all, which includes a card whose machine is not a Kubernetes node we hold. serving_holders carries every holder of the card rather than the single one serving resolves to, so a shared card can be charted in full. Each holder is named the way its placement names it: a card on a Kubernetes node we hold names its holders by namespace, pod and container with process_name and process_id null, and a card on any other machine names them by the process on the host, carrying process_name and process_id with namespace, pod and container null. mig_instance_id names the partition the holder occupies and is null where the holder holds the whole card. deployment_id and deployment_name are set only where the holder is a model-serving deployment we measure, and address the same deployment /ai/deployments lists. A card nothing holds carries an empty list rather than null, with serving.reason saying why.
Authorizations
Enter "Bearer {token}"
Headers
Tenant ID
Path Parameters
Accelerator UUID as the device reports it