EDA flow parameter tuning is critical for quality-of-results~(QoR), yet the parameter space is large, tightly coupled, and full evaluations are prohibitively expensive. Prior LLM-assisted tuners mainly use the LLM as an external proposer with transient working context; we instead present StateTune, which reformulates LLM-assisted EDA tuning as a closed-loop, state-carrying process. Its optimizer state is a typed, evidence-gated persistent optimization memory that is updated by every evaluation and shared between candidate generation and budget allocation. On top of this optimizer state, an expected hypervolume improvement (EHVI)-guided, runtime-aware promotion policy ranks quick-stage candidates by expected Pareto frontier gain per unit of runtime cost. Evaluated on a Cadence industrial flow across six benchmark blocks (two technology nodes × three designs), against five baselines including LLM+retrieval-augmented generation (RAG) and preference-based Bayesian optimization (BO) tuners, StateTune achieves the strongest final hypervolume on all six benchmark blocks, showing a stable improvement in frontier quality across the full matrix; it also matches or surpasses the strongest baselines on worst negative slack (WNS), area, and power across the same set. Ablation shows persistent memory is the largest contributor: removing it costs 58.5% of the hypervolume. Dedicated analyses of evidence-gating sensitivity, memory poisoning, cross-design transfer, and three-seed reproducibility (CV,<,7% on five of six blocks) further validate the memory design.
Figures & tables
Figure 1. Overall workflow of StateTune. The knowledge layer (left) builds and updates persistent optimization memory from design inputs and evaluation feedback via Prior Initialization and an Analysis Agent. The decision layer (center) generates candidate configurations through Knowledge-guided Search and ranks them via EHVI-based Promotion; an Evaluation Engine arbitrates the final selection. The execution layer (right) schedules multi-fidelity evaluations through a Scheduling Agent and returns QoR metrics. The persistent optimization memory connects all three layers.
Method
LLM search
RAG
Memory type
Gate
Multi- fid.
Multi- obj.
Cross- design
PTPT ( 7 )
∘
∘
–
∘
∘
∙
∘
FlowTuner ( 13 )
∘
∘
–
∘
∙ a
∘
∘
RankTuner ( 21 )
∘
∘
–
∘
∘
∙
∘
CROP ( 14 )
∙
∙ b
Prompt hist.
∘
∘
∘
∘
ORFS-agent ( 8 )
∙
∘
Prompt hist.
∘
∘
∙ c
∘
AstroTune ( 19 )
⊙ d
∙
–
∘
∙
∙
∘
Table 1. Capability comparison of EDA flow tuning methods. ∙ = supported; ∘ = not supported; ⊙ = partial.
Figure 2. Structure of the persistent optimization memory Mt . Evaluation results, failure diagnoses, and sensitivity analyses feed into six components. The design prior Pt conditions generation; reusable rules Rt guide failure avoidance; Pareto status Πt and the runtime model Tt drive EHVI-based promotion.
Table 6. Results across the 2×3 benchmark matrix under the shared budget caps. Six methods are compared: BO (qEHVI), Optuna-TPE, Random, RankTuner (ICCAD’24) ( 21 ) , CROP (ICCAD’25) ( 14 ) , and StateTune. Bold = best per benchmark (per column).
Figure 3. Pareto frontier projections for the ASAP-JPEG case ( − Area vs. WNS, − Area vs. − Power, WNS vs. − Power). StateTune (purple triangles) occupies the strongest region among the compared methods.
Figure 4. Anytime hypervolume trajectory for ASAP7-AES, averaged over three independent runs per method with shaded ±1 standard-deviation bands. StateTune (cyan) separates from all baselines early and maintains a clear advantage throughout the run.
ASAP7
NAN
Benchmark
HV ( μ±σ )
CV (%)
Benchmark
HV ( μ±σ )
CV (%)
JPEG
5.33e5±8.21e4
15.4
JPEG
2.53e6±1.29e4
0.51
AES
3.73e6±3.32e4
0.89
AES
4.42e3±6.34e1
1.43
IBEX
4.57e5±2.86e4
6.27
IBEX
1.66e3±9.00e1
5.42
Table 7. StateTune reproducibility over three independent runs.
Variant
Final HV (M)
HV Drop (%)
Pareto Hits
First Hit (h)
Full system
10.10
—
6
10.29
w/o Persistence
4.19
58.5
0
–
w/o KA
4.57
54.8
2
2.10
w/o RAG
5.44
46.1
0
–
w/o CoT
6.92
31.5
1
29.62
w/o EHVI
8.32
17.6
4
12.93
Table 8. Ablation on ASAP7 JPEG under 48 thread ⋅ h budget. Variants ordered by degradation severity.
Figure 5. Additional validation on ASAP7 JPEG under 48 thread ⋅ h. (a) Final HV and global Pareto hit rate peak at k=12 . (b) Transferred memory converges faster and reaches higher final HV than no transfer. Thin curves denote individual runs, thick curves denote means, and shaded bands indicate ±1 standard deviation.
The throughput of an LLM training job depends on its recipe: how the model is split across GPUs, how memory is traded for compute, and which kernels and communication overlaps it uses. The best recipe changes with every model, accelerator and framework version. Automated tuners search a fixed space of knobs and check only that a job runs, so they miss levers outside that space and can ship a configuration that silently changes training. ATTUNE is a coding agent that tunes any working recipe unattended within a GPU-hour budget. Guided by a skill of search rules, scripts and lessons from past tuning campaigns, it diagnoses each run and changes one lever at a time. A correctness gate outside the agent refuses any argument known to change the training objective. ATTUNE tunes Amazon's production post-training recipes on H100, H200 and B200 clusters, raising throughput by 1.7x on average. It beats the published throughput of four of NVIDIA's own benchmark recipes on NVIDIA's AutoModel framework by 6-17%. On models held out from its development, it improves the strongest public recipes most where they were written for another setting, by up to 2.6x on MiniMax-M2, and least where the vendor tuned them for the same hardware. Given the same GPU-hour budget, it outperforms existing automated tuners, including Bayesian optimization, random search and OptiCo, a recent LLM-agent tuner. Its gain on GLM-4.5 is more than four times the best alternative's. The same coding agent without ATTUNE's skill gains less and fails half its launches. We release ATTUNE at https://github.com/amazon-science/attune and OpenRecipes, a leaderboard of tuned and verified training recipes, at https://openrecipes.ai.
Electronic design automation (EDA) has advanced engineering productivity through successive generations of tooling that progressively automate synthesis, optimisation, and verification. Large language models (LLMs) extend this trajectory by enabling direct translation from design intent to hardware implementations. In most of the EDA literature, LLM-based solutions are typically assisting siloed design stages or tasks, however this obscured the drivers by which capability emerges and systems scale. In this Perspective, we instead define three hierarchical roles that reveal how capability accumulates: a Generator that produces design artifacts in a single pass, an Agent that refines outputs through iterative tool feedback, and an Orchestrator that coordinates decisions across EDA-stages. Across published systems, this reveals a syntax trap in which models are trained to produce plausible code rather than physically correct hardware, compounded by fragmented tools and loss of design context that obscure how decisions affect later stages. Comparisons across the three roles show that current approaches struggle to scale to industrial designs, motivating a shift towards a standardised, physics-aware orchestrator that connects tools and agents across the EDA flow for more reliable and accessible hardware design.
Matthew Youngman, Cristian Sestito, Themis Prodromakis
Centre for Electronics Frontiers, Institute for Integrated Micro and Nano Systems, School of Engineering, The University of Edinburgh, UK
Large Language Models (LLMs) have become an integral part of many real-world workflows. However, LLMs consume a lot of energy, which becomes a large concern in the scale of the demand for these tools. As LLMs become integrated into different workflows, different applications have arisen to deal with the challenge of running inference for these tools. This raises another issue of choosing the runtime parameter values for these services in order to minimize the energy consumption. Oftentimes this requires deep knowledge of the application or traditional optimization methods that can take days to find optimal values. In this work, we created a human-in-the-loop flow with LLM-assisted runtime parameter optimization in order to solve this issue. With human-created, specific feedback prompting methods, chat-based LLMs can iteratively find energy-efficient inference parameters faster than traditional search methods. LLMs can also tailor their solutions to different hardware setups and easily take into account other system constraints. The enhanced prompt template was able to converge below the threshold at an average of 3.4 prompts compared to the baseline, which converged in an average of 5.2 prompts, and consistently achieved lower final energy per token. The enhanced prompt template also outperformed Sobol sampling in convergence speed.