mlsys-related-work

MLSys Related Work

Use this to audit positioning and novelty. The core difficulty is that MLSys's literature

does not live at MLSys: the field's landmark systems are spread across OS, architecture,

networking, and ML conferences, plus arXiv reports and repositories that never became

papers. A related-work section here is judged on whether it maps that whole territory,

not one venue's proceedings.

The five lanes to cover

| Lane | Where it publishes | What reviewers check |

|---|---|---|

| ML-systems venue work | MLSys proceedings (proceedings.mlsys.org) | Do you know this venue's own line on your topic? |

| Classical systems venues | OSDI, SOSP, NSDI, ASPLOS, ATC, EuroSys, SC | Is the nearest big-venue system compared or distinguished? |

| ML algorithm venues | NeurIPS, ICML, ICLR | Does the ML-side idea you accelerate/serve already have algorithmic competitors? |

| Industry systems | arXiv reports, engineering blogs, open-source repos | Are the systems practitioners actually use acknowledged? |

| Benchmarks/measurement | MLPerf/MLCommons line, characterization studies | Is your evaluation methodology situated, not invented? |

A bibliography drawing on only one or two lanes signals to half the reviewer pool that

their community's prior work is being rediscovered.

The freshness problem

ML-systems moves on a months-scale clock: serving engines, compilers, and quantization

methods ship major improvements between your experiments and your reviews.

• Re-run a literature sweep in the final month before the deadline (in the 2026 cycle:

October), specifically for new arXiv postings and release notes of your baselines.

• Pin the exact version/commit of every compared system in the paper; "we compare

against X" without a version is unanswerable when X improves next month.

• Reviews arrive months after submission (January, for the 2026 cycle). Expect "why not

compare against Y?" where Y postdates your submission — you cannot pre-cite it, but

you can pre-empt the mechanism: if Y's approach is a known design point, place it in

your taxonomy even before a specific system ships.

Comparing against work without papers

Production and open-source systems are legitimate, expected comparison points here:

• Cite repositories and technical reports with version/commit and access date; treat a

README's performance claims as claims, not results.

• If the practitioner-standard system is closed (a cloud provider's serving stack),

say so and compare against the strongest open proxy, naming the gap honestly.

• Never dismiss an unpublished system as "not peer-reviewed" — to a systems reviewer

who runs it daily, that reads as evasion.

@misc{vllm2025,
  title        = {vLLM (release v0.x.y)},
  howpublished = {\url{https://github.com/vllm-project/vllm}},
  note         = {Commit abc1234, accessed 2026-07-08; evaluated configuration in App.~B},
  year         = {2026}
}

Writing the delta statement

Both reviewer cultures must find their contrast:

• Against the nearest system: what mechanism differs, and what measured behavior

changes because of it — "unlike X's reactive swapping, we schedule migrations into

predicted bubbles, which is why the p99 gap appears only under bursty load."

• Against the nearest algorithm: what your systems constraints add — "batching-aware

variants of this idea exist [7]; none address multi-tenant memory pressure."

• Comparison tables (rows: systems; columns: capabilities) are venue-idiomatic and

efficient, but every checkmark against a competitor must be defensible from their

paper or code — reviewers include those systems' authors.

Building the capability table honestly

The venue-idiomatic comparison table is powerful and dangerous. Rules that keep it

defensible when the compared systems' authors review you:

• Columns are capabilities the paper evaluates, not marketing attributes; a column

never exercised in the evaluation does not belong in the table.

• Every negative cell (✗ for a competitor) carries a citation or footnote to where

that limitation is documented — their paper, their docs, or your measured attempt.

• Version-stamp the table: a system's ✗ can become ✓ in next month's release, and a

reviewer running the newer version will check.

• Include the row where a competitor beats you, if the evaluation shows one; a table

where the proposed system sweeps every column is read as curated, and curation in

the comparison table contaminates trust in the results tables.

Worked contrast sentence, fictional serving-scheduler paper: "Orca-style iteration-level

scheduling [4] and reactive expert swapping [9] both target utilization; the former

assumes dense models, the latter pays migration on the critical path. Our planner

addresses the MoE case the former excludes, using the bubble structure the latter

ignores — Section 6.3 measures both boundaries." Two named systems, two mechanism-level

gaps, one pointer to where the claims are tested.

Misattribution traps

• Do not cite famous ML-systems work to the wrong venue (vLLM is SOSP, PipeDream is

SOSP, FlashAttention is NeurIPS); this venue's reviewers notice. Verified MLSys-native

exemplars live in ../../resources/exemplars/library.md.

• Do not claim "first to X" in a field with a large gray literature; write "to our

knowledge, the first published system that X" and let the evidence carry it.

• Concurrent work that appeared during your project deserves a neutral sentence and a

mechanism-level contrast, not silence — silence looks like either ignorance or fear.

Scoping the search itself

• Search the venue's own archive first (proceedings.mlsys.org is small enough to scan

a topic exhaustively in an hour) — missing an MLSys-native predecessor is the least

forgivable gap at MLSys.

• Then sweep the last two editions of each systems venue in your lane, then the

ML-venue "efficient ML" tracks, then arXiv's recent months; breadth-first by

community, not depth-first by citation chain, or one community's chain will crowd

out the others.

Double-blind interaction

Cite your own prior systems in third person, and be careful with self-identifying

version lineages ("we extend our earlier scheduler" → "we extend the scheduler of

[12]"). arXiv posting of the submission itself is permitted (2026 rule), but the

related-work text must not link the submission to that preprint.

Output format

[Lane coverage] <mlsys-native/systems-venues/ML-venues/industry/benchmarks: present?>
[Nearest neighbors] <top 3 with venue + version/commit where applicable>
[Delta statement] <mechanism contrast + measured-behavior contrast>
[Freshness] <last sweep date; baselines pinned?>
[Misattribution/overlap risks] <wrong-venue cites, "first" claims, concurrent work>
[Fixes] <ordered list>