Default to fp32 on CPU/MPS instead of bf16 (fixes #15)

[hemanth1999k]

Problem

load_miso_8b defaults to torch.bfloat16 and _load_model applies it unconditionally:

def load_miso_8b(device="cuda", model_path_or_repo_id=None, dtype=torch.bfloat16): ...
# _load_model:
model.to(device=device, dtype=dtype)

The checkpoint weights are stored as fp32, so on CPU (and MPS) the default silently downcasts to bf16. bf16 buys no speed/memory benefit on those devices, and because audio generation is autoregressive, small bf16/fp32 rounding differences alter the next-frame state and compound over time — CPU bf16 and CPU fp32 produce audibly different output, especially for longer generations. (See #15 for a codebook-level repro.)

Fix

Resolve the default dtype from the target device instead of hardcoding bf16:

• CUDA → torch.bfloat16 (unchanged behavior)
• CPU / MPS → torch.float32

dtype now defaults to None and is resolved via a small _default_dtype_for_device helper. An explicitly passed dtype is still honored, so callers who deliberately want bf16 on CPU can opt in — this is fully backward compatible for CUDA users.

Notes

• One-file change, no new dependencies.
• I don't have a CUDA box to run the full model end-to-end; the dtype-resolution logic itself is covered by a quick local check (cuda/cuda:0 → bf16, cpu/mps → fp32). Happy to adjust naming or fold this into a broader device-handling refactor if you'd prefer.

Fixes #15.

[robbiemu]

❤️
Not sure that the reasoning is correct here but the solution might in fact be that they migrate all devices to fp32, if they really testing in full fp32 instead of shortcutting to nvidia/cuda bf16.

I just finished a test on vast.ai (which I had to use because I don't have Nvidia hardware) and I can confirm CUDA's BF16 is identical to CPU bf16 on the edge case I could identify.

[robbiemu]

Apple Silicon started supporting bfloat16 (BF16) at the hardware level with the M2 family of chips. I believe that statement is true only my homelab M1's (line 201, "no such upside")

[robbiemu]

I can also add this in support of this pr (or at least the approach it embodies):

My tests show a real numeric difference between CPU and MPF fp32 logits, but it is small fp32 backend drift. It is not a decision-level CPU/MPS fp32 disagreement.