跳转到内容

GPUStack 面试题库

30 道题
分类
LLM
题目数
30 道
已阅读 0 / 30 题
1 GPUStack 的核心定位与架构设计理念

答案:

GPUStack 是一个开源的 GPU 集群管理器,核心定位为异构 GPU 资源池化与 LLM 推理统一编排平台。通过 Server-Worker 分布式架构,在基础设施层之上抽象出模型部署、调度与 Serving 的控制面,对外提供 OpenAI 兼容 API。

分层架构:

层级组件职责
接入层AI Gateway(Higress)统一入口、请求路由、负载均衡、认证鉴权
控制面Server(FastAPI + Controllers)API 服务、模型调度、Worker 管理、事件总线
计算面Worker(ServeManager + Runtime)GPU 发现、模型 Serving、指标上报、心跳同步
数据层SQL Database(PostgreSQL/SQLite)模型、Worker、实例、用户等持久化存储
推理层可插拔推理引擎(vLLM/SGLang/TensorRT-LLM/MindIE)实际推理计算

核心设计理念:

  • 引擎无关:通过可插拔 Backend 机制解耦推理引擎,vLLM、SGLang、TensorRT-LLM 等均可接入,模型部署时自动选择最优引擎。
  • 声明式管理:模型部署通过声明期望副本数(replicas)、Backend、Placement Strategy 等参数,Controller 通过 Reconcile Loop 将现状向期望收敛。
  • 异构统一:支持 NVIDIA、AMD、Ascend NPU、Hygon DCU、MThreads、Iluvatar、MetaX、Cambricon MLU 等多种加速器,统一资源池化管理。
  • 模型目录驱动:内置预调优模型目录,覆盖 Qwen3、DeepSeek-R1/V3、GLM-4.x 等,支持一键部署,自动配置最优推理参数。
2 GPUStack 的架构组件(Server / Worker / Controller)

答案:

GPUStack 的核心组件分为三类:Server 控制面组件、Worker 计算面组件、Controller 调和控制器。

Server 组件矩阵:

组件职责关键技术
API ServerRESTful 接口服务,处理客户端请求FastAPI
Scheduler模型实例调度,Filter → Score → Select 流水线placement_scorer.py
ModelController调和期望副本数与实际副本数(sync_replicas)EventBus 订阅 Model 事件
ModelInstanceController管理实例生命周期,触发模型文件下载EventBus 订阅 ModelInstance 事件
WorkerController监控 Worker 心跳,标记 UNREACHABLE 状态心跳超时检测
AI Gateway请求路由与负载均衡Higress + Wasm 插件

Worker 组件矩阵:

组件职责
WorkerManager向 Server 注册,每 30 秒同步状态与资源信息
ServeManager管理本节点模型实例生命周期,映射 Backend 到推理引擎实现
GPUStack Runtime检测 GPU 设备,与容器运行时交互部署模型实例
MetricExporter导出 Prometheus 兼容指标(端口 10162)
ModelFileManager从 HuggingFace / ModelScope 下载模型权重(并发限制默认 5)

Controller 架构:

Controller 作为后台异步任务运行,通过 EventBus 订阅资源变更事件,执行调和逻辑:

Model 变更事件 → ModelController.sync_replicas()
                   ├── 期望副本 > 实际副本 → 创建 ModelInstance (PENDING)
                   └── 期望副本 < 实际副本 → 按 Scale-Down 评分移除实例

ModelInstance 变更事件 → ModelInstanceController
                          ├── INITIALIZING → 触发模型文件下载
                          └── DELETED → 重新触发调和

Worker 心跳事件 → WorkerController
                   └── 超时 → 标记实例 UNREACHABLE
3 GPUStack 的 GPU 资源池化机制

答案:

GPUStack 通过 Worker 注册、GPU 自动发现、统一资源视图与调度器三层机制实现跨节点的 GPU 资源池化。

资源池化流程:

Worker 启动 → GPU 设备检测(CUDA/ROCm/CANN)
           → 向 Server 注册(Worker ID + GPU 列表 + VRAM/RAM 容量)
           → Server 维护全局 GPU 资源视图(Worker → GPU  → 可用容量)
           → Scheduler 基于全局视图进行 Filter → Score → Select

GPU 资源数据结构:

字段说明
GPU IndexWorker 内 GPU 卡序号
GPU Name / Vendor型号与厂商(NVIDIA A100 / AMD MI250)
VRAM Total / Free显存总量与可用量
Backend Framework运行时类型(CUDA / ROCm / CANN)
LabelsWorker 标签,用于调度筛选

资源视图更新机制:

Worker 每 30 秒向 Server 同步心跳,上报当前 GPU 状态(利用率、显存、温度)。Server 依据心跳更新全局资源视图。Worker 心跳超时后,对应 GPU 资源从可用池中移除,已部署实例标记为 UNREACHABLE。

多集群资源池:

GPUStack 支持多集群管理:每个 Cluster 包含一组 Worker,模型部署时通过 cluster_id 指定目标集群,调度器仅在目标集群的 Worker 池内进行调度。

4 GPUStack 的模型部署生命周期(Register → Deploy → Serve → Update → Undeploy)

答案:

GPUStack 的模型部署遵循声明式生命周期管理,每个阶段由特定 Controller 驱动。

状态机流转:

graph LR
    P["PENDING"] --> A["ANALYZING"] --> S["SCHEDULED"] --> I["INITIALIZING"] --> D["DOWNLOADING"] --> ST["STARTING"] --> R["RUNNING"]
    R --> E["ERROR"]
    R --> U["UNREACHABLE"]

各阶段详解:

阶段触发者动作
PENDING用户创建 Model(POST /v2/modelsModelInstance 记录创建,等待调度
ANALYZINGScheduler评估模型资源需求(VRAM、层数、Offload 策略)
SCHEDULEDScheduler选定 Worker 与 GPU,写入调度结果
INITIALIZINGWorker ServeManagerWorker 接收调度结果,准备部署
DOWNLOADINGModelInstanceControllerModelFileManager 从 HuggingFace/ModelScope 下载权重
STARTINGServeManager启动推理引擎进程(vLLM/SGLang 等)
RUNNINGServeManager实例正常 Serving,AI Gateway 开始路由请求
ERROR各组件部署或运行时异常,可触发重试
UNREACHABLEWorkerControllerWorker 心跳超时,实例不可达

Update(更新):

修改 Model 配置(Backend 参数、副本数、Placement Strategy)后,ModelController 触发 reconcile:旧实例逐步销毁,新实例按更新后配置创建,实现滚动更新。模型权重更新通过重新指定 HuggingFace repo 或本地路径完成。

Undeploy(卸载):

将 Model replicas 设置为 0 或删除 Model 资源,Controller 触发实例销毁,推理进程终止,GPU 资源释放回池。

5 GPUStack 的多节点 GPU 调度策略

答案:

GPUStack 的调度器采用 Filter → Score → Select 三级流水线,在全局 GPU 资源池中为每个模型实例选择最优部署节点。

Filter 过滤链(Candidate Selection):

过滤器功能
Cluster Filter仅保留目标集群内的 Worker
GPU Matching Filter按 gpu_selector 显式匹配 GPU ID
Label Matching Filter按 worker_selector 标签匹配
Status Filter仅保留 READY 状态 Worker
Backend Framework Filter检查 GPU 运行时兼容性与 Backend 版本
Local Path Filter对于 LOCAL_PATH 模型,检查 Worker 上是否存在模型文件

资源匹配优先级瀑布(Waterfall Strategy):

1. 单 Worker 单 GPU 满足需求 → 最优(单节点内延迟最低)
2. 单 Worker 多 GPU 满足需求 → 次优(单节点内张量并行)
3. 跨 Worker 分布式推理        → 仅当 Backend 支持(vLLM/SGLang)
4. 部分 Offload 或 CPU 执行    → 仅 GGUF / VoxBox / Custom Backend

Score 评分链:

评分器策略逻辑
Placement ScorerBinpackGPU 剩余容量越少分数越高(紧密装箱,减少碎片)
Placement ScorerSpreadGPU 剩余容量越多分数越高(均匀分布,提升容错)
Model File Locality Scorer已有模型文件的 Worker 优先(减少下载延迟)

Scale-Down 调度(缩容移除排序):

评分器行为
Status Scorer不健康实例优先移除
Offload Layer ScorerGGUF 模型中 Offload 层数少的实例优先移除
Placement Scorer按 Binpack/Spread 策略从移除角度重新评分,低分优先移除
6 GPUStack 的 GPU 发现与注册机制

答案:

GPUStack Worker 启动时通过 GPUStack Runtime 自动检测本节点 GPU 设备,并将资源信息注册到 Server。

发现流程:

Worker 启动 → Runtime 调用 GPU 驱动 API 枚举设备
           → 收集 GPU 属性:Index / Name / Vendor / VRAM Total / Framework / Labels
           → WorkerManager 构建注册请求(Worker ID + GPU 列表)
           → 向 Server /worker-auth 端点认证并注册
           → Server 创建或更新 Worker 记录,更新全局 GPU 资源表

支持的 GPU 检测方式:

硬件平台运行时检测接口
NVIDIA GPUCUDAnvidia-smi / NVML API
AMD GPUROCmrocm-smi / ROCm API
Ascend NPUCANNnpu-smi / Ascend API
Hygon DCUROCm 兼容dcu-smi
Apple SiliconMetalMetal API
MThreads / Iluvatar / MetaX / Cambricon厂商 SDK各自设备管理 API

心跳同步周期:

Worker 每 30 秒向 Server 发送心跳,携带当前 GPU 利用率和健康状态。Server 通过 WorkerController 监控心跳,超时(默认 90 秒)后将 Worker 状态标记为 NOT_READY,其上所有实例标记为 UNREACHABLE。

7 GPUStack 的 OpenAI 兼容 API(Chat Completions / Completions / Embeddings)

答案:

GPUStack 对外提供与 OpenAI 格式兼容的 RESTful API,客户端无需修改代码即可从 OpenAI SDK 切换到 GPUStack。

支持的 API 端点:

OpenAI 端点GPUStack 端点说明
/v1/chat/completions/v1/chat/completions对话补全,支持流式与非流式
/v1/completions/v1/completions文本补全(Legacy)
/v1/embeddings/v1/embeddings文本向量化
/v1/models/v1/models列出可用模型
/v1/images/generations/v1/images/generations图像生成(需部署对应模型)
/v1/audio/transcriptions/v1/audio/transcriptions语音转文字
/v1/audio/speech/v1/audio/speech文字转语音

调用示例:

export GPUSTACK_API_KEY=gpustack_abc123_def456
curl http://<gpustack-server>/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $GPUSTACK_API_KEY" \
  -d '{
    "model": "qwen3-32b",
    "messages": [
      {"role": "system", "content": "你是一个AI助手"},
      {"role": "user", "content": "解释GPUStack的架构"}
    ],
    "temperature": 0.7,
    "max_tokens": 2048,
    "stream": true
  }'

请求路由链路:

Client → AI Gateway (Higress) → 路由表匹配 model → 负载均衡选择 ModelInstance → Worker → 推理引擎
8 GPUStack 的模型目录与模型管理

答案:

GPUStack 内置基于 YAML 的模型目录系统,提供预配置、预调优、可一键部署的模型模板。

模型目录结构:

model_sets:
  - name: Qwen3
    categories: [llm]
    capabilities: [context/128k, tools]
    sizes: [8, 32, 235]
    licenses: [apache-2.0]
    templates:
      - quantizations: [Q4_K_M, Q8_0, BF16]
        source: huggingface
        huggingface_repo_id: Qwen/Qwen3-{size}B-Instruct
        backend: vllm
        cpu_offloading: false
        distributed_inference_across_workers: true

模型来源支持:

来源说明
HuggingFace指定 repo_id 与 filename,自动下载
ModelScope中国区优化的模型下载源
Local Path已下载到 Worker 本地或共享存储的模型
Ollama(已弃用)v2 版本起移除,需迁移至上述来源

模型目录操作:

操作方式
使用内置目录默认启用,GPUStack 发布时包含主流模型配置
自定义目录通过 --model-catalog-file 指定本地 YAML 文件或 URL
手动部署通过 API/UI 直接指定 HuggingFace repo 部署非目录模型
目录更新升级 GPUStack 版本时自动更新内置目录

模型管理 CRUD:

操作API
创建部署POST /v2/models
列出模型GET /v2/models(支持 search / categories / state / cluster_id / backend 过滤)
更新模型PUT /v2/models/{id}(修改副本数、Backend 参数等)
删除模型DELETE /v2/models/{id}
9 GPUStack 的量化模型支持(GGUF / AWQ / GPTQ)

答案:

GPUStack 支持多种模型量化格式,以 GGUF 为内置一等支持的格式,AWQ/GPTQ/BitsandBytes 可通过手动配置 vLLM Backend 参数部署。

量化格式支持矩阵:

量化格式内置目录支持推理 Backend关键特性
GGUF (Q2–Q8, F16)支持(一等支持)llama-box / llama.cppCPU Offloading、跨 Worker 分布式推理
BF16支持vLLM高精度推理
AWQ手动配置vLLM(--quantization awq4-bit 激活感知量化
GPTQ手动配置vLLM(--quantization gptq4-bit GPT 后训练量化
BitsandBytes手动安装vLLM非默认安装,性能不推荐

GGUF 量化级别详情:

量化级别位宽特点推荐场景
Q2_K2-bit极致压缩,精度损失明显显存极度受限
Q3_K_M3-bit中等压缩性价比场景
Q4_K_M4-bit推荐默认通用部署
Q5_K_M5-bit更高质量质量优先
Q8_08-bit近无损精度敏感任务
F1616-bit无量化,原生精度高精度要求

GGUF 模型自定义目录示例:

templates:
  - quantizations: [Q4_K_M, Q8_0]
    source: huggingface
    huggingface_repo_id: bartowski/Llama-3.2-{size}B-Instruct-GGUF
    huggingface_filename: "*-{quantization}*.gguf"
    backend: llama-box
    cpu_offloading: true
    distributed_inference_across_workers: true
10 GPUStack 的推理后端支持(llama.cpp / vLLM)

答案:

GPUStack 通过可插拔 Backend 架构支持多种推理引擎,部署模型时根据模型格式和硬件平台自动选择最优 Backend。

内置推理后端矩阵:

Backend适用场景模型格式关键能力
vLLM文本生成(默认)HF TransformersPagedAttention、高吞吐 Batching、张量并行
SGLang高吞吐 / 结构化生成 / 扩散模型HF TransformersRadixAttention、HiCache、扩散模型(Flux/Qwen-Image)
llama-box / llama.cppGGUF 格式模型GGUFCPU Offloading、跨 Worker 分布式推理
TensorRT-LLMNVIDIA GPU 极致性能TRT EngineNVIDIA 全栈优化
Ascend MindIE华为昇腾 NPUMindIE 格式CANN 生态
VoxBox语音/音频模型多种ASR/TTS 专用
Custom用户自定义镜像任意通过容器接入任意推理引擎

Backend 选择逻辑:

用户指定 Backend → 直接使用
未指定 + GGUF 模型 → llama-box
未指定 + HuggingFace 模型 + NVIDIA GPU → vLLM(默认)
未指定 + HuggingFace 模型 + Ascend NPU → MindIE

多版本 Backend 管理:

GPUStack 为每个 Backend 维护多个版本镜像(如 vLLM v0.6.3 / v0.7.1),部署时可指定 backend_version,避免升级 Backend 导致已有模型异常。

11 GPUStack 的多模型并发 Serving

答案:

GPUStack 基于模型实例副本(Replica)机制和 AI Gateway 路由分发实现多模型并发 Serving。

并发能力来源:

维度机制说明
模型实例副本replicas 字段同一模型部署多个实例分散到不同 GPU/Worker
Backend 内部并发vLLM Continuous Batching单实例内通过 PagedAttention 实现高并发 Continuous Batching
AI Gateway 负载均衡Higress 路由请求按模型名匹配路由表,负载均衡分发到多个实例
多模型共存不同模型占用不同 GPU同一 Worker 上可同时运行多个不同模型的实例

资源隔离策略:

  • 显存隔离:调度器在分配 GPU 时计算 VRAM 需求,确保同一 GPU 上的多个模型实例不超卖显存。
  • 算力共享:GGUF 模型支持 CPU Offloading,仅部分层占据 GPU,多个 GGUF 实例可共享 GPU 算力。
  • 隔离粒度:默认以 GPU 卡为隔离单元;HAMI 等第三方方案可实现单卡内细粒度隔离。

并发 Serving 架构:

Client → AI Gateway
           ├── model: qwen3-32b → Worker-1 (vLLM instance 1) / Worker-2 (vLLM instance 2)
           ├── model: llama-8b   → Worker-1 (llama-box instance) / Worker-3 (llama-box instance)
           └── model: embedding  → Worker-2 (vLLM embedding instance)
12 GPUStack 在 Kubernetes 上的部署(Helm)

答案:

GPUStack 提供容器化部署方式,支持在 Kubernetes 上通过 Docker Compose 或手动编排部署 Server 与 Worker 组件。官方推荐使用 Docker 部署方案,Kubernetes 部署可通过社区提供的 Helm Chart 或自定义编排实现。

Kubernetes 部署架构:

graph TD
    subgraph K8s["Kubernetes Cluster"]
        subgraph Server["GPUStack Server (Deployment)"]
            API["API Server"]
            SCH["Scheduler"]
            CTRL["Controllers"]
            PG["PostgreSQL"]
        end

        subgraph Worker["GPUStack Worker (DaemonSet)"]
            RT["GPUStack Runtime"]
            SM["ServeManager"]
            ME["MetricExporter"]
            GPU["GPU devices"]
        end

        subgraph GW["AI Gateway (Higress)"]
            SVC["Service (LoadBalancer/NodePort)"]
            ROUTE["Request Routing"]
        end

        Server --> GW
        Worker --> GW
    end

Server 部署关键配置:

参数说明
GPUSTACK_SERVER_HOSTServer 监听地址
GPUSTACK_SERVER_PORTServer 监听端口
GPUSTACK_DATABASE_URL数据库连接(SQLite 默认 / PostgreSQL 生产)
GPUSTACK_JWT_SECRET_KEYJWT 签名密钥
GPUSTACK_BOOTSTRAP_PASSWORD初始管理员密码

Worker 部署关键配置:

参数说明
GPUSTACK_SERVER_URLServer 地址
GPUSTACK_TOKENWorker 注册令牌
GPUSTACK_WORKER_IPWorker 对外 IP
GPUSTACK_WORKER_LABELSWorker 标签(用于调度筛选)
--gpus allDocker GPU 资源挂载

生产环境 Kubernetes 部署要点:

  • Server 部署为 Deployment(多副本需外部 PostgreSQL)。
  • Worker 部署为 DaemonSet(每个 GPU 节点一个实例)。
  • 使用 NodeSelector / NodeAffinity 将 Worker 限定在 GPU 节点。
  • AI Gateway 通过 Service 暴露,生产环境使用 LoadBalancer 或 Ingress。
  • 配置 PersistentVolume 持久化模型缓存目录和数据库。
13 GPUStack 的 GPU Offloading 与 Worker 管理

答案:

GPUStack 支持模型层级粒度的 GPU Offloading,允许 GGUF 模型将部分层运行在 CPU 上,剩余层加载到 GPU,实现显存不足时的弹性部署。

Offloading 机制:

gguf-parser-go 工具 → 解析 GGUF 模型的层数与每层大小
                    → ComputedResourceClaim { total_layers, vram_per_gpu, offload_layers }
                    → 调度器按 Waterfall 策略匹配:
                        1. 全量 GPU 加载(prefer_gpu)
                        2. 单 Worker 多 GPU 分片
                        3. 跨 Worker 分布式
                        4. 部分 Offload(GPU 层 + CPU 层)
                        5. 全 CPU 执行

Worker 状态管理:

状态说明触发条件影响
READY正常运行,可接收调度心跳正常实例可分配
NOT_READYWorker 心跳超时90 秒无心跳不再分配新实例
UNREACHABLE端点不可达Server 探测失败实例标记 UNREACHABLE
MAINTENANCE手动禁用管理员操作不分配新实例,已有实例保持

Worker 管理操作:

  • 添加 Worker:在新 GPU 节点启动 Worker 容器,指定 Server URL 与 Token,自动注册并纳入资源池。
  • 移除 Worker:停止 Worker 容器或将其标记为 MAINTENANCE,已有实例迁移或终止。
  • 标签管理:通过 GPUSTACK_WORKER_LABELS 环境变量设置标签,配合模型的 worker_selector 实现定向调度。
14 GPUStack 的负载均衡与请求分发

答案:

GPUStack 通过 AI Gateway(Higress)实现推理请求的统一入口、路由分发和负载均衡。

请求分发流程:

Client Request → AI Gateway
                   ├── 请求认证(API Key / JWT)
                   ├── 模型名匹配 → 查询路由表(Model → ModelInstances)
                   ├── 负载均衡选择目标实例
                   └── 转发请求 → Worker → 推理引擎

路由表维护:

路由表由 ModelController 在模型实例状态变更时动态更新:

ModelInstance.CREATED / RUNNING → 添加到路由表
ModelInstance.DELETED / ERROR / UNREACHABLE → 从路由表移除

负载均衡策略:

策略说明
加权轮询默认策略,按实例权重分发
最少连接优先分发到活跃请求数最少的实例
一致性哈希按请求特征(Session ID)粘性路由

速率限制与流量控制:

  • API Key 级别速率限制(可按模型、Token 数设置上限)。
  • Backend 级别并发限制(防止推理引擎过载)。
  • 请求排队:当所有实例繁忙时,请求进入 Gateway 层面队列等待。
15 GPUStack 的监控仪表板与指标

答案:

GPUStack 内置 Prometheus + Grafana 可观测性栈,提供 GPU 资源、模型实例、请求吞吐的全面监控。

内置组件:

组件访问地址说明
Grafanahttp://<host>/grafana(端口 13000)预置仪表板
Prometheushttp://<host>/prometheus(端口 19090)指标采集与存储
Metrics Endpointhttp://<host>:10161/metricsWorker 暴露的 Prometheus 指标
Targets APIhttp://<host>:10161/metrics/targetsWorker 发现端点

统一指标命名空间(gpustack:*):

指标类型说明
gpustack:num_requests_runningGauge当前正在处理的请求数
gpustack:num_requests_waitingGauge队列中等待的请求数
gpustack:num_requests_swappedGauge被交换出的请求数
gpustack:kv_cache_usage_ratioGaugeKV Cache 使用率
gpustack:prefix_cache_hit_rateGauge前缀缓存命中率
gpustack:prompt_tokensCounterPrompt Token 总量
gpustack:generation_tokensCounter生成 Token 总量
gpustack:time_to_first_token_secondsHistogram首 Token 延迟(TTFT)
gpustack:time_per_output_token_secondsHistogram每 Token 生成延迟(TPOT)
gpustack:e2e_request_latency_secondsHistogram端到端请求延迟
gpustack:request_successCounter成功请求计数

Dashboard Summary API:

GET /v2/dashboard 提供聚合摘要:Worker/GPU/Model 计数、系统负载历史、活跃模型排名、Token 消耗趋势。

自定义指标栈:

通过 docker-compose.external-observability.yamlGPUSTACK_GRAFANA_URL 环境变量集成外部 Grafana。

16 GPUStack 的认证与 RBAC 权限

答案:

GPUStack 实现多层认证体系和基于角色的访问控制(RBAC),通过 FastAPI 依赖注入在 API 层面执行权限校验。

认证方式矩阵:

方式适用场景实现
Basic AuthenticationWeb UI 登录用户名/密码,密码 Argon2 哈希存储
API Key(Bearer Token)编程/API 访问格式 gpustack_{access_key}_{secret_key},Sercret Argon2 哈希
JWT Token(Session Cookie)Web UI 会话Cookie gpustack_session,JWTManager 管理
System User AuthWorker / Cluster 注册注册令牌,/worker-auth 端点

角色定义:

角色权限范围
Admin(is_admin=True全部操作:用户管理、模型管理、API Key 管理、集群管理
Cluster集群级操作(模型部署、Worker 管理)
WorkerWorker 注册与状态上报

权限校验依赖函数:

依赖函数要求用途
get_admin_useruser.is_admin == TrueAdmin 专属操作
get_cluster_userCluster 或 Admin集群管理操作
get_worker_userWorker 或 AdminWorker 注册操作

模型级别访问控制:

策略说明
Public任何认证用户可访问
Authed仅认证用户可访问
Allowed Usersmodel_user_links 中的用户或 Admin 可访问
17 GPUStack 的 API Key 管理

答案:

GPUStack 提供完整的 API Key 生命周期管理,API Key 格式为 gpustack_{access_key}_{secret_key},密钥采用 Argon2 哈希存储。

API Key CRUD 端点:

操作端点说明
创建POST /v2/api-keys返回完整 Key(仅此一次),可设过期时间
查询GET /v2/api-keys返回掩码值(gs_abcd...
更新PUT /v2/api-keys/{id}修改 allowed_model_names 范围
删除DELETE /v2/api-keys/{id}永久删除

Key 范围限制(Scoping):

通过 allowed_model_names 字段将 API Key 限制为仅可访问指定模型列表,实现细粒度访问控制。

安全特性:

特性实现
密钥哈希存储Secret Key 使用 secrets.token_hex() 生成,Argon2 哈希后存储
一次性展示完整 Key 仅在创建时返回一次,后续仅返回掩码
过期时间可选 expires_at 时间戳,过期 Key 自动失效
密钥轮换创建新 Key 替换旧 Key,无停机影响

使用方式:

export GPUSTACK_API_KEY=gpustack_abc123_def456789
curl http://<server>/v1/chat/completions \
  -H "Authorization: Bearer $GPUSTACK_API_KEY" \
  -d '{"model": "qwen3-32b", "messages": [{"role": "user", "content": "Hello"}]}'
18 GPUStack 的模型版本管理与 Rollback

答案:

GPUStack 的模型版本管理通过 HuggingFace repo 版本化、Backend 多版本管理和模型实例重建实现。

版本管理维度:

维度机制说明
模型权重版本HuggingFace repo 的 revision/commit hash指定模型权重版本
Backend 版本backend_version 字段指定推理引擎版本
模型配置版本Model CRUD 的更新操作副本数、Backend 参数等配置版本
GPUStack 平台版本Docker 镜像 Tag平台自身版本

权重更新流程:

1. 更新 Model 的 huggingface_repo_id / revision
2. ModelController 触发 reconcile
3. 旧 ModelInstance 逐步删除
4. 新 ModelInstance 创建 → 下载新权重 → 启动新 Backend → 加入路由表
5. AI Gateway 路由切换至新实例

Rollback 操作:

GPUStack 当前不内置自动 Rollback 功能,回滚通过手动操作完成:

  1. 模型权重 Rollback:将 Model 配置回滚到之前的 HuggingFace repo revision。
  2. Backend 版本 Rollback:修改 backend_version 回退到先前版本。
  3. 平台版本回退:降级 Docker 镜像版本,恢复数据库备份。

版本升级风险控制:

操作说明
数据库备份升级前备份 /var/lib/gpustack/database.db
Backend 版本固定生产模型指定 backend_version 避免自动升级
先扩容后缩容先创建新版本实例验证,再删除旧版本实例
部分灰度通过 replicas 分批创建新版本实例
19 GPUStack 的分布式推理(跨 Worker Tensor Parallelism / Pipeline Parallelism)

答案:

GPUStack 通过 distributed_inference_across_workers 参数支持跨节点的 GPU 分布式推理,调度器负责分配多个 Worker 上的 GPU 共同完成单个模型实例的推理。

支持的分布式范式:

范式说明适用 Backend
Tensor Parallelism模型权重矩阵按列/行切分到多个 GPU,减少单卡显存占用vLLM / SGLang / TensorRT-LLM
Pipeline Parallelism模型按层切分到多个 GPU,微批次流水线执行vLLM / SGLang
GGUF 分布式GGUF 模型层分布到多个 Worker 的 GPU/CPUllama-box

调度流程:

Scheduler 评估模型显存需求(ComputedResourceClaim.vram)
    ├── 单 Worker 单 GPU 满足 → 不使用分布式
    ├── 单 Worker 多 GPU 满足 → 使用 Ray 多 GPU(单节点内 NCCL)
    └── 单 Worker 不满足 → 启用 distributed_inference_across_workers
         └── 选择 N 个 Worker 上的 GPU 组成分布式推理组
              ├── 主节点(Rank 0):启动推理引擎主进程
              └── 从节点(Rank 1..N-1):配置分布式环境变量后启动

Ray Cluster 用于跨节点 GPU 通信协调

部署配置示例:

# Model 部署参数
replicas: 1
backend: vllm
distributed_inference_across_workers: true
# vLLM Backend 参数
backend_parameters:
  --tensor-parallel-size: 4
  --pipeline-parallel-size: 2

约束条件:

  • 仅 vLLM、SGLang、TensorRT-LLM 等 Backend 支持跨节点分布式推理。
  • 分布式推理实例的所有 GPU 必须在同一时间可用。
  • 跨节点通信依赖 NCCL / Ray,需确保 Worker 节点间网络低延迟高带宽。
  • 多节点分布式推理故障域更大,任一参与节点故障会导致整个实例不可用。
20 GPUStack 的故障容错与 Worker 健康检测

答案:

GPUStack 通过心跳监控、自动故障标记和调度恢复实现多层次的故障容错机制。

健康检测体系:

检测层机制周期动作
Worker 心跳Worker → Server 状态同步30 秒更新 Worker 状态和 GPU 资源
Worker 超时检测WorkerController 超时判定90 秒阈值状态 → NOT_READY
端点可达性Server 主动探测 Worker心跳超时后状态 → UNREACHABLE
实例健康ServeManager 监控推理进程持续崩溃自动重启

故障处理流程:

Worker 心跳超时(90 秒)
  → WorkerController 标记 Worker NOT_READY
  → 该 Worker 上所有 ModelInstance → UNREACHABLE
  → AI Gateway 从路由表移除 UNREACHABLE 实例
  → Scheduler 检测副本数不足
  → 在其他可用 Worker 上创建新 ModelInstance
  → 新实例达到 RUNNING 后加入路由表
  → 服务恢复

故障恢复时间线:

阶段延迟(近似)说明
心跳超时检测90 秒可配置心跳间隔与超时阈值
实例故障标记即时Controller 异步响应
新实例调度秒级Scheduler 实时处理
模型下载数分钟取决于模型大小与网络带宽
推理引擎启动30–120 秒vLLM/SGLang 预热时间
服务恢复30 秒–数分钟总计恢复时间

Worker 级别容错:

  • 同一模型部署多副本到不同 Worker 实现冗余。
  • 使用 Spread 策略将实例分布到不同节点提升故障隔离。
  • Worker 恢复后自动重新注册并加入资源池。
21 GPUStack 的模型自动扩缩(基于请求负载 / 基于 GPU 使用率)

答案:

GPUStack 的模型副本管理以声明式为主,用户通过 replicas 字段指定期望副本数,ModelController 负责调和。自动扩缩能力通过观察指标和手动调整或外部自动化实现。

副本数管理机制:

Model.replicas = N
  → ModelController.sync_replicas()
  → current_replicas < N → 创建新 ModelInstance(Scheduler 分配 Worker/GPU)
  → current_replicas > N → Scale-Down 评分,移除低分实例
  → current_replicas == N → 无操作

自动扩缩实现路径:

方案实现方式说明
HPA 式外部扩缩基于 Prometheus 指标触发 API 调用修改 replicasgpustack:num_requests_waiting 或 GPU 利用率触发
Webhook 事件驱动订阅 GPUStack EventBus 事件模型负载变化触发自动化脚本
定时扩缩CronJob 周期性调整 replicas按日夜流量模式预调副本数
Grafana Alert 触发Grafana Alert → Webhook → API基于自定义阈值触发缩扩容

扩缩决策指标参考:

指标扩容阈值建议缩容阈值建议
num_requests_waiting> 10 持续 2 分钟< 2 持续 10 分钟
kv_cache_usage_ratio> 0.9 持续 1 分钟< 0.3 持续 10 分钟
GPU Memory 使用率> 90%< 40%
e2e_request_latency_seconds P95> 目标值 2 倍< 目标值 0.5 倍

约束与注意事项:

  • GPUStack 本身不自带内置 AutoScaler,需结合外部工具(KEDA / 自定义 Controller)实现。
  • 扩缩容需考虑模型下载时间(冷启动延迟)。
  • GPU 资源池余量需预留扩缩容空间。
  • 使用 Binpack 策略可提高资源利用率但降低扩缩灵活性。
22 GPUStack 的队列管理与请求优先级

答案:

GPUStack 的请求队列由 AI Gateway(Higress)和推理引擎后端两层共同管理,支持请求排队、速率限制和超时控制。

队列层次:

Client → AI Gateway
           ├── 速率限制检查(API Key / IP 级别)
           ├── 路由表匹配(model → instances)
           ├── 实例选择(负载均衡)
           ├── 请求转发队列(Gateway 层排队)
           └── 超时处理(Gateway 层超时返回 504)
         
         → Worker → 推理引擎
                      ├── Continuous Batching(vLLM)
                      ├── 内部请求队列(等待 GPU 资源)
                      ├── Prefix Caching
                      └── KV Cache 管理

关键指标:

指标说明
num_requests_waiting推理引擎等待队列中的请求数
num_requests_running正在 GPU 上处理的请求数
num_requests_swapped因显存不足被交换出的请求数
kv_cache_usage_ratioKV Cache 占用率

速率限制配置:

限制维度配置方式
API Key 级别API Key 创建时设置 rate_limit
模型级别模型配置中设置最大并发数
Backend 级别推理引擎启动参数中的并发限制

优先级策略:

GPUStack 当前未实现显式的多级请求优先级队列。调度层面通过 Placement Strategy(Binpack / Spread)和模型 priority 配置权重决定资源分配顺序。请求级优先级需通过以下方式实现:

  • 部署同一模型的多个实例组,配置不同的 API Key 和速率限制。
  • 使用 AI Gateway 的请求路由规则按 Header / API Key 分流。
  • 在应用层实现优先级逻辑(优先级高的请求使用专用实例组)。
23 GPUStack 的升级策略(滚动升级 / 蓝绿部署)

答案:

GPUStack 支持通过 Docker 镜像升级平台组件,模型的滚动升级由 ModelController 的 Reconcile Loop 驱动。

平台升级流程:

1. 备份数据库(/var/lib/gpustack/database.db)
2. 拉取新版本 Docker 镜像
3. 停止旧版本容器
4. 启动新版本容器(挂载同一数据目录)
5. 自动执行数据库 Migration(Alembic)
6. 验证服务正常
7. 删除旧版本镜像(可选)

模型滚动升级(修改配置触发):

更新 Model 配置(如修改 Backend 参数)
  → ModelController 检测 spec 变更
  → 逐个创建新版本 ModelInstance
  → 新实例达到 RUNNING → AI Gateway 将路由切换到新实例
  → 逐个删除旧版本 ModelInstance
  → 所有副本升级完成

升级风险缓解措施:

风险缓解措施
数据库 Migration 失败升级前完整备份数据库
新版本不兼容旧 Backend先升级 Backend 版本,再升级平台
模型缓存失效升级前确认缓存路径配置一致性
Ollama 模型源移除(v2)迁移前将所有 Ollama 模型转为 HuggingFace 来源
Backend 枚举值变更升级后检查并修正模型 Backend 名称

蓝绿部署策略:

GPUStack 不内置蓝绿部署,但可通过以下方式实现:

  1. 部署两套 GPUStack Server 实例(蓝环境 + 绿环境)。
  2. 两套环境共享同一 GPU Worker 池。
  3. 在绿环境部署并验证新版本模型实例。
  4. 切换 AI Gateway / DNS 指向绿环境 Server。
  5. 蓝环境保留作为回滚备用。
24 GPUStack 与 vLLM / SGLang 的集成方式

答案:

GPUStack 在架构层面将 vLLM 和 SGLang 作为可插拔推理 Backend 集成,通过统一的模型部署流程启动和管理推理引擎进程。

集成架构:

GPUStack Model Deployment
  ├── backend: vllm
  │     ├── GPUStack 调用 vLLM API Server(OpenAI 兼容模式)
  │     ├── 自动传递 --tensor-parallel-size / --gpu-memory-utilization 等参数
  │     ├── MetricExporter 抓取 vLLM /metrics 端点
  │     └── 归一化为 gpustack:* 命名空间
  └── backend: sglang
        ├── GPUStack 调用 SGLang Runtime
        ├── 支持 RadixAttention、分层缓存
        ├── 支持扩散模型(Flux.1-dev, Qwen-Image)
        └── MetricExporter 抓取并归一化指标

Backend 参数自动注入:

参数vLLMSGLang
张量并行度--tensor-parallel-size--tp-size
GPU 显存利用率--gpu-memory-utilization--mem-fraction-static
最大模型长度--max-model-len--context-length
量化--quantization awq/gptq自动检测
KV Cache 扩展LMCacheHiCache
推测解码EAGLE3 / MTP / N-gramsEAGLE3

版本映射与管理:

GPUStack 为 vLLM 和 SGLang 维护多版本 Docker 镜像:

vLLM  v0.6.3  → gpustack/vllm:v0.6.3
vLLM  v0.7.1  → gpustack/vllm:v0.7.1
SGLang v0.4.1 → gpustack/sglang:v0.4.1

部署时通过 backend_version 选择特定版本,通过 backend_parameters 透传引擎级参数:

backend: vllm
backend_version: v0.7.1
backend_parameters:
  --tensor-parallel-size: "2"
  --gpu-memory-utilization: "0.90"
  --max-model-len: "32768"
25 GPUStack 与 Ollama 的对比

答案:

GPUStack 与 Ollama 定位不同:Ollama 面向个人开发者和单机场景的轻量级 LLM 运行工具,GPUStack 面向企业生产环境的多节点 GPU 集群管理与推理编排平台。

核心差异矩阵:

维度OllamaGPUStack
定位个人本地 LLM 运行工具企业级 GPU 集群管理平台
安装复杂度极简,一条命令安装需 Docker,Server + Worker 分离部署
GPU 集群不支持多节点统一管理
推理 Backend仅 llama.cppvLLM / SGLang / TensorRT-LLM / llama-box 等
单实例并发个位数100+(vLLM Continuous Batching)
50 并发错误率41%–58%稳定运行
100 并发错误率71%–78%稳定运行
显存效率(高并发)低(需多个实例)高(PagedAttention 共享 KV Cache)
分布式推理不支持支持跨 Worker 张量并行
异构 GPU有限支持全面支持(NVIDIA/AMD/Ascend/Hygon 等)
多模型仓库Ollama 自有HuggingFace / ModelScope / Local Path
鉴权与 RBAC内置 JWT + API Key + RBAC
监控内置 Prometheus + Grafana
API 兼容性OpenAI 兼容OpenAI 兼容 + Embeddings / Image / Audio
适用场景本地开发、单机测试生产推理、多租户 SaaS、企业私有化

GPUStack 弃用 Ollama 模型源说明:

GPUStack v2 版本起移除 Ollama 模型源支持,主要原因:Ollama 自有格式与 GPUStack Backend 体系存在兼容性问题,且 HuggingFace 和 ModelScope 生态更丰富,vLLM/SGLang Backend 无法直接加载 Ollama 格式模型。用户需将 Ollama 模型迁移至 HuggingFace GGUF 仓库后重新部署。

26 GPUStack 与 HuggingFace TGI 的对比

答案:

HuggingFace TGI(Text Generation Inference)是 HuggingFace 官方推出的 LLM 推理服务框架,与 GPUStack 在架构和定位上有本质区别。

核心差异矩阵:

维度HuggingFace TGIGPUStack
定位单模型推理服务器多模型 GPU 集群管理平台
架构单实例推理服务Server-Worker 分布式架构
GPU 集群管理不支持多节点统一调度与管理
多模型管理每模型独立 TGI 实例统一平台管理所有模型
推理 Backend自研(基于 Transformers + Candle)可插拔(vLLM / SGLang / TensorRT-LLM / MindIE)
模型目录HuggingFace Hub 一键部署内置预调优模型目录
请求路由单实例直连AI Gateway 统一入口 + 路由 + 负载均衡
量化支持GPTQ / AWQ / BitsandBytes / EETQ / FP8GGUF 一等支持 + AWQ / GPTQ 手动配置
调度策略无(单实例)Binpack / Spread + Waterfall 策略
鉴权与多租户基础 API KeyJWT + RBAC + API Key + 模型级访问控制
监控有限指标Prometheus + Grafana 预置仪表板
分布式推理张量并行(同节点)跨节点张量并行 / Pipeline Parallelism
异构 GPUNVIDIA 为主NVIDIA / AMD / Ascend / Hygon 等
适用场景单模型高性能推理多模型多租户 GPU 集群统一管理

选型建议:

  • 仅需部署单一 HuggingFace 模型且无需多节点 GPU 管理时,TGI 更轻量。
  • 多模型生产 Serving、多租户 GPU 集群管理、需要统一监控与权限控制时,GPUStack 是更优选择。
  • TGI 可作为 GPUStack 的 Custom Backend 集成,结合两者优势。
27 GPUStack 的安全加固(TLS / mTLS / Audit)

答案:

GPUStack 的安全加固涵盖传输层加密、服务间认证、API 认证与审计日志多个层面。

传输层安全:

层面机制说明
Client ↔ AI GatewayHTTPS / TLS生产环境在 AI Gateway 前部署反向代理(Nginx/Traefik)终止 TLS
AI Gateway ↔ Worker内部网络默认明文,可通过 Docker 网络隔离或 mTLS 加固
Worker ↔ ServerBearer TokenWorker 注册令牌认证

TLS 终止配置(Nginx 反向代理示例):

server {
    listen 443 ssl;
    server_name gpustack.example.com;

    ssl_certificate     /etc/ssl/certs/gpustack.crt;
    ssl_certificate_key /etc/ssl/private/gpustack.key;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    location / {
        proxy_pass http://gpustack-server:80;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }
}

mTLS 配置(服务间通信):

GPUStack 自身不内置 mTLS,可通过以下方式加固:

  • 在 Kubernetes 中使用 Istio / Linkerd Service Mesh 为 Server ↔ Worker 通信注入 mTLS。
  • Worker 注册使用强随机 Token(secrets.token_hex(32))作为预共享密钥。
  • 网络层通过防火墙规则限制 Worker 仅允许 Server IP 访问。

API 认证加固:

措施配置
密码哈希Argon2 算法,自动加盐
API Key 加密Secret Key Argon2 哈希存储,仅创建时返回原文
JWT 密钥GPUSTACK_JWT_SECRET_KEY 环境变量,建议 256-bit 随机值
Session 管理Cookie gpustack_session,设置 HttpOnly + Secure + SameSite
登录保护失败次数限制,账号激活管理

审计日志:

GPUStack 的审计能力通过以下方式实现:

  • API 请求日志:FastAPI 中间件记录客户端 IP、端点、响应状态码。
  • 操作审计:Model / Worker / API Key 等资源的创建、修改、删除操作记录。
  • 集成方案:将日志输出到 stdout/stderr,通过 Fluentd / Loki 采集至集中日志系统。
  • API Key 使用追踪:通过 Prometheus 指标跟踪每个 Key 的请求量。
28 GPUStack 的性能优化

答案:

GPUStack 的性能优化覆盖推理引擎、调度策略、缓存技术与基础设施四个层面。

推理引擎优化:

优化项技术效果
Continuous BatchingvLLM PagedAttention单实例并发从个位数提升至 100+
KV Cache 扩展LMCache(vLLM)/ HiCache(SGLang)TTFT 显著降低,长上下文收益明显
推测解码EAGLE3 / MTP / N-grams解码吞吐提升 1.5–3 倍
预调优配置低延迟 / 高吞吐预置模式避免手动调参
前缀缓存SGLang RadixAttention多轮对话场景大幅降低重复计算

调度优化:

优化项策略效果
Binpack 策略优先填满已使用 GPU减少 GPU 碎片,提高总体利用率
模型文件本地性优先调度到已有模型缓存的 Worker减少重复下载,加速部署
Backend 版本固定指定 backend_version避免 Backend 自动升级导致性能回退
GPU Memory 利用率--gpu-memory-utilization 0.90最大化 KV Cache 可用空间

基础设施优化:

优化项配置
GPU 驱动使用 NVIDIA 最新稳定驱动,开启 Persistence Mode
NUMA 亲和绑定推理进程到 GPU 所在 NUMA 节点
网络跨节点分布式推理使用 RDMA / NVLink / InfiniBand
存储模型缓存使用 NVMe SSD,避免 NFS 延迟
PostgreSQL生产环境使用外部 PostgreSQL 替代 SQLite

AI Gateway 性能:

优化项说明
Higress 替代传统代理v2.0 起使用 Higress,消除代理层性能瓶颈
连接复用HTTP Keep-Alive 与连接池
响应流式传输开启 SSE Streaming 减少首字节延迟

关键性能指标基线:

指标优化目标
TTFT(Time to First Token)< 200ms(短 Prompt)
TPOT(Time per Output Token)< 30ms
KV Cache 命中率> 70%(有前缀复用场景)
GPU 利用率> 80%
请求成功率> 99.9%
29 GPUStack 的常见故障排查

答案:

GPUStack 常见故障涵盖 Worker 失联、模型部署失败、推理性能异常和升级兼容性问题。

故障分类与排查路径:

一、Worker 失联

现象根因排查步骤
Worker 状态 NOT_READY心跳超时(90 秒)检查网络连通性、Worker 容器是否运行、Server URL 配置
Worker 状态 UNREACHABLEServer 无法访问 Worker 端点检查防火墙规则、Worker IP 是否可达、Worker 端口是否监听
Worker 注册失败Token 认证失败验证 GPUSTACK_TOKEN 是否正确、Server 是否正常运行

排查命令:

# 检查 Worker 容器日志
docker logs gpustack-worker

# 检查 Worker 心跳
curl http://<server>:10161/metrics/targets

# 检查 GPU 设备
docker exec gpustack-worker nvidia-smi

二、模型部署失败

现象根因排查步骤
实例卡在 DOWNLOADING模型下载失败(网络 / 权限)检查 HuggingFace / ModelScope 连通性、磁盘空间
实例卡在 STARTINGBackend 启动失败检查 Worker 日志中的推理引擎启动报错、GPU 显存是否充足
实例进入 ERROR 状态Backend 运行时崩溃检查 Backend 版本兼容性、Backend 参数配置
调度失败(无可用 Worker)GPU 资源不足检查全局 GPU 资源视图、Worker 是否处于 MAINTENANCE

三、推理性能异常

现象可能原因排查方向
TTFT 过高KV Cache 不足 / Cold Start检查 kv_cache_usage_ratio、是否触发 Swapping
吞吐量低GPU 利用率不足检查 gpu-memory-utilization 配置、Batch Size
请求排队多实例副本不足检查 num_requests_waiting、评估增加 replicas
偶发超时推理引擎 OOM / GPU 故障检查 GPU 是否 ECC Error、推理引擎日志

四、升级兼容性问题

现象根因修复
启动报错 enum values 不匹配Backend 枚举值变更(如 Ollama 移除)清理数据库中不兼容的模型记录
Backend 名称大小写错误vLLM 写成 vllm修正 Backend 名称大小写
模型缓存失效缓存路径版本间变更重新下载模型或手动迁移缓存目录
数据库 Migration 失败Alembic 迁移冲突手动修复 alembic version,或从备份恢复重建

排查工具汇总:

工具用途
docker logs查看 Server / Worker 日志
GET /v2/dashboard全局资源与状态概览
/metrics 端点Prometheus 指标排查
Grafana Dashboard可视化趋势分析
nvidia-smiGPU 设备直接检查
GET /v2/models?state=ERROR筛选失败模型实例
30 GPUStack 生产环境部署最佳实践

答案:

GPUStack 生产环境部署需综合考虑高可用、数据持久化、安全加固、监控告警与容灾恢复。

架构设计最佳实践:

实践说明
Server 高可用多副本部署 Server,使用外部 PostgreSQL 替代 SQLite
Worker 反亲和多副本模型实例使用 Spread 策略分布到不同 Worker/物理机
AI Gateway 冗余AI Gateway 多副本部署,前端通过 LB 分发
网络隔离Server ↔ Worker 通信使用内部网络,API 流量通过 DMZ
共享存储模型文件使用共享存储(NFS / S3 / MinIO),避免每个 Worker 重复下载

数据持久化:

数据存储方案
数据库外部 PostgreSQL(HA 方案:Patroni / Cloud SQL)
模型缓存共享存储或各 Worker 本地 NVMe SSD
日志集中日志系统(Loki / ELK)
监控数据Prometheus 远程写入(Thanos / Grafana Mimir)

安全最佳实践:

措施配置
TLS 终止在 API 前端部署 Nginx/Traefik,使用 Let’s Encrypt 或企业 CA
API 认证生产环境强制 API Key 认证,禁用 Anonymous 访问
API Key 轮换定期轮换 API Key,设置过期时间
密码策略GPUSTACK_JWT_SECRET_KEY 使用 256-bit 随机值
网络策略Kubernetes NetworkPolicy 限制 Worker 仅与 Server 通信
最小权限API Key 按 allowed_model_names 限制模型访问范围

监控与告警:

指标告警阈值等级
Worker 数量下降< 预期值Critical
num_requests_waiting> 50 持续 5 分钟Warning
kv_cache_usage_ratio> 0.95 持续 5 分钟Warning
GPU 显存可用量< 10GBWarning
实例 ERROR 状态> 0 持续 5 分钟Critical
API 错误率> 1%Warning
TTFT P95> 1 秒Warning

容灾与备份:

措施频率
数据库全量备份每日
数据库增量备份(WAL 归档)持续
模型配置导出(GET /v2/models每周
跨集群灾备在备用集群部署相同模型配置
恢复演练每季度

容量规划参考:

维度建议
GPU 资源按并发请求数估算所需 GPU 实例数:replicas = peek_rps / instance_capacity
VRAM 余量保留 10%–15% VRAM 余量用于 KV Cache 增长
网络带宽跨节点分布式推理需 > 100Gbps 网络带宽(RoCE v2 / InfiniBand)
磁盘空间模型缓存需预留模型总大小 3 倍空间(下载 + 解压 + 缓存)

附录:GPUStack 核心命令速查

Server 启动:

docker run -d --name gpustack \
    --restart unless-stopped \
    -p 80:80 \
    -v gpustack-data:/var/lib/gpustack \
    gpustack/gpustack:latest

Worker 注册:

docker run -d --name gpustack-worker \
    --restart unless-stopped \
    --gpus all \
    -e GPUSTACK_SERVER_URL=http://<server-ip> \
    -e GPUSTACK_TOKEN=<token> \
    -e GPUSTACK_WORKER_LABELS='{"region":"cn-east","tier":"production"}' \
    gpustack/gpustack:latest

模型部署 API:

curl -X POST http://<server>/v2/models \
  -H "Authorization: Bearer $GPUSTACK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "qwen3-32b",
    "source": "huggingface",
    "huggingface_repo_id": "Qwen/Qwen3-32B-Instruct",
    "backend": "vllm",
    "backend_version": "v0.7.1",
    "replicas": 2,
    "placement_strategy": "spread",
    "backend_parameters": ["--tensor-parallel-size=2", "--max-model-len=32768"]
  }'

推理调用:

curl http://<server>/v1/chat/completions \
  -H "Authorization: Bearer $GPUSTACK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "qwen3-32b", "messages": [{"role": "user", "content": "Hello"}], "stream": true}'