一、 面试题目在生产环境中部署大模型服务时你是如何结合Docker 和 K8s实现高效治理的特别是在GPU 调度如共享、切分和推理加速如 vLLM, TensorRT-LLM方面有哪些实战经验二、 知识储备1. 核心背景LLM 部署的“三道坎”显存瓶颈模型参数量巨大KV Cache 占用极快。冷启动延迟镜像动辄数十 GBGPU 预热慢。算力浪费传统的“一容器一卡”在低频访问时浪费严重。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总拥有成本的最低化’。你可以告诉面试官Docker解决了‘环境的确定性’通过镜像预拉取Pre-pull解决冷启动K8s 调度解决了‘资源的规模化’。我推崇使用Karpenter这种自动缩放器根据 Pending Pod 的 GPU 需求动态创建节点推理加速则是‘吞吐量的倍增器’。在工程实践中我通常会采用vLLM 配合 K8s 弹性伸缩。一个优秀的架构师不应让 GPU 处于低效等待状态。通过 PagedAttention 解决显存碎片化结合 K8s 的 HPA 指标如 Token 队列深度我们能让算力资源像水和电一样按需流动真正实现从‘买显卡’到‘买服务’的思维转变。”四、 代码实现1. Dockerfile 实现高性能推理环境构建# 使用 NVIDIA 官方提供的推理基础镜像 FROM nvcr.io/nvidia/pytorch:24.01-py3 # 安装推理加速引擎 vLLM RUN pip install vllm tensorrt-llm # 设置环境变量优化显存分配 ENV PYTORCH_CUDA_ALLOC_CONFexpandable_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 并配置健康检查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 以上普通的拉取会导致网络带宽瞬间被撑爆。提到这一点面试官会立刻意识到你处理过真正的超大规模部署场景。