OCI Data Science: Notebooks, Pipelines, and Model Deployment

Every machine learning team eventually builds the same four things: a place to explore data, a way to run training that outlives a laptop, a system to make the training repeatable, and a path that serves the resulting model to applications. Teams that build these themselves on raw compute spend their first two quarters on plumbing. OCI Data Science packages the four as managed services inside the tenancy, under the same IAM, networking, and compartment model as the rest of the estate, which is precisely what distinguishes it from doing data science on someone's laptop with production credentials.

This article is part of our complete guide to AI on OCI. The neighboring layers, renting raw GPU capacity and consuming hosted models, are covered in their own articles; here we stay on the managed platform between them.

The four components that matter

Notebook sessions

A notebook session is a managed JupyterLab environment on a compute shape you choose, CPU for most exploration, GPU when the work demands it, with conda based environments for dependency management and block storage that persists. Sessions can be deactivated when idle, which stops compute billing while keeping the storage, and that single habit, deactivation as a reflex, is the difference between a tidy exploration bill and a standing tax. Critically, sessions run inside your VCN if you design them that way, so data access follows network policy instead of convenience.

Jobs

A job runs a script or training task on managed compute and releases the capacity when it finishes. This is the workhorse for real training: it bills only for the run, it scales to shapes a notebook should never hold, and it removes the human babysitter from long executions. Anything that runs longer than a coffee break belongs in a job, not a notebook, both for cost and for reproducibility.

Pipelines

Pipelines chain steps, data preparation, training, evaluation, registration, into a repeatable graph with per step compute. The value is institutional rather than technical: a pipeline is the difference between "the model Maria trained in March" and a process the team can rerun, audit, and improve after Maria changes jobs.

Model catalog and model deployment

The model catalog stores versioned model artifacts with their metadata, provenance, and dependencies. Model deployment takes a catalog entry and serves it as an HTTPS endpoint on managed instances with load balancing and scaling. Between them they form the production seam: everything before the catalog is experimentation, everything after is operations, and the catalog entry is the auditable handoff.

Choosing the compute mode

Where the GPU line crosses

The platform runs GPU shapes for notebooks, jobs, and deployments, which raises the obvious question of when to use it versus renting bare GPU capacity directly. The working rule: OCI Data Science carries you through single node and modest multi GPU training comfortably, including most fine tuning of open weights models, the workflow we walk through in fine tuning LLMs on OCI. When the work demands many nodes with RDMA class networking between them, you have left the platform's lane and entered cluster territory, covered in building AI training clusters on OCI. Matching the shape to the task, and knowing which side of that line your workload sits on, is the substance of our GPU shapes guide.

From notebook to production: the MLOps loop

Environments and reproducibility

The platform's conda based environment system deserves more attention than it gets, because dependency drift is the quietest way machine learning programs rot. A model trained in an environment nobody recorded cannot be retrained with confidence, only approximately imitated. The working discipline is to treat environments as artifacts: published, versioned, and referenced by jobs and deployments explicitly, so that the answer to "what exactly produced this model" is a lookup rather than an investigation. The same logic extends to data. Training jobs should record the object versions or table snapshots they consumed, because a model is a function of its data, and a metrics regression six months later is unanswerable without knowing what the data looked like six months earlier. None of this is glamorous, and all of it is the difference between a model catalog that serves an audit and one that decorates it. Teams that adopt these habits early spend their time improving models; teams that adopt them late spend a quarter reconstructing how the production model was ever built.

Governing a multi team platform

Data science platforms accumulate users faster than governance, and the compartment model is the tool that keeps the accumulation orderly. Give each team or product its own compartment with quotas on the shapes that hurt, GPU sessions above all, so one team's enthusiasm cannot consume another team's quarter. Use dynamic groups and resource principals so notebooks and jobs reach data through policy rather than through credentials pasted into cells, which is both the secure path and the auditable one. Tag every session, job, and deployment with team and project defaults so the bill decomposes without forensics, the practice that underpins any serious AI cost control program. And put the model deployment privilege behind a narrower gate than the notebook privilege: exploration should be cheap and broad, production should be deliberate and reviewed. The platform enforces whichever culture you configure, and configuring none is also a choice, just a worse one.

Integration with the rest of the estate

The platform's quiet advantage is adjacency. Data access reaches Object Storage and Autonomous Database natively, with resource principals replacing embedded credentials, so the security review has something to approve rather than something to discover. Secrets live in Vault. Logs and metrics land in the same observability stack as the rest of the tenancy. And generative workloads can call the hosted models of the OCI Generative AI service from notebooks and jobs, which makes the platform a natural harness for evaluation and prompt engineering work, not just classical ML. Container based teams can serve models on OKE instead of managed deployment when they need mesh integration or custom serving stacks; the trade is control for operational ownership.

Cost behavior and the habits that control it

Data Science billing is infrastructure billing: you pay for the shapes under sessions, jobs, and deployments, plus block and object storage. The platform itself adds no premium on top of the compute, which keeps the math simple. The leaks are behavioral. Idle notebook sessions left active are the classic, deactivation policies and scheduled stop automation close it. Oversized deployments are the second, a model that serves comfortable traffic on two small instances does not need four large ones because launch week was scary. And orphaned block volumes from deleted sessions are the third, a periodic sweep finds them. The broader program for keeping AI infrastructure honest is in controlling AI workload costs on OCI.

The independent view

OCI Data Science is the platform layer we recommend most often for teams whose data already lives on OCI, not because it wins feature comparisons against every dedicated MLOps vendor, but because it removes the two failure modes that actually kill enterprise ML programs: ungoverned infrastructure and unreproducible models. The work that needs doing is design, the VCN attachment, the IAM policies, the pipeline structure, and the deployment gates, and that is implementation work, not product selection work. We deliver it through our OCI implementation practice on a fixed Project fee, and operate the result under Managed Monthly retainers where the deactivation policies, utilization reviews, and drift monitoring are simply part of the service.