Google Cloud 會計算每個運算執行個體的頻寬，而非每個虛擬網路介面 (vNIC) 或 IP 位址。執行個體的機型會定義其可能的最高輸出速率，但您只能在特定情況下達到該速率。
本頁面列出網路頻寬限制，有助於規劃部署作業。這項指標會根據兩個維度將頻寬分類：
- 輸出或輸入：如本頁所述，輸出和輸入一律是從 Google Cloud 執行個體的角度來看：
- 執行個體傳送的封包會組成 Google Cloud 輸出 (輸出) 流量。
- 傳送至執行個體的封包會組成輸入 (輸入) 流量。 Google Cloud
- 封包的轉送方式：封包可從傳送端執行個體轉送至接收端執行個體，方法是使用下一個躍點位於虛擬私有雲網路內的路由，或虛擬私有雲網路外的路由。
本頁面的所有資訊都適用於 Compute Engine 計算執行個體，以及依附於 Compute Engine 執行個體的產品。舉例來說，Google Kubernetes Engine 節點就是 Compute Engine 執行個體。
影響網路頻寬的設定
額外的虛擬網路介面 (vNIC) 和每個 vNIC 的額外 IP 位址，都不會增加運算執行個體的輸入或輸出頻寬。舉例來說，具有 22 個 vCPU 的 C3 VM 總輸出頻寬上限為 23 Gbps。如果您為 C3 VM 設定兩個 vNIC，VM 的總輸出頻寬仍會限制為 23 Gbps，而不是每個 vNIC 的頻寬為 23 Gbps。
以下各節說明其他運算執行個體設定如何影響網路頻寬。
使用各個 VM 的 Tier_1 網路效能
如要盡可能提高輸入和輸出頻寬，請為運算執行個體設定 Tier_1 網路。
Dynamic Network Interface
動態網路介面會使用父項 vNIC 的頻寬。上層 vNIC 內沒有流量隔離。來自 Dynamic NIC 的網路流量可能會導致與相同上層 vNIC 相關聯的其他 Dynamic NIC 資源不足。如要避免這類衝突，可以使用 Linux 流量控制 (TC) 制定應用程式專屬的流量型態政策。這些政策有助於實作公平性或特定類型的優先順序。如要設定優先順序，請將流量 (例如動態 NIC 的流量) 對應至流量類別，然後將該流量類別對應至服務品質。如需這個方法的範例，請參閱「使用 Red Hat 進行流量控管」。
執行 Windows 作業系統的 Compute Engine 執行個體不支援動態 NIC。
透過 Cloud RDMA 分享頻寬
使用 Cloud RDMA 的應用程式通常會同時使用 TCP 和 RDMA 流量。舉例來說，在高效能運算 (HPC) 工作期間，應用程式通常會在載入和儲存階段使用 TCP 進行通訊，並在運算階段使用 RDMA。使用 GVNIC 處理 TCP 流量的 H4D 執行個體，可提供高達 200 Gbps 的網路頻寬。如果您也將 H4D 執行個體設定為使用 Cloud RDMA，則設定的網路介面會共用網路頻寬。
系統會動態分配 Cloud RDMA 流量和 TCP 流量之間的網路頻寬。GVNIC 網路介面不會將 Cloud RDMA 和 TCP 流量的頻寬限制為 100 Gbps，而是會在未使用 Cloud RDMA 網路介面時，使用所有可用頻寬。同樣地，如果未使用 GVNIC 網路介面，Cloud RDMA 網路介面就能使用所有可用頻寬。如果同時使用這兩種網路介面類型，Cloud RDMA 流量和 TCP 流量會共用頻寬。
頻寬摘要
下表說明封包是從運算執行個體傳送 (輸出) 或由運算執行個體接收 (輸入)，以及封包的轉送方式，並列出這些情況下的最大可能頻寬。
輸出頻寬限制
| 虛擬私有雲網路內的 路由 |
|
|---|---|
| 將流量路由至 虛擬私有雲網路外部 |
|
輸入頻寬限制
| 虛擬私有雲網路內的 路由 |
|
|---|---|
| 將流量路由至 虛擬私有雲網路外部 |
|
輸出頻寬
Google Cloud 使用每個執行個體的最高傳出速率，限制傳出 (Egress) 頻寬。這些速率取決於傳送封包的運算執行個體機型，以及封包目的地是否可透過虛擬私有雲網路內的路由或虛擬私有雲網路外的路由存取。輸出頻寬包括所有執行個體 NIC 發出的封包，以及傳輸至所有 Hyperdisk 和永久磁碟磁碟區的資料。
每個執行個體的輸出頻寬上限
每個執行個體的輸出頻寬上限通常為每個 vCPU 2 Gbps，但視機器系列而定，可能會有差異和例外狀況。下表顯示在虛擬私有雲網路內路由傳送的流量，其輸出頻寬上限範圍。
下表摘要列出各個機器系列的輸出頻寬上限。如要查看每個機型的例項輸出頻寬上限，請前往特定機器家族頁面 (使用表格中各機器系列的連結)。
| 每個執行個體的輸出上限 | ||
|---|---|---|
| 機器系列 | 標準 | Tier_1 網路 |
| C4 和 C4D | 100 Gbps | 200 Gbps |
| C4A | 50 Gbps | 100 Gbps |
| C3 和 C3D | 100 Gbps | 200 Gbps |
| C2 和 C2D | 32 Gbps | 100 Gbps |
| E2 | 16 Gbps | 不適用 |
| E2 共用核心 | 2 Gbps | 不適用 |
| H4D 和 H3 | 200 Gbps | 不適用 |
| M4 | 100 Gbps | 不適用 |
| M3 | 32 Gbps | 100 Gbps |
| M2 | Intel Cascade Lake 以上 CPU：32 Gbps 其他 CPU 平台：16 Gbps |
不適用 |
| M1 | 32 Gbps | 不適用 |
| N4、 N4A 和 N4D | 50 Gbps | 不適用 |
| N2 和 N2D | 32 Gbps | 100 Gbps |
| N1 (不含 1 個 vCPU 的 VM) | Intel Skylake 和後續 CPU：32 Gbps 較早的 CPU 平台：16 Gbps |
不適用 |
| 具有 1 個 vCPU 的 N1 機器類型 | 2 Gbps | 不適用 |
| N1 共用核心 (f1-micro 和 g1-small) | 1 Gbps | 不適用 |
| T2A 和 T2D | 32 Gbps | 不適用 |
| X4 | 100 Gbps | 不適用 |
| Z3 | 100 Gbps | 200 Gbps |
如需加速器最佳化機器系列的網路頻寬資訊，請參閱「網路和 GPU 機器」。
我們無法保證每個執行個體的最高輸出頻寬。實際輸出頻寬可能會因下列因素而降低 (不限於這些因素)：
- 在同時支援兩種網路介面驅動程式的運算執行個體上，使用 VirtIO 而非 gVNIC
- 封包大小
- 通訊協定負擔
- 流程數量
- 運算執行個體客層 OS 的乙太網路驅動程式設定，例如檢查碼卸載和 TCP 分段卸載 (TSO)
- 網路壅塞
- 在永久磁碟 I/O 與其他網路輸出流量競爭的情況下，系統會將 60% 的最大網路頻寬提供給永久磁碟寫入作業，剩下的 40% 則供其他網路輸出流量使用。詳情請參閱「影響磁碟效能的因素」。
如要取得每個執行個體可用的最大輸出頻寬，請按照下列步驟操作：
- 使用較大的機器類型，啟用各個 VM 的 Tier_1 網路效能。
- 使用網路拓撲支援的最大虛擬私有雲網路最大傳輸單位 (MTU)。較大的 MTU 可減少封包標頭的負擔，並提高酬載資料的處理量。
- 如果執行個體和客體作業系統支援，請使用最新版 gVNIC 驅動程式。
- 使用第三代或更新的機器系列，透過 Titanium 將網路處理作業從主機 CPU 卸載。
輸出至虛擬私有雲網路中可路由傳送的目的地
從傳送執行個體的角度來看，對於可透過「虛擬私有雲網路內」的路由存取的目的地 IP 位址，Google Cloud 會使用這些規則限制輸出流量：
- 每個 VM 的輸出頻寬上限：如「每個執行個體的輸出頻寬上限」一節所述，每個執行個體的輸出頻寬上限。
- 每個專案的跨區域輸出頻寬：如果傳送執行個體和內部目的地 (或下一個躍點) 位於不同區域，Google Cloud 會根據傳送執行個體的區域和專案，以及內部目的地 (或下一個躍點) 的區域，強制執行配額。如要進一步瞭解這項配額，請參閱虛擬私有雲配額與限制說明文件中的「從 Compute 執行個體跨區域網路輸出頻寬 (Mbps)」。
- Cloud VPN 和 Cloud Interconnect 限制：從執行個體傳送流量至可透過下一個中繼站 Cloud VPN 通道或 Cloud Interconnect VLAN 連結轉送的內部 IP 位址目的地時，輸出頻寬會受到下列因素限制：
- 每個 Cloud VPN 通道的封包速率和頻寬上限
- 每個 VLAN 連結的封包傳輸速率和頻寬上限
- 如要使用 ECMP 轉送，充分利用多個下一個躍點 Cloud VPN 通道或 Cloud Interconnect VLAN 連結的頻寬，您必須使用多個 TCP 連線 (不重複的 5 元組)。
虛擬私有雲網路中可路由傳送的目的地包括下列所有目的地，從傳送執行個體的角度來看，每個目的地都可透過下一個躍點「不是」預設網際網路閘道的路徑存取：
- 子網路主要 IPv4 和子網路次要 IPv4 位址範圍中的區域內部 IPv4 位址，包括私有 IPv4 位址範圍和私用公開 IPv4 位址範圍，由下列目的地資源使用：
- 接收端執行個體網路介面 (vNIC) 的主要內部 IPv4 位址。(當傳送執行個體連線至另一個執行個體的 vNIC 外部 IPv4 位址時，封包會使用下一個躍點預設網際網路閘道進行路由，因此適用「傳出至虛擬私有雲網路以外目的地的流量」規定)。
- 接收端執行個體 vNIC 別名 IP 範圍內的內部 IPv4 位址。
- 用於通訊協定轉送或內部直通式網路負載平衡器的內部轉送規則內部 IPv4 位址。
- 這些目的地資源的全域內部 IPv4 位址：
- 這些目的地資源使用的內部 IPv6 子網路位址範圍：
- 指派給雙重堆疊或僅支援 IPv6 的接收端執行個體 vNIC 的
/96IPv6 位址範圍中的 IPv6 位址。 - 來自內部轉送規則 IPv6 位址範圍的 IPv6 位址，適用於通訊協定轉送或內部直通式網路負載平衡器。
/96
- 指派給雙重堆疊或僅支援 IPv6 的接收端執行個體 vNIC 的
- 這些目的地資源使用的外部 IPv6 子網路位址範圍，當封包是透過虛擬私有雲網路中的子網路路徑或對等互連子網路路徑轉送，或是透過虛擬私有雲網路中不使用預設網際網路閘道下一個躍點的自訂路徑轉送時：
- 指派給雙重堆疊或僅支援 IPv6 的接收端執行個體 vNIC 的
/96IPv6 位址範圍中的 IPv6 位址。 - 外部轉送規則的 IPv6 位址範圍中的 IPv6 位址，適用於通訊協定轉送或外部直通式網路負載平衡器。
/96
- 指派給雙重堆疊或僅支援 IPv6 的接收端執行個體 vNIC 的
- 可透過下列虛擬私有雲網路路徑存取的其他目的地：
以下清單依據傳送執行個體到內部目的地的流量，從最高可能頻寬到最低排序：
- 位於相同可用區的運算執行個體之間
- 相同區域內不同可用區的運算執行個體之間
- 不同地區的運算執行個體之間
- 從運算執行個體到 Google Cloud API 和服務，使用Private Google Access或從執行個體的外部 IP 位址存取 Google API。包括 Google API 的 Private Service Connect 端點。
輸出至虛擬私有雲網路外部的目的地
從傳送執行個體的角度來看，如果目的地 IP 位址位於虛擬私有雲網路外部， Google Cloud 輸出流量會受限於下列任一速率 (以先達到者為準)：
每個執行個體的輸出頻寬：從運算執行個體到虛擬私有雲網路外部目的地的所有連線，其頻寬上限為「每個執行個體的輸出頻寬上限」和下列其中一個速率的較小值：
- 如果啟用 Tier_1 網路：25 Gbps
- 如果未啟用或不支援 Tier_1 網路：
- G4 執行個體：vCPU 不足 48 個的機器類型總共 7 Gbps，vCPU 達 48 個以上的機器類型總共 28 Gbps
- H4D 和 H3 執行個體為 1 Gbps
- 對於支援多個實體 NIC 的機器系列 (例如 A3、A4、A4X 和 A4X Max 執行個體)，每個實體 NIC 的速度為 7 Gbps
- 所有其他機器系列：7 Gbps
舉例來說，即使
c3-standard-44VM 的單一執行個體最大輸出頻寬為 32 Gbps，從c3-standard-44VM 到外部目的地的單一執行個體輸出頻寬為 25 Gbps 或 7 Gbps，具體取決於是否啟用 Tier_1 網路。每個封包流的輸出速率上限：從運算執行個體到虛擬私有雲網路外部目的地的每個專屬 5 元組連線，頻寬上限為 3 Gbps，但 H4D 和 H3 例外，頻寬上限為 1 Gbps。
每個專案的網際網路輸出頻寬：專案每個區域中，運算執行個體連線至虛擬私有雲網路外部目的地的最大頻寬，是由專案的「網際網路輸出頻寬」配額所定義。
虛擬私有雲網路外部的目的地包括下列所有目的地，每個目的地都可透過傳送執行個體虛擬私有雲網路中的路徑存取，且下一個躍點是預設網際網路閘道：
- 外部 Proxy 網路負載平衡器和外部應用程式負載平衡器的全域外部 IPv4 和 IPv6 位址
- 資源的區域性外部 IPv4 位址，包括 VM vNIC 外部 IPv4 位址、外部通訊協定轉送的外部 IPv4 位址、外部直通式網路負載平衡器，以及 Cloud NAT 閘道的傳回封包。 Google Cloud
- 雙重堆疊或僅限 IPv6 子網路中的區域性外部 IPv6 位址，具有外部 IPv6 位址範圍，由雙重堆疊或僅限 IPv6 執行個體的外部 IPv6 位址、外部通訊協定轉送和外部直通式網路負載平衡器使用。子網路必須位於獨立的非對等互連虛擬私有雲網路。目的地 IPv6 位址範圍必須可透過傳送端執行個體虛擬私有雲網路中的路徑存取，且該路徑的下一個躍點是預設網際網路閘道。如果具有外部 IPv6 位址範圍的雙重堆疊或僅限 IPv6 的子網路位於相同或對等互連的虛擬私有雲網路中，請改為參閱「傳送至虛擬私有雲網路中可路由傳送的目的地」。
- 可透過傳送執行個體虛擬私有雲網路中的靜態路徑存取的其他外部目的地，但路徑的下一個躍點必須是預設網際網路閘道。
如要瞭解哪些 Google Cloud 資源使用哪些類型的外部 IP 位址，請參閱「外部 IP 位址」一文。
輸入頻寬
Google Cloud 處理傳入 (輸入) 頻寬，視傳入封包的路由方式而定，封包會路由至接收端運算執行個體。
可透過虛擬私有雲網路路由傳輸至目的地的輸入流量
接收運算執行個體可處理的傳入封包數量，取決於機器類型、作業系統和其他網路條件。 Google Cloud不會對傳送至執行個體的傳入封包實施任何有目的的頻寬限制 (如果傳入封包是使用虛擬私有雲網路內的路徑傳送)：
- 接收端執行個體虛擬私有雲網路中的子網路路由
- 對等互連虛擬私有雲網路中的對等互連子網路路徑
- 其他網路中的路由，其下一個躍點是位於接收端執行個體虛擬私有雲網路中的 Cloud VPN 通道、Cloud Interconnect (VLAN) 連結或路由器設備執行個體
在虛擬私有雲網路中轉送的封包目的地包括：
- 接收執行個體虛擬網路介面 (vNIC) 的主要內部 IPv4 位址。主要內部 IPv4 位址是區域內部 IPv4 位址，來自子網路的主要 IPv4 位址範圍。
- 接收端執行個體 vNIC 別名 IP 範圍內的內部 IPv4 位址。別名 IP 範圍可來自子網路的主要 IPv4 位址範圍，或其中一個次要 IPv4 位址範圍。
- 指派給雙重堆疊或僅支援 IPv6 的接收端執行個體 vNIC 的
/96IPv6 位址範圍。運算執行個體 IPv6 範圍可來自下列子網路 IPv6 範圍：- 內部 IPv6 位址範圍。
- 外部 IPv6 位址範圍 當傳入封包使用本節先前列出的其中一個虛擬私有雲網路路由，在內部路由至接收執行個體時。
- 轉送規則的內部 IPv4 位址，內部通訊協定轉送會使用這個位址，將流量轉送至接收端執行個體或內部直通式網路負載平衡器，而接收端執行個體是負載平衡器的後端。內部轉送規則的 IPv4 位址來自子網路的主要 IPv4 位址範圍。
- 轉送規則的
/96IPv6 範圍內的內部 IPv6 位址，由內部通訊協定轉送功能使用，轉送至接收端執行個體或內部直通式網路負載平衡器，其中接收端執行個體是負載平衡器的後端。內部轉送規則 IPv6 位址來自子網路的內部 IPv6 位址範圍。 - 外部通訊協定轉送功能使用的轉送規則
/96IPv6 範圍中的外部 IPv6 位址，會轉送至接收端執行個體或外部直通式網路負載平衡器。當傳入的封包使用本節稍早列出的其中一個路徑，在虛擬私有雲網路中轉送時，接收端執行個體就是負載平衡器的後端。外部轉送規則 IPv6 位址來自子網路的外部 IPv6 位址範圍。 - 自訂靜態路徑目的地範圍內的 IP 位址，該路徑使用接收執行個體做為下一個躍點執行個體 (
next-hop-instance或next-hop-address)。 - 如果接收執行個體是內部直通式網路負載平衡器 (
next-hop-ilb) 下一個躍點的後端，則為使用該負載平衡器的自訂靜態路由目的地範圍內的 IP 位址。
將流量傳送至虛擬私有雲網路外部的目的地
Google Cloud 會對使用虛擬私有雲網路「外部」路由傳送至接收端執行個體的封包，實作下列頻寬限制。如果涉及負載平衡，頻寬限制會個別套用至每個接收執行個體。
如果機器系列不支援多個實體 NIC，適用的輸入頻寬限制會一併套用至所有虛擬網路介面 (vNIC)。限制為下列第一個遇到的費率：
- 每秒 1,800,000 個封包
- 30 Gbps
如果機器系列支援多個實體 NIC，適用的輸入頻寬限制會分別套用至每個實體 NIC。限制為下列第一個遇到的費率：
- 每個實體 NIC 每秒 1,800,000 個封包
- 每個實體 NIC 30 Gbps
使用虛擬私有雲網路以外的路徑轉送封包的目的地包括：
- 在其中一個接收端執行個體的網路介面 (NIC) 上，以一對一 NAT 存取權設定指派的外部 IPv4 位址。
- 當傳入封包是使用接收端執行個體虛擬私有雲網路外的路徑轉送時，雙重堆疊或僅限 IPv6 的接收端執行個體 vNIC 指派的
/96IPv6 位址範圍中的外部 IPv6 位址。 - 外部通訊協定轉送使用的轉送規則外部 IPv4 位址，用於接收執行個體或外部直通式網路負載平衡器，其中接收執行個體是負載平衡器的後端。
- 外部通訊協定轉送功能使用的轉送規則
/96IPv6 範圍中的外部 IPv6 位址，會轉送至接收端執行個體或外部直通式網路負載平衡器。當傳入封包是透過 VPC 網路外部的路徑轉送時，接收執行個體必須是負載平衡器的後端。 - Cloud NAT 處理的已建立傳入回應。
使用巨型封包，盡量提高網路頻寬
如要接收及傳送巨型封包，請設定運算執行個體使用的虛擬私有雲網路，並將最大傳輸單元 (MTU) 設為較大的值 (最多 8896)。
MTU 值越高，封包大小就越大，封包標頭的負擔也越小，進而提高酬載資料的總處理量。
您可以在 VM 執行個體上使用 gVNIC 驅動程式 1.3 以上版本，或在裸機執行個體上使用 IDPF 驅動程式，來使用巨型封包。並非所有 Google Cloud 公開映像檔都包含這些驅動程式。如要進一步瞭解作業系統對巨型封包的支援情形，請參閱「作業系統詳細資料」頁面的「網路功能」分頁。
如果您使用的 OS 映像檔未完全支援巨型封包，可以手動安裝 gVNIC 驅動程式 1.3.0 以上版本。Google 建議安裝標示 Latest 的 gVNIC 驅動程式版本，以享有額外功能和錯誤修正。您可以從 GitHub 下載 gVNIC 驅動程式。
如要在客體 OS 中手動更新 gVNIC 驅動程式版本，請參閱「在不支援的作業系統上使用」一節。
巨型封包和 GPU 機器
如果是 GPU 機器類型，請使用巨型封包的建議 MTU 設定。詳情請參閱「巨型封包的建議 MTU 設定」。
接收及傳輸佇列
運算執行個體的每個 NIC 或 vNIC 都會指派多個接收和傳輸佇列，用於處理來自網路的封包。
- 接收佇列 (RX)：接收封包的佇列。當 NIC 從網路接收封包時，會從佇列中選取傳入封包的描述元、處理該描述元，並透過附加至 vCPU 核心的封包佇列，使用中斷將封包交給客體 OS。如果 RX 佇列已滿，且沒有可放置封包的緩衝區，封包就會遭到捨棄。如果應用程式過度使用也附加至所選封包佇列的 vCPU 核心，通常就會發生這種情況。
- 傳輸佇列 (TX)：用於傳輸封包的佇列。訪客 OS 傳送封包時，系統會分配描述元並放入 TX 佇列。接著，NIC 會處理描述元並傳輸封包。
預設佇列分配
除非您明確為 NIC 指派佇列計數，否則可以透過下列方式，模擬演算法 Google Cloud 為每個 vNIC 指派固定數量的 RX 和 TX 佇列：
- 裸機執行個體
- Bare Metal 執行個體只有一個 vNIC，因此佇列數量上限為 16。
- 使用 gVNIC 網路介面的 VM 執行個體
如果是 C4 執行個體，如要提升效能，下列設定會使用固定數量的佇列：
- 如果是具有 2 個 vCPU 的 Linux 執行個體，佇列數為 1。
- 如果是 4 個 vCPU 的 Linux 執行個體，佇列數為 2。
如果是其他機器系列，佇列數量取決於機器系列是否使用 Titanium。
適用於使用 Titanium 的第三代 (不含 M3) 和後續執行個體：
將 vCPU 數量除以 vNIC 數量 (
num_vcpus/num_vnics)， 並捨棄所有餘數。對於未使用 Titanium 的 M3 和第一代/第二代 VM 執行個體：
將 vCPU 數量除以 vNIC 數量，然後將結果除以 2 (
num_vcpus/num_vnics/2)。捨棄任何餘數。
如要完成預設佇列數計算，請按照下列步驟操作：
如果計算出的數字小於 1，請改為為每個 vNIC 指派一個佇列。
判斷計算出的數字是否大於每個 vNIC 的佇列數上限 (
16)。如果計算出的數字大於16，請忽略該數字，並為每個 vNIC 指派 16 個佇列。
- 使用 VirtIO 網路介面或自訂驅動程式的 VM 執行個體
將 vCPU 數量除以 vNIC 數量，並捨棄任何餘數 (
[number of vCPUs/number of vNICs])。如果計算出的數字小於 1，請改為為每個 vNIC 指派一個佇列。
判斷計算出的數字是否大於每個 vNIC 的佇列數上限 (
32)。如果計算出的數字大於32，請忽略該數字，並為每個 vNIC 指派 32 個佇列。
- H4D 執行個體搭配 Cloud RDMA
對於使用 Cloud RDMA 的 H4D 執行個體，每個實體主機都會執行單一運算執行個體。因此執行個體會取得所有可用的佇列配對。H4D 執行個體有 16 個 gVNIC 網路介面佇列，以及 16 個 IRDMA 網路介面佇列。
範例
以下範例說明如何計算 VM 執行個體的預設佇列數量：
如果 VM 執行個體使用 VirtIO，且有 16 個 vCPU 和 4 個 vNIC，則計算出的數字為
[16/4] = 4。 Google Cloud 會為每個 vNIC 指派四個佇列。如果 VM 執行個體使用 gVNIC 搭配 Titanium 卸載，且有 128 個 vCPU 和 2 個 vNIC，則計算出的數字為
[128/2] = 64。Google Cloud 為每個 vNIC 指派每個 vNIC 的佇列數上限，即16。
在 Linux 系統上，您可以使用 ethtool 設定 vNIC，佇列數量少於每個 vNIC 指派的佇列數量 Google Cloud 。
使用 Dynamic Network Interface 時的佇列計數
如果您搭配網路介面使用動態網路介面，佇列計數不會變更。Dynamic NIC 沒有自己的接收和傳輸佇列，而是使用與父項 vNIC 相同的佇列。
為 VM 執行個體自訂佇列分配
使用 Compute Engine API 建立新的運算執行個體時，您可以為每個 vNIC 指派自訂佇列數量 (RX 和 TX 佇列的總數)，而不使用預設佇列分配。
您指定的自訂佇列數量必須符合下列規則：
每個 vNIC 可指派的佇列數量下限為一。
您可以為 VM 執行個體的每個虛擬 NIC 指派佇列，但數量上限取決於驅動程式類型，且不得超過 vCPU 數量或每個虛擬 NIC 的佇列數量上限：
VM 執行個體設定的所有 NIC 的佇列計數總和必須符合下列其中一項規則：
- 最大值為下列兩者中較小的值：
[number of vCPUS][number of vNICs] * [max number of queues per vNIC]
- 如果使用佇列超額訂閱，最大值為：
[number of vNICs] * 16
- 最大值為下列兩者中較小的值：
透過佇列超額訂閱，您可以為 VM 執行個體的每個 vNIC 指派最多 16 個佇列，即使 VM 的佇列總數超過 vCPU 數量也沒關係。如要超額訂閱自訂佇列計數，VM 執行個體必須符合下列條件：
- 將 gVNIC 做為執行個體設定的所有 vNIC 的 vNIC 類型。
- 使用 N2、N2D、C2 或 C2D 機器系列中的機型。
- 已啟用 Tier_1 網路。
- 為 VM 執行個體設定的所有 vNIC 指定自訂佇列計數。
使用佇列超額訂閱時，VM 執行個體的佇列數量上限為 vNIC 數量的 16 倍。因此，如果您為具有 30 個 vCPU 的執行個體設定 6 個 vNIC，則最多可為 VM 執行個體設定 (16 * 6) 個自訂佇列，也就是 96 個。
範例
如果 N2 VM 執行個體有 8 個 vCPU 和 4 個 vNIC：
- 您最多可以在 4 個 vNIC 中指派 8 個佇列。舉例來說，您可以將 1 個佇列指派給
nic0、4 個佇列指派給nic1，以及 3 個佇列指派給nic2。 - 由於使用 N2 的 Tier_1 網路需要至少 32 個 vCPU 的 VM，因此無法超額訂閱佇列。
- 您最多可以在 4 個 vNIC 中指派 8 個佇列。舉例來說，您可以將 1 個佇列指派給
如果 VM 有 48 個 vCPU 和 4 個 NIC：
- 如果使用 NIC 的 virtIO 驅動程式，則最多可跨 4 個 NIC 指派 48 個佇列，任何 vNIC 的佇列計數上限為 32。舉例來說，您可以在每個 vNIC 上有 12 個佇列，也可以在其中一個 NIC 上有 32 個佇列，在另一個 vNIC 上有 14 個佇列，在剩餘 2 個 NIC 上有 1 個佇列。
- 如果使用 gVNIC 驅動程式做為 NIC，則最多可為 4 個 NIC 指派 48 個佇列，且任何 vNIC 的佇列數量上限為 16 個。舉例來說，您可以在 3 個 NIC 上有 15 個佇列，其餘 vNIC 上有 3 個佇列，也可以在每個 vNIC 上有 12 個佇列。
- 如果您使用 gVNIC 和佇列超額訂閱，則每個 vNIC 最多可指派 16 個佇列，總共 64 個佇列。
如果 N2D VM 有 224 個 vCPU 和 8 個 NIC：
- 如果為 NIC 使用 virtIO 驅動程式，則最多可為 8 個 NIC 指派 224 個佇列，且任何 vNIC 的佇列計數上限為 32。舉例來說，您可以在 6 個 NIC 上有 32 個佇列，然後在剩餘的 2 個 NIC 上有 16 個佇列。
- 如果 NIC 使用 gVNIC 驅動程式，則所有 8 個 NIC 的佇列計數上限為 16。佇列計數的總和最多為 128。
您也可以只為部分 vNIC 指派自訂佇列計數，讓 Compute Engine 為其餘 vNIC 指派佇列。每個 vNIC 可指派的佇列數量仍須遵守先前所述的規則。您可以透過下列程序，模擬設定的可行性，以及 Compute Engine 指派給其餘 vNIC 的佇列數量：
計算已自訂佇列指派的 vNIC 佇列總和。
從 vCPU 數量中減去自訂指派佇列的總和。如果差異小於 Compute Engine 必須指派佇列的剩餘 vNIC 數量，Compute Engine 會傳回錯誤，因為每個 vNIC 至少要有一個佇列。
將上一步的差值除以沒有自訂佇列計數的 vNIC 數量，並捨棄所有餘數：
[(number of vCPUs - sum of assigned queues)/(number of remaining vNICs)]這項計算一律會得出整數 (而非分數)，且至少等於 1，因為每個 vNIC 至少要有一個佇列。
Compute Engine 會為每個剩餘的 vNIC 指派佇列計數，方式如下：
- 如果計算出的數量少於每個 vNIC 的佇列數量上限，系統會將佇列數量設為計算出的數量。
- 如果計算出的數量大於每個 vNIC 的佇列數量上限，則 vNIC 的佇列數量會設為佇列數量上限。
範例
假設您有一個 VM，其中有 20 個 vCPU 和 6 個 NIC，且您已為 nic0 指派 5 個佇列、為 nic1 指派 6 個佇列、為 nic2 指派 4 個佇列，並讓 Compute Engine 為 nic3、nic4 和 nic5 指派佇列計數。
自訂指派佇列的總和為
5 + 6 + 4 = 15。Compute Engine 還有
20 - 15 = 5個佇列可指派給其餘三個 vNIC (nic3、nic4、nic5)。差異 (5) 大於沒有自訂佇列計數的 vNIC 數量 (3)。5的差值除以3，並捨棄餘數。因此值為1。由於計算出的數量 (
1) 小於每個 vNIC 的佇列數量上限，因此其餘 vNIC 的佇列數量會設為1。
設定自訂佇列計數
如要建立運算執行個體，並為一或多個 NIC 或 vNIC 使用自訂佇列計數，請完成下列步驟。
在下列程式碼範例中，建立 VM 時，網路介面類型會設為 GVNIC，並啟用各 VM 的 Tier_1 網路效能。您可以運用這些程式碼範例，指定支援的機器類型可用的最大佇列計數和佇列超額訂閱。
gcloud
- 如果您尚未建立虛擬私有雲網路，請為每個要設定的虛擬 NIC 介面建立子網路。
- 使用
gcloud compute instances create指令建立運算執行個體。針對要為執行個體設定的每個 vNIC，重複使用--network-interface旗標，並加入queue-count選項。
gcloud compute instances create INSTANCE_NAME \
--zone=ZONE \
--machine-type=MACHINE_TYPE \
--network-performance-configs=total-egress-bandwidth-tier=TIER_1 \
--network-interface=network=NETWORK_NAME_1,subnet=SUBNET_1,nic-type=GVNIC,queue-count=QUEUE_SIZE_1 \
--network-interface=network=NETWORK_NAME_2,subnet=SUBNET_2,nic-type=GVNIC,queue-count=QUEUE_SIZE_2
更改下列內容：
Terraform
- 如果您尚未建立虛擬私有雲網路，請為每個要設定的虛擬 NIC 介面建立子網路。
使用
google_compute_instance資源，為 vNIC 建立具有特定佇列計數的運算執行個體。針對要為運算執行個體設定的每個 vNIC 重複--network-interface參數，並加入queue-count參數。# Queue oversubscription instance resource "google_compute_instance" "INSTANCE_NAME" { project = "PROJECT_ID" boot_disk { auto_delete = true device_name = "DEVICE_NAME" initialize_params { image="IMAGE_NAME" size = DISK_SIZE type = "DISK_TYPE" } } machine_type = "MACHINE_TYPE" name = "INSTANCE_NAME" zone = "ZONE" network_performance_config { total_egress_bandwidth_tier = "TIER_1" } network_interface { nic_type = "GVNIC" queue_count = QUEUE_COUNT_1 subnetwork_project = "PROJECT_ID" subnetwork = "SUBNET_1" } network_interface { nic_type = "GVNIC" queue_count = QUEUE_COUNT_2 subnetwork_project = "PROJECT_ID" subnetwork = "SUBNET_2" } network_interface { nic_type = "GVNIC" queue_count = QUEUE_COUNT_3 subnetwork_project = "PROJECT_ID" subnetwork = "SUBNET_3"" } network_interface { nic_type = "GVNIC" queue_count = QUEUE_COUNT_4 subnetwork_project = "PROJECT_ID" subnetwork = "SUBNET_4"" } }
更改下列內容：
INSTANCE_NAME：新運算執行個體的名稱PROJECT_ID：要在其中建立執行個體的專案 ID。除非您使用 Shared VPC 網路，否則指定的專案必須與建立所有子網路和網路的專案相同。DEVICE_NAME：要在客層 OS 中與開機磁碟建立關聯的名稱IMAGE_NAME：圖片名稱，例如"projects/debian-cloud/global/images/debian-12-bookworm-v20250311"。DISK_SIZE：開機磁碟大小 (以 GiB 為單位)DISK_TYPE：用於開機磁碟的磁碟類型，例如pd-standardMACHINE_TYPE：執行個體的機型。如要超額訂閱佇列數量，您必須使用 N2、N2D、C2 或 C2D 機器系列的機型，並使用 gVNIC 和 Tier_1 網路。ZONE：要建立執行個體的可用區QUEUE_COUNT：vNIC 的佇列數量，須遵守「自訂佇列分配」一節所述規則。SUBNET_*：網路介面連線的子網路名稱
REST
- 如果您尚未建立虛擬私有雲網路，請為每個要設定的虛擬 NIC 介面建立子網路。
使用
instances.insert方法，為 vNIC 建立具有特定佇列計數的運算執行個體。您可以重複使用networkInterfaces屬性，設定多個網路介面。POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances { "name": "INSTANCE_NAME", "machineType": "machineTypes/MACHINE_TYPE", "networkPerformanceConfig": { "totalEgressBandwidthTier": TIER_1 }, "networkInterfaces": [ { "nicType": gVNIC, "subnetwork":"regions/region/subnetworks/SUBNET_1", "queueCount": "QUEUE_COUNT_1" } ], "networkInterfaces": [ { "nicType": gVNIC, "subnetwork":"regions/region/subnetworks/SUBNET_2", "queueCount": "QUEUE_COUNT_2" } ] }更改下列內容：
佇列分配和變更機型
建立運算執行個體時，系統會預設分配佇列，您也可以使用 Compute Engine API 建立新的運算執行個體時，為每個虛擬網路介面卡 (vNIC) 指派自訂佇列數量。預設或自訂 vNIC 佇列指派作業只會在建立運算執行個體時設定。如果執行個體的 vNIC 使用預設佇列計數，您可以變更機型。如果變更後的機型 vCPU 數量不同，系統會根據新的機型，重新計算執行個體的預設佇列數。
如果 VM 的 vNIC 使用自訂的非預設佇列計數，則可以使用 Google Cloud CLI 或 Compute Engine API 更新執行個體屬性，藉此變更機型。如果產生的 VM 支援與原始執行個體相同的每個 vNIC 佇列計數，轉換就會成功。如果 VM 使用 VirtIO-Net 介面，且每個 vNIC 的自訂佇列計數高於 16，則無法將機型變更為第三代或更新的機型，因為這些機型只使用 gVNIC。您可以按照「將工作負載移至新的運算執行個體」一文中的操作說明，將 VM 遷移至第三代或更新的機型。
後續步驟
- 建立並啟動 VM 執行個體。
- 為運算執行個體設定各 VM 的 Tier_1 網路效能。
- 瞭解如何最佳化 TCP 以提升網路效能