How LLMFIT Reports Full DIMM Capacity on AMD APU Systems with BIOS UMA Carveouts

LLMFIT detects AMD APUs and queries SMBIOS directly via WMI to override the UMA carve-out, reporting the full physical DIMM capacity instead of the OS-visible subset.

LLMFIT is a Rust-based model-fitting framework that requires precise hardware telemetry to calculate memory bounds for large language models. When an AMD APU reserves system RAM for integrated graphics via a BIOS-configured UMA carveout, Windows reports only the remaining memory to sysinfo queries. LLMFIT implements a specialized override routine in llmfit-core/src/hardware.rs that restores the true installed DIMM capacity for accurate fit analysis.

Understanding the AMD APU UMA Carveout Problem

AMD Accelerated Processing Units (APUs) integrate CPU and GPU cores on a single die. To feed the integrated Radeon graphics processor, the BIOS reserves a portion of system memory—known as the UMA carveout—that becomes invisible to the operating system. On a 32 GB system with an 8 GB carveout, Windows sysinfo reports approximately 24 GB of available RAM.

For LLMFIT, this under-reporting is critical. The plan and fit modules rely on the SystemSpecs struct to determine whether a model can run on a given machine. If the tool trusts the OS-reported value, it underestimates the hardware capability and rejects viable model configurations.

Detecting AMD APUs in LLMFIT

CPU String Identification

The first step in the override pipeline identifies whether the system uses an AMD APU. In llmfit-core/src/hardware.rs, the is_amd_apu function inspects the CPU name string for dual keywords indicating Ryzen processors with Radeon graphics:

// llmfit-core/src/hardware.rs lines 626-630
fn is_amd_apu(cpu_name: &str) -> bool {
    let lower = cpu_name.to_lowercase();
    lower.contains("ryzen") && lower.contains("radeon")
}

This check returns true only when both terms appear, filtering out discrete GPU systems and non-AMD processors that might exhibit different memory mapping behaviors.

Querying Physical Memory via WMI

Bypassing the OS Memory Report

Once LLMFIT identifies an AMD APU, it bypasses the OS memory abstraction layer. The detect_windows_physical_total_ram_gb function executes a PowerShell one-liner that calls Get-CimInstance Win32_PhysicalMemory, retrieving raw SMBIOS data that reflects the actual DIMM capacity regardless of BIOS reservations:

// llmfit-core/src/hardware.rs lines 984-1016
fn detect_windows_physical_total_ram_gb() -> Option<f64> {
    // PowerShell command: Get-CimInstance Win32_PhysicalMemory | Measure-Object -Property Capacity -Sum
    let output = Command::new("powershell")
        .args(&["-Command", "Get-CimInstance Win32_PhysicalMemory | Select-Object -ExpandProperty Capacity | Measure-Object -Sum | Select-Object -ExpandProperty Sum"])
        .output()
        .ok()?;
    
    let text = String::from_utf8_lossy(&output.stdout);
    let bytes: u64 = text.trim().parse().ok()?;
    Some(bytes as f64 / (1024.0 * 1024.0 * 1024.0))
}

This WMI query sums the Capacity fields of all physical memory modules, returning the full installed RAM total in gigabytes.

Applying the UMA Carveout Override Logic

The 1 GB Threshold

LLMFIT applies the physical memory value only when the discrepancy indicates a genuine carveout rather than a rounding error. The apply_ram_carveout_override function compares the WMI-derived total against the sysinfo value, using a 1 GB minimum gap constant that matches the smallest BIOS-configurable UMA carveout:

// llmfit-core/src/hardware.rs lines 2476-2482
const UMA_CARVEOUT_MIN_GAP_GB: f64 = 1.0;

fn apply_ram_carveout_override(sysinfo_total_gb: f64, physical_total_gb: f64) -> f64 {
    if physical_total_gb - sysinfo_total_gb >= UMA_CARVEOUT_MIN_GAP_GB {
        physical_total_gb
    } else {
        sysinfo_total_gb
    }
}

If the difference between physical and reported memory meets or exceeds this threshold, the function returns the full DIMM capacity; otherwise, it preserves the original sysinfo value.

The Windows-Specific Entry Point

The windows_apu_total_ram_gb function orchestrates the detection workflow. Located at lines 1192-1199 in hardware.rs, it first validates the APU status, then attempts the WMI query, and finally applies the carveout logic:

// llmfit-core/src/hardware.rs lines 1192-1199
fn windows_apu_total_ram_gb(cpu_name: &str, sysinfo_total_gb: f64) -> f64 {
    if !is_amd_apu(cpu_name) {
        return sysinfo_total_gb;
    }
    match detect_windows_physical_total_ram_gb() {
        Some(physical) => apply_ram_carveout_override(sysinfo_total_gb, physical),
        None => sysinfo_total_gb,
    }
}

On non-Windows platforms (Linux and macOS), LLMFIT skips this routine and uses the standard sysinfo total, as the UMA carveout under-reporting issue is currently observed only on Windows AMD APU implementations.

Impact on System Specifications

The corrected memory value flows into the SystemSpecs struct, which the llmfit-tui, CLI, and API layers consume for all memory-related calculations. When running cargo run -- system, the CLI displays both the original sysinfo value and the overridden DIMM total:

$ cargo run -- system
Detected system:
  CPU: AMD Ryzen 7 8845HS
  GPU: AMD Radeon Graphics (unified_memory = true)
  RAM: 32 GB (reported by sysinfo)
  RAM (DIMM total): 96 GB (UMA carve-out override applied)

Downstream modules—including the plan and fit engines—use this accurate capacity to compute feasible tensor sizes and batch dimensions for AMD APU-based systems.

Code Examples

Checking Memory Directly in Rust

You can invoke the detection logic programmatically when building custom tooling around LLMFIT:

use llmfit_core::hardware;

fn main() {
    let cpu_name = "AMD Ryzen AI MAX 390";
    let sysinfo_ram = 32.0; // GB reported by sysinfo
    let total_ram = hardware::windows_apu_total_ram_gb(cpu_name, sysinfo_ram);
    println!("Effective RAM = {:.1} GB", total_ram);
}

On a Windows machine with a concealed UMA carveout, this outputs the full physical capacity rather than the OS-reported subset.

Unit Test Verification

The test suite in llmfit-core/src/hardware.rs validates the override behavior at lines 3976-3986:

#[test]
fn test_uma_carveout_override() {
    // Simulate 32 GB sysinfo vs 96 GB physical DIMMs
    let sysinfo = 32.0;
    let physical = 96.0;
    let result = hardware::apply_ram_carveout_override(sysinfo, physical);
    assert_eq!(result, 96.0);
}

This confirms the function correctly selects the physical total when the 64 GB gap exceeds the 1 GB threshold.

Summary

• AMD APUs reserve RAM for integrated graphics via BIOS UMA carveouts, causing Windows to under-report available memory.
• LLMFIT identifies APUs by checking CPU names for "ryzen" and "radeon" substrings in the is_amd_apu function.
• The tool queries SMBIOS via WMI (Win32_PhysicalMemory) to retrieve the true DIMM capacity independent of OS reporting.
• A 1 GB threshold (UMA_CARVEOUT_MIN_GAP_GB) prevents false positives from rounding errors before applying the override.
• The windows_apu_total_ram_gb entry point ties detection, querying, and logic together for Windows systems.
• Accurate memory reporting ensures the SystemSpecs struct provides reliable data to LLMFIT's planning and fitting algorithms.

Frequently Asked Questions

What is a UMA carveout on AMD APUs?

A UMA (Unified Memory Architecture) carveout is a BIOS-level reservation of system RAM for the integrated Radeon graphics processor. The operating system cannot access this reserved block, causing standard memory queries to report less RAM than physically installed. LLMFIT detects this condition and restores the true capacity via direct firmware queries.

Why does LLMFIT only apply this override on Windows?

The UMA carveout under-reporting behavior primarily affects Windows systems where the sysinfo API returns the OS-managed memory pool. On Linux and macOS, memory reporting mechanisms typically account for the full DIMM capacity or handle UMA reservations differently, making platform-specific overrides unnecessary according to the current codebase implementation.

How does the 1 GB threshold prevent errors?

The UMA_CARVEOUT_MIN_GAP_GB constant (1.0) represents the smallest configurable UMA carveout size in standard BIOS implementations. LLMFIT applies the override only when the difference between physical and reported memory meets or exceeds this value, preventing the override from triggering on minor discrepancies caused by memory-mapped I/O or reporting rounding.

Where can I find the source code for this detection logic?

All UMA carveout detection and override logic resides in llmfit-core/src/hardware.rs within the AlexsJones/llmfit repository. Key functions include is_amd_apu (lines 626-630), detect_windows_physical_total_ram_gb (lines 984-1016), and apply_ram_carveout_override (lines 2476-2482), with the main entry point at windows_apu_total_ram_gb (lines 1192-1199).

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}