| name | mlsys-writing-style |
| description | Use when revising an MLSys paper's prose and structure, building the measured-bottleneck opening, naming the mechanism instead of listing optimizations, writing evaluation sections as answers to research questions, quantifying every performance claim with workload context, and fitting the argument into the venue's 10-page two-column body. |
MLSys Writing Style
Use this during drafting and revision. MLSys prose sits between two failure modes: the
ML-paper voice (contribution bullets, related-work-first, benchmarks as decoration) and
the tech-report voice (system tour, feature list, "extensive experiments"). The venue's
own genre is different: a paper here is an argument about where time, memory, or money
goes in an ML workload, and how a named idea changes that.
The first-page arc
- Bottleneck, measured. Open with the profiling fact that justifies the paper —
a percentage, a stall, a cost line — on a workload the reader recognizes. If the
introduction's first numbers appear in the evaluation section, the order is wrong.
- Why existing designs cannot remove it. Mechanistic reasons per named system or
design family, not "prior work is limited."
- Insight. The one observation that unlocks the design, stated in a sentence a
reader could repeat tomorrow.
- Mechanism, named. Give the technique a noun. Anonymous "several optimizations"
is how research contributions disappear into engineering.
- Payoff with scope. Ranged improvement, named baseline, stated cost or non-win.
Sentence-level rewrites
| Draft pattern | MLSys-safe rewrite |
|---|
| "achieves up to 3.4x speedup" | "1.6-2.2x goodput at matched p99 across three traces (3.4x peak on the bursty trace)" |
| "significantly reduces memory" | "cuts peak activation memory 38% (Fig. 5), enabling batch 32 on one A100" |
| "our highly optimized implementation" | name the three optimizations and ablate them |
| "extensive experiments demonstrate" | "we answer four questions: (RQ1)..." |
| "existing systems suffer from poor utilization" | "SystemX idles the interconnect 41% of decode time on this trace (§2)" |
| "we believe this generalizes to other accelerators" | state the mechanism's hardware assumptions; claim only what was measured |
Evaluation sections answer questions
Structure the evaluation as research questions, each mapped to figures that answer it:
6. Evaluation
RQ1 Does <mechanism> improve end-to-end serving under realistic load? (6.2)
RQ2 Where does the gain come from? [ablation per component] (6.3)
RQ3 When does it *not* help? [load shapes, model sizes, hardware] (6.4)
RQ4 What does it cost? [memory, complexity, build time, $ ] (6.5)
RQ3 and RQ4 are not optional at this venue; their absence is the strongest style-level
predictor of skeptical reviews. A results tour organized by dataset instead of by
question reads as unanalyzed output.
Numbers discipline
- Every performance number carries its workload, hardware, and variance context on
first mention; naked speedups are marketing.
- Prefer goodput/latency-constrained framings over raw throughput when serving is
involved — systems readers discount throughput wins that trash tails.
- Use consistent units and precision; a table mixing ms, s, and "x" invites arithmetic
audits.
- When a number is estimated (cost models, projections to larger scale), typographically
separate it from measured results and say how it was estimated.
Compression into 10 two-column pages
- The design section earns space in proportion to what the evaluation ablates; a
component never ablated should be described in two sentences, not two columns.
- Background sections rarely deserve more than half a page — MLSys readers know the
transformer, the GPU memory hierarchy, and the serving stack; spend the space on
your workload characterization instead.
- Architecture diagrams beat prose walkthroughs; one good figure with numbered dataflow
arrows replaces a column of "then the request is forwarded to."
- Move full configuration matrices to the separately-uploaded appendix, but keep the
fairness-critical facts (baseline tuning budget) in the body — reviewers are not
obliged to open the appendix.
- References are excluded from the 10 pages and must list all authors (2026 rule), so
never compress by mutilating the bibliography.
Figures and tables carry the paper
Systems reviewers form their judgment from the exhibits, then read prose to confirm it.
- The architecture figure: numbered dataflow, the new components visually distinct from
inherited infrastructure, and no internal codenames. If a reader cannot locate the
contribution in this figure, the design section will not save it.
- The money figure: one plot that shows the headline claim with its constraint —
typically goodput versus load with a p99 ceiling marked, both systems on the same
axes. Reviewers screenshot this one into their reviews.
- Every performance plot states hardware and trial count in the caption; captions are
read during skims, body text is not.
- Log-scale axes are honest for spanning regimes but must be labeled loudly; a log axis
that makes a 1.3x gap look large will be caught and remembered.
- Tables: bold the best number per row only if "best" is defined in the caption;
include the variance column; never mix measured and projected numbers in one table
without typographic separation.
Title and abstract mechanics
- Titles at this venue name the system or mechanism and the setting ("X:
for "); cleverness that hides the topic costs discovery, since
practitioners search proceedings by problem.
- The abstract must contain at least one measured number with its workload context —
an abstract with no number reads as a position paper here.
- Spell out the ML property and system constraint being co-designed in the first two
sentences; abstract readers include the reviewers bidding on papers, and bidding
mismatch produces the wrong panel (see
mlsys-review-process).
Anonymization without lobotomy (research track)
Blinding at a systems venue tempts authors to delete the deployment context that makes
the paper credible. Keep the facts, drop the identity: "a production recommendation
service serving tens of millions of daily requests" survives review; the company name
returns at camera-ready. Scrub cluster hostnames and internal codenames from figures —
profiler screenshots are the classic leak.
Output format
[Diagnosis] tech-report voice / ML-paper voice / MLSys-ready
[First-page arc] <bottleneck number present? insight? named mechanism? scoped payoff?>
[RQ structure] <RQ list; RQ3 (non-wins) and RQ4 (costs) present?>
[Claim rewrites] <naked number -> contextualized rewrite>
[Compression cuts] <un-ablated design prose, background, config matrices to move>
[Anonymity edits] <identity leaks to fix without deleting context>
