Skip to content

studio: label RAM and VRAM readouts as GiB not GB#6895

Merged
danielhanchen merged 1 commit into
mainfrom
studio-vram-gib-units
Jul 6, 2026
Merged

studio: label RAM and VRAM readouts as GiB not GB#6895
danielhanchen merged 1 commit into
mainfrom
studio-vram-gib-units

Conversation

@danielhanchen

Copy link
Copy Markdown
Member

What

The Studio live resource monitor (and the other GPU/RAM readouts) derive memory from binary byte counts but label the values "GB":

  • torch / psutil: bytes / 1024**3
  • nvidia-smi path: MiB / 1024

Both are GiB. On a B200 the monitor showed 178.35 GB while nvidia-smi reports 183359 MiB (179 GiB), so it looked like about 14 GB of VRAM was missing.

Why GiB, not decimal GB

Every GPU dev tool uses binary units, and the marketing "GB" is inconsistent per card:

GPU nvidia-smi GiB (/1024^3) decimal GB (/1e9) Marketing
B200 183,359 MiB 179.1 GiB 192.3 GB "192 GB" (decimal)
A100 80GB 81,920 MiB 80.0 GiB 85.9 GB "80 GB" (binary)
H100 80GB ~81,559 MiB ~79.6 GiB 85.5 GB "80 GB" (binary)

nvidia-smi reports MiB, and PyTorch's own OOM messages use GiB. Switching the divisor to 1e9 would make the meter disagree with nvidia-smi and over-report every A100/H100/4090, so the correct fix is the label, not the math.

Change

Relabel the measured RAM/VRAM readouts from GB to GiB in:

  • components/floating-monitor.tsx
  • features/settings/tabs/resources-tab.tsx (RAM/VRAM only, via a new formatGiB helper; disk keeps formatGb)
  • features/studio/sections/progress-section.tsx
  • features/hub/hub-page.tsx
  • features/settings/tabs/about-tab.tsx
  • features/onboarding/components/steps/summary-step.tsx

The numeric values are unchanged, so the training GPU-selection and memory-fit logic that read the same *_gb fields are unaffected. No backend changes.

Left as GB on purpose:

  • Disk usage (backend reports decimal GB, bytes / 1e9)
  • Model file sizes and download progress (decimal GB to match Hugging Face)
  • Heuristic model VRAM fit estimates ("~X GB")

Testing

  • npm run typecheck passes clean
  • eslint on the changed files reports no new problems (the pre-existing hook/import warnings are unchanged from main)

The live resource monitor and GPU readouts derive memory from binary byte
counts (bytes / 1024**3 for torch and psutil, MiB / 1024 for the nvidia-smi
path), which is GiB, but the UI labeled the values "GB". On a B200 this
showed "178.35 GB" for a card whose nvidia-smi total is 183359 MiB
(179 GiB), so it looked like memory was missing.

Relabel the measured RAM and VRAM readouts to GiB across the floating
monitor, the resources tab, the studio live GPU panel, the hub header, the
about tab and the onboarding summary. The numeric values are unchanged, so
the training GPU selection and memory-fit logic that read the same fields
are unaffected. Disk stays labeled GB because the backend reports it in
decimal GB (bytes / 1e9), and model file sizes and download progress keep
their decimal GB labels to match Hugging Face.

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request updates the frontend to display RAM and VRAM values in "GiB" instead of "GB" across multiple components (FloatingMonitor, ModelsPage, SummaryStep, AboutTab, ResourcesTab, and ProgressSection) to correctly represent the binary units received from the backend. Feedback was provided to format the VRAM values in the live GPU panel using .toFixed(1) to prevent unformatted floating-point numbers from breaking the UI layout.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

Comment on lines 448 to 450
currentGpu.vram_used_gb != null && currentGpu.vram_total_gb != null
? `${currentGpu.vram_used_gb} / ${currentGpu.vram_total_gb} GB`
? `${currentGpu.vram_used_gb} / ${currentGpu.vram_total_gb} GiB`
: "--"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

To prevent raw floating-point numbers with many decimal places (e.g., 11.123456789 / 16 GiB) from rendering in the UI and potentially breaking the layout, it is highly recommended to format the VRAM readouts using .toFixed(1) or a similar rounding method, matching the formatting precision used in other monitor components.

Suggested change
currentGpu.vram_used_gb != null && currentGpu.vram_total_gb != null
? `${currentGpu.vram_used_gb} / ${currentGpu.vram_total_gb} GB`
? `${currentGpu.vram_used_gb} / ${currentGpu.vram_total_gb} GiB`
: "--"
currentGpu.vram_used_gb != null && currentGpu.vram_total_gb != null
? currentGpu.vram_used_gb.toFixed(1) + " / " + currentGpu.vram_total_gb.toFixed(1) + " GiB"
: "--"

@unslothai unslothai deleted a comment from chatgpt-codex-connector Bot Jul 6, 2026
@danielhanchen

Copy link
Copy Markdown
Member Author

@codex review

@chatgpt-codex-connector

Copy link
Copy Markdown

Codex Review: Didn't find any major issues. More of your lovely PRs please.

Reviewed commit: f2d4e5d366

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

@danielhanchen
danielhanchen merged commit 46e2cf5 into main Jul 6, 2026
41 checks passed
@danielhanchen
danielhanchen deleted the studio-vram-gib-units branch July 6, 2026 15:27
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.

1 participant