DIMWIT: Directly Invoking Models Without Intensive Tuning

D IMWIT : D IRECTLY I NVOKING M ODELS W ITHOUT I NTENSIVE T UNING

arXiv:2611.01463v1 [cs.PF] 1 Nov 2026

Saarth Deshpande 1 Neeraja J. Yadwadkar 1 Venkat Arun 1

A BSTRACT Resource managers typically encode what to do in a task-specific policy—a heuristic, an optimization procedure, or a model trained for the task—that must be developed before use and may need revision as the workload or system changes. We propose bypassing policy development and instead asking pretrained models to make resource-management decisions directly, given the current system state, desired outcome, and available choices. We evaluate this approach on microservice autoscaling, DRAM sizing, and video encoding, using a frontier LLM and two small decision models. On two microservice applications, a small decision model meets latency targets while using within 10% of the replicas allocated by policy-based autoscalers and within 13% of the frontier LLM. In DRAM sizing, a small decision model reduces DRAM usage by up to 27.5% relative to static provisioning while maintaining at least 95% of baseline performance. In video encoding, it completes encodes up to 4.3× faster than the frontier LLM, with an imperceptible 1.1-point decrease in Video Multi-Method Assessment Fusion (VMAF), a metric of perceptual video quality. Making individual resource-management decisions may be considerably simpler than developing a general strategy for making them. 1

I NTRODUCTION

Many systems problems invite an unreasonable thought: “If I could just sit in the control loop, I would know what to do.” Resource management requires meeting performance targets without wasting resources, even as workloads and system conditions change. Say a service is overloaded while its neighbors are idle: give that service more replicas. Say an application gains little from additional fast memory: try giving it less. The intuition may be imperfect, but it is often easy to express. We might even want to steer a running system by saying “this is the service that’s misbehaving” or “err on the side of lower local DRAM usage,” and have it adjust accordingly. The obvious problem is that nobody wants to spend their day being a resource allocator. These decisions are typically automated using a resourcemanagement policy: a mapping from system measurements to actions. A hand-tuned threshold is a policy; so is a decision tree, an optimization procedure, or a neural network trained with reinforcement learning. They differ in how the mapping is obtained, but each must be designed, tuned, or trained for the task before the system can act, and may require revision as the workload or system changes. A simple policy, such as scaling replicas when CPU utilization exceeds a fixed threshold, may waste resources or fail to meet performance targets (Gan et al., 2019). Making these poli1 The University of Texas at Austin. Correspondence to: Saarth Deshpande <saarth@utexas.edu>.

cies effective often requires domain expertise, applicationspecific profiling, and repeated experimentation to balance resource consumption against performance targets. More recently, LLMs have been used to generate and refine such heuristics (Romera-Paredes et al., 2024; Dwivedula et al., 2025), but the output is still a policy that must be produced and validated before use. This paper asks whether we can skip developing a task-specific policy altogether. For some applications, we can instead ask a language model to make each decision directly. This is practical when the system can tolerate the LLM’s inference latency and the inference cost is offset by the number of resources being managed. Decision models such as Jev (Almeida, 2026) and Laya (Convai Innovations, 2026) make this practical for many more applications: a decision takes 0.1–0.2 s with Jev or with Laya on a GPU (2–3 s for Laya on a CPU with 16 threads), against 3–4 s for Opus 5.5 at low reasoning effort and 7–8 s at high. The proposition is slightly absurd, but concrete: instead of writing a policy that captures what we would do, describe the situation and ask what to do next. That is, make the relevant information explicit without prescribing how the model should use it to make a decision. We investigate whether pretrained models—general-purpose LLMs and small decision models—can make resourcemanagement decisions that minimize resource use while meeting performance targets, without developing a policy for each task. We also ask how sophisticated a model needs to be to make these decisions. We evaluate three models: Claude Opus 5.5 (Anthropic, 2026), a general-purpose LLM,

D IMWIT: Directly Invoking Models Without Intensive Tuning

Jev (Almeida, 2026), a proprietary decision model, and Laya (Convai Innovations, 2026), an open-weight 421Mparameter decision model. We refer to resource managers built using these models as D IMWIT resource managers. Our evaluation covers three representative use cases. First, we consider microservice applications, where we perform horizontal autoscaling: adjusting the number of replicas of each service to reduce resource use while meeting a latency target. Second, we consider applications that use both fast local DRAM and remote Compute Express Link (CXL) memory. Here, we dynamically adjust the amount of DRAM allocated to an application while keeping its slowdown within a limit. Third, we consider video compression, where we adjust compression settings to reduce encoding time while meeting a visual-quality target. As we show in §4, even the small decision models perform competitively with Claude Opus 5.5 and specialized resource-management systems across all three tasks, without task-specific training or profiling. In DRAM sizing and video encoding, Laya makes more aggressive choices than Opus 5.5, allocating up to approximately 19% less DRAM while meeting performance targets on six of eight workloads, and reducing encoding time by up to 4.3× within a 1.1-point reduction in perceptual video quality on a 100point scale, which is an imperceptible difference (Li et al., 2016). Our studies yield several conclusions. First, these problems are simple enough that large models do not always offer a meaningful advantage. A 421M-parameter open-source model performs competitively with a frontier LLM. Second, while these models do not dramatically outperform hand-designed heuristics, and sometimes perform worse, they achieve comparable results without requiring the development of task-specific policies. They allow the developer to “talk” to their systems to tweak their behavior. This makes them a practical alternative when developers need a quick heuristic but lack the time to translate their intuition into a control algorithm, provided the application can tolerate the inference overhead. Having a model-in-the-loop ensures common sense and prevents catastrophically bad performance.

2

I S THE DECISION THE EASY PART ?

Managing resources like CPU and memory typically requires task-specific mechanisms to decide what actions to take, whether through learned models, optimization algorithms, or hand-tuned heuristics. In each case, the intuition about what to do must first be made precise—written as a rule, posed as an optimization, or learned from data— before the system can act on it. We explore an alternative: describe the current system state, the desired outcome, and

the available choices, and let a language model decide how to allocate resources. For this to work, the model must have enough relevant information to evaluate the tradeoffs between available choices. The challenge thus shifts from specifying how to make decisions to specifying the information needed to make them. Our main design question was simply: “If I could only see what the model sees, would I have enough information to make a decision?” When the answer was no, we added the missing information. Why are humans, LLMs and decision models comparable? Because many of the problems are simple enough that intelligence does not offer a meaningful advantage. Cleverness is necessary when designing an algorithm that must handle every eventuality. That is why many of these have been rich areas of research. Cleverness is less important when making the decision directly in the loop. This is the key insight of the paper. When the model did not make the desired trade-off, we could adjust the model’s behavior with instructions such as “err on the side of lower local memory usage,” without rewriting a heuristic or retraining a policy. All three tasks pose the model the same problem: choose among discrete configurations to minimize a cost while meeting a performance target. In horizontal autoscaling for microservices, this means minimizing the number of replicas while meeting latency targets; in DRAM sizing, minimizing allocated DRAM while maintaining performance; and in video encoding, minimizing encoding time while preserving video quality. Only the system state, available configurations, objectives, and constraints differ. Yet sharing the same structure does not make these decisions straightforward. For example, the effect of adding replicas depends on workload and interactions among services, while that of reducing DRAM depends on memory access patterns. These relationships are precisely what taskspecific mechanisms attempt to capture. How, then, can a language model make useful decisions without first learning or profiling them? We conjecture that useful resource-management decisions can be made from the system’s observed behavior, without learning either a model of the system or a task-specific decision policy. The current resource allocation, recent changes in workload and performance, and distance from the target may already be enough to determine what to adjust. What is difficult to encode as a general decisionmaking strategy may be considerably simpler to decide one instance at a time. If individual decisions are indeed simpler than learning a general decision-making strategy, how sophisticated does the model making them need to be? We investigate this using a frontier LLM (Anthropic, 2026) and two small decision models (Convai Innovations, 2026;

D IMWIT: Directly Invoking Models Without Intensive Tuning

Almeida, 2026), asking each to solve the same resourcemanagement problems. The next section describes what information each model receives, what choices it makes, and how its decisions are applied.

History

D IMWIT Autoscaler

RPS

Metrics API

Set replicas = R

3

I MPLEMENTATION

3.1

Horizontal Autoscaling

Microservice applications consist of multiple interacting services whose resource demands change with workload (Gan et al., 2019). Horizontal autoscaling adjusts the number of replicas of each service in response to changing workloads while satisfying application latency Service-Level Objectives (SLOs) (Sachidananda & Sivaraman, 2024). However, determining which services to scale and by how much requires reasoning about how different resource allocations affect end-to-end performance (Zhang et al., 2021; Sachidananda & Sivaraman, 2024). We integrate the D IMWIT autoscalers with Kubernetes by replacing the scaling policy of its Horizontal Pod Autoscaler (HPA) (Kubernetes, 2024), the most widely used autoscaler today (Datadog, 2026). Every 15 seconds, the pretrained models determine the replica counts for the application’s microservices. We apply these decisions by setting the minimum and maximum replica counts of the corresponding HPA objects to the selected values, allowing Kubernetes to carry out the scaling operations (see Figure 1). When autoscaling, each D IMWIT model is provided the following state: current replica count of a service, its CPU and memory utilization, time since the last replica change, and its average replica startup time. We also provide the latency SLO, per-endpoint request rates and p95 latencies, and the change in each endpoint’s request rate over the past 60 seconds. In addition to these inputs, Opus 5.5 receives a history of its previous scaling decisions and the reasoning it provided for those decisions, including its assessment of workload trends and resource requirements. To manage the overhead of model inference, we batch the states of multiple services into a single request to Laya, since invoking the self-hosted model separately for each service would be computationally expensive. Unlike Opus 5.5, which jointly determines the replica counts of all services in a single decision, Laya’s batching groups independent per-service decisions into one API call. Jev does not support batched requests, so we issue one API call per service every 15 s. We ask Laya and Jev to choose among seven scaling factors: 0.25, 0.5, 0.75, 1, 1.5, 2, and 2.5 times the current replica count, subject to a minimum of 1 and a maximum of 50 replicas per service. Opus 5.5 instead selects the absolute replica count of every service in a single decision. We

HPA Controller

Utilizations

Metrics Server

Deployment Kubernetes

Figure 1. Architecture common to the D IMWIT autoscalers. At each tick, the autoscaler reads per-service utilization via the Kubernetes Metrics API and patches the service’s HPA object with the desired replica count R, causing HPA to adjust the service’s Deployment.

instruct all three models to select the minimum number of replicas needed to meet the p95 latency SLO under the load expected during replica startup. We also instruct them to scale out proactively when increased load is anticipated, while otherwise preferring to keep or reduce replicas instead of overprovisioning. 3.2

Dynamic DRAM Sizing

Tiered memory systems combine fast DRAM with slower, cheaper memory such as CXL to reduce memory costs (Maruf et al., 2023; Li et al., 2023). DRAM sizing determines how much memory to allocate to the fast tier while maintaining application performance. We implement the D IMWIT sizers on top of ARMS (Yadalam et al., 2025), a state-of-the-art tiering system. ARMS uses PEBS (Intel Corporation., 2018) to sample per-page accesses and compute page hotness scores. Periodically, it ranks pages by hotness, migrating the hottest pages to DRAM and the coldest to CXL. Every 30 seconds, each D IMWIT sizer makes a decision using the state, sizing options, and prompt described below. We provide each sizer with the current DRAM allocation, the estimated slowdown at that allocation, and three onesecond samples of memory-access behavior. We estimate this slowdown as (1 − s0 )/(1 − s) − 1, where s is the stall fraction measured at the current allocation over the latest 30-second interval and s0 is a reference stall fraction measured after warm-up. Each sample includes access rates and estimated latencies for DRAM and CXL, memory-level parallelism, and the estimated fraction of all accesses that would shift from DRAM to CXL if the DRAM allocation were reduced by 4 GiB. We estimate DRAM and CXL latencies from each tier’s measured bandwidth using per-tier

D IMWIT: Directly Invoking Models Without Intensive Tuning Parameter

Description

subme me ref trellis bframes b strategy

Precision of motion estimation and optimization of block encoding Motion search algorithm Number of reference frames used for prediction Optimization of quantized values Maximum number of consecutive B-frames Algorithm for selecting B-frame positions

Choices

FFmpeg Default

2, 4, 7, 9 dia, hex, umh 1, 3, 5 0, 1, 2 0, 3, 5 0, 1, 2

7 hex 3 1 3 1

Table 1. x264 encoding parameters available to the LLMs, their allowed values, and the defaults under the medium preset.

bandwidth–latency curves, with linear interpolation within the profiled range. We ask each sizer to choose among reducing DRAM by 4 GiB, keeping the current allocation, or increasing DRAM by 4 GiB, with the goal of minimizing DRAM usage while satisfying the slowdown budget. We conservatively target a slowdown 4 percentage points below the specified budget (e.g., 1% for a 5% budget), reserving 2 percentage points for estimation errors and another 2 as additional safety margin. Despite this conservatism, Laya and Jev perform well within the 95% performance target and Laya saves more DRAM than TierSizer (see §4.3). Unlike Laya and Jev, Opus 5.5 also receives a history of its previous sizing decisions and reasoning, since its larger context window can accommodate this additional information. We instruct the D IMWIT model to minimize DRAM allocation while meeting the performance target, encouraging it to err on the side of trying a smaller allocation when it expects the target to remain satisfied. Every 30 seconds, it chooses whether to decrease DRAM by 4 GiB, maintain the current allocation, or increase DRAM by 4 GiB. The selected allocation is applied through ARMS. 3.3

Video Compression

At a fixed bitrate, video encoders trade encoding time for video quality (Amirpour et al., 2023; MSU Graphics & Media Lab, 2008). A video is a sequence of frames, each divided into small blocks of pixels. Rather than store each block’s pixels directly, the encoder predicts them from neighboring blocks or other frames and stores only the difference. For each block, it evaluates candidate predictions and selects the one with the lowest estimated rate-distortion cost (Sullivan & Wiegand, 1998). Evaluating more candidates can improve video quality at a given bitrate but takes longer. Video quality is commonly measured using Video MultiMethod Assessment Fusion (VMAF) (Li et al., 2016), a perceptual metric that estimates visual quality on a scale from 0 to 100, with higher scores indicating better quality. As Figure 2 illustrates, encoder configurations span a range of encoding times and video quality at a fixed bitrate. Selecting effective configurations is challenging because encoding parameters affect one another, making it difficult to deter-

Use case Autoscaling (past decisions) DRAM Sizing (1 s access samples) Video Compression (past segments)

Laya

Jev

Opus 5.5

– 3 2

– 3 5

10 10 5

Table 2. Past observations in each model’s state. Opus 5.5 also sees its own past reasoning for those decisions.

mine their combined impact on encoding time and video quality (Amirpour et al., 2023). Finding effective configurations can require repeated execution: Netflix’s Dynamic Optimizer (Netflix TechBlog, 2018), for example, encodes each video shot using multiple configurations to identify favorable quality–bitrate tradeoffs. We investigate whether pretrained models can select encoder configurations without evaluating multiple configurations through repeated encoding. We divide each video into 5-second segments and ask a D IMWIT model to select encoding parameters for each segment, with the goal of minimizing encoding time while maintaining an average VMAF across the video at least as high as that achieved by x264’s default configuration. After encoding each segment, we measure its VMAF and encoding time, which the model uses to select parameters for the next segment. The six parameters and the values the model can select are listed in Table 1. Unlike autoscaling with the small decision models and DRAM sizing, which select changes relative to the current configuration (scaling factors and ±4 GiB, respectively), video encoding selects absolute values for each encoder parameter. This lets the model choose any allowed value, regardless of the current setting. The model receives the target VMAF, the average VMAF achieved so far, the minimum average required over the remaining segments to meet the target, the remaining video duration, the current settings, and the settings, VMAF, and CPU time of the last five segments. We also provide a short description of each setting’s effect on encoding speed and quality.

D IMWIT: Directly Invoking Models Without Intensive Tuning

Figure 2. Example frame from Elephants Dream (Blender Foundation, 2006), shown uncompressed (left) and encoded at the same bitrate using two different x264 encoder configurations (center and right). The encoded versions achieve VMAF scores of 94.59 and 38.51, respectively, illustrating how encoder settings affect video quality.

4

E VALUATION

of its bundled load generator.

4.1

Model Configuration.

Kubernetes specifies guaranteed resource allocations through requests and maximum allocations through limits. For Online Boutique, each replica has CPU requests/limits of 1000m/2000m and memory requests/limits of 64/128 MiB, except redis-cart, which retains its defaults of 70m/125m CPU and 200/256 MiB memory. TeaStore uses the same CPU configuration as Online Boutique, with 2 GiB for both memory requests and limits. Social Network uses 500m/1000m CPU and 128/256 MiB memory.

We use Laya’s english model and jev-latest for Jev, with default input token limits of 512 (Convai Innovations) and 32,000 (Jev AI), respectively. Laya’s limit applies to each question–state pair, with up to 192 tokens reserved for the question and its options, which restricts the history it can be given compared with Jev and Opus 5.5. We therefore give Laya a shorter window of recent history than Jev and Opus 5.5 in each of the following use cases. Table 2 summarizes the history provided to each model. 4.2

Horizontal Autoscaling

We evaluate how well D IMWIT autoscalers minimize resource allocation while satisfying per-endpoint p95 latency Service-Level Objectives (SLOs) under changing workloads. 4.2.1

Experimental Setup

Cluster. We run experiments on a CloudLab (Duplyakin et al., 2019) cluster, comprising 15 r320 nodes: one control-plane instance, 13 worker instances running Kubernetes deployed with kubeadm, and one dedicated node hosting Laya. Application pods are scheduled only on the worker instances; autoscalers run on the control-plane instance. Opus 5.5 and Jev are accessed through their respective APIs.

Benchmarks. We evaluate three microservice applications: TeaStore (von Kistowski et al., 2018) (7 services), Online Boutique (GoogleCloudPlatform, 2020) (11 services), and Social Network (Gan et al., 2019) (20 services). For Social Network, we exclude MongoDB instances from autoscaling because their Kubernetes Deployment configuration does not support sharding, causing replicas to contend for the same persistent volume. For Online Boutique, we use an external Locust (Locust team, ongoing) instance instead

Workloads. For each application, we derive replay workloads from Alibaba production traces (Luo et al., 2021), and use the HTTP-entrypoint microservice call rate (MCR) as the workload signal. These HTTP entrypoints provide the most direct measure of offered load. Using call-rate measurements from internal service interactions would instead make the workload signal depend on application-specific implementation details rather than externally imposed demand. Since the original request-rate data is available at 60 s granularity, we linearly interpolate it to 15 s resolution for replay. We assign one such workload trace to each application endpoint and rescale the resulting demand to match the capacity of the target deployment. Locust is configured with 100 users and a ramp-up of 1 user/s for TeaStore and Online Boutique, and with 1000 users and a ramp-up of 100 users/s for Social Network. Baselines. We compare the D IMWIT autoscalers against Erlang (Sachidananda & Sivaraman, 2024), a banditlearning horizontal autoscaler, Agar (Deshpande et al., 2026), which uses analytical models to allocate the minimum number of replicas needed to meet a target SLO, and the Kubernetes Horizontal Pod Autoscaler (HPA) (Kubernetes, 2024), configured with hand-tuned utilization thresholds and scaling policies. Given Jev’s low inference latency, we evaluate two variants: Jev-Single, which makes scaling decisions for each microservice using only its local state, and Jev-Batched, which makes a separate scaling

decision for each microservice using the shared state of all microservices. Since most prior work focuses on vertical autoscaling (Zhang et al., 2021; Saxena et al., 2026; Wang et al., 2024), we use Erlang and Agar as our research baselines. We tune HPA through extensive experimentation, iteratively adjusting its scaling thresholds based on observed scaling behavior under load, as is common in production autoscalers (Knative Project, 2024; Google Cloud, 2024; Amazon Web Services, 2024; Google Cloud, 2026). We train both Erlang and Agar’s models on the first six hours of Alibaba traces and evaluate all autoscalers on the subsequent two hours.

The information available to the models also matters. Although Laya’s requests are batched for inference efficiency, each decision sees only its own service’s resource state. On TeaStore, Laya and Jev-Single request more replicas than the cluster can accommodate, leaving excess pods in the Pending state while violating the SLO. Providing Jev with application-wide state reduces replica allocation by over 6× on both TeaStore and Social Network, and eliminates the SLO violations on TeaStore. However, Jev-Batched remains less resource-efficient than the other autoscalers on Social Network.

Erlang

Agar

Laya

Opus-Low

Opus-High

Jev-Single

Jev-Batch

300 200 100 0 20

40 Replicas (a) Online Boutique

60

300 200 100 0 20

40 Replicas (b) Social Network

60

400

340

360

60K 300 200 100 0

0

20

40

60

80

220

240

Replicas (c) TeaStore

Dynamic DRAM Sizing

We evaluate how much DRAM the D IMWIT sizers can save while maintaining at least 95% of the performance achieved with static DRAM provisioning. 4.3.1

Median p95 latency (ms)

Figure 3 compares the resource allocations and per-endpoint latencies achieved by each autoscaler. Additional reasoning effort substantially improves Opus 5.5’s decisions, particularly on TeaStore, where Opus-High achieves the lowest resource allocation among all autoscalers. However, greater model sophistication does not consistently yield better results: on Social Network, Laya achieves lower worstendpoint latency than Opus-High with approximately the same number of replicas.

4.3

HPA

Results

Median p95 latency (ms)

4.2.2

Median p95 latency (ms)

D IMWIT: Directly Invoking Models Without Intensive Tuning

Experimental Setup

Hardware Setup. We run our experiments on a c220g5 CloudLab (Duplyakin et al., 2019) node running Linux v6.18. We use remote NUMA memory to emulate the slow CXL tier. We lower the uncore frequency of the remote node to emulate longer slow tier latencies. Unloaded latency is ≈90 ns for local DRAM and ≈180 ns for the emulated CXL tier. Workloads. For our evaluation, we select a set of eight representative and diverse workloads shown in Table 3. These workloads have been widely used to evaluate tiered

Figure 3. Per-endpoint median p95 latency when horizontally scaling replicas using HPA, Erlang, Agar, Claude Opus 5.5 (low and high reasoning effort), Laya, and Jev on CloudLab. Jev-Single sends a separate request per service every 15 s, while Jev-Batched sends one batched request for all services every 15 s. The horizontal dashed line marks the 300 ms SLO. For each application, the boundary boxes show average running replicas, except for Jev-Single on Social Network and TeaStore and Laya on TeaStore, where they show requested replicas; excess pods remain Pending due to cluster capacity limits.

memory systems in prior works (Raybuck et al., 2021; Lee et al., 2023; Lepers & Zwaenepoel, 2023; Yang et al., 2017; Yadalam et al., 2026). We run these workloads with 16 threads, large enough to saturate the memory bandwidth of each system.

D IMWIT: Directly Invoking Models Without Intensive Tuning

TPC-C YCSB-C

75.68 71.40

In-memory transactional database.

Btree (Achermann & Panwar, 2020)

-

42.01

In-memory index lookup benchmark.

XSBench (Tramm et al., 2014)

-

64.97

Compute kernel of MCNP algorithm.

GUPS (Plimpton et al., 2006)

8 GiB hot

64.03

Skewed accesses with dynamic hotset.

0.5

0 Li bl

in e

ar

Table 3. DRAM sizing workload characteristics. Resident set size (RSS) is in GiB.

1

(a) DRAM savings. Target performance

Normalized performance

Baselines. We compare the D IMWIT DRAM sizers against TierSizer (Yadalam et al., 2026), a DRAM sizer that uses analytical models to predict application slowdown at unexecuted DRAM sizes and adjust allocations at runtime, and a static 2:1 DRAM:CXL ratio, representative of current stateof-the-art deployments (Maruf et al., 2023). Pond (Li et al., 2023) predicts DRAM allocations at VM startup and reverts to fully local DRAM if performance degrades, whereas our approach continuously adjusts DRAM allocations at runtime. We set the performance target to a 5% slowdown relative to this 2:1 baseline.

G U PS

Silo (Tu et al., 2013)

nc h

Compute connected components of graph

e

Compute PageRank score of a graph.

69.29

SB e

12.32

kronecker

Jev

X

twitter

GapBS-CC (Beamer et al., 2015)

Laya Opus-High

TierSizer Opus-Low

Bt re

GapBS-PR (Beamer et al., 2015)

Static 2:1 Peak Savings

S Y ilo CS B

Logistic regression-based classifier.

S TP ilo C- C

Description

20.69

CC

RSS

kddb

PR

Inputs

Liblinear (Fan et al., 2008)

DRAM (norm. to static)

Workload

1 0.95 0.8

Figure 4 compares DRAM allocations and performance across the eight workloads. The D IMWIT sizers achieve savings comparable to TierSizer on several workloads without learning application-specific performance models. On PageRank, Laya and Opus 5.5 reduce average DRAM allocation by approximately 25–30% while meeting the 95% performance target. Opus 5.5 also achieves savings of approximately 15–20% on XSBench and GUPS while maintaining performance. On both Silo workloads, all methods retain allocations close to static provisioning. The models differ in how aggressively they reduce DRAM. Jev generally retains more DRAM, particularly on Liblinear, PageRank, and connected components. Laya is more aggressive, achieving substantial savings on Liblinear and BTree, but violates the performance target on BTree, where performance falls to approximately 85% of the static baseline. In contrast to autoscaling, Opus-Low and Opus-High achieve nearly identical DRAM allocations and performance across most workloads, with little benefit from additional reasoning effort. 4.4

Video Compression

4.4.1

Experimental Setup

Machine Configuration. We run all encodes on a Dell Precision 3680 with an Intel Core i9-14900 (8 performance and 16 efficiency cores). x264 runs single-threaded through ffmpeg. Opus 5.5 and Jev are accessed through their APIs,

U PS G

ch X SB en

e Bt re

S Y ilo CS B

S TP ilo C- C

CC

PR

ea bl in Li

Results

r

0.6 4.3.2

(b) Performance. Figure 4. DRAM usage and performance achieved with TierSizer, Laya, Opus 5.5 (low and high reasoning effort), and Jev, normalized to static 2:1 DRAM provisioning. Bars show average DRAM usage and performance, while black markers indicate minimum DRAM usage (peak savings). The dashed red line marks the 95% performance target.

while Laya is served locally on an NVIDIA RTX 2000 Ada Generation GPU with 16 GB of memory.

Workloads. We evaluate three videos from the Xiph.org media collection (Xiph.Org Foundation): Big Buck Bunny (Blender Foundation, 2008), Elephants Dream (Blender Foundation, 2006), and Sintel Trailer (Blender Foundation, 2010). All videos have a resolution of 720p and a frame rate of 24 frames per second. We encode each video with a target bitrate of 2 Mbps.

Baselines. We compare Laya, Jev, and Opus 5.5 against x264’s default configuration using its medium preset. All models select encoding parameters every 5 seconds. We show the impact of varying this decision interval in our ablation experiments (§4.4.3).

D IMWIT: Directly Invoking Models Without Intensive Tuning Video

Duration

Motion Description

Big Buck Bunny (Blender Foundation, 2008) Elephants Dream (Blender Foundation, 2006) Sintel Trailer (Blender Foundation, 2010)

9:56 10:54 0:52

Colourful animation, smooth gradients, fine textures, moderate motion Dark, highly detailed mechanical scenes with complex camera movement Fast-paced action, rapid cuts and dynamic camera movement

Table 4. Videos used in our encoding experiments and their motion characteristics. All source videos are 720p at 24 fps, obtained from Xiph.org (Xiph.Org Foundation).

FFmpeg medium Sintel

Laya

Big Buck Bunny

Jev

Opus 5.5

Elephants Dream

Mean VMAF

97 96 Better

95 94 93

0

100 200 300 400 500 1,000 1,100 Encoding time (s)

Figure 5. Video quality (mean VMAF) versus encoding time across video clips, with encoding parameters updated every 5 seconds. Laya achieves the lowest encoding time on all videos while maintaining quality close to FFmpeg medium. A difference of 6 VMAF points is commonly considered barely perceptible to human viewers (Ozer, 2017). Smaller differences are generally imperceptible.

4.4.2

Figure 5 compares encoding time and mean VMAF for the three videos. Laya achieves the lowest encoding time across all three. On Big Buck Bunny and Elephants Dream, it reduces encoding time by approximately 40–45% relative to FFmpeg medium, with a reduction of less than two VMAF points. On Sintel, Laya achieves nearly the same quality as FFmpeg medium with a shorter encoding time. We found that Opus 5.5 selects substantially more expensive encoder configurations than Laya. On Big Buck Bunny and Elephants Dream, Opus-Low runs 4.3× and 3.8× longer than Laya, for a mean VMAF gain of <1 point. Most of the extra time came from the heavier encoder settings Opus picks, not from model calls: 70–73% of it is spent on encoding. For example, on Big Buck Bunny, Opus selects near-maximum encoding settings for 56 of 60 segments, while Laya selects faster motion estimation settings for approximately 45 segments. We also find little difference between Opus-Low and Opus-High: their VMAF scores differ by at most 0.04 points, while Opus-High takes 7–13% longer. 4.4.3

Laya

Mean VMAF

Encoding time (s)

Sintel

Jev

Big Buck Bunny

Results

Ablation Study

Opus 5.5 Elephants Dream

1,000 500 0

96 94

Figure 6 shows the effect of varying the interval between encoding-parameter decisions. Increasing the interval generally improves mean VMAF across the three videos by a few points, potentially too little to be perceptible to humans (Ozer, 2017), without a corresponding increase in encoding time. This suggests that more frequent decisions are not necessarily beneficial for video encoding, and that relatively infrequent adjustments can achieve favorable encoding-time–quality tradeoffs.

5

D ISCUSSION

92 1

2

5

10

Decision interval (s) Figure 6. Impact of decision interval, the time between encoding parameter updates, on encoding time and video quality for the three videos described in Table 4. Lower encoding time and higher VMAF are better.

The benefit of additional reasoning varies across resourcemanagement tasks. In microservice autoscaling, Opus with high reasoning effort substantially outperforms Opus with low reasoning effort, particularly on TeaStore. In contrast, additional reasoning provides little benefit in DRAM sizing and video encoding. In video encoding, despite explicit instructions to minimize encoding time subject to a quality target, Opus picks configurations that cost substantially more time than Laya’s for slightly higher VMAF.

D IMWIT: Directly Invoking Models Without Intensive Tuning

This motivates composing models with different capabilities for different decisions rather than relying on a single model: small, inexpensive decision models where additional reasoning showed no benefit, and more capable models where it did. In our autoscaling experiments, giving Jev applicationwide state substantially improves its decisions, even though it still chooses replica counts independently for each service. Future work could explore how to divide decisions among models with different capabilities and coordinate their actions.

DRAM allocations at VM startup and falls back to fully local DRAM if performance degrades, rather than continuously adjusting allocations at runtime. Vulcan (Tang et al., 2025) dynamically partitions a fixed DRAM budget among co-running workloads to improve fairness and efficiency, rather than sizing DRAM to meet individual performance targets. Tuna (Chen et al., 2024) dynamically sizes DRAM using offline-profiled microbenchmarks, but relies on predefined performance models that may generalize poorly to unseen workloads.

Although model outputs may be stochastic, restricting decisions to a finite set of choices allows us to treat the model as a nondeterministic component. This opens the possibility of using model checking to exhaustively explore possible actions and their interleavings, potentially providing formal guarantees for safety and liveness properties of a system. Verified safety constraints could then be enforced at runtime without prescribing how the model should decide.

Video encoding involves tradeoffs between encoding time, compression efficiency, and visual quality. Prior work characterizes these tradeoffs across encoder configurations (MSU Graphics & Media Lab, 2008) and selects among predefined encoding presets, each specifying a collection of encoder parameter settings (Amirpour et al., 2023). Content-adaptive approaches construct bitrate ladders by evaluating candidate encodings (Netflix TechBlog, 2018) or predicting bitrate–resolution combinations from video features (Katsenou et al., 2021). We select individual encoder parameters rather than presets, and adjust them per segment from observed encoding time and quality.

6

R ELATED W ORK

AI-assisted policy design. A growing line of work uses LLMs to search for algorithms and heuristics: FunSearch (Romera-Paredes et al., 2024) uses LLMs to discover mathematical constructions and bin-packing heuristics through iterative generation and evaluation. Vulcan (Dwivedula et al., 2025) generates heuristics tailored to specific systems. The ADRS framework (Cheng et al., 2025) applies the generate–evaluate–refine loop across scheduling, load balancing, and LLM-based SQL processing. Finally, AI-greement (Burgelin et al., 2026) uses agents to discover and formally verify a consensus protocol. In each case, the model’s output is an artifact—a program, a heuristic, a protocol—that is evaluated and subsequently executes without the model. In contrast, we use pretrained models to make resource-management decisions directly at runtime, rather than develop an algorithm or policy for making them.

Task-specific resource management. Most prior work on microservice resource management focuses on vertical scaling, adjusting CPU and memory allocations per service (Zhang et al., 2021; Qiu et al., 2020; Wang et al., 2024; Saxena et al., 2026). Horizontal autoscaling instead adjusts replica counts, using threshold-based controllers (Kubernetes, 2024; Google Cloud, 2026; 2024; Amazon Web Services, 2024), bandit-based approaches (Sachidananda & Sivaraman, 2024), or analytical what-if models (Deshpande et al., 2026). In tiered memory, systems such as TPP (Maruf et al., 2023), HeMem (Raybuck et al., 2021) and ARMS (Yadalam et al., 2025) use policies to place frequently accessed pages in DRAM, while TierSizer (Yadalam et al., 2026) uses analytical models to determine DRAM allocations at runtime. Pond (Li et al., 2023) predicts

Learned models as the policy. Reinforcement learning has been used to train runtime policies for cluster scheduling (Mao et al., 2019), adaptive-bitrate streaming (Mao et al., 2017), and congestion control (Jay et al., 2019). These systems learn decision policies from task-specific experience, often collected through simulation, using rewards that encode the desired behavior. Although the resulting policies can generalize to unseen workloads and environments, they still require training for their respective tasks. D IMWIT models receive no such training; they act on the current state, objective, and available actions alone.

7

C ONCLUSION

Resource management has traditionally relied on taskspecific policies that map system measurements to actions. We investigate whether explicitly developing such policies is necessary. Across microservice autoscaling, DRAM sizing, and video encoding, we find that pretrained models can make competitive decisions directly from observed system state, objectives, and available choices, without taskspecific training or policy development. Small decision models achieve results comparable to a frontier LLM and policy-based systems in several cases, though not always within performance targets. Our results challenge the assumption that effective resource management must begin with developing a task-specific policy. This work does not raise any ethical questions.

D IMWIT: Directly Invoking Models Without Intensive Tuning

R EFERENCES Achermann, R. and Panwar, A. Mitosis workload btree. 2020. URL https://github.com/mitosis-p roject/mitosis-workload-btree. Almeida, D. Introducing System One Models & Jev. TypeSafe AI Blog, September 2026. URL https: //typesafe.ai/blog/introducing-syste m-one-models-and-jev. Accessed: 2026-10-24. Amazon Web Services. Target tracking scaling policies for Amazon EC2 auto scaling. https://docs.aws.a mazon.com/autoscaling/ec2/userguide/ as-scaling-target-tracking.html, 2024. Accessed: 2025-06-20. Amirpour, H., Menon, V. V., Afzal, S., Prodan, R., and Timmerer, C. Optimizing video streaming for sustainability and quality: The role of preset selection in per-title encoding. In IEEE International Conference on Multimedia and Expo (ICME), pp. 1679–1684, 2023. doi: 10.1109/ICME55011.2023.00289. Anthropic. Introducing claude opus 5.5. https://ww w.anthropic.com/claude-opus-5-5, 2026. Accessed: 2026-10-30. Beamer, S., Asanović, K., and Patterson, D. The gap benchmark suite. arXiv preprint arXiv:1508.03619, 2015. Blender Foundation. Elephants Dream. https://oran ge.blender.org/, 2006. Blender Foundation. Big Buck Bunny. https://peac h.blender.org/, 2008. Blender Foundation. Sintel. https://durian.blend er.org/, 2010. Burgelin, C., Guerraoui, R., Hong, Z., Hu, Y., Kermarrec, A.-M., Pires, R., Veski, R. M., and de Vos, M. The end of consensus research?, 2026. URL https://arxiv. org/abs/2610.30114. Chen, S., Huang, J., Yang, S., Liu, J., Li, H., Nikolopoulos, D., Ryu, J., Baek, J., Shin, K., and Li, D. Tuning fast memory size based on modeling of page migration for tiered memory. arXiv preprint arXiv:2410.00328, 2024. Cheng, A., Liu, S., Pan, M., Li, Z., Wang, B., Krentsel, A., Xia, T., Cemri, M., Park, J., Yang, S., Chen, J., Agrawal, L., Desai, A., Xing, J., Sen, K., Zaharia, M., and Stoica, I. Barbarians at the gate: How ai is upending systems research, 2025. URL https://arxiv.org/abs/ 2510.06189. Convai Innovations. Laya. https://huggingface. co/convaiinnovations/laya.

Convai Innovations. Laya. Hugging Face model card, 2026. URL https://huggingface.co/convaiinn ovations/laya. Accessed: 2026-10-24. Datadog. State of containers and serverless. https://ww w.datadoghq.com/state-of-containers-a nd-serverless/, 2026. Accessed: 2026-09-03. Deshpande, S., Yadwadkar, N. J., and Arun, V. Agar: Whatif analysis for microservice applications, 2026. URL https://arxiv.org/abs/2610.36636. Duplyakin, D., Ricci, R., Maricq, A., Wong, G., Duerig, J., Eide, E., Stoller, L., Hibler, M., Johnson, D., Webb, K., Akella, A., Wang, K., Ricart, G., Landweber, L., Elliott, C., Zink, M., Cecchet, E., Kar, S., and Mishra, P. The design and operation of CloudLab. In Proceedings of the USENIX Annual Technical Conference (ATC), pp. 1–14, July 2019. URL https://www.flux.utah.edu/ paper/duplyakin-atc19. Dwivedula, R., Saxena, D., Yadalam, S., Campbell, E. H., Kim, D., and Akella, A. Vulcan: Instance-specialized, verifiable systems heuristics through llm-driven search. arXiv preprint arXiv:2512.25065, 2025. Fan, R.-E., Chang, K.-W., Hsieh, C.-J., Wang, X.-R., and Lin, C.-J. Liblinear: A library for large linear classification. The Journal of machine Learning research, 2008. Gan, Y., Zhang, Y., Cheng, D., Shetty, A., Rathi, P., Katarki, N., Bruno, A., Hu, J., Ritchken, B., Jackson, B., Hu, K., Pancholi, M., He, Y., Clancy, B., Colen, C., Wen, F., Leung, C., Wang, S., Zaruvinsky, L., Espinosa, M., Lin, R., Liu, Z., Padilla, J., and Delimitrou, C. An open-source benchmark suite for microservices and their hardware-software implications for cloud & edge systems. In Proceedings of the Twenty-Fourth International Conference on Architectural Support for Programming Languages and Operating Systems, ASPLOS ’19, pp. 3–18, New York, NY, USA, 2019. Association for Computing Machinery. ISBN 9781450362405. doi: 10.1145/3297858.3304013. URL https: //doi.org/10.1145/3297858.3304013. Google Cloud. Autoscaling groups of instances. https: //cloud.google.com/compute/docs/auto scaler, 2024. Accessed: 2025-06-20. Google Cloud. About autoscaling workloads based on metrics. https://docs.cloud.google.com/ku bernetes-engine/docs/concepts/custom -and-external-metrics, 2026. Google Kubernetes Engine documentation, last updated 2026-03-26, accessed 2026-03-30.

D IMWIT: Directly Invoking Models Without Intensive Tuning

GoogleCloudPlatform. Online Boutique: A cloud-native microservices demo application. https://github .com/GoogleCloudPlatform/microservic es-demo, 2020. Intel Corporation. Intel 64 and ia-32 architectures software developer manuals. 2018. URL https://software .intel.com/articles/intel-sdm. Jay, N., Rotman, N. H., Godfrey, P. B., Schapira, M., and Tamar, A. A deep reinforcement learning perspective on internet congestion control. In Proceedings of the 36th International Conference on Machine Learning (ICML), volume 97 of Proceedings of Machine Learning Research, pp. 3050–3059. PMLR, 2019. Jev AI. Jev models. https://jev-ai.org/docs/m odels/. Katsenou, A. V., Sole, J., and Bull, D. R. Efficient bitrate ladder construction for content-optimized adaptive video streaming. IEEE Open Journal of Signal Processing, 2: 496–511, 2021. doi: 10.1109/OJSP.2021.3086691. Knative Project. Autoscaling concepts. https://knat ive.dev/docs/serving/autoscaling/aut oscaling-concepts/, 2024. Accessed: 2025-0620.

Li, Z., Aaron, A., Katsavounidis, I., Moorthy, A., and Manohara, M. Toward a practical perceptual video quality metric, June 2016. URL https://netflixtechb log.com/toward-a-practical-perceptua l-video-quality-metric-653f208b9652. Locust team. Locust: A modern load testing framework, ongoing. https://locust.io/. Luo, S., Xu, H., Lu, C., Ye, K., Xu, G., Zhang, L., Ding, Y., He, J., and Xu, C. Characterizing microservice dependency and performance: Alibaba trace analysis. In Proceedings of the ACM Symposium on Cloud Computing, pp. 412–426, 2021. Mao, H., Netravali, R., and Alizadeh, M. Neural adaptive video streaming with Pensieve. In Proceedings of the Conference of the ACM Special Interest Group on Data Communication (SIGCOMM), pp. 197–210, 2017. doi: 10.1145/3098822.3098843. Mao, H., Schwarzkopf, M., Venkatakrishnan, S. B., Meng, Z., and Alizadeh, M. Learning scheduling algorithms for data processing clusters. In Proceedings of the ACM Special Interest Group on Data Communication (SIGCOMM ’19), pp. 270–288. ACM, 2019. doi: 10.1145/3341302.33 42080.

Kubernetes. Horizontal pod autoscaler. https://kube rnetes.io/docs/tasks/run-application /horizontal-pod-autoscale/, 2024. Accessed: 2025-06-20.

Maruf, H. A., Wang, H., Dhanotia, A., Weiner, J., Agarwal, N., Bhattacharya, P., Petersen, C., Chowdhury, M., Kanaujia, S., and Chauhan, P. Tpp: Transparent page placement for cxl-enabled tiered-memory. In Proceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, 2023.

Lee, T., Monga, S. K., Min, C., and Eom, Y. I. Memtis: Efficient memory tiering with dynamic page classification and page size determination. In Proceedings of the 29th Symposium on Operating Systems Principles, 2023.

MSU Graphics & Media Lab. Options analysis of mpeg-4 avc/h.264 codec x264. https://www.compressio n.ru/video/codec_comparison/x264_opt ions_analysis_08_en.html, 2008.

Lepers, B. and Zwaenepoel, W. Johnny cache: the end of {DRAM} cache conflicts (in tiered main memory systems). In 17th USENIX Symposium on Operating Systems Design and Implementation, 2023.

Netflix TechBlog. Dynamic optimizer: A perceptual video encoding optimization framework. https://netfli xtechblog.com/dynamic-optimizer-a-per ceptual-video-encoding-optimization-f ramework-e19f1e3a277f, 2018.

Li, H., Berger, D. S., Hsu, L., Ernst, D., Zardoshti, P., Novakovic, S., Shah, M., Rajadnya, S., Lee, S., Agarwal, I., Hill, M. D., Fontoura, M., and Bianchini, R. Pond: Cxl-based memory pooling systems for cloud platforms. In Proceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2, ASPLOS 2023, pp. 574–587, New York, NY, USA, 2023. Association for Computing Machinery. ISBN 9781450399166. doi: 10.1145/3575693.3578835. URL https: //doi.org/10.1145/3575693.3578835.

Ozer, J. Finding the just noticeable difference with netflix vmaf. Streaming Learning Center, 2017. URL https: //streaminglearningcenter.com/blogs/ finding-the-just-noticeable-differenc e-with-netflix-vmaf.html. Plimpton, S. J., Brightwell, R., Vaughan, C., Underwood, K., and Davis, M. A simple synchronous distributed-memory algorithm for the hpcc randomaccess benchmark. In 2006 IEEE International Conference on Cluster Computing, 2006.

D IMWIT: Directly Invoking Models Without Intensive Tuning

Qiu, H., Banerjee, S. S., Jha, S., Kalbarczyk, Z. T., and Iyer, R. K. FIRM: An intelligent fine-grained resource management framework for SLO-Oriented microservices. In 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20), pp. 805–825. USENIX Association, November 2020. ISBN 978-1-939133-19-9. URL https://www.usenix.org/conference/ osdi20/presentation/qiu. Raybuck, A., Stamler, T., Zhang, W., Erez, M., and Peter, S. Hemem: Scalable tiered memory management for big data applications and real nvm. In Proceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles, 2021. Romera-Paredes, B., Barekatain, M., Novikov, A., Balog, M., Kumar, M. P., Dupont, E., Ruiz, F. J. R., Ellenberg, J. S., Wang, P., Fawzi, O., Kohli, P., and Fawzi, A. Mathematical discoveries from program search with large language models. Nature, 625(7995):468–475, January 2024. doi: 10.1038/s41586-023-06924-6. URL https://www.nature.com/articles/s415 86-023-06924-6. Sachidananda, V. and Sivaraman, A. Erlang: Applicationaware autoscaling for cloud microservices. In Proceedings of the Nineteenth European Conference on Computer Systems, EuroSys ’24, pp. 888–923, New York, NY, USA, 2024. Association for Computing Machinery. ISBN 9798400704376. doi: 10.1145/3627703.3650084. URL https://doi.org/10.1145/3627703.3650 084. Saxena, D., Vipat, G., Lin, J., Wang, J., Dillig, I., Shakkottai, S., and Akella, A. Towards performance robustness for microservices. In 23rd USENIX Symposium on Networked Systems Design and Implementation (NSDI 26), pp. 93–112, Renton, WA, May 2026. USENIX Association. ISBN 978-1-939133-54-0. URL https: //www.usenix.org/conference/nsdi26/p resentation/saxena. Sullivan, G. J. and Wiegand, T. Rate-distortion optimization for video compression. IEEE Signal Processing Magazine, 15(6):74–90, 1998. doi: 10.1109/79.733497. Tang, W., Wang, Y., Wang, Y., and Wu, J. Leave no one behind: Fair and efficient tiered memory management for multi-applications. In Proceedings of the 54th International Conference on Parallel Processing, pp. 699–709, 2025. Tramm, J. R., Siegel, A. R., Islam, T., and Schulz, M. XSBench: The development and verification of a performance abstraction for monte carlo reactor analysis. In PHYSOR 2014: The Role of Reactor Physics toward a

Sustainable Future, 2014. URL https://www.mcs. anl.gov/papers/P5064-0114.pdf. Tu, S., Zheng, W., Kohler, E., Liskov, B., and Madden, S. Speedy transactions in multicore in-memory databases. In Proceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles, 2013. von Kistowski, J., Eismann, S., Schmitt, N., Bauer, A., Grohmann, J., and Kounev, S. TeaStore: A Micro-Service Reference Application for Benchmarking, Modeling and Resource Management Research. In Proceedings of the 26th IEEE International Symposium on the Modelling, Analysis, and Simulation of Computer and Telecommunication Systems, MASCOTS ’18, September 2018. Wang, Z., Li, P., Liang, C.-J. M., Wu, F., and Yan, F. Y. Autothrottle: A practical Bi-Level approach to resource management for SLO-Targeted microservices. In 21st USENIX Symposium on Networked Systems Design and Implementation (NSDI 24), pp. 149–165, Santa Clara, CA, April 2024. USENIX Association. ISBN 978-1-93913339-7. URL https://www.usenix.org/confe rence/nsdi24/presentation/wang-zibo. Xiph.Org Foundation. Xiph.org video test media. https: //media.xiph.org/. Accessed: 2026-10-29. Yadalam, S., Kanellis, K., Swift, M., and Venkataraman, S. Arms: Adaptive and robust memory tiering system. arXiv preprint arXiv:2508.04417, 2025. Yadalam, S., Deshpande, S., Saxena, D., Arun, V., Yadwadkar, N. J., and Akella, A. TierSizer: Counterfactual reasoning for DRAM sizing in tiered memory systems. In 4th Workshop on Disruptive Memory Systems (DIMES), 2026. Yang, Z., Hoseinzadeh, M., Andrews, A., Mayers, C., Evans, D. T., Bolt, R. T., Bhimani, J., Mi, N., and Swanson, S. Autotiering: Automatic data placement manager in multitier all-flash datacenter. In 2017 IEEE 36th International Performance Computing and Communications Conference, 2017. Zhang, Y., Hua, W., Zhou, Z., Suh, G. E., and Delimitrou, C. Sinan: Ml-based and qos-aware resource management for cloud microservices. In Proceedings of the 26th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, ASPLOS ’21, pp. 167–181, New York, NY, USA, 2021. Association for Computing Machinery. ISBN 9781450383172. doi: 10.1145/3445814.3446693. URL https: //doi.org/10.1145/3445814.3446693.

D IMWIT: Directly Invoking Models Without Intensive Tuning

AI U SAGE D ISCLOSURE Generative AI tools, specifically ChatGPT and Claude Code, were used to assist with literature searches and citation verification, code development and debugging, and drafting and editing portions of the manuscript. The models evaluated in this paper were also used to make resource-management decisions in the experiments, as described in the paper. The key ideas and experimental design were developed by the human authors, and experimental results were obtained from actual system executions. The authors reviewed and edited all AI-assisted outputs and take full responsibility for the paper’s content, including the accuracy of its claims and citations.

Related documents

• Remember Your Trace: Memory-Guided Long-Horizon Agentic Framework for Consistent and Hierarchical Repository-Level Code Documentation#1141539
• Coupled-task scheduling with time windows, bounded pathwidth and bounded slack is para-NP-complete#129474
• Tool Attention Is All You Need: Dynamic Tool Gating and Lazy Schema Loading for Eliminating the MCP/Tools Tax in Scalable Agentic Workflows#126555
• VeRA: Renewing Reasoning Benchmarks with Executable Specifications#1049754
• nvidia/OpenMathReasoning#786575