mlsys-related-work
GitHub指导撰写MLSys论文相关工作部分，覆盖五大文献领域，处理无论文的生产系统对比，并撰写兼顾OS与ML社区接受度的创新点声明。
Trigger Scenarios
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill mlsys-related-work -g -y
SKILL.md
Frontmatter
{
"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>
Version History
- 9f86f09 Current 2026-07-19 16:59
