K8s 1.30+大模型推論平台部署實戰：GPU彈性排程與vLLM生產級最佳化全指南

DevOps

摘要

  • 掌握Kubernetes 1.30+ DRA（動態資源分配）機制，實現多GPU場景下的精細化排程與顯存隔離
  • 基於vLLM+KEDA建構大模型推論彈性擴縮平台，實現從0到N的秒級自動擴縮容
  • 生產級LLM推論平台全鏈路實戰：模型載入最佳化、KV Cache管理、流量路由與灰度發佈

目錄

一、大模型推論平台的架構設計

1.1 推論平台核心元件

2026年，大模型推論平台已成為企業AI基礎設施的核心。一個生產級LLM推論平台需要涵蓋從模型載入到請求回應的全鏈路能力，其核心元件包括：

┌──────────────────────────────────────────────────────┐
│                   API Gateway                         │
│        限流 · 認證 · 路由 · 負載平衡 · 灰度            │
├──────────────────────────────────────────────────────┤
│                Inference Engine                       │
│     vLLM / TGI / Triton Inference Server             │
│     Continuous Batching · PagedAttention · Speculative│
├──────────────────────────────────────────────────────┤
│              Model Management                         │
│   模型儲存庫 · 版本管理 · 熱載入 · 量化轉換            │
├──────────────────────────────────────────────────────┤
│              GPU Resource Layer                       │
│   DRA排程 · 顯存池化 · MIG分區 · 多卡並行             │
├──────────────────────────────────────────────────────┤
│              Autoscaling & Scheduling                 │
│   KEDA HPA · Pod優先順序 · 排程拓樸 · 預測性擴縮      │
└──────────────────────────────────────────────────────┘

API Gateway層負責請求的統一入口管理，包括限流、認證、路由和灰度發佈。Inference Engine層是推論的核心，vLLM憑藉其Continuous Batching和PagedAttention機制成為2026年最主流的開源推論引擎。Model Management層管理模型的版本、載入和轉換。GPU Resource Layer透過K8s DRA機制實現GPU的精細化排程。Autoscaling層基於KEDA實現基於自訂指標的彈性擴縮。

1.2 推論模式選擇

大模型推論存在兩種核心模式，選擇合適的模式直接影響平台成本和效能：

同步推論（Online Serving）：使用者請求即時回應，延遲敏感（P99 < 2s），適用於對話、補全等互動場景。需要常駐GPU資源，成本較高但體驗最佳。

非同步推論（Offline Batch）：批次提交推論任務，吞吐優先，適用於資料處理、內容生成等非即時場景。可利用Spot執行個體和閒置GPU，成本顯著降低。

生產環境通常採用混合模式：白天線上推論佔主導，夜間利用閒置GPU資源執行批次任務，最大化GPU使用率。

1.3 關鍵效能指標

指標 目標值 說明
Time to First Token (TTFT) < 200ms 首Token延遲
Token Generation Rate > 100 tok/s 單卡生成速率
GPU Utilization > 80% GPU運算使用率
GPU Memory Utilization > 90% 顯存使用率
Request Success Rate > 99.9% 請求成功率
Cold Start Time < 60s 模型冷啟動時間

二、K8s 1.30+ DRA GPU排程深度實踐

2.1 DRA機制核心概念

Kubernetes 1.30正式引入的Dynamic Resource Allocation（DRA）機制，徹底改變了GPU等加速器的排程方式。此前透過Extended Resource和Device Plugin的方案存在三大痛點：無法分片——一張GPU只能分配給一個Pod；無法共享——不同Pod無法安全共享同一GPU；無法動態調整——分配後無法線上調整資源配額。

DRA透過ResourceClaim和ResourceClass兩個核心API解決了這些問題：

  • ResourceClaim：宣告式地描述工作負載所需的資源（如「需要2張A100 GPU，各40GB顯存」）
  • ResourceClass：定義資源的供應策略（如「優先分配A100，不足時降級到A10G」）
  • ResourceHandle：驅動回傳的資源控制代碼，包含裝置ID、拓樸資訊等
apiVersion: resource.k8s.io/v1beta1
kind: ResourceClass
metadata:
  name: nvidia-a100
driverName: gpu.resource.k8s.io/nvidia
parametersRef:
  apiGroup: gpu.resource.k8s.io
  kind: GPUParameters
  name: a100-config
---
apiVersion: gpu.resource.k8s.io/v1beta1
kind: GPUParameters
metadata:
  name: a100-config
spec:
  gpuType: "A100-SXM4-80GB"
  migStrategy: "single"
  memoryLimit: "40Gi"
  priority: 100
  fallbackGpuType: "A10G"
---
apiVersion: v1
kind: Pod
metadata:
  name: llm-inference-server
spec:
  containers:
  - name: vllm
    image: vllm/vllm-openai:v0.8.0
    resources:
      claims:
      - name: gpu-claim
  resourceClaims:
  - name: gpu-claim
    resourceClaimTemplateName: a100-claim-template
---
apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaimTemplate
metadata:
  name: a100-claim-template
spec:
  spec:
    resources:
    - name: nvidia-a100
      resourceClassName: nvidia-a100
      allocationMode: WaitForFirstConsumer

2.2 GPU顯存池化與MIG分區

在多租戶場景下，GPU顯存池化是提升資源使用率的關鍵。NVIDIA MIG（Multi-Instance GPU）允許將一張A100劃分為最多7個獨立執行個體，每個執行個體擁有獨立的GPU核心和顯存。

apiVersion: gpu.resource.k8s.io/v1beta1
kind: GPUParameters
metadata:
  name: a100-mig-config
spec:
  gpuType: "A100-SXM4-80GB"
  migStrategy: "mixed"
  migProfiles:
  - name: "1g.10gb"
    count: 4
    memoryLimit: "10Gi"
    suitableModels:
    - "qwen3-4b"
    - "chatglm3-6b"
  - name: "2g.20gb"
    count: 2
    memoryLimit: "20Gi"
    suitableModels:
    - "qwen3-14b"
    - "llama3-8b"
  - name: "3g.40gb"
    count: 1
    memoryLimit: "40Gi"
    suitableModels:
    - "qwen3-32b"
    - "llama3-70b-awq"

2.3 多卡並行排程

大模型推論常需要多卡並行。K8s 1.30+的DRA支援拓樸感知排程，確保分配的GPU位於同一NUMA節點或NVLink域內，避免跨節點通訊的效能損失。

package scheduler

import (
    "k8s.io/kubernetes/pkg/scheduler/framework"
)

type GPUScheduler struct {
    topologyAware bool
    numaNodes     map[int][]GPUDevice
}

type GPUDevice struct {
    ID        int
    NodeID    int
    MemoryGB  int
    BusID     string
    NVLink    []int
}

func (s *GPUScheduler) Score(ctx context.Context, state *framework.CycleState, pod *v1.Pod, nodeName string) (int64, *framework.Status) {
    gpuClaim := extractGPUClaim(pod)
    if gpuClaim == nil {
        return 0, nil
    }

    devices := s.getAvailableDevices(nodeName)
    if len(devices) < gpuClaim.Count {
        return 0, nil
    }

    selected := s.selectOptimalDevices(devices, gpuClaim.Count)
    
    score := int64(0)
    if s.areOnSameNVLinkDomain(selected) {
        score += 100
    } else if s.areOnSameNUMANode(selected) {
        score += 70
    } else {
        score += 30
    }

    if s.hasEnoughMemory(selected, gpuClaim.MemoryPerGPU) {
        score += 50
    }

    return score, nil
}

func (s *GPUScheduler) areOnSameNVLinkDomain(devices []GPUDevice) bool {
    if len(devices) <= 1 {
        return true
    }
    firstNode := devices[0].NodeID
    for _, d := range devices[1:] {
        if d.NodeID != firstNode {
            return false
        }
        connected := false
        for _, link := range d.NVLink {
            if link == devices[0].ID {
                connected = true
                break
            }
        }
        if !connected {
            return false
        }
    }
    return true
}

三、vLLM推論引擎生產級最佳化

3.1 Continuous Batching與PagedAttention

vLLM的核心創新在於Continuous Batching和PagedAttention兩個機制。Continuous Batching允許在當前批次執行過程中動態插入新請求，避免了傳統Static Batching的等待浪費。PagedAttention借鑑作業系統虛擬記憶體的分頁機制，將KV Cache劃分為固定大小的Block，按需分配和回收，解決了KV Cache的顯存碎片問題。

生產級vLLM部署的關鍵參數組態：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-qwen3-72b
  namespace: llm-inference
spec:
  replicas: 2
  selector:
    matchLabels:
      app: vllm-qwen3-72b
  template:
    metadata:
      labels:
        app: vllm-qwen3-72b
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "8000"
        prometheus.io/path: "/metrics"
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:v0.8.0
        command:
        - python
        - -m
        - vllm.entrypoints.openai.api_server
        - --model
        - Qwen/Qwen3-72B-Instruct-AWQ
        - --tensor-parallel-size
        - "4"
        - --gpu-memory-utilization
        - "0.92"
        - --max-model-len
        - "32768"
        - --max-num-seqs
        - "256"
        - --block-size
        - "16"
        - --swap-space
        - "8"
        - --enable-prefix-caching
        - --enable-chunked-prefill
        - --speculative-decoding-model
        - Qwen/Qwen3-7B-Instruct
        - --num-speculative-tokens
        - "5"
        - --port
        - "8000"
        ports:
        - containerPort: 8000
        resources:
          claims:
          - name: gpu-claim
        env:
        - name: VLLM_WORKER_MULTIPROC_METHOD
          value: "ray"
        - name: VLLM_ATTENTION_BACKEND
          value: "FLASHINFER"
        volumeMounts:
        - name: model-cache
          mountPath: /root/.cache/huggingface
        - name: shm
          mountPath: /dev/shm
      volumes:
      - name: model-cache
        persistentVolumeClaim:
          claimName: model-cache-pvc
      - name: shm
        emptyDir:
          medium: Memory
          sizeLimit: "16Gi"

3.2 推測解碼最佳化

推測解碼（Speculative Decoding）是2026年LLM推論最重要的最佳化技術之一。核心思想是使用一個小模型（Draft Model）快速生成候選Token序列，再由大模型（Verifier Model）並行驗證，接受正確的Token、拒絕錯誤的Token。

在vLLM中啟用推測解碼需要組態Draft Model和推測長度。實際測試表明，對於Qwen3-72B + Qwen3-7B的組合，在對話場景下可實現1.5x-2.5x的加速比，且不損失輸出品質。

from vllm import LLM, SamplingParams

llm = LLM(
    model="Qwen/Qwen3-72B-Instruct-AWQ",
    speculative_model="Qwen/Qwen3-7B-Instruct",
    num_speculative_tokens=5,
    speculative_max_model_len=32768,
    tensor_parallel_size=4,
    gpu_memory_utilization=0.92,
    enable_prefix_caching=True,
    enable_chunked_prefill=True,
)

sampling_params = SamplingParams(
    temperature=0.7,
    top_p=0.9,
    max_tokens=2048,
)

outputs = llm.generate(
    prompts=["解釋量子計算的基本原理"],
    sampling_params=sampling_params,
)

3.3 量化與模型壓縮

模型量化是降低推論成本的核心手段。2026年主流的量化方案包括：

量化方案 精度損失 顯存節省 推論加速 適用場景
AWQ 4bit < 1% 60-70% 1.2-1.5x 生產首選
GPTQ 4bit 1-2% 60-70% 1.1-1.3x 相容性好
FP8 < 0.5% 50% 1.5-2x H100/H200
GGUF Q4_K_M 1-3% 65-75% 1.0-1.2x CPU推論

AWQ（Activation-aware Weight Quantization）是當前生產環境的首選方案，透過保護重要權重通道來最小化量化損失。對於Qwen3-72B模型，AWQ 4bit量化後僅需約38GB顯存，可在2張A100-80GB上執行，相比FP16的144GB需求大幅降低。

四、KEDA彈性擴縮與流量路由

4.1 KEDA自訂指標擴縮

Kubernetes原生HPA僅支援CPU/記憶體指標，無法滿足LLM推論場景的彈性擴縮需求。KEDA（Kubernetes Event-Driven Autoscaling）支援基於自訂指標的擴縮，是LLM推論平台彈性擴縮的最佳選擇。

核心擴縮指標：

  • 請求佇列深度：vLLM暴露的vllm:num_requests_waiting指標，反映待處理請求數
  • GPU使用率：DCGM_FI_DEV_GPU_UTIL指標，反映GPU運算資源使用率
  • 平均請求延遲：自訂指標，反映服務品質
  • 活躍序列數：vllm:num_requests_running指標，反映當前處理中的請求數
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: vllm-scaler
  namespace: llm-inference
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: vllm-qwen3-72b
  minReplicaCount: 1
  maxReplicaCount: 10
  cooldownPeriod: 120
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus.monitoring:9090
      metricName: vllm_requests_waiting
      threshold: "10"
      query: |
        sum(vllm:num_requests_waiting{deployment="vllm-qwen3-72b"})
  - type: prometheus
    metadata:
      serverAddress: http://prometheus.monitoring:9090
      metricName: vllm_avg_latency
      threshold: "2000"
      query: |
        histogram_quantile(0.95, 
          sum(rate(vllm:e2e_request_latency_seconds_bucket{deployment="vllm-qwen3-72b"}[2m]))
          by (le)
        ) * 1000
  advanced:
    horizontalPodAutoscalerConfig:
      behavior:
        scaleUp:
          stabilizationWindowSeconds: 30
          policies:
          - type: Pods
            value: 2
            periodSeconds: 60
        scaleDown:
          stabilizationWindowSeconds: 300
          policies:
          - type: Pods
            value: 1
            periodSeconds: 120

4.2 預測性擴縮

基於歷史流量模式的預測性擴縮是2026年的前沿實踐。透過分析過去N天的請求量時間序列，使用Prophet或LSTM模型預測未來1小時的流量，提前擴容以應對流量高峰。

import pandas as pd
from prophet import Prophet
from kubernetes import client, config

class PredictiveScaler:
    def __init__(self, deployment_name: str, namespace: str):
        self.deployment_name = deployment_name
        self.namespace = namespace
        config.load_incluster_config()
        self.apps_v1 = client.AppsV1Api()

    def predict_and_scale(self, metrics_df: pd.DataFrame):
        model = Prophet(
            changepoint_prior_scale=0.05,
            seasonality_prior_scale=10,
            daily_seasonality=True,
            weekly_seasonality=True,
        )
        model.fit(metrics_df)
        future = model.make_future_dataframe(periods=60, freq='min')
        forecast = model.predict(future)
        
        predicted_requests = forecast.tail(60)['yhat'].max()
        current_replicas = self._get_current_replicas()
        
        target_replicas = max(1, int(predicted_requests / 50))
        target_replicas = min(target_replicas, 10)
        
        if target_replicas != current_replicas:
            self._scale_to(target_replicas)
            print(f"Scaled from {current_replicas} to {target_replicas} replicas")

    def _get_current_replicas(self) -> int:
        deployment = self.apps_v1.read_namespaced_deployment(
            self.deployment_name, self.namespace
        )
        return deployment.spec.replicas

    def _scale_to(self, replicas: int):
        self.apps_v1.patch_namespaced_deployment_scale(
            self.deployment_name,
            self.namespace,
            body={"spec": {"replicas": replicas}},
        )

4.3 流量路由與負載平衡

LLM推論的流量路由需要考慮模型版本、請求優先順序和後端負載。推薦使用Gateway API替代Ingress，實現更精細的流量控制。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: llm-route
  namespace: llm-inference
spec:
  parentRefs:
  - name: llm-gateway
  rules:
  - matches:
    - headers:
      - type: Exact
        name: X-Model-Version
        value: canary
    backendRefs:
    - name: vllm-qwen3-72b-canary
      port: 8000
      weight: 100
  - backendRefs:
    - name: vllm-qwen3-72b-stable
      port: 8000
      weight: 90
    - name: vllm-qwen3-72b-canary
      port: 8000
      weight: 10

五、模型載入與KV Cache管理

5.1 模型熱載入與預載入

大模型的冷啟動時間是影響使用者體驗的關鍵因素。Qwen3-72B AWQ量化模型從磁碟載入到GPU約需30-60秒，透過以下策略可最佳化至5-10秒：

模型預載入：在Pod啟動時即載入模型到GPU，透過Readiness Probe確認模型就緒後才接入流量。

模型快取：使用PVC持久化模型檔案，避免每次擴容都從遠端下載。配合ModelCache DaemonSet在叢集節點上預快取常用模型。

分層載入：先載入模型結構（幾MB），再按需載入權重層。對於對話場景，可先載入Embedding層和前幾層Transformer，快速回應首個Token。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: model-cache-daemon
  namespace: llm-inference
spec:
  selector:
    matchLabels:
      app: model-cache-daemon
  template:
    metadata:
      labels:
        app: model-cache-daemon
    spec:
      containers:
      - name: cache-loader
        image: python:3.11-slim
        command:
        - bash
        - -c
        - |
          pip install huggingface_hub
          python -c "
          from huggingface_hub import snapshot_download
          models = [
              'Qwen/Qwen3-72B-Instruct-AWQ',
              'Qwen/Qwen3-14B-Instruct-AWQ',
              'Qwen/Qwen3-7B-Instruct',
          ]
          for m in models:
              snapshot_download(m, cache_dir='/models')
          "
          sleep infinity
        volumeMounts:
        - name: model-cache
          mountPath: /models
      volumes:
      - name: model-cache
        hostPath:
          path: /data/model-cache
          type: DirectoryOrCreate

5.2 KV Cache最佳化

KV Cache是大模型推論中佔用顯存最大的部分。對於32K上下文長度的請求，KV Cache可能佔用超過10GB顯存。最佳化策略包括：

Prefix Caching：對於共享相同System Prompt的請求，快取公共前綴的KV Cache，避免重複運算。vLLM透過--enable-prefix-caching啟用。

KV Cache量化：將KV Cache從FP16量化為FP8或INT8，顯存佔用減半，精度損失可忽略。

Sliding Window Attention：對於超長上下文，只保留最近W個Token的KV Cache，丟棄更早的KV對。適用於長文件摘要等場景。

from vllm import LLM, SamplingParams

llm = LLM(
    model="Qwen/Qwen3-72B-Instruct-AWQ",
    tensor_parallel_size=4,
    gpu_memory_utilization=0.92,
    max_model_len=32768,
    enable_prefix_caching=True,
    kv_cache_dtype="fp8",
    block_size=16,
)

5.3 顯存池化與共享

在多模型共部署場景下，不同模型的推論Pod可能存在顯存浪費。透過GPU顯存池化技術，將GPU顯存抽象為共享資源池，按需分配和回收。

NVIDIA的GPU Operator配合MPS（Multi-Process Service）允許多個行程共享同一GPU的算力，同時保證顯存隔離。對於小模型推論場景（如7B-14B），一張A100可同時執行4-6個推論執行個體。

六、灰度發佈與A/B測試

6.1 模型版本灰度發佈

大模型推論平台的灰度發佈需要同時管理多個模型版本，逐步切換流量。核心流程：

  1. 部署新版本：在新Deployment中部署新模型版本，不接入流量
  2. 冒煙測試：透過內部測試端點驗證新模型的輸出品質和延遲
  3. 金絲雀發佈：將1%流量路由到新版本，監控錯誤率和延遲
  4. 漸進放量：逐步增加新版本流量佔比（1% → 5% → 20% → 50% → 100%）
  5. 全量切換：確認無異常後，將全部流量切換到新版本
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: llm-canary-route
  namespace: llm-inference
spec:
  parentRefs:
  - name: llm-gateway
  rules:
  - backendRefs:
    - name: vllm-qwen3-72b-v2
      port: 8000
      weight: 5
    - name: vllm-qwen3-72b-v1
      port: 8000
      weight: 95
  filters:
  - type: ResponseHeaderModifier
    responseHeaderModifier:
      set:
      - name: X-Model-Version
        value: v2

6.2 A/B測試與效果評估

大模型A/B測試的核心挑戰是輸出品質評估。不同於傳統軟體的確定性輸出，LLM的輸出具有隨機性，需要統計方法評估：

  • 人工評估採樣：對兩個版本的輸出進行人工打分，計算統計顯著性
  • LLM-as-Judge：使用GPT-4等強模型作為裁判，自動評估輸出品質
  • 業務指標對比：對比兩個版本的使用者滿意度、對話輪次、任務完成率等業務指標

七、監控警示與故障排查

7.1 核心監控指標

大模型推論平台的監控需要涵蓋基礎設施、推論引擎和業務三個層面：

基礎設施層：

  • GPU使用率、顯存使用率、GPU溫度
  • 節點CPU/記憶體/網路IO
  • GPU Xid錯誤（硬體故障）

推論引擎層：

  • 請求延遲P50/P95/P99
  • 吞吐量（tokens/s）
  • 請求佇列深度
  • KV Cache命中率
  • 推測解碼接受率

業務層：

  • 請求成功率
  • 平均對話輪次
  • 使用者滿意度評分
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: llm-inference-alerts
  namespace: llm-inference
spec:
  groups:
  - name: llm.rules
    rules:
    - alert: LLMHighLatency
      expr: histogram_quantile(0.99, sum(rate(vllm:e2e_request_latency_seconds_bucket[5m])) by (le)) > 5
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "LLM inference P99 latency exceeds 5s"
    - alert: LLMQueueBacklog
      expr: sum(vllm:num_requests_waiting) > 50
      for: 3m
      labels:
        severity: critical
      annotations:
        summary: "LLM request queue backlog exceeds 50"
    - alert: GPUMemoryExhaustion
      expr: DCGM_FI_DEV_FB_USED / DCGM_FI_DEV_FB_TOTAL > 0.95
      for: 2m
      labels:
        severity: critical
      annotations:
        summary: "GPU memory usage exceeds 95%"
    - alert: GPUXidError
      expr: increase(DCGM_FI_DEV_XID_ERRORS[5m]) > 0
      labels:
        severity: critical
      annotations:
        summary: "GPU Xid error detected, possible hardware failure"

7.2 常見故障排查

故障現象 可能原因 排查方法
OOM Kill KV Cache過大/模型顯存超限 檢查gpu_memory_utilization和max_model_len
請求逾時 佇列積壓/GPU使用率過高 檢查num_requests_waiting和GPU使用率
輸出亂碼 模型載入不完整/量化錯誤 驗證模型檔案完整性，檢查量化組態
GPU使用率低 Batch Size過小/請求不均勻 調整max_num_seqs，檢查流量分佈
冷啟動慢 模型未快取/網路頻寬不足 檢查PVC掛載，啟用模型預載入

7.3 日誌與追蹤

LLM推論請求的全鏈路追蹤需要涵蓋從API Gateway到推論引擎的完整路徑。推薦使用OpenTelemetry SDK在vLLM中注入Trace Context，實現請求級別的端對端追蹤。

八、總結與展望

Kubernetes 1.30+為大模型推論平台提供了強大的GPU排程和彈性擴縮能力。本文從架構設計、DRA GPU排程、vLLM最佳化、KEDA彈性擴縮、KV Cache管理、灰度發佈和監控警示七個維度，系統性地闡述了生產級LLM推論平台的建構方法。

關鍵要點回顧：

  1. DRA排程：K8s 1.30+的DRA機制實現了GPU的分片、共享和動態調整，是LLM推論平台GPU管理的基礎
  2. vLLM最佳化：Continuous Batching + PagedAttention + 推測解碼的組合，可將推論吞吐提升2-5倍
  3. 彈性擴縮：KEDA基於請求佇列深度和延遲的自訂指標擴縮，比原生HPA更適合LLM場景
  4. KV Cache管理：Prefix Caching + KV Cache量化 + Sliding Window Attention，是顯存最佳化的三板斧
  5. 灰度發佈：Gateway API的權重路由 + 統計評估，實現模型版本的平滑切換

未來，隨著K8s DRA生態的成熟和GPU硬體的疊代（B200、GB200），LLM推論平台將向更高密度、更低成本的方向發展。FP8推論、KV Cache offload到CPU/SSD、多叢集聯邦排程等技術將進一步降低推論成本。

相關閱讀

權威參考

本站提供瀏覽器本地工具，免註冊即可試用 →

#K8s 1.30#大模型推理#LLM部署#GPU调度#弹性伸缩#2026