Just-in-Time Model Replacement (JITR)

• Just-in-Time Model Replacement (JITR) is an adaptive framework that replaces large language models with efficient surrogate models for recurring, template-based tasks.
• It continuously monitors LLM usage, detects recurring task patterns via clustering and vectorization, and triggers model replacement based on cost and accuracy thresholds.
• Leveraging methods like full fine-tuning, adapters/LoRA, and distillation, JITR achieves near LLM-level performance with significantly reduced computational overhead.

Just-in-Time Model Replacement (JITR) is an adaptive framework for dynamically substituting LLMs with computationally cheaper, task-specialized surrogate models in production pipelines. Upon detecting recurrent user requests that can be characterized as stable task templates, JITR identifies and fine-tunes small models—thereby reducing operational cost and latency without sacrificing accuracy for the repetitive task. The approach centers on continual monitoring of LLM usage, automatic detection and clustering of recurring task patterns, efficient surrogate model search and adaptation, and seamless runtime model switching with ongoing performance monitoring (Strassenburg et al., 5 Dec 2025).

1. Formal Problem Formulation

Let $\mathcal{D} = \{(x_i, y_i)\}$ be the stream of user prompts $x_i$ and LLM-generated outputs $y_i$. Many requests in practice correspond to a small set of recurring tasks $T$, recognizable as templates $x = \mathrm{template}_T(\ell ; \phi)$, where $\ell$ defines the high-level instruction (e.g., "sentiment classification of movie review") and $\phi$ are slot-fillers (e.g., the actual review text). For each recurring task $T$ in a sliding window $W$, frequency $f_T$ quantifies occurrence.

The objective is to find, for each detected $x_i$0, a surrogate model $x_i$1 that (i) achieves task accuracy $x_i$2 and (ii) minimizes per-instance invocation cost $x_i$3 (monetary, energy, or time). Model replacement is enacted when, after accumulating $x_i$4 labeled instances, a candidate model $x_i$5 is shown to satisfy

$x_i$6

where $x_i$7 is the original LLM.

2. Recurring-Task Detection and Trigger Mechanisms

Incoming LLM calls are monitored and analyzed through multilayered pipelines designed to extract recurring patterns and cluster requests into tasks $x_i$8:

• Prompt-Prefix Vectorization: Each request $x_i$9 is embedded into a fixed-length vector $y_i$0 (extracted from model KV-cache or wrapper prompts). Pairwise cosine similarities are used to link prompt instances:

$y_i$1

Thresholding ($y_i$2) groups requests into candidate templates.

• Wrapper Prompt Classification: Requests are optionally wrapped in metadata prompts instructing the LLM to emit $y_i$3 fields, yielding initial cluster assignments.
• Periodic Clustering: Offline clustering (agglomerative or $y_i$4-means) is applied every 1,000 requests to recent embeddings, producing clusters $y_i$5.

Surrogate generation is triggered when frequency $y_i$6 and buffer size for cluster $y_i$7 exceed user-specified or estimated thresholds $y_i$8 and $y_i$9.

3. Surrogate Model Search and Selection Strategy

The candidate search space $T$0 comprises models from private repositories or public hubs (e.g., Hugging Face), each annotated with parameter count ($T$1), model size, inference latency $T$2, and benchmarking metadata. The optimization seeks

$T$3

where $T$4 and $T$5 are latency and memory constraints. The search process systematically prunes infeasible models, ranks candidates using quick surrogate predictors $T$6 on samples, clusters via Task2Vec-like embeddings, and full fine-tunes the $T$7 most promising meta-candidates before final selection.

Step	Input	Output
Prune	$T$8, constraints	Models with valid memory/latency
Surrogate Prediction	Pruned models, task samples	Predicted accuracy for fast ranking
Clustering	Ranked models, embeddings	Top-$T$9 clusters; select cluster representatives
Fine-tuning	Meta-candidates, full data	Measured $x = \mathrm{template}_T(\ell ; \phi)$0, select best cost-achieving $x = \mathrm{template}_T(\ell ; \phi)$1

4. Transfer Learning and Fine-Tuning Pipeline

Surrogate adaptation uses several transfer learning paradigms:

• Full Fine-Tuning updates all parameters.
• Adapters / LoRA freeze the base model $x = \mathrm{template}_T(\ell ; \phi)$2 and learn low-rank updates $x = \mathrm{template}_T(\ell ; \phi)$3.
• Distillation minimizes the Kullback-Leibler divergence between $x = \mathrm{template}_T(\ell ; \phi)$4 output and the full LLM's output logits.

The composite training loss is: $x = \mathrm{template}_T(\ell ; \phi)$5 with $x = \mathrm{template}_T(\ell ; \phi)$6 as the cross-entropy, $x = \mathrm{template}_T(\ell ; \phi)$7 as distillation loss, and $x = \mathrm{template}_T(\ell ; \phi)$8, $x = \mathrm{template}_T(\ell ; \phi)$9 weighting ground-truth versus teacher signal.

Empirical results indicate only a few hundred to a few thousand examples are required to approach LLM-level test accuracy on straightforward tasks, using standard data split, early stopping on $\ell$0, and checkpoint retention based on validation set $\ell$1.

5. System Architecture and Workflow (Poodle Framework)

The Poodle system is the canonical instantiation of JITR, with clearly delineated components:

• Data Collector / Monitor: Hooks into each LLM API call, applies optional wrapper prompts, logs $\ell$2, and cost/timing metrics.
• Task Analyzer: Performs clustering on recent logs to update the set of recurring tasks.
• Model Manager / Generator: On new recurring task $\ell$3, runs search and customization workflow and registers $\ell$4.
• Inference Engine: Routes incoming requests for $\ell$5 to $\ell$6; otherwise, defaults to LLM $\ell$7.
• Model Monitor: Periodically shadow-tests a random fraction (1–5%) of requests on both $\ell$8 and surrogate $\ell$9 to monitor performance drift $\phi$0; triggers retraining or reversion if performance falls below threshold $\phi$1.

Integration is achieved via transparent proxying or a client SDK that intercepts and augments calls, enabling non-intrusive deployment with existing LLM APIs.

6. Empirical Evaluation and Quantitative Results

The Poodle prototype was evaluated on binary sentiment classification (IMDB), comparing canonical LLMs (GPT-4.1, GPT-4.1-nano, Llama-405B Turbo, Llama-2-7B) with surrogates (BERT-base, $\phi$280M params).

• Cost Savings (per 1 million requests, Table 1 prices):
  • GPT-4.1-nano $\phi$3 BERT: Break-even $\phi$4100k requests, saving \$33.
  • GPT-4.1 $\phi$5 BERT: Break-even $\phi$610k requests, saving \$850.
  • Llama-405B Turbo $\phi$7 BERT: Break-even $\phi$810k requests, saving \$1,420.
• Latency and Throughput (NVIDIA A5000, max batch size):
  • Llama-2-7B: 13 items/sec (batch=16)
  • BERT: 254 items/sec (batch=128), $\phi$919.6$T$0 faster
  • Break-even at $T$1100k requests; $T$2 speedup at 1M
• Surrogate Accuracy (IMDB test set):

#Examples	GT Train$T$3Test Acc	LLM$T$4Test Acc
500	0.86$T$50.88	0.88$T$60.88
1,000	0.88$T$70.89	0.88$T$80.88
2,000	0.89$T$90.90	0.88$W$00.88
5,000	0.90$W$10.91	0.90$W$20.90

• Development Efficiency:
  • Naïve full-fine-tune (10 candidates on 5,000 examples): 53 min, test-acc 0.92
  • JITR search+fine-tune, best on 500 examples: 2.8 min, acc 0.91
  • JITR search+fine-tune on 5,000: 12 min, acc 0.92

7. Practical Challenges, Limitations, and Future Directions

Key challenges include early-detection overhead from wrapper tokens, scaling model-store indexing for millions of candidates, storage/throughput bottlenecks (require fast load and cluster-aware compression), and calibration of monitoring (how much shadowing is required to robustly detect surrogate drift). Notable limitations are that surrogate accuracy is contingent on quality and representativeness of $W$3 data; rare or shifting tasks produce weaker surrogates; and privacy concerns arise with logging sensitive prompts/responses.

Proposed research directions include meta-learning for low-shot surrogate performance prediction, hardware- and storage–co-optimization, advanced distillation (including intermediate representation matching), multi-task surrogates with shared layers, and dynamic refinement of user-defined performance/cost thresholds via automated feedback loops (Strassenburg et al., 5 Dec 2025).