Ich habe in letzter Zeit mit vielen Leuten gesprochen, die an RL arbeiten, und mir ist etwas Interessantes aufgefallen – immer wenn das Gespräch auf RL Infra kommt, dreht es sich fast immer um ein Thema: die Übereinstimmung zwischen Training und Inferenz. Wie man die Trainings- und Inferenzrichtlinien konsistent hält. Wie man den Off-Policy-Grad kontrolliert. Wie man die Log-Wahrscheinlichkeitsdifferenz nach der Einführung von Async behandelt. Das sind alles wichtige Fragen, da besteht kein Zweifel. Aber ich bin zunehmend überzeugt, dass RL Infra unter einer erheblichen Fehlallokation von Aufmerksamkeit leidet. Ich nenne dies, entlehnt aus einer kürzlichen Diskussion mit einem Kollegen, den Barrel-Effekt von RL Infra. Ein Fass hält nur so viel Wasser wie seine kürzeste Daube. Der Durchsatz und die Korrektheit eines RL-Trainingssystems funktionieren auf die gleiche Weise – sie werden nicht durch das Modul bestimmt, das du am meisten optimiert hast, sondern durch das, das du am meisten vernachlässigt hast. Die Übereinstimmung zwischen Training und Inferenz könnte die Daube sein, die du bis zur Perfektion geschliffen und poliert hast. Aber wenn die Stabilität deiner Sandbox eine Katastrophe ist, deine Belohnungspipeline ständig ins Stocken gerät und deine End-to-End-Observierbarkeit praktisch nicht vorhanden ist – was nützt dann perfekte Übereinstimmung? Die Kapazität des Systems ist bereits durch jede andere schwache Stelle begrenzt. Das ist grundlegend anders, als es bei der Optimierung von Inferenzsystemen funktioniert. Als Inferenzmaschine hat SGLang einen enormen Strategieraum für die Optimierung, aber seine Pipeline ist relativ linear – Anfrage verarbeiten, vorab ausfüllen, dekodieren. Du kannst Engpässe Modul für Modul isolieren, und die Kopplung zwischen den Komponenten ist handhabbar. RL-Training ist ein ganz anderes Biest – ein albtraumhaft komplexer Multi-System-Zyklus: Rollout-Generierung hängt von der Inferenzmaschine ab, die Belohnungsberechnung kann von externen Umgebungen abhängen, Politikupdates hängen vom Trainingsrahmen ab, und die nächste Runde von Rollouts hängt von der aktualisierten Politik ab. Wenn irgendein einzelnes Glied bricht, bricht der gesamte Zyklus zusammen. Leider gibt es, basierend auf dem, was ich im letzten Jahr gesehen habe, immer noch viele stark unterschätzte Schwachstellen: Zuverlässigkeit der Agentensandbox. Das ist wahrscheinlich die schmutzigste, mühsamste und am wenigsten akademisch glamouröse Arbeit in RL Infra heute. Agentenbasiertes RL benötigt eine zuverlässige Ausführungs-Sandbox für Rollouts – klingt einfach, stellt sich aber als Albtraum heraus. Stabilität von Containern, Kaltstartlatenz, Zuverlässigkeit der Ressourcenisolierung, Verwaltung des Sandbox-Zustands – diese Dinge erscheinen auf dem Papier entkoppelt, aber die auf dem Markt verfügbaren Sandbox-Produkte erfüllen die Erwartungen konstant nicht. Agentensandboxing ist kein Algorithmusproblem, aber es bestimmt direkt deine Effizienz bei der Datengenerierung, die wiederum deine Trainingsgeschwindigkeit bestimmt. Observierbarkeit. Das Debuggen von Pretraining ist relativ einfach – beobachte die Verlustkurve, überprüfe die Gradienten-Norm, und du kannst normalerweise das Problem eingrenzen. Aber das Debuggen von RL erfordert End-to-End-Trace-Fähigkeiten: Rollout-Qualitätsverteilungen, Belohnungsstatistiken, Off-Policy-Grad, Magnituden der Politikupdates und sogar die Zuordnung der Log-Wahrscheinlichkeitsdifferenz (kommt die Differenz von der Inferenzseite oder von der Versionsverzögerung des asynchronen Trainings?). Leider fliegen die meisten Teams, die ich getroffen habe, in diesen Dimensionen im Grunde blind. Das führt zu einer unangenehmen Situation – wenn die Trainingsergebnisse schlecht sind, weißt du nicht einmal, welches Modul du beschuldigen sollst. Das Skalierungsdilemma. Viele RL Infra-Optimierungen zeigen nur bei ausreichender Skalierung messbare Auswirkungen. Experimente im kleinen Maßstab zeigen oft keinen signifikanten Unterschied – nicht weil die Optimierung nutzlos ist, sondern weil das Rauschen zu hoch und die Schrittzahl zu niedrig ist, damit das Signal an die Oberfläche kommt. Doch Experimente im großen Maßstab sind prohibitively teuer. Das schafft einen Teufelskreis: Du kannst nicht beweisen, dass deine Optimierung im kleinen Maßstab funktioniert, also kannst du die Ressourcen für große Experimente nicht sichern; und ohne große Validierung bleibt deine Optimierung für immer bei "theoretisch sollte es helfen." Die Investitionen der Branche in RL Infra sind stark fehlgeleitet im Vergleich zu ihrer tatsächlichen Komplexität. Die meisten Teams behandeln es als eine Notlösung auf der Grundlage von Pretraining Infra – schnapp dir ein handelsübliches Trainingsframework, schraube eine Inferenzmaschine dran, klebe sie mit Skripten zusammen und nenne es RL Infra. Aber die Systemkomplexität des RL-Trainings und des Pretrainings ist nicht einmal in derselben Liga. Pretraining-Pipelines sind linear, homogen und haben praktisch null externe Abhängigkeiten. RL-Trainingspipelines sind zyklisch, heterogen und stark von externen Umgebungen abhängig. Die architektonische Denkweise des ersten auf den zweiten anzuwenden, wird garantiert an der Skalierung scheitern. Die wirkliche Schwierigkeit im Systemengineering besteht nicht darin, irgendein einzelnes Modul bis zum Extrem zu treiben – es geht darum, die Kopplung zwischen den Modulen und den globalen Trade-off-Raum zu verstehen. Das gilt für Inferenzsysteme und noch mehr für RL Infra, wo die Kopplungsdimensionen größer, die Rückkopplungsschleifen länger und die Informationsdichte für das Debuggen viel niedriger ist. Ich möchte mit zwei Fragen schließen, über die ich nachgedacht habe, und ich würde gerne von anderen hören, die in diesem Bereich arbeiten: Wo genau beginnen die marginalen Erträge der Übereinstimmung zwischen Training und Inferenz zu sinken? Sobald Async eingeführt wird, ist der Off-Policy-Grad bereits erheblich. Auf dieser Basis, ist der inkrementelle Gewinn aus weiterer Übereinstimmung tatsächlich höher-ROI als die gleiche Ingenieureffizienz in die Stabilität der Sandbox, die Optimierung der Belohnungspipeline oder die Infrastruktur zur Beobachtbarkeit zu investieren? Ich habe meine eigene vorläufige Antwort, aber ich denke, diese Frage verdient ernsthafte Überlegungen von mehr Leuten – anstatt einfach die Übereinstimmung zur obersten Priorität zu machen, nur weil es das sichtbarste Thema ist. Und es gibt einen Grund, warum es das sichtbarste ist: Die Übereinstimmung zwischen Training und Inferenz hat eine saubere mathematische Formalisierung und produziert elegante Ablationen – es ist eine natürliche Passform für Papers. Aber wie schreibt man ein Paper über die Stabilität der Sandbox? Wie rahmt man die Zuverlässigkeit der Container-Orchestrierung als akademische Geschichte ein? Das kann man wirklich nicht. Also werden diese Probleme kollektiv ignoriert. Selbst wenn ein RL Infra-System eine bitgenaue Übereinstimmung zwischen Training und Inferenz erreicht, kann die Gesamteffizienz immer noch miserabel sein – weil der Engpass schon lange woanders hin gewandert ist. Inwieweit kann RL Infra standardisiert werden? Inferenzsysteme haben relativ gut definierte Benchmark-Metriken – TTFT, TBT, Durchsatz. Diese objektiven Indikatoren ermöglichen es uns, die Auswirkungen von Optimierungen klar zu bewerten. Aber was sind die Evaluierungsstandards für RL Infra? Trainingsdurchsatz? Proben-Effizienz? End-to-End-Wand-Uhrzeit? Die optimale Architektur könnte dramatisch je nach Szenario variieren (Code-Generierung vs. Agent vs. Schlussfolgerung). Wenn wir nicht einmal einen Konsens darüber haben, wie "gute RL Infra" aussieht, wird es extrem schwierig sein, Ingenieurwissen in diesem Bereich zu akkumulieren und wiederzuverwenden. Ob RL der kritische Pfad zur Verbesserung der Modellfähigkeiten ist – dieses Urteil entwickelt sich noch. Aber wenn die Antwort ja ist, dann ist Infra der am stärksten unterschätzte Engpass auf diesem Weg. Nicht weil niemand daran arbeitet, sondern weil die kollektive Aufmerksamkeit fehlgeleitet ist. Die Grausamkeit des Barrel-Effekts ist dies: Egal wie hoch deine höchste Daube ist, sie kann das System nicht retten. RL Infra ist kein sekundäres Anliegen. Es ist ein unabhängiger, hochkomplexer Bereich des Systemengineering. Nur wenn wir es als gleichwertig behandeln, haben wir eine Chance, RL zu skalieren.