- Zero-copy float32 Arrow shard writer: the old add_column([e.tolist()...])
materialized ~18GB of Python floats at 1.2M rows and swap-wedged workers
silently; also halves shard size (float32 fixed_size_list vs list<double>)
- Passthrough consolidator: per-file download->upload, peak disk = ONE shard
(34GB wiki merge in 293s on cpu-xl); normalizes old list<double> shards to
fixed_size_list<float32> so mixed-version runs still merge loadable
- --streaming: file-level IterableDataset sharding, each rank streams only its
own files, bounded-memory part writes (very-big-dataset mode; text only)
- Input revision pinned at launch and recorded in the manifest - every rank
and any later --retry-rank slices the identical snapshot
- 'writing' heartbeat state so post-encode is visible, not silent
- --consolidate-flavor; retry exit-code check; manifest-driven retries
Validated on Jobs: wikipedia-en 6,407,814 rows (8x l4x1) and fineweb-edu
sample-10BT 9,672,101 rows (8x l4x1, 56 min end-…
launcher: --consolidate-flavor (cpu-upgrade's 50GB disk too small past ~20GB of shards)
generate-embeddings.py gains an env-driven shard mode (RANK/NUM_SHARDS/RUN_ID/
OUTPUT_BUCKET): each worker embeds an exact contiguous slice, writes its parquet
+ progress heartbeats to a Bucket (object PUTs, no commit contention), and
new launch-embedding-fleet.py / consolidate-shards.py handle spawn, wait,
per-rank retry, and the single final merge commit with fleet provenance.
Unsharded behavior is unchanged.
Smoke-tested on Jobs: 20k rows x 2 t4-small workers -> exact 20,000-row output;
kill-one-worker -> --retry-rank -> --consolidate-only recovery verified.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
