How Hardware Profiles Override Detected SystemSpecs Capacity and CalcConfig Bandwidth in llmfit

Hardware profiles in llmfit override detected system capacity and bandwidth by replacing raw SystemSpecs detection values and mutating CalcConfig estimator parameters through explicit apply methods.

The llmfit library analyzes whether large language models fit on target hardware by combining automatic resource detection with user-defined hardware profiles. While SystemSpecs::detect() captures the host's actual RAM, CPU, and GPU capabilities, hardware profiles enable deterministic, reproducible analysis by overriding these detected values and calculation parameters.

Understanding the Detection Baseline

llmfit discovers host resources through SystemSpecs::detect() in llmfit-core/src/hardware.rs. This method interrogates the machine for total RAM, CPU core count, GPU memory availability, and compute capabilities to establish a raw capacity baseline.

These detected values serve as the default for "how much fits" calculations—determining if a model can physically reside on the machine. However, raw detection varies across environments and may not reflect intended deployment targets or specialized hardware configurations.

Overriding SystemSpecs Capacity with Hardware Profiles

When a hardware profile is selected via --profile <name>, the HardwareProfile::apply_to_specs method in llmfit-core/src/hwprofile.rs creates a new SystemSpecs instance with modified capacity fields.

According to the source code, this method specifically replaces total_ram_gb and unified_memory fields with the profile's defined values. For unified-memory architectures, the profile synthesizes a GPU object sharing the system memory pool, ensuring the GPU execution path remains viable even when no discrete GPU is present.

This replacement occurs at lines 20-24 of hwprofile.rs, constituting the only pathway where a profile influences capacity-based fit analysis. The original detected specs are consumed, and a transformed specification object propagates through the pipeline.

Overriding CalcConfig Bandwidth and Compute Parameters

Beyond capacity, hardware profiles mutate throughput estimation parameters via HardwareProfile::apply_to_config. This method targets CalcConfig instances—objects storing roof-line model parameters for performance prediction.

The profile copies specific fields from its hardware section into the calculation config:

• gpu_memory_bandwidth_gbps_override receives the profile's gpu_memory_bandwidth_gbps
• ddr_bandwidth_gbps maps directly to the profile's DDR bandwidth specification
• gpu_compute_tflops_fp16 injects the profile's compute capability rating
• Optional efficiency factors and per-run-mode multipliers are applied to refine estimates

As implemented in llmfit-core/src/hwprofile.rs (lines 27-38 and 42-63), unspecified fields remain untouched. This selective mutation allows partial profiles to override only specific bandwidth bottlenecks while preserving detected defaults for other parameters.

The Unified Application Flow

The HardwareProfile::apply convenience method orchestrates both override operations in a single call. This method first updates the mutable CalcConfig reference, then returns a new SystemSpecs instance with capacity fields applied.

This sequence ensures synchronization between the specification object (determining fit) and the configuration object (determining speed). The implementation in hwprofile.rs (lines 65-70) guarantees that analysis pipelines receive consistent, profile-adjusted values for both dimensions.

Practical Implementation Examples

The following Rust code demonstrates the complete workflow from detection to profile application:

use llmfit_core::hardware::SystemSpecs;
use llmfit_core::fit::CalcConfig;
use llmfit_core::hwprofile::resolve;

// 1️⃣ Detect the current hardware.
let detected = SystemSpecs::detect()?;           // <-- raw detection

// 2️⃣ Load a profile (e.g. the bundled "ryzen-ai-max-plus-395").
let loaded = resolve("ryzen-ai-max-plus-395")?; // ← parses & validates

// 3️⃣ Prepare a fresh calculation config.
let mut cfg = CalcConfig::default();

// 4️⃣ Apply the profile – capacity and estimator inputs are overridden.
let specs = loaded.profile.apply(detected, &mut cfg);

// 5️⃣ Run the normal modeling workflow with the overridden objects.
let model_fits = llmfit_core::analysis::build_model_fits(&specs, &cfg, ...);

For scenarios requiring only bandwidth overrides without touching capacity limits, partial profiles suffice:

let partial = HardwareProfile::parse(r#"
{
    "schema_version": 1,
    "name": "my‑gpu",
    "hardware": { "total_ram_gb": 128, "unified_memory": false },
    "estimation": { "gpu_memory_bandwidth_gbps": 300 }
}
"#)?;
let mut cfg = CalcConfig::default();
partial.apply_to_config(&mut cfg);          // only bandwidth is changed

Key Source Files

Understanding the override mechanism requires familiarity with these specific components:

• llmfit-core/src/hwprofile.rs: Contains HardwareProfile definition, validation logic, and the apply_to_specs, apply_to_config, and apply methods
• llmfit-core/src/hardware.rs: Houses SystemSpecs struct and the SystemSpecs::detect implementation
• llmfit-core/src/fit.rs: Defines CalcConfig and roof-line estimation parameters
• llmfit-core/src/analysis.rs: Orchestrates model-fit building using the overridden specifications

Summary

• Capacity Override: HardwareProfile::apply_to_specs replaces total_ram_gb and unified_memory in detected specs, with special handling for unified-memory GPU synthesis
• Bandwidth Override: HardwareProfile::apply_to_config selectively mutates CalcConfig fields including GPU memory bandwidth, DDR bandwidth, and compute TFLOPS
• Atomic Application: The apply method coordinates both overrides to maintain consistency between fit analysis and performance estimation
• Partial Profiles: Unspecified fields in hardware profiles preserve detected defaults, enabling targeted overrides of specific bottlenecks
• Deterministic Analysis: Profile-driven overrides ensure reproducible results across different detection environments and hardware variations

Frequently Asked Questions

How do partial hardware profiles affect detection values?

Partial profiles only override the specific fields defined in their JSON configuration. If a profile specifies only gpu_memory_bandwidth_gbps but omits total_ram_gb, the bandwidth value updates while capacity retains the automatically detected SystemSpecs value. This selective application occurs because apply_to_config and apply_to_specs only assign values present in the profile structure.

What happens when unified_memory is true in a hardware profile?

When a hardware profile sets unified_memory: true, the apply_to_specs method synthesizes a GPU specification sharing the system RAM pool. This ensures that GPU-accelerated inference paths remain available in the analysis even when no discrete GPU exists in the detected hardware, accurately modeling Apple Silicon or AMD APU architectures.

Can I use hardware profiles without overriding detected specs?

No, the current implementation always applies capacity overrides when calling HardwareProfile::apply or apply_to_specs. However, you can approximate detection-only behavior by creating a profile that exactly matches your detected hardware values, or by using apply_to_config exclusively if you only need to adjust bandwidth parameters while preserving the original SystemSpecs detection.

Where does the profile resolution occur in the codebase?

Profile resolution and validation occur in llmfit-core/src/hwprofile.rs through the resolve function and HardwareProfile implementation. This module handles JSON parsing, schema validation, and the transformation logic that bridges static profile definitions with dynamic hardware detection from llmfit-core/src/hardware.rs.

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