HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
nebuly-ai
nos
Go2023–2023
nebuly-ai / nos

nos

Module to Automatically maximize the utilization of GPU resources in a Kubernetes cluster through real-time dynamic partitioning and elastic quotas - Effortless optimization at its finest!

Systems & InfrastructureAI & Machine LearningScience & EngineeringDevOps & Cloud
Explore on GitHubRead Hacker News discussions
5Distinct people
9Mentions
0Explicit recommenders
687GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Module to Automatically maximize the utilization of GPU resources in a Kubernetes cluster through real-time dynamic partitioning and elastic quotas - Effortless optimization at its finest!

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by day9 dated mentions

Observed mentions: 2023-01-30 13:41:46 UTC to 2023-03-01 14:00:28 UTC.

012342023-01-30 00:00:00 UTC to 2023-01-31 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 commentsJan 302023-01-31 00:00:00 UTC to 2023-02-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2023-02-01 00:00:00 UTC to 2023-02-02 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-02-02 00:00:00 UTC to 2023-02-03 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-03 00:00:00 UTC to 2023-02-04 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-04 00:00:00 UTC to 2023-02-05 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-05 00:00:00 UTC to 2023-02-06 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-06 00:00:00 UTC to 2023-02-07 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-02-07 00:00:00 UTC to 2023-02-08 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-08 00:00:00 UTC to 2023-02-09 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-09 00:00:00 UTC to 2023-02-10 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-02-10 00:00:00 UTC to 2023-02-11 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-11 00:00:00 UTC to 2023-02-12 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-12 00:00:00 UTC to 2023-02-13 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-13 00:00:00 UTC to 2023-02-14 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-14 00:00:00 UTC to 2023-02-15 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsFeb 142023-02-15 00:00:00 UTC to 2023-02-16 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-16 00:00:00 UTC to 2023-02-17 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-17 00:00:00 UTC to 2023-02-18 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-18 00:00:00 UTC to 2023-02-19 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-19 00:00:00 UTC to 2023-02-20 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-20 00:00:00 UTC to 2023-02-21 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-21 00:00:00 UTC to 2023-02-22 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-22 00:00:00 UTC to 2023-02-23 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-23 00:00:00 UTC to 2023-02-24 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-24 00:00:00 UTC to 2023-02-25 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-25 00:00:00 UTC to 2023-02-26 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-26 00:00:00 UTC to 2023-02-27 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-27 00:00:00 UTC to 2023-02-28 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-28 00:00:00 UTC to 2023-03-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-03-01 00:00:00 UTC to 2023-03-02 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsMar 1

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Jan 302023-01-30 00:00:00 UTC2023-01-31 00:00:00 UTC110
Jan 312023-01-31 00:00:00 UTC2023-02-01 00:00:00 UTC404
Feb 12023-02-01 00:00:00 UTC2023-02-02 00:00:00 UTC101
Feb 22023-02-02 00:00:00 UTC2023-02-03 00:00:00 UTC000
Feb 32023-02-03 00:00:00 UTC2023-02-04 00:00:00 UTC000
Feb 42023-02-04 00:00:00 UTC2023-02-05 00:00:00 UTC000
Feb 52023-02-05 00:00:00 UTC2023-02-06 00:00:00 UTC000
Feb 62023-02-06 00:00:00 UTC2023-02-07 00:00:00 UTC101
Feb 72023-02-07 00:00:00 UTC2023-02-08 00:00:00 UTC000
Feb 82023-02-08 00:00:00 UTC2023-02-09 00:00:00 UTC000
Feb 92023-02-09 00:00:00 UTC2023-02-10 00:00:00 UTC101
Feb 102023-02-10 00:00:00 UTC2023-02-11 00:00:00 UTC000
Feb 112023-02-11 00:00:00 UTC2023-02-12 00:00:00 UTC000
Feb 122023-02-12 00:00:00 UTC2023-02-13 00:00:00 UTC000
Feb 132023-02-13 00:00:00 UTC2023-02-14 00:00:00 UTC000
Feb 142023-02-14 00:00:00 UTC2023-02-15 00:00:00 UTC000
Feb 152023-02-15 00:00:00 UTC2023-02-16 00:00:00 UTC000
Feb 162023-02-16 00:00:00 UTC2023-02-17 00:00:00 UTC000
Feb 172023-02-17 00:00:00 UTC2023-02-18 00:00:00 UTC000
Feb 182023-02-18 00:00:00 UTC2023-02-19 00:00:00 UTC000
Feb 192023-02-19 00:00:00 UTC2023-02-20 00:00:00 UTC000
Feb 202023-02-20 00:00:00 UTC2023-02-21 00:00:00 UTC000
Feb 212023-02-21 00:00:00 UTC2023-02-22 00:00:00 UTC000
Feb 222023-02-22 00:00:00 UTC2023-02-23 00:00:00 UTC000
Feb 232023-02-23 00:00:00 UTC2023-02-24 00:00:00 UTC000
Feb 242023-02-24 00:00:00 UTC2023-02-25 00:00:00 UTC000
Feb 252023-02-25 00:00:00 UTC2023-02-26 00:00:00 UTC000
Feb 262023-02-26 00:00:00 UTC2023-02-27 00:00:00 UTC000
Feb 272023-02-27 00:00:00 UTC2023-02-28 00:00:00 UTC000
Feb 282023-02-28 00:00:00 UTC2023-03-01 00:00:00 UTC000
Mar 12023-03-01 00:00:00 UTC2023-03-02 00:00:00 UTC101

What Hacker News says

9 sources
yarapavan·Mar 1, 2023
Some of the available modules include: Speedster: Automatically apply the best set of SOTA optimization techniques to achieve the maximum inference speed-up on your hardware. https://github.com/nebuly-ai/nebullvm/blob/main/apps/acceler... Nos: Automatically maximize the utilization of GPU resources in a Kubernetes cluster through real-time dynamic partitioning and elastic quotas. https://github.com/nebuly-ai/nos ChatLLaMA: Build faster and cheaper ChatGPT-like training process based on LLaMA architectures. https://github.com/nebuly-ai/nebullvm/tree/main/apps/acceler... OpenAlphaTensor: Increase the computational performances of an AI model with custom-generated matrix multiplication algorithm fine-tuned for your specific hardware. https://github.com/nebuly-ai/nebullvm/tree/main/apps/acceler... Forward-Forward: The Forward Forward algorith
Read the rest
m is a method for training deep neural networks that replaces the backpropagation forward and backward passes with two forward passes. https://github.com/nebuly-ai/nebullvm/tree/main/apps/acceler...
In Nebullvm: Plug and play modules to optimize the performances of your AI systems
michele_zanotti·Feb 9, 2023
Hi HN! I’m Michele Zanotti and today I’m releasing nos, an open-source module to efficiently run GPU workloads on Kubernetes! Nos is meant to increase GPU utilization and cut down infrastructure and operational costs providing 2 main features: 1. Dynamic GPU Partitioning: you can think of this as a cluster autoscaler for GPUs. Instead of scaling up the number of nodes and GPUs, it dynamically partitions them into smaller “GPU slices”. This ensures that each workload only uses the GPU resources it actually needs, resulting in spare GPU capacity that could be used for other workloads. To partition GPUs, nos leverages Nvidia's MPS and MIG [1,2], finally making them dynamic. 2. Elastic Resource Quota management: it allows to increase the number of Pods running on the cluster by allowing teams (namespaces) to borrow quotas of reserved resource
Read the rest
s from other teams as long as they are not using them. https://github.com/nebuly-ai/nos What is your thoughts on this project? :) Nos addresses some key challenges of Kubernetes tied to the fact that Kubernetes was not designed to support GPU and AI / machine learning workloads. In Kubernetes, GPUs are managed with [3] Nvidia k8s Device Plugin, which has a few major downsides. First, it requires the allocation of an integer number of GPUs per workload, not allowing workloads to request only fractions of GPU. Second, when enabling GPU shared access either with time-slicing or MIG, the device plugin advertises to Kubernetes a fixed set of GPU resources that do not dynamically adapt to the requests of the Pods at each time. This often leads to both underutilized GPUs and pending Pods, and/or the cluster admin having to spend a lot of time looking for workarounds to make the best use of GPUs. For example, consider a company with a k8s cluster with 20 GPUs, where 3 of these GPUs have been reserved for the data science team using Resource Quota objects. In most cases, the workloads of data scientists (notebooks, scripts, etc.) require much less memory/compute resources than those of an entire GPU, yet Kubernetes will force each container to consume an entire GPU. Also, if the team once needs to run a heavy workload, it may want to use as many resources as possible. However, the Resource Quota over their namespace would constrain the team to use at most the 3 GPUs reserved for them, even if the company cluster may be full of unused GPUs! Instead, with nos the data science team would use nos Dynamic GPU Partitioning to request GPU slices so that many workloads can share the same GPU. Also, Elastic Resource Quotas would allow the team to consume more than the 3 reserved GPUs, borrowing quotas from other teams that are not using them. To recap, the team would be able to launch more Pods and the company would likely need fewer nodes. All this with minimal effort required by the cluster admin, who only has to set up nos. Let me know what you think of nos, feedback would be very helpful! :) And please leave a star on GitHub if you like this opensource https://github.com/nebuly-ai/nos Here are some other links that may be useful - Tutorial on how to use Dynamic GPU Partitioning with Nvidia MIG https://towardsdatascience.com/dynamic-mig-partitioning-in-k... - Pros and cons of different technologies for sharing resources among workloads in Kubernetes: time-slicing, MIG, and MPS https://docs.nebuly.com/nos/dynamic-gpu-partitioning/partiti... - Nos documentation https://docs.nebuly.com/nos/overview/ References [1] Multi-Process Service (MPS) https://docs.nvidia.com/deploy/mps/index.html [2] Multi-Instance GPU (MIG) https://docs.nvidia.com/datacenter/tesla/mig-user-guide/ [3] NVIDIA k8s Device Plugin https://github.com/NVIDIA/k8s-device-plugin
In [dead]
michele_zanotti·Feb 6, 2023
Hi HN, I'm excited to share my latest Towards Data Science article on how to take advantage of Dynamic MIG Partitioning to efficiently run AI workloads on Kubernetes Excited to share my latest Towards Data Science article on how to take advantage of Dynamic MIG Partitioning to efficiently run AI workloads on Kubernetes MIG Partitioning is a way to divide GPU resources into smaller slices. This allows Pods to be scheduled only on the memory/compute resources they actually need, thus increasing GPU utilization and reducing infrastructure costs in Kubernetes clusters. In this article, I discuss how the NVIDIA GPU Operator supports Multi-Instance GPU (MIG) in Kubernetes by exposing isolated GPU partitions as resources. I then present the limitations of static MIG configurations that can lead to inefficiencies and impracticality for cluster ad
Read the rest
mins. Finally, the article introduces Dynamic MIG Partitioning as a more effective solution to manage MIG configurations, improving GPU utilization while reducing the burden on cluster admins. Dynamic GPU partitioning is a component of nos, an opensource I developed to maximize GPU utilization by dynamically partitioning GPUs with NVIDIA MIG and MPS and leveraging Elastic Quotas. https://github.com/nebuly-ai/nos I hope this will be helpful to you as well. And let me know your feedback on this solution!
In [dead]
zanotti·Feb 1, 2023
Hi HN, my name is Michele Zanotti and I’ve just released an open-source called nos https://github.com/nebuly-ai/nos that enables to finally make GPU partitioning dynamic on Kubernetes! (and much more) You can think of the Dynamic GPU Partitioning as a cluster autoscaler for GPUs. Instead of scaling up the number of nodes and GPUs, it dynamically partitions them into smaller “GPU slices”. This ensures that each workload only uses the GPU resources it actually needs, resulting in spare GPU capacity that could be used for other workloads. To partition GPUs, nos leverages Nvidia MIG, as well as the less known MPS, finally making them dynamic. On Towards Data Science you can find a tutorial on how to use the Dynamic GPU Partitioning https://towardsdatascience.com/dynamic-mig-partitioning-in-k... I also wrote a review of the pros and cons of di
Read the rest
fferent technologies for sharing resources among workloads in Kubernetes: time-slicing, MIG, and MPS https://docs.nebuly.com/nos/dynamic-gpu-partitioning/partiti... In addition, this open source also has other components to increase GPU utilization even more. It’s called Elastic Resource Quota management: it allows to increase the number of Pods running on the cluster by allowing teams (namespaces) to borrow quotas of reserved resources from other teams as long as they are not using them. It’s better described in nos documentation https://docs.nebuly.com/nos/overview/ Let me know your thoughts on the project!
In [dead]
michele_zanotti·Jan 31, 2023
Hi HN, my name is Michele Zanotti and I’ve just released an open-source called nos https://github.com/nebuly-ai/nos that enables to finally make GPU partitioning dynamic on Kubernetes! (and much more) You can think of the Dynamic GPU Partitioning as a cluster autoscaler for GPUs. Instead of scaling up the number of nodes and GPUs, it dynamically partitions them into smaller “GPU slices”. This ensures that each workload only uses the GPU resources it actually needs, resulting in spare GPU capacity that could be used for other workloads. To partition GPUs, nos leverages Nvidia MIG, as well as the less known MPS, finally making them dynamic. On Towards Data Science you can find a tutorial on how to use the Dynamic GPU Partitioning https://towardsdatascience.com/dynamic-mig-partitioning-in-k... I also wrote a review of the pros and cons of di
Read the rest
fferent technologies for sharing resources among workloads in Kubernetes: time-slicing, MIG, and MPS https://docs.nebuly.com/nos/dynamic-gpu-partitioning/partiti... In addition, this open source also has other components to increase GPU utilization even more. It’s called Elastic Resource Quota management: it allows to increase the number of Pods running on the cluster by allowing teams (namespaces) to borrow quotas of reserved resources from other teams as long as they are not using them. It’s better described in nos documentation https://docs.nebuly.com/nos/overview/ Let me know your thoughts on the project!
In [dead]
michele_zanotti·Jan 31, 2023
Hi HN, my name is Michele Zanotti and I’ve just released an open-source called nos https://github.com/nebuly-ai/nos that enables to finally make GPU partitioning dynamic on Kubernetes! (and much more) You can think of the Dynamic GPU Partitioning as a cluster autoscaler for GPUs. Instead of scaling up the number of nodes and GPUs, it dynamically partitions them into smaller “GPU slices”. This ensures that each workload only uses the GPU resources it actually needs, resulting in spare GPU capacity that could be used for other workloads. To partition GPUs, nos leverages Nvidia MIG, as well as the less known MPS, finally making them dynamic. On Towards Data Science you can find a tutorial on how to use the Dynamic GPU Partitioning https://towardsdatascience.com/dynamic-mig-partitioning-in-k... I also wrote a review of the pros and cons of di
Read the rest
fferent technologies for sharing resources among workloads in Kubernetes: time-slicing, MIG, and MPS https://docs.nebuly.com/nos/dynamic-gpu-partitioning/partiti... In addition, this open source also has other components to increase GPU utilization even more. It’s called Elastic Resource Quota management: it allows to increase the number of Pods running on the cluster by allowing teams (namespaces) to borrow quotas of reserved resources from other teams as long as they are not using them. It’s better described in nos documentation https://docs.nebuly.com/nos/overview/ Let me know your thoughts on the project!
In [dead]
emilecourth·Jan 31, 2023
Hi HN, my name is Michele Zanotti and I’ve just released an open-source called nos https://github.com/nebuly-ai/nos that enables to finally make GPU partitioning dynamic on Kubernetes! (and much more) You can think of the Dynamic GPU Partitioning as a cluster autoscaler for GPUs. Instead of scaling up the number of nodes and GPUs, it dynamically partitions them into smaller “GPU slices”. This ensures that each workload only uses the GPU resources it actually needs, resulting in spare GPU capacity that could be used for other workloads. To partition GPUs, nos leverages Nvidia MIG, as well as the less known MPS, finally making them dynamic. On Towards Data Science you can find a tutorial on how to use the Dynamic GPU Partitioning https://towardsdatascience.com/dynamic-mig-partitioning-in-k... I also wrote a review of the pros and cons of di
Read the rest
fferent technologies for sharing resources among workloads in Kubernetes: time-slicing, MIG, and MPS https://docs.nebuly.com/nos/dynamic-gpu-partitioning/partiti... In addition, this open source also has other components to increase GPU utilization even more. It’s called Elastic Resource Quota management: it allows to increase the number of Pods running on the cluster by allowing teams (namespaces) to borrow quotas of reserved resources from other teams as long as they are not using them. It’s better described in nos documentation https://docs.nebuly.com/nos/overview/ Let me know your thoughts on the project!
In [dead]
emilecourth·Jan 31, 2023
Hi HN, my name is Michele Zanotti and I’ve just released an open-source called nos https://github.com/nebuly-ai/nos that enables to finally make GPU partitioning dynamic on Kubernetes! (and much more) You can think of the Dynamic GPU Partitioning as a cluster autoscaler for GPUs. Instead of scaling up the number of nodes and GPUs, it dynamically partitions them into smaller “GPU slices”. This ensures that each workload only uses the GPU resources it actually needs, resulting in spare GPU capacity that could be used for other workloads. To partition GPUs, nos leverages Nvidia MIG, as well as the less known MPS, finally making them dynamic. On Towards Data Science you can find a tutorial on how to use the Dynamic GPU Partitioning https://towardsdatascience.com/dynamic-mig-partitioning-in-k... I also wrote a review of the pros and cons of di
Read the rest
fferent technologies for sharing resources among workloads in Kubernetes: time-slicing, MIG, and MPS https://docs.nebuly.com/nos/dynamic-gpu-partitioning/partiti... In addition, this open source also has other components to increase GPU utilization even more. It’s called Elastic Resource Quota management: it allows to increase the number of Pods running on the cluster by allowing teams (namespaces) to borrow quotas of reserved resources from other teams as long as they are not using them. It’s better described in nos documentation https://docs.nebuly.com/nos/overview/ Let me know your thoughts on the project!
In [dead]
Telemaco019·Jan 30, 2023Submission

Show HN: Nos – Open-Source to Maximize GPU Utilization in Kubernetes

Hi HN! I’m Michele Zanotti and today I’m releasing nos, an open-source module to efficiently run GPU workloads on Kubernetes! Nos is meant to increase GPU utilization and cut down infrastructure and operational costs providing 2 main features: 1. Dynamic GPU Partitioning: you can think of this as a cluster autoscaler for GPUs. Instead of scaling up the number of nodes and GPUs, it dynamically partitions them into smaller “GPU slices”. This ensures that each workload only uses the GPU resources it actually needs, resulting in spare GPU capacity that could be used for other workloads. To partition GPUs, nos leverages Nvidia's MPS and MIG [1,2], finally making them dynamic. 2. Elastic Resource Quota management: it allows to increase the number of Pods running on the cluster by allowing teams (namespaces) to borrow quotas of reserved resource
Read the rest
s from other teams as long as they are not using them. Let me know your thoughts on the project in the comments :) Nos addresses some key challenges of Kubernetes tied to the fact that Kubernetes was not designed to support GPU and AI / machine learning workloads. In Kubernetes, GPUs are managed with [3] Nvidia k8s Device Plugin, which has a few major downsides. First, it requires the allocation of an integer number of GPUs per workload, not allowing workloads to request only fractions of GPU. Second, when enabling GPU shared access either with time-slicing or MIG, the device plugin advertises to Kubernetes a fixed set of GPU resources that do not dynamically adapt to the requests of the Pods at each time. This often leads to both underutilized GPUs and pending Pods, and/or the cluster admin having to spend a lot of time looking for workarounds to make the best use of GPUs. For example, consider a company with a k8s cluster with 20 GPUs, where 3 of these GPUs has been reserved to the data science team using Resource Quota objects. In most cases, the workloads of data scientists (notebooks, scripts, etc.) require much less memory/compute resources than those of an entire GPU, yet Kubernetes will force each container to consume an entire GPU. Also, if the team once needs to run a heavy workload, it may want to use as many resources as possible. However, the Resource Quota over their namespace would constrain the team to use at most the 3 GPUs reserved for them, even if the company cluster may be full of unused GPUs! Instead, with nos the data science team would use nos Dynamic GPU Partitioning to request GPU slices so that many workloads can share the same GPU. Also, Elastic Resource Quotas would allow the team to consume more than the 3 reserved GPUs, borrowing quotas from other teams that are not using them. To recap, the team would be able to launch more Pods and the company would likely need fewer nodes. All this with minimal effort required by the cluster admin, who only has to set up nos. Let me know what you think of nos, feedback would be very helpful! :) And please leave a star on GitHub if you like this opensource https://github.com/nebuly-ai/nos Here are some other links that may be useful - Tutorial on how to use Dynamic GPU Partitioning with Nvidia MIG https://towardsdatascience.com/dynamic-mig-partitioning-in-k... - Pros and cons of different technologies for sharing resources among workloads in Kubernetes: time-slicing, MIG, and MPS https://docs.nebuly.com/nos/dynamic-gpu-partitioning/partiti... - Nos documentation https://docs.nebuly.com/nos/overview/ References [1] Multi-Process Service (MPS) https://docs.nvidia.com/deploy/mps/index.html [2] Multi-Instance GPU (MIG) https://docs.nvidia.com/datacenter/tesla/mig-user-guide/ [3] NVIDIA k8s Device Plugin https://github.com/NVIDIA/k8s-device-plugin
2 points · Open discussion

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.