How to Manually Force a Specific Hardware Tier During Dream Server Installation

Pass the --tier flag or set the TIER environment variable before running the installer to override automatic hardware detection and select your preferred configuration.

Dream Server from the Light-Heart-Labs/DreamServer repository automatically analyzes your GPU and system resources to assign a performance tier, but you can manually force a specific hardware tier during installation when you need precise control over model selection and resource allocation.

Understanding Dream Server Hardware Tiers

Dream Server organizes hardware capabilities into numbered tiers (0-4) and specialized tier names that determine which AI models get downloaded and how much VRAM gets allocated.

Available Tier Options

• 0 – Lightweight (8 GB VRAM, 2B parameter models)
• 1 – Entry Level (8 GB VRAM, 9B parameter models)
• 2 – Prosumer (12 GB VRAM, 9B models with larger context)
• 3 – Pro (24 GB VRAM, 30B parameter models)
• 4 – Enterprise (48 GB VRAM or dual-GPU setup, 30B models)
• CLOUD – Optimized for cloud deployment
• NV_ULTRA – NVIDIA Ultra configuration
• SH_LARGE / SH_COMPACT – Specialized form factors
• ARC / ARC_LITE – Intel Arc GPU configurations

As implemented in tier-map.sh lines 46-85, each tier maps to specific GGUF model files and context window sizes.

Method 1: Using the --tier Command-Line Flag

The installer accepts --tier as a command-line argument parsed in install-core.sh (lines 86-90). This flag stores the value in the TIER variable and skips the automatic hardware detection phase.

# Force Tier 2 (Prosumer) with voice features enabled

./install.sh --tier 2 --voice

# Force Tier 3 (Pro) with all components installed non-interactively

./install.sh --tier 3 --all --non-interactive

The install.sh wrapper passes all arguments to the core installation logic, so you can combine --tier with any other supported flags such as --all, --no-voice, or --non-interactive.

Method 2: Setting the TIER Environment Variable

For automated deployments, CI/CD pipelines, or scripted installations, export the TIER environment variable before invoking the installer. This method achieves the same result as the --tier flag.

# Export and run in one command

TIER=NV_ULTRA ./install.sh --voice

# Export for the session

export TIER=ARC_LITE
./install.sh --no-voice

# Use in CI configuration

export TIER=3
./install.sh --non-interactive

According to the source code in install-core.sh, the installer checks for this variable at line 89 before proceeding to hardware detection.

How the Installer Processes Tier Overrides

When you supply a manual tier selection, the installer follows this execution flow:

1. Argument Parsing – In install-core.sh, the script captures --tier and assigns it to the TIER variable (lines 86-90).

2. Detection Bypass – The detect_gpu function in installers/lib/detection.sh checks for the presence of TIER. If found, it skips automatic hardware probing and adds the tier flag to resume arguments for potential reboot scenarios.

3. Configuration Resolution – The resolve_tier_config function in tier-map.sh (lines 46-85) reads the TIER value and selects the appropriate model weights, GGUF quantization level, and context size, completely bypassing the auto-selection logic.

Complete Installation Examples

Here are practical commands for common scenarios:

# Force Entry Level tier on a shared server with limited resources

./install.sh --tier 1 --no-voice

# Force Enterprise tier for high-performance inference

./install.sh --tier 4 --all

# Force Cloud configuration in a containerized environment

export TIER=CLOUD
./install.sh --non-interactive

# Force Intel Arc Lite for specific GPU architecture

TIER=ARC_LITE ./install.sh

Verification and Troubleshooting

After the detection phase runs, the installer logs the selected tier to stdout:

[INFO] Tier forced to: 2 (Prosumer)

This message appears early in the installation output because install-core.sh passes the tier value immediately to the detection library. If you see this log entry followed by your expected tier number, the override succeeded.

If the installer still attempts hardware detection despite setting a tier, verify that:

• You placed --tier before any positional arguments when using the flag method
• The TIER environment variable is exported in the current shell session, not just set locally
• You are running the command from the dream-server directory where install.sh resides

Summary

• Dream Server supports numbered tiers 0-4 and specialized names like CLOUD, NV_ULTRA, and ARC_LITE.
• Override automatic detection by passing --tier VALUE to install.sh or exporting TIER=VALUE before execution.
• The install-core.sh script parses these inputs at lines 86-90, storing them in the TIER variable.
• The resolve_tier_config function in tier-map.sh maps your selection to specific model configurations.
• Verify successful tier forcing by checking for the [INFO] Tier forced to: log entry during installation.

Frequently Asked Questions

What happens if I specify an invalid tier name?

The installer validates tier inputs during the resolution phase in tier-map.sh. If you provide an unrecognized tier value, the installation will fail with an error message listing valid options before attempting to download any model files.

Can I change the tier after installation without reinstalling?

The tier selection primarily determines which GGUF model files download during the initial setup. To change tiers post-installation, you must re-run the installer script with the new --tier value, which triggers resolve_tier_config to pull the appropriate model weights for your new selection.

Does forcing a tier skip all hardware checks?

When TIER is set, the detect_gpu function in detection.sh bypasses the hardware capability analysis that would normally assign automatic tiers. However, basic system compatibility checks still run to ensure the platform can execute the core Dream Server binaries.

Why would I force a lower tier than my hardware supports?

Forcing a lower tier reduces VRAM requirements and enables larger context windows or concurrent operations on powerful hardware. This is useful when running Dream Server alongside other GPU-intensive applications, or when you specifically need smaller model variants for testing or latency-sensitive deployments.

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