DE
von Tim Varelmann
In der letzten Oktoberwoche 2025 fand die europäische Ausgabe des Gurobi Summit in Wien statt. Etwa 250 Teilnehmende kamen zusammen, um reale Optimierungserfolge zu teilen, aktuelle Entwicklungen kennenzulernen – und die beeindruckende Hofburg zu bestaunen, ein Veranstaltungsort, der selbst Diskussionen um Modelle, Algorithmen und mathematische Software ganz besonders wirken ließ.
Einige Vorträge sind mir besonders in Erinnerung geblieben:
Zwischen inspirierenden Vorträgen, tollen Pausengesprächen und traditionellen österreichischem Essen kündigte Gurobi eine Solver-Tuning-Challenge an.
Optimierungssolver wie Gurobi können viele Probleme „out of the box“ lösen. Aber mit den richtigen Anpassungen – dem Tuning von Solver-Parametern – lässt sich die Laufzeit oft um bis zu einen Faktor 10 verkürzen.
Gemischt-ganzzahlige Optimierung ist und bleibt ein „Beutel voller Tricks“ wie die Gurobi Gründer zu sagen pflegen – und durch Tuning kann man entscheiden, welche Tricks man öfter und intensiver anwendet oder weglässt.
Der Preis?
Eine Wiener Sachertorte – die ikonische Schokoladentorte aus der k.u.k. Hofzuckerbäckerei.
Die Aufgabe?
Den besten Satz nicht-standardmäßiger Solver-Parameter finden, um ein gegebenes Modell so schnell wie möglich zu lösen.
Ich war sofort neugierig – und natürlich sehr motiviert durch den Kuchen.
Die Challenge hatte einen interessanten Kniff: Die Bewertung erfolgte anhand der durchschnittlichen Laufzeit über drei Läufe, jeweils mit einem anderen sogenannten random seed.
Das klingt unscheinbar, ist aber genial. Solver nutzen intern Zufall – zum Beispiel, um alternative Suchpfade zu wählen.
Dasselbe Modell kann also je nach seed völlig unterschiedliche Rechenzeiten haben.
Durch diese Vorgabe zeigte Gurobi sehr elegant, woran viele Praktiker selten denken:
Man sollte die Performance eines Solvers nie auf Basis eines einzigen Laufs beurteilen.
Selbst erfahrene Optimierer – mich eingeschlossen – wurden daran erinnert, dass „ein paar schnelle Tests“ leicht in die Irre führen können.
Beim nächsten Performance-Benchmark werde ich definitiv mit mehreren seeds messen – nicht nur mit einem.
Ich wählte mein Modell und begann zu experimentieren. Mit den Standardparametern lag die durchschnittliche Laufzeit bei etwa 200 Sekunden, aber die einzelnen Läufe schwankten stark – zwischen 75 und 330 Sekunden.
Um zu verstehen, was im Solver passiert, schaute ich mir die Logfiles an, die Gurobi bei jedem Lauf erstellt. Daraus ergab sich für mich ein Bild wie dieses:
Die blaue Linie zeigt den jeweils besten gefundenen zulässigen Wert der Zielfunktion.
Die rote Linie stellt die untere Schranke dar – also den besten theoretisch noch möglichen Wert zu dem noch keine Lösung gefunden wurde.
Die rote Fläche dazwischen ist die Optimalitätslücke.
Man erkennt: Die optimale Lösung wird sehr früh gefunden – doch der Großteil der Laufzeit wird darauf verwendet, ihre Optimalität zu beweisen. Fast die gesamte Rechenzeit fließt also in das Schließen dieser roten Lücke.
Diese Beobachtung brachte mich zum Nachdenken:
Wenn die optimale Lösung so früh gefunden wird – warum dann Minuten darauf verwenden, sie auf viele Nachkommastellen zu verifizieren?
Standardmäßig verwendet Gurobi eine Optimalitätstoleranz von 1e-6, das heißt, der Solver beendet erst, wenn sicher ist, dass keine Lösung existiert, die auch nur um den millionsten Teil besser ist.
In vielen realen Anwendungen – vor allem in Chemie- und Produktionsplanung, meinem akademischen Hintergrund – sind unsere Modelle aber nur Näherungen der Realität. Eine Genauigkeit von 1 % oder sogar 5 % ist oft das Beste, was sinnvoll ist.
Warum also nach Perfektion streben, wenn das Modell selbst gar nicht so genau ist?
Kurz dachte ich daran, eine augenzwinkernde Lösung einzureichen, die einfach nur die Optimalitätstoleranz lockert – das hätte die Laufzeit praktisch auf null reduziert.
Aber ich entschied mich dagegen; das wäre zu simpel gewesen. Stattdessen wollte ich zeigen, dass sich echte Performance-Verbesserungen auch bei gleicher Präzision erreichen lassen.
Als die Ergebnisse verkündet wurden, zeigte Mario Ruthmair von Gurobi eine Grafik ähnlich der obigen und erwähnte, schmunzelnd, dass jemand genau das getan hatte, was mir zuerst eingefallen war – die Toleranz zu verändern.
In diesem Moment dachte ich, ich sei aus dem Rennen.
Offenbar hatte jemand den einfachen Trick genutzt, während ich mich mit zu vielen Details aufgehalten hatte.
Dann fügte Mario lachend hinzu, dass er diese Einreichung disqualifiziert habe, da sie nicht dem geforderten Optimalitätskriterium entsprach.
Ich atmete auf.
Und als er weiter erwähnte, dass die beste gültige Lösung „etwa 45 Sekunden“ gebraucht habe, wusste ich:
Mein letzter Lauf lag bei 45,04 Sekunden.
Ich war wieder im Spiel.
Ja – ich durfte tatsächlich nach vorne gehen und die Sachertorte entgegennehmen. Hier sind die Parameter, mit denen ich das beste Ergebnis erzielt habe:
Dieser Parameter steuert, worauf Gurobi den Fokus legt: gute Lösungen finden, Optimalität beweisen oder die untere Schranke verbessern. Ich begann mit „untere Schranke verbessern“, da das der Engpass zu sein schien. Zwei Läufe waren nach rund 20 Sekunden fertig – doch ein dritter konvergierte selbst nach 10 Minuten nicht. Zu riskant. Also stellte ich auf „Optimalität beweisen“ um – eine ausgewogenere Variante. Das brachte stabile und konstant schnelle Ergebnisse.
Sogenannte „Cuts“ sind mathematische Abkürzungen, die unnötige Bereiche des Suchraums ausschließen. Ich stellte die Aggressivität der Cut-Erzeugung aufs Maximum – und erhielt einen weiteren Performance-Schub.
Durch zusätzliche Anstrengung bei der Erkennung und Beseitigung von Symmetrien (gleichwertige Modellteile, die doppelte Arbeit verursachen) ließ sich die Laufzeit nochmals leicht verkürzen. Diesen Tipp verdanke ich übrigens meinem KI-Assistenten – und er hat tatsächlich funktioniert!
Heuristiken helfen, früh gute zulässige Lösungen zu finden. Da mein Modell ohnehin schnell eine fand, reduzierte ich den Aufwand von standardmäßig 5 % auf 0 %. Selbst das vollständige Abschalten hatte keinen negativen Effekt – die Lösung war ohnehin rasch da.
Der Gewinn der Sachertorte war schön – doch die eigentliche Erkenntnis war wertvoller.
Das Gurobi-Team wies zu Recht darauf hin, dass man in realen Projekten nur wenige Parameter ändern sollte – zu viele Anpassungen können kontraproduktiv sein.
Aber in diesem Wettbewerb ging es gerade darum, ans Limit zu gehen – und das hat sich gelohnt.
Zu Hause freute sich meine Familie, dass ich diesmal nicht nur „nerdige Erkenntnisse“ von einer Konferenz mitbrachte – sondern auch echten Kuchen.
Danke an das Gurobi-Team für ein großartiges Event, eine clevere Challenge und einen rundum authentischen Preis.
Verpasse keine meiner Ideen und Aha-Momente aus der Welt der Optimierung!
Hast du dich schon mal gefragt, wie der Weihnachtsmann alle Geschenke verpackt, wenn das Geschenkpapier knapp wird? Gemeinsam mit Chahira Mourad, entdecken wir wie Optimierung Weihnachten rettet. Mitmachen erwünscht mit unserem open-source Code!
Im Gespräch mit interessierten Leuten sage ich häufig, dass Computer mit Optimierung nicht-emotionale Entscheidungen treffen können. In meinen Projekten sind das meist Planungen: Von Produktion, Energiegewinnung oder Transporten. Weniger alltägliche Entscheidung sind in diesem magisches Beispiel.
