Warn before large downloads in long-running commands (build, quantize) + live elapsed-time counter

[hi-brenda]

Description

Long-running commands that trigger large downloads (calibration datasets, model weights) start the download silently with no upfront warning, no size estimate, and no time estimate. A developer on slow or metered connectivity has no chance to abort before the transfer is underway.

Confirmed reproduction with winml build + calibration dataset:

winml build downloads the entire timm/mini-imagenet dataset (~7 GB — 13 train + 3 validation + 2 test parquet files) even though the config specifies "samples": 10. Quantization took 896 s (~15 min), almost entirely spent downloading. The user sees no warning and no estimated time before this begins.

Steps to Reproduce

winml build -c config.json -m ProsusAI/finbert -o output/

Where config.json specifies:

{ "quant": { "dataset_name": "timm/mini-imagenet", "samples": 10 } }

Expected Behavior

Before any large download begins, the CLI prints a warning with size and estimated time:

⚠  Downloading calibration dataset timm/mini-imagenet (~7.0 GB).
   Estimated time on 10 Mbps: ~95 min  |  100 Mbps: ~10 min
   Press Ctrl+C to cancel.

If the dataset size cannot be determined ahead of time, at minimum print the dataset name and that it may be large, before streaming begins.

The same pre-download warning should apply to:

• Model weight downloads (winml build -m <huggingface_id>)
• Any other command that triggers a network fetch > a configurable threshold (e.g., 500 MB)

Actual Behavior

No warning is printed. The download starts immediately and silently inside the quantize StageLive block. The first visible signal is the spinner; the user has no indication of how long it will run or how much data will be transferred.

Root Cause (initial analysis)

The datasets library streams or caches parquet shards for the full dataset split regardless of how many samples are consumed downstream. The quantize_onnx call in _run_quantize_stage (build.py) does not query dataset size before fetching, and StageLive suppresses datasets progress bars to keep the display clean — removing the only secondary signal the user might have seen.

Two independent fixes are needed:

1. Pre-download warning (UX): Query the Hugging Face Hub API for dataset / model size before fetching and print a structured warning with size + time estimate. Block for 3 s (or until Ctrl+C) to give the user a chance to abort.
2. Lazy / partial download (efficiency): Investigate whether datasets streaming mode or shard-level access can be used to fetch only the N calibration samples without pulling all parquet files first. If feasible, this eliminates the problem for the samples-bounded case entirely.

Environment

• OS: Windows 11
• ModelKit version: latest main (post feat: multi-model support with KV cache (T5, Qwen, Mu2) #334)
• Network: WiFi (variable)

Additional Context

This issue affects any command with a slow first-run experience:

Command	Download trigger	Typical size
winml build (HF model)	Model weights	0.1 – 10 GB
winml build (calibration)	Dataset parquet shards	1 – 50 GB
winml quantize	Same as above	1 – 50 GB
winml eval	Eval dataset	variable

A developer running on coffee shop WiFi or a metered mobile hotspot will abandon the tool after one silent 15-minute hang. The pre-download warning is a low-cost, high-trust fix that should be prioritized independently of the lazy-download optimization.

[hi-brenda]

Extended scope: live elapsed-time counter during long-running stages

The pre-download warning (#444) addresses the start of a long operation. The same UX gap continues during the stage: once a blocking call begins, the StageLive display is completely static — no elapsed counter, no animation tick. A developer running a 15-minute quantize job cannot distinguish "working" from "hung".

What's currently shown (frozen for entire stage duration)

⚙ Quantize  Quantizing (INT8)...

What should be shown (updating every ~1s)

⚙ Quantize  Quantizing (INT8)...   2m 34s

Root cause

StageLive._make_running_line() (console.py) builds a static Text with no timestamp. set_status() is called once before the blocking work and never again. Live(refresh_per_second=15) is active but nothing triggers a re-render — so the spinner is frozen.

The silence is compounded in the quantize stage because datasets progress bars are explicitly suppressed to keep the Live display clean, removing the only secondary signal the user might have seen.

Fix outline (additive to the pre-download warning)

1. Record self._start_time = time.monotonic() in StageLive.__enter__.
2. Update _make_running_line to append elapsed seconds on each call.
3. Spawn a lightweight background thread that calls _update() every 1 s so the counter ticks even when the main thread is blocked in quantize_onnx() / compile_onnx().
4. set_done(elapsed) already records final elapsed — keep unchanged.

Affected stages

Stage	Typical silent duration
Export	10 – 60 s
Quantize	1 – 15 min
Compile	30 s – 5 min

The optimize stage is less affected because _on_node_result callbacks fire during analysis, driving re-renders naturally. Quantize has no equivalent callbacks — making it the worst offender.

Acceptance criteria (addition to #444)

• StageLive displays a live elapsed-time counter that updates at ~1 s intervals during any blocking stage
• Counter is visible for Export, Quantize, and Compile stages
• Counter stops and final elapsed is frozen once set_done() is called (existing behavior preserved)