Skip to content

feat(output): add --show-gpu-ratios (vCPU/GPU, RAM/GPU columns) - #154

Merged
scttfrdmn merged 1 commit into
mainfrom
feat/51-vcpu-per-gpu
Aug 19, 2026
Merged

feat(output): add --show-gpu-ratios (vCPU/GPU, RAM/GPU columns)#154
scttfrdmn merged 1 commit into
mainfrom
feat/51-vcpu-per-gpu

Conversation

@scttfrdmn

Copy link
Copy Markdown
Contributor

Summary

find/search show vCPUs and GPUs as separate columns, so seeing whether an instance can actually feed its accelerators requires computing vCPU/GPU by hand across two columns. For CPU/IO-bound ML workloads (data prep or I/O-heavy inference where the GPU sits mostly idle) that ratio is the decisive spec, not the raw GPU count — the issue's own motivating example: g5.4xlarge (16 vCPU / 1 GPU = 16.0) vs g5.12xlarge (48 vCPU / 4 GPUs = 12.0). The naive "4 GPUs → 4x throughput" reading of the separate columns is backwards: the bigger box actually starves each GPU more.

Adds TableOptions.ShowGPURatios, wired to a new --show-gpu-ratios flag on both find and search. Renders two additional columns (vCPU/GPU, RAM/GPU) alongside the existing GPUs/GPU Model/VRAM columns, computed from data already present in InstanceTypeResult — no new API calls. A fractional GPU (GPUs==0, GPUPartitionSize>0, e.g. g6f.large — a time-sliced L4 partition) renders - for both rather than dividing by a fractional count: that row is a shared slice of one GPU, not a caller-controlled resource-feeding ratio, so the number would look precise but answer no real question.

Verification against live AWS

us-east-1, --show-price --show-gpu-ratios:

g5.4xlarge   → vCPU/GPU 16.0, RAM/GPU 64.0   (matches the issue's own table exactly)
g5.12xlarge  → vCPU/GPU 12.0, RAM/GPU 48.0   (matches the issue's own table exactly)
g6f.large    → vCPU/GPU  -,   RAM/GPU  -     (fractional GPU, correctly dashed)

Test plan

  • New tests in pkg/output/printer_test.go: TestPrintTable_ShowGPURatios_MotivatingExample (reproduces the issue's own g5.4xlarge/g5.12xlarge numbers), TestPrintTable_ShowGPURatios_RAMPerGPU, TestPrintTable_ShowGPURatios_FractionalGPUShowsDash, TestPrintTable_ShowGPURatios_NonGPURowShowsDash, TestGPURatioDisplay (pure-helper boundary cases: zero memory, zero GPUs), TestPrintTable_ShowGPURatios_Default (columns are opt-in — absent without the flag).
  • Confirmed regression: stashing pkg/output/printer.go makes go vet fail to compile the new tests (unknown field ShowGPURatios) — the tests cannot pass without the fix.
  • go build ./..., go vet ./..., go test ./... all green
  • golangci-lint run ./cmd/... ./pkg/output/... — only pre-existing findings in untouched code (app.go, gendocs.go, root.go, and one unrelated printer.go helper), none in the new code
  • make check-docs clean (regenerated docs-gen/find.md and docs-gen/search.md for the new flag)
  • CHANGELOG.md updated under ## [Unreleased]

Fixes #51

@codecov

codecov Bot commented Aug 19, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 90.90909% with 2 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
cmd/find.go 66.66% 1 Missing ⚠️
cmd/search.go 50.00% 1 Missing ⚠️

📢 Thoughts on this report? Let us know!

find/search show vCPUs and GPUs as separate columns, so seeing whether
an instance can actually feed its accelerators requires computing
vCPU/GPU by hand across two columns. For CPU/IO-bound ML workloads (data
prep or I/O-heavy inference where the GPU sits mostly idle) that ratio
is the decisive spec, not the raw GPU count: g5.4xlarge (16 vCPU / 1 GPU
= 16.0) vs g5.12xlarge (48 vCPU / 4 GPUs = 12.0) — the naive "4 GPUs ->
4x throughput" reading is backwards, since the bigger box actually
starves each GPU MORE.

Adds TableOptions.ShowGPURatios, wired to a new --show-gpu-ratios flag
on both find and search. Renders two additional columns (vCPU/GPU,
RAM/GPU) alongside the existing GPU/GPU Model/VRAM columns, computed
from data already in InstanceTypeResult (no new API calls). A
fractional GPU (GPUs==0, GPUPartitionSize>0, e.g. g6f.large — a
time-sliced L4 partition) renders "-" for both rather than dividing by
a fractional count: that row is a shared slice of one GPU, not a
caller-controlled resource, so the ratio would be a number that looks
precise but answers no real question.

Verified against live AWS data (us-east-1): g5.4xlarge and g5.12xlarge
reproduce the issue's own motivating numbers exactly (16.0 and 12.0);
g6f.large correctly shows dashes.

Fixes #51
@scttfrdmn
scttfrdmn force-pushed the feat/51-vcpu-per-gpu branch from de2e77f to fabe41e Compare August 19, 2026 05:03
@scttfrdmn
scttfrdmn merged commit e539309 into main Aug 19, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Surface vCPU-per-GPU (and RAM-per-GPU) ratio for GPU instances — decisive for I/O-bound ML

1 participant