Pick the safetensors over-read ratio per file and warn on heavy over-read

[mridul-sahu]

Description

Follow-up to #3455. With the sharding-driven safetensors load, no fixed max_over_read_ratio default serves every sharding: the ratio at which the greedy partitioner collapses a file's plan into whole-span reads is span / needed, which varies with the target sharding and the process topology.

Measured on Mistral-7B (8-way axis, real HF headers), the old fixed default of 2.0 lands on both failure modes:

• Contiguous leading-dim shards, 2 processes x 4 devices: each process owns half of every tensor, so the cumulative merge test passes on every step at ratio 2.0 and every process reads the entire checkpoint (2.0x egress for zero request savings). At 1.0 the same load is 227 clean reads with no over-read.
• Inner-dim shards, same topology at ratio 1.0: the plan fragments into ~131k strided reads per process; at larger scales (8 processes x 1 device) ~1.4M — enough to exhaust file handles. Intermediate ratios are strictly worse than either extreme (e.g. 3.9 on 4x2: 95k reads and 3.8x over-read).

This PR makes max_over_read_ratio=None (the default) pick the ratio per file from the planned runs, which are already available before any I/O:

• Count the reads a ratio-1.0 partition would produce (exactly 1 + gaps above the coalesce floor, one pass over sorted runs). At or under 1024 reads, use 1.0 — contiguous shardings read exactly the bytes they need. Above it, use the file's span / needed, which collapses the fragmented plan into whole-span reads fetched as concurrent fixed-size chunks.
• Replace the read-fragmentation hint with an over-read warning: with the automatic ratio, reading well above the needed bytes (>= 1.5x) means the target sharding fragments the checkpoint's byte layout, so the warning points at the sharding rather than at a loader knob. Fires once, on the primary process only, and only when the ratio was left automatic.

An explicit max_over_read_ratio float keeps exactly the previous fixed-cap behavior.

Type of change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (alters existing behavior or a public API)
• Docs / tests / internal tooling (no user-facing behavior change)

Checklist

• I have read the contribution guidelines.
• Tests cover this change and pass locally.
• Public APIs and non-trivial functions are documented.
• If this change is user-facing, I have updated CHANGELOG.md under the [Unreleased] section (or the relevant checkpoint/ / export/ changelog).