You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Make mlops module independent of train and serving modules #5813
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
I agree, the mlops namespace package should be independent of serve and train. Additionally when using the step decorator to define a pipeline step, it will install mlops namespace 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
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.
Activity
guibberta commentedon May 12, 2026
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.gbeasleytombola commentedon May 12, 2026
Also agree. This is stopping us updating to V3. This has previously been raised here #5531 and as a discussion here #5441
mjost5v commentedon May 12, 2026
DieterDP-ng commentedon May 19, 2026
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.
gabrielclimb commentedon Jun 15, 2026
Please, someone removes it, this is so annoying