[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"similar-4paradigm--k8s-vgpu-scheduler":3,"tool-4paradigm--k8s-vgpu-scheduler":64},[4,17,27,35,43,56],{"id":5,"name":6,"github_repo":7,"description_zh":8,"stars":9,"difficulty_score":10,"last_commit_at":11,"category_tags":12,"status":16},3808,"stable-diffusion-webui","AUTOMATIC1111\u002Fstable-diffusion-webui","stable-diffusion-webui 是一个基于 Gradio 构建的网页版操作界面，旨在让用户能够轻松地在本地运行和使用强大的 Stable Diffusion 图像生成模型。它解决了原始模型依赖命令行、操作门槛高且功能分散的痛点，将复杂的 AI 绘图流程整合进一个直观易用的图形化平台。\n\n无论是希望快速上手的普通创作者、需要精细控制画面细节的设计师，还是想要深入探索模型潜力的开发者与研究人员，都能从中获益。其核心亮点在于极高的功能丰富度：不仅支持文生图、图生图、局部重绘（Inpainting）和外绘（Outpainting）等基础模式，还独创了注意力机制调整、提示词矩阵、负向提示词以及“高清修复”等高级功能。此外，它内置了 GFPGAN 和 CodeFormer 等人脸修复工具，支持多种神经网络放大算法，并允许用户通过插件系统无限扩展能力。即使是显存有限的设备，stable-diffusion-webui 也提供了相应的优化选项，让高质量的 AI 艺术创作变得触手可及。",162132,3,"2026-04-05T11:01:52",[13,14,15],"开发框架","图像","Agent","ready",{"id":18,"name":19,"github_repo":20,"description_zh":21,"stars":22,"difficulty_score":23,"last_commit_at":24,"category_tags":25,"status":16},1381,"everything-claude-code","affaan-m\u002Feverything-claude-code","everything-claude-code 是一套专为 AI 编程助手（如 Claude Code、Codex、Cursor 等）打造的高性能优化系统。它不仅仅是一组配置文件，而是一个经过长期实战打磨的完整框架，旨在解决 AI 代理在实际开发中面临的效率低下、记忆丢失、安全隐患及缺乏持续学习能力等核心痛点。\n\n通过引入技能模块化、直觉增强、记忆持久化机制以及内置的安全扫描功能，everything-claude-code 能显著提升 AI 在复杂任务中的表现，帮助开发者构建更稳定、更智能的生产级 AI 代理。其独特的“研究优先”开发理念和针对 Token 消耗的优化策略，使得模型响应更快、成本更低，同时有效防御潜在的攻击向量。\n\n这套工具特别适合软件开发者、AI 研究人员以及希望深度定制 AI 工作流的技术团队使用。无论您是在构建大型代码库，还是需要 AI 协助进行安全审计与自动化测试，everything-claude-code 都能提供强大的底层支持。作为一个曾荣获 Anthropic 黑客大奖的开源项目，它融合了多语言支持与丰富的实战钩子（hooks），让 AI 真正成长为懂上",138956,2,"2026-04-05T11:33:21",[13,15,26],"语言模型",{"id":28,"name":29,"github_repo":30,"description_zh":31,"stars":32,"difficulty_score":23,"last_commit_at":33,"category_tags":34,"status":16},2271,"ComfyUI","Comfy-Org\u002FComfyUI","ComfyUI 是一款功能强大且高度模块化的视觉 AI 引擎，专为设计和执行复杂的 Stable Diffusion 图像生成流程而打造。它摒弃了传统的代码编写模式，采用直观的节点式流程图界面，让用户通过连接不同的功能模块即可构建个性化的生成管线。\n\n这一设计巧妙解决了高级 AI 绘图工作流配置复杂、灵活性不足的痛点。用户无需具备编程背景，也能自由组合模型、调整参数并实时预览效果，轻松实现从基础文生图到多步骤高清修复等各类复杂任务。ComfyUI 拥有极佳的兼容性，不仅支持 Windows、macOS 和 Linux 全平台，还广泛适配 NVIDIA、AMD、Intel 及苹果 Silicon 等多种硬件架构，并率先支持 SDXL、Flux、SD3 等前沿模型。\n\n无论是希望深入探索算法潜力的研究人员和开发者，还是追求极致创作自由度的设计师与资深 AI 绘画爱好者，ComfyUI 都能提供强大的支持。其独特的模块化架构允许社区不断扩展新功能，使其成为当前最灵活、生态最丰富的开源扩散模型工具之一，帮助用户将创意高效转化为现实。",107662,"2026-04-03T11:11:01",[13,14,15],{"id":36,"name":37,"github_repo":38,"description_zh":39,"stars":40,"difficulty_score":23,"last_commit_at":41,"category_tags":42,"status":16},3704,"NextChat","ChatGPTNextWeb\u002FNextChat","NextChat 是一款轻量且极速的 AI 助手，旨在为用户提供流畅、跨平台的大模型交互体验。它完美解决了用户在多设备间切换时难以保持对话连续性，以及面对众多 AI 模型不知如何统一管理的痛点。无论是日常办公、学习辅助还是创意激发，NextChat 都能让用户随时随地通过网页、iOS、Android、Windows、MacOS 或 Linux 端无缝接入智能服务。\n\n这款工具非常适合普通用户、学生、职场人士以及需要私有化部署的企业团队使用。对于开发者而言，它也提供了便捷的自托管方案，支持一键部署到 Vercel 或 Zeabur 等平台。\n\nNextChat 的核心亮点在于其广泛的模型兼容性，原生支持 Claude、DeepSeek、GPT-4 及 Gemini Pro 等主流大模型，让用户在一个界面即可自由切换不同 AI 能力。此外，它还率先支持 MCP（Model Context Protocol）协议，增强了上下文处理能力。针对企业用户，NextChat 提供专业版解决方案，具备品牌定制、细粒度权限控制、内部知识库整合及安全审计等功能，满足公司对数据隐私和个性化管理的高标准要求。",87618,"2026-04-05T07:20:52",[13,26],{"id":44,"name":45,"github_repo":46,"description_zh":47,"stars":48,"difficulty_score":23,"last_commit_at":49,"category_tags":50,"status":16},2268,"ML-For-Beginners","microsoft\u002FML-For-Beginners","ML-For-Beginners 是由微软推出的一套系统化机器学习入门课程，旨在帮助零基础用户轻松掌握经典机器学习知识。这套课程将学习路径规划为 12 周，包含 26 节精炼课程和 52 道配套测验，内容涵盖从基础概念到实际应用的完整流程，有效解决了初学者面对庞大知识体系时无从下手、缺乏结构化指导的痛点。\n\n无论是希望转型的开发者、需要补充算法背景的研究人员，还是对人工智能充满好奇的普通爱好者，都能从中受益。课程不仅提供了清晰的理论讲解，还强调动手实践，让用户在循序渐进中建立扎实的技能基础。其独特的亮点在于强大的多语言支持，通过自动化机制提供了包括简体中文在内的 50 多种语言版本，极大地降低了全球不同背景用户的学习门槛。此外，项目采用开源协作模式，社区活跃且内容持续更新，确保学习者能获取前沿且准确的技术资讯。如果你正寻找一条清晰、友好且专业的机器学习入门之路，ML-For-Beginners 将是理想的起点。",84991,"2026-04-05T10:45:23",[14,51,52,53,15,54,26,13,55],"数据工具","视频","插件","其他","音频",{"id":57,"name":58,"github_repo":59,"description_zh":60,"stars":61,"difficulty_score":10,"last_commit_at":62,"category_tags":63,"status":16},3128,"ragflow","infiniflow\u002Fragflow","RAGFlow 是一款领先的开源检索增强生成（RAG）引擎，旨在为大语言模型构建更精准、可靠的上下文层。它巧妙地将前沿的 RAG 技术与智能体（Agent）能力相结合，不仅支持从各类文档中高效提取知识，还能让模型基于这些知识进行逻辑推理和任务执行。\n\n在大模型应用中，幻觉问题和知识滞后是常见痛点。RAGFlow 通过深度解析复杂文档结构（如表格、图表及混合排版），显著提升了信息检索的准确度，从而有效减少模型“胡编乱造”的现象，确保回答既有据可依又具备时效性。其内置的智能体机制更进一步，使系统不仅能回答问题，还能自主规划步骤解决复杂问题。\n\n这款工具特别适合开发者、企业技术团队以及 AI 研究人员使用。无论是希望快速搭建私有知识库问答系统，还是致力于探索大模型在垂直领域落地的创新者，都能从中受益。RAGFlow 提供了可视化的工作流编排界面和灵活的 API 接口，既降低了非算法背景用户的上手门槛，也满足了专业开发者对系统深度定制的需求。作为基于 Apache 2.0 协议开源的项目，它正成为连接通用大模型与行业专有知识之间的重要桥梁。",77062,"2026-04-04T04:44:48",[15,14,13,26,54],{"id":65,"github_repo":66,"name":67,"description_en":68,"description_zh":69,"ai_summary_zh":69,"readme_en":70,"readme_zh":71,"quickstart_zh":72,"use_case_zh":73,"hero_image_url":74,"owner_login":75,"owner_name":76,"owner_avatar_url":77,"owner_bio":78,"owner_company":79,"owner_location":79,"owner_email":79,"owner_twitter":79,"owner_website":80,"owner_url":81,"languages":82,"stars":106,"forks":107,"last_commit_at":108,"license":109,"difficulty_score":110,"env_os":111,"env_gpu":112,"env_ram":113,"env_deps":114,"category_tags":125,"github_topics":79,"view_count":23,"oss_zip_url":79,"oss_zip_packed_at":79,"status":16,"created_at":126,"updated_at":127,"faqs":128,"releases":163},3233,"4paradigm\u002Fk8s-vgpu-scheduler","k8s-vgpu-scheduler","OpenAIOS vGPU device plugin for Kubernetes is originated from the OpenAIOS project to virtualize GPU device memory, in order to allow applications to access larger memory space than its physical capacity. It is designed for ease of use of extended device memory for AI workloads.","k8s-vgpu-scheduler（现更名为 Project-HAMi）是一款专为 Kubernetes 集群设计的 GPU 资源管理调度器。它旨在解决传统模式下 GPU 必须整卡分配导致的资源浪费问题，特别适用于显存和算力利用率较低的场景，如多模型推理服务、教学环境或云端小实例部署。\n\n该工具主要面向需要在 K8s 上高效运行 AI 工作负载的开发者、运维工程师及研究人员。其核心亮点在于实现了细粒度的 GPU 资源共享：用户不再受限于独占整张显卡，而是可以按需申请特定的显存大小（如 3000MB）或算力比例。此外，k8s-vgpu-scheduler 支持“虚拟显存”技术，允许利用主机内存作为交换空间，使任务能够突破物理显存限制，从而运行更大批量的模型训练或容纳更多并发任务。\n\n安装后，无需修改现有的任务配置文件即可自动启用增强功能，同时支持指定使用或避开特定类型的 GPU 设备。通过智能调度算法，它还能在多个 GPU 节点间平衡负载，显著提升集群整体的资源利用率和经济性，是让 AI 基础设施更灵活、高效的关键组件。","English version|[中文版](README_cn.md)\n\n# OpenAIOS vGPU scheduler for Kubernetes\n\n[![build status](https:\u002F\u002Fgithub.com\u002FProject-HAMi\u002FHAMi\u002Factions\u002Fworkflows\u002Fmain.yml\u002Fbadge.svg)](https:\u002F\u002Fgithub.com\u002F4paradigm\u002Fk8s-vgpu-scheduler\u002Factions\u002Fworkflows\u002Fmain.yml)\n[![docker pulls](https:\u002F\u002Fimg.shields.io\u002Fdocker\u002Fpulls\u002F4pdosc\u002Fk8s-vgpu.svg)](https:\u002F\u002Fhub.docker.com\u002Fr\u002F4pdosc\u002Fk8s-vgpu)\n[![slack](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FSlack-Join%20Slack-blue)](https:\u002F\u002Fjoin.slack.com\u002Ft\u002Fk8s-device-plugin\u002Fshared_invite\u002Fzt-oi9zkr5c-LsMzNmNs7UYg6usc0OiWKw)\n[![discuss](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FDiscuss-Ask%20Questions-blue)](https:\u002F\u002Fgithub.com\u002F4paradigm\u002Fk8s-device-plugin\u002Fdiscussions)\n[![Contact Me](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FContact%20Me-blue)](https:\u002F\u002Fgithub.com\u002F4paradigm\u002Fk8s-vgpu-scheduler#contact)\n\n## Supperted devices\n\n[![nvidia GPU](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FNvidia-GPU-blue)](https:\u002F\u002Fgithub.com\u002F4paradigm\u002Fk8s-vgpu-scheduler#preparing-your-gpu-nodes)\n[![cambricon MLU](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FCambricon-Mlu-blue)](docs\u002Fcambricon-mlu-support.md)\n[![hygon DCU](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FHygon-DCU-blue)](docs\u002Fhygon-dcu-support.md)\n\n\n> **Note** This project has beed renamed to [project-HAMi](https:\u002F\u002Fgithub.com\u002FProject-HAMi\u002FHAMi), We reserve old repo here for compatable reasons \n\n## Introduction\n\n**4paradigm k8s vGPU scheduler is an \"all in one\" chart to manage your GPU in k8s cluster**, it has everything you expect for a k8s GPU manager, including:\n\n***GPU sharing***: Each task can allocate a portion of GPU instead of a whole GPU card, thus GPU can be shared among multiple tasks.\n\n***Device Memory Control***: GPUs can be allocated with certain device memory size (i.e 3000M) or device memory percentage of whole GPU(i.e 50%) and have made it that it does not exceed the boundary.\n\n***Virtual Device memory***: You can oversubscribe GPU device memory by using host memory as its swap.\n\n***GPU Type Specification***: You can specify which type of GPU to use or to avoid for a certain GPU task, by setting \"nvidia.com\u002Fuse-gputype\" or \"nvidia.com\u002Fnouse-gputype\" annotations. \n\n***Easy to use***: You don't need to modify your task yaml to use our scheduler. All your GPU jobs will be automatically supported after installation. In addition, you can specify your resource name other than \"nvidia.com\u002Fgpu\" if you wish\n\nThe **k8s vGPU scheduler** is based on retaining features of 4paradigm k8s-device-plugin ([4paradigm\u002Fk8s-device-plugin](https:\u002F\u002Fgithub.com\u002F4paradigm\u002Fk8s-device-plugin)), such as splitting the physical GPU, limiting the memory, and computing unit. It adds the scheduling module to balance the GPU usage across GPU nodes. In addition, it allows users to allocate GPU by specifying the device memory and device core usage. Furthermore, the vGPU scheduler can virtualize the device memory (the used device memory can exceed the physical device memory), run some tasks with large device memory requirements, or increase the number of shared tasks. You can refer to [the benchmarks report](#benchmarks).\n\n## When to use\n\n1. Scenarios when pods need to be allocated with certain device memory usage or device cores.\n2. Needs to balance GPU usage in cluster with mutiple GPU node\n3. Low utilization of device memory and computing units, such as running 10 tf-servings on one GPU.\n4. Situations that require a large number of small GPUs, such as teaching scenarios where one GPU is provided for multiple students to use, and the cloud platform that provides small GPU instance.\n5. In the case of insufficient physical device memory, virtual device memory can be turned on, such as training of large batches and large models.\n\n## Prerequisites\n\nThe list of prerequisites for running the NVIDIA device plugin is described below:\n* NVIDIA drivers >= 384.81\n* nvidia-docker version > 2.0\n* Kubernetes version >= 1.16\n* glibc >= 2.17\n* kernel version >= 3.10\n* helm > 3.0\n\n## Quick Start\n\n### Preparing your GPU Nodes\nThe following steps need to be executed on all your GPU nodes.\nThis README assumes that the NVIDIA drivers and the `nvidia-container-toolkit` have been pre-installed.\nIt also assumes that you have configured the `nvidia-container-runtime` as the default low-level runtime to use.\n\nPlease see: https:\u002F\u002Fdocs.nvidia.com\u002Fdatacenter\u002Fcloud-native\u002Fcontainer-toolkit\u002Finstall-guide.html\n\n#### Example for debian-based systems with `docker` and `containerd`\n\n##### Install the `nvidia-container-toolkit`\n```bash\ndistribution=$(. \u002Fetc\u002Fos-release;echo $ID$VERSION_ID)\ncurl -s -L https:\u002F\u002Fnvidia.github.io\u002Flibnvidia-container\u002Fgpgkey | sudo apt-key add -\ncurl -s -L https:\u002F\u002Fnvidia.github.io\u002Flibnvidia-container\u002F$distribution\u002Flibnvidia-container.list | sudo tee \u002Fetc\u002Fapt\u002Fsources.list.d\u002Flibnvidia-container.list\n\nsudo apt-get update && sudo apt-get install -y nvidia-container-toolkit\n```\n\n##### Configure `docker`\nWhen running `kubernetes` with `docker`, edit the config file which is usually\npresent at `\u002Fetc\u002Fdocker\u002Fdaemon.json` to set up `nvidia-container-runtime` as\nthe default low-level runtime:\n```json\n{\n    \"default-runtime\": \"nvidia\",\n    \"runtimes\": {\n        \"nvidia\": {\n            \"path\": \"\u002Fusr\u002Fbin\u002Fnvidia-container-runtime\",\n            \"runtimeArgs\": []\n        }\n    }\n}\n```\nAnd then restart `docker`:\n```\n$ sudo systemctl daemon-reload && systemctl restart docker\n```\n\n##### Configure `containerd`\nWhen running `kubernetes` with `containerd`, edit the config file which is\nusually present at `\u002Fetc\u002Fcontainerd\u002Fconfig.toml` to set up\n`nvidia-container-runtime` as the default low-level runtime:\n```\nversion = 2\n[plugins]\n  [plugins.\"io.containerd.grpc.v1.cri\"]\n    [plugins.\"io.containerd.grpc.v1.cri\".containerd]\n      default_runtime_name = \"nvidia\"\n\n      [plugins.\"io.containerd.grpc.v1.cri\".containerd.runtimes]\n        [plugins.\"io.containerd.grpc.v1.cri\".containerd.runtimes.nvidia]\n          privileged_without_host_devices = false\n          runtime_engine = \"\"\n          runtime_root = \"\"\n          runtime_type = \"io.containerd.runc.v2\"\n          [plugins.\"io.containerd.grpc.v1.cri\".containerd.runtimes.nvidia.options]\n            BinaryName = \"\u002Fusr\u002Fbin\u002Fnvidia-container-runtime\"\n```\nAnd then restart `containerd`:\n```\n$ sudo systemctl daemon-reload && systemctl restart containerd\n```\n\nThen, you need to label your GPU nodes which can be scheduled by 4pd-k8s-scheduler by adding \"gpu=on\", otherwise, it cannot be managed by our scheduler.\n\n```\nkubectl label nodes {nodeid} gpu=on\n```\n\n### Enabling vGPU Support in Kubernetes\n\nFirst, you need to heck your Kubernetes version by the using the following command\n\n```\nkubectl version\n```\n\nThen, add our repo in helm\n\n```\nhelm repo add vgpu-charts https:\u002F\u002F4paradigm.github.io\u002Fk8s-vgpu-scheduler\n```\n\nYou need to set the Kubernetes scheduler image version according to your Kubernetes server version during installation. For example, if your cluster server version is 1.16.8, then you should use the following command for deployment\n\n```\nhelm install vgpu vgpu-charts\u002Fvgpu --set scheduler.kubeScheduler.imageTag=v1.16.8 -n kube-system\n```\n\nYou can customize your installation by adjusting [configs](docs\u002Fconfig.md).\n\nYou can verify your installation by the following command:\n\n```\n$ kubectl get pods -n kube-system\n```\n\nIf the following two pods `vgpu-device-plugin` and `vgpu-scheduler` are in *Running* state, then your installation is successful.\n\n### Running GPU Jobs\n\nNVIDIA vGPUs can now be requested by a container\nusing the `nvidia.com\u002Fgpu` resource type:\n\n```\napiVersion: v1\nkind: Pod\nmetadata:\n  name: gpu-pod\nspec:\n  containers:\n    - name: ubuntu-container\n      image: ubuntu:18.04\n      command: [\"bash\", \"-c\", \"sleep 86400\"]\n      resources:\n        limits:\n          nvidia.com\u002Fgpu: 2 # requesting 2 vGPUs\n          nvidia.com\u002Fgpumem: 3000 # Each vGPU contains 3000m device memory （Optional,Integer）\n          nvidia.com\u002Fgpucores: 30 # Each vGPU uses 30% of the entire GPU （Optional,Integer)\n```\n\nYou should be cautious that if the task can't fit in any GPU node(ie. the number of `nvidia.com\u002Fgpu` you request exceeds the number of GPU in any node). The task will get stuck in `pending` state.\n\nYou can now execute `nvidia-smi` command in the container and see the difference of GPU memory between vGPU and real GPU.\n\n> **WARNING:** *if you don't request vGPUs when using the device plugin with NVIDIA images all\n> the vGPUs on the machine will be exposed inside your container.*\n\n### More examples\n\nClick [here](docs\u002Fexamples\u002Fnvidia\u002F)\n\n### Scheduler Webhook Service NodePort\n\nDefault schedulerPort is 31998, other values can be set using `--set deivcePlugin.service.schedulerPort` during installation.\n\n### Monitoring vGPU status\n\nMonitoring is automatically enabled after installation. You can get vGPU status of a node by visiting \n\n```\nhttp:\u002F\u002F{nodeip}:{monitorPort}\u002Fmetrics\n```\n\nDefault monitorPort is 31992, other values can be set using `--set deivcePlugin.service.httpPort` during installation.\n\ngrafana dashboard [example](docs\u002Fdashboard.md)\n\n> **Note** The status of a node won't be collected before any GPU operations\n\n### Upgrade\n\nTo Upgrade the k8s-vGPU to the latest version, all you need to do is update the repo and restart the chart.\n\n```\n$ helm uninstall vgpu -n kube-system\n$ helm repo update\n$ helm install vgpu vgpu -n kube-system\n```\n\n### Uninstall \n\n```\nhelm uninstall vgpu -n kube-system\n```\n\n## Scheduling\n\nCurrent schedule strategy is to select GPU with the lowest task. Thus balance the loads across mutiple GPUs\n\n## Benchmarks\n\nThree instances from ai-benchmark have been used to evaluate vGPU-device-plugin performance as follows\n\n| Test Environment | description                                              |\n| ---------------- | :------------------------------------------------------: |\n| Kubernetes version | v1.12.9                                                |\n| Docker  version    | 18.09.1                                                |\n| GPU Type           | Tesla V100                                             |\n| GPU Num            | 2                                                      |\n\n| Test instance |                         description                         |\n| ------------- | :---------------------------------------------------------: |\n| nvidia-device-plugin      |               k8s + nvidia k8s-device-plugin                |\n| vGPU-device-plugin        | k8s + VGPU k8s-device-plugin，without virtual device memory |\n| vGPU-device-plugin(virtual device memory) |  k8s + VGPU k8s-device-plugin，with virtual device memory   |\n\nTest Cases:\n\n| test id |     case      |   type    |         params          |\n| ------- | :-----------: | :-------: | :---------------------: |\n| 1.1     | Resnet-V2-50  | inference |  batch=50,size=346*346  |\n| 1.2     | Resnet-V2-50  | training  |  batch=20,size=346*346  |\n| 2.1     | Resnet-V2-152 | inference |  batch=10,size=256*256  |\n| 2.2     | Resnet-V2-152 | training  |  batch=10,size=256*256  |\n| 3.1     |    VGG-16     | inference |  batch=20,size=224*224  |\n| 3.2     |    VGG-16     | training  |  batch=2,size=224*224   |\n| 4.1     |    DeepLab    | inference |  batch=2,size=512*512   |\n| 4.2     |    DeepLab    | training  |  batch=1,size=384*384   |\n| 5.1     |     LSTM      | inference | batch=100,size=1024*300 |\n| 5.2     |     LSTM      | training  | batch=10,size=1024*300  |\n\nTest Result: ![img](https:\u002F\u002Foss.gittoolsai.com\u002Fimages\u002F4paradigm_k8s-vgpu-scheduler_readme_2986003f20d7.png)\n\n![img](https:\u002F\u002Foss.gittoolsai.com\u002Fimages\u002F4paradigm_k8s-vgpu-scheduler_readme_4753b4f36c35.png)\n\nTo reproduce:\n\n1. install k8s-vGPU-scheduler，and configure properly\n2. run benchmark job\n\n```\n$ kubectl apply -f benchmarks\u002Fai-benchmark\u002Fai-benchmark.yml\n```\n\n3. View the result by using kubctl logs\n\n```\n$ kubectl logs [pod id]\n```\n\n## Features\n\n- Specify the number of vGPUs divided by each physical GPU.\n- Limits vGPU's Device Memory.\n- Allows vGPU allocation by specifying device memory \n- Limits vGPU's Streaming Multiprocessor.\n- Allows vGPU allocation by specifying device core usage\n- Zero changes to existing programs\n\n## Experimental Features\n\n- Virtual Device Memory\n\n  The device memory of the vGPU can exceed the physical device memory of the GPU. At this time, the excess part will be put in the RAM, which will have a certain impact on the performance.\n\n## Known Issues\n\n- Currently, A100 MIG can only support \"none\" and \"mixed\" mode \n- Currently, task with filed \"nodeName\" can't be scheduled, please use \"nodeSelector\" instead\n- Currently, only computing tasks are supported, and video codec processing is not supported.\n\n## TODO\n\n- Support video codec processing\n- Support Multi-Instance GPUs (MIG)\n\n## Tests\n\n- TensorFlow 1.14.0\u002F2.4.1\n- torch 1.1.0\n- mxnet 1.4.0\n- mindspore 1.1.1\n\nThe above frameworks have passed the test.\n\n## Issues and Contributing\n\n* You can report a bug, a doubt or modify by [filing a new issue](https:\u002F\u002Fgithub.com\u002F4paradigm\u002Fk8s-vgpu-scheduler\u002Fissues\u002Fnew)\n* If you want to know more or have ideas, you can participate in the [Discussions](https:\u002F\u002Fgithub.com\u002F4paradigm\u002Fk8s-device-plugin\u002Fdiscussions) and the [slack](https:\u002F\u002Fjoin.slack.com\u002Ft\u002Fk8s-device-plugin\u002Fshared_invite\u002Fzt-oi9zkr5c-LsMzNmNs7UYg6usc0OiWKw) exchanges\n\n\n## Authors\n\n- Mengxuan Li (limengxuan@4paradigm.com)\n- Zhaoyou Pei (peizhaoyou@4paradigm.com)\n- Guangchuan Shi (shiguangchuan@4paradigm.com)\n- Zhao Zheng (zhengzhao@4paradigm.com)\n\n## Contact\n\nOwner & Maintainer: Limengxuan\n\nFeel free to reach me by \n\n```\nemail: \u003Climengxuan@4paradigm.com> \nphone: +86 18810644493\nWeChat: xuanzong4493\n```","英文版|[中文版](README_cn.md)\n\n# OpenAIOS Kubernetes vGPU 调度器\n\n[![构建状态](https:\u002F\u002Fgithub.com\u002FProject-HAMi\u002FHAMi\u002Factions\u002Fworkflows\u002Fmain.yml\u002Fbadge.svg)](https:\u002F\u002Fgithub.com\u002F4paradigm\u002Fk8s-vgpu-scheduler\u002Factions\u002Fworkflows\u002Fmain.yml)\n[![Docker 拉取次数](https:\u002F\u002Fimg.shields.io\u002Fdocker\u002Fpulls\u002F4pdosc\u002Fk8s-vgpu.svg)](https:\u002F\u002Fhub.docker.com\u002Fr\u002F4pdosc\u002Fk8s-vgpu)\n[![Slack](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FSlack-Join%20Slack-blue)](https:\u002F\u002Fjoin.slack.com\u002Ft\u002Fk8s-device-plugin\u002Fshared_invite\u002Fzt-oi9zkr5c-LsMzNmNs7UYg6usc0OiWKw)\n[![讨论](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FDiscuss-Ask%20Questions-blue)](https:\u002F\u002Fgithub.com\u002F4paradigm\u002Fk8s-device-plugin\u002Fdiscussions)\n[![联系我](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FContact%20Me-blue)](https:\u002F\u002Fgithub.com\u002F4paradigm\u002Fk8s-vgpu-scheduler#contact)\n\n## 支持的设备\n\n[![NVIDIA GPU](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FNvidia-GPU-blue)](https:\u002F\u002Fgithub.com\u002F4paradigm\u002Fk8s-vgpu-scheduler#preparing-your-gpu-nodes)\n[![Cambricon MLU](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FCambricon-Mlu-blue)](docs\u002Fcambricon-mlu-support.md)\n[![Hygon DCU](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FHygon-DCU-blue)](docs\u002Fhygon-dcu-support.md)\n\n\n> **注意** 本项目已更名为 [project-HAMi](https:\u002F\u002Fgithub.com\u002FProject-HAMi\u002FHAMi)，我们保留旧仓库以确保兼容性。\n\n## 简介\n\n**4paradigm k8s vGPU调度器是一个用于在Kubernetes集群中管理GPU的“一体化”解决方案**，它具备您对Kubernetes GPU管理工具的所有期望功能，包括：\n\n***GPU共享***：每个任务可以分配部分GPU资源，而不是整张GPU卡，从而实现多任务之间的GPU资源共享。\n\n***设备内存控制***：GPU可以按固定大小（如3000M）或占总显存的百分比（如50%）进行分配，并确保不会超出限制。\n\n***虚拟设备内存***：通过使用主机内存作为交换空间，您可以超额分配GPU设备内存。\n\n***GPU类型指定***：您可以通过设置`nvidia.com\u002Fuse-gputype`或`nvidia.com\u002Fnouse-gputype`注解来指定某个GPU任务应使用或避免使用的GPU类型。\n\n***易于使用***：您无需修改任务的YAML文件即可使用我们的调度器。安装完成后，所有GPU作业都会自动得到支持。此外，如果您愿意，还可以将资源名称指定为`nvidia.com\u002Fgpu`以外的其他名称。\n\n**k8s vGPU调度器**基于4paradigm k8s-device-plugin（[4paradigm\u002Fk8s-device-plugin](https:\u002F\u002Fgithub.com\u002F4paradigm\u002Fk8s-device-plugin)）的功能扩展，例如物理GPU的分割、内存和计算单元的限制等。在此基础上，它增加了调度模块，以平衡不同GPU节点之间的GPU使用情况。此外，用户还可以通过指定设备内存和计算核心的使用量来分配GPU资源。更进一步地，vGPU调度器能够虚拟化设备内存（实际使用的设备内存可以超过物理显存），从而运行一些需要大量显存的任务，或者增加共享任务的数量。有关详细信息，请参阅[基准测试报告](#benchmarks)。\n\n## 使用场景\n\n1. 当Pod需要按特定的设备内存用量或计算核心数分配资源时。\n2. 需要在包含多个GPU节点的集群中均衡GPU资源使用时。\n3. 设备内存和计算单元利用率较低的情况，例如在一张GPU上运行10个TensorFlow Serving实例。\n4. 需要大量小型GPU资源的场景，例如教学环境中为多名学生共享一台GPU，或云平台提供小型GPU实例。\n5. 在物理设备内存不足的情况下，可以启用虚拟设备内存功能，例如训练大规模数据集和大型模型时。\n\n## 先决条件\n\n以下是运行NVIDIA设备插件所需的先决条件：\n* NVIDIA驱动程序 ≥ 384.81\n* nvidia-docker版本 > 2.0\n* Kubernetes版本 ≥ 1.16\n* glibc ≥ 2.17\n* 内核版本 ≥ 3.10\n* Helm > 3.0\n\n## 快速开始\n\n### 准备您的GPU节点\n以下步骤需要在所有GPU节点上执行。\n本README假定NVIDIA驱动程序和`nvidia-container-toolkit`已经预先安装好。\n同时假设您已将`nvidia-container-runtime`配置为默认的底层运行时。\n\n请参阅：https:\u002F\u002Fdocs.nvidia.com\u002Fdatacenter\u002Fcloud-native\u002Fcontainer-toolkit\u002Finstall-guide.html\n\n#### 基于Debian系统的`docker`和`containerd`示例\n\n##### 安装`nvidia-container-toolkit`\n```bash\ndistribution=$(. \u002Fetc\u002Fos-release;echo $ID$VERSION_ID)\ncurl -s -L https:\u002F\u002Fnvidia.github.io\u002Flibnvidia-container\u002Fgpgkey | sudo apt-key add -\ncurl -s -L https:\u002F\u002Fnvidia.github.io\u002Flibnvidia-container\u002F$distribution\u002Flibnvidia-container.list | sudo tee \u002Fetc\u002Fapt\u002Fsources.list.d\u002Flibnvidia-container.list\n\nsudo apt-get update && sudo apt-get install -y nvidia-container-toolkit\n```\n\n##### 配置`docker`\n当使用`docker`运行`kubernetes`时，编辑通常位于`\u002Fetc\u002Fdocker\u002Fdaemon.json`的配置文件，将`nvidia-container-runtime`设置为默认的底层运行时：\n```json\n{\n    \"default-runtime\": \"nvidia\",\n    \"runtimes\": {\n        \"nvidia\": {\n            \"path\": \"\u002Fusr\u002Fbin\u002Fnvidia-container-runtime\",\n            \"runtimeArgs\": []\n        }\n    }\n}\n```\n然后重启`docker`：\n```\n$ sudo systemctl daemon-reload && systemctl restart docker\n```\n\n##### 配置`containerd`\n当使用`containerd`运行`kubernetes`时，编辑通常位于`\u002Fetc\u002Fcontainerd\u002Fconfig.toml`的配置文件，将`nvidia-container-runtime`设置为默认的底层运行时：\n```\nversion = 2\n[plugins]\n  [plugins.\"io.containerd.grpc.v1.cri\"]\n    [plugins.\"io.containerd.grpc.v1.cri\".containerd]\n      default_runtime_name = \"nvidia\"\n\n      [plugins.\"io.containerd.grpc.v1.cri\".containerd.runtimes]\n        [plugins.\"io.containerd.grpc.v1.cri\".containerd.runtimes.nvidia]\n          privileged_without_host_devices = false\n          runtime_engine = \"\"\n          runtime_root = \"\"\n          runtime_type = \"io.containerd.runc.v2\"\n          [plugins.\"io.containerd.grpc.v1.cri\".containerd.runtimes.nvidia.options]\n            BinaryName = \"\u002Fusr\u002Fbin\u002Fnvidia-container-runtime\"\n```\n然后重启`containerd`：\n```\n$ sudo systemctl daemon-reload && systemctl restart containerd\n```\n\n之后，您需要为可由4pd-k8s-scheduler调度的GPU节点打上标签`gpu=on`，否则这些节点将无法被我们的调度器管理。\n```\nkubectl label nodes {nodeid} gpu=on\n```\n\n### 在 Kubernetes 中启用 vGPU 支持\n\n首先，您需要使用以下命令检查您的 Kubernetes 版本：\n\n```\nkubectl version\n```\n\n然后，在 Helm 中添加我们的仓库：\n\n```\nhelm repo add vgpu-charts https:\u002F\u002F4paradigm.github.io\u002Fk8s-vgpu-scheduler\n```\n\n在安装过程中，您需要根据您的 Kubernetes 服务器版本设置 Kubernetes 调度器镜像版本。例如，如果您的集群服务器版本是 1.16.8，则应使用以下命令进行部署：\n\n```\nhelm install vgpu vgpu-charts\u002Fvgpu --set scheduler.kubeScheduler.imageTag=v1.16.8 -n kube-system\n```\n\n您可以通过调整 [配置](docs\u002Fconfig.md)来自定义安装。\n\n您可以通过以下命令验证安装是否成功：\n\n```\n$ kubectl get pods -n kube-system\n```\n\n如果 `vgpu-device-plugin` 和 `vgpu-scheduler` 这两个 Pod 处于 *Running* 状态，则说明您的安装已成功。\n\n### 运行 GPU 作业\n\n现在，容器可以使用 `nvidia.com\u002Fgpu` 资源类型来请求 NVIDIA vGPU：\n\n```\napiVersion: v1\nkind: Pod\nmetadata:\n  name: gpu-pod\nspec:\n  containers:\n    - name: ubuntu-container\n      image: ubuntu:18.04\n      command: [\"bash\", \"-c\", \"sleep 86400\"]\n      resources:\n        limits:\n          nvidia.com\u002Fgpu: 2 # 请求 2 个 vGPU\n          nvidia.com\u002Fgpumem: 3000 # 每个 vGPU 包含 3000m 设备内存（可选，整数）\n          nvidia.com\u002Fgpucores: 30 # 每个 vGPU 使用整个 GPU 的 30%（可选，整数）\n```\n\n请注意，如果任务无法分配到任何 GPU 节点上（即您请求的 `nvidia.com\u002Fgpu` 数量超过了任何节点上的 GPU 数量），该任务将陷入 `pending` 状态。\n\n现在您可以在容器中执行 `nvidia-smi` 命令，并查看 vGPU 和物理 GPU 之间的显存差异。\n\n> **警告：** *如果您在使用 NVIDIA 镜像的设备插件时未请求 vGPU，机器上的所有 vGPU 将暴露在您的容器中。*\n\n### 更多示例\n\n点击 [这里](docs\u002Fexamples\u002Fnvidia\u002F) 查看更多示例。\n\n### 调度器 Webhook 服务 NodePort\n\n默认调度器端口为 31998，您可以在安装时使用 `--set deivcePlugin.service.schedulerPort` 来设置其他值。\n\n### 监控 vGPU 状态\n\n安装后会自动启用监控功能。您可以通过访问以下地址获取节点的 vGPU 状态：\n\n```\nhttp:\u002F\u002F{nodeip}:{monitorPort}\u002Fmetrics\n```\n\n默认监控端口为 31992，您可以在安装时使用 `--set deivcePlugin.service.httpPort` 来设置其他值。\n\nGrafana 仪表板 [示例](docs\u002Fdashboard.md)\n\n> **注意** 在进行任何 GPU 操作之前，不会收集节点的状态信息。\n\n### 升级\n\n要将 k8s-vGPU 升级到最新版本，您只需更新仓库并重新启动 Chart 即可：\n\n```\n$ helm uninstall vgpu -n kube-system\n$ helm repo update\n$ helm install vgpu vgpu -n kube-system\n```\n\n### 卸载\n\n```\nhelm uninstall vgpu -n kube-system\n```\n\n## 调度\n\n当前的调度策略是选择任务最少的 GPU，从而在多个 GPU 之间均衡负载。\n\n## 基准测试\n\n我们使用了 ai-benchmark 中的三个实例来评估 vGPU 设备插件的性能，具体如下：\n\n| 测试环境 | 描述                                              |\n| -------- | :------------------------------------------------------: |\n| Kubernetes 版本 | v1.12.9                                                |\n| Docker 版本    | 18.09.1                                                |\n| GPU 类型           | Tesla V100                                             |\n| GPU 数量            | 2                                                      |\n\n| 测试实例 |                         描述                         |\n| --------- | :---------------------------------------------------------: |\n| nvidia-device-plugin      |               k8s + nvidia k8s-device-plugin                |\n| vGPU-device-plugin        | k8s + VGPU k8s-device-plugin，不使用虚拟设备内存 |\n| vGPU-device-plugin（使用虚拟设备内存） |  k8s + VGPU k8s-device-plugin，使用虚拟设备内存   |\n\n测试用例：\n\n| 测试编号 |     案例      |   类型    |         参数          |\n| ------- | :-----------: | :-------: | :---------------------: |\n| 1.1     | Resnet-V2-50  | 推理 |  batch=50,size=346*346  |\n| 1.2     | Resnet-V2-50  | 训练  |  batch=20,size=346*346  |\n| 2.1     | Resnet-V2-152 | 推理 |  batch=10,size=256*256  |\n| 2.2     | Resnet-V2-152 | 训练  |  batch=10,size=256*256  |\n| 3.1     |    VGG-16     | 推理 |  batch=20,size=224*224  |\n| 3.2     |    VGG-16     | 训练  |  batch=2,size=224*224   |\n| 4.1     |    DeepLab    | 推理 |  batch=2,size=512*512   |\n| 4.2     |    DeepLab    | 训练  |  batch=1,size=384*384   |\n| 5.1     |     LSTM      | 推理 | batch=100,size=1024*300 |\n| 5.2     |     LSTM      | 训练  | batch=10,size=1024*300  |\n\n测试结果：![img](https:\u002F\u002Foss.gittoolsai.com\u002Fimages\u002F4paradigm_k8s-vgpu-scheduler_readme_2986003f20d7.png)\n\n![img](https:\u002F\u002Foss.gittoolsai.com\u002Fimages\u002F4paradigm_k8s-vgpu-scheduler_readme_4753b4f36c35.png)\n\n重现步骤：\n\n1. 安装 k8s-vGPU 调度器，并正确配置。\n2. 运行基准测试作业。\n\n```\n$ kubectl apply -f benchmarks\u002Fai-benchmark\u002Fai-benchmark.yml\n```\n\n3. 使用 kubctl logs 查看结果。\n\n```\n$ kubectl logs [pod id]\n```\n\n## 功能\n\n- 可以指定每个物理 GPU 分配的 vGPU 数量。\n- 限制 vGPU 的设备内存。\n- 允许通过指定设备内存来分配 vGPU。\n- 限制 vGPU 的流式多处理器。\n- 允许通过指定设备核心使用率来分配 vGPU。\n- 对现有程序无需任何修改。\n\n## 实验性功能\n\n- 虚拟设备内存\n\n  vGPU 的设备内存可以超过 GPU 的物理设备内存。此时，超出部分将被存储在 RAM 中，这会对性能产生一定影响。\n\n## 已知问题\n\n- 目前 A100 MIG 仅支持“none”和“mixed”模式。\n- 目前带有 “nodeName” 字段的任务无法被调度，请改用 “nodeSelector”。\n- 目前仅支持计算任务，不支持视频编解码处理。\n\n## 待办事项\n\n- 支持视频编解码处理。\n- 支持多实例 GPU (MIG)。\n\n## 测试\n\n- TensorFlow 1.14.0\u002F2.4.1\n- torch 1.1.0\n- mxnet 1.4.0\n- mindspore 1.1.1\n\n以上框架均已通过测试。\n\n## 问题与贡献\n\n* 您可以通过 [提交新问题](https:\u002F\u002Fgithub.com\u002F4paradigm\u002Fk8s-vgpu-scheduler\u002Fissues\u002Fnew) 报告错误、提出疑问或进行修改。\n* 如果您想了解更多或有想法，可以参与 [讨论](https:\u002F\u002Fgithub.com\u002F4paradigm\u002Fk8s-device-plugin\u002Fdiscussions) 和 [Slack](https:\u002F\u002Fjoin.slack.com\u002Ft\u002Fk8s-device-plugin\u002Fshared_invite\u002Fzt-oi9zkr5c-LsMzNmNs7UYg6usc0OiWKw) 社区交流。\n\n\n## 作者\n\n- 李孟轩 (limengxuan@4paradigm.com)\n- 裴兆友 (peizhaoyou@4paradigm.com)\n- 史广川 (shiguangchuan@4paradigm.com)\n- 郑钊 (zhengzhao@4paradigm.com)\n\n## 联系方式\n\n负责人及维护者：李孟轩\n\n欢迎通过以下方式联系我：\n\n```\n邮箱：\u003Climengxuan@4paradigm.com> \n电话：+86 18810644493\n微信：xuanzong4493\n```","# k8s-vgpu-scheduler 快速上手指南\n\nk8s-vgpu-scheduler（现更名为 Project-HAMi）是一个用于 Kubernetes 集群的 GPU 统一管理调度器。它支持 GPU 共享、显存限制、核心算力限制以及虚拟显存等功能，无需修改现有任务 YAML 即可自动生效。\n\n## 1. 环境准备\n\n在部署前，请确保您的集群满足以下前置条件：\n\n*   **操作系统**: Linux (glibc >= 2.17, kernel >= 3.10)\n*   **Kubernetes**: 版本 >= 1.16\n*   **NVIDIA 驱动**: 版本 >= 384.81\n*   **容器运行时**: 已安装 `nvidia-docker` (> 2.0) 或配置了 `nvidia-container-toolkit`\n*   **包管理工具**: Helm > 3.0\n\n### 节点预处理\n在所有 GPU 节点上，需确保 `nvidia-container-runtime` 已设为默认运行时。\n\n**安装 nvidia-container-toolkit (以 Debian\u002FUbuntu 为例):**\n```bash\ndistribution=$(. \u002Fetc\u002Fos-release;echo $ID$VERSION_ID)\ncurl -s -L https:\u002F\u002Fnvidia.github.io\u002Flibnvidia-container\u002Fgpgkey | sudo apt-key add -\ncurl -s -L https:\u002F\u002Fnvidia.github.io\u002Flibnvidia-container\u002F$distribution\u002Flibnvidia-container.list | sudo tee \u002Fetc\u002Fapt\u002Fsources.list.d\u002Flibnvidia-container.list\n\nsudo apt-get update && sudo apt-get install -y nvidia-container-toolkit\n```\n\n**配置 Docker (如使用 Docker):**\n编辑 `\u002Fetc\u002Fdocker\u002Fdaemon.json`:\n```json\n{\n    \"default-runtime\": \"nvidia\",\n    \"runtimes\": {\n        \"nvidia\": {\n            \"path\": \"\u002Fusr\u002Fbin\u002Fnvidia-container-runtime\",\n            \"runtimeArgs\": []\n        }\n    }\n}\n```\n重启 Docker:\n```bash\nsudo systemctl daemon-reload && systemctl restart docker\n```\n\n**配置 Containerd (如使用 Containerd):**\n编辑 `\u002Fetc\u002Fcontainerd\u002Fconfig.toml`, 确保包含以下配置:\n```toml\nversion = 2\n[plugins]\n  [plugins.\"io.containerd.grpc.v1.cri\"]\n    [plugins.\"io.containerd.grpc.v1.cri\".containerd]\n      default_runtime_name = \"nvidia\"\n      [plugins.\"io.containerd.grpc.v1.cri\".containerd.runtimes]\n        [plugins.\"io.containerd.grpc.v1.cri\".containerd.runtimes.nvidia]\n          privileged_without_host_devices = false\n          runtime_engine = \"\"\n          runtime_root = \"\"\n          runtime_type = \"io.containerd.runc.v2\"\n          [plugins.\"io.containerd.grpc.v1.cri\".containerd.runtimes.nvidia.options]\n            BinaryName = \"\u002Fusr\u002Fbin\u002Fnvidia-container-runtime\"\n```\n重启 Containerd:\n```bash\nsudo systemctl daemon-reload && systemctl restart containerd\n```\n\n**标记 GPU 节点:**\n必须为可调度的 GPU 节点添加标签，否则无法被管理：\n```bash\nkubectl label nodes \u003Cnode-name> gpu=on\n```\n\n## 2. 安装步骤\n\n### 添加 Helm 仓库\n```bash\nhelm repo add vgpu-charts https:\u002F\u002F4paradigm.github.io\u002Fk8s-vgpu-scheduler\nhelm repo update\n```\n\n### 部署调度器\n请根据您的 Kubernetes 集群版本设置 `scheduler.kubeScheduler.imageTag`。例如，若集群版本为 `v1.16.8`：\n\n```bash\nhelm install vgpu vgpu-charts\u002Fvgpu --set scheduler.kubeScheduler.imageTag=v1.16.8 -n kube-system\n```\n\n> **提示**: 可通过 `--set` 参数自定义配置，详见官方 config 文档。\n\n### 验证安装\n检查 Pod 状态，确认 `vgpu-device-plugin` 和 `vgpu-scheduler` 均处于 `Running` 状态：\n```bash\nkubectl get pods -n kube-system\n```\n\n## 3. 基本使用\n\n安装完成后，无需修改现有 YAML 结构，只需在 Pod 的 `resources.limits` 中声明 GPU 资源即可。\n\n### 示例：申请带显存和算力限制的 vGPU\n\n以下示例申请 2 个 vGPU，每个 vGPU 限制显存为 3000MB，算力占用为整卡的 30%：\n\n```yaml\napiVersion: v1\nkind: Pod\nmetadata:\n  name: gpu-pod\nspec:\n  containers:\n    - name: ubuntu-container\n      image: ubuntu:18.04\n      command: [\"bash\", \"-c\", \"sleep 86400\"]\n      resources:\n        limits:\n          nvidia.com\u002Fgpu: 2                # 申请 2 个 vGPU\n          nvidia.com\u002Fgpumem: 3000          # (可选) 每个 vGPU 限制显存 3000MB\n          nvidia.com\u002Fgpucores: 30          # (可选) 每个 vGPU 限制算力为 30%\n```\n\n### 使用说明\n*   **资源名称**: 默认为 `nvidia.com\u002Fgpu`，也可通过配置自定义。\n*   **显存超卖**: 支持开启虚拟显存功能，使分配的显存总和超过物理显存（利用主机内存作为 Swap）。\n*   **类型指定**: 可通过注解 `nvidia.com\u002Fuse-gputype` 或 `nvidia.com\u002Fnouse-gputype` 指定使用或避开特定类型的 GPU。\n*   **状态监控**: 安装后自动开启监控，访问 `http:\u002F\u002F{nodeip}:31992\u002Fmetrics` 即可查看节点 vGPU 状态。\n\n### 验证效果\n进入容器执行 `nvidia-smi`，您将看到显存大小已被限制为设定值，而非整卡显存。\n\n> **注意**: 如果请求的资源量超过集群中任意单节点的承载能力，Pod 将保持在 `Pending` 状态。","某云教育平台需在有限的 GPU 集群上，同时支撑数百名学生进行深度学习模型训练与推理实验。\n\n### 没有 k8s-vgpu-scheduler 时\n- **资源严重浪费**：每个学生任务必须独占整张物理显卡，即便模型仅需 1GB 显存，也会占用整卡 16GB，导致大量算力闲置。\n- **并发能力受限**：由于无法切分显卡，集群只能串行处理少量任务，学生排队等待时间过长，教学效率低下。\n- **大模型无法运行**：部分进阶课程需要加载超大模型，显存需求超过物理上限，直接导致任务启动失败（OOM）。\n- **调度缺乏灵活性**：管理员无法指定任务使用特定型号显卡或限制其显存用量，难以精细化管理集群负载。\n\n### 使用 k8s-vgpu-scheduler 后\n- **实现细粒度共享**：支持将单张物理 GPU 切分为多个虚拟实例，每位学生可按需分配如\"2GB 显存 +20% 算力”，资源利用率提升数倍。\n- **大幅提升并发**：同一张显卡可同时承载多个轻量级训练任务，学生无需排队，实验吞吐量显著增加。\n- **突破显存物理限制**：开启虚拟显存功能后，利用主机内存作为交换空间，成功运行了原本因显存不足而失败的大批量训练任务。\n- **智能调度与隔离**：通过注解灵活指定显卡类型或避免使用某些节点，并严格限制每个任务的显存边界，防止相互干扰。\n\nk8s-vgpu-scheduler 通过显存虚拟化与细粒度切分技术，将昂贵的 GPU 资源从“独占奢侈品”转变为可高效共享的“公共服务”，极大降低了 AI 教学与研发的门槛。","https:\u002F\u002Foss.gittoolsai.com\u002Fimages\u002F4paradigm_k8s-vgpu-scheduler_0c0a4268.png","4paradigm","4Paradigm","https:\u002F\u002Foss.gittoolsai.com\u002Favatars\u002F4paradigm_945c02ee.jpg","4Paradigm Open Source Community",null,"4paradigm.com","https:\u002F\u002Fgithub.com\u002F4paradigm",[83,87,91,95,99,103],{"name":84,"color":85,"percentage":86},"Go","#00ADD8",72.9,{"name":88,"color":89,"percentage":90},"C","#555555",25.6,{"name":92,"color":93,"percentage":94},"Shell","#89e051",0.6,{"name":96,"color":97,"percentage":98},"Smarty","#f0c040",0.5,{"name":100,"color":101,"percentage":102},"Dockerfile","#384d54",0.2,{"name":104,"color":105,"percentage":102},"Makefile","#427819",588,100,"2026-04-03T16:41:08","Apache-2.0",4,"Linux","必需。支持 NVIDIA GPU (驱动>=384.81), Cambricon MLU, Hygon DCU。需安装 nvidia-docker > 2.0 及 nvidia-container-toolkit。显存大小和 CUDA 版本取决于具体物理显卡，工具支持指定显存大小（如 3000M）或使用百分比，并支持显存超分（虚拟显存）。","未说明（取决于宿主机及任务需求，开启虚拟显存功能时利用宿主机内存作为交换空间）",{"notes":115,"python":116,"dependencies":117},"1. 该项目已重命名为 project-HAMi，当前仓库为兼容保留。2. 必须在所有 GPU 节点上预装 NVIDIA 驱动和 nvidia-container-toolkit，并将 nvidia-container-runtime 配置为默认运行时。3. 需给 GPU 节点打上 'gpu=on' 标签才能被调度器管理。4. 安装时需根据 Kubernetes 集群版本指定 scheduler 镜像版本。5. 支持 GPU 共享、显存控制、显存超分（虚拟显存）及指定 GPU 类型等功能。","未说明",[118,119,120,121,122,123,124],"Kubernetes >= 1.16","Helm > 3.0","glibc >= 2.17","Linux Kernel >= 3.10","NVIDIA Drivers >= 384.81","nvidia-docker > 2.0","nvidia-container-toolkit",[13],"2026-03-27T02:49:30.150509","2026-04-06T05:44:18.123756",[129,134,139,144,149,154,159],{"id":130,"question_zh":131,"answer_zh":132,"source_url":133},14886,"分配了多张 vGPU 但在容器内使用 nvidia-smi 只能看到一张，原因是什么？","这通常是由于环境变量 `NVIDIA_DEVICE_MAP` 设置问题导致的。容器启动时可能修改了环境变量，导致第二张及后续 vGPU 的环境变量设置未成功生效。建议检查容器启动时的环境变量配置，或尝试升级到最新版本（如 v0.9.0.19 及以上）以修复该问题。","https:\u002F\u002Fgithub.com\u002F4paradigm\u002Fk8s-vgpu-scheduler\u002Fissues\u002F17",{"id":135,"question_zh":136,"answer_zh":137,"source_url":138},14887,"为什么容器内看到的显存大小与宿主机不一致（少几百 MB）？","这是正常现象。容器内的显存数据是由插件统计的，与宿主机存在几百 MB 的差异主要是因为部分用于管理上下文的显存，NVIDIA 没有提供查询接口，因此插件无法统计到这部分显存。只要训练任务不报错且未超过限制，通常不影响使用。","https:\u002F\u002Fgithub.com\u002F4paradigm\u002Fk8s-vgpu-scheduler\u002Fissues\u002F12",{"id":140,"question_zh":141,"answer_zh":142,"source_url":143},14888,"启用 vGPU 后在 Pod 内执行 nvidia-smi 报错 \"Segmentation fault (core dumped)\" 怎么办？","该问题可能与集群中 GPU 卡的数量或参数设置有关。有用户反馈当集群内 GPU 超过一张卡时 vGPU 可正常工作，单卡时可能出现此错误。建议在容器内执行 `env` 命令检查环境变量配置，并确认是否因单卡环境下的特定参数导致。如果问题持续，建议升级插件版本或在多卡环境下测试。","https:\u002F\u002Fgithub.com\u002F4paradigm\u002Fk8s-vgpu-scheduler\u002Fissues\u002F11",{"id":145,"question_zh":146,"answer_zh":147,"source_url":148},14889,"启动插件时报错 \"Error: failed to create FS watcher: no such file or directory\" 如何解决？","该错误通常意味着 kubelet 安装或版本存在问题。正常情况下，Node 节点上必须存在 `\u002Fvar\u002Flib\u002Fkubelet\u002Fdevice-plugins` 目录。请检查 kubelet 是否正确安装，确认该目录是否存在，并验证 kubelet 版本是否与插件兼容。","https:\u002F\u002Fgithub.com\u002F4paradigm\u002Fk8s-vgpu-scheduler\u002Fissues\u002F6",{"id":150,"question_zh":151,"answer_zh":152,"source_url":153},14890,"运行 nvidia-smi 时报错 \"can't find function nvmlDeviceGetComputeRunningProcesses_v2 in libnvidia-ml.so.1\" 是什么原因？","此错误表明当前的 NVIDIA 驱动版本过旧，不支持插件调用的 `nvmlDeviceGetComputeRunningProcesses_v2` 函数。虽然宿主机的 `nvidia-smi` 可能正常运行，但 vGPU 插件需要较新版本的驱动支持。请升级宿主机的 NVIDIA 驱动程序至最新版本。","https:\u002F\u002Fgithub.com\u002F4paradigm\u002Fk8s-vgpu-scheduler\u002Fissues\u002F4",{"id":155,"question_zh":156,"answer_zh":157,"source_url":158},14891,"切分 vGPU 后显存数值无变化，或者 dmesg 中出现 segfault 错误会影响使用吗？","如果显存显示无变化但任务能正常运行，通常不影响使用，可能是显示层面的问题（相关版本已修复）。对于 dmesg 中出现的 `segfault` 错误（如 `nvidia-smi` 崩溃），如果容器内任务执行正常且未频繁崩溃，一般不影响核心功能，但建议更新到最新版本的插件以获取修复补丁。若进入生产环境，强烈推荐使用稳定的发布版本。","https:\u002F\u002Fgithub.com\u002F4paradigm\u002Fk8s-vgpu-scheduler\u002Fissues\u002F19",{"id":160,"question_zh":161,"answer_zh":162,"source_url":138},14892,"不同 Pod 之间似乎存在算力争夺导致互相影响，如何排查？","正常情况下 vGPU 具备显存隔离功能。如果出现不同 Pod 训练互相影响的情况，可能是因为算力（GPU Core）未被完全隔离而发生了争夺。建议在训练时在容器内部执行 `watch nvidia-smi` 观察实际使用情况，确认是否超出了预期的算力或显存限制。宿主机与容器内 `nvidia-smi` 结果不一致通常是统计机制差异造成的，应以容器内监控为准。",[]]