Separate autoregressive generation from downstream inference for AR zero-shot models

For AR foundation models (e.g., MEDS-EIC-AR — see #302), zero-shot inference is actually two distinct steps:

1. Generate trajectories — autoregressively roll forward future patient timelines from each prediction-time context. Expensive: requires the model, a GPU, and is sample-time bound.
2. Inference over the generated trajectories — read the generated futures and compute task-specific labels / metrics. Cheap: pure post-processing, CPU-fine, depends only on the task and the trajectories.

Today these would be a single supervised-predict pass per task. That coupling has two practical downsides:

• Re-generation per task. Two tasks against the same context (e.g., "in-ICU mortality" and "30-day readmission") force two full generation passes, even though the trajectories themselves are task-agnostic. For long-horizon generation against many tasks, the wasted GPU-time compounds fast.
• Re-generation per metric. Iterating on the inference function (different decision thresholds, different summary statistics over the trajectories) shouldn't require re-running the model.

Proposed split

Mirror the structure being discussed in #270 (data-prep vs. training) but at the inference end:

• zero_shot_generate — produces a per-context trajectories artifact (probably a parquet of generated event sequences indexed by subject_id × prediction_time). One pass per (model, dataset, prediction-time-set).
• zero_shot_infer — consumes a trajectories artifact and a task spec, emits the standard predictions.parquet. One pass per (task, metric-set), arbitrarily many per generation.

The model registry stays dataset-agnostic (per the recent close of #248 / #300 / cehrgpt#140) — generation is fully a function of the MEDS dataset + the model; tasks only enter at the inference step.

Open questions

• Artifact format. Parquet of generated event sequences is the obvious answer, but we'd want to nail down the schema (probably a MEDS-compatible "future trajectory" record per context, with model-version metadata embedded for reproducibility).
• MEDS-DEV plumbing. Does this need a new lane (zero_shot_generate alongside unsupervised/supervised), or can it be expressed within the existing unsupervised/supervised structure? E.g., generation as an unsupervised: predict step producing the artifact, inference as supervised: predict taking a --trajectories-dir arg. Worth a brief design pass before any model wires this in.
• Caching. This is the bigger payoff — once trajectories are cached on _results (or a sibling branch), running a new task against an existing AR model becomes a CPU job. Worth scoping early.

Related

• #270 — same split (decouple expensive prep from cheap downstream) but for data preprocessing vs. training; this issue is the inference-side analog.
• #302 — MEDS-EIC-AR registration; the first concrete model that would benefit from this split.

Start by reading #270, #302, and the existing MEDS-DEV unsupervised and supervised predict plumbing. Trace how a zero-shot prediction currently reaches the model and task, then scope separate generation and inference entry points, the trajectories artifact schema, and caching behavior. Done means the design resolves the lane, artifact, metadata, and reuse questions before implementation.