熟练版本控制 (Git)、CI/CD 流程。

项目背景

项目名称： 企业级智能知识库问答系统（基于 Llama-3-70B）
你的角色： 负责模型推理服务的工程化落地、CI/CD 流水线搭建及生产环境稳定性保障。
面临痛点：

模型文件巨大： 70B 量化模型接近 40GB，打包进 Docker 导致镜像拉取极慢，部署耗时久。
性能退化风险： 算法团队更新 Prompt 或调整解码参数（Decoding Params）后，经常导致推理延迟（Latency）暴涨，上线前难以察觉。
配置混乱： 代码、模型版本、Prompt 模版三者经常对不上，导致线上回答效果回滚。

核心解决方案：基于 GitOps 的全链路部署流水线

我设计了一套**"代码与模型解耦，性能卡点前置"**的 CI/CD 方案。

第一步：Git 仓库设计（版本控制策略）

在面试中强调："我采用了 Mono-repo（单体仓库）与配置分离的策略。"

核心代码库 (Application Repo)：
- 存放推理服务代码（基于 vLLM 或 TGI 封装的 API）。
- 存放 Dockerfile。
- 关键点： 绝对不放模型权重文件。
模型注册表 (Model Registry - YAML based)：
- 这是一个 Git 中的核心配置文件 models.yaml。
- 内容示例：
  yaml 复制代码
```
- model_id: "llama3-70b-chat-int4"
  version: "v2.1.0"
  s3_path: "s3://model-zoo/llama3/70b-awq-v2/" # 指向对象存储
  prompt_template: "prompts/rag_v2.jinja" # 指向具体的 Prompt 文件
  min_gpu_memory: "48GiB"
```
- 作用： 每次算法团队微调出新模型，只需要更新这个 YAML 文件并提交 MR (Merge Request)，就会触发发布流程。

第二步：CI 流程（持续集成 - 质量与性能的守门员）

当开发人员提交了代码修改，或者更新了 Prompt 模版时，GitLab CI/GitHub Actions 会触发。

阶段 1：基础构建与静态检查 (Build & Lint)

常规操作：Python 代码规范检查（Black/Isort），Dockerfile 语法检查。
亮点细节： 检查 requirements.txt 中的 PyTorch/CUDA 版本与 Docker 基础镜像中的 CUDA 版本是否冲突（这在大模型部署中是常见坑）。

阶段 2：单元测试 (Unit Test)

测试 Tokenizer：确保特定的业务关键词不会被错误分词。
测试 Prompt 模版：渲染 Jinja2 模版，检查生成的 Prompt 字符串是否符合 Llama-3 的 Chat 格式要求（避免模型生成乱码）。

阶段 3：GPU 冒烟与性能基准测试 (GPU Regression Testing) ------ 这是面试杀手锏

环境： 使用 Self-hosted Runner（自建的带 GPU 的 CI 服务器）。
操作：
1. CI 脚本拉起 vLLM 服务容器。
2. 功能测试： 发送一个简单的 "Health Check" 请求，确保模型加载成功，显存没有 OOM。
3. 性能基准比对：
  - 运行脚本，并发发送 50 条典型请求。
  - 记录 TTFT (首字延迟) 和 TPOT (生成速率)。
  - 判定逻辑： 如果新版本的 TPOT 比主分支（Master）慢了 10% 以上，CI 直接报错，禁止合并。
- 价值： 杜绝了"代码改动导致推理变慢"的代码上线。

第三步：CD 流程（持续部署 - 快速且安全的上线）

当 CI 通过，代码合并到 Main 分支后。

策略 1：瘦身镜像构建 (Slim Docker Image)

面试话术： "为了解决 40GB 镜像传输慢的问题，我将模型权重（Model Weights）从镜像中剥离。"
做法： Docker 镜像只包含代码和依赖环境（约 2GB）。模型权重在 Pod 启动时，通过 K8s 的 initContainer 从 S3/OSS 挂载或下载到共享卷（PVC）中。

策略 2：K8s 滚动更新与就绪探测 (Rolling Update & Readiness Probe)

挑战： 70B 模型加载到 GPU 需要 2-3 分钟，如果 Pod 刚启动就导入流量，服务会报错。
解决方案：
- 配置 K8s Readiness Probe。
- 脚本：curl localhost:8000/v1/models。
- 只有当推理引擎完全将模型加载进显存，返回 HTTP 200 时，K8s Service 才会把流量切给这个新 Pod。

策略 3：金丝雀发布 (Canary Release)

对于重大版本更新（比如从 Llama-2 换到 Llama-3）：
- 利用 Istio 或 Ingress Nginx。
- 设置 Canary 权重为 5%。
- 观察 10 分钟，监控 Grafana 面板上的 显存使用率 和 请求错误率。
- 无异常后，自动全量发布。

面试中的"高光总结"话术（可以直接背诵）

如果面试官问："你如何保证大模型部署的稳定性？" 你可以这样回答：

"在之前的项目中，我负责 Llama-3 70B 的部署。为了解决大模型迭代中常见的性能退化 和版本混乱问题，我基于 Git 和 CI/CD 建立了一套标准化的工程流：

版本控制方面：我实施了'模型配置化'（Model-as-Code），将模型权重路径、Prompt 模版和推理参数统一在 Git 中管理，确保了环境的严格可复现。

CI 环节 ：我引入了 GPU 自动化回归测试。在代码合并前，流水线会自动拉起容器进行推理基准测试。我们设定了阈值，如果新代码导致首字延迟（TTFT）增加超过 10%，流水线会自动拦截。这直接避免了多次潜在的性能事故。

CD 环节 ：针对大模型镜像过大的问题，我采用了权重与镜像解耦的构建策略，配合 K8s 的就绪探针（Readiness Probe），确保模型完全加载进显存后才承接流量，实现了服务发布的零宕机（Zero Downtime）。"

这套回答的优势：

逻辑清晰： 从 Git -> CI -> CD 闭环。
有细节： 提到了 TTFT、TPOT、Readiness Probe、OOM 等专业术语。
解决了实际问题： 慢、不稳、不可回溯，这些都是企业最头疼的问题。

1. `prompts/rag_v2.jinja` 是干啥的？里面啥内容？

作用：

在大模型工程中，Prompt 不是简单的字符串拼接，它需要严格遵循模型训练时的格式（Chat Template）。jinja 是 Python 最通用的模板引擎。我们将 Prompt 逻辑抽离成 .jinja 文件，是为了将"提示词工程"与"后端代码"解耦。

里面有什么？（以 Llama-3 为例）

它包含了 System Message（人设）、User Message（用户问题）、Context（RAG 查到的资料）以及最重要的特殊控制符（Special Tokens）。

文件内容示例 (prompts/rag_v2.jinja)：

jinja2 复制代码

{# Llama-3 的标准格式开头 #}
<|begin_of_text|>

{# 系统指令区：定义人设和 RAG 规则 #}
<|start_header_id|>system<|end_header_id|>

你是一个专业的企业助手。请基于以下【参考资料】回答用户问题。如果资料中没有答案，请说"我不知道"，严禁编造。

【参考资料】：
{{ context_str }}  {# 变量：这是后端 RAG 检索回来的文档片段 #}
<|eot_id|>

{# 用户提问区 #}
<|start_header_id|>user<|end_header_id|>

{{ query_str }}    {# 变量：这是用户的实际问题 #}
<|eot_id|>

{# 引导模型开始输出 #}
<|start_header_id|>assistant<|end_header_id|>

面试加分点：

"为什么要用 Jinja？因为 Llama-3、Qwen-1.5、Mistral 的特殊符都不一样。通过 Jinja 模版，我在切换模型时，只需要换个模版文件，后端 Python 代码（template.render()）一行都不用改。"

2. 更新 YAML 后，完整的发布流程链条是什么？

这是一个典型的 GitOps 流程。假设你提交了 MR 更新了 models.yaml 中的 version。

全链路流程图：

开发提交 (Trigger): 你将 models.yaml 推送到 GitLab 的 feature/update-model 分支，并创建 MR。
CI 启动 (Pre-merge): GitLab Runner 启动，检测到 YAML 变更。
- 运行校验脚本：检查 S3 上该路径的模型文件是否存在？MD5 校验码对不对？
- 通过后，Team Leader 点击 Merge。
构建镜像 (Build): 合并到 main 分支触发主流水线。
- Docker Build 启动。由于我们策略是"代码与模型分离"，这个构建极快（只打代码层），生成镜像 my-llm-service:v2。
- 推送到公司内部的 Harbor 仓库。
配置同步 (Sync):
- CI 脚本调用 K8s API 或修改 Helm Chart 中的 ConfigMap，将 models.yaml 的新内容更新到集群配置中。
CD 部署 (Deploy):
- ArgoCD（GitOps 工具）检测到 Helm Chart 变化。
- 它控制 K8s 创建新的 Pod。
- 关键点： 新 Pod 的 initContainer（初始化容器）读取 ConfigMap，使用 aws s3 cp (或者阿里云 ossutil) 将新模型权重下载到 Pod 的共享存储卷中。
流量切换 (Switch):
- 应用容器启动 -> 加载模型 -> 暴露端口。
- K8s Readiness Probe 探测通过。
- Service 修改 Endpoints，流量打入新 Pod。老 Pod 销毁。

3. Black/Isort 是啥？谁来检查？

这是代码洁癖的"看门狗"，保证团队协作时代码风格统一。

Black: Python 代码格式化工具。它非常霸道，不管你怎么写，它都会把你强制改成它认为"好看"的样子（比如统一双引号，统一缩进）。
Isort: 专门用来给 import 排序的。它会把标准库、第三方库、本地库的引用分好类，按字母排序。

谁来检查？
GitLab CI (Runner) 来检查。

具体实现：

在 CI 配置文件（.gitlab-ci.yml）里有这么一段：

yaml 复制代码

lint_check:
  stage: test
  script:
    - pip install black isort
    - black --check .  # 如果代码没格式化，这里直接报错，CI 红灯
    - isort --check-only .

面试话术： "如果开发人员的代码乱糟糟的没有格式化，CI 流水线在第一步就会直接 Fail 掉，根本不会进入后续的构建环节，强迫大家养成规范。"

4. 怎么检查 PyTorch/CUDA 版本冲突？

这是一个痛点。Docker 基础镜像里有 CUDA 驱动（如 12.1），但 requirements.txt 里可能写了 torch==2.1.0+cu118。这会导致 GPU 无法调用。

具体检查脚本逻辑（Python 脚本）：

读取 Dockerfile: 正则提取 FROM 行的基础镜像 Tag，例如 nvcr.io/nvidia/pytorch:23.10-py3。去查阅该 Tag 对应的 CUDA 版本（比如是 12.2）。
读取 requirements.txt: 解析 torch 版本。
- 如果写着 index-url https://download.pytorch.org/whl/cu118 -> 提取出 cu118 (CUDA 11.8)。
比对逻辑:
- 如果 Docker_CUDA_Major_Ver < Torch_CUDA_Major_Ver：报错（驱动旧跑不了新软件）。
- 如果差异过大：警告。
CI 实现: 这个 Python 脚本作为 CI 的一步运行。

5. 单元测试是自动的嘛？具体怎么实现的？

必须是自动的。 只要代码 push 上去，GitLab CI 就会跑。

具体实现工具： pytest

怎么测（不依赖 GPU 的部分）：

你不需要显卡也能测很多东西。

Mock 测试: 我们会 Mock 掉底层的推理引擎（比如 vLLM 的 LLMEngine 类）。

测试用例示例：

python 复制代码

# test_api.py
def test_chat_template_rendering():
    # 测试 Jinja 模版是不是写错了
    prompt = render_template("rag_v2.jinja", query="你好", context="...")
    assert "<|start_header_id|>system" in prompt  # 检查关键符是否存在

def test_request_validation():
    # 测试如果用户发了空字符串，API 是否返回 400
    response = client.post("/v1/chat", json={"query": ""})
    assert response.status_code == 400

6. 大陆环境 CI 细节与硬件分配方案

这是最考验实战经验的部分。由于网络封锁和硬件昂贵，我们不能像国外那样随意。

技术栈 (大陆企业标配)：

代码仓: GitLab (私有部署)
CI 工具: GitLab Runner
制品库: Harbor (存 Docker 镜像)
模型存储: MinIO (自建 S3) 或阿里云 OSS / 腾讯云 COS
镜像源: 必须配置 pip 清华源，Docker 镜像加速器（现在很难搞，通常需要自建代理）。
HuggingFace: 必须要用 HF-Mirror 或者下载好模型存到内网 OSS。

硬件资源分配策略 (根据你手头的卡)：

你有的卡：A100, A800, H20, V100, RTX5880, RTX6000, P100

CI/CD 流水线硬件分配：

CI - 静态检查 & 单元测试 (Lint/Unit Test):
- 硬件: CPU 服务器 (不需要显卡)。
- 原因: 跑 black, pytest 不需要 GPU，别浪费资源。
CI - 冒烟测试与构建 (Smoke Test):
- 硬件: RTX 5880 Ada 或 RTX 6000。
- 原因:
  - CI 需要频繁跑，RTX 系列显存大（48GB），推理速度快，且比数据中心卡（A800）便宜，适合拿来做 dirty work。
  - 如果模型是 70B 的量化版（Int4 约 40GB），RTX 6000 (48G) 刚好能塞下，跑通测试。
- 备选: V100 (32G)。如果模型切分了 TP (Tensor Parallelism) 或者模型比较小（8B/14B），用 V100 这种老卡跑 CI 也就是验证个功能，完全够用。
生产环境 (Production):
- 硬件: H20 和 A800。
- 原因:
  - H20: 专门针对大陆合规的高带宽卡，适合 推理 (Inference)，尤其是大并发场景。它的显存带宽大，吞吐量高。
  - A800: 硬通货，互联带宽强，适合做 训练/微调 (SFT) 或者超大模型的推理（需要多卡 NVLink 互联）。
  - A100: 如果有存货，那是宝贝，和 A800 一样用。
P100 怎么用？
- 扔给开发人员做 Debug 调试 或者跑跑 7B 以下的小模型。因为架构太老（Pascal），很多新算子（FlashAttention）不支持，不建议进生产或关键 CI。

CI 流程中的特殊设计（大陆网络）：

在 .gitlab-ci.yml 中，我会显式注入环境变量：