NVIDIA ने scikit-learn, UMAP, और HDBSCAN में GPU त्वरक की घोषणा की
जानें कि NVIDIA के नवीनतम cuML अपडेट से scikit-learn, UMAP, और HDBSCAN में GPU त्वरक कैसे आता है—और sklearn के लिए प्रदर्शन 50 गुना तक बढ़ता है—वह भी बिना कोड बदले।
NVIDIA का cuML एक GPU-त्वरित मशीन लर्निंग लाइब्रेरी है जो RAPIDS AI इकोसिस्टम का हिस्सा है। और अब, ओपन बीटा में, cuML 25.02 scikit-learn, UMAP, और HDBSCAN में GPU त्वरक को संभव बनाता है—वह भी आपके Python कोड को बदले बिना। यह उन सभी प्रोफेशनल्स के लिए बेहद दिलचस्प खबर है—Python मशीन लर्निंग इंजीनियर्स, डेटा और रिसर्च साइंटिस्ट्स, डेवलपर्स—जो अपने मॉडलों के प्रदर्शन में बढ़ोतरी देखना चाहते हैं।
अगर आप cuML या GPU त्वरक की अवधारणा से अभी परिचित नहीं हैं, तो चिंता न करें। मैं आपको एक त्वरित टूर पर ले जाऊंगा और इस लेख के अंत तक आप अपने रिग्रेशन, क्लासीफिकेशन, डायमेंशनलिटी रिडक्शन, या क्लस्टरिंग समस्याओं में GPU त्वरक का उपयोग करने में सक्षम होंगे।
NVIDIA, RAPIDS AI, और cuML
आइए जल्दी से सभी हिस्सों को सही जगह पर रख लें।
RAPIDS AI क्या है?
NVIDIA उच्च-प्रदर्शन कंप्यूटिंग, AI, और डेटा साइंस को शक्ति देने वाली अत्याधुनिक तकनीकें विकसित करता है। आपको याद होगा कि Deepseek ने Deepseek-R1 लॉन्च किया था, तब यह चर्चा में था कि क्या Deepseek ने NVIDIA चिप्स का इस्तेमाल किया।
खैर, NVIDIA फिर से खबरों में है—इस बार अपने RAPIDS AI इकोसिस्टम में नवाचारों के लिए। RAPIDS AI, यदि आप परिचित नहीं हैं, तो यह GPU-त्वरित ओपन-सोर्स लाइब्रेरियों का एक सूट है, जिसे डेटा साइंस और मशीन लर्निंग वर्कफ्लोज़ को तेज करने के लिए डिज़ाइन किया गया है। RAPIDS, CUDA (Compute Unified Device Architecture) पर बना है, जो NVIDIA द्वारा विकसित एक पैरेलल कंप्यूटिंग प्लेटफ़ॉर्म और API मॉडल है। RAPIDS की GPU-त्वरित लाइब्रेरियों में शामिल हैं:
cuML, एक मशीन लर्निंग लाइब्रेरी (हम इसी पर अधिक बात करेंगे।)
cuGraph, एक ग्राफ एनालिटिक्स लाइब्रेरी
cuSpatial, एक जियोस्पैशियल एनालिटिक्स लाइब्रेरी
cuML क्या है?
अब cuML के बारे में: cuML पारंपरिक मशीन लर्निंग एल्गोरिद्म्स के अत्यधिक ऑप्टिमाइज़्ड इम्प्लीमेंटेशन प्रदान करता है। क्योंकि NVIDIA के पास बेहतरीन AI चिप्स हैं, ये एल्गोरिद्म्स—जो NVIDIA GPUs पर चलते हैं—काफी तेज़ हो जाते हैं। CPU के विपरीत, GPUs पैरेलल प्रोसेसिंग में माहिर होते हैं—यानी वे एक साथ हजारों गणनाएँ कर सकते हैं—जिससे वे डीप लर्निंग और मशीन लर्निंग जैसे कार्यों के लिए आदर्श बनते हैं।
scikit-learn क्या है?
यदि आप scikit-learn से परिचित नहीं हैं और आप मशीन लर्निंग तथा डेटा साइंस को गंभीरता से लेते हैं, तो आपको हमारा Supervised Learning with scikit-learn कोर्स अवश्य करना चाहिए। मैं ऐसा इसलिए कह रहा हूँ क्योंकि scikit-learn, मशीन लर्निंग के लिए सबसे लोकप्रिय प्रोग्रामिंग भाषा में सारणीबद्ध डेटा के लिए नंबर-वन लाइब्रेरी है। साथ ही, scikit-learn सीखना अपेक्षाकृत आसान है, इसका API सरल है, और यह pandas और NumPy के साथ अच्छी तरह काम करता है। इसमें आश्चर्य नहीं कि RAPIDS AI टीम रणनीतिक और स्वाभाविक रूप से scikit-learn एल्गोरिद्म्स पर फोकस कर रही है।
scikit-learn को cuML क्या देता है
NVIDIA और cuML अब scikit-learn के साथ-साथ UMAP और HDBSCAN के लिए प्रदर्शन गति में भारी बढ़ोतरी का नवाचार पेश कर रहे हैं। RAPIDS AI टीम के अनुसार, इसका मतलब है scikit-learn में 50 गुना तक, UMAP में 60 गुना, और HDBSCAN में 175 गुना तक रफ्तार।
मेरे मोटे हिसाब से, कोई एल्गोरिद्म जो scikit-learn पर चलने में पाँच मिनट लेता है, वह सैद्धांतिक तौर पर घटकर लगभग छह सेकंड रह सकता है। यह बड़ा फर्क है। नीचे बेंचमार्क देखते समय मैं इस पर थोड़ी और बात करूँगा।
शून्य कोड बदलाव
यदि यह सब जटिल सुनाई देता है, तो चिंता न करें। RAPIDS AI, scikit-learn के API कोड में शून्य कोड बदलाव के लिए प्रतिबद्ध है। सच में, आपको बस इस तरह एक्सटेंशन लोड करना है:
%load_ext cuml.accel
$ python -m cuml.accel script.pyसंचालित द्वारा
यह आपके प्रचलित वर्कफ़्लो में कोई बड़ा बदलाव नहीं है—और यही मकसद है। कभी-कभी आपको कर्नेल रीस्टार्ट करके एक्सटेंशन फिर से लोड करना पड़ सकता है।
मेरी नज़र में, यह शून्य-कोड-बदलाव वाला पहलू शुरू से ही काफी रोमांचक दावा है। बात यह है कि आपको अपने पहले से बने scikit-learn स्क्रिप्ट्स में बदलाव नहीं करना होगा—न पहली बार, न बाद में। cuML स्वचालित रूप से NVIDIA GPUs पर संगत कंपोनेंट्स को तेज़ कर देगा, लेकिन यदि आपके कोड में कुछ ऐसा है जो NVIDIA के GPUs के साथ संगत नहीं है, तो आपकी स्क्रिप्ट ‘सामान्य’ CPU निष्पादन पर लौट आएगी। आप, बतौर कोडर, बस परिणाम देखेंगे—आपको एरर हैंडलिंग आदि की चिंता नहीं करनी होगी।
यह सब कहते हुए भी, मैं कुछ ऐसे कोनों की उम्मीद करूँगा जहाँ समायोजन करने पड़ें। कोडिंग में चीजें गलत भी हो सकती हैं, और कुछ भी उतना आसान नहीं निकलता जितना लगता है। रेफरेंस डॉक्स में कुछ बातें हैं जो ‘नो कोड चेंजेज़’ के दावे पर थोड़ी खटास डालती हैं—या कम से कम उसमें थोड़ा घर्षण जोड़ती हैं। आपको लिस्ट्स को NumPy एरेज़ या Pandas DataFrames में बदलना होगा, और स्ट्रिंग लेबल्स समर्थित नहीं हैं—तो उपयोगकर्ताओं को श्रेणीबद्ध लेबल्स को पहले से एन्कोड करना होगा। आप यह सब वैसे भी करते होंगे, पर बात यह है कि सिर्फ एक्सटेंशन लोड करने से इतर भी कुछ चीज़ों की आदत डालनी पड़ सकती है।
काफी तेज़ी का फायदा
यदि आप mtcars डेटासेट पर एक साधारण लीनियर रिग्रेशन चलाकर बुनियादी सांख्यिकी का अभ्यास कर रहे हों, तो रेखा का ढाल और इंटरसेप्ट ज़रा-सा जल्दी निकालने के लिए GPU त्वरक का खास उपयोग नहीं होगा। सेकंड के अंश बचाना, सच कहें तो, एक्सटेंशन लोड करने के लायक भी नहीं। लेकिन यदि आप कोई जटिल एल्गोरिद्म चला रहे हों, तो बचाया गया समय दो प्रमुख कारणों से मायने रखता है।
पहली बात, कई वर्कफ़्लोज़ के लिए यह समय-बचत महत्वपूर्ण होती है। मैंने बताया कि 50 गुना गति-बढ़ोतरी का मतलब पाँच मिनट के ट्रेनिंग समय को घटाकर छह सेकंड करना हो सकता है। यह लगभग पाँच मिनट की बचत है। पर मशीन लर्निंग इंजीनियर के वर्कफ़्लो पर विचार करें—जहाँ मॉडल को सही करने के लिए उसे कई बार चलाना पड़ सकता है। हर रन पर समय की बचत जोड़ें, तो यह किसी डेटा साइंटिस्ट की समग्र उत्पादकता की बात हो जाती है।
दूसरी बात, और इससे जुड़ी हुई, अब वैज्ञानिक या इंजीनियर और भी जटिल मॉडलों की कोशिश कर सकता है। पिछले उदाहरण में, हम एक ऐसे मॉडल के समय की बात कर रहे हैं जो समान सटीकता देता है। लेकिन यदि आपको लगे कि अधिक जटिल मॉडल से सटीकता और बेहतर होगी? कल्पना करें कि आप अलग-अलग पैरामीटर्स पर ग्रिड सर्च करके मॉडल ट्रेन करें। (नीचे मैं अपना एक छोटा-सा उदाहरण दूँगा।) पर्म्यूटेशंस घातीय रूप से बढ़ते हैं—CPU पर गणनात्मक लागत बाधा बन जाती है। लेकिन 50 गुना रफ्तार हो तो यह समस्या नहीं रह जाती।
ये फायदे साथ-साथ चलते हैं। यदि आपने अपना प्रोजेक्ट सही तरह सेट किया, तो आपका मॉडल अधिक सटीक भी हो सकता है और जल्दी भी बनेगा—या, मशीन लर्निंग इंजीनियर के नज़रिये से, आप अधिक परिष्कृत मॉडल आर्किटेक्चर रख सकते हैं बिना प्रशिक्षण समय अनावश्यक रूप से बढ़ाए।
संख्यात्मक रूप से समकक्ष परिणाम
NVIDIA इस पर जोर देता है कि GPUs से प्राप्त परिणाम संख्यात्मक रूप से समकक्ष होंगे। यह अच्छी बात है—क्योंकि इसका मतलब है कि फायदे, मॉडल सटीकता के नुकसान की कीमत पर नहीं आते।
लेकिन इससे मेरे मन में सवाल आया: परिणाम समकक्ष क्यों हैं, एकदम समान क्यों नहीं? संभवतः पैरेलल प्रोसेसिंग के कारण आउटपुट में छोटे-छोटे अंतर होते हैं, या किसी विधि की संख्यात्मक स्थिरता में भिन्नताएँ होती हैं। शायद UMAP के मामले में UMAP प्रोजेक्शन थोड़ा अलग हो। यह मैं इसलिए उठा रहा हूँ ताकि यदि आपको CPU और GPU रन के बीच आउटपुट में सूक्ष्म अंतर दिखें, तो NVIDIA के अनुसार यह सामान्य है और अपेक्षित भी।
यह सब कहते हुए, यदि आप स्वयं को चुनौती दे रहे हैं और कोई ऐसा जटिल मॉडल GPUs पर चला रहे हैं जो CPUs पर व्यावहारिक नहीं है, तो उसके आउटपुट की किसी CPU-समकक्ष से तुलना करना कठिन हो जाएगा।
cuML समर्थित एल्गोरिद्म और लाइब्रेरीज़
मैंने पहले कहा कि इस cuML 25.02 रिलीज़ में scikit-learn, UMAP, और HDBSCAN का सपोर्ट है। लेकिन यदि आप scikit-learn से वाकिफ हैं, तो आप जानते हैं कि इसमें बहुत-से अलग-अलग एल्गोरिद्म हैं। फिलहाल, RAPIDS AI कुछ लाइब्रेरीज़ को सपोर्ट करता है—सभी को नहीं। टीम के अनुसार मुख्य रूप से ये हाइलाइट्स हैं:
इस सूची में, मैं k-Nearest Neighbors की रफ्तार बढ़ने के लिए सबसे अधिक उत्साहित हूँ—यह जाना-माना है कि यह गणनात्मक रूप से भारी होता है क्योंकि सभी डेटा पॉइंट्स के बीच दूरी निकालनी होती है।
नीचे दी गई तालिका उन एस्टिमेटर्स को दिखाती है जो अधिकांशतः या पूरी तरह cuML के साथ चलते हैं।
एल्गोरिद्म
लाइब्रेरी / फ़ंक्शन नाम
श्रेणी
UMAP
umap.UMAP
डायमेंशनलिटी रिडक्शन
PCA (प्रिंसिपल कंपोनेंट एनालिसिस)
sklearn.decomposition.PCA
डायमेंशनलिटी रिडक्शन
Truncated SVD
sklearn.decomposition.TruncatedSVD
डायमेंशनलिटी रिडक्शन
t-SNE
sklearn.manifold.TSNE
डायमेंशनलिटी रिडक्शन
HDBSCAN
hdbscan.HDBSCAN
क्लस्टरिंग
K-Means
sklearn.cluster.KMeans
क्लस्टरिंग
DBSCAN
sklearn.cluster.DBSCAN
क्लस्टरिंग
रैंडम फॉरेस्ट क्लासीफायर
sklearn.ensemble.RandomForestClassifier
क्लासीफिकेशन
लॉजिस्टिक रिग्रेशन
sklearn.linear_model.LogisticRegression
क्लासीफिकेशन
k-Nearest Neighbors क्लासीफायर
sklearn.neighbors.KNeighborsClassifier
क्लासीफिकेशन
रैंडम फॉरेस्ट रिग्रेसर
sklearn.ensemble.RandomForestRegressor
रिग्रेशन
लीनियर रिग्रेशन
sklearn.linear_model.LinearRegression
रिग्रेशन
एलास्टिक नेट
sklearn.linear_model.ElasticNet
रिग्रेशन
रिज रिग्रेशन
sklearn.linear_model.Ridge
रिग्रेशन
लासो रिग्रेशन
sklearn.linear_model.Lasso
रिग्रेशन
कर्नेल रिज रिग्रेशन
sklearn.kernel_ridge.KernelRidge
रिग्रेशन
k-Nearest Neighbors रिग्रेसर
sklearn.neighbors.KNeighborsRegressor
रिग्रेशन
नज़दीकी पड़ोसी खोज
sklearn.neighbors.NearestNeighbors
नज़दीकी पड़ोसी खोज
समर्थित विधियों की पूरी सूची RAPIDS AI डॉक्स में उपलब्ध है। हमें उम्मीद है कि जल्द और एल्गोरिद्म जोड़े जाएंगे। (आप टीम को प्राथमिकता तय करने में मदद के लिए फीडबैक भी दे सकते हैं।) कुछ जिनकी कमी मैंने नोटिस की: सपोर्ट वेक्टर रिग्रेसर (sklearn.svm.SVR), Theil-Sen Regressor (sklearn.linear_model.TheilSenRegressor), मीन-शिफ्ट क्लस्टरिंग (sklearn.cluster.MeanShift), और मल्टीडायमेंशनल स्केलिंग (sklearn.manifold.MDS)।
cuML अंदर से कैसे काम कर रहा है
आप सोच रहे होंगे कि यह सब कैसे काम करता है। ऊँचे स्तर पर समझें तो, आधुनिक लाइब्रेरियाँ इस तरह डिज़ाइन की जा रही हैं कि वे उपलब्ध सर्वश्रेष्ठ हार्डवेयर—चाहे CPU हो या GPU—को स्वतः पहचानकर उपयोग करें। अब हम देख रहे हैं कि जब scikit-learn में कोई फ़ंक्शन कॉल होता है (जब cuml.accel सक्षम है), तो सॉफ़्टवेयर यह चेक करता है कि क्या संगत GPU उपलब्ध है—यदि हाँ, तो निष्पादन को GPU-त्वरित संस्करण पर रीडायरेक्ट कर देता है।
RAPIDS AI इस तंत्र को एक कम्पैटिबिलिटी लेयर बताता है जो cuml.accel को sklearn जैसा बर्ताव करने देता है। इस स्थिति में, cuML की कम्पैटिबिलिटी लेयर scikit-learn कोड को NVIDIA GPUs पर बिना बदलाव के चलने देती है। यह ड्रॉप-इन रिप्लेसमेंट की तरह बना है—एक प्रॉक्सी की तरह काम करता है—जो scikit-learn के फ़ंक्शन कॉल्स को इंटरसेप्ट करके उन्हें cuML पर रीडायरेक्ट कर देता है।
NVIDIA की RAPIDS AI टीम ने एक उपयोगी ग्राफिक साझा किया है, जिसे मैं यहाँ भी साझा कर रहा हूँ:
cuML पहले से ही Google Colab में प्री-इंस्टॉल है, पर यदि आप Jupyter नोटबुक का उपयोग कर रहे हैं, तो scikit-learn इम्पोर्ट करने से पहले इसे इस कमांड से सक्रिय करें:
अब हमारा sklearn वाला Python कोड परिचित लगेगा—और यही मकसद है। यहाँ OLS रिग्रेशन का उदाहरण है।
# Import necessary librariesfrom sklearn.datasets import make_regression
from sklearn.model_selection import train_test_split
from sklearn.linear_model import LinearRegression
# Generate synthetic regression data
X, y = make_regression(n_samples=500000, n_features=50, noise=0.1, random_state=0)# Split into training and test sets
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=0)# Create and train an OLS regression model
ols = LinearRegression()
ols.fit(X_train, y_train)संचालित द्वारा
यदि मैं देखना चाहूँ कि कौन-से हिस्से CPU की जगह GPU पर चले, तो मैं logger का उपयोग कर सकता/सकती हूँ।
%load_ext cuml.accel
from cuml.common import logger;
logger.set_level(logger.level_enum.debug)संचालित द्वारा
cuML: Installed accelerator for sklearn.
cuML: Successfully initialized accelerator.
cuML: Performing fit in GPUसंचालित द्वारा
आप समझ गए। अब, एक और अधिक विश्वसनीय उदाहरण आज़माते हैं। वैसे भी लीनियर रिग्रेशन खास पैरेललाइज़ेबल नहीं है क्योंकि नॉर्मल इक्वेशन या QR डीकंपोज़िशन में कुछ सीक्वेंशियल ऑपरेशंस होते हैं।
OLS रिग्रेशन का एक अधिक जटिल विस्तार है रिज रिग्रेशन। जब आप Python में रिज रिग्रेशन करते हैं, तो Ridge() डिफ़ॉल्ट हाइपरपैरामीटर्स लगाता है—जो ज़रूरी नहीं कि सर्वोत्तम हों। alpha मान यह नियंत्रित करता है कि रेग्युलराइज़ेशन कितना लागू हो। बहुत छोटा होगा तो मॉडल ओवरफिट करेगा; बहुत बड़ा होगा तो अंडरफिट।
%load_ext cuml.accel
import sklearn
from sklearn.linear_model import Ridge
from sklearn.datasets import make_regression
from sklearn.model_selection import train_test_split
from sklearn.metrics import mean_squared_error
# Generate synthetic data
X, y = make_regression(n_samples=100000, n_features=50, noise=0.1, random_state=0)# Split into training and test sets
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=0)# Train a Ridge Regression model with default settings
ridge_default = Ridge()
ridge_default.fit(X_train, y_train)# Make predictions and evaluate
y_pred_default = ridge_default.predict(X_test)
mse_default = mean_squared_error(y_test, y_pred_default)संचालित द्वारा
ऊपर का कोड एक ही मॉडल को एक ही alpha मान और सॉल्वर से ट्रेन करता है। (मेरा मानना है कि यह डिफ़ॉल्ट रूप से 'auto' होता है।) तो यह काम करता है, लेकिन न तो रेग्युलराइज़ेशन स्ट्रेंथ को ऑप्टिमाइज़ करता है और न सॉल्वर चयन को।
डिफ़ॉल्ट पर निर्भर रहने के बजाय, हम कुछ और कर सकते हैं। हम एक ग्रिड सर्च बना सकते हैं जो कई हाइपरपैरामीटर कॉम्बिनेशंस की जाँच करे और श्रेष्ठ को चुने।
from sklearn.model_selection import GridSearchCV
# Define Ridge Regression model
ridge = Ridge()# Define a grid of hyperparameters to search
param_grid ={'alpha':[0.01,0.1,1.0,10.0,100.0],# Different regularization strengths'solver':['auto','svd','cholesky','lsqr','saga']# Test multiple solvers}# Perform Grid Search with cross-validation
grid_search = GridSearchCV(ridge, param_grid, scoring='neg_mean_squared_error', cv=2, n_jobs=-1)
grid_search.fit(X_train, y_train)# Get the best model from the search
best_ridge = grid_search.best_estimator_
# Make predictions and evaluate
y_pred_best = best_ridge.predict(X_test)
mse_best = mean_squared_error(y_test, y_pred_best)संचालित द्वारा
हमारा ग्रिड सर्च यहाँ सभी संभावित हाइपरपैरामीटर कॉम्बिनेशंस को टेस्ट करता है। यदि हम alpha के 5 मान ([0.01, 0.1, 1.0, 10.0, 100.0]), 5 सॉल्वर विकल्प (['auto', 'svd', 'cholesky', 'lsqr', 'saga']) लें, और 2-फोल्ड क्रॉस-वैलिडेशन करें, तो कुल ट्रेनिंग्स 5x5x2 = 50 होंगी। यानी एक मॉडल की जगह हम 50 मॉडल ट्रेन करते हैं। यह कहीं अधिक जटिल है—इसीलिए GPUs का उपयोग शानदार रहेगा—क्योंकि वे बहुत तेज़ हैं। चूँकि sklearn में (50 गुना तक) स्पीड बूस्ट है, इन 50 मॉडलों को ट्रेन करने में उतना ही समय लग सकता है जितना एक मॉडल में। (मैंने यही दिखाने के लिए ये संख्या चुनी है। मैं मानता हूँ कि सभी मॉडलों में समान तेज़ी नहीं होगी।)
cuML sklearn बेंचमार्क्स
NVIDIA ने Intel CPUs पर चल रहे scikit-learn एल्गोरिद्म्स बनाम अपने NVIDIA GPUs पर चल रहे एल्गोरिद्म्स की तुलना की। उन्होंने क्लासीफिकेशन और रिग्रेशन समेत अलग-अलग मशीन लर्निंग वर्कलोड्स को देखा।
निष्कर्ष यह है कि साधारण मॉडल—जैसे रैंडम फॉरेस्ट—CPU पर मिनटों में ट्रेन होते थे, जो GPUs पर सेकंडों में आ गए; और जटिल मॉडल—जैसे क्लस्टरिंग—घंटों से घटकर मिनटों में। हर मामले में वर्कफ़्लो तेज़ रहे; पर उच्च-आयामी डेटा वाले भारी-भरकम मॉडलों में फायदे और स्पष्ट थे। यह वह जगह है जहाँ GPUs चमकते हैं—क्योंकि वे पैरेलल प्रोसेसिंग का उपयोग करते हैं—और यह उन मॉडलों में बड़ा फर्क डालता है जिन्हें व्यापक मैट्रिक्स ऑपरेशंस, दूरी-गणनाएँ, या इटरेटिव ऑप्टिमाइज़ेशन चाहिए।
GPU पर cuML scikit-learn बनाम CPU पर scikit-learn। स्रोत: NVIDIA
मैंने ऊपर कोडिंग उदाहरण में लीनियर रिग्रेशन से हटकर और कुछ दिखाना चाहा—ताकि शक्ति साफ़ दिखे। लेकिन यहाँ मैं लीनियर रिग्रेशन में 52 गुना तेज़ी देख रहा हूँ। मैं मानता हूँ, यह मुझे चौंकाता है—क्योंकि यह बड़ा मल्टिप्लायर लगता है। यह याद दिलाता है कि NVIDIA और भी उन्नत काम कर रहा है—जैसे अलग-अलग स्टेप्स को इस तरह इंटरलीव करना कि GPU खाली न बैठे।
कुछ सर्वोत्तम प्रक्रियाएँ
cuML संस्करण 25.02 की बदौलत अब GPUs के साथ scikit-learn एल्गोरिद्म चलाना कठिन नहीं रहा। जैसा मैंने दिखाया, आपको बस एक्सटेंशन लोड करना है। फिर भी, यदि आप वर्कफ़्लो में और गहराई तक जाते हैं और GPU त्वरक का अधिकतम लाभ लेना चाहते हैं, तो कुछ विशेष बातों पर ध्यान देना होगा।
NVIDIA सिफारिश करता है कि आप अपने पाइपलाइन में CPU और GPU के बीच डेटा ट्रांसफर्स को न्यूनतम रखें। यानी, प्री-प्रोसेसिंग, ट्रेनिंग, और इन्फरेंस स्टेप्स GPUs पर ही करें—और फिर परिणामों को होस्ट मेमोरी में भेजें। स्टेप्स को इस तरह मत मिलाएँ कि प्री-प्रोसेसिंग CPU पर और इन्फरेंस GPU पर हो।
साथ ही, दक्षता अधिकतम करने के लिए आप CUDA-X पर विचार करें—जो NVIDIA द्वारा विकसित GPU-त्वरित लाइब्रेरियों का संग्रह है। मसलन, रैंडम फॉरेस्ट्स के लिए आप scikit-learn की बजाय cuML की फॉरेस्ट इन्फरेंस लाइब्रेरी का उपयोग कर सकते हैं।
ज्ञात सीमाएँ
RAPIDS AI टीम जो कर रही है वह जटिल है—तो कुछ मुद्दे होना तय है। सौभाग्य से, ज्ञात सीमाओं का प्रलेखन अच्छी तरह से रखा गया है। मैं यहाँ सभी—या कुछ—सीमाओं की सूची नहीं देना चाहता क्योंकि कई मुद्दे विशिष्ट एल्गोरिद्म की बारीकियों में जाते हैं। साथ ही, अपडेट्स और पैच तेज़ी से आ रहे हैं। इसकी बजाय, मैं विचार करने के लिए अधिक सामान्य श्रेणियाँ बताऊँगा।
1. सामान्य सीमाएँ
कुछ प्रतिबंध ऐसे हैं जो पूरे cuML पर लागू होते हैं—सिर्फ विशिष्ट एल्गोरिद्म पर नहीं। उदाहरण के तौर पर, डेटा इनपुट फ़ॉर्मैट्स पर प्रतिबंध (कुछ समस्याएँ Python लिस्ट्स के साथ), वर्ज़न कम्पैटिबिलिटी, और मेमोरी हैंडलिंग।
2. एल्गोरिद्म-विशिष्ट सीमाएँ
कुछ अनूठी बाधाएँ अलग-अलग मशीन लर्निंग एल्गोरिद्म पर लागू होती हैं। ये भिन्नताएँ इस बात को प्रभावित कर सकती हैं कि मॉडल कैसे ट्रेन होते हैं, पैरामीटर्स कैसे बर्ताव करते हैं, या परिणाम कैसे निकाले जाते हैं। उदाहरण के लिए, cuML में रैंडम फॉरेस्ट एल्गोरिद्म स्प्लिट थ्रेशहोल्ड चुनने के लिए अलग विधि का उपयोग करता है—जिससे ट्री संरचनाएँ थोड़ी अलग हो सकती हैं।
3. समर्थित और असमर्थित फीचर्स
पैरामीटर्स, सॉल्वर्स, और इनिशियलाइज़ेशन विधियों में कुछ भिन्नताएँ हैं। उदाहरण के लिए, PCA "full" और "auto" SVD सॉल्वर्स को सपोर्ट करता है, लेकिन "randomized" को नहीं। और KNN Minkowski मेट्रिक्स को सपोर्ट करता है, Mahalanobis को नहीं।
4. पुनरुत्पादनशीलता और संख्यात्मक भिन्नताएँ
कभी-कभी पैरेललिज़्म या सॉल्वर भिन्नताओं के कारण परिणामों में हल्का फर्क हो सकता है—मैंने यह पहले भी बताया। मसलन, UMAP एम्बेडिंग्स समान नहीं होंगी, पर ट्रस्टवर्थिनेस स्कोर उच्च होना चाहिए। अन्य मामलों में, PCA कंपोनेंट के संकेत उलट सकते हैं—जिन्हें नॉर्मलाइज़ेशन की ज़रूरत होगी। फिर भी, ये विशिष्ट बातें हैं—किसी खास एल्गोरिद्म को चलाते समय ताज़ा डॉक्स देखें।
निष्कर्ष
सबसे आम Python मशीन लर्निंग लाइब्रेरीज़ के सुप्रसिद्ध एल्गोरिद्म्स के लिए अत्यंत आसान GPU त्वरक की संभावना मुझे उत्साहित करती है। इससे मॉडल सटीकता में बड़ा फर्क पड़ेगा—और इसे लागू करना सुविधाजनक तथा कठिन नहीं है।
मैं एक डेटा साइंस संपादक हूँ और वैज्ञानिक पत्रिकाओं में प्रकाशित शोध लेखों में योगदान दे चुका/चुकी हूँ। मुझे विशेष रूप से रैखिक बीजगणित, सांख्यिकी, R, और इसी तरह के विषयों में रुचि है।
FAQs
scikit-learn के लिए NVIDIA cuML की ज़ीरो-कोड-चेंज क्षमता क्या है?⌄
NVIDIA cuML की ज़ीरो-कोड-चेंज क्षमता scikit-learn उपयोगकर्ताओं को बिना अपना मौजूदा कोड बदले NVIDIA GPUs पर अपने मशीन लर्निंग वर्कफ़्लो तेज करने देती है। यह समर्थित एल्गोरिद्म्स को अपने-आप GPUs पर चलाती है और असमर्थित ऑपरेशंस के लिए CPUs पर लौट आती है।
cuML की ज़ीरो-कोड-चेंज सुविधा से कौन-से scikit-learn एल्गोरिद्म समर्थित हैं?⌄
बीटा रिलीज़, scikit-learn के लोकप्रिय एल्गोरिद्म्स—जैसे रैंडम फॉरेस्ट, k-Nearest Neighbors, प्रिंसिपल कंपोनेंट एनालिसिस (PCA), और k-means क्लस्टरिंग—को तेज करती है। उपयोगकर्ता फीडबैक के आधार पर अतिरिक्त एल्गोरिद्म जोड़े जाएँगे।
NVIDIA GPUs पर cuML से मुझे कितनी स्पीड में सुधार की उम्मीद करनी चाहिए?⌄
बेंचमार्क्स में महत्वपूर्ण स्पीडअप दिखते हैं—NVIDIA GPUs पर चलते समय scikit-learn मॉडलों के लिए 50 गुना तक, UMAP के लिए 60 गुना, और HDBSCAN के लिए 175 गुना—CPUs की तुलना में।
मैं अपने scikit-learn स्क्रिप्ट्स में cuML का GPU त्वरक कैसे सक्षम करूँ?⌄
cuML का त्वरक सक्षम करने के लिए, Jupyter Notebook में %load_ext cuml.accel का उपयोग करें या स्क्रिप्ट्स को python -m cuml.accel unchanged_script.py से चलाएँ। यह cuML की कम्पैटिबिलिटी लेयर को सक्रिय करता है, जो जहाँ संभव हो, गणनाओं को GPUs पर रीडायरेक्ट करता है।
क्या cuML, pandas और NumPy जैसी मौजूदा Python लाइब्रेरियों के साथ सहजता से काम करता है?⌄
हाँ, cuML को pandas और NumPy जैसी लोकप्रिय Python लाइब्रेरियों के साथ काम करने के लिए डिज़ाइन किया गया है। cuDF-pandas और cuML को साथ में उपयोग करने से CPUs और GPUs के बीच डेटा ट्रांसफर्स को कम करके प्रदर्शन बेहतर किया जा सकता है।
NVIDIA का cuML एक GPU-त्वरित मशीन लर्निंग लाइब्रेरी है जो RAPIDS AI इकोसिस्टम का हिस्सा है। और अब, ओपन बीटा में, cuML 25.02 scikit-learn, UMAP, और HDBSCAN में GPU त्वरक को संभव बनाता है—वह भी आपके Python कोड को बदले बिना। यह उन सभी प्रोफेशनल्स के लिए बेहद दिलचस्प खबर है—Python मशीन लर्निंग इंजीनियर्स, डेटा और रिसर्च साइंटिस्ट्स, डेवलपर्स—जो अपने मॉडलों के प्रदर्शन में बढ़ोतरी देखना चाहते हैं।
अगर आप cuML या GPU त्वरक की अवधारणा से अभी परिचित नहीं हैं, तो चिंता न करें। मैं आपको एक त्वरित टूर पर ले जाऊंगा और इस लेख के अंत तक आप अपने रिग्रेशन, क्लासीफिकेशन, डायमेंशनलिटी रिडक्शन, या क्लस्टरिंग समस्याओं में GPU त्वरक का उपयोग करने में सक्षम होंगे।
NVIDIA, RAPIDS AI, और cuML
आइए जल्दी से सभी हिस्सों को सही जगह पर रख लें।
RAPIDS AI क्या है?
NVIDIA उच्च-प्रदर्शन कंप्यूटिंग, AI, और डेटा साइंस को शक्ति देने वाली अत्याधुनिक तकनीकें विकसित करता है। आपको याद होगा कि Deepseek ने Deepseek-R1 लॉन्च किया था, तब यह चर्चा में था कि क्या Deepseek ने NVIDIA चिप्स का इस्तेमाल किया।
खैर, NVIDIA फिर से खबरों में है—इस बार अपने RAPIDS AI इकोसिस्टम में नवाचारों के लिए। RAPIDS AI, यदि आप परिचित नहीं हैं, तो यह GPU-त्वरित ओपन-सोर्स लाइब्रेरियों का एक सूट है, जिसे डेटा साइंस और मशीन लर्निंग वर्कफ्लोज़ को तेज करने के लिए डिज़ाइन किया गया है। RAPIDS, CUDA (Compute Unified Device Architecture) पर बना है, जो NVIDIA द्वारा विकसित एक पैरेलल कंप्यूटिंग प्लेटफ़ॉर्म और API मॉडल है। RAPIDS की GPU-त्वरित लाइब्रेरियों में शामिल हैं:
cuML क्या है?
अब cuML के बारे में: cuML पारंपरिक मशीन लर्निंग एल्गोरिद्म्स के अत्यधिक ऑप्टिमाइज़्ड इम्प्लीमेंटेशन प्रदान करता है। क्योंकि NVIDIA के पास बेहतरीन AI चिप्स हैं, ये एल्गोरिद्म्स—जो NVIDIA GPUs पर चलते हैं—काफी तेज़ हो जाते हैं। CPU के विपरीत, GPUs पैरेलल प्रोसेसिंग में माहिर होते हैं—यानी वे एक साथ हजारों गणनाएँ कर सकते हैं—जिससे वे डीप लर्निंग और मशीन लर्निंग जैसे कार्यों के लिए आदर्श बनते हैं।
scikit-learn क्या है?
यदि आप scikit-learn से परिचित नहीं हैं और आप मशीन लर्निंग तथा डेटा साइंस को गंभीरता से लेते हैं, तो आपको हमारा Supervised Learning with scikit-learn कोर्स अवश्य करना चाहिए। मैं ऐसा इसलिए कह रहा हूँ क्योंकि scikit-learn, मशीन लर्निंग के लिए सबसे लोकप्रिय प्रोग्रामिंग भाषा में सारणीबद्ध डेटा के लिए नंबर-वन लाइब्रेरी है। साथ ही, scikit-learn सीखना अपेक्षाकृत आसान है, इसका API सरल है, और यह pandas और NumPy के साथ अच्छी तरह काम करता है। इसमें आश्चर्य नहीं कि RAPIDS AI टीम रणनीतिक और स्वाभाविक रूप से scikit-learn एल्गोरिद्म्स पर फोकस कर रही है।
scikit-learn को cuML क्या देता है
NVIDIA और cuML अब scikit-learn के साथ-साथ UMAP और HDBSCAN के लिए प्रदर्शन गति में भारी बढ़ोतरी का नवाचार पेश कर रहे हैं। RAPIDS AI टीम के अनुसार, इसका मतलब है scikit-learn में 50 गुना तक, UMAP में 60 गुना, और HDBSCAN में 175 गुना तक रफ्तार।
मेरे मोटे हिसाब से, कोई एल्गोरिद्म जो scikit-learn पर चलने में पाँच मिनट लेता है, वह सैद्धांतिक तौर पर घटकर लगभग छह सेकंड रह सकता है। यह बड़ा फर्क है। नीचे बेंचमार्क देखते समय मैं इस पर थोड़ी और बात करूँगा।
शून्य कोड बदलाव
यदि यह सब जटिल सुनाई देता है, तो चिंता न करें। RAPIDS AI, scikit-learn के API कोड में शून्य कोड बदलाव के लिए प्रतिबद्ध है। सच में, आपको बस इस तरह एक्सटेंशन लोड करना है:
यह आपके प्रचलित वर्कफ़्लो में कोई बड़ा बदलाव नहीं है—और यही मकसद है। कभी-कभी आपको कर्नेल रीस्टार्ट करके एक्सटेंशन फिर से लोड करना पड़ सकता है।
मेरी नज़र में, यह शून्य-कोड-बदलाव वाला पहलू शुरू से ही काफी रोमांचक दावा है। बात यह है कि आपको अपने पहले से बने scikit-learn स्क्रिप्ट्स में बदलाव नहीं करना होगा—न पहली बार, न बाद में। cuML स्वचालित रूप से NVIDIA GPUs पर संगत कंपोनेंट्स को तेज़ कर देगा, लेकिन यदि आपके कोड में कुछ ऐसा है जो NVIDIA के GPUs के साथ संगत नहीं है, तो आपकी स्क्रिप्ट ‘सामान्य’ CPU निष्पादन पर लौट आएगी। आप, बतौर कोडर, बस परिणाम देखेंगे—आपको एरर हैंडलिंग आदि की चिंता नहीं करनी होगी।
यह सब कहते हुए भी, मैं कुछ ऐसे कोनों की उम्मीद करूँगा जहाँ समायोजन करने पड़ें। कोडिंग में चीजें गलत भी हो सकती हैं, और कुछ भी उतना आसान नहीं निकलता जितना लगता है। रेफरेंस डॉक्स में कुछ बातें हैं जो ‘नो कोड चेंजेज़’ के दावे पर थोड़ी खटास डालती हैं—या कम से कम उसमें थोड़ा घर्षण जोड़ती हैं। आपको लिस्ट्स को NumPy एरेज़ या Pandas DataFrames में बदलना होगा, और स्ट्रिंग लेबल्स समर्थित नहीं हैं—तो उपयोगकर्ताओं को श्रेणीबद्ध लेबल्स को पहले से एन्कोड करना होगा। आप यह सब वैसे भी करते होंगे, पर बात यह है कि सिर्फ एक्सटेंशन लोड करने से इतर भी कुछ चीज़ों की आदत डालनी पड़ सकती है।
काफी तेज़ी का फायदा
यदि आप mtcars डेटासेट पर एक साधारण लीनियर रिग्रेशन चलाकर बुनियादी सांख्यिकी का अभ्यास कर रहे हों, तो रेखा का ढाल और इंटरसेप्ट ज़रा-सा जल्दी निकालने के लिए GPU त्वरक का खास उपयोग नहीं होगा। सेकंड के अंश बचाना, सच कहें तो, एक्सटेंशन लोड करने के लायक भी नहीं। लेकिन यदि आप कोई जटिल एल्गोरिद्म चला रहे हों, तो बचाया गया समय दो प्रमुख कारणों से मायने रखता है।
पहली बात, कई वर्कफ़्लोज़ के लिए यह समय-बचत महत्वपूर्ण होती है। मैंने बताया कि 50 गुना गति-बढ़ोतरी का मतलब पाँच मिनट के ट्रेनिंग समय को घटाकर छह सेकंड करना हो सकता है। यह लगभग पाँच मिनट की बचत है। पर मशीन लर्निंग इंजीनियर के वर्कफ़्लो पर विचार करें—जहाँ मॉडल को सही करने के लिए उसे कई बार चलाना पड़ सकता है। हर रन पर समय की बचत जोड़ें, तो यह किसी डेटा साइंटिस्ट की समग्र उत्पादकता की बात हो जाती है।
दूसरी बात, और इससे जुड़ी हुई, अब वैज्ञानिक या इंजीनियर और भी जटिल मॉडलों की कोशिश कर सकता है। पिछले उदाहरण में, हम एक ऐसे मॉडल के समय की बात कर रहे हैं जो समान सटीकता देता है। लेकिन यदि आपको लगे कि अधिक जटिल मॉडल से सटीकता और बेहतर होगी? कल्पना करें कि आप अलग-अलग पैरामीटर्स पर ग्रिड सर्च करके मॉडल ट्रेन करें। (नीचे मैं अपना एक छोटा-सा उदाहरण दूँगा।) पर्म्यूटेशंस घातीय रूप से बढ़ते हैं—CPU पर गणनात्मक लागत बाधा बन जाती है। लेकिन 50 गुना रफ्तार हो तो यह समस्या नहीं रह जाती।
ये फायदे साथ-साथ चलते हैं। यदि आपने अपना प्रोजेक्ट सही तरह सेट किया, तो आपका मॉडल अधिक सटीक भी हो सकता है और जल्दी भी बनेगा—या, मशीन लर्निंग इंजीनियर के नज़रिये से, आप अधिक परिष्कृत मॉडल आर्किटेक्चर रख सकते हैं बिना प्रशिक्षण समय अनावश्यक रूप से बढ़ाए।
संख्यात्मक रूप से समकक्ष परिणाम
NVIDIA इस पर जोर देता है कि GPUs से प्राप्त परिणाम संख्यात्मक रूप से समकक्ष होंगे। यह अच्छी बात है—क्योंकि इसका मतलब है कि फायदे, मॉडल सटीकता के नुकसान की कीमत पर नहीं आते।
लेकिन इससे मेरे मन में सवाल आया: परिणाम समकक्ष क्यों हैं, एकदम समान क्यों नहीं? संभवतः पैरेलल प्रोसेसिंग के कारण आउटपुट में छोटे-छोटे अंतर होते हैं, या किसी विधि की संख्यात्मक स्थिरता में भिन्नताएँ होती हैं। शायद UMAP के मामले में UMAP प्रोजेक्शन थोड़ा अलग हो। यह मैं इसलिए उठा रहा हूँ ताकि यदि आपको CPU और GPU रन के बीच आउटपुट में सूक्ष्म अंतर दिखें, तो NVIDIA के अनुसार यह सामान्य है और अपेक्षित भी।
यह सब कहते हुए, यदि आप स्वयं को चुनौती दे रहे हैं और कोई ऐसा जटिल मॉडल GPUs पर चला रहे हैं जो CPUs पर व्यावहारिक नहीं है, तो उसके आउटपुट की किसी CPU-समकक्ष से तुलना करना कठिन हो जाएगा।
cuML समर्थित एल्गोरिद्म और लाइब्रेरीज़
मैंने पहले कहा कि इस cuML 25.02 रिलीज़ में scikit-learn, UMAP, और HDBSCAN का सपोर्ट है। लेकिन यदि आप scikit-learn से वाकिफ हैं, तो आप जानते हैं कि इसमें बहुत-से अलग-अलग एल्गोरिद्म हैं। फिलहाल, RAPIDS AI कुछ लाइब्रेरीज़ को सपोर्ट करता है—सभी को नहीं। टीम के अनुसार मुख्य रूप से ये हाइलाइट्स हैं:
इस सूची में, मैं k-Nearest Neighbors की रफ्तार बढ़ने के लिए सबसे अधिक उत्साहित हूँ—यह जाना-माना है कि यह गणनात्मक रूप से भारी होता है क्योंकि सभी डेटा पॉइंट्स के बीच दूरी निकालनी होती है।
नीचे दी गई तालिका उन एस्टिमेटर्स को दिखाती है जो अधिकांशतः या पूरी तरह cuML के साथ चलते हैं।
umap.UMAPsklearn.decomposition.PCAsklearn.decomposition.TruncatedSVDsklearn.manifold.TSNEhdbscan.HDBSCANsklearn.cluster.KMeanssklearn.cluster.DBSCANsklearn.ensemble.RandomForestClassifiersklearn.linear_model.LogisticRegressionsklearn.neighbors.KNeighborsClassifiersklearn.ensemble.RandomForestRegressorsklearn.linear_model.LinearRegressionsklearn.linear_model.ElasticNetsklearn.linear_model.Ridgesklearn.linear_model.Lassosklearn.kernel_ridge.KernelRidgesklearn.neighbors.KNeighborsRegressorsklearn.neighbors.NearestNeighborsसमर्थित विधियों की पूरी सूची RAPIDS AI डॉक्स में उपलब्ध है। हमें उम्मीद है कि जल्द और एल्गोरिद्म जोड़े जाएंगे। (आप टीम को प्राथमिकता तय करने में मदद के लिए फीडबैक भी दे सकते हैं।) कुछ जिनकी कमी मैंने नोटिस की: सपोर्ट वेक्टर रिग्रेसर (
sklearn.svm.SVR), Theil-Sen Regressor (sklearn.linear_model.TheilSenRegressor), मीन-शिफ्ट क्लस्टरिंग (sklearn.cluster.MeanShift), और मल्टीडायमेंशनल स्केलिंग (sklearn.manifold.MDS)।cuML अंदर से कैसे काम कर रहा है
आप सोच रहे होंगे कि यह सब कैसे काम करता है। ऊँचे स्तर पर समझें तो, आधुनिक लाइब्रेरियाँ इस तरह डिज़ाइन की जा रही हैं कि वे उपलब्ध सर्वश्रेष्ठ हार्डवेयर—चाहे CPU हो या GPU—को स्वतः पहचानकर उपयोग करें। अब हम देख रहे हैं कि जब scikit-learn में कोई फ़ंक्शन कॉल होता है (जब
cuml.accelसक्षम है), तो सॉफ़्टवेयर यह चेक करता है कि क्या संगत GPU उपलब्ध है—यदि हाँ, तो निष्पादन को GPU-त्वरित संस्करण पर रीडायरेक्ट कर देता है।RAPIDS AI इस तंत्र को एक कम्पैटिबिलिटी लेयर बताता है जो
cuml.accelको sklearn जैसा बर्ताव करने देता है। इस स्थिति में, cuML की कम्पैटिबिलिटी लेयर scikit-learn कोड को NVIDIA GPUs पर बिना बदलाव के चलने देती है। यह ड्रॉप-इन रिप्लेसमेंट की तरह बना है—एक प्रॉक्सी की तरह काम करता है—जो scikit-learn के फ़ंक्शन कॉल्स को इंटरसेप्ट करके उन्हें cuML पर रीडायरेक्ट कर देता है।NVIDIA की RAPIDS AI टीम ने एक उपयोगी ग्राफिक साझा किया है, जिसे मैं यहाँ भी साझा कर रहा हूँ:
cuML scikit-learn वर्कफ़्लो डायग्राम। स्रोत: NVIDIA
GPU त्वरक के लिए cuML कैसे उपयोग करें
cuML पहले से ही Google Colab में प्री-इंस्टॉल है, पर यदि आप Jupyter नोटबुक का उपयोग कर रहे हैं, तो scikit-learn इम्पोर्ट करने से पहले इसे इस कमांड से सक्रिय करें:
अब हमारा sklearn वाला Python कोड परिचित लगेगा—और यही मकसद है। यहाँ OLS रिग्रेशन का उदाहरण है।
यदि मैं देखना चाहूँ कि कौन-से हिस्से CPU की जगह GPU पर चले, तो मैं
loggerका उपयोग कर सकता/सकती हूँ।आप समझ गए। अब, एक और अधिक विश्वसनीय उदाहरण आज़माते हैं। वैसे भी लीनियर रिग्रेशन खास पैरेललाइज़ेबल नहीं है क्योंकि नॉर्मल इक्वेशन या QR डीकंपोज़िशन में कुछ सीक्वेंशियल ऑपरेशंस होते हैं।
OLS रिग्रेशन का एक अधिक जटिल विस्तार है रिज रिग्रेशन। जब आप Python में रिज रिग्रेशन करते हैं, तो
Ridge()डिफ़ॉल्ट हाइपरपैरामीटर्स लगाता है—जो ज़रूरी नहीं कि सर्वोत्तम हों।alphaमान यह नियंत्रित करता है कि रेग्युलराइज़ेशन कितना लागू हो। बहुत छोटा होगा तो मॉडल ओवरफिट करेगा; बहुत बड़ा होगा तो अंडरफिट।ऊपर का कोड एक ही मॉडल को एक ही alpha मान और सॉल्वर से ट्रेन करता है। (मेरा मानना है कि यह डिफ़ॉल्ट रूप से
'auto'होता है।) तो यह काम करता है, लेकिन न तो रेग्युलराइज़ेशन स्ट्रेंथ को ऑप्टिमाइज़ करता है और न सॉल्वर चयन को।डिफ़ॉल्ट पर निर्भर रहने के बजाय, हम कुछ और कर सकते हैं। हम एक ग्रिड सर्च बना सकते हैं जो कई हाइपरपैरामीटर कॉम्बिनेशंस की जाँच करे और श्रेष्ठ को चुने।
हमारा ग्रिड सर्च यहाँ सभी संभावित हाइपरपैरामीटर कॉम्बिनेशंस को टेस्ट करता है। यदि हम alpha के 5 मान (
[0.01, 0.1, 1.0, 10.0, 100.0]), 5 सॉल्वर विकल्प (['auto', 'svd', 'cholesky', 'lsqr', 'saga']) लें, और 2-फोल्ड क्रॉस-वैलिडेशन करें, तो कुल ट्रेनिंग्स 5x5x2 = 50 होंगी। यानी एक मॉडल की जगह हम 50 मॉडल ट्रेन करते हैं। यह कहीं अधिक जटिल है—इसीलिए GPUs का उपयोग शानदार रहेगा—क्योंकि वे बहुत तेज़ हैं। चूँकि sklearn में (50 गुना तक) स्पीड बूस्ट है, इन 50 मॉडलों को ट्रेन करने में उतना ही समय लग सकता है जितना एक मॉडल में। (मैंने यही दिखाने के लिए ये संख्या चुनी है। मैं मानता हूँ कि सभी मॉडलों में समान तेज़ी नहीं होगी।)cuML sklearn बेंचमार्क्स
NVIDIA ने Intel CPUs पर चल रहे scikit-learn एल्गोरिद्म्स बनाम अपने NVIDIA GPUs पर चल रहे एल्गोरिद्म्स की तुलना की। उन्होंने क्लासीफिकेशन और रिग्रेशन समेत अलग-अलग मशीन लर्निंग वर्कलोड्स को देखा।
निष्कर्ष यह है कि साधारण मॉडल—जैसे रैंडम फॉरेस्ट—CPU पर मिनटों में ट्रेन होते थे, जो GPUs पर सेकंडों में आ गए; और जटिल मॉडल—जैसे क्लस्टरिंग—घंटों से घटकर मिनटों में। हर मामले में वर्कफ़्लो तेज़ रहे; पर उच्च-आयामी डेटा वाले भारी-भरकम मॉडलों में फायदे और स्पष्ट थे। यह वह जगह है जहाँ GPUs चमकते हैं—क्योंकि वे पैरेलल प्रोसेसिंग का उपयोग करते हैं—और यह उन मॉडलों में बड़ा फर्क डालता है जिन्हें व्यापक मैट्रिक्स ऑपरेशंस, दूरी-गणनाएँ, या इटरेटिव ऑप्टिमाइज़ेशन चाहिए।
GPU पर cuML scikit-learn बनाम CPU पर scikit-learn। स्रोत: NVIDIA
मैंने ऊपर कोडिंग उदाहरण में लीनियर रिग्रेशन से हटकर और कुछ दिखाना चाहा—ताकि शक्ति साफ़ दिखे। लेकिन यहाँ मैं लीनियर रिग्रेशन में 52 गुना तेज़ी देख रहा हूँ। मैं मानता हूँ, यह मुझे चौंकाता है—क्योंकि यह बड़ा मल्टिप्लायर लगता है। यह याद दिलाता है कि NVIDIA और भी उन्नत काम कर रहा है—जैसे अलग-अलग स्टेप्स को इस तरह इंटरलीव करना कि GPU खाली न बैठे।
कुछ सर्वोत्तम प्रक्रियाएँ
cuML संस्करण 25.02 की बदौलत अब GPUs के साथ scikit-learn एल्गोरिद्म चलाना कठिन नहीं रहा। जैसा मैंने दिखाया, आपको बस एक्सटेंशन लोड करना है। फिर भी, यदि आप वर्कफ़्लो में और गहराई तक जाते हैं और GPU त्वरक का अधिकतम लाभ लेना चाहते हैं, तो कुछ विशेष बातों पर ध्यान देना होगा।
NVIDIA सिफारिश करता है कि आप अपने पाइपलाइन में CPU और GPU के बीच डेटा ट्रांसफर्स को न्यूनतम रखें। यानी, प्री-प्रोसेसिंग, ट्रेनिंग, और इन्फरेंस स्टेप्स GPUs पर ही करें—और फिर परिणामों को होस्ट मेमोरी में भेजें। स्टेप्स को इस तरह मत मिलाएँ कि प्री-प्रोसेसिंग CPU पर और इन्फरेंस GPU पर हो।
साथ ही, दक्षता अधिकतम करने के लिए आप CUDA-X पर विचार करें—जो NVIDIA द्वारा विकसित GPU-त्वरित लाइब्रेरियों का संग्रह है। मसलन, रैंडम फॉरेस्ट्स के लिए आप scikit-learn की बजाय cuML की फॉरेस्ट इन्फरेंस लाइब्रेरी का उपयोग कर सकते हैं।
ज्ञात सीमाएँ
RAPIDS AI टीम जो कर रही है वह जटिल है—तो कुछ मुद्दे होना तय है। सौभाग्य से, ज्ञात सीमाओं का प्रलेखन अच्छी तरह से रखा गया है। मैं यहाँ सभी—या कुछ—सीमाओं की सूची नहीं देना चाहता क्योंकि कई मुद्दे विशिष्ट एल्गोरिद्म की बारीकियों में जाते हैं। साथ ही, अपडेट्स और पैच तेज़ी से आ रहे हैं। इसकी बजाय, मैं विचार करने के लिए अधिक सामान्य श्रेणियाँ बताऊँगा।
1. सामान्य सीमाएँ
कुछ प्रतिबंध ऐसे हैं जो पूरे cuML पर लागू होते हैं—सिर्फ विशिष्ट एल्गोरिद्म पर नहीं। उदाहरण के तौर पर, डेटा इनपुट फ़ॉर्मैट्स पर प्रतिबंध (कुछ समस्याएँ Python लिस्ट्स के साथ), वर्ज़न कम्पैटिबिलिटी, और मेमोरी हैंडलिंग।
2. एल्गोरिद्म-विशिष्ट सीमाएँ
कुछ अनूठी बाधाएँ अलग-अलग मशीन लर्निंग एल्गोरिद्म पर लागू होती हैं। ये भिन्नताएँ इस बात को प्रभावित कर सकती हैं कि मॉडल कैसे ट्रेन होते हैं, पैरामीटर्स कैसे बर्ताव करते हैं, या परिणाम कैसे निकाले जाते हैं। उदाहरण के लिए, cuML में रैंडम फॉरेस्ट एल्गोरिद्म स्प्लिट थ्रेशहोल्ड चुनने के लिए अलग विधि का उपयोग करता है—जिससे ट्री संरचनाएँ थोड़ी अलग हो सकती हैं।
3. समर्थित और असमर्थित फीचर्स
पैरामीटर्स, सॉल्वर्स, और इनिशियलाइज़ेशन विधियों में कुछ भिन्नताएँ हैं। उदाहरण के लिए, PCA "full" और "auto" SVD सॉल्वर्स को सपोर्ट करता है, लेकिन "randomized" को नहीं। और KNN Minkowski मेट्रिक्स को सपोर्ट करता है, Mahalanobis को नहीं।
4. पुनरुत्पादनशीलता और संख्यात्मक भिन्नताएँ
कभी-कभी पैरेललिज़्म या सॉल्वर भिन्नताओं के कारण परिणामों में हल्का फर्क हो सकता है—मैंने यह पहले भी बताया। मसलन, UMAP एम्बेडिंग्स समान नहीं होंगी, पर ट्रस्टवर्थिनेस स्कोर उच्च होना चाहिए। अन्य मामलों में, PCA कंपोनेंट के संकेत उलट सकते हैं—जिन्हें नॉर्मलाइज़ेशन की ज़रूरत होगी। फिर भी, ये विशिष्ट बातें हैं—किसी खास एल्गोरिद्म को चलाते समय ताज़ा डॉक्स देखें।
निष्कर्ष
सबसे आम Python मशीन लर्निंग लाइब्रेरीज़ के सुप्रसिद्ध एल्गोरिद्म्स के लिए अत्यंत आसान GPU त्वरक की संभावना मुझे उत्साहित करती है। इससे मॉडल सटीकता में बड़ा फर्क पड़ेगा—और इसे लागू करना सुविधाजनक तथा कठिन नहीं है।
मशीन लर्निंग की ताज़ा जानकारियों से अपडेट रहें। हमारा Machine Learning Scientist in Python करियर ट्रैक करें—ताकि आप सही तकनीकों से परिचित हों और नवीनतम प्रगतियों का अधिकतम लाभ उठा सकें। साथ ही, हमारा DataFramed पॉडकास्ट सब्सक्राइब करें। हमारे पास एक एपिसोड भी है, जिसमें Jean-Francois Puget, Distinguished Engineer at NVIDIA & Chris Deotte, Senior Data Scientist at NVIDIA GPU त्वरक के प्रभाव समेत अन्य बातों पर चर्चा करते हैं।