Skip to main content

Performance Analysis of Containerized vs Non-Containerized Machine Learning Deployment

Page 1


International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 13 Issue: 03 | Mar 2026 www.irjet.net p-ISSN: 2395-0072

Performance Analysis of Containerized vs Non-Containerized Machine Learning Deployment

Abdullah 1 , Nikhil Kumar2

1 M.E.Cloud Computing, Chandigarh University, India Email: abdshaikh1727@gmail.com

2 M.E.Cloud Computing, Chandigarh University, India Email: sabherwalnikhil@gmail.com

Abstract Machine learning models are w idely used in the context of the modern data-oriented applications, so their implementation in the production domain is of the utmost importance. The machine learning models have traditionally been deployed on the host directly. Nevertheless, the traditional approach to the implementation of machine learning models has often resulted in a number of issues, such as the questions of scalability, portability, and environment management. To solve the challenges, containerization tools like Docker have become a significant solution to the deployment of machine learning services.

The proposed research will be a comparative performance analysis of deployments of machine learning models with the option of containerization and non-containerized deployment methods. A machine learning model, trained on a publicly accessible healthcare dataset, is used as part of the research. The machine learning model is then implemented as an inference via a RESTful API. The implementation of the machine learning models is done in two environments; one environment is the traditional hostbased environment and another one is the environment based on the Docker containerization platform. A number of performance metrics are considered in order to assess the effects of containerization, and they are response latency, CPU, and memory consumption.

The findings have revealed the trade-offs between the conventional approach to deployment and containerization approach. Although the containerization method may have certain computational cost, the method offers a number of benefits, one of them being portability, reproducibility and scalability which can be exploited effectively to deploy machine learning services.

Index Terms Machine Learning Deployment, Docker, Containerization, Performance Analysis, MLOps

I. INTRODUCTION

Indeed, as it has been noted, the application of machine learning is currently becoming more widespread in real-life production settings, encompassing a very broad field. Thus, it can be stated with great certainty that as organizations are becoming more and more dependent on data-driven technologies, the necessity of efficient implementation of machine learningmodelshasbeenincreasingjustasmuch.Actually,oneshouldrealizethatdeployingmachinelearningmodelsisnot a simpletasksinceitisassociatedwiththechallengessuchassoftwaredependency,versioncontrolandscaling.[10].

The use of machine learning models is traditionally performed on the host systems using the local Python environment. Although this approach can be considered simple and convenient, it has been noted to be problematic in a live setting. An exampleisthatvariousprojectsmight requirevariouspackagesandthentheissueofincompatibilitywillarise.Moreover,the models could act differently both in the deployment environment and in the development environment because of the differentversionsofthesoftwareorthesystems.Theenvironmentisalsonotstandardizedandthusmakes ithardtoconduct experiments. Moreover, this approach is also limited in its scalability, particularly in an instance where the system has to managedifferentorahugeworkload.[9].

Docker, as one of the representatives of containerization technologies, have been identified as a potential solution in addressingseveralissuesrelatedtothedeploymentofmachinelearningapplications.Containersofferalightweightversionof virtualization, which is the ability to package an application and other related dependencies and libraries into a package together with its configuration files. This encapsulation allows the application to remain consistent even on multiple computingplatformssuchasalocalmachinewhenadeveloperisdevelopingtheapplication,toaserverinalocaldatacenter orevenacloudbasedplatform.[19].

This is regardless of the fact that it has its merits. It is thus possible that it could impact on performance. The reason is that it contains more abstraction levels and it may impact on performance. This is attributed to the fact that, under containerization,thereisruntime,namespaceandresourcemechanismsthatmayimpactontheperformance,particularlythe

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 13 Issue: 03 | Mar 2026 www.irjet.net p-ISSN: 2395-0072

computation. As a result, it should be identified how it will perform in particular, when it is compared to noncontainerizedsystems.

The research is targeting to assess and measure the performance variability between containerized and non- containerized systemsparticularlyinthe caseofmachinelearningsystems. The reason is thatunder thisstudy, there will be theabilityto knowhowitwillperformparticularlywhencomparedtonon-containerizedsystems.

Theremainingpapersectionisstructuredasfollows:SectionIIisrelatedwork,SectionIIIistheproposed architecture,Section IVistheexperimentalsetup,SectionVistheresultsandSectionVIareconclusions.

II. RELATED WORK

Containerization technology has become widely accepted in implementation of applications owing to lightweight nature of architecture.Withregardtothefieldofmachinelearning,anumberofstudieshavebeendonetoexaminethebenefitsofthe deploymentmethods,inadditiontothecostofdeployment.

A. Containerization for Machine Learning

Owen and Ajeigbe[10] describe in detail how machines can be containerized to support machine learning models, and why consistency, reproducibility and scalability are so important, and possible with the use of containerization. Another important point that the authors make is the role of Docker and Kubernetes in effective deployment and microservices architecture. The paper identifies the significant benefits of container usage in machine learning, including isolation, portability,andmanagesdependenciesmoreeasily.

KrogulskiandRak [9]studiedtheuseofDockercontainersintheimplementation ofhigh-performancecomputingprograms has been researched, and specifically the implementation of ma- chine learning-based programs has been studied. With respect to this, it was established that the HPC applications which are containerised can provide the degree of performance that is similar to the native execution, and also offer the benefits of portability and deployment. Moreover, an anomaly detectionapplicationimplemented withmachinelearningwasdeployedinavirtualclusterwiththehelpofDocker,therefore, provingthattheinfluenceofcontainerizationontheperformanceoftheapplicationis slight.

B. Multi-Container Deployments and Orchestration

Liu et al. [5] The authors studied the concept of multi- container deployment to implement online learning on Kubernetes. Their experiment involved an analysis of various container granularity configurations and CPU/memory affinity configurations. The findings demonstrated that fine-grained multi-container deployments using resource affinity of finegrained nature can significantly enhance both throughput and latency with up to an 87 percent performance improvement over single-container deployments. This work highlights the opportunity of optimizing the containerized machine learning deploymentswiththehelpofpropermanagementoftheresources.

VariousstudieshaveperformedtheperformanceanalysisofKubernetes.Kutsa[11]investigatedapplyingmachine learningto Kubernetes performance metrics, offering indications on how resources are managed in containers, scaling behavior, and detecting anomalies in containerized applications. The RunAI whitepaper [14] discusses Kubernetes architecture concerns thatdatascienceworkloadshave,suchas batchscheduling,topologyawareness,andgangscheduling ofdistributedtraining jobs.

C. Performance Comparison Studies

Felter et al. [19]It carried out a comparative performance analysis of containers and virtual machines on the different kinds of workloads. Containers, as demonstrated in the benchmarking tests, are nearly as fast as it is possible, and their overhead is low; virtual machines, by contrast, need many more resources due to the hypervisor overhead and the requirement to virtualize the entire OS. This demonstrates the utilization of performance-sensitive activities such as ML inference.

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 13 Issue: 03 | Mar 2026 www.irjet.net p-ISSN: 2395-0072

In the domain of ML serving, Schro¨der et al. [1] It has analyzed various types of autoscaling frameworks applied in the containerized applications based on machine learning and found that local scaling frameworks can respond to load changes promptlywhen compared tocloudbasedservices whicharecharacterized bysome degree oflatencyasa resultofdelays in machine provisioning. The analysis identifies the importance of the deployment environment with regard to ML inference applications.

D. Related Technologies and Applications

Another study that is of relevance is that of Zhou et al.. [3]Scholars have examined applying the concept of reinforcement learning to Kubernetes scheduling of compute- intensive pods. In their work, they demonstrate that the intelligentschedulingcanbehelpfulinconsiderablyenhancingtheutilizationofresourcesincontainerizedsettings.Bhartietal. [4] Devarakonda proposed a dynamic model of offloading tasks in serverless edge computing, which is efficient in resource allocationproblemsinadistributedcontainerizedsystem.Devarakonda[12]Thepapergivesacomprehensivewayofscaling machine learning models to a microservices architecture, which addresses different challenges of service discovery, load balancingand faulttolerance.Even thoughit is not the primary consideration, the aspecthas beenstudied by variousother studies in the topic of monitoring strategies. Pham et al [2] and Iwashita [6] explored drift detection in ML systems, while KurianandAllali[7]appliedKLdivergencefordriftdetectionindatastreams.Waseemetal.[8]The paperprovidedasurvey on drift management in the field of identifying IoT devices, revealing the significance of constant monitoring of production machinelearningsystems.

The paper provided a survey on drift management in the field of identifying IoT devices, revealing the significance of constantmonitoringofproductionmachinelearningsystems.TableIsummarizesthekeyrelatedworksandtheircontributions.

Although the process of containerization and ML deployment is widely studied, it is still useful to directly compare containerizationversusnon-containerizationofMLinferenceunderthesameconditions,tocompareitsperformancemetrics. That gap has been bridged in this paper through a con- trolled experiment performed with systematic measurements and analysis.

TABLE- SUMMARY OF RELATED WORK ON CONTAINERIZED MACHINE LEARNING DEPLOYMENT

Study

Owenand Ajeigbe[10]

Krogulski and Rak [9]

Focus Key Findings

Containerization forMLmodels

Dockerin HPCforML

Liu et al.[5] Multicontainer deploymentson Kubernetes

Kutsa[11] MLfor Kubernetes metrics

Felteret al. [19]

Schro¨deret al. [1]

Reproducibility, portability, scalability

Near-native performance,ease ofdeployment

Fine-grained deployments improve throughput/latenc y

ML-basedanalysis ofcontainer performance

Containersvs VMs Containershave near-native performance

Autoscaling forcontainerized ML

Localscaling outperformscloud services

Relevance

Foundational

Demonstrator

Optimized

Quantifiable

Baseline efficiency

Importance ofenvironment

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 13 Issue: 03 | Mar 2026 www.irjet.net p-ISSN: 2395-0072

III. PROPOSED ARCHITECTURE

The proposed architecture will offer a reasonable and orderly method of contrasting containerized and non- containerized machine learning implementations. It gives a systematic framework of evaluating the performance within a controlled environmentFig.1.

A. System Components

Thefollowingarethemajorbuildingblocksofthearchitecture:

Data Processing Module: The system takes the raw data as an input and the required preprocessing tasks are carried out. Thisinvolvesthetreatmentofmissingvalues,normalizationofthedataandthedivisionofthedataintotrainingandtestdata. Inthecaseofthediabetesdatasetthathasbeenusedinthestudy,preprocessingiscarriedoutbystandardizingthenumerical attributesandcodifyingthecategoricalones.

Model Training Module: The machine learning model then trains the model with the preprocessed data. The model of classification adopted is the logistic regression model because it is simple and it is used in a production setting. After the modelhasbeentrained,itissavedintheJoblibmodeltobedeployed.

API Serving Module: The trained model is embedded in a RESTful API, and this is achieved using the Flask web development framework, which is a lightweight web application development framework for the Python program- ming language. The RESTful API is configured to include a prediction API, and this prediction API is responsible for accepting data,performingpredictionsusingtheloadedmodel, and producing the predictions in JSON format. This is astandardway ofservingmachinelearningmodels,asshown inFigure1,wheremodelsarerunasmicroservices.

Fig. 1. Overviewoftheperformancecomparisonpipeline Deployment Environments: Toenablecomparativeanalysis,thesameapplicationisusedintwodifferentcontexts:

• Non-Containerized: In the former configuration Flask ap- plication is executed on the host operating system directly throughthesystemPythoninterpreter,andalldependenciesaregloballyinstalled.

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 13 Issue: 03 | Mar 2026 www.irjet.net p-ISSN: 2395-0072

• Containerized: ThesecondsetupincludestheapplicationthatispackedintoaDockercontainer,andtherequirementsare definedinarequirements.txtfile.Thecontainerhasaseparatefilesystemandprocessnamespace.

Monitoring Module: Duringthe application execution, the performance monitoringtoolsmonitors the important metrics of thesystemsuchastheresponselatency,processortimeusageandmemorytimeusage.Allthesemeasurementsarerecorded andanalyzedsubsequently.

B. Workflow

Theexperimentchainofworkbecomesasfollows:

• Performance Monitoring: Intheprocessofexecution,itistrackedwiththehelpofperformancemonitoringtoolswiththe metrics of the system, such as response latency, CPU usage and memory consumption. These values arestored and subsequentlypreprocessedinthedatasetsandtrainedinthemodels.

• Model Serialization and API Development: The trained model will be turned into a REST API to serve predictions.

• Deployment in Non-Containerized Environment with Performance Measurement: Theapplicationisdeployed directlyonthehostsystemandperformancemetricsaretaken.

• Creating Container Image and Deployment Using Docker Environment: The application is bundled into a Dockercontainer,includingalldependencies,anddeployedandruninisolation.

• Performance Measurement under Similar Conditions: System metrics in the case of a non-containerized deploymentaretakenunderidenticalloadconditions.

• Comparative Analysis: The gathered measures in both settings are compared to assess the performance dissimilarity.

• IV. EXPERIMENTAL SETUP

A. Hardware and Software Configuration

All the experimentsare performed on a machine that is consistent. hardware andsoftware setupso that it is fairly comparable.

• Operating System: OperatingSystem:Ubuntu22.04LTS(Linuxkernel).

• Processor: CPU:IntelCorei7-1165G7(4cores,8threads)

• RAM: 16GBDDR4@3200MHz

• Storage: 512GBNVMeSSD

• Programming Language: Python3.10.12

• Machine Learning Library: Scikit-learn1.2.2

• API Framework: Flask2.3.2withWerkzeug2.3.6

• Container Platform: Docker24.0.5(usingoverlay2storagedriver)

• Performance Monitoring: psutil 5.9.5, Python timemodule

B. Dataset and Model

Anopen-sourcediabetespredictiondatasetfromtheUCIMachineLearningRepositorywasusedinthisstudy:

• Samples: 768patientrecords

• Features: 8medicalpredictorvariables,suchasbloodglucoselevel,bloodpressure,skinthick-ness,insulinlevel, BMI,pedigreeofdiabetesfunctionalityandage.Target:Binaryoutcomeofthepresenceofdiabetesin lessthan.

• Target: A logistic regression with regularization L2 is trained. training 80 percent and testing 20 percent. The accuracyofmodelisapproximately 78%t,aspreciseas 0.76andrecalling0.71onthepositive.

TheJoblibserializesthetrainedmodel,whichproducestheresult.withinafilesizeofabout2.1KB.

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 13 Issue: 03 | Mar 2026 www.irjet.net p-ISSN: 2395-0072

C. Deployment Configurations

1) Non-Containerized Deployment: The application is running to the host with the Python system. All globally dependencies areinstalled withpip.Theapplicationis running onport 5000 with theinbuiltdevelopmentserver offered by Werkzeug,acomponentoftheFlask-library,anditisnotprocess-isolatedandresource-constrained.

FROM python:3.10-slim AS builder 207 WORKDIR /app 208 COPY requirements.txt . 209 RUN pip install –user -r requirements.txt

2) Containerized Deployment: A Docker image is made. employing a multi-stage method used to reduce the final image size.

FROMpython:3.10-slimASbuilderWORKDIR/app COPYrequirements.txt

RUNpipinstall user-rrequirements.txt

FROMpython:3.10-slimWORKDIR/app

COPY from=builder/root/.local/root/.localCOPYapp.pymodel.joblib. ENVPATH=/root/.local/bin:$PATHEXPOSE5000 CMD["python","app.py"]

Thesizeofthefinalimageisapproximatedtobe182MB.Thecontainerrunswithdefaultsettingsusing: dockerrun-p5000:5000 nameml-containerml-image

Thesize ofthe final image isapproximatedto be 182 MB.The container isrunningdefaultsettings (no CPUormemory limits)usingthefollowingcommand: dockerrun-p5000:5000 nameml-containerml-image

Performance Measurement andTraffic Simulation

MeasurementofPerformanceandTrafficSimulation.Theuser requests are simulated by the Python script with thehelp of sending. 20 sequential POSTs to the API endpoint. A short Delay of 100 ms inserted between requests to simulate. realistic usage patterns. The value of features of each request. are at random generated by the same distribution as the trainingdata..

Thefollowingmetricsarenotedinrelationtoeachrequest:

• Latency: Timetakenbetweeninitiationofrequestandresponse.receipt(inmilliseconds)

• CPU Utilization: TheserverprocessCPUusageat.requesthandling(profiledafterrequestcompletion)

• Memory Usage: What Percentage of memory is usedbytheresidentsetsizealsoindicatestheserverprocess.(RSS) Inthisscript,there isaninclusionofa warm-up of10requests.measureshave beenmeasured beforemaking surethat themodelandAPIarechargedintomemoryandalljust-in-timeoptimizationshavebeenapplied.

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 13 Issue: 03 | Mar 2026 www.irjet.net p-ISSN: 2395-0072

Thenon-containerizeddeploymentshowsanaveragelatencyof17.36mswithconsiderablevariability(range:7.82–28.70ms, standard deviation: 5.84 ms). The CPU utilization averages 13.09% with occasional spikes up to 42.9% during request processing. Memory usage remains remarkably stable at approximately 90.1% of the process’s allocated memory, correspondingtoabout450MBRSS.

FortheDockercontainerizeddeployment,theaveragelatencywasapproximately12.7mswithlowervariability(range:10.2–15.8ms,standarddeviation:1.6ms).CPUutilizationaveraged15.0%withmemoryusagearound91.0%.TableIIIsummarizes thecomparativeanalysis.

TABLE III COMPARISON OF AVERAGE PERFORMANCE METRICS

D. Graphical Analysis

Fig.2showsthecomparisonoflatencyofbothdeploymenttypes.Thecontainerizeddeploymenthasareducedlatency,which impliesmorepredictableperformancewithload.

Fig.3TheutilityoftheCPUpatternsiscomparedinFig. 3,anditshowsthatwhereasthecontainerizeddeploymentis alittle moreaverage. TheutilizationislessinconsistentandthisislesswithCPU. extreme spikes.This impliessuperiorisolation of resourcesandContainerruntimescheduling.

Fig. 4 Comparison of memory usage is shown in Fig. 4. Both deploy- memory consumption patterns are similar in the mentions.containerizedonewithslightlyincreasedmemory.usagebecauseofoverheadofcontainerruntime.

TABLE II PERFORMANCE METRICS FOR NON-CONTAINERIZED DEPLOYMENT (20 REQUESTS)

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 13 Issue: 03 | Mar 2026 www.irjet.net p-ISSN: 2395-0072

Fig. 3 showsthecomparisonofCPUutilizationpatterns betweencontainerizedandnon-containerized deployments.

E. Discussion and Interpretation

Thefindingsoftheexperimenthaveanumberofimplications.asfarascontainerizedMLdeploymentisconcerned: Latency Improvement: TheDockercontainerizeddeploymenthas27%reducedaveragelatencythanthe. Non-containerized deployment(12.7msvs17.36ms).Thissuchcounterintuitiveresultcanbeexplainedbyanumberoffactors:

• Resource Isolation: One is the factthatcontainers provide. enhancedCPU and memoryseparation, which decreases. othersystemprocessesinterference.

• Caching Effects: Caching Effects Containerized pro-

Fig. 2. Latencycomparisonofnon-containerizedvscontainerizeddeployment
Fig. 4 Memoryusagecomparison(percentageofprocessmemory)

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 13 Issue: 03 | Mar 2026 www.irjet.net p-ISSN: 2395-0072

cessescanalsoreceivefewercontextswitchescourtesy ofnamespaceisolation.

• Reduced Context Switching: ProcessesinContainersuseNamespacesmayresultinfewercontextswitches and improvedisolation..

Resource Utilization Trade-offs: The containerized deployment is a bit heavier to the CPU (15 percent vs. 13 percent). memory(91%vs.90.1)becauseofoverheadofthecontainer.runtime.Thisoverheadincludes...

• Container runtime process (containerd or docker-containerd)

• Networknamespacevirtualization

• Filesystemlayeroverhead(overlay2storagedriver)

• Additionalkerneloperationsfornamespaceisolation

Performance Stability: Thecontainerizeddeploymentalso.hasmuchlowerlatencyvariability,thestandardofwhichis1.6ms deviation as opposed to 5.84 ms non- containerized setup. This implies containers are a way of providing. more foreseeable performance,andthisisespeciallycrucial.wheretheproductionsystemsneedconstantservicelevel.agreements(SLAs). Comparison with Previous Studies: These are findings consistent with those of the past. has demonstrated to have low incurredcostswithpastresearch[9],[19]containersoverheadatacostofgeneratinghighbenefits.Eventhoughthereduction inlatencyisnotseeninall.applications,theenhancementdenotesthatcontainerization.areevenabletoenhancethework of somekindsofapplications.

Practical Implications: In the case of production ML systems, the slight resource overhead caused by containerization 2additionalCPUand1percentadditionalmemory-isreadilywarranted.bythesubstantialbenefits:

• Portability: Containers ensure that the implementation of the use in a uniform fashion in a variety of environments.Development,testingandenvironmentsareexamplesofsuch.duction.

• Reproducibility: Containerorchestrationsoftwarepermitsthe.scalingapplicationsautomaticallyfully.

• Scalability: Containerorchestrationtoolspermitthescalingofapplicationscompletelyautomatically.

• Isolation: Thereareseveralmodelsthataredeployedonthehostandwithoutdependencyproblems.

• DevOps Integration:

TableIVprovidesaqualitativecomparisonofthetwodeploymentapproaches.

Aspect

Non-Containerized Containerized

SetupComplexity Low Moderate

EnvironmentIsolation Poor Excellent Portability Low High

Reproducibility Difficult Easy Scalability Manual Orchestration-ready PerformanceOverhead None(baseline) Slight(2%CPU,1% memory)

CONCLUSION AND FUTURE WORK

A. Conclusion

Adetailed comparison of thestudy wasmade. of applying machinelearning modelsin containerized and non- containerized forms. A healthcare data was used in the study. and a logistic regression model implemented with a REST API, and the response time, processor usage, and memory utilization, CPU utilization, and memory utilization. The performance comparisonwasconductedunderthesameexperimentalconditionstoensureafairevaluation. Themeanlatency of responsewas discovered to bereduced by27percent.inthecontainerised deploymentversusthenoncontainerizeddeployment(12.7msvs.17.36ms).

1) The total overhead of resource consumption caused by containerization was negligible, with approximately 2% CPU overhead.

TABLE IV - QUALITATIVE COMPARISON OF DEPLOYMENT APPROACHES

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 13 Issue: 03 | Mar 2026 www.irjet.net p-ISSN: 2395-0072

2) The model had a considerable implication on its performance stability. more effective in the containerized deployment,withtheaggregate.latencyvariabilitydecreaseby73%.

3) Bothhadasimilarmemoryconsumptionbehavior.deploymentmodels,however,thecontainerizedone. hadaslightly morememoryconsumption.

B. Future Work

Therearealsointerestingdirectionsproposedtothisstudy.

1) Larger Models and Deep Learning: Larger Models and Deep Learning: other direction. is to investigate the use of deep learning models, e.g. CNNs. and Transformers, which makes use of GPU acceleration, are affected. by containerization.

2) Orchestration Platforms: Another direction is to explore how container orchestration tools, such as Kuber- netes, impactperformance,includingauto-scaling,loadbalancing,andthecostofusingaservicemesh.

3) Multi-container Applications: Otherdirectionistounderstandthefunctionalityofthecontainerorchestrationtools, e.g.,Kubernetes,impactperformance,andauto-scaling.loadbalancing,andtheexpenseofaservicemeshusage.

4) Resource-Constrained Environments: Analternative direction refers toinvestigatethe questionof howcontainers can influence machine learn- or deployments of edge computing, such as CPU, memory, and networking capabilitiesserverless.INGinferenceplatforms,suchascontainercost.

5) Different Container Runtimes: Anotherfuturedirectionistoinvestigatehowdifferentcontainerruntimessuchas containerd,CRI-O,andPodmaninfluencemachinelearningperformance,includingcomparisonsbetweenorchestration platformssuchasKubernetes.

REFERENCES

[1]C. Schro¨der, R. Bo¨hm, and A. Lampe, “Comparison of Autoscaling Frameworks for Containerised MachineLearningApplicationsina LocalandCloudEnvironment,”arXivpreprintarXiv:2311.18659,2023.

[2]T.M.T.Pham,K.Premkumar,M.Naili,andJ.Yang,“TimetoRetrain? DetectingConceptDriftsinMachineLearning Systems,”arXivpreprint arXiv:2410.09190,2024.

[3]H. Zhou, H. Y. Chan, S. Y. Zhang, M. E. Lin, and J. Ni, “A Kubernetes Custom Scheduler Based on Reinforcement LearningforCompute- IntensivePods,”arXivpreprintarXiv:2601.13579,2026.

[4]S.Bharti,R.Gill,andS.Harnal,“AdaptiveTaskOffloadingFramework forServerlessEdgeComputing,”inProc.IEEE Int.Conf.onDisruptive Technologies,2025.

[5]P. Liu, J. Guitart, and A. Taherkordi, “Performance Characterization of Multi-Container Deployment Schemes for OnlineLearningInference,” inIEEEInternationalConferenceonCloudComputing,2023.

[6]A.S.IwashitaandJ.P.Papa,“AnOverviewonConceptDriftLearning,” IEEEAccess,vol.4,pp.1–15,2016.

[7]J.F.KurianandM.Allali,“DetectingDriftsinDataStreamsUsing Kullback-LeiblerDivergenceMeasure,”Journalof Data,Information andManagement,2024.

[8]Q. Waseem et al., “Drift Management in ML-Based IoT Device Classification: A Survey and Evaluation,” InternationalJournalon Advanced Science,EngineeringandInformationTechnology,2025.

[9]P. Krogulski and T. Rak, “A Case Study on Virtual HPC Container Clusters and Machine Learning Applications,” AppliedSciences,vol. 15,2025.

[10]A.OwenandK.Ajeigbe,“ContainerizationofMachineLearning Models,”2024.

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 13 Issue: 03 | Mar 2026 www.irjet.net p-ISSN: 2395-0072

[11]D. Kutsa, “Using Machine Learning for Analyzing Performance Metrics in Kubernetes,” International Journal of ScientificResearchandEngi- neeringDevelopment,2025.

[12]R. R. Devarakonda, “An Integrated Approach for Scalable Deployment of Machine Learning Models in a ContainerizedMicroservicesArchi- tecture,”JournalofEmergingTrendsandNovelResearch,2023.

[13]Quadri et al., “Artificial Intelligence Performance Evaluation in Cloud Computing Environments,” Journal of ArtificialIntelligenceResearch, 2023.

[14]RunAI,“KubernetesArchitectureforDataScienceWorkloads,”RunAI Whitepaper,2023.

[15]“UnderstandingDataDriftandConceptDriftinMachineLearning Systems,”ResearchReport,2024.

[16]“AIPerformanceAnalysisinCloudInfrastructure,”TechnicalReport, 2023.

[17]“PerformanceAnalysisofAISystemsinContainerizedInfrastructure,” SSRNElectronicJournal,2024.

[18]“Machine Learning Deployment and Performance Optimization in Cloud Systems,” International Journal of ScientificResearchandEngineering Development,2025.

[19]W. Felter, A. Ferreira, R. Rajamony, and J. Rubio, “An updated perfor- mance comparison of virtual machines and linux containers,” in 2015 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS),2015,pp.171–172.

Abdullah

Heispresentlyservingasaresearcherinthefield. ofCloudcomputinginChandigarhUniversity,India. HisfieldsofinterestareMLOps,containerization, andloadbalancingofdistributedsystems.Hehasbeeninvolved insomeprojectsinrelationtoDockerandScalable machinelearningwithKubernetes.

Nikhil Kumar

Co-Authorandinvestigatorwithspecialfocus inthesectorofCloudcomputingandDevOperations. methodologies.Histopicsofinterestarescalable. containerization,theuseandarchitectureintheCloud. ofContinuousDeploymentandContinuousIntegration. applicationstoolstotheefficientdeploymentofapplications. Heisconcernedwithmachinelearningintegration withImprovement ofthecloudtechnologies.systemreliability, systemefficiency,andsystemreproducibility.

Turn static files into dynamic content formats.

Create a flipbook
Performance Analysis of Containerized vs Non-Containerized Machine Learning Deployment by IRJET Journal - Issuu