studio: label RAM and VRAM readouts as GiB not GB#6895
Conversation
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.
There was a problem hiding this comment.
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.
| 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` | ||
| : "--" |
There was a problem hiding this comment.
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.
| 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" | |
| : "--" |
|
@codex review |
|
Codex Review: Didn't find any major issues. More of your lovely PRs please. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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". |
What
The Studio live resource monitor (and the other GPU/RAM readouts) derive memory from binary byte counts but label the values "GB":
bytes / 1024**3MiB / 1024Both are GiB. On a B200 the monitor showed
178.35 GBwhilenvidia-smireports183359 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:
nvidia-smireports MiB, and PyTorch's own OOM messages use GiB. Switching the divisor to1e9would make the meter disagree withnvidia-smiand 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.tsxfeatures/settings/tabs/resources-tab.tsx(RAM/VRAM only, via a newformatGiBhelper; disk keepsformatGb)features/studio/sections/progress-section.tsxfeatures/hub/hub-page.tsxfeatures/settings/tabs/about-tab.tsxfeatures/onboarding/components/steps/summary-step.tsxThe numeric values are unchanged, so the training GPU-selection and memory-fit logic that read the same
*_gbfields are unaffected. No backend changes.Left as GB on purpose:
bytes / 1e9)Testing
npm run typecheckpasses cleaneslinton the changed files reports no new problems (the pre-existing hook/import warnings are unchanged from main)