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

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>