Note on scope: two provided peer IDs are alias-normalized against the KB —2310.0724→ 2310.07240 (CacheGen),2401.0967→ 2401.09670 (DistServe); the truncated forms have no L1/L2 on disk. All eight peers plus the target carrycategory: framework, but the target is the only cluster/continuum orchestrator in the set: eight peers are GPU-side LLM systems (seven serving, one RLHF training), DECICE is a Kubernetes-level job scheduler for a cloud-HPC-edge continuum. The comparison below is therefore mostly cross-layer rather than head-to-head, and that mismatch is itself the finding.
DECICE's thesis is: *put a predictive state source (a Digital Twin carrying power,
carbon, and anomaly forecasts) inside the orchestrator, and let a pool of schedulers
pick a strategy per workload shape* [2605.25292]. The peers relate to
it along three axes, none of which is "same problem, better numbers."
Ring 1 — scheduling granularity and placement policy (the mechanism peers).
sibling: it also decides which model/role goes on which device group across a
heterogeneous cluster, exposes the decision as a declarative knob (Model Placement
Ratio) rather than an algorithm, and explicitly supports mixed-generation GPUs
[2312.11819]. DECICE's Model Placement Ratio analogue is
the three-scheduler pool (AI / Heuristic / Gang) plus the workflow ingestion layer
[2605.25292]. Both are placement frameworks whose scheduling
is decided before the run, not adapted during it.
granularity: it argues that in the workload regime DECICE targets (skewed job sizes,
high load), queuing — not execution — is 90–98% of latency, and the fix is
iteration-level preemptive MLFQ, several abstraction levels below job-to-node
mapping.
DECICE never states: per-GPU goodput (requests/s meeting an SLO) instead of raw
time-to-completion, and it proves via ablation that placement search alone buys
nothing ("vLLM++" ≈ vLLM) unless the phases are physically separated
Ring 2 — simulation and predictive state (the Digital-Twin peers).
simulator validated to <2% SLO-attainment error against the real system
[2401.09670]. That is the exact artifact DECICE's LB-KAIROS
simulation box claims to be [2605.25292] and the exact
validation DECICE never performs.
Digital Twin: DECICE feeds a predictive state store into the scheduler
(GET Cluster Snapshot before placement, POST after binding
[2605.25292]), whereas CachedAttention feeds the *scheduler's
own queue* into the state store as a Belady oracle. Same coupling, opposite
direction of information flow.
Ring 3 — what the orchestrated resource actually is (the substrate peers).
GPU nodes the binding resource is not CPU/GPU utilization but KV-cache memory,
with effective utilization as low as 20.4–38.2% under naive allocation. DECICE's
monitored metric list — CPU/GPU utilization, memory pressure, network throughput,
storage I/O [2605.25292] — contains no term that would expose
this.
the memory manager are the same component*: request order (longest-shared-prefix
first) determines cache hit rate, proven DFS-optimal [2312.07104].
DECICE's architecture keeps them as separate boxes.
[2310.07240] are the two peers whose deployment shape DECICE
ought to be the natural host for — FastDecode needs one GPU node plus N remote CPU
sockets over InfiniBand [2403.11421], CacheGen needs a storage
server reachable over a single-digit-Gbps link
[2310.07240]. Both are continuum topologies expressed
manually; neither is expressible in DECICE's constraint vocabulary.
Genuinely new in DECICE.
split puts energy, latency, and cost on the objective side and argues the orchestrator
is missing a state source for them, which is why the second core component is a
Digital Twin rather than a second scheduler [2605.25292]. Not one
of the eight peers models energy or carbon at all: FastServe, vLLM, SGLang,
DistServe, FastDecode, CacheGen, and CachedAttention all optimize
throughput/latency/cost-in-dollars, and FlexRLHF's own metric critique concedes it
reports only samples/sec, max batch size, and stage share
[2312.11819]. This is DECICE's uncontested niche.
Frontend Nodes → Proxy path is a capability no peer has
[2605.25292]. FlexRLHF, the only other paper spanning
heterogeneous hardware, assumes a DGX cluster with NCCL/InfiniBand and full device
control [2312.11819].
entry point** [2605.25292]. Every peer takes requests through
either an OpenAI-compatible HTTP API ([2309.06180],
[2401.09670]) or a bespoke Python API
[2312.11819]; DAG-shaped workflow ingestion is outside their
scope entirely.
Incremental or borrowed.
shape [2605.25292]) restates what DistServe formalizes: the
optimal configuration is an interior optimum, intra-op parallelism winning at low
arrival rate and inter-op at high rate, which is precisely why a search is needed
[2401.09670]. DistServe supplies the crossover analysis and the
selection algorithm; DECICE supplies the pool but no selection rule — its L2 records
that no threshold and no decision tree is given
simulator [2401.09670] and FastDecode's performance-model-guided
R-Worker sizing [2403.11421]. DECICE's LB-KAIROS occupies
the same slot with neither a model nor a fidelity measurement.
pairs [2605.25292]) is a heavier version of FastServe's
observation that per-iteration execution time is a deterministic function of
(hardware, model, input length) and can be captured by offline profiling rather than
learned [2305.05920].
Contradictory.
that "Heuristics (GA, PSO, ACO, SA, HEFT, OLB) maintain sub-second runtimes
throughout," while the very figure it cites plots PSO at 3.89/4.59/4.13 s and SA at
3.92/4.71/4.65 s [2605.25292]. Gurobi at 1.41 s on the hardest
workflow therefore beats two of the metaheuristics
矛盾根源 — 类别叙事覆盖了逐点读数: the section's narrative is organized as
"exact = slow, heuristic = fast," and the sentence generalizes the band label rather
than the bars. The defensible claim the same data supports is different and stronger:
dependency count is the sensitive axis for exact solvers (WF1→WF3 ratio 8.4–23.5×)
and nearly irrelevant for heuristics (1.0–1.4×) [2605.25292].
chain treats "framework delivered, modules independently adoptable" as the terminal
claim, with placement/strategy selection as the load-bearing mechanism
[2605.25292]. DistServe's ablation directly contradicts the general
form of that hope: a best-effort parallelism/placement search under an unchanged
execution model recovers essentially nothing ("vLLM++" ≈ vLLM), and the gain comes
from physically splitting the phases [2401.09670].
矛盾根源 — 不同的 workload 与不同的自由度: DistServe searches within a fixed
two-phase LLM workload where the phases interfere at sub-second granularity, so only
physical separation helps; DECICE searches across genuinely heterogeneous domains
(HPC / cloud / edge) where placement changes which machine class runs the job. Both
can be right, but DECICE never runs the ablation that would show which regime it is
in — it has no end-to-end comparison against vanilla Kubernetes at all
is a percentage resource-usage level, including an undefined >100 % bucket
[2605.25292]. vLLM shows the utilization number an orchestrator
reads can be 100% while effective KV-cache utilization is 20.4–38.2%
[2309.06180], and SGLang shows the same pool is
deliberately over-subscribed — a large waiting batch may evict all cached tokens to
grow batch size [2312.07104].
矛盾根源 — 观测层不同: DECICE reads node-level counters through Prometheus;
the serving engines manage an application-level pool invisible to those counters.
A continuum scheduler acting on node utilization is acting on a proxy that the GPU
workload it schedules deliberately saturates.
Attack 1 — the headline number measures the wrong latency. "5000×5000 within 300 s"
is model training plus validation time, not the online scheduling decision latency;
the L2 states the inference path (ETL → RNN forward) is never reported
[2605.25292]. For a scheduler this is the one number that matters,
and every peer reports its equivalent: FastServe's whole thesis is that scheduling-side
queuing is 92.7–98% of end-to-end latency [2305.05920], and
DistServe defines its metric as SLO attainment on TTFT and TPOT rather than any
aggregate time [2401.09670]. Worse, the 300 s claim clears its own
bound by 0.7% (297.974 s measured), so it carries no extrapolation margin
[2605.25292] — while the paper's own future work asks for
"thousands of tasks" production workloads [2605.25292].
Attack 2 — the Digital Twin's entire value proposition is unevidenced. Step 4 of
the argument chain (energy/carbon-aware scheduling requires a predictive state source,
therefore a Digital Twin) is architecturally complete and empirically empty: there is
not one joule or gCO2 figure anywhere in the paper [2605.25292]. The
adjacent claim that this is what makes the DT more than a monitoring dashboard rests on
the snapshot ordering in the request lifecycle, not on a measurement
[2605.25292]. Compare the discipline the peers apply to their own
central mechanism: SGLang isolates RadixAttention with a component ablation and bounds
its overhead at <0.3% under zero reuse [2312.07104];
CachedAttention isolates its scheduler-aware eviction against LRU and FIFO and reports
the tier breakdown, >99.6% of hits in DRAM vs ~0.5%
[2403.19708]. DECICE ablates nothing.
Attack 3 — LB-KAIROS is an unvalidated simulator carrying a sim-to-real claim.
The L2 identifies the real technical barrier as the shared snapshot contract between
the virtual test environment and the production cluster, and notes the paper gives no
schema, no field list, no versioning policy, no sampling period, and no statement of
whether a snapshot is atomic across nodes [2605.25292].
A simulator whose fidelity is unmeasured cannot support the training-deployment
no-drift claim. DistServe is the counter-example within the same category: it validates
simulator vs real SLO attainment to <2% before using the simulator for any ablation
[2401.09670]. Naming makes it worse — the component is LB-KAIROS in
the caption and LiI-KAIROS in the drawing, expanded nowhere
**Attack 4 — the only real benchmark is a solver bake-off with no solution quality and
no controlled setup.** The 10-tool comparison reports runtime only; makespan and energy
objective values are absent, so "which strategy should the IAIS pick" is answerable on
at most half the evidence [2605.25292]. None of the ten tools is
individually cited, so solver versions (Gurobi's presolving is strongly
version-and-license dependent), metaheuristic hyperparameters (PSO's 3.89 s is
plausibly just an iteration-count setting), and the host CPU/core/memory configuration
are all unrecoverable [2605.25292]. CP-SAT is listed among the
benchmarked solvers in the method section but absent from the figure, so constraint
programming is missing as a class [2605.25292]. Contrast the
baseline hygiene the peers volunteer: DistServe names its baseline versions and
per-model intra-op degrees and explains why DeepSpeed-MII cannot serve OPT-175B
[2401.09670]; SGLang flags that Guidance and LMQL lack batching and
tensor parallelism and are therefore weak on the harder benchmarks
Attack 5 — the HPC ingress path is an unmeasured single point of failure. Every HPC
job must traverse Frontend Nodes → Proxy, which sets the HPC partition's scheduling
latency and throughput ceiling; the paper neither measures it nor discusses its HA
[2605.25292]. This is the same shape of defect FlexRLHF
successfully attacked in trlX, whose single-GPU reward placement flattened throughput
as devices scaled (8.87 vs 109.18 samples/s at 4×8 GPUs)
[2312.11819]. A per-domain proxy in the data path is exactly where
that pathology reappears.
Attack 6 — three named use cases carry zero quantitative data. Cloud robotics,
scientific computing, and edge inference are named in the work-package section and the
conclusion, with edge inference lacking even an owning partner, and none has an in-paper
measurement [2605.25292]. There is no limitations section and no
negative-result table in the five pages [2605.25292], so the
win/lose table in the L2 had to be reconstructed from data gaps
Paradigm position. DECICE occupies a layer the LLM-serving literature has largely
vacated. The 2023–2024 arc of its peers is a sustained argument that *the useful
scheduling decision moved below the job*: iteration-level preemption because queuing
dominates [2305.05920], block-level memory management because
the KV cache is the binding resource [2309.06180],
request-order-as-cache-policy because ordering determines hit rate
[2312.07104], phase-level disaggregation because prefill and decode
have incompatible optima [2401.09670], and device-role-level
placement because co-locating everything wastes memory and bandwidth
[2312.11819]. DECICE schedules at job-to-node granularity
across a federation. That is not obsolete — someone must still decide which cluster
a workload lands in, and the peers all assume that decision was made offline by a
human — but it means DECICE's contribution is complementary infrastructure, not a
competitor, and the paper does not position it that way.
Its defensible niche is narrower and real: **carbon- and energy-aware placement across
administrative domains, with a rootless-HPC ingress**. Nothing in the peer set touches
either. The second niche is the two-plane state abstraction — a snapshot contract shared
by the production cluster and the training/simulation environment
[2605.25292] — which is a genuinely reusable idea, and
the one DistServe's validated simulator [2401.09670] shows how to
make credible.
Adoption evidence. Structurally stronger than the closest peer, substantively
unproven. DECICE is open source under an organization-level entry point with a
three-year funded consortium, over 15 consortium publications, and tutorials reaching
more than 100 participants [2605.25292] — but the paper names no
repository, module path, commit, or version, so the artifact claim is not yet
actionable [2605.25292], and the project is presented
retrospectively (funded period ended November 2025) rather than as ongoing work
[2605.25292]. That profile is better than FlexRLHF, which was
never open-sourced and saw its ideas absorbed by OpenRLHF instead of being adopted
directly [2312.11819], and far behind vLLM, which became
the de-facto engine integrated by HuggingFace and Ray Serve
[2309.06180], or SGLang, whose RadixAttention primitives
are traceable to specific files and were partially upstreamed
[2312.07104]. The realistic outcome for DECICE is
component-level adoption: KSI and the ephemeral-cluster tooling are the pieces with a
standalone value proposition, which matches the paper's own "modular architecture
enables independent adoption" framing [2605.25292].
cheapest high-value experiment in the cluster: measure LB-KAIROS predicted
placement outcomes against the real federated cluster and report the error, as
DistServe does to <2% SLO-attainment error before trusting any simulator-driven
ablation [2401.09670]. Until that number exists, the DT's snapshot
contract [2605.25292] is an architectural assertion.
No peer has done this for an energy/carbon-predicting twin.
GET Cluster Snapshot → placement → POST Cluster Snapshot
[2605.25292]. CachedAttention runs the other: the scheduler's
pending-job queue becomes the cache's future-access oracle, which is what relocates
99.6% of hits onto the fast tier [2403.19708]. A continuum
Digital Twin that also ingests the workflow DAG's pending tasks could pre-position
data and pre-warm nodes before a task is dispatched — carbon-aware deferral rather
than carbon-aware selection. Neither paper builds this.
no selection rule [2605.25292], while its own benchmark already
contains the right feature: dependency count, whose WF1→WF3 sensitivity ratio splits
exact solvers (8.4–23.5×) from heuristics (1.0–1.4×)
[2605.25292]. DistServe's crossover analysis is the template —
an interior optimum in a two-configuration plane, resolved by search
[2401.09670]. Turning the RNN's target from "predict the placement"
to "predict which solver to invoke, given dependency density and a time budget"
uses the paper's strongest evidence for the decision it currently leaves manual.
bake-off.** The solver comparison is runtime-only [2605.25292],
which makes it unusable for the multi-objective (energy / latency / cost) problem the
motivation declares [2605.25292]. A Pareto frontier over
(makespan, energy, solve time) for the same ten tools is a direct, technically
straightforward extension and would be the first energy-objective solver benchmark
in this cluster.
CPU/GPU utilization, memory pressure, network throughput, and storage I/O
[2605.25292] — none of which exposes KV-cache pressure
[2309.06180] or cache hit rate
[2312.07104], the two quantities that actually predict whether an
LLM serving node can absorb another request. Adding engine-level metrics as a DT
client behind the existing JSON wrapper contract
[2605.25292] would let a continuum scheduler place
inference work on evidence instead of on a proxy. This is the concrete bridge between
DECICE's layer and the rest of the category.
FastDecode requires one GPU node plus N CPU sockets sized by a bandwidth model, and
degrades badly when mis-sized — eight sockets score worse than four on short
sequences [2403.11421]. CacheGen requires a storage tier
reachable over a single-digit-Gbps link and adapts per chunk
[2310.07240]. Both are exactly "match a workload to
heterogeneous resources under bandwidth and locality constraints," which is DECICE's
stated problem [2605.25292]. Expressing a heterogeneous
CPU-offload serving deployment as a DECICE workflow, with the DT sizing the CPU-side
worker count, is the highest-leverage untried combination in this cluster.