Repository navigation
Make mlops module independent of train and serving modules #5813
Description
Activity
I agree, the
mlopsnamespace package should be independent ofserveandtrain. Additionally when using the step decorator to define a pipeline step, it will installmlopsnamespace at runtime which results in huge overhead.- Previously I was able to run a lambda to manage my lops pipeline in v2. V3's size requires stripping dependencies to get the size under lambda size constraints…On Tue, May 12, 2026, 10:55 AM gbeasleytombola ***@***.***> wrote: *gbeasleytombola* left a comment (aws/sagemaker-python-sdk#5813) <#5813 (comment)> Also agree. This is stopping us updating to V3. This has previously been raised here #5531 <#5531> and as a discussion here #5441 <#5441> — Reply to this email directly, view it on GitHub <#5813 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFRCH4FDGF2OI56EG3FWZL42M3M7AVCNFSM6AAAAACYMTRPWKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DIMZRGYZDCMBZG4> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>
We're hitting a related issue in a standard local development / CI context (not Lambda).
Our project uses sagemaker-mlops purely for pipeline orchestration (building a DAG with ModelStep, TuningStep, ConditionStep, etc.) and calls ModelBuilder.build() / ModelBuilder.register() only within a PipelineSession to compile the pipeline definition. No torch usage.
Yet pip install sagemaker pulls down ~1 GB of CUDA wheels on every CPU-only machine and CI runner because sagemaker-mlops declares sagemaker-serve as a hard dependency, and sagemaker-serve (0.1.0 through 1.11.0) unconditionally requires
torch>=2.0.0. Making sagemaker-serve an optional extra of sagemaker-mlops, or splitting torch into an optional extra of sagemaker-serve, would reduce this bloat.Please, someone removes it, this is so annoying
Previously, MLOps orchestration was possible within a Lamber. Now with new dependencies, they are too big to fit in the lambda. The native dependencies and PyTorch explode the size of the total deployment signficantly