Explore a complete MLOps workflow using → KitOps for model packaging → Cog for local testing → KAITO for scalable Kubernetes deployment read full article! cncf.io/blog/2025/07/26/stan…

Running AI workloads on Kubernetes? The scheduling part works fine. It's the GPU utilization and artifact management that breaks everything. Typical inference workload uses 20-40% of GPU compute and maybe 30 GiB memory. But Kubernetes Device Plugin only reports integer device counts. So nvidia/gpu: 1 means you get the entire H100, and every other workload waits. NVIDIA Time-Slicing lets multiple Pods share, but there's no VRAM isolation. One Pod OOMs, everything crashes. MIG works but only on A100/H100, and you're stuck with fixed partition sizes. Then there's the artifact problem. Which model version is deployed? Does config.json match the weights? Can this move through CI/CD without manual file transfers? I came across @HAMiProject + @Kit_Ops tutorial, and the pattern actually makes sense. HAMi handles GPU virtualization through CUDA API interception. No driver changes, no app changes. It exposes nvidia/gpu, nvidia/gpumem, and nvidia/gpucores as schedulable resources. One H100 becomes 10 vGPUs. Your Pod requests 30 GiB, gets scheduled, and can only see that allocation. Over-allocation returns OOM without crashing other workloads. KitOps handles artifact packaging. Models, datasets, configs, code → stored as OCI artifacts in the same registry you use for containers. The ModelKit gets pulled by an initContainer, unpacked into a flat directory, and the inference engine loads it from local disk. Registry-native supply chain, version controlled, reproducible. The lab workflow: → Pull Qwen3-4B-Instruct ModelKit from Jozu Hub → Unpack with kitunpacker initContainer → Schedule Pod with HAMi GPU shares (30 GiB memory) → Serve with SGLang → Optionally co-locate vLLM on same physical GPU Everything moves through standard K8s patterns. No one-off scripts, no S3 bucket coordination, no guessing which version is actually running. Useful if you're running LLMs in production and trying to avoid building custom deployment infrastructure.

Another guide with @rudrakshkarpe also in the works using @Kit_Ops to serve models with modelkits and serve them using @HAMiProject thus providing a safe way to securely get signed models with verifiable identity github.com/Project-HAMi/webs…

@Kit_Ops + @HAMiProject brings together two important pieces of the production inference stack. ModelKits make model packaging and distribution portable, while HAMi enables efficient GPU sharing and resource isolation on @kubernetesio Excited to see this lab coming up!

Great tutorial for a collaboration between two @cncf projects @HAMiProject <> @Kit_Ops Kudos to @rudrakshkarpe as the co-author for this one, and we shared this during @KubeCon_ India

HAMi lab worth bookmarking: ModelKit → `kit unpack` in an initContainer → SGLang/vLLM on HAMi GPU shares. ~60 min · Jul 2026 project-hami.io/tutorials/la… Sample uses Jozu Hub; any OCI registry works the same way.

MCP servers and agent skills are still being shared as ZIP files and GitHub links. That's a problem. These change what agents can access and how they behave. They need the same controls as production code: versioning, provenance, signing, and rollback. @Kit_Ops v1.13 lets teams package skills as OCI-based ModelKits, govern them in @Jozu_AI Hub, and install approved versions directly: kit unpack <modelkit> --as-skill Quick demo 👇

Weekend spent with #CloudNative Kolkata! Technology may evolve rapidly, but communities are what turn ideas into impact 🚀 Discussed about @Kit_Ops and ModelKit addresses a fundamental challenge for ML/Data Scientists — making AI projects reproducible, portable to share! #meetup

We're securing AI agents at the wrong layer. A 2026 review of 85 agent-security papers found 66% focus on perception attacks like prompt injection and jailbreaks. Only 4.7% study what happens when an agent actually takes action. That's the problem. Prompt injection is only dangerous because of what it makes an agent do: Read a database. Run code. Call a tool. Delete a file. Move money. So the better question isn't: "Can I stop the agent from being manipulated?" It's: "If it gets manipulated, what can it actually do?" That shifts security from trying to make agents impossible to fool to making them safe to operate. → Least privilege → Scoped tools → Runtime policies → Signed artifacts → Human approval for high-risk actions The model will make mistakes. The real security boundary is what happens after.

The interesting shift in AI security: the threat is no longer just the model. OWASP's 2026 agentic security work shows real incidents across goal hijacking, tool misuse, identity abuse, supply-chain attacks, and unexpected code execution. We're already seeing agents escape test environments and interact with real systems without explicit human direction. That changes how you think about agent security. You don't just need to secure what an agent knows. You need to control what it can do. That means: → Verify the agent and its dependencies before execution → Control individual tool calls at runtime → Enforce least privilege → Keep an audit trail of every decision @Jozu_AI is building Agent Guard for this: a zero-trust runtime that scans and signs agents, MCP servers and models, then enforces policy at both admission and runtime. Agentic AI is moving from "generate an answer" to "take an action." Security needs to catch up.

Jozu just launched Agent Guard → a zero-trust runtime for AI coding agents and MCP (Claude Code, etc). Most agent guardrails today run in user-space. So if the agent can access the same host processes/filesystem, a bypass is always on the table. @Jozu_AI Agent Guard 👉 hypervisor isolation + policy enforcement at runtime. What that means in practice: → agent runs in a hypervisor-isolated container → it only sees the workspace you explicitly share → host FS, processes, SSH keys, creds stay inaccessible → only supply-chain-verified artifacts get in → policies are tamper-evident + enforced on every action → policy server runs as PID 1 (agent can’t kill it) If your agent touches real credentials or prod-adjacent workflows, this is worth a look. I'll explore it in more details soon!

We just ran @opencode with @Jozu_AI Rapid Inference Containers. Opencode supports local models, and we used the 4-bit quantized GGUF version of Qwen3.5-9B. Jozu RIC is even faster than @nvidia NIM in benchmarks. In one test, NIM took 239.2 seconds, while RIC took only 42.8 seconds. With Jozu secure packaging, speed, and deployment, anyone can run critical workloads on their infra more easily. Jozu also enables 7x faster model deployment with a proper audit trail. Full tutorial coming soon!

When working with DevOps projects, I can't see myself using anything but @warpdotdev. It works like a charm at fixing annoying kubectl bugs. POV: Running a demo showing how to integrate @Kit_Ops with KServe

200k+ KitOps downloads so far🔥

Year end community call at @Kit_Ops 🔥 Streaming on @Jozu_AI YT now! Watch👇

Kudos To 200k @Kit_Ops

The KitOps Project wrap is here! 🎉 Huge shoutout to @SaiyamPathak and @kubesimplify for building such an awesome project. Thanks to everyone who supported KitOps along the way!