Scikit-learn 1.9 am 12. Juni 2026 veröffentlicht: Ein großer Schritt für das Engineering klassischer ML

Das scikit-learn-Kernteam hat Version 1.9.0 am 12. Juni 2026 veröffentlicht und markiert damit eine der funktionsreichsten Versionen der Bibliothek in letzter Zeit. Das Update kommt zu einem kritischen Zeitpunkt für das Machine-Learning-Ökosystem: Während große Sprachmodelle weiterhin die Schlagzeilen dominieren, haben die scikit-learn-Betreuer ihre Anstrengungen auf das verdoppelt, was die Bibliothek am besten kann – schnelles, interpretierbares, produktives klassisches Machine Learning – und modernisieren gleichzeitig ihre Schnittstelle für die nächste Generation von ML-Tools. Die Version ist auf PyPI verfügbar und kompatibel mit Python 3.11 bis 3.14.

Für Ingenieure, die ML-Pipelines auf strukturierten, tabellarischen Daten erstellen – das Kerngeschäft von Enterprise ML – bietet scikit-learn 1.9 eine Fülle von Verbesserungen: ein brandneues experimentelles Callback-System zur Trainingsüberwachung, erweiterte GPU-Beschleunigung über die Array API, eine leichtere Dataframe-Kompatibilitätsschicht via narwhals und eine deutlich umfangreichere HTML-Estimator-Visualisierung. Diese Änderungen sprechen zusammen lange bestehende Reibungspunkte für Praktiker an, die sklearn-Modelle in großem Maßstab bereitstellen.

Die Veröffentlichung erfolgt auch vor dem Hintergrund einer aktiven Partnerschaft mit Hugging Face, der AI-Plattform, die sich zur zentralen Drehscheibe der Open-Source-ML-Community entwickelt hat. Obwohl Version 1.9 keine neue Hugging Face-spezifische Integrationscode enthält, haben die beiden Organisationen über vier Jahre hinweg eine gemeinsame Infrastruktur aufgebaut – besonders durch die skops-Bibliothek – die jetzt fast 800 scikit-learn-Modelle auf dem Hugging Face Hub beherbergt. Zusammen repräsentieren die Version 1.9 und die reifende sklearn–Hugging Face-Pipeline einen entscheidenden Moment für klassisches ML im Zeitalter von Foundational Models.

Die Callback-API: Echtzeit-Trainingsüberwachung kommt zu Scikit-learn

Die einflussreichste Ergänzung in Version 1.9 ist der experimentelle Callback-Mechanismus, eine lange geforderte Funktion, die Echtzeit-Überwachung und Fortschrittssichtbarkeit in die Trainingschleife von scikit-learn-Estimatoren einführt. Bislang hatten ML-Ingenieure, die sklearn verwendeten, keine native Möglichkeit, ein Modell während des Trainings zu beobachten – keine Fortschrittsbalken, keine Live-Verlustskurven, keine Early-Stopping-Hooks. Diese Lücke zwang Teams, auf Workarounds wie ausführliche Protokollierungsflags oder externe Bibliotheken auszuweichen. Version 1.9 schließt sie definitiv.

Das Callback-System führt zwei konkrete Implementierungen direkt ein:

• sklearn.callback.ProgressBar – rendert eine Live-Fortschrittsleiste während fit() und gibt Ingenieuren einen Echtzeit-Überblick über den Trainingsfortschritt, ohne das Notebook oder Terminal zu verlassen
• sklearn.callback.ScoringMonitor – protokolliert Scoring-Metriken bei jeder Iteration der Optimierungsschleife und ermöglicht Konvergenztracking ohne externe Tools oder benutzerdefinierte Boilerplates

In Version 1.9 wird das Callback-System von einer gezielten, aber bedeutsamen Reihe von Estimatoren unterstützt: LogisticRegression (mit dem lbfgs Solver), die vollständige SearchCV-Familie (GridSearchCV, RandomizedSearchCV, HalvingGridSearchCV und HalvingRandomSearchCV), Pipeline und StandardScaler. Die Betreuer haben deutlich signalisiert, dass dies ein Fundament ist, keine Obergrenze – der Veröffentlichungsblog-Post beschreibt den Callback-Mechanismus als einen, der "die Tür zu Fortschrittsbalken oder fortschrittlicher Konvergenzüberwachung öffnet", wobei eine breitere Estimator-Abdeckung für nachfolgende Versionen geplant ist.

Die Bedeutung dieser Funktion geht über die Benutzerfreundlichkeit hinaus. Für Teams, die scikit-learn in größere MLOps-Pipelines integrieren – wo Überwachung, Alerting und Auditierbarkeit nicht verhandelbar sind – bietet die Callback-API einen programmatischen Hook, der in Logging-Infrastruktur, Dashboards oder Experiment-Tracker wie MLflow und Weights & Biases einfließen kann. Es signalisiert, dass das scikit-learn-Team ernsthaft über den operativen Kontext nachdenkt, in dem ihre Bibliothek verwendet wird, nicht nur über die statistische Korrektheit ihrer Algorithmen.

"Der Callback-Mechanismus öffnet die Tür zu Fortschrittsbalken oder fortschrittlicher Konvergenzüberwachung" – scikit-learn 1.9 Veröffentlichungsmitteilung, Juni 2026

Vorausblickend bedeutet der experimentelle Status der Callback-API, dass sich die Schnittstelle vor der Stabilisierung möglicherweise entwickelt. Ingenieure, die Produktionssysteme darauf aufbauen, sollten die API-Oberfläche als Änderungen durch die Versionen 1.10 und 1.11 unterworfen betrachten. Allerdings ist das Design bereits aussagekräftig genug, um die häufigsten Überwachungsanwendungsfälle abzudecken, und die Gemeinschaftsreaktion seit der Veröffentlichung am 12. Juni war größtenteils positiv, mit mehreren MLOps-Tool-Betreuern, die bereits mit Callback-Adaptern für ihre Plattformen experimentieren.

GPU-Beschleunigung und Array API: Scikit-learn bewegt sich in Richtung Hardware-Neutralität

Eine der bestimmenden Erzählungen des Zeitraums 2024–2026 im ML-Engineering war die Beschleunigung der Hardware-Vielfalt: Ingenieure sind nicht mehr auf CPUs für klassisches ML beschränkt. Scikit-learns Antwort auf diesen Trend – die schrittweise Einführung der Array API-Unterstützung – machte in Version 1.9 einen bedeutenden Schritt nach vorne. Die Veröffentlichung erweitert die GPU-kompatible Ausführung auf eine breitere Reihe von Estimatoren und Metriken und entkoppelt scikit-learn weiter von der Annahme, dass die gesamte Berechnung auf einer CPU mit NumPy-Arrays erfolgt.

In Version 1.9 sind die Hauptmerkmalswerte, die GPU-Unterstützung über die Array API erhalten,:

• linear_model.LogisticRegression mit solver="lbfgs" – einer der am häufigsten verwendeten Estimatoren in der Bibliothek läuft jetzt nativ auf GPU
• linear_model.PoissonRegressor mit solver="lbfgs" – kritisch für Zähldaten und Versicherungs- oder Versicherungsmathematik-Anwendungen
• kernel_approximation.Nystroem – GPU-beschleunigte Kernel-Approximation schaltet großflächige Kernel-SVM-Workflows frei
• pipeline.FeatureUnion – ermöglicht vollständig GPU-beschleunigte Multi-Branch-Feature-Kombinationspipelines

Metrikfunktionen erhielten auch in 1.9 Abdeckung: d2_absolute_error_score, d2_pinball_score und average_precision_score akzeptieren jetzt Array API-konforme Eingaben, was bedeutet, dass sie direkt auf GPU-Tensoren arbeiten können, ohne Daten zurück auf die CPU zu kopieren. Die Version enthält auch ein neues Hilfsprogramm, sklearn.utils._array_api.move_estimator_to, das es Ingenieuren ermöglicht, die Array-Attribute eines trainierten Estimators auf ein anderes Gerät oder einen anderen Namespace zu verschieben – ein kritischer Enabler für gemischte Device-ML-Pipelines, bei denen die Vorverarbeitung auf CPU erfolgen kann, während die Inferenz auf GPU ausgeführt wird.

Die praktischen Auswirkungen sind erheblich. Unabhängige Benchmarks, die von :probabl. im März 2026 veröffentlicht wurden, zeigten Beschleunigungen von bis zu 15x in komplexen scikit-learn-Pipelines bei Ausführung auf GPU über die Array API. Obwohl diese Gewinne stark vom Modelltyp und der Datengröße abhängen – kleinere Datensätze sehen oft keinen Vorteil aufgrund des Datenübertragungsoverheads – validieren sie die strategische Richtung: Für große tabellarische Datensätze und rechenintensive Pipelines ist GPU-beschleunigtes sklearn jetzt eine praktikable Produktionsoption.

Modernisierung der Sparse-Schnittstelle

Version 1.9 führt auch den Konfigurationsschlüssel "sparse_interface" ein, mit dem Benutzer steuern können, ob scikit-learn SciPy-Sparse-Matrizen oder die neuere Sparse-Array-Schnittstelle zurückgibt:

import sklearn
sklearn.set_config(sparse_interface="sparray")  # opt into sparse arrays

Dies ist Teil einer breiteren Ausrichtung mit der Richtung des SciPy-Ökosystems, das seit SciPy 1.8 vom Legacy-Format csr_matrix zu csr_array wechselt. Der aktuelle Standardwert bleibt für Rückwärtskompatibilität "spmatrix", aber das Team hat einen zukünftigen Standardwechsel zu "sparray" in kommenden Versionen signalisiert. Ingenieure, die neue Pipelines erstellen, sollten heute in Betracht ziehen, sich für die neue Schnittstelle anzumelden, um eine störende Migration später zu vermeiden.

Narwhals-Integration: Ein leichterer Weg zur Dataframe-Interoperabilität

Eine der stilleren, aber strategisch wichtigen Änderungen in scikit-learn 1.9 ist das Hinzufügen von narwhals als neue Bibliotheksabhängigkeit. Narwhals ist eine leichte Kompatibilitätsschicht, die Python-Code ermöglicht, nahtlos über mehrere Dataframe-Bibliotheken zu arbeiten – hauptsächlich pandas und Polars – ohne bedingte Verzweigungen pro Bibliothek zu benötigen. Mit der Annahme von narwhals erkennt scikit-learn eine Realität an, die Praktiker in den letzten zwei Jahren gespürt haben: Das Python-Datenökosystem ist nicht mehr gleichbedeutend mit pandas allein.

Der unmittelbare Impetus für diese Änderung ist die Veraltung des Dataframe-Austauschprotokolls (__dataframe__) durch das Polars-Team. Scikit-learn hatte sich auf dieses Protokoll verlassen, um Nicht-Pandas-Dataframes über seine in Version 1.2 eingeführte set_output-API zu handhaben. Mit Polars, die das Protokoll veralten, benötigte das sklearn-Team eine robustere Lösung, die nicht unterbrochen würde, während die Polars-API weiterhin evolvierte. Wie das Changelog von Version 1.9 erklärt, bietet narwhals genau das: eine einheitliche, leichte Schnittstelle, die über der Dataframe-Schicht sitzt und Operationen in die zugrunde liegende Bibliothek übersetzt.

Für ML-Ingenieure ist dies eine erhebliche Verbesserung der Lebensqualität mit echten Produktionsauswirkungen. Polars, das Leistung durch Lazy Evaluation, Multi-Threading-Verarbeitung und ein Rust-Backend priorisiert, hat erhebliche Aufmerksamkeit als Alternative zu pandas für Datenvorverarbeitung im großen Maßstab gewonnen. Teams, die ihre Vorverarbeitungs-Upstreampipelines zu Polars migriert haben, können jetzt set_output(transform="polars") in scikit-learn verwenden, ohne auf die Kompatibilitätsprobleme zu stoßen, die der Austauschprotokoll-Ansatz plagte. Die narwhals-Brücke stellt sicher, dass sklearn-Transformer-Ausgaben – sei es von StandardScaler, ColumnTransformer oder benutzerdefinierten Estimatoren – nativ als Polars DataFrames zurückgegeben werden können, wobei der Lazy-Ausführungskontext stromabwärts erhalten bleibt.

Die Wahl von narwhals – ein von der Community getriebenes Projekt statt einer First-Party-Lösung von einem der pandas- oder Polars-Teams – spiegelt die Vorliebe des scikit-learn-Teams für Ökosystem-Neutralität wider. Statt auf eine Bibliothek-interne API zu wetten, haben sie eine Abstraktionsschicht angenommen, die sich zusammen mit dem breiteren Ökosystem entwickelt. Dies ist der gleiche philosophische Ansatz, der die Einführung der Array API motivierte: Wenn möglich, sollte scikit-learn ein Verbraucher von Community-Standards sein, statt ein Definieren von proprietären Schnittstellen.

Für Datenwissenschaftler, die an der Schnittstelle von sklearn und modernen Data-Stack-Tools arbeiten – Pipelines, die von Parquet via DuckDB eingespeist werden, mit Polars vorverarbeitet und mit sklearn modelliert – schließt narwhals eine Lücke, die zuvor manuelle Konvertierungsschritte oder benutzerdefinierten Wrapper-Code erforderte. Die End-to-End-Pipeline kann jetzt das ganze Wege durch die sklearn-Transform-Phase in Polars-nativem Territorium bleiben.

Scikit-learn und Hugging Face Hub: 800 Modelle und eine vertiefende Partnerschaft

Die scikit-learn 1.9-Veröffentlichung enthält keinen neuen First-Party-Hugging-Face-Integrationscode, sondern landet innerhalb eines Ökosystems, das seit Juni 2022 ruhig gereift hat, als Hugging Face ein offizieller Sponsor des scikit-learn-Konsortiums bei der Fondation Inria in Paris wurde. Diese Partnerschaft, nun in ihrem vierten Jahr, hat konkrete Infrastrukturveränderungen hervorgebracht, die transformieren, wie klassische ML-Modelle geteilt, bereitgestellt und entdeckt werden.

Das Herzstück der sklearn–Hugging Face-Integration ist skops, eine Python-Bibliothek, die speziell entwickelt wurde, um die beiden Ökosysteme zu verbinden. Skops bietet zwei Kernfähigkeiten, die echte Schmerzpunkte bei der klassischen ML-Modellverteilung ansprechen:

1. Sichere Serialisierung via skops.io – scikit-learn-Modelle werden als Zip-Archive mit zugehörigen JSON-Schemadateien verpackt, was das unsichere pickle-Format ersetzt, das lange Zeit ein Sicherheitsproblem beim ML-Modellfreigabe ist. Im Gegensatz zu pickle erlaubt das skops-Format Modellverbrauchern, die vollständige Objektstruktur vor dem Laden zu überprüfen, was einen sinnvollen Schutz vor Lieferkettenangriffen via bösartige Modelldateien bietet – ein Bedrohungsvektor, der immer relevanter wird, während der Hugging Face Hub skaliert.
2. Hugging Face Hub-Integration via skops.card – mit skops können Ingenieure trainierte sklearn-Modelle direkt auf den Hub pushen, Modellkarten automatisch aus Estimator-Metadaten generieren und Modelle für browserbasierte Inferenz durch Hugging Face Spaces verfügbar machen. Die Modellkartengeneration allein entfernt eine Dokumentationslast, die Praktiker zuvor davon abhielt, klassische ML-Modelle öffentlich zu teilen.

Der Umfang dieser Integration spiegelt sich in aktuellen Hub-Statistiken: Stand Juni 2026 gibt es 799 scikit-learn-Modelle auf dem Hugging Face Hub, die sich über tabellarische Klassifikation, tabellarische Regression und einen wachsenden Satz strukturierter Vorhersageaufgaben erstrecken, einschließlich Kreditbewertung, Betrugserkennung, Kundenabwanderungsprognose und medizinische Risikostratifizierung. Diese Zahl repräsentiert eine Bibliothek, die vor vier Jahren praktisch keine Präsenz auf dem Hub hatte – Hugging Face-Plattform wurde hauptsächlich um Deep-Learning-Modelle für NLP, Vision und Audio aufgebaut. Das Wachstum von sklearn-Modellen auf dem Hub signalisiert eine wichtige Verbreiterung des Plattformumfangs: Sie wird zu einem Zuhause für den vollständigen ML-Stack, nicht nur zu neuronalen Netzen.

Das menschliche Kapital hinter der Partnerschaft

Die institutionelle Investition, die die Zusammenarbeit untermauert, ist gleich bemerkenswert. Zwei erfahrene Entwickler sind speziell bei Hugging Face eingebettet, um das sklearn-Ökosystem voranzutreiben: Adrin Jalali, ein Kern-scikit-learn-Beitragender, der zentral für die Governance und API-Design der Bibliothek war, und Benjamin Bossan, Autor der weit verbreiteten skorch-Bibliothek, die scikit-learn und PyTorch verbindet. Ihre Präsenz bei Hugging Face stellt sicher, dass die Integration von Ingenieuren vorangetrieben wird, die scikit-learns Internals auf der Ebene verstehen, die erforderlich ist, um zuverlässiges, zukunftsfähiges Tooling aufzubauen.

Die Partnerschaft hat auch institutionelle Tiefe durch die Evaluate-Bibliothek, Hugging Face's Framework für effiziente, standardisierte ML-Evaluation. Die Evaluate-Bibliothek wird erweitert, um scikit-learn-Metriken in ihrer API nativ zu unterstützen, was es Ingenieuren ermöglichen würde, sklearn-Metriken zu berechnen und zu vergleichen – Präzision, Recall, F1, AUC, Kalibrierung – zusammen mit Deep-Learning-Metriken innerhalb einer einzigen Evaluation-Pipeline. Dies ist ein wichtiger Schritt zu einheitlichen ML-Evaluierungs-Tools über klassische und neurale Ansätze hinweg, was die operative Komplexität reduziert, die derzeit aus dem Pflegen separater Evaluierungscode für unterschiedliche Modellpfade entsteht.

Was die scikit-learn 1.9-Veröffentlichung für auf dem Hub gehostete Modelle bedeutet

Für die 799 Modelle, die bereits auf dem Hub gehostet sind, übersetzen sich die scikit-learn 1.9-Verbesserungen direkt in bessere Modellqualität. Die verbesserte Behandlung von Stichprobengewichtungen in baumgestützten Modellen und die verbesserte numerische Stabilität in Ridge-Regressions-Modellen bedeuten, dass Modelle, die mit 1.9 umgelernt werden, statistisch korrektere Ausgaben erzeugen sollten, besonders für Modelle, die auf Umfrage- oder Verwaltungsdaten trainiert wurden, bei denen Stichprobengewichtungen häufig sind. Ingenieure, die sklearn-Modelle auf dem Hub verwalten, sollten in Betracht ziehen, das Training mit Version 1.9 erneut auszuführen und ihre Modellkarten zu aktualisieren – die neue HTML-Estimator-Ansicht macht es deutlich einfacher, genaue Modellarchitektur-Beschreibungen zu generieren.

Zusätzliche Verbesserungen: Schnellere Algorithmen, intelligentere Visualisierungen und wichtige Veraltungen

Jenseits der Haupt-Features liefert scikit-learn 1.9 ein dichtes Paket von algorithmischen Verbesserungen, Visualisierungs-Upgrades und Bugfixes, die alltägliche ML-Engineering-Arbeiten nutzen. Mehrere davon verdienen Aufmerksamkeit von Praktikern, die sie möglicherweise in den Release Notes übersehen.

Algorithmische Leistungsgewinne

FastICA mit dem Deflations-Algorithmus ist ungefähr 10x schneller in Version 1.9, eine dramatische Verbesserung für Teams, die Independent Component Analysis für Signaltrennung in Audioverarbeitung, Neurowissenschaft (EEG/fMRI) oder finanzielle Zeitreihenzerlegung verwenden. RidgeCV und RidgeClassifierCV – unter den am häufigsten eingesetzten Modellen in produktivem klassischem ML – sind jetzt schneller und numerisch stabiler, was Edge Cases behebt, die bei schlecht konditionierten Designmatrizen unzuverlässige Alpha-Auswahl erzeugen konnten. Der ARPACK-Eigensolver, der in SpectralEmbedding verwendet wird, wurde optimiert, wobei Graph-basierte Manifold-Learning-Workflows profitieren, die auf Eigenzerlegung großer dünngebesetzter Matrizen beruhen.

Neue metric_at_thresholds() Funktion

Die neue metrics.metric_at_thresholds() Funktion berechnet Metrikwerte über alle möglichen Klassifikationsschwellen aus einem einzelnen Pass über Modellvorhersagen. Vor dieser Addition erforderte das Berechnen von Schwellensensitivitätskurven für binäre Klassifizierer – eine Routineaufgabe in medizinischen Diagnosen, Betrugserkennung und jeder Anwendung, bei der der Betriebspunkt abstimmbar ist – entweder benutzerdefinierten Loop-Code oder Nachbearbeitung von precision_recall_curve() und roc_curve() Ausgaben. Die neue Funktion standardisiert diesen Workflow und integriert sich sauber mit dem Rest der sklearn-Metriken-API.

Reichere HTML-Estimator-Visualisierungen

Die HTML-Darstellung von trainierten Estimatoren in Jupyter-Notebooks wurde erheblich verbessert. Trainierte Attribute (die auf _ enden, wie coef_, feature_importances_ und n_iter_) werden jetzt in einer strukturierten Tabelle innerhalb der HTML-Ansicht angezeigt, was es Ingenieuren ermöglicht, gelernte Parameter auf einen Blick zu überprüfen, ohne print(model.coef_) aufzurufen. ColumnTransformer zeigt jetzt Ausgabe-Featurnamen mit Copy-Paste-Buttons in der Visualisierung, was es dramatisch einfacher macht, nachzuverfolgten, wie Input-Features durch komplexe Vorverarbeitungspipelines zugeordnet werden. Für Teams, die Jupyter für Explorations-Modellentwicklung und Stakeholder-Kommunikation verwenden, reduzieren diese Visualisierungs-Verbesserungen sinnvoll die Reibung der Modellprüfung.

Baum- und Lineare-Modell-Verbesserungen

RandomForestRegressor unterstützt jetzt native Behandlung fehlender Werte bei Verwendung des Kriteriums absolute_error – was eine Lücke schließt, die Praktiker zwang, Daten vor dem Anpassen von Ensemble-Modellen in Kontexten zu imputieren (wie Gesundheitsakten oder Sensordaten), bei denen Fehlen Informationen trägt und nicht imputiert werden sollte. Die Veröffentlichung verbessert auch die statistische Korrektheit der Stichprobengewichtungsbehandlung in HistGradientBoosting, RandomForest und ExtraTree, wobei subtile Biases behoben werden, die Modelle, die auf unausgeglichenen Datensätzen oder Erhebungsdaten mit Wahrscheinlichkeitsgewichtungen trainiert wurden, beeinflussen konnten. Zusätzlich unterstützen Multi-Task-Linearmodelle jetzt dünnbesetzte Input-Matrizen X und Stichprobengewichtungen – eine wichtige Fähigkeit für NLP-Praktiker, die Multi-Output-Regression auf dünnbesetzten Document-Feature-Matrizen verwenden.

Veraltungen zum Beobachten

Version 1.9 führt mehrere Veraltungen ein, die Teams vor den geplanten Breaking Changes in den Versionen 1.11 und 1.12 migrieren sollten:

• criterion="friedman_mse" in baumgestützten Modellen ist veraltet; das Standard-"squared_error" Kriterium ist die empfohlene Alternative
• SVC.probability Parameter ist veraltet; die empfohlene Alternative ist CalibratedClassifierCV mit einem Basis-SVC(probability=False)
• n_alphas Parameter ist in lasso_path() und enet_path() veraltet
• Das Standard-Scoring in LogisticRegressionCV wird sich in Version 1.11 von Genauigkeit zu "neg_log_loss" ändern – eine statistisch motivierte Änderung, die Teams, die sich auf das aktuelle Standard-Verhalten für Schwellenbasierte Modellauswahl verlassen, überraschen kann

Diese Veraltungen folgen scikit-learns Konvention, zwei Hauptversionen vor Breaking Changes zu warnen, was Teams angemessene Laufzeit gibt, um ihren Code zu aktualisieren, ohne Notfall-Refactors.

Quellen

• Scikit-learn release 1.9: better numerics, new core functionality (scikit-learn Blog)
• Version 1.9 — scikit-learn 1.9.0 release notes (scikit-learn.org)
• scikit-learn and Hugging Face join forces (scikit-learn Blog)
• Models compatible with the scikit-learn library (Hugging Face Hub)
• skops — Python library for secure scikit-learn model sharing (GitHub)
• Accelerating scikit-learn with GPUs: 15x speed-ups via Array API (:probabl. blog)
• scikit-learn 1.9.0 on PyPI
• Update on array API adoption in scikit-learn (Quansight Labs)