Quota is the only artifact in this build that outlives the cluster. Azure grants it per subscription and it survives resource group deletion, so the walkthrough treats it as a one-time step rather than something you redo on every rebuild [8]. Everything downstream is a command. This one is a ticket a person at Azure approves, and the author's advice is that it has to happen before you plan to build, because without approval `az aks nodepool add` for a GPU fails outright [10]. New subscriptions sit at 0 vCPUs for GPU families, which the article attributes to cost and abuse potential [9].
The 108 is arithmetic, not an Azure constant. It is three nodes at 36 vCPUs, chosen to match the `--max-count 3` set on the GPU pool [7]. For that figure to transfer to your build you need the same VM family at 36 vCPUs per node, the same region, which is westus here [6], and the same ceiling of three. Note that 3 x 36 is exactly 108, so there is no headroom above the declared ceiling: a fourth node would need 144 vCPUs [20], and that is another approval round [10].
Scale-from-zero is what forces the taint and label to be declared at pool creation rather than found later. With no node running, the cluster autoscaler decides whether a pending pod would fit by reading the pool's declared taints, labels and VM size, then provisions a node if it would [14]. There is no running node to inspect, so the pool spec is the only evidence the autoscaler has. The three placement primitives then do separate jobs: the taint repels pods by default, a toleration lifts that block for one pod, and the `nodeSelector` steers it, which is why the vLLM pod spec carries both the toleration and the selector [15].
After that comes the part with no error message. AKS does not install the NVIDIA device plugin, and without it a GPU node never advertises `nvidia.com/gpu` as allocatable, so a pod requesting one stays Pending indefinitely [16]. The upstream DaemonSet at v0.17.1 tolerates only the standard `nvidia.com/gpu` taint, not the custom `sku=gpu` taint from the pool creation step, so it needs a JSON patch to schedule onto the node at all [17]. The taint that keeps CPU pods off your GPU also keeps the driver plugin off it.
The first link in the chain is the one this piece delegates: the VRAM requirement is worked out in a companion article on choosing the right GPU [19]. What lands on the node here is an AWQ-quantised Qwen2.5-7B served by `vllm/vllm-openai:latest` [3] on a single A10 with 24 GB [2]. If your model does not fit in 24 GB, the SKU changes, the vCPUs per node change with it, and the 108 you queued behind manual approval was the wrong number to ask for. That is the case for pricing the model against VRAM before you open the quota form, which is exactly the order the article states: model, VRAM requirement, GPU SKU, region availability, quota [5].
