Mono为何能跨平台？聊聊CIL(MSIL)
际粤职坦先看几个令人心动又让钱包一紧的 GPU 型号：NVIDIA A100 80GB、H800 80GB、RTX 4090 24GB...
这些 AI 时代的“超级马力”，无论我们是砸钱买断，还是花高价租用，都只能整块拿下。可除了模型训练，更多时候只是用来跑推理、开发/测试环境，几十上百 GB 的显存真的全能派上用场吗？多数情况下，你的 GPU 算力其实都在“摸鱼”，利用率可能连 20% 都不到。
在算力就是钞票的 AI 时代，GPU 闲置哪是“摸鱼”，这分明是“撒币”行为。
如果你是 AI 团队的 Leader，一边要交代高昂算力开销，一边还要安抚抱怨“GPU 不够、流程太慢”的团队成员，是不是早已身心俱疲？
如果你是 MLOps 或平台工程师，每天盯着 GPU 集群利用率长期低于 20%，还得处理各种“抢资源”工单，是不是觉得自己的技术没用在刀刃上？
如果你是 AI 算法工程师，只是想跑个预处理、验证模型、调试代码，却要为一张被“霸占”却没被用满的 A100/H800 排队数小时，灵感都快被磨光了吧？
别急，今天的主角——HAMi，就是你的“开源解药”！
GitHub 地址：github.com/Project-HAMi/HAMi
简单来说，HAMi 是由上海密瓜智能发起的，面向 K8s 的异构 AI 计算虚拟化中间件。它的核心能力，就是像切蛋糕一样，把一整块物理 GPU 灵活切分为多块虚拟 GPU（vGPU），并按需分配给不同业务（Pod），实现算力的精细化共享与隔离。
最关键的是，你的 AI 应用代码，一行都不用改！
一、GPU 共享的两个“陷阱”，为何需要 HAMi？
要理解 HAMi 的价值，我们首先要明白一块 GPU 包含了两种核心资源：显存 (Memory) 和计算核心 (Compute Cores)。在没有管理机制的“原生共享”模式下，这两种资源都会陷入困境：
显存的“独占性”（OOM 问题）：GPU 显存是一个“硬性资源”。一个程序启动时，必须先申请到足够的显存空间来加载模型和数据。在原生共享模式下，这就是一场“先到先得”的游戏。
算力的“混沌竞争”（性能问题）：即便多个任务都成功挤进了显存，它们接下来也要争抢有限的算力核心。这就像一场没有规则的“大乱斗”。一个计算密集型任务可能会在某个瞬间霸占几乎所有的计算资源，导致其他任务被“饿死”，响应变得极慢。
面对以上两个陷阱，HAMi 提供了精准且优雅的解决方案。它能同时对显存和算力进行精细化切分和管理：
对于显存：实现“硬性隔离”
HAMi 会为每个任务划分出一段完全独立的、大小固定的虚拟显存空间。每个任务只能在自己的“包间”里活动，彻底杜绝了因某个任务过度占用而导致其他任务无法启动的 OOM 问题。
对于算力：实现按比例分配
HAMi 允许你为每个任务分配特定比例的算力（例如，为 A 任务（pod）分配 30% 的算力，B 任务 50%）。确保每个任务都能获得其应有的计算资源，从而保障性能的稳定和可预期，告别“性能抖动”。
总结一下，HAMi 可以将 GPU 从一个混乱、不可预测的“公共资源”，转变为多个独立、稳定、可度量的“私有资源”，这就是它实现 GPU 高效利用的核心所在。
搞懂了这一点，我们再来看 HAMi 在 K8s 里的操作，你就会觉得豁然开朗。
二、三步搞定，简单到不像话！
在我们熟悉的 K8s 环境里，GPU 一直是个“倔强的老顽固”——一个 Pod 就得独占一整张卡，申请 GPU 资源也只能按“卡”来。
但 HAMi 的出现，彻底改变了这一游戏规则。
有了 HAMi，你可以像点菜一样，随心为 AI 应用选配告别 GPU 资源浪费，比如「1GB 显存、30% 算力」。
别看功能这么牛，但安装 HAMi 却超级简单。它就像 K8s 的即插即用扩展包，用 Helm 工具三条命令搞定：
# 1. 先给你有 GPU 的机器打个标签，让 HAMi 认识它
kubectl label nodes {nodeid} gpu=on
# 2. 添加 HAMi 的官方“菜单”
helm repo add hami-charts https://project-hami.github.io/HAMi/
# 3. 下单安装！
helm install hami hami-charts/hami -n kube-system
搞定！看到 hami-device-plugin 和 hami-scheduler 这两个 Pod 都正常地 Running 起来，就说明你已经成功化身“GPU 管理大师”了。
以后，你就可以用下面的配置，为你的 AI 应用轻松+愉快地申请任意大小的 vGPU 了。
apiVersion: v1
kind: Pod
metadata:
name: gpu-pod
spec:
containers:
- name: ubuntu-container
image: ubuntu:18.04
command: ["bash", "-c", "sleep 86400"]
resources:
limits:
nvidia.com/gpu: 1 # 申请 1 个 vGPU
nvidia.com/gpumem: 1024 # 每个 vGPU 包含 1024MB 设备内存
nvidia.com/gpucores: 30 # 每个 vGPU 分配 30% 的计算核心
此外，官方还贴心地准备了可视化界面 HAMi-WebUI，让摸鱼的 GPU 无所遁形！
三、揭秘 HAMi 技术核心，个人开发者也能玩转！
你肯定好奇，HAMi 到底用了什么黑科技，竟然能瞒天过海，“骗”过 CUDA，让程序觉得自己拥有一整块 GPU？
答案全在它的核心武器：HAMi-core。
这玩意儿的原理，说白了，就是“欺上瞒下”的高级玩法。
3.1 HAMi 核心原理
HAMi-core 本质上是一个实现了 CUDA API Hook（钩子）的动态链接库 (libvgpu.so)。它的工作原理非常巧妙，也十分经典：
如上图所示，它通过 LD_PRELOAD 环境变量，在你的应用程序和真正的 CUDA 驱动之间“插入”了自己。当你的程序调用一个 CUDA API（比如申请显存）时，HAMi-core 会先“劫持”这个请求，然后根据你设置的限制（比如 2GB 显存）进行判断和管理，最后再把一个“修改过”的请求或者一个“虚拟”的响应回传给你的程序。
整个过程，你的程序和驱动都被蒙在鼓里，还以为对方是原装的。就靠这手“瞒天过海”，它轻松实现了显存虚拟化、算力限制和用量监控。
3.2 本地体验 GPU 虚拟化
这个设计的精髓在于，HAMi-core 完全可以脱离 K8s 单飞！这意味着，在你自己的电脑上，用 Docker 就能体验到 GPU 精准分配的快乐！
这对于想在单张卡上模拟多环境测试的个人开发者来说，简直太实用了！
假设你的显卡是 12G，我们切个 2G 的 vGPU 出来玩玩。
第一步：构建包含 HAMi-core 的镜像
# 在 HAMi-core 项目里，用官方 Dockerfile 构建一个新镜像
docker build . -f=dockerfiles/Dockerfile -t cuda_vmem:tf1.8-cu90
第二步：准备 Docker 运行所需的环境变量
# 把英伟达驱动、工具啥的都准备好挂载进去
export DEVICE_MOUNTS="..."
export LIBRARY_MOUNTS="..."
第三步：运行容器并应用 vGPU 限制！
最关键的一步来了，通过环境变量“激活”我们的 GPU 管家：
docker run ${LIBRARY_MOUNTS} ${DEVICE_MOUNTS} -it \
-e CUDA_DEVICE_MEMORY_LIMIT=2g \
-e LD_PRELOAD=/libvgpu/build/libvgpu.so \
cuda_vmem:tf1.8-cu90
当你在容器里敲下 nvidia-smi 并回车，你会看到……
总显存不多不少，正好是我们设定的 2048MB！在这个容器里，任何程序都休想突破这个“结界”。是不是泰酷辣！
四、为什么说 HAMi 是 AI 算力的“必选项”？
看到这里，你应该明白了，HAMi 代表了一种更聪明、更高效的算力利用方式。
降本增效，立竿见影：GPU 利用率大幅提升，让本只能跑一个任务的显卡，轻松承载更多任务，资源价值直接翻倍。
国产芯的“瑞士军刀”：不止支持英伟达，HAMi 还兼容寒武纪、海光、昇腾等众多国产 AI 芯片。在信创大潮下，战略价值不言而喻。
出身名门，CNCF 认证：作为 CNCF 官方沙箱项目，HAMi 拥有云原生世界的“正统身份”，稳定性和社区支持有保障，选它更安心。
久经沙场，巨头验证：顺丰、AWS 等国内外头部企业都已在生产环境深度应用，早已证明 HAMi 不是“玩具”，是真正能打的“正规军”。
五、最后
在 AI 大模型“军备竞赛”白热化的今天，谁能把算力用得更精、更省，谁就掌握了未来的主动权。HAMi 正是为此而生的一把“瑞士军刀”，它优雅、无感，却能实实在在地帮你把钱花在刀刃上。
最后，别再让你的 GPU 继续摸鱼了，给它上点强度吧！
GitHub 地址：github.com/Project-HAMi/HAMi
社区动态：HAMi 2.7.0 重磅发布
开源不易，期待你的 Star 支持！
作者：削微寒
扫描左侧的二维码可以联系到我
知识共享许可协议
本作品采用署名-非商业性使用-禁止演绎 4.0 国际 进行许可。
好文要顶 关注我 收藏该文 微信分享
削微寒
粉丝 - 4516 关注 - 14
推荐博客
+加关注
63
升级成为会员
? 上一篇： 《HelloGitHub》第 114 期
? 下一篇： DIY ChatGPT 一周狂揽 27k Star「GitHub 热点速览」
posted @ 2025-10-14 08:19 削微寒 阅读(1508) 评论(3) 收藏 举报
刷新页面返回顶部
登录后才能查看或发表评论，立即 登录 或者 逛逛 博客园首页
【推荐】博客园&小马算力达成战略合作，为开发者注入“算力引擎”
【推荐】鸿蒙应用开发者激励计划，开发上架应用，现金激励超亿元！
【推荐】2025 HarmonyOS 创新赛正式启动，百万大奖等你来挑战！
【推荐】天翼云智惠上云月，爆款云主机2核2G只要18.8元/3个月起
【推荐】帮园友公司招聘，杭州吉合信科技诚聘 Java 全栈开发工程师
编辑推荐：
史诗级警报：ASP.NET Core 被曝 CVSS 9.9 分漏洞
一个轻量级C++内存监控及可视化开源库
EF Core: FromExpression 方法有什么用？
深度学习优化器算法巧思速览
如何在 Spring Boot 应用中配置多个 Spring AI 的 LLM 客户端
HarmonyOS专区：
开发上架鸿蒙应用，现金激励超亿元！
前端转鸿蒙开发几个比较难受的地方
闯入鸿蒙：浪漫、理想与「草台班子」
3天赚2万！开发者的梦想也可以掷地有声！
Flutter 适配 HarmonyOS 5 开发知识地图
历史上的今天：
2021-10-14 桀骜不驯的代码又搞事情？我找来 10 个开源项目帮你驯服它们！
公告
test
昵称： 削微寒
园龄： 10年5个月
荣誉： 推荐博客
粉丝： 4516
关注： 14
+加关注
积分与排名
积分 - 1702608
排名 - 133
随笔分类
git(17)
GitHub 热点速递(125)
HelloDjango(48)
HelloGitHub(154)
HelloVue(3)
HelloZooKeeper(14)
linux(24)
OneFile(2)
Python(40)
Python Web(17)
SQL和MySQL(17)
VS Code(2)
大数据(5)
翻译(24)
感悟(4)
更多
随笔档案
2025年10月(2)
2025年9月(4)
2025年8月(4)
2025年7月(4)
2025年6月(3)
2025年5月(4)
2025年4月(4)
2025年3月(4)
2025年2月(4)
2025年1月(4)
2024年12月(6)
2024年11月(4)
2024年10月(4)
2024年9月(4)
2024年8月(4)
更多
阅读排行榜
1. [Python]新手写爬虫全过程（已完成）(191847)
2. [python]pip常用命令（转载）(121277)
3. [git]merge和rebase的区别(115995)
4. supervisor 安装、配置、常用命令(101045)
5. python转义字符——重点解释：\b,\n和\r区别