Eudoxia: Deterministic FaaS Simulator

• Eudoxia is a deterministic simulator for scheduling FaaS workloads in Bauplan's DLH, designed to evaluate SQL, Python, and system actions as ephemeral functions.
• It models pipelines as DAGs with precise operator resource requirements, memory thresholds, and CPU scaling functions for realistic performance estimates.
• The simulator supports AI-driven policy discovery by executing LLM-generated scheduling algorithms and providing detailed, repeatable performance metrics.

Eudoxia is an open-source, deterministic simulator for scheduling Function-as-a-Service (FaaS) workloads in Bauplan, a composable data lakehouse (DLH) built on “spare data parts” and a unified runtime for SQL queries and Python pipelines. It was introduced to let developers evaluate scheduling algorithms cheaply and reproducibly against a function-first execution model in which SQL blocks, Python functions, and system actions are all expressed as ephemeral functions over object storage, with Tables as the core data interchange type. In subsequent work, the simulator also serves as the deterministic verifier in a generate-and-verify loop in which LLMs propose Python scheduling policies and Eudoxia executes them on standardized traces, returning metrics such as throughput, p99 latency, and failed DAGs (Srivastava et al., 19 May 2025, Tagliabue, 20 Oct 2025).

1. Bauplan context and the scheduling problem

Eudoxia emerges from Bauplan’s “function-first” programming and execution model. In that model, all computation is written “as a function” with signature Table(s) → Table and is executed “as a function” on off-the-shelf VMs. User pipelines are DAGs composed of SQL blocks and Python functions; system-level actions such as branch checkout, object store reads, and materialization are themselves functions injected by a logical planner. Ephemeral functions spawn in milliseconds inside VMs, and nothing persists before or after a request: no container, warehouse, or engine (Srivastava et al., 19 May 2025).

This execution model creates a scheduling regime with several distinctive constraints. Workloads are heterogeneous in both structure and service objective: batch pipelines, iterative development runs, and interactive queries differ in latency sensitivity and fairness requirements. Individual functions have limited horizontal scaling, because each function executes within a single VM; scale-ups are vertical, in CPU and RAM, rather than horizontal splitting. Memory-driven failures are explicit, since allocations below an operator’s minimum RAM requirement induce OOM and necessitate rescheduling. CPU scale-up behavior is also variable: IO-bound operators may not benefit from additional CPUs, whereas compute-bound operators may exhibit near-linear improvement up to saturation. Preemption and autoscaling further complicate policy design, because interactive queries may need to preempt batch workloads and resource pools may expand at monetary cost (Srivastava et al., 19 May 2025).

A common misconception is to treat Eudoxia as a generic cloud simulator. The papers instead position it specifically around composable DLH workloads executed in a unified FaaS runtime on single or few pools of VMs. Its target problem is not generic cluster management in the abstract, but function-level scheduling trade-offs in lakehouse environments where interleaving interactive and non-interactive workloads is beneficial (Srivastava et al., 19 May 2025).

2. Formal model of workloads, resources, and objectives

Eudoxia models workloads as pipelines, or jobs, each represented as a directed acyclic graph of operators. For a pipeline $p$, the DAG is $G_p = (V_p, E_p)$ with operators $i \in V_p$ and edges $i \to j \in E_p$ indicating precedence. Pipelines arrive according to a user-configured renewal process with inter-arrival times drawn from a prescribed distribution centered at waiting_ticks_mean, in ticks where one tick $\approx 10$ microseconds. In configurations using exponential inter-arrivals, the arrival rate is

$$\lambda = 1 / (\text{waiting\_ticks\_mean} \times 10\,\mu s).$$

Each operator $i$ has a memory requirement $m_i$ in GB, a CPU scaling function $f_i(k)$ giving duration in ticks under $k$ allocated CPUs, and a priority class inherited from the pipeline, with $G_p = (V_p, E_p)$0 (Srivastava et al., 19 May 2025).

Resources are organized into one or more pools. Each pool has CPU capacity $G_p = (V_p, E_p)$1 and RAM capacity $G_p = (V_p, E_p)$2. At time $G_p = (V_p, E_p)$3, a container allocation assigns to an operator set a tuple $G_p = (V_p, E_p)$4 of CPUs and RAM from a specific pool. An allocation runs until completion or until OOM. The scheduler maintains queues by priority and pool, tracks active containers, and issues preemptions; precedence constraints prohibit starting a downstream operator before its parents complete (Srivastava et al., 19 May 2025).

The formal constraints given for this model include:

$G_p = (V_p, E_p)$5

for DAG edges $G_p = (V_p, E_p)$6,

$G_p = (V_p, E_p)$7

and

$G_p = (V_p, E_p)$8

Depending on policy, allocations may be non-preemptive or preemptive; if preempted, allocated resources are freed immediately and the operator returns to the scheduler queues (Srivastava et al., 19 May 2025).

The simulator does not fix a single optimization objective. Instead, it supports makespan, average completion time, priority-weighted latency with weights $G_p = (V_p, E_p)$9, average waiting time, throughput, utilization, and monetary cost if autoscaling is enabled. The average waiting time is given as

$i \in V_p$0

and utilization for pool $i \in V_p$1 is reported as

$i \in V_p$2

The cost objective integrates resource-time usage across pools (Srivastava et al., 19 May 2025).

3. Simulator architecture and deterministic execution semantics

Eudoxia is a deterministic, modular, tick-driven simulator whose main loop executes one iteration per tick. Its architecture comprises three core components: a Workload Generator, a Scheduler, and an Executor. The Workload Generator produces pipelines at configurable intervals; each pipeline’s DAG and operator attributes can be drawn from user-specified distributions centered at provided parameters or loaded from external traces. The Scheduler receives newly arrived pipelines and failures from the previous tick and decides resource assignments and preemptions. The Executor manages pools and containers, validates memory sufficiency, computes predicted completion time using $i \in V_p$3 for assigned operators, and advances execution (Srivastava et al., 19 May 2025).

In the generate-and-verify setting, the same three-module structure is described as Generator → Scheduler → Executor, run to completion after users set simulator parameters and pass them to the initializer. Built-in APIs expose resource pools, priority queues, and hardware consumption so that policies can reason about capacity and contention. Determinism and metrics collection are first-class features: runs are repeatable under fixed seeds and parameters, and the simulator outputs performance statistics at the end, including throughput, p99 latency, and number of failed DAGs. The later paper also notes optional runtime monitors to verify safety invariants during policy evaluation, including no oversubscription and bounded waiting (Srivastava et al., 19 May 2025, Tagliabue, 20 Oct 2025).

This deterministic execution semantics is central to Eudoxia’s role as an offline verifier. Randomness can be eliminated by feeding real traces or controlled through generator parameters and, in practice, seeding the PRNG. The simulator logs per-tick CPU and RAM utilization per pool and records scheduling and execution events for post-hoc analysis and visualization. In the AI-driven loop, traces are replayed deterministically under fixed seeds and configuration so that policies can be compared fairly across iterations and runs (Srivastava et al., 19 May 2025, Tagliabue, 20 Oct 2025).

4. Scheduler interface, extensibility, and policy space

A notable design choice in Eudoxia is the minimal Python interface for user-defined schedulers. In the original simulator paper, the interface is described through an initialization function scheduler_init(sch: Scheduler) and a scheduler function scheduler_algo(sch: Scheduler, failures: List[Failure], arrivals: List[Pipeline]) returning (suspensions, assignments). Policies are registered via decorators such as @register_scheduler_init(key="my-scheduler") and @register_scheduler(key="my-scheduler"). The later AI paper presents the same interface in stripped-down form as functions receiving (s, failures, pipelines), with an optional initializer and a per-tick scheduling function that returns the two lists suspensions and assignments (Srivastava et al., 19 May 2025, Tagliabue, 20 Oct 2025).

This interface is intentionally code-first. The papers emphasize that it is easy for LLMs to generate valid policies and for humans to read, debug, and extend them. Interpretability is preserved because policies are readable Python programs conforming to a simple API, and all generated policies are logged as executable files for asynchronous debugging and human evaluation. The built-in simulator APIs, including resource pools, priority queues, and hardware consumption, keep the policy space transparent enough that both successes and failures are explainable and actionable (Tagliabue, 20 Oct 2025).

The simulator includes several built-in schedulers that illustrate different trade-offs. The Naive scheduler uses a single pool, assigns all available resources to the next pipeline, blocks until completion, and has decision complexity per tick $i \in V_p$4. The Priority scheduler also uses a single pool but maintains queues for batch, iterative, and interactive workloads; new workloads receive containers with 10% of total resources initially, OOM causes re-entry with the last allocation recorded, and the next attempt doubles the previous allocation up to a cap of 50% of total CPU or RAM. If a high-priority arrival finds all resources allocated, the scheduler scans running containers for low-priority workloads, preempts one, and immediately serves the high-priority job; the preempted batch job returns to the waiting queue without being flagged as a failure. The Priority-pool scheduler generalizes this logic to multiple pools and chooses the pool with the most available resources, with tie-breakers that favor pools minimizing expected completion time or maximizing headroom (Srivastava et al., 19 May 2025).

5. Metrics, validation, and AI-driven use as a verifier

Eudoxia reports latency metrics, throughput, utilization, makespan, and cost if autoscaling is enabled. The original paper validates the simulator against real workloads by running TPC-H, comprising 22 queries, on a 10GB dataset on an AWS c5ad.4xlarge with 16 vCPUs and 32GB RAM via Bauplan. Each query runs alone with caching disabled, and CPU and RAM usage are observed during execution. For queries 11, 16, and 22, runtimes were too short for reliable telemetry. Across the remaining queries, Eudoxia’s simulated runtimes had percent error ranging from 0.44% to 3.08%, averaging 1.74%, which the authors present as evidence that operator-level RAM thresholds and CPU scaling functions yield realistic runtime estimates in DLH settings (Srivastava et al., 19 May 2025).

The later paper repurposes Eudoxia as the deterministic simulator in a repeated LLM sampling loop for policy discovery. The pipeline comprises a policy generator that calls the LLM via LiteLLM and performs syntax checks and parsing, a deterministic simulator that runs the policy on standardized traces with fixed simulation parameters and collects metrics, and a context manager that maintains prompt state, injects structured feedback, and compresses context when token limits are exceeded. The structured feedback includes performance metrics, optional trace data summaries, error diagnostics for invalid code, and safety-check outputs. The target metric in the reported experiments is throughput, scored as the median across six realistic, standardized traces generated with Eudoxia’s APIs from three parameter sets with two seeds per set (Tagliabue, 20 Oct 2025).

The reported setup uses 50 total LLM sampling iterations per model, with workload and simulation parameters fixed throughout each run, and selects the best policy by median throughput across traces. The experiments, conducted on Oct 19–21, 2025, report the best of three independent runs per model:

Model	Throughput improvement	Cost and time
GPT5	+371.1%	$9.92; 8292 s
Sonnet 4.5	+313.2%	$4.587; 2785 s
Opus 4.1	+263.2%	$37.27; 2158 s
GPT5-mini	0% improvement over three trials	$1.65; 7669 s

The paper explicitly frames these results as evidence of feasibility rather than generalizable conclusions about specific models or absolute gains. It also notes that the FIFO baseline is non-trivial and that GPT5-mini failing to improve across trials underscores that the task meaningfully challenges capable models. A plausible implication is that Eudoxia’s deterministic feedback makes it suitable not only for classical scheduler evaluation but also for structured search over a large policy design space (Tagliabue, 20 Oct 2025).

6. Limitations, positioning, and future directions

Eudoxia’s realism is bounded by the fidelity of its abstractions. The simulator captures operator RAM thresholds, CPU scaling functions, priorities, preemption, and pool-level resource accounting, but some phenomena are modeled only indirectly or not separated into dedicated submodels. IO-heavy stages are represented through scaling functions that may not improve with additional CPUs, cold-start distributions are not modeled separately, and the simulator does not prescribe a vendor-specific price model even when autoscaling cost is included. In the AI-design paper, the authors state that the value of verification hinges on how representative the simulator is of the real Bauplan runtime, and that significant engineering and statistical inference are needed to increase confidence before scaling costly experiments (Srivastava et al., 19 May 2025, Tagliabue, 20 Oct 2025).

Its scope is also narrower than that of general cloud simulators. The original paper contrasts Eudoxia with CloudSim and with QoS-focused or power-constrained HPC schedulers, arguing that its contribution lies in targeting composable DLH workloads executed in a unified FaaS runtime. It is described as closer in spirit to fine-grained scheduling in Mesos and Borg’s data-local task packing and Meta’s XFaaS optimizations, but tailored to pipelines where each operator runs within a single VM and where interleaving interactive and non-interactive workloads is beneficial (Srivastava et al., 19 May 2025).

The stated future directions proceed along two lines. One is simulator refinement: broader integration of real scaling functions derived from production traces, richer cost and IO models, and exploration of multi-pool scheduling trade-offs and policy portability beyond single-pool setups. The other is methodological scaling in the AI-driven setting: prompt evolution and better context management, structured exploration via evolutionary computation, training smaller models with reinforcement learning to yield effective, efficient policies, extending Eudoxia to more general serverless platforms such as multi-tenant Lambda-like FaaS, and even using LLMs to help bootstrap verifiers themselves by predicting system-level outcomes from specifications (Srivastava et al., 19 May 2025, Tagliabue, 20 Oct 2025).

The implementation is open source. The simulator repository is available at https://github.com/BauplanLabs/eudoxia, and the reference generate-and-verify loop code is available at https://github.com/BauplanLabs/AI-for-Distributed-System-Design. Configuration is provided in TOML, with parameters such as duration, waiting_ticks_mean, num_pools, and scheduling_algo; a minimal run is eudoxia.run_simulator(paramfile). Exact full simulator configurations, specific CPU and pool counts, and workload parameterizations are not included beyond mentions such as “number of CPUs, number of pools” and the three-parameter-set trace-generation approach, and the AI paper does not specify hardware details beyond the use of LiteLLM and end-to-end loop times (Srivastava et al., 19 May 2025, Tagliabue, 20 Oct 2025).