[bug] Three different answers to "how much memory can this box use", two for "how much does this model need" (0.8.10)

[redstar-systems]

Component

provider-swift (Swift CLI)

What happened?

One binary, one machine, same minute, disagreeing with itself.

Same model, two memory requirements

mlx-community/Qwen3-TTS-12Hz-1.7B-Base-bf16:

$ darkbloom models list
ID                                           TYPE       QUANT  SIZE    EST MEM
mlx-community/Qwen3-TTS-12Hz-1.7B-Base-bf16  qwen3_tts  bf16   4.2 GB  5.1 GB

$ darkbloom doctor
[FAIL] model fits in RAM — mlx-community/Qwen3-TTS-12Hz-1.7B-Base-bf16 needs ~11.6 GB
       but only 6.6 GB is usable — it will show online but every request fails to load.

5.1 GB vs ~11.6 GB for the same model.

Available memory, three figures

doctor:  only 6.6 GB is usable
doctor:  metal gpu: Apple M2 Max, 21 GB working set
status:  Inference memory: 28 GB available

The 6.6 GB usable figure did not change between two runs several minutes apart, while system-wide
free memory went from roughly 200 MB to 67%. So it does not appear to track actual availability.

Consequence in the catalog picker

darkbloom start offers Qwen 3.6 35B A3B at 21.3 GB on this box, whose reported Metal working
set is 21 GB, under a header reading:

Select models (RAM: 32 GB)
0 selected · 0.0 GB total · all models can be served simultaneously

The picker appears to gate on total RAM (min_ram_gb ≤ 32) rather than on the GPU working set that
doctor reports. Weights fitting RAM is not the same as the model fitting Metal residency, and on a
32 GB machine that difference is the whole margin.

I did not test whether selecting Qwen is actually permitted or what happens if you do, so I am
describing what the picker offers and on what basis, not asserting it would fail.

Related to #653 from the opposite direction: that one blocks models that should fit, this one
advertises one that likely cannot.

Expected behavior

One memory model, shared by models list, doctor, status, and the catalog picker.

Whichever figure is authoritative, the other surfaces should quote it rather than compute their own.
In particular the picker should gate on the same number doctor fails on, so a model cannot be
offered and then rejected by the next command you run.

Steps to reproduce

1. darkbloom models list — note EST MEM for a local model
2. darkbloom doctor — note the needs ~X GB but only Y GB is usable line for that same model
3. darkbloom status — note Inference memory: N GB available
4. Compare all three
5. darkbloom start — note which models are offered relative to the working set doctor reports

Environment

• provider: 0.8.10
• macOS: 15.4.1 (24E263)
• hardware: MacBook Pro M2 Max, 32 GB, 38 GPU cores

Logs

$ darkbloom models list
mlx-community/Qwen3-TTS-12Hz-1.7B-Base-bf16  qwen3_tts  bf16  4.2 GB  EST MEM 5.1 GB

$ darkbloom doctor
[FAIL] model fits in RAM — mlx-community/Qwen3-TTS-12Hz-1.7B-Base-bf16 needs ~11.6 GB
       but only 6.6 GB is usable
[PASS] hardware: Apple M2 Max, 32 GB RAM, 38 GPU cores
[PASS] metal gpu: Apple M2 Max, 21 GB working set

$ darkbloom status
Hardware: Apple M2 Max, 32 GB RAM, 38 GPU cores
Inference memory: 28 GB available

Confirmations

• I searched existing issues and this isn't a duplicate

[hnshah]

Multi-host operator corroboration + code map (read-only)

We hit the same class of “one binary, disagreeing with itself” confusion on other tiers. Did not re-run the exact Qwen3-TTS path on paid boxes (operator freeze), but the definitional split is in tree:

Surface	Metric
models list EST MEM	estimatedMemoryGb = on-disk × overhead factor
doctor needs ~X	ModelFitDiagnostic.requiredGb = weights + load headroom (ModelLoadAdmission.requiredToLoadGb)
doctor usable Y	usableInferenceGb / same free-for-load gate as daemon
status Inference memory	hardware.memoryAvailableGb (different question)
metal working set	recommended max working set
start picker	not-downloaded gated on catalog min_ram_gb vs physical RAM (StartCommand+Picker.buildPickerEntries); not the doctor usable gate

So 5.1 vs ~11.6 can both be “correct” under different defs — operators still experience it as a bug.

Suggested consolidation (maintainer-shaped, not a drive-by PR)

1. One MemoryBudget DTO shared by doctor / status / models / picker
2. models list: show LOAD NEED beside EST MEM
3. picker: gate on required_to_load <= usable_for_load
4. status: print doctor’s usable string
5. unit tests: fixture where EST MEM < required_to_load

Happy to turn this into a small pure-logic PR if you want that scoped. Related: #653 (opposite direction).