【AI面试临阵磨枪-56】大模型服务部署:Docker、K8s、GPU 调度、推理加速

一、 面试题目

在生产环境中部署大模型服务时,你是如何结合 Docker 和 K8s 实现高效治理的?特别是在 GPU 调度(如共享、切分) 和 推理加速(如 vLLM, TensorRT-LLM) 方面有哪些实战经验?

二、 知识储备

1. 核心背景:LLM 部署的"三道坎"

  • 显存瓶颈: 模型参数量巨大,KV Cache 占用极快。
  • 冷启动延迟: 镜像动辄数十 GB,GPU 预热慢。
  • 算力浪费: 传统的"一容器一卡"在低频访问时浪费严重。

2. 核心技术栈拆解

|------------------|---------------------------------------------------|---------------------------------------------|
| 维度 | 解决方案 (The Solution) | 关键技术 (The Key) |
| 容器化 (Docker) | 构建基础推理镜像。集成 NVIDIA Container Toolkit,确保环境一致性。 | 多阶段构建、基础镜像瘦身(减少冷启动时间)。 |
| K8s 调度 | GPU 设备插件 (Device Plugin)。实现对显卡的识别、分配与健康检查。 | NVIDIA K8s Device Plugin、Node Affinity。 |
| GPU 调度优化 | 虚拟化与切分。将一块 A100 切分为多个实例,供不同轻量任务使用。 | NVIDIA MIG (硬件切分)、MPS (逻辑切分)。 |
| 推理加速 | 高效算子与显存管理。采用连续批处理(Continuous Batching)提升吞吐。 | vLLM (PagedAttention)、TensorRT-LLM。 |

三、 破局之道

在回答完技术方案后,通过这段话展现你对 "算力成本与性能平衡" 的思考:

"回答部署架构,核心要理解我们是在 '追求 TCO(总拥有成本)的最低化'。

你可以告诉面试官:

  1. Docker 解决了 '环境的确定性' ,通过 镜像预拉取(Pre-pull) 解决冷启动;
  2. K8s 调度 解决了 '资源的规模化' 。我推崇使用 Karpenter 这种自动缩放器,根据 Pending Pod 的 GPU 需求动态创建节点;
  3. 推理加速 则是 '吞吐量的倍增器'。

在工程实践中,我通常会采用 vLLM 配合 K8s 弹性伸缩 。一个优秀的架构师不应让 GPU 处于低效等待状态。通过 PagedAttention 解决显存碎片化,结合 K8s 的 HPA 指标(如 Token 队列深度),我们能让算力资源像水和电一样按需流动,真正实现从'买显卡'到'买服务'的思维转变。"

四、 代码实现

1. Dockerfile 实现:高性能推理环境构建

bash 复制代码
# 使用 NVIDIA 官方提供的推理基础镜像
FROM nvcr.io/nvidia/pytorch:24.01-py3

# 安装推理加速引擎 vLLM
RUN pip install vllm tensorrt-llm

# 设置环境变量,优化显存分配
ENV PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True

# 拷贝代码
WORKDIR /app
COPY . .

# 启动服务
ENTRYPOINT ["python", "-m", "vllm.entrypoints.openai.api_server"]
CMD ["--model", "/models/llama3-8b", "--gpu-memory-utilization", "0.9"]

2. K8s 资源配置:申请 GPU 并配置健康检查

bash 复制代码
apiVersion: apps/v1
kind: Deployment
metadata:
  name: llm-inference-node
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: vllm-container
        image: my-llm-vllm:latest
        resources:
          limits:
            nvidia.com/gpu: 1 # 申请 1 块 GPU
        # 关键:存活探针,防止 GPU 掉线或显存溢出导致的死锁
        livenessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 60 # 给模型加载留出时间
          periodSeconds: 10

面试加分建议:

提到 "大镜像加速" 。例如:在 K8s 集群中使用 Dragonfly 或 P2P 镜像分发 。因为 LLM 镜像通常在 10GB 以上,普通的拉取会导致网络带宽瞬间被撑爆。提到这一点,面试官会立刻意识到你处理过真正的超大规模部署场景。

相关推荐
Shockang2 小时前
llama.cpp 本地运行 9B 模型:部署、工具调用与微调数据
人工智能
Shockang2 小时前
n8n 智能体工作流实战:触发、工具、记忆与发布护栏
人工智能
冬奇Lab4 小时前
开源项目第241期:YuE2 —— 用符号乐谱当“白盒“接口的开源音乐生成模型,SongBench 超越 Suno v5/v6
人工智能
鶴哥只手遮天5 小时前
Spring AI 2.0.1 深度解析-第 14 章 MCP 服务端(上):注解式实现与工具来源
java·人工智能·开源
鶴哥只手遮天5 小时前
Spring AI 2.0.1 深度解析-第 15 章 MCP 服务端(下):三种协议形态、Streamable 传输与状态管理
java·人工智能·开源
鶴哥只手遮天5 小时前
Spring AI 2.0.1 深度解析-第 16 章 向量存储(上):`VectorStore` 接口体系、`BatchingStrategy`
java·人工智能·开源
鶴哥只手遮天5 小时前
Spring AI 2.0.1 深度解析-第 12 章 工具循环的流式形态、Usage 累加与扩展体系
java·人工智能·开源
鶴哥只手遮天5 小时前
Spring AI 2.0.1 深度解析-第 23 章 模型供应商实现:从 `OpenAiSetup` 到 Bedrock
java·人工智能·开源
鶴哥只手遮天5 小时前
Spring AI 2.0.1 深度解析-第 06 章 内置 Advisor 全景:13 个实现逐个剖到源码级
java·人工智能·开源