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

> Discover how llmfit hardware profiles override detected SystemSpecs capacity and CalcConfig bandwidth by replacing raw values and mutating estimator parameters via apply methods.

- Repository: [Alex Jones/llmfit](https://github.com/AlexsJones/llmfit)
- Tags: internals
- Published: 2026-09-11

---

**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`](https://github.com/AlexsJones/llmfit/blob/main/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`](https://github.com/AlexsJones/llmfit/blob/main/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`](https://github.com/AlexsJones/llmfit/blob/main/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`](https://github.com/AlexsJones/llmfit/blob/main/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`](https://github.com/AlexsJones/llmfit/blob/main/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:

```rust
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:

```rust
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`](https://github.com/AlexsJones/llmfit/blob/main/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`](https://github.com/AlexsJones/llmfit/blob/main/llmfit-core/src/hardware.rs)**: Houses `SystemSpecs` struct and the `SystemSpecs::detect` implementation
- **[`llmfit-core/src/fit.rs`](https://github.com/AlexsJones/llmfit/blob/main/llmfit-core/src/fit.rs)**: Defines `CalcConfig` and roof-line estimation parameters
- **[`llmfit-core/src/analysis.rs`](https://github.com/AlexsJones/llmfit/blob/main/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`](https://github.com/AlexsJones/llmfit/blob/main/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`](https://github.com/AlexsJones/llmfit/blob/main/llmfit-core/src/hardware.rs).