Think Before You Grid-Search: Floor-First Triage for LLM Serving

Technische Samenvatting: Floor-First Triage voor LLM-serving

Probleemstelling
Productieteams die de optimalisatie van Large Language Model (LLM) serving aanpakken, worden geconfronteerd met een enorme configuratieruimte bestaande uit parallellisme-layouts (TP, EP, DP), batching, kwantisatie en kernel-niveau werkzaamheden. De gangbare operationele reactie op gemiste latentiedoelstellingen is het benchmarken van talloze configuraties en het willekeurig inzetten van zware profilers (bijv. Nsight Systems). Deze aanpak degradeert vaak tot inefficiënt grid search, waarbij de gemeten prestatiecijfers ambigu zijn: een trage Time Per Output Token (TPOT) kan voortkomen uit fundamentele bandbreedtelimieten, implementatiegebreken, geëxposeerde communicatie, host-overhead of onderpresterende kernels. Het artikel stelt dat de engineeringgemeenschap een systematische besluitprocedure mist om te bepalen wanneer profiling gerechtvaardigd is en waar men als eerste moet kijken, wat leidt tot onvoorspelbare deploymentkeuzes (bijv. conflicterende parallellisme-strategieën voor DeepSeek-modellen op identieke hardware) gebaseerd op folklore in plaats van expliciete resource-rekenkunde.

Methodologie: Floor-First Triage
Het artikel stelt "Floor First" voor, een residual-gestuurde triage-workflow die analytische schatting behandelt als de primaire laag van profiling. De methodologie bestaat uit vier afzonderlijke stadia:

1. Constructie van de Analytische Vloer (Analytical Floor): Voordat er enige benchmarking plaatsvindt, berekent het systeem een "tweezijdige vloer" voor een gegeven configuratie. Dit model behandelt elke decode-stap als een vijfdimensionale resource-vector: HBM-bytes, FLOPs, netwerkbytes, netwerkberichten en KV-capaciteit.

   • Optimistische Vloer ($t_{opt}$): Berekend als het maximum van onafhankelijke resource-tijden ($max(t_{HBM}, t_{compute}, t_{network})$), uitgaande van perfecte overlap.
   • Pessimistische Vloer ($t_{sum}$): Berekend als de som van alle resource-tijden ($t_{HBM} + t_{compute} + t_{network}$), uitgaande van geen overlap.
   • Diagnostisch Interval: De positie van een gemeten benchmark binnen het $[t_{opt}, t_{sum}]$ interval dient als een zero-cost diagnose voor systeemoverlap. Als de meting nabij $t_{opt}$ ligt, is de overlap goed; als deze nabij $t_{sum}$ ligt, zijn scheduling/overlap de bottleneck; als deze boven $t_{sum}$ ligt, lekt tijd weg naar ongemodelleerde kosten (host gaps, stragglers).

2. Benchmark-discipline: Benchmarks moeten worden uitgevoerd onder strikte regels: open-loop load generatie (om self-throttling bias te vermijden), realistische lengteverdelingen, steady-state operatie en tail-percentiel (P99) rapportage.

3. Reconciliatie en Triage: De gemeten tijd wordt vergeleken met de vloer.

   • Kleine Residual (< 1.3× vloer): De investigatie stopt. Het systeem bevindt zich nabij de theoretische limiet voor die as; verdere optimalisatie vereist het wijzigen van de architectuur (bijv. sparse attention, kwantisatie) in plaats van het tunen van kernels.
   • Grote Residual: Profiling wordt geëscaleerd. Nsight Systems wordt alleen gebruikt om drie specifieke vragen te beantwoorden: Zijn er gaten tussen kernels? Is communicatie geëxposeerd? Welke kernelklasse overschrijdt zijn analytische budget? Nsight Compute is strikt voorbehouden aan kernelklassen die hun budget overschrijden nadat andere oorzaken zijn uitgesloten.

4. Wall Ordering: In plaats van single-batch latentie te vergelijken, worden deployments geëvalueerd via "wall ordering"—het bepalen welke resource-constraint (KV-capaciteit, KV-bandbreedte, gewichtsbandbreedte of compute) als eerste bindend wordt naarmate de load toeneemt. Capaciteit wordt behandeld als een eersteklasse resource-dimensie, niet als een post-hoc geheugencontrole.

Belangrijkste Bijdragen

1. Residual-gestuurde Triage-workflow: Een decision loop die target definitie, vloer-constructie en profiler-escalatie scheidt, met expliciete stop-regels die optimalisatie-inspanningen toewijzen aan ofwel pipeline-werk (layout/scheduling) ofwel kernel-werk.
2. Tweezijdige Vloer-model: Een analytisch model dat zowel optimistische als pessimistische grenzen biedt, gebruikmakend van de kloof tussen hen om overlap-efficiëntie te diagnosticeren zonder een profiler te draaien.
3. Wall Ordering als Output: Een methode om deployment-alternatieven te vergelijken op basis van welke resource-muur (wall) als eerste bindend wordt naarmig de concurrency groeit, wat onthult dat een layout met een slechtere single-batch latentie de goodput-frontier kan domineren als deze een hogere capaciteitsmuur heeft.
4. Metrische Discipline: Een systematisering van utilisatie-metrieken (MFU vs. MBU) gebaseerd op de "ridge identity" ($MFU/MBU = I_{work}/I_{ridge}$), waardoor de juiste metriek wordt gerapporteerd voor de bindende resource.
5. Artifact en Agent Skill: Een zero-dependency Python artifact (floor.py) en een agent-leesbare skill (SKILL.md) die deze discipline afdwingen in agentic optimalisatie-loops, waardoor agents wordt voorkomen dat ze reflexmatig naar profilers grijpen.

Casestudy Resultaten
Het artikel past deze methodologie toe op een DeepSeek-V3.2-stijl 671B MoE-model op 16 NVIDIA H20 GPU's.

• Hardware Karakterisering: De H20 GPU wordt geïdentificeerd als een onderdeel met een ridge punt van ~74 FLOP/byte (vs. ~590 voor H100), wat het een extreem "decode-georiënteerd" onderdeel maakt waarbij de memory-bound regio 8× breder is.
• Layout Oordeel:
  • TP16: Bij een batch size van 64 en 8K context is TP16 beperkt door KV-capaciteit tot ~70 gelijktijdige verzoeken. De KV-bandbreedte term is significant, en de compute-muur is onbereikbaar binnen de haalbare regio.
  • EP16 + DP Attention: Deze layout ruilt iets slechtere gewichts-traffic in voor een capaciteitsmuur van ~644 verzoeken (een orde van grootte hoger). Hoewel TP16 een lagere single-stream latentie heeft (2.4× sneller bij B=1), domineert EP16+DP de high-concurrency goodput-frontier.
  • Sparse Attention (DSA): Verwijdert de KV-bandbreedte-muur maar niet de capaciteitsmuur, aangezien de volledige KV adresseerbaar moet blijven.
• Resolutie van Onenigheid: De studie verklaart waarom verschillende teams tegenovergestelde layouts (TP vs. DP) op dezelfde hardware hebben ingezet: de optimale keuze is een berekenbare functie van het operationele punt (concurrency). Hoge concurrency bevoordeelt DP; lage concurrency bevoordeelt TP.

Betekenis en Claims
Het artikel claimt dat onenigheid in productie-deployments van LLM's vaak voorspelbaar is vanuit een kleine resource-rekening (vijf getallen per GPU plus modeldimensies) in plaats van uitgebreide experimentatie te vereisen. Door deze rekening systematisch te maken, biedt de workflow een algemene triage-procedure die:

• Verspilde profiling-inspanning voorkomt wanneer metingen dicht bij de analytische vloer liggen.
• De juiste optimalisatie-as identificeert (pipeline vs. kernel) voordat dure tools worden ingezet.
• Deployment-keuzes verklaart via "wall ordering" in plaats van punt-benchmarks.
• Een robuuste methode biedt voor hardware met extreme kenmerken (zoals de H20) waar standaard heuristieken falen.

De auteurs merken bescheiden op dat de huidige conceptversie steunt op analytische vloeren en gekalibreerde constanten, met een geplande meetcampagne (Sectie 8) vereist om de residual-drempels en escalatieregels empirisch te valideren. De methode wordt gepresenteerd als een besluitprocedure voor engineering, niet als een vervanging voor simulators of profilers, die essentieel blijven voor residuals die de vloer-check overleven.