Epochen 9 und 10: ein Nachweis für die Uhr, eine Regel für die Last

Diesen Beitrag anhören14 Min.

Von KI aus dem Text dieses Beitrags erstellt und von einer synthetischen Stimme gelesen; keine wörtliche Fassung, Fehler sind möglich.

Epoche 8 dauerte etwa vier Stunden. Am 2026-10-09 um 22:29 UTC ging das Orakel, die Instanz, die über jede Änderung an Coherent entscheidet, in Epoche 9, am 2026-10-10 um 13:08 UTC in Epoche 10. Keine der beiden änderte die Bedingungen, unter denen ein gewöhnlicher Kandidat spielt. Epoche 9 brachte ein Werkzeug, das am Ende niemand nutzte, und eine Freigabe, die eine Regel zur Rechnerlast fast eine Stunde lang aufhielt. Epoche 10 brachte unter anderem eine bessere Fassung dieser Regel. Dieser Beitrag erzählt beides, auch die Anläufe, die scheiterten.

Kleinere Epochen, dann die goldene Mitte

Am 2026-10-09 bat der Inhaber des Projekts, Epoche 8 so zu lassen, alles Neue in spätere Epochen einzuplanen und Epochen kleiner zu halten. Die Agenten des Projekts machten daraus ein eng gefasstes Thema je Epoche. Am nächsten Morgen stellte der Inhaber klar, gemeint sei eine goldene Mitte: nicht zu oft, aber auch nicht unübersichtlich groß. Eine Prüfung durch drei Modellfamilien im Auftrag des Inhabers hielt den engen Zuschnitt für zu fein. Die Regel seitdem: ein Thema je Epoche, aber breiter gefasst; Teile, die die Messung nicht berühren, dürfen gebündelt werden, jeder mit eigenem Nachweis; nie zwei Änderungen, die die Messung betreffen, in derselben Epoche, weil sich eine Verschiebung sonst keiner zuordnen ließe; und ein Fenster erst, wenn alles vorbereitet und geprüft ist. Dieselbe Prüfung schätzte den Vorbereitungsaufwand auf etwa 5 Agentenstunden für Epoche 9 und mindestens 9 für Epoche 10.

Die neunte Epoche: ein Nachweis für die Uhr

Das Orakel spielt beide Stufen mit einem Zuschlag je Zug, 8+0.08 und 40+0.4 Sekunden. Eine Korrektur, die nur wirkt, wenn eine Engine eine feste Zahl von Zügen je Zeitabschnitt einteilen muss, verhält sich dort genau wie ihr Vorgänger: Der geänderte Code läuft nie. Partien unter den Bedingungen des Orakels können deshalb nie zeigen, was eine solche Korrektur wert ist.

Epoche 9 hängte an den bestehenden Weg für Korrekturen ohne behaupteten Gewinn einen Uhrnachweis. Zuerst dürfen Läufe mit fester Knotenzahl auf einer festen Menge von Stellungen keine Abweichung vom Vorgänger zeigen. Dann misst eine Uhrprobe für feste Stellungen und Uhrstände die Zeit vom Suchbefehl bis zur Antwort, je mindestens 5 Mal in frischen Prozessen. Eine Stellung zählt nur, wenn der Kandidat seine Zeitgrenze in jeder Wiederholung sicher einhält und der Vorgänger sie in jeder Wiederholung verfehlt; Fälle nahe der Grenze zählen nicht. Danach folgt der übliche Test, der nur zeigen muss, dass die Korrektur innerhalb einer Marge nicht schlechter ist.

Gewöhnliche Messungen ändern sich dadurch nicht. Eine Epoche brauchte es trotzdem, weil das Programm des Orakels Teil des Fingerabdrucks der Messbedingungen ist.

Wie das Fenster für die neunte Epoche lief

Die erste Fassung des Codes lag kurz nach 18:00 UTC vor. Die Prüfung der anderen Modellfamilie lehnte sie ab: Sie wäre nur mit einem größeren Mechanismus gelaufen, der bewusst abgeschaltet blieb. Eine kleinere Fassung über den bestehenden Weg wurde um 18:55 angenommen, das Fensterpaket um 19:28. Ab 20:23 wurden keine neuen Tests mehr zugelassen; der letzte Lauf der Epoche 8 endete um 21:03.

Erster Anlauf, 21:15. Der erste Schritt, der nur liest, hielt an: Die Prüfsumme der Stellungsdatei passte nicht. Das Paket nannte die Prüfsumme der Kopie im Repositorium, nicht der Kopie auf dem Orakelrechner; der Inhalt ist gleich, nur ein Kommentar am Anfang unterscheidet sich. Der leitende Agent hielt das als eigenen Fehler fest. Verändert war nichts.

Zweiter Anlauf, 21:37. Der erste Schritt hielt erneut an. Auf dem Orakelrechner lag noch eine Nachweisdatei eines längst zurückgezogenen Kandidaten. Solche Altlasten werden seitdem als veraltet geführt, statt das Fenster anzuhalten.

Dritter Anlauf, 21:46. Die ersten drei Schritte bestanden. Vor dem Anker mussten zwei Modellfamilien die festgeschriebenen Lastbedingungen bestätigen. In der ersten Runde bestätigte eine Familie nicht: Es war nicht belegt, dass die Uhrprobe im direkt folgenden Test keine Spur hinterlässt. In der zweiten Runde bestätigte sie wieder nicht. Ein Vorversuch auf einem anderen Rechner hatte nach einer Uhrprobe 2,1 Prozent mehr Knoten je Sekunde gemessen, mit einem 95-Prozent-Intervall von −1,5 bis +5,8; eine Wirkung war damit nicht ausgeschlossen. Der Uhrnachweis wurde für Epoche 9 deshalb ausgesetzt. In der dritten Runde bestätigten beide. Der Anker folgte um 22:29, mit zweimal byte-gleich gebauter Engine.

Viermal angehalten vor der Freigabe

Bevor das Orakel nach einem Epochenwechsel wieder misst, wird die Last auf dem Orakelrechner geprüft. Die Regel lautete: unter 1 Prozent auf jedem Thread. Vier Prüfungen zwischen 22:32 und 22:41 hielten mit „Last zu hoch“ an, bei 1,7 bis 4,2 Prozent auf einem einzelnen Thread. Ursache waren die eigenen Dienste des Orakels, vor allem seine Schleife, die alle 30 Sekunden läuft. Epoche 8 hatte dieselbe Regel mit 0,3 Prozent nur bestanden, weil ihr 20-Sekunden-Beleg zwischen zwei Durchgänge der Schleife fiel. Die Regel maß den Takt der Dienste, nicht fremde Last.

Die Frist von 15 Minuten für die Freigabe war nicht mehr zu halten. Das Orakel blieb gesperrt, wie vorgesehen, wenn etwas scheitert, und das Fenster schloss um 22:45. Der Inhaber wies dann an: zweimal im Abstand von 5 bis 10 Sekunden messen und Epoche 9 freigeben. Die beiden Belege zeigten höchstens 0,7 und 2,05 Prozent auf einem einzelnen Thread. Um 23:28 wurde das Orakel freigegeben. Den zweiten Beleg hätte die alte Regel nicht bestehen lassen.

Balkendiagramm der höchsten Last eines einzelnen Threads in den Belegen vor der Freigabe. Epoche 8, Freigabe: 0,3 Prozent, freigegeben. Epoche 9, vier Prüfungen: 1,85, 2, 4,2 und 1,7 Prozent, jeweils angehalten wegen zu hoher Last. Epoche 9, zwei Belege auf Anweisung des Inhabers: 0,7 und 2,05 Prozent, freigegeben. Epoche 10, Freigabe: 0,45 Prozent, freigegeben. Eingezeichnet sind die alte Grenze von 1 Prozent je Thread und die neue von 10 Prozent; nach der neuen Regel muss zudem die Summe über alle Threads unter 50 Punkten und das 1-Minuten-Lastmittel unter 0,5 bleiben.
Alte und neue Lastregel (aus einer Messung)

Das Werkzeug ohne Nutzer

In der Nacht versuchten die Agenten ein zweites Mal, den Uhrnachweis zuzulassen. Die andere Familie bestätigte wieder nicht und verlangte eine Ruhezeit nach dem Uhrnachweis, festgeschrieben im Code des Orakels; das hieß eine weitere Epoche. Am 2026-10-10 um 02:53 UTC wurde der Weg des einzigen Kandidaten für den Uhrnachweis geschlossen. Ein Gutachten hatte gefunden, dass der Nachweis Kandidat und Vorgänger in diesem Fall nur zufällig trennte, in 2 von 4 Läufen, und dass der Fall nicht selten ist; der Weg für Korrekturen verlangt beides. Die spätere Prüfung des Epochenzuschnitts hielt fest, dass der einzige genannte Nutzer der Epoche 9 ausgeschieden war.

In Epoche 9 wurde ein Lauf gemessen: eine Änderung am Futility-Rand für stille Züge in der Suche. Er bestand beide Stufen (Tabelle unten). Allein die lange Stufe dauerte etwa 9,6 Stunden.

Die zehnte Epoche: Ruhe, frische Last, eine bessere Regel

Epoche 10 enthält unter anderem die verlangte Ruhezeit und eine neue Lastregel.

Ruhe nach bestandenem Nachweis. Hat eine Korrektur auf dem Weg für Korrekturen ohne behaupteten Gewinn ihren Nachweis bestanden, wartet das Orakel 600 Sekunden ab dem Ende des Nachweises, bevor der Test beginnt. Der Wert ist nicht aus einer Messung hergeleitet; er übernimmt die bestehende Wartezeit nach einem Anker.

Frische Last vor der ersten Stufe. Nach der Ruhe misst das Orakel 20 Sekunden lang die Last auf allen Threads. Nach einem erfolglosen Beleg wartet es 180 Sekunden bis zum nächsten Versuch, insgesamt höchstens 3 Belege. Besteht keiner, hält es an, ohne zu testen.

Eine neue Lastregel. Sie ersetzt „unter 1 Prozent auf jedem Thread“. Ein Beleg besteht nur, wenn er alle 128 Threads mit gültigen Werten umfasst, die Summe über alle Threads unter 50 Prozentpunkten bleibt, also einem halben Thread, kein Thread 10 Prozent erreicht und das 1-Minuten-Lastmittel unter 0,5 bleibt. Das wichtigste Maß ist die Summe: Ein fremder Prozess, der einen Thread beschäftigt, zeigt sich darin, wie auch immer das System ihn auf die Threads verteilt, während die eigenen Dienste des Orakels weit darunter bleiben. Dieselbe Regel gilt vor der ersten Messung einer Epoche und vor der ersten Stufe nach einem bestandenen Nachweis.

Ruhezeit und frischer Lastbeleg folgen auf einen bestandenen Nachweis im Weg für Korrekturen ohne behaupteten Gewinn. Zugelassen war in Epoche 10 dafür nur der Nachweis des einen Kandidaten mit Uhrnachweis. Seit dessen Weg geschlossen ist, läuft dieser Teil der Epoche 10 derzeit nicht.

Wie das Fenster für die zehnte Epoche lief

Ab 06:04 UTC am 2026-10-10 wurden keine neuen Tests mehr zugelassen, und der laufende Test, der Lauf zum Futility-Rand, durfte zu Ende laufen. Das Fenster öffnete um 12:43; die ersten drei Schritte bestanden. In der ersten Runde zur Bestätigung der Lastbedingungen lehnten beide Modellfamilien ab: Der leitende Agent hatte Text außerhalb der für Werte vorgesehenen Stellen ergänzt und einen falschen Bezug genannt, ein eigener Fehler. Die zweite Runde verwendete den ursprünglichen Entwurf mit den Messwerten und einem berichtigten Bezug, und beide bestätigten. Der Anker folgte um 13:08, wieder mit zwei gleichen Bauten.

Der Schritt, der vor der Freigabe die Dienste wieder anlaufen lässt, brach in seiner ersten Zeile ab, ohne Wirkung: Ein Beleg war vorher nicht übertragen worden, wieder ein eigener Fehler des leitenden Agenten. Nachdem der Inhaber den Schritt von Hand zurückgesetzt hatte, ging er um 13:18 durch. Die Freigabe kam um 13:19, im ersten Versuch nach der neuen Regel: eine Summe von 4,1 Punkten, höchstens 0,45 Prozent auf einem einzelnen Thread, ein Lastmittel von 0,00. Vom Öffnen des Fensters bis zur Freigabe vergingen etwa 36 Minuten; in Epoche 9 dauerte dieselbe Strecke ab dem Öffnen des dritten Anlaufs 1 Stunde und 42 Minuten.

Die ersten Ergebnisse der zehnten Epoche

In Epoche 10 sind drei Läufe abgeschlossen. Eine Beschleunigung um etwa 1 Prozent bei unverändertem Suchbaum wurde in der kurzen Stufe abgelehnt; unter diesen Bedingungen zeigte der Lauf keinen Gewinn durch die Beschleunigung. Eine stärkere Skalierung der Netzbewertung nach Material bestand beide Stufen. Ebenso das Netz, nachtrainiert auf Stellungen aus eigenen Partien, bewertet durch eine tiefere eigene Suche. Diese Tests endeten nach wenigen Partien; die Werte sind grobe Schätzungen.

LaufEpocheKurze Stufe, Elo (Partien)Lange Stufe, Elo (Partien)
Futility-Rand für stille Züge9+4,92 ± 3,48 (9.878)+3,69 ± 2,80 (14.122)
Beschleunigung, Suchbaum unverändert10−0,17 ± 1,86 (24.792)nicht gespielt
Skalierung der Bewertung nach Material10+9,43 ± 5,15 (4.422)+13,02 ± 6,10 (2.990)
Netz nachtrainiert auf eigenen Partien10+24,60 ± 8,58 (1.542)+31,43 ± 9,51 (1.186)

Die Epochen 9 und 10 änderten wenig daran, was das Orakel misst, und einiges daran, wie es entscheidet, wann es messen darf. Die alte Lastregel hielt eine Freigabe wegen des eigenen Takts des Orakels an. Die neue Regel schaut vor allem auf die Summe, und die Freigabe bestand sie im ersten Versuch.