--- 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. ```bibtex @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 ```text [Lane coverage] [Nearest neighbors] [Delta statement] [Freshness] [Misattribution/overlap risks] [Fixes] ```