Research
SIRIS: Can LLMs Tell When Simulation Errors Matter in AI-Driven Systems Research
Overview Research area: AI-driven systems research (ADRS) — specifically, whether LLM agents can judge when a computer-system simulator's modeling limitations actually invalidate a recommended design.
- arXiv
- 2611.10329
- Published
- 2026-11-06
- Authors
- Jinwoo Hwang, Sukmin Cho, Tao Zhang, Soheil Abbasloo, Jongse Park, Peng Cheng
AI summary
Overview
Research area: AI-driven systems research (ADRS) — specifically, whether LLM agents can judge when a computer-system simulator's modeling limitations actually invalidate a recommended design.
Technical level: Intermediate. Readers should be comfortable with LLM agent evaluation, multiple-choice benchmarking, and the general idea of cycle-accurate or analytical simulators, but the paper's core idea is explained with worked examples.
Scope (one sentence): The paper introduces SIRIS, a framework that injects controlled perturbations into an LLM-serving simulator to build paired upheld and overturned problems, then measures thirteen frontier LLMs on whether they can tell when the same limitation leaves a recommendation valid versus when it should be overridden.
What This Paper Is About
LLM agents increasingly propose, evaluate, and revise system designs, and they depend on simulators to score candidate designs at a scale real hardware cannot support. Simulators are deliberately approximate, and a modeling limitation may either distort predictions while the recommended design is still correct, or flip which design should be chosen. SIRIS tests whether LLMs can distinguish these two cases from their systems understanding, rather than merely noticing that a limitation exists.
Key Contributions
-
Reframes systems understanding as a decision judgment. The authors argue that, for ADRS (AI-Driven Research for Systems), the relevant capability is not predicting system performance unaided but recognizing when a simulator of that system can be trusted for a specific design decision.
-
Introduces SIRIS and its paired-problem construction. Controlled perturbations — small code changes to how the simulator represents work, costs, or resource interactions — generate perturbation pairs: an upheld and an overturned problem sharing the candidates, perturbation, target metric, and presented recommendation, differing only in workload.
-
Defines judgment and disposition metrics. Judgment is the mean of upheld accuracy (U) and overturned accuracy (O); disposition is their imbalance, D = (U − O)/2. A fixed rule that always follows the presented recommendation solves every upheld problem and no overturned one, scoring J = 50 and D = +50, so neither identifying a limitation nor a fixed preference can solve both members of a pair.
-
Evaluates thirteen frontier GPT, Grok, and Gemini LLMs across three evidence conditions and a two-turn review protocol, and shows that inspection instructions and self-correction often shift disposition more than they raise judgment.
Main Findings
-
Uninformative baselines and controls. Without simulator evidence, every model scores near chance. With the reference simulator, all models except Grok 4.7 reach near-perfect judgment. Neither condition separates models in a way that matters for ADRS.
-
Perturbed evidence is the discriminating condition. Every model's judgment rises above its no-simulator level under the perturbed simulator, and the improvement tends to grow with model recency within each family. GPT-6 Astra and GPT-6.1 Sol approach their reference-simulator judgment, while the other models stay closer to the follow rule.
-
Similar judgment, very different behavior. GPT-6 Sol and Grok 4.7 score 66 and 67 in judgment but +29 and +10 in disposition, showing that overall accuracy hides whether a model errs by keeping bad recommendations or by discarding good ones.
-
Solving a pair is rare. GPT-6 Astra and GPT-6.1 Sol solve both problems in 79 and 65 of 87 pair attempts (29 pairs, three repetitions); every other model solves fewer than half.
-
Identification is not decision correctness. About a quarter of responses that identify the limitation still select a design other than the reference answer, and every model makes such errors. Even GPT-6 Astra and GPT-6.1 Sol abandon some valid recommendations on upheld problems, where the limitation changes predicted values but leaves the reference answer unchanged. For the eight models with loss measurements, these errors increase p95 latency under the reference simulator by a median of 14% per problem.
-
Models often do not read the perturbed code. The share of conversations reading the changed simulator code ranges from 13% to 100% across models. GPT-5.6 Sol and GPT-5.6 Luna read it in 80% and 72% of conversations but in only 4% and 2% of first turns.
-
Instructed inspection raises identification, not judgment. An instruction to check the code against the specification substantially increases limitation identification in GPT-5.6 Sol and GPT-5.6 Luna but does not consistently improve judgment; disposition moves more than judgment. GPT-6.1 Sol, which already inspects the code, changes little. The authors note the instruction also hints at a mismatch, so it does not isolate the effect of inspection.
-
Review helps but creates new errors. Twelve of the thirteen models move toward more similar upheld and overturned accuracies after the review turn. For GPT-5.6 Sol, review corrects 31 choices and introduces 10 new errors, raising J by 12 points; for GPT-5.6 Terra, 17 corrections are offset by 15 new errors, yielding only a 1-point gain despite a large change in disposition.
-
Evidence components behave unexpectedly. For GPT-5.6 Sol and GPT-6.1 Sol, the simulator code, cost parameters, and configuration alone yield judgment close to or above the full perturbed evidence, even though the code contains the perturbation. Adding execution records or predictions lowers judgment in both models, while their effects on disposition differ: execution records raise disposition in both, whereas predictions raise it for GPT-5.6 Sol and lower it for GPT-6.1 Sol.
Methodology in Plain English
The authors build a design-review task on top of LLMServingSim, using its unperturbed version as the reference simulator. Four candidate serving designs, shown under neutral labels, are compared across three design problems: request routing (load-only, SGLang-inspired, Preble, DualMap), prefill-to-decode handoff (stay on source versus three remote placements), and local scheduling with chunked prefill (caps of 16, 24, 32 tokens, and no cap). Routing and handoff are scored on p95 end-to-end latency; local scheduling on p95 time to first token.
They then inject seven perturbations, each an explicit program change to a simulator computation that all four candidates rely on: prefix-reuse credit capped at 512 tokens, prefix reuse credited only in 256-token units, a dedicated link per GPU pair instead of a shared NIC, omitted interpolation along the query axis, step cost taken from the largest request instead of the sum, swapped query and KV lookup coordinates, and wrong interpolation arithmetic (y0 + r·y1 instead of y0 + r(y1 − y0)). The authors stress these are controlled changes for the study, not reported defects of LLMServingSim. A change is admitted only if varying the workload can make the recommendation correct on some workloads and wrong on others.
For each perturbation, they search workloads with both simulator versions. If both versions recommend the same design, the problem is upheld; if they differ, it is overturned. A perturbation pair joins one of each, differing only in workload. Separate LLM builders and reviewers construct and validate the problems, independent solvers attempt each one, and failing problems are dropped with their pair partner. The result is 58 problems in 29 perturbation pairs, with 2,262 conversations per condition and 6,786 in total across thirteen models at three repetitions.
Each model acts as an agent with read-only file tools. In the first turn it is asked only for a recommendation with a short rationale, with no mention of modeling limitations. In the second turn it is asked to review that choice and name any consequential limitation, with no new evidence or correctness feedback. Evidence is varied across conditions — none, all of the perturbed simulator's evidence, and all of the reference simulator's evidence — and separate LLM annotators, blind to labels and model identity, record whether each response identifies the limitation.
Why This Matters
Impact on research. The paper argues that evaluating LLMs for ADRS by identification accuracy alone misses the errors that matter. A model can name the exact limitation and still keep an invalid recommendation or discard a valid one, and both error directions need to be counted together. The paired-problem design supplies a controlled way to do that, and the disposition metric exposes behavioral differences that a single accuracy number conceals.
Real-world applications (as identified by the authors):
- Data-center scheduling, where an approximate model can misrank policies under realistic contention.
- LLM serving policy selection, including routing, prefill-to-decode handoff, and chunked-prefill scheduling.
- Load balancing across replicas, where shared-resource effects such as network bandwidth are commonly idealized.
- Database optimization, where Database ADRS co-evolves a simulator with candidate policies.
Industry relevance. Simulator-grounded search loops such as AlphaEvolve and ShinkaEvolve select candidates directly by evaluator scores, so a modeling limitation can become a search target: designs that exploit the simulator's blind spot may be favored. Knowing which frontier models reliably flag decision-relevant limitations — and which quietly abandon correct recommendations — is directly useful when deciding how much human or LLM review to put around an automated design loop.
Future Directions
-
Broaden beyond LLM serving. Extend SIRIS to other domains whose simulators trade fidelity for speed, using documented limitations of existing simulators to supply naturally occurring problems once a reference establishes their decision impact.
-
Compound and interacting limitations. Inject several limitations at once, whose effects may compound or cancel, and define decision impact by their combined effect rather than one perturbation at a time.
-
Richer question formats. Move beyond multiple-choice selection of the best design to ranking all candidates or proposing a revised design, defining decision impact for each format.
-
Embed evaluation in full ADRS loops. Track whether LLM reviews improve search outcomes in workflows like AlphaEvolve and Glia, and how judgment on individual decisions connects to the designs an ADRS pipeline ultimately produces — including cases where the LLM also modifies the simulator, which requires keeping a reference independent of the evolving simulator.
-
Evidence acquisition under budget. Test whether LLMs recognize when the presented evidence leaves a comparison unresolved and request a targeted measurement, scoring the final design against the cost of the measurements taken.
Target Audience
Researchers and practitioners working on LLM agents for systems and architecture research, simulator and performance-model developers, and evaluation designers interested in how models use unreliable external evidence. It is also relevant to engineers running automated design-search or autotuning pipelines where a simulator is the grading function, and to anyone studying self-correction and critique-versus-action gaps in LLM agents.
Authors’ abstract
LLM agents increasingly drive systems research and rely on simulators to evaluate candidate designs at scale. Simulators are imperfect by design: their modeling limitations can distort predictions yet leave the recommended design correct, or change which design should be selected. We introduce Siris to test whether LLMs can tell these cases apart, judging from their systems understanding when a limitation invalidates the simulator's recommendation. By perturbing a simulator, Siris constructs workload pairs with the same candidates, limitation, and simulator recommendation. The perturbation changes predictions on both workloads, yet a reference simulator supports the recommendation on only one. Evaluating thirteen frontier LLMs on LLM serving design problems, we find that identifying a limitation does not ensure a correct choice, and even the strongest models sometimes abandon valid recommendations. Self-correction through a review turn helps these models restore valid choices but introduces new errors in several others. These findings motivate evaluating systems understanding through design decisions under imperfect simulators.