---

name: mlsys-related-work description: Use when positioning an MLSys submission against the fast-moving ML-systems literature scattered across OSDI, SOSP, NSDI, ASPLOS, and ML venues, handling arXiv-first and open-source-first prior work, comparing against production systems that have no paper, and writing the delta statement two reviewer cultures will both accept.

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>