DEV Community: Brad Micklea

What’s Next for the KitOps Project

Brad Micklea — Thu, 23 Jan 2025 15:51:40 +0000

KitOps 1.0: Production Proven

Today is an important milestone for the KitOps open source project as we release version 1.0. This isn’t just about new features (although automatically creating a ModelKit from Hugging Face or a scanned directory is exciting), it’s about the start of a journey for every KitOps user. KitOps is downloaded thousands of times a week and is used in production by global enterprises, secure government agencies, and a slew of smaller (but equally important) organizations.

This 1.0 says KitOps has been proven production and by some of the most demanding organizations and it’s ready for whatever you can throw at it!

Of course there are new features too thanks to our awesome community of developers, authors, and feedback providers:

Generate a ModelKit by importing an existing Hugging Face repository (no need to edit the Kitfile)
Generate a Kitfile automatically by scanning a directory structure
The config object for ModelKits now stores digests with each layer, to make it easier to access a specific layer's blob
Layers are now packed to include directories relative to the context directory, making unpacking tarballs simpler
Tail logs with the -f flag
The Kitfile model object now has a format field so you can be explicit about the model’s serialization format (e.g., GGUF, ONNX, etc…)

Despite the major version change, KitOps 1.0 is backward compatible.

Before What’s Next, What Started It?

KitOps started with a simple question:

“why isn’t there an open standard for packaging an AI/ML project so that it can be imported or exported into any tool or environment?”

Every AI/ML tool has its own packaging format and approach, making moving projects from tool-to-tool (or worse yet, replacing one vendor’s tool with another) less fun than Carrie’s high school prom. So why wasn’t there a standard already? The answer was because tool and infrastructure vendors don’t like choice - they want customers locked into their formats and tools. Sounds great to investors, but ultimately it’s always a losing strategy because users will always need choices. That’s why PDF, GIF, Markdown, and other open standards are…well standards!

Luckily, the original KitOps authors were all readers of xkcd, so we didn’t create a 15th standard, instead we built KitOps to allow teams to share and reproduce their AI/ML projects using the existing OCI standard (the container one). But…we didn’t want to just jam models, datasets, codebases, and documentation into a single container image because not everyone needs everything to do their part of the project lifecycle.

Instead we packaged everything as an OCI Artifact called a ModelKit that includes models, datasets, codebases, and documentation in separate layers. We then built the Kit CLI to make it trivial for people or pipelines to pull only those layers they need to do their job.

Teams using KitOps are seeing big improvements in security and reduction of risk, plus a 31.9% decrease in the time it takes to take an AI/ML project from conception to completion:

KitOps stores, versions, and secures their AI/ML projects in the same place their containers are already kept with no additional infrastructure (everyone has a container registry already)
KitOps ModelKits are tamper-proof, secure, and can be digitally signed
KitOps ModelKits can be used with existing MLOps and DevOps tools without any changes
KitOps selective unpacking reduces time and space needed to deploy and reproduce AI/ML projects
KitOps packages are easy to turn into runnable containers or Kubernetes deployments

What’s Next for KitOps?

KitOps was part of a larger goal - to establish an open standard for packaging AI/ML projects that will be adopted by all vendors. We’ve made two important steps on that road:

*1/ Drafted a CNCF-sanctioned model packaging specification *
The KitOps maintainers along with members of Red Hat, ANT Group, ByteDance, and Jozu have discussed and drafted a new specification that would give OCI registries and runtimes a consistent format and interfaces for handling AI/ML projects. This CNCF standard would simplify sharing and reproducing AI/ML projects in Kubernetes and its associated projects.

2/ Submitted KitOps to the CNCF as a sandbox project

We have submitted KitOps as a sandbox project to the CNCF, and expect to have it approved in Q1 2025. This will make KitOps community property and make it simpler for other vendors to add KitOps integrations in their products.

It’s always hard letting something go out into the world that you’ve built with love and care, but we’re more excited to see how you, the AI/ML community, adopt and grow KitOps!

-Brad Micklea, KitOps Project Lead & Jozu CEO

Join the KitOps community

For support, release updates, and general KitOps discussion, please join the KitOps Discord. Follow KitOps on X for daily updates.

If you need help there are several ways to reach our community and Maintainers outlined in our support doc

Reporting Issues, Suggesting Features, and Contributing

Your insights help KitOps evolve as an open standard for AI/ML. We deeply value the issues and feature requests we get from users in our community. To contribute your thoughts,navigate to the Issues tab and hitting the New Issue green button. Our templates guide you in providing essential details to address your request effectively.

We love our KitOps community and contributors. To learn more about the many ways you can contribute (you don't need to be a coder) and how to get started see our Contributor's Guide. Please read our Governance and our Code of Conduct before contributing.

A Community Built on Respect

At KitOps, inclusivity, empathy, and responsibility are at our core. Please read our Code of Conduct to understand the values guiding our community.

Roadmap

We share our roadmap openly so anyone in the community can provide feedback and ideas. Let us know what you'd like to see by pinging us on Discord or creating an issue.

KitOps: A Practical Approach to Accelerating AI/ML Development to Production

Brad Micklea — Wed, 02 Oct 2024 14:12:56 +0000

Every company and executive is talking about accelerating their success with AI/ML. But between the aspiration and reality is a huge gulf. For large tech companies they’re spending their way across: hiring data scientists, ML engineers, MLOps practitioners, and a host of other very high-paid roles and putting them in new divisions or AI Centres of Excellence (AI CoEs).

This new CoE looks suspiciously like the software engineering organization that it sits beside. This shouldn’t be surprising because many of the problems plaguing AI/ML development are problems that faced software development years ago: how to create effective collaboration, how to reproduce experiments across different teams and environments, how to secure projects, how to know where IP came from...

The idea that companies need a whole new set of teams starting from the ground up to solve these issues for AI/ML is...odd. Why can’t we use the solutions learned from years of software development?

We can...and should.

The trick is identifying which parts of the existing infrastructure, tools, and processes can be adapted to work with AI/ML and which genuinely require a new approach.

AI/ML Project Packaging and Versioning

There is no standard for packaging and versioning the various artifacts needed to reproduce an AI/ML project:

Models in Jupyter notebooks or MLOps tools
Datasets in data lakes, databases, or file systems
Code in Git repositories
Metadata (such as hyperparameters, features, and weights) scattered across different storage systems

That’s insane - in every other area of technology there are these basic standards so teams can use different tools while collaborating: containers, PDFs, TARs, there are hundreds of other examples.

Without this, the already challenging job of managing the lifecycle of AI projects is even harder, and more likely to fail.

We created KitOps to solve this problem. It’s an open-source, standards-based packaging and versioning system designed for AI/ML projects. KitOps takes advantage of existing software standards so the tools and processes your DevOps / SRE teams use with their containerized applications, can be used with AI/ML projects.

KitOps allows AI teams to package AI/ML models, datasets, code, and metadata into what’s called a ModelKit. This ModelKit is a versioned bundle that can be sent to staging, user acceptance testing (UAT), or production. For DevOps and SRE teams it means they can manage AI models like any other production asset, such as containers or microservices.

For companies that are using containers and enterprise registries, KitOps is a seamless fit. KitOps ModelKits use the OCI standard - because it doesn’t make sense to create a unique standard when an existing one works. With KitOps DevOps and SRE teams manage AI artifacts like models, datasets, code, and metadata from the same registry where every other artifact is.

Let’s dive into how KitOps can streamline AI/ML operations and solve some of the unique challenges faced by companies adopting machine learning.

Level 1: Simplifying the Handoff from Development to Production

With KitOps integrated into your CI/CD pipeline, you can automate the deployment of AI models, either manually triggered by the model development team or automatically when changes are made in the model or its associated artifacts. Here’s why this matters:

Unified Operations: All assets are in one place, making it easier for operations teams to test, deploy, audit, and manage AI workloads.
Compliance and Security: By keeping AI versioned packages in the same enterprise registry as other production assets, they’re easier to secure and audit, which is crucial for compliance purposes.
Vendor Independence: Using the OCI standard protects your company from vendor lock-in, giving you flexibility when negotiating with vendors and adapting your MLOps or serving infrastructure as your needs evolve.

For companies dipping their toes into AI/ML, this is the first step with KitOps, but many find themselves wanting to extend its use.

Level 2: Adding Security to the Mix

Security is a top concern, especially when dealing with sensitive data or compliance requirements like GDPR or HIPAA. KitOps, in combination with the open-source ModelScan tool, allows your team to scan models for vulnerabilities before they’re promoted beyond development and package them in a tamper-proof ModelKit.

Security-conscious teams can create curated ModelKits by pulling trusted models from public repositories like Hugging Face, scanning them, and storing them as ModelKits in the enterprise registry. This guarantees that only tamper-proof, verified models are used within the organization. This level of security isn’t just important for peace of mind — it’s increasingly a requirement in industries subject to strict regulatory oversight.

Once a model passes scanning, it’s packaged and signed as a ModelKit, ensuring that it can’t be tampered with on its way to production.

Level 3: Full Lifecycle Management with KitOps

For companies looking to mature their AI operations or meet stringent compliance standards (like in the European Union), KitOps can be used throughout the entire AI project lifecycle. Instead of waiting until production, you can start using ModelKits in development.

This approach solves many common pain points:

Unified Storage: All AI/ML project artifacts are stored as OCI-compliant objects, ensuring a consistent and standardized process across the organization.
Collaboration Across Teams: Since data, AI/ML, and software teams work in different tools, using KitOps ensures that they can share and collaborate on artifacts securely and efficiently without compromising on their chosen toolset.
Tamper-Proof Artifacts: By storing development artifacts as ModelKits, you protect them from accidental or malicious tampering — an increasingly common concern in AI development.

Best of all, this process can be automated using the KitOps CLI, meaning your team won’t have to manually track every update or model change.

A Real-World Example: KitOps in Action

Let’s walk through how a typical company might use KitOps from development to production.

Development: Data scientists work in Jupyter notebooks, but save their work as a ModelKit at every milestone using simple KitOps commands:

kit pack . -t registry.gitlab.com/chatbot/legalchat:tuned

kit push registry.gitlab.com/chatbot/legalchat:tuned

This ensures that all models, datasets, and code are versioned and stored in a secure, centralized location.

Integration: The application team pulls the updated ModelKit:

kit pull registry.gitlab.com/chatbot/legalchat:tuned

They test service integration, paying attention to performance and any changes between model versions.

Testing: Once integration is complete, an engineer validates the model by running it with the included validation dataset:

kit unpack registry.gitlab.com/chatbot/legalchat:tuned --model --datasets

Deployment: When ready for production, the SRE team tags the ModelKit as challenger and pushes it into the CI/CD pipeline for deployment:

kit tag registry.gitlab.com/chatbot/legalchat:tuned registry.gitlab.com/chatbot/legalchat:challenger

kit push registry.gitlab.com/chatbot/legalchat:challenger

The deployment team monitors the new challenger model in production, and if it’s successful, they re-tag it as champion. If there are any issues, the previous model can be rolled back with minimal friction.

Conclusion: Why KitOps Should Be On Your Radar

Adopting AI/ML doesn’t have to mean adding new teams and infrastructure. KitOps offers a structured, secure, and scalable solution for managing the entire lifecycle of AI projects. It integrates seamlessly with existing container infrastructure, uses open standards, and provides critical security and auditing features that will help your team stay compliant and efficient.

Accelerating into AI: Lessons from AWS

Brad Micklea — Wed, 12 Jun 2024 12:17:18 +0000

One of the hallmarks of the best businesses is that they move fast, and consistently get the long-term strategy right. While running Amazon API Gateway, I was struck by the interplay between two of their leadership principles:

Bias For Action
Right, A Lot

To radically oversimplify: “when in doubt, start doing...but remember that huge impact come from getting the long term bets right.”

AWS made the early big bet that utility computing in the cloud would change the face of software and IT. They moved fast, but never lost sight of that goal and were rewarded for it. Having spent time with the people who were there in the early days, that path was hard and uncertain because the easiest answers rarely worked for what they were building - something which is always true for big changes.

I’ve been reminded of this while speaking to people about how AI is being adopted in enterprises.

The Enterprise AI Divide

Today there is a sharp divide - many organizations are taking a wait-and-see approach, but a few enterprises are building out internal AI/ML development teams that will train, tune, and manage AI models and agents tailored to their business and customers.

These companies are making a long-term bet that AI will be a market changer and that those with in-house AI skills will win. Looking at previous seismic shifts like the internet and mobility, they’re likely right.
For now, though, the road they’re walking is difficult. They’re struggling to:

Choose amongst 1,000 MLOps tools that have no standards, never work with each other, and are periodically abandoned
Find and hiring strong people in not-yet-well-defined job areas like AI research, data science, ML engineering, and MLOps
Establish processes to keep AI projects moving quickly and safely, without compromising enterprise data privacy and compliance regulations

The simpler route is to use public LLMs from OpenAI, Google, Mistral, or Perplexity and simply avoiding any use cases that touch sensitive data. That’s a reasonable place to start, but it won’t be where the best companies end up, because the greatest customer impact comes from using the deepest data.

Too Many Tools!

There are a host of reasons why companies are struggling to move AI projects out of the pilot phase, from a lack of strategic clarity, to worries about hallucinations, to a lack of tooling and talent. But according to a recent McKinsey study “too many tools” was the biggest reason.

Focus on tools with open standards; protect yourself from vendor changes.

In many cases each group, team, or division has selected a set of tools, an LLM, and started on prototypes. This is a fine way to start (after all, n solutions are better than 0 solutions), but to protect the organization there should be a focus on standards and flexibility. The hard truth is that many AI/ML tool vendors will disappear along with their tools. Focusing on standards is great protection. Unfortunately today’s crop of MLOps tools have chosen to focus on proprietary options over standards. Instead, look for solutions that let you leverage the standards in other parts of your software development chain: Terraform for infrastructure-as-code, AI project storage in your OCI registry, and open source LLMs are a good start. There are other open source projects that might help too:

Pachyderm is an open source platform for managing datasets and the workflow around their cleaning and changes.
Feast is a feature store to help teams track changes during in-house model development.
CometML and mlMLFlow are popular development and experimentation tools, although some express concerns about their proprietary and weak data storage with its lack of tamper-proof guarantees.
KitOps lets you store all your AI project artifacts (models, datasets, parameters, code, and documentation) in a tamper-proof and versionable package you can store and share through your existing OCI / container registry. It can help protect you from costly migration work if you need to change part of your toolchain.
KubeFlow simplifies the task of deploying, running, and managing ML models on Kubernetes… which you’re probably already using.

While it’s more “exciting” to focus on getting a chatbot deployed and playing with it and your data, companies that focus on building a repeatable, fast, and safe workflow will be able to learn faster, deploy faster, and beat their competitors. A solid and enterprise-approved AI project development lifecycle and toolset should be the first big milestone in any company’s journey with AI.

What separates the best is the operational maturity around the AI project.

A Framework for Selecting AI Projects

Once you have a solid foundation, then the fight about which projects to focus on begins (I know, it began long ago…). They key is prioritizing them based on customer value and risk avoidance.

I’ve used the following framework to prioritize projects because it divides potential AI use cases into four quadrants based on their customer value and organizational risk.

A Framework for Prioritizing Enterprise AI Use Cases

The X-axis focuses on your customers and the amount of value they’d get from an AI-driven use case (which in a good business equates to an increase in value for your organization).

The Y-axis is about your business and the amount of risk (severity and likelihood) that would result from a failure or problem with the AI-driven solution.
The four quadrants are:

Now: These projects have high value but low risk so start work here. You can build MVPs using hosted LLMs’ APIs, but ultimately you want this to be handled in-house - so after the MVP is launched, use these projects as a testing ground for an in-house AI team. Can they train a model that works better, faster, and cheaper?
Next: This is where your differentiation and long-term value will be unlocked. However, the risk is high so you can’t offload this to a public LLM, it will need to be built and managed in-house. This isn’t where you start, but once an in-house team has proven themselves, it’s where they need to go next.
Later: This area is dangerous because it can be a distraction and resource suck. It looks appealing because it’s easy, but the customer value is low so unless you need to do something here to keep up with a competitor (and are actually losing deals because of it), then keep teams focused on the high value projects.
Stop: The risk / value equation is wrong. Don’t touch these unless that materially changes.

Over time use cases will shift as their value or risk profile changes. Re-classify projects every 6-12 months.

For mid-to-large enterprises, most use cases will be at the top two quadrants, because valuable data is almost always sensitive. Again, these are areas where you shouldn’t be outsourcing to a public LLM because of data privacy, but also because you will be helping your competitors by training a public model that they may be using on your unique data.

Setting Up an AI Product Team

Once you decide you need an internal AI team focused on your products, how do you make it happen?

Make sure the engineering and business milestones are aligned and realistic

Before starting, ensure you have clarity on goals and milestones (I prefer writing a document to slides, but different company cultures will dictate what is best).
Define the Mission and Impact: It's important to establish clear goals that directly map them to the organization's business problems. Include what things the group won’t do that people may expect. Details matter here, so this should include metrics and milestones with dates for accountability. If time will be needed for experimentation (it often is with AI projects) then be clear what the milestones of learning will be along the way and treat them like any other deadline.

Secure Executive Sponsorship: With a strong mission and set of objectives, gaining executive support shouldn’t be difficult. However, executives are busy so practice your “pitch” and keep it short. Executives learn by asking questions to treat your pitch as a movie trailer, not as the movie and give them time to question.
Create a Roadmap: It’s tempting to do this as part of the mission and impact, but in most cases, only a high level roadmap is needed at that point. Once you have executive sponsorship your mission may shift. This roadmap should go a level or two deeper but align to the same milestones you agreed to when getting sponsorship. Classifying opportunities based on the framework above keeps things simple for stakeholders and consistent with how your team will execute.
Emphasize Agile and Iterative Approaches: AI is changing at a rapid pace and no one knows the future. Don’t give an impossible sense of determinism to your future plans, instead focus on how the team will be built to adapt and iterate quickly (faster than competitors).

Creating compelling but realistic milestones can be tricky. Below is just an example, but shows how you can mix engineering milestones (we’re going to get faster, safer, and smoother over time so we can win long-term) and business milestones (we solved a customer problem faster than expected).

Be up-front that your roadmap will need to balance engineering maturity and business impact milestones

Choosing the Organization Structure

There are several ways to set up an AI team. The best teams, regardless of their specialization, do their best work when they are connected and focused on the customer benefit. That means that they need to be close to the “edge” where the customer is.

Be up-front that your roadmap will need to balance engineering maturity and business impact milestones

Don’t over-staff a central AI team, you need “doers” close to the customer.

Centralized Model

Centralized works for small organizations with a single product, where decisions are made centrally. In this case the organization is small enough that everyone in the product organization should know the customer and their use cases, including the AI team. They should be included in key meetings not only to report on their progress, but to learn about other teams’ successes and struggles that they might learn from.

Hub and Spoke Model

Hub and Spoke is best for larger organizations where there are multiple products and customers, and where decisions are made independently. In this model there’s a natural division of responsibility:

The Spokes sit in each business area and should feel (and be treated) as a core part of that team. Their priorities should be set by the business, not the hub because they are closest to the product and customer. They are also closest to the ground and should be able to provide valuable data and insights back to the hub. There isn’t a lot of ambiguity in this realm, making it good for new and experienced team members.

The Hub provides standards and tools that will elevate every team member in the spokes. Their primary customers are the spokes so they should listen to them and enable them. This job is hard because it’s tempting for this team to try and move more and more into standards and then push those standards down. Instead, they should listen for common problems across spokes and decide if a shared solution would benefit all. The hub is also responsible for creating a consistent career path and performance expectation. There is much more ambiguity and balance needed in the hub roles so it’s a better place for more senior and experienced team members, or for people who excel in solving ambiguous problems.

One challenge with this model is that it can get "center heavy," pulling resources from the spokes which have the greatest customer impact. To prevent this, I question situations where the number of people in the hub is >30% of the number of people in the spokes because it can indicate an imbalance.

Seizing the AI Opportunity

We are in the early stages of an AI revolution in the enterprise. Organizations that take this time to work through the challenges will be rewarded with a competitive advantage in the future. OpenAI and Google might get you started, but they won’t solve your AI problems for you - it’s time to take the reins yourself.

Why enterprise AI projects are moving too slowly

Brad Micklea — Mon, 22 Apr 2024 14:49:06 +0000

In AI projects the biggest (and most solvable) source of friction are the handoffs between data scientists, application developers, testers, and infrastructure engineers as the project moves from development to production. This friction exists at every company size, in every industry, and every vertical. Gartner’s research shows that AI/ML projects are rarely deployed in under 9 months despite the use of ready-to-go large language models (LLMs) like Llama, Mistral, and Falcon.

Why do AI/ML projects move so much slower than other software projects? It’s not for lack of effort or lack of focus - it’s because of the huge amount of friction in the AI/ML development, deployment, and operations life cycle.

AI/ML isn’t just about the code

A big part of the problem is that AI/ML projects aren’t like other software projects. They have a lot of different assets that are held in different locations. Until now, there hasn't been a standard mechanism to package, version, and share these assets in a way that is accessible to data science and software teams alike. Why?

It’s tempting to think of an AI project as “just a model and some data” but it’s far more complex than that:

Model code
Adapter code
Tokenizer code
Training code
Training data
Validation data
Configuration files
Hyperparameters
Model features
Serialized models
API interface
Embedding code
Deployment definitions

Parts of this list are small and easily shared (like the code through git). But others can be massive (the datasets and serialized models), or difficult to capture and contextualize (the features or hyperparameters) for non-data science team members.

Making it worse is the variety of storage locations and lack of cross-artifact versioning:

Code in git
Datasets in DvC or cloud storage like AWS S3
Features and hyperparameters in ML training and experimentation tools
Serialized models in a container registry
Deployment definitions in separate repos

Keeping track of all these assets (which may be unique to a single model, or shared with many models) is tricky...

Which changes should an application or SRE team be aware of?

How do you track the provenance of each and ensure they weren’t accidentally or purposefully tampered with?

How do you control access and guarantee compliance?

How does each team know when to get involved?

It’s almost impossible to have good cross-team coordination and collaboration when people can’t find the project’s assets, don’t know which versions belong together, and aren’t notified of impactful changes.

I can hear you saying... “but people have been developing models for years...there must be a solution!”

Kind of. Data scientists haven't felt this issue too strongly because they all use Jupyter notebooks. But…

Jupyter notebooks are great...and terrible

Data scientists work in Jupyter notebooks because they work perfectly for experimentation.

But you can’t easily extract the code or data from a notebook, and it’s not clear for a non-data scientist where the features, parameters, weights, and biases are in the notebook. Plus, while a data scientist can run the model in the notebook on their machine, it doesn't generate a sharable and runnable model that non-data science teams can use.

Notebooks are perfect for early development by data scientists, but they are a walled garden, and one that engineers can’t use.

What about containers?

Unfortunately, getting a model that works offline on a data scientist’s machine to run in production isn’t as simple as dropping it into a container.

That’s because the model created by a data science team is best thought of as a prototype. It hasn’t been designed to work in production at scale.

For example, the features it uses may take too long to calculate in production. Or the libraries it uses may be ideally suited to the necessary iterations of development but not for the sustained load of production. Even something as simple as matching package versions in production may take hours or days of work.

We haven't even touched on the changes that are likely needed for logging and monitoring, continuous training, and deployment pipelines that include a feedback loop mechanism.

Completing the model is half the job, and if you’re waiting until the model is done to start thinking about the operational needs you’ll likely lose weeks and have to redo parts of the model development cycle several times.

Bridging the divide between data science and operations

In my previous roles at Red Hat and Amazon Web Services, I faced a dilemma familiar in many tech organizations: an organizational separation between data science and operations teams.

As much as the data scientists were wizards with data, their understanding of deploying and managing applications in a production environment was limited. Their AI projects lacked crucial production elements like packaging and integration, which led to frequent bottlenecks and frustrations when transitioning from development to deployment.

The solution was not to silo these teams but to integrate them. By embedding data scientists directly into application teams, they attended the same meetings, shared meals, and naturally understood that they (like their colleagues) were responsible for the AI project’s success in production. This made them more proactive in preparing their models for production and gave them a sense of accomplishment each time an AI project was deployed or updated.

Integrating teams not only reduces friction but enhances the effectiveness of both groups. Learning from the DevOps movement, which bridged a similar gap between software developers and IT operations, embedding data scientists within application teams eliminates the "not my problem" mindset and leads to more resilient and efficient workflows.

There’s more...

Today, there are only a few organizations that have experience putting AI projects into production. However, nearly every organization I talk to is working on developing AI projects so it’s only a matter of time before those projects will need to live in production. Sadly, most organizations aren’t ready for the problems that will come that day.

I started Jozu to help people avoid an unpleasant experience when their new AI project hits production.

Our first contribution is a free open source tool called KitOps that packages and versions AI projects into ModelKits. It uses existing standards - so you can store ModelKits in the enterprise registry you already use.

You can read more about how we see ModelKits bridging the Data Science / Software Engineering divide. Or, if you're curious to go deeper, read about how to using versioning and tagging with ModelKits to speed up and de-risk AI projects.

If you've pushed an AI project into production I'd love to hear what your experiences were and what helped / hindered.