## 一、模型规模：参数量的意义与代价

### 1.1 参数量的直观理解

| 规模         | 参数量    | 显存需求（FP16） | 典型代表                      | 适用场景                     |
| ------------ | --------- | ---------------- | ----------------------------- | ---------------------------- |
| **小模型**   | 1B - 7B   | 2 - 14 GB        | LLaMA-2-7B, Qwen-7B           | 边缘设备、单卡推理、实时对话 |
| **中模型**   | 13B - 30B | 26 - 60 GB       | LLaMA-2-13B, Baichuan-13B     | 企业级应用、复杂推理         |
| **大模型**   | 65B - 72B | 130 - 144 GB     | LLaMA-2-70B, DeepSeek-67B     | 高精度任务、研究探索         |
| **超大模型** | 100B+     | 200 GB+          | GPT-4（估计 1.8T）, PaLM-540B | 通用人工智能、多模态         |

**关键认知**：

- **1B = 10 亿可训练参数**，每个参数存储模型从数据中学到的"知识"
- **参数量 ∝ 模型容量**：更多参数 = 更强的模式记忆、更长的上下文关联
- **参数量 ∝ 计算成本**：推理时每个 token 都要与所有参数计算，72B 比 7B 慢 10 倍

### 1.2 规模选择的工程权衡

```
# 决策框架：在满足质量的前提下，选最小的模型

def select_model(requirements):
    if latency < 100ms and device == "mobile":
        return "1B-4B INT4量化"      # 端侧优先
    
    if concurrency > 1000 and task == "简单分类":
        return "7B FP16"              # 吞吐优先
    
    if task in ["代码生成", "数学推理", "长文档分析"]:
        return "13B-72B"              # 质量优先
    
    if budget == "unlimited" and research == True:
        return "72B+ 或 MoE"          # 探索性任务
    
    return "7B-13B 性价比最优"        # 默认选择
```

------

## 二、精度与量化：用质量换速度的艺术

### 2.1 数值精度对比

| 精度          | 每参数字节 | 相对速度   | 相对显存  | 质量损失 | 适用场景               |
| ------------- | ---------- | ---------- | --------- | -------- | ---------------------- |
| **FP32**      | 4 bytes    | 1×（基准） | 100%      | 0%       | 训练阶段、精度敏感研究 |
| **FP16/BF16** | 2 bytes    | **2×**     | **50%**   | <1%      | **推理默认标准**       |
| **INT8**      | 1 byte     | 3-4×       | 25%       | 2-5%     | 消费级 GPU、边缘部署   |
| **INT4/GPTQ** | 0.5 bytes  | 4-8×       | **12.5%** | 5-10%    | 手机、嵌入式、高并发   |
| **NF4/QLoRA** | ~0.5 bytes | -          | 12.5%     | 3-7%     | 单卡微调大模型         |

### 2.2 量化技术详解

**为什么 INT8/INT4 能工作？**

```
# 核心思想：把浮点权重映射到整数范围
# FP16 权重范围: [-0.5, 0.5, 1.2, -1.5, ...]
# 量化后 INT8: [-64, 64, 154, -192, ...]  # 缩放因子 scale = 128/1.5 ≈ 85.3

# 推理时反量化：INT8 × scale ≈ 原始 FP16
# 损失来源：小数部分被四舍五入，极端值被截断
```

**主流量化方案**：

| 方案               | 特点                             | 命令示例                         |
| ------------------ | -------------------------------- | -------------------------------- |
| **GPTQ**           | 逐层量化，校准数据少，4bit 主流  | `python -m gptq.llama --wbits 4` |
| **AWQ**            | 激活感知，保护重要权重，精度更高 | `python -m awq.entry --w_bit 4`  |
| **GGUF/llama.cpp** | CPU 友好，支持多种量化组合       | `./quantize model.gguf Q4_K_M`   |
| **SmoothQuant**    | 激活-权重联合量化，INT8 推理最优 | 集成于 vLLM、TensorRT-LLM        |

### 2.3 显存计算公式

```
def estimate_memory(params_b, precision="fp16", batch=1, seq_len=2048, kv_cache=True):
    """
    快速估算模型推理显存需求
    """
    bytes_per_param = {
        "fp32": 4, "fp16": 2, "bf16": 2,
        "int8": 1, "int4": 0.5
    }[precision]
    
    # 权重显存
    model_memory = params_b * 1e9 * bytes_per_param / (1024**3)  # GB
    
    # KV-Cache 显存（每 token 每头需要 2×hidden_dim×bytes）
    # 简化估算：约 2 × seq_len × batch × hidden_dim × layers × bytes
    kv_memory = 0
    if kv_cache:
        # 以 LLaMA-7B 为例: hidden=4096, layers=32, heads=32
        hidden, layers, heads = 4096, 32, 32
        kv_per_token = 2 * hidden * bytes_per_param  # K + V
        kv_memory = seq_len * batch * layers * kv_per_token / (1024**3)
    
    # 激活值、临时缓冲（约 10-20% 额外）
    overhead = model_memory * 0.2
    
    total = model_memory + kv_memory + overhead
    return {
        "model_weights": round(model_memory, 2),
        "kv_cache": round(kv_memory, 2),
        "overhead": round(overhead, 2),
        "total_gb": round(total, 2),
        "recommend_gpu": f"A100-{80 if total > 40 else 40}GB" if total > 20 else "RTX-4090-24GB"
    }

# 使用示例
print(estimate_memory(7, "fp16", batch=16, seq_len=4096))
# {'model_weights': 13.0, 'kv_cache': 16.0, 'overhead': 2.6, 'total_gb': 31.6, 'recommend_gpu': 'A100-40GB'}
```

------

## 三、训练三阶段：从"会说话"到"懂规矩"

### 3.1 预训练（Pre-training）：海量数据灌入

```
数据：互联网公开文本（Common Crawl、Books、Wiki、Code）
规模：1T - 10T tokens（1 token ≈ 0.75 英文单词）
目标：预测下一个词（Next Token Prediction）
输出：基础模型（Base Model），会说人话但不懂指令
```

**关键工程挑战**：

- **数据清洗**：去重、过滤垃圾、去毒（toxic content）
- **分布式训练**：千卡级 GPU 集群，3D 并行（数据+张量+流水线）
- **稳定性**：loss 突跳、梯度爆炸、硬件故障容错

### 3.2 监督微调（SFT）：学会"听指令"

```
数据：人工编写的高质量（指令，回答）对，通常 10万 - 100万条
目标：最大化回答质量（而非预测下一个词）
输出：指令模型（Instruct Model），能按格式回答问题
```

**典型数据集**：

- Alpaca（52k 指令，开源标杆）
- ShareGPT（真实 ChatGPT 对话）
- 企业私有数据（客服记录、内部文档）

### 3.3 对齐（RLHF）：价值观与安全

```
数据：人对多个回答的排序偏好（A > B > C）
方法：
  1. 训练奖励模型（Reward Model）：学会打分
  2. PPO 强化学习：让策略模型生成高分回答
输出：对齐模型（Aligned Model），有用、无害、诚实
```

**替代方案：DPO（Direct Preference Optimization）**

- 跳过奖励模型，直接用偏好数据优化
- 更简单、更稳定，效果接近 RLHF

------

## 四、模型架构：Transformer 一统天下

### 4.1 核心组件：自注意力机制

```
# 伪代码：Scaled Dot-Product Attention
def attention(Q, K, V, mask=None):
    """
    Q: Query (batch, seq, dim)  - "我要查什么"
    K: Key   (batch, seq, dim)  - "我有什么信息"
    V: Value (batch, seq, dim)  - "信息的内容"
    """
    scores = Q @ K.T / sqrt(dim)        # 相似度打分
    if mask:
        scores = scores.masked_fill(mask, -inf)  # 因果掩码（只看前面）
    weights = softmax(scores, dim=-1)   # 归一化为概率
    output = weights @ V                # 加权求和
    return output, weights              # 输出 + 注意力权重（可可视化）
```

**直观理解**：

- 读句子时，每个词都"回头看"所有前面的词
- "它"这个词，注意力权重在"猫"上最高 → 模型学会指代消解

### 4.2 GPT vs BERT：两种路线

| 特性         | GPT（生成式）            | BERT（理解式）                 |
| ------------ | ------------------------ | ------------------------------ |
| **结构**     | Decoder-only（因果掩码） | Encoder-only（双向 attention） |
| **训练目标** | 预测下一个词             | 掩码语言模型（MLM）            |
| **代表**     | GPT-4, LLaMA, ChatGLM    | BERT, RoBERTa, ERNIE           |
| **擅长**     | 文本生成、对话、代码     | 分类、NER、语义搜索            |
| **输入输出** | 前缀 → 续写              | 完整句子 → 向量表示            |

**现代趋势**：GPT 架构一统江湖，BERT 类模型逐渐边缘化。

### 4.3 KV-Cache：推理加速的关键

**问题**：生成第 N 个 token 时，前 N-1 个 token 的 K/V 被重复计算

**解法**：把算过的 K/V 存起来，只算新的

```
# 推理时的优化
past_kvs = []           # 缓存列表
for i in range(max_length):
    # 只输入最新的 1 个 token，但 K/V 是完整的
    logits, new_kvs = model.forward(
        input_ids=[new_token], 
        past_key_values=past_kvs   # 传入缓存
    )
    past_kvs.append(new_kvs)       # 更新缓存
    
    # 计算量从 O(N²) 降到 O(N)
```

**显存代价**：缓存随序列长度线性增长，长文本需小心 OOM。

------

## 五、推理加速：从实验室到生产线

### 5.1 批处理策略演进

| 策略                                                   | 原理                           | 吞吐提升  | 延迟         | 适用               |
| ------------------------------------------------------ | ------------------------------ | --------- | ------------ | ------------------ |
| **静态批（Static Batching）**                          | 等够 N 条一起发                | 3-5×      | 高（等凑齐） | 离线任务           |
| **动态批（Dynamic Batching）**                         | 有就来，超时未满也发           | 2-4×      | 中           | 通用 API           |
| **连续批（Continuous Batching / In-flight Batching）** | 每完成一条立即补新，流水线不停 | **5-10×** | 低           | **高并发在线服务** |

**vLLM 的 PagedAttention**：把 KV-Cache 分页管理，像操作系统管理内存，支持高效的连续批。

### 5.2 投机解码（Speculative Decoding）

```
小模型（草稿模型）：快速生成 3-5 个 token 候选
大模型（目标模型）：一次验证，接受或回滚

效果：小模型算 5 步 ≈ 大模型算 1 步，整体提速 30-50%
条件：小模型质量不能太差（通常用 7B 草拟，70B 验证）
```

### 5.3 其他加速技术

| 技术                       | 原理                                    | 收益              |
| -------------------------- | --------------------------------------- | ----------------- |
| **FlashAttention**         | IO 感知的 attention 算法，减少 HBM 读写 | 2-4× 速度，省显存 |
| **Tensor Parallel (TP)**   | 单层网络切开，多卡同时算                | 单节点线性扩展    |
| **Pipeline Parallel (PP)** | 不同层放不同卡，流水线接力              | 跨节点扩展        |
| **量化推理**               | INT8/INT4 kernel 优化                   | 2-4× 吞吐         |

------

## 六、高效微调：小资源玩转大模型

### 6.1 LoRA：低秩适配

```
# 原始权重 W (d×d)，冻结不动
# 只训练两个小子矩阵 A (d×r), B (r×d)，r << d（通常 r=8,16,64）

h = W @ x + (B @ A) @ x   # 前向：原始输出 + LoRA 分支
# 训练参数：2×d×r vs 原始 d×d，节省 99.9%（当 r=16, d=4096）
```

**优势**：

- 显存省 3×（只存优化器状态到 A,B）
- checkpoint 小（MB 级 vs GB 级）
- 多任务切换时，换 LoRA 权重即可，基座不动

### 6.2 QLoRA：极致压缩

```
4-bit Normal Float 量化基座模型
    +
Paged Optimizer（分页优化器，避免梯度 checkpoint 碎片）
    +
LoRA 微调
    =
单张 RTX-4090-24GB 微调 70B 模型
```

**关键参数**：

```
python qlora.py \
  --model_name_or_path meta-llama/Llama-2-70b \
  --bits 4 \
  --lora_r 64 \
  --lora_alpha 16 \
  --max_memory 24GB \
  --per_device_train_batch_size 1
```

------

## 七、评估指标：如何说"这个模型好"

| 指标                             | 定义                      | 测什么       | 好模型的值                       |
| -------------------------------- | ------------------------- | ------------ | -------------------------------- |
| **Perplexity (PPL)**             | 模型预测下一个词的困惑度  | 语言建模能力 | 越低越好（7B 模型 ~ 10-15）      |
| **BLEU/ROUGE**                   | n-gram 重叠度             | 翻译、摘要   | 越高越好                         |
| **HumanEval**                    | 代码通过率                | 编程能力     | GPT-4 ~ 67%, CodeLlama-34B ~ 48% |
| **MMLU**                         | 多学科选择题              | 知识广度     | GPT-4 ~ 86%, LLaMA-2-70B ~ 69%   |
| **首 Token 延迟 (TTFT)**         | 用户输入 → 首个输出 token | 响应速度     | < 100ms（实时交互）              |
| **Time Per Output Token (TPOT)** | 每生成一个 token 的时间   | 流畅度       | < 50ms（人类阅读速度）           |
| **吞吐 (Throughput)**            | 每秒输出 token 数         | 并发能力     | 越高越好，决定成本               |

------

## 八、生态工具：站在巨人肩膀上

### 8.1 Hugging Face：模型界的 GitHub

```
# 一行代码下载模型
from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-2-7b-chat-hf")
tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-2-7b-chat-hf")

# 推理
inputs = tokenizer("The future of AI is", return_tensors="pt")
outputs = model.generate(**inputs, max_new_tokens=50)
print(tokenizer.decode(outputs[0]))
```

**关键服务**：

- **Model Hub**：10万+ 预训练模型
- **Datasets**：数万数据集
- **Spaces**：模型 Demo 托管
- **Inference API**：即开即用的模型推理端点

### 8.2 vLLM：生产级推理引擎

```
# 启动服务
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-2-7b \
  --tensor-parallel-size 2 \
  --dtype half

# 客户端调用（OpenAI 兼容 API）
curl http://localhost:8000/v1/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-llama/Llama-2-7b",
    "prompt": "San Francisco is a",
    "max_tokens": 7
  }'
```

**核心特性**：

- PagedAttention 高效 KV-Cache 管理
- 连续批处理（Continuous Batching）
- 张量并行、流水线并行
- OpenAI API 兼容

### 8.3 DeepSpeed：微软的训练加速库

```
# ZeRO-3：把优化器状态、梯度、参数都切分到多卡
deepspeed --num_gpus=8 train.py \
  --deepspeed_config ds_config_zero3.json

# 关键配置
{
  "zero_optimization": {
    "stage": 3,                    # ZeRO-3：全分片
    "offload_optimizer": {         # CPU/NVMe 卸载
      "device": "cpu",
      "pin_memory": true
    }
  },
  "train_batch_size": "auto",
  "train_micro_batch_size_per_gpu": "auto"
}
```

**能力**：

- ZeRO（零冗余优化器）：省显存 4-8×
- 3D 并行（数据+张量+流水线）
- MoE（专家混合）训练支持

------

## 九、选型决策树

```
开始
  │
  ▼
需要训练新模型？ ──Y──→ 数据量 > 1B tokens？
  │                      │
  N                      Y ──→ DeepSpeed + 千卡集群
  │                      │
  ▼                      N ──→ LoRA/QLoRA 微调
需要推理服务？
  │
  Y ──→ 并发 > 1000 QPS？
  │        │
  │        Y ──→ vLLM + TensorRT-LLM + 连续批
  │        │
  │        N ──→ HuggingFace TGI / 简单 transformers
  │
  ▼
端侧部署（手机/边缘）？
  │
  Y ──→ llama.cpp (GGUF) / MLC-LLM / 高通 QNN
  │
  ▼
结束
```

------

## 十、关键术语速查表

| 术语                                     | 一句话解释                                           |
| ---------------------------------------- | ---------------------------------------------------- |
| **Token**                                | 模型处理的最小单位，1 token ≈ 0.75 英文词 / 0.5 汉字 |
| **Context Length**                       | 模型能"记住"的上下文长度，如 4K, 32K, 128K           |
| **Temperature**                          | 采样随机性，0=确定，1=创意，>1=混乱                  |
| **Top-p / Nucleus Sampling**             | 只从累积概率前 p% 的 token 中采样                    |
| **Repetition Penalty**                   | 惩罚重复 token，防止车轱辘话                         |
| **System Prompt**                        | 全局指令，设定模型角色和行为准则                     |
| **Few-shot Prompting**                   | 给几个例子，让模型模仿                               |
| **Chain-of-Thought (CoT)**               | "让我们一步步想"，提升推理能力                       |
| **RAG (Retrieval-Augmented Generation)** | 外挂知识库，解决幻觉和时效性                         |



大语言模型基础

## 一、Tmux —— 经典之选，服务器标配

**Tmux** 是目前最主流的终端复用器，几乎所有 Linux 服务器预装，社区生态最成熟。

### 核心操作速查

```
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# 会话管理（Session）
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

# 新建会话（指定名称）
tmux new -s myproject

# 断开会话（后台保持运行）—— 快捷键
Ctrl+b  d

# 重新连接会话
tmux attach -t myproject
# 简写
tmux a -t myproject

# 列出所有会话
tmux ls

# 切换会话
tmux switch -t another

# 重命名当前会话
Ctrl+b  $
# 或命令行
tmux rename-session -t oldname newname

# 杀掉会话
tmux kill-session -t myproject

# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# 窗口管理（Window）—— 类似浏览器标签页
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Ctrl+b  c       # 新建窗口
Ctrl+b  n       # 下一个窗口
Ctrl+b  p       # 上一个窗口
Ctrl+b  0~9     # 切换到指定编号窗口
Ctrl+b  w       # 可视化选择窗口
Ctrl+b  &       # 关闭当前窗口（需确认）

# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# 窗格管理（Pane）—— 分屏操作
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Ctrl+b  %       # 垂直分割（左右）
Ctrl+b  "       # 水平分割（上下）
Ctrl+b  方向键   # 切换窗格
Ctrl+b  z       # 最大化/还原当前窗格
Ctrl+b  x       # 关闭当前窗格
Ctrl+b  空格     # 切换布局模式

# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# 实用功能
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Ctrl+b  [       # 进入滚动/复制模式（按 q 退出）
Ctrl+b  =       # 粘贴缓冲区内容
Ctrl+b  ?       # 查看所有快捷键
Ctrl+b  :       # 进入命令模式（如输入 kill-session）
```

### 实用配置建议（~/.tmux.conf）

```
# 修改前缀键为 Ctrl+a（更符合习惯）
unbind C-b
set -g prefix C-a
bind C-a send-prefix

# 鼠标支持
set -g mouse on

# 窗口从 1 开始计数（更符合键盘位置）
set -g base-index 1
setw -g pane-base-index 1

# 状态栏美化
set -g status-style bg=black,fg=white
set -g window-status-current-style bg=blue,fg=white,bold
```

------

## 二、Zellij —— 现代 Rust 神器，零配置开箱即用

**Zellij** 用 Rust 重写，提供现代化的 UI、内置布局系统，对鼠标和键盘都极友好。

### 核心操作速查

```
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# 会话管理
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

# 新建会话（自带欢迎界面，可选布局）
zellij

# 指定名称启动
zellij --session mydev

# 后台分离（detach）
Ctrl+g  d        # 或点击 UI 中的 detach 按钮

# 重新连接
zellij attach mydev

# 列出会话
zellij list-sessions
# 简写
zellij ls

# 杀掉会话
zellij kill-session mydev
zellij kill-all-sessions  # 清理全部

# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# 窗格/标签管理（Zellij 概念：Pane + Tab）
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Ctrl+g  n       # 新建标签页（Tab）
Ctrl+g  t       # 切换标签（或鼠标点击）
Ctrl+g  x       # 关闭当前标签

Ctrl+g  p       # 新建窗格（智能分割）
Ctrl+g  方向键   # 切换窗格
Ctrl+g  f       # 全屏切换当前窗格
Ctrl+g  e       # 编辑当前窗格滚动缓冲区

# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# 布局系统（Zellij 杀手级功能）
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

# 使用内置布局启动
zellij --layout strider    # 文件管理器 + 终端
zellij --layout compact    # 紧凑开发布局

# 保存当前布局
Ctrl+g  Ctrl+o   # 导出当前布局为 kdl 文件
```

### Zellij 独有优势

```
# 浮动窗格（类似弹出窗口）
Ctrl+g  w       # 打开浮动终端，按任意键关闭

# 滚动搜索
Ctrl+g  s       # 进入搜索模式，/ 搜索，n/N 跳转

# 重新绑定快捷键（无需配置文件）
zellij setup --dump-config > ~/.config/zellij/config.kdl
```

------

## 三、GNU Screen —— 老牌经典，极简稳定

**Screen** 历史悠久，几乎所有 Unix 系统都有预装，适合极简环境。

### 核心操作速查

```
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# 会话管理
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

# 新建会话
screen -S mytask

# 分离会话（后台运行）
Ctrl+a  d

# 重新连接
screen -r mytask

# 列出会话
screen -ls

# 杀掉会话
screen -S mytask -X quit
# 或进入后
Ctrl+a  k       # 然后 y 确认

# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# 窗口管理
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Ctrl+a  c       # 新建窗口
Ctrl+a  n       # 下一个窗口
Ctrl+a  p       # 上一个窗口
Ctrl+a  0~9     # 跳转到窗口
Ctrl+a  "       # 列出所有窗口（可视化选择）
Ctrl+a  A       # 重命名当前窗口

# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# 分屏（Screen 的分屏较原始）
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Ctrl+a  S       # 水平分割区域
Ctrl+a  |       # 垂直分割（较新版本）
Ctrl+a  Tab     # 切换区域
Ctrl+a  X       # 关闭当前区域
```

------

## 四、Byobu —— Ubuntu 官方推荐，状态栏神器

**Byobu** 是 tmux/screen 的增强前端，提供华丽的状态栏和 F 键操作体系。

### 核心操作速查

```
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# 会话管理
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

# 启动（自动选择后端 tmux 或 screen）
byobu

# 新建命名会话
byobu new -s production

# 分离
F6              # 或 Ctrl+a d（取决于后端）

# 重新连接
byobu attach -t production

# 列出会话
byobu ls

# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# F 键快捷操作（Byobu 特色）
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

F2              # 新建窗口
F3 / F4         # 上一个/下一个窗口
F5              # 刷新状态栏
F7              # 滚动模式（空格标记，Enter 复制）
F8              # 重命名窗口
F9              # 配置菜单（交互式设置）
F12             # 锁定屏幕

Shift+F2        # 水平分屏
Ctrl+F2         # 垂直分屏
Shift+方向键     # 切换窗格
```

------

## 五、Mosh —— SSH 断网救星，配合复用工具使用

**Mosh** 不是复用工具，但常与 tmux 配合使用，解决 SSH 弱网/断线问题。

```
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# 基础用法
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

# 替代 SSH 连接（UDP 协议，自动重连）
mosh user@server

# 指定端口
mosh --ssh="ssh -p 2222" user@server

# 连接后自动进入 tmux
mosh user@server -- tmux attach -t work

# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# 典型工作流：Mosh + Tmux 黄金组合
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

# 1. 本地连接（即使切换 WiFi 也不中断）
mosh server -- zellij attach dev

# 2. 关闭笔记本盖子 → 回家 → 打开 → 自动恢复
# 3. 手机流量开热点 → 无缝切换网络
```

------

## 六、工具选型速查表

| 你的需求           | 推荐工具        | 理由                          |
| ------------------ | --------------- | ----------------------------- |
| 服务器运维，求稳   | **tmux**        | 预装率高，文档丰富            |
| 现代体验，鼠标友好 | **Zellij**      | 开箱即用，UI 美观             |
| 老旧系统兼容       | **screen**      | 无处不在，零依赖              |
| 状态栏信息丰富     | **byobu**       | 自带系统监控，Ubuntu 官方支持 |
| 经常切换网络       | **mosh + tmux** | 漫游不断连                    |
| 不想记快捷键       | **Zellij**      | 可视化提示，鼠标可操作        |

------

## 七、效率倍增技巧

```
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# 1. 会话命名规范（防止混乱）
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

tmux new -s prod-api        # 生产环境 API 服务
tmux new -s dev-frontend    # 本地前端开发
tmux new -s train-gpu       # 模型训练任务

# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# 2. 一键恢复工作流（添加到 ~/.bashrc）
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

# 自动恢复或新建开发会话
alias dev='tmux attach -t dev 2>/dev/null || tmux new -s dev'

# 快速进入项目
alias proj='cd ~/project && dev'

# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# 3. 跨设备同步会话（配合 tmux-resurrect 插件）
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

# 安装插件后，保存/恢复完整会话状态
Ctrl+b Ctrl+s   # 保存会话（包括 vim 等程序状态）
Ctrl+b Ctrl+r   # 恢复会话（重启服务器后也能找回）
```

------

## 总结

终端复用工具的核心价值在于**会话持久化**和**工作区组织**。

- **入门首选**：Zellij（零配置，体验现代）
- **深入必学**：Tmux（生态最广，服务器标配）
- **断网无忧**：Mosh + Tmux 组合

终端复用工具

## 一、什么是终端复用？

### 核心定义

终端复用（Terminal Multiplexer）是一种**在单个物理终端窗口中管理多个虚拟终端会话**的软件层。它位于操作系统内核与用户 Shell 之间，提供以下关键能力：

```
┌───────────────────────────────────────┐
│           用户界面层                   │
│    （iTerm2、Windows Terminal、Kitty） │
├───────────────────────────────────────┤
│      🔧 终端复用层（Tmux/Zellij）      │  ← 核心位置
│   • 会话管理  • 窗口分割  • 状态保持    │
├───────────────────────────────────────┤
│           Shell 层（Bash/Zsh）         │
├───────────────────────────────────────┤
│           操作系统内核                 │
└───────────────────────────────────────┘
```

### 解决的三大痛点

| 痛点           | 传统终端                      | 复用工具               |
| -------------- | ----------------------------- | ---------------------- |
| **网络中断**   | SSH 断开，任务终止            | 会话保持后台，随时重连 |
| **单窗口限制** | 开多个终端窗口混乱            | 单窗口多会话，分屏管理 |
| **上下文丢失** | 关闭终端 = 丢失工作目录、历史 | 完整状态持久化         |

------

## 二、核心架构与工作原理

### 1. 会话生命周期管理

```
# 传统 SSH 连接的生命周期
[本地终端] ──SSH──► [远程 Shell 进程]
     │                    │
     │ 网络断开            │ 进程收到 SIGHUP，终止
     ▼                    ▼
  连接中断 ◄────────── 任务丢失

# 复用工具的生命周期
[本地终端] ──SSH──► [Tmux Server 守护进程] ◄── 长期存活
                         │
              ┌─────────┼─────────┐
              ▼         ▼         ▼
         [Shell A]  [Shell B]  [Shell C]
         运行任务    编辑文件    监控日志
              │         │         │
              └─────────┴─────────┘
                    网络断开不影响
              [新终端] ──attach──► 恢复原状
```

### 2. 核心组件模型

| 组件        | 类比         | 功能                         |
| ----------- | ------------ | ---------------------------- |
| **Server**  | 操作系统服务 | 后台守护进程，管理所有会话   |
| **Session** | 浏览器窗口   | 独立的工作空间，包含多个窗口 |
| **Window**  | 浏览器标签页 | 全屏的虚拟终端，可切换       |
| **Pane**    | 分屏区域     | 窗口内的分割区域，同时可见   |

### 3. 进程关系图解

```
系统启动
   │
   ▼
┌─────────────┐     ┌─────────────┐
│ Tmux Server │◄────│ Zellij Daemon│  （二选一，长期运行）
│  (PID 1234) │     │  (PID 5678)  │
└──────┬──────┘     └─────────────┘
       │
       ├─────────────────────────────────┐
       │                                 │
       ▼                                 ▼
┌─────────────┐                 ┌─────────────┐
│ Session: dev │                │ Session: ops │
│ ┌─────────┐ │                │ ┌─────────┐   │
│ │Window 1 │ │                │ │Window 1 │   │
│ │ ┌─┬───┐ │ │                │ │ ┌───┐   │   │
│ │ │ │   │ │ │                │ │ │   │   │   │
│ │ │Pane │ │ │                │ │ │Pane │   │   │
│ │ │ 1  2│ │ │                │ │ └───┘   │   │
│ │ │ │   │ │ │                │ └─────────┘   │
│ │ └──┴───┘ │ │                │ Window 2...   │
│ └─────────┘ │                └─────────────┘
│ Window 2... │
└─────────────┘

用户通过 Client 连接 Server：
tmux attach → Unix Socket → Server → 恢复 Session 状态
```

------

## 三、技术演进时间线

```
1970s ─────────────────────────────────────────► 2020s

1987  GNU Screen 诞生
      └─ 首个终端复用器，解决拨号连接不稳定问题

2007  Tmux 发布
      └─ BSD 协议，现代化设计，分屏功能革新

2010s 配置生态爆发
      └─ Tmuxinator、Teamocil 等会话管理工具

2020  Zellij 发布（Rust 重写）
      └─ 零配置、插件系统、WebAssembly 扩展

2021  WezTerm、Tabby 等 GPU 终端内置复用
      └─ 终端与复用层边界模糊化

2023  AI 终端（Warp、Fig）兴起
      └─ 复用功能成为基础能力，转向智能化
```

------

## 四、主流工具深度对比

### 功能矩阵

| 特性           | GNU Screen    | Tmux        | Zellij    | Byobu        |
| -------------- | ------------- | ----------- | --------- | ------------ |
| **首次发布**   | 1987          | 2007        | 2020      | 2009         |
| **代码语言**   | C             | C           | Rust      | Python/Shell |
| **后端依赖**   | 无            | 无          | 无        | Tmux/Screen  |
| **默认安装**   | 几乎所有 Unix | 主流服务器  | 需手动    | Ubuntu 预装  |
| **学习曲线**   | 陡峭          | 中等        | 平缓      | 平缓         |
| **配置复杂度** | 高            | 中          | 极低      | 低           |
| **分屏灵活性** | ⭐⭐            | ⭐⭐⭐⭐        | ⭐⭐⭐⭐⭐     | ⭐⭐⭐          |
| **鼠标支持**   | ❌             | ✅（需配置） | ✅（原生） | ✅            |
| **插件生态**   | 弱            | 极丰富      | growing   | 无           |
| **远程协作**   | ❌             | ✅（tmate）  | ✅（内置） | ❌            |
| **资源占用**   | 极低          | 低          | 中        | 中           |

### 架构设计哲学对比

#### Tmux：Unix 哲学

```
"Do one thing and do it well"
• 专注会话管理，不替代 Shell
• 通过插件扩展（TPM 管理器）
• 高度可定制，配置即代码

典型用户：运维工程师、后端开发者
```

#### Zellij：现代产品思维

```
"Batteries included"
• 约定优于配置，开箱即用
• 内置布局系统、插件市场
• 视觉反馈优先，降低记忆负担

典型用户：全栈开发者、新手友好
```

#### Screen：兼容至上

```
"Run everywhere"
• 30 年向后兼容
• 嵌入式、路由器、老旧系统
• 功能精简但稳定

典型用户：嵌入式开发、遗留系统维护
```

------

## 五、核心机制详解

### 1. 会话持久化原理

```
# 传统进程信号处理
SIGHUP (Hangup) → 终端断开 → 默认终止进程

# 复用工具的防护机制
┌─────────────┐
│   用户进程   │ ◄── 运行在伪终端（PTY）上
│   (vim/top) │
└──────┬──────┘
       │
┌──────▼──────┐
│  Tmux Server │ ◄── 守护进程，忽略 SIGHUP
│  (daemon)   │     通过 Unix Socket 通信
└─────────────┘
       │
┌──────▼──────┐
│  Tmux Client │ ◄── 可随时 attach/detach
│  (终端连接)  │
└─────────────┘
```

### 2. 滚动缓冲区与复制模式

```
┌────────────────────────────┐
│  屏幕显示区域（可见部分）    │ ◄── 实时输出
│  $ ps aux                  │
│  USER  PID %CPU %MEM       │
│  ...                       │
├────────────────────────────┤
│  滚动缓冲区（历史记录）       │ ◄── 可回溯查看
│  [10000 行历史数据]         │
│  支持搜索、复制、导出        │
└────────────────────────────┘

操作示例：
Ctrl+b [        # 进入复制模式
↑/↓ 或 PgUp/PgDn  # 滚动
/ 或 ?          # 搜索（正向/反向）
Space           # 开始选择
Enter           # 复制到缓冲区
Ctrl+b ]        # 粘贴
```

### 3. 客户端-服务器分离架构

```
# 查看 Tmux 进程结构
$ ps aux | grep tmux
user    1234  ... tmux: server (/tmp/tmux-1000/default)
user    5678  ... tmux: client (/tmp/tmux-1000/default)

# 服务器持续运行，即使所有客户端断开
$ tmux ls
dev: 2 windows (created Wed Jan 10 09:00:00 2024)
ops: 1 windows (created Wed Jan 10 10:30:00 2024)

# 从另一台机器重新连接
$ ssh server
$ tmux attach -t dev  # 恢复原会话
```

------

## 六、选型决策树

```
开始选择终端复用工具
        │
        ▼
    是否老旧/嵌入式系统？
        │
    ┌───┴───┐
    是       否
    │        ▼
    ▼    是否追求开箱即用？
 GNU Screen   │
              │
          ┌───┴───┐
          是       否
          │        ▼
          ▼    是否需要丰富插件？
       Zellij     │
                  │
              ┌───┴───┐
              是       否
              │        ▼
              ▼    是否需要状态栏增强？
           Tmux + TPM  │
                      │
                  ┌───┴───┐
                  是       否
                  │        ▼
                  ▼      选择 Tmux
               Byobu    （标准配置）
```

------

## 七、现代演进趋势

### 1. 边界模糊化：终端内置复用

```
# WezTerm 内置多路复用
wezterm cli spawn --new-window
wezterm cli list --format=json

# Tabby 内置分屏 + SSH 管理
# Warp 基于云的会话同步
```

### 2. 云原生适配

| 场景       | 解决方案                      |
| ---------- | ----------------------------- |
| Kubernetes | `kubectl exec` + tmux sidecar |
| 容器开发   | Dev Containers + Zellij 布局  |
| 云端 IDE   | GitHub Codespaces 内置复用    |
| 无服务器   | 不适用（无持久化环境）        |

### 3. AI 集成方向

```
传统复用工具          下一代工具
    │                    │
    ▼                    ▼
┌─────────┐        ┌─────────────┐
│ 状态保持 │   +    │ AI 上下文感知 │
│ 分屏管理 │        │ 智能命令建议  │
│ 会话恢复 │        │ 自然语言操作  │
└─────────┘        │ 自动错误诊断  │
                   └─────────────┘
                   
示例：Warp 的 AI 命令搜索
"帮我找一个占用 CPU 高的进程"
→ 自动生成：ps aux --sort=-%cpu | head -n 5
```

------

## 八、最佳实践总结

### 黄金法则

1. **服务器必装**：所有远程服务器预装 tmux/screen
2. **命名规范**：`环境-项目-用途`（如 `prod-api-logs`）
3. **定期清理**：`tmux ls` 检查僵尸会话，避免资源泄漏
4. **配置同步**：dotfiles 管理配置文件，跨机器一致
5. **组合使用**：Mosh（网络层）+ Tmux（会话层）= 终极稳定

### 性能考量

```
资源占用对比（空闲状态）：
• Screen: ~1MB 内存
• Tmux:   ~5MB 内存  
• Zellij: ~15MB 内存（Rust 运行时）
• 每个窗格额外: +~2MB

现代服务器可忽略，嵌入式选 Screen。
```

------

## 结语

终端复用工具是**命令行工作流的基石基础设施**。从 1987 年的 Screen 到 2024 年的 AI 终端，其核心使命始终不变：**让计算会话超越物理连接的局限**。

掌握这一层工具，意味着从"操作终端"进阶到"编排计算环境"，是每位命令行用户的必修课。

终端复用原理到实践

## 一、故障症状速查表

| 现象                              | 可能层级  | 紧急程度   |
| --------------------------------- | --------- | ---------- |
| `nvidia-smi` 报错 / 无输出        | 驱动/内核 | 🔴 高       |
| GPU 温度 > 90°C / 降频            | 散热      | 🟡 中       |
| 显存不足 OOM                      | 应用/配置 | 🟡 中       |
| ECC 单比特错误 (SBE)              | 显存老化  | 🟡 中       |
| ECC 双比特错误 (DBE)              | 显存损坏  | 🔴 **极高** |
| 训练 loss 异常 / 结果不对         | 计算单元  | 🔴 高       |
| PCIe 报错 / 掉卡                  | 硬件连接  | 🔴 高       |
| 功耗不达标 / 电源告警             | 供电      | 🟡 中       |

------

## 二、分层排查流程图

```
┌─────────────────┐
│   现象观察      │
│  nvidia-smi /   │
│  应用报错 /     │
│  系统日志       │
└────────┬────────┘
         ▼
┌─────────────────┐     Y     ┌─────────────────┐
│ 驱动是否正常？   │ ─────────→│  驱动层排查      │
│ nvidia-smi 有输出│           │ 重装/降级/补丁   │
└────────┬────────┘           └─────────────────┘
         │ N
         ▼
┌─────────────────┐     Y     ┌─────────────────┐
│ 能否识别硬件？   │ ─────────→│  硬件层排查      │
│ lspci 有 NVIDIA │           │ 重插/换槽/换卡   │
└────────┬────────┘           └─────────────────┘
         │ N
         ▼
┌─────────────────┐     Y     ┌─────────────────┐
│ 温度/功耗异常？  │ ─────────→│  散热/供电排查   │
│                 │           │ 清灰/换硅脂/查电源│
└────────┬────────┘           └─────────────────┘
         │ N
         ▼
┌─────────────────┐     Y     ┌─────────────────┐
│ 显存/计算错误？  │ ─────────→│  ECC/计算单元排查│
│ ECC 报错 / loss 异常│        │ 隔离故障卡/报修  │
└────────┬────────┘           └─────────────────┘
         │ N
         ▼
┌─────────────────┐
│  软件/应用层    │
│  CUDA 版本 /    │
│  代码逻辑 /     │
│  集群调度       │
└─────────────────┘
```

------

## 三、逐层详细排查

### 第一层：驱动层（最常见）

#### 3.1.1 快速诊断

```
# 基础检查
nvidia-smi                    # 无输出 = 驱动问题
dmesg | grep -i nvidia        # 内核报错
cat /var/log/nvidia-installer.log  # 安装日志

# 驱动状态
modinfo nvidia                # 驱动模块信息
lsmod | grep nvidia           # 模块是否加载
cat /proc/driver/nvidia/version  # 驱动版本
```

#### 3.1.2 常见问题与修复

| 现象                                         | 根因             | 修复                       |
| -------------------------------------------- | ---------------- | -------------------------- |
| `nvidia-smi` 报 `Failed to initialize NVML`  | 驱动与内核不匹配 | 重装驱动或降级内核         |
| `modprobe: ERROR: could not insert 'nvidia'` | Secure Boot 阻止 | BIOS 关闭 Secure Boot      |
| 新内核启动后失效                             | DKMS 未自动编译  | `sudo dkms autoinstall`    |
| CUDA 版本不匹配                              | 多版本冲突       | `update-alternatives` 管理 |

#### 3.1.3 驱动重装（保留配置）

```
参考该篇文章
http://8.148.180.168:4000/post/87
```

------

### 第二层：硬件识别层

#### 3.2.1 PCIe 链路检查

```
# 查看 GPU 是否在总线上
lspci | grep -i nvidia
# 输出示例：0000:41:00.0 3D controller: NVIDIA Corporation GV100GL [Tesla V100 PCIe 32GB]

# 详细链路状态
sudo lspci -vv -s 0000:41:00.0 | grep -E "LnkCap|LnkSta"
# LnkCap: 链路能力（支持 PCIe 3.0 x16）
# LnkSta: 当前状态（实际协商速度）

# 关键：若 LnkSta 显示 x4 或 PCIe 1.0 = 插槽/线缆问题
```

#### 3.2.2 物理定位

```
# 获取槽位信息（用于带外定位）
sudo dmidecode -t slot | grep -B2 -A2 "Bus Address: 41"

# 或结合温度定位（跑压力测试后看 BMC 温度）
./gpu_burn 60 &
# 然后到 IPMI/BMC 查看各 PCIe 设备温度，最高即目标卡
```

#### 3.2.3 掉卡/链路降级处理

```
# 1. 软件层面重扫描（无需重启）
echo 1 | sudo tee /sys/bus/pci/rescan

# 2. 若无效，热卸载后重识别（内核 4.19+）
sudo nvidia-smi drain -p 0000:41:00.0 -m 1    # 卸载
echo 1 | sudo tee /sys/bus/pci/rescan          # 重扫
sudo nvidia-smi drain -p 0000:41:00.0 -m 0    # 重新启用

# 3. 仍无效 = 物理重插或换槽
```

------

### 第三层：散热与功耗层

#### 3.3.1 温度监控

```
# 实时温度
watch -n 1 nvidia-smi

# 详细温度与限制
nvidia-smi -q -d TEMPERATURE,PERFORMANCE,POWER
# 关键字段：
# - GPU Current Temp
# - GPU Shutdown Temp（硬限制，通常 100°C）
# - GPU Slowdown Temp（软限制，通常 85°C）
# - Clocks Throttle Reasons（若显示 "HW Slowdown" = 过热降频）
```

#### 3.3.2 压力测试验证散热

```
# 满载测试 5 分钟
./gpu_burn 300

# 观察：
# - 温度是否持续上升至 90°C+
# - 是否触发 [Clocks Throttle Reasons] "HW Slowdown"
# - 功耗是否达到 TDP（如 300W/300W）
```

#### 3.3.3 散热故障处理

| 现象                 | 处理                          |
| -------------------- | ----------------------------- |
| 温度高但风扇不转     | 检查风扇电源线 / 更换风扇模组 |
| 温度高但风速低       | BIOS 清灰 / 更换轴承老化风扇  |
| 温度高、风速高仍降频 | 更换硅脂 / 检查散热器接触     |
| 多卡温差 > 15°C      | 检查风道 / 调整卡间距         |

------

### 第四层：显存与计算层（ECC 错误）

#### 3.4.1 ECC 错误查询

```
# 查看 ECC 统计
nvidia-smi -q -d ECC
# 或
nvidia-smi ecc --error-correcting-code-config

# 关键字段：
# - Aggregate ECC Errors
#   - Single Bit: 可纠正，监控即可
#   - Double Bit: 不可纠正，立即更换
```

#### 3.4.2 显存压力测试

```
# 显存满载测试（触发潜在故障）
./gpu_burn 600 -m 100%  # 10 分钟满载

# 同时监控
watch -n 5 'nvidia-smi -q -d ECC,MEMORY | grep -A5 "ECC Errors"'
```

#### 3.4.3 ECC 错误处理流程

```
发现 SBE（单比特错误）
    │
    ├── 错误数 < 10/天 ──→ 监控，记录趋势
    │
    └── 错误数 > 10/天 或持续增长
            │
            ▼
    运行显存压力测试 30 分钟
            │
            ├── 测试期间无新增 ──→ 继续监控
            │
            └── 测试期间新增或出现 DBE
                    │
                    ▼
            标记故障卡 → 隔离任务 → 申请更换
```

#### 3.4.4 显存行重映射（Row Remapping）

```
# 查看重映射状态
nvidia-smi -q | grep -A10 "Row Remapper"

# 关键字段：
# - Remapping Failure: Yes = 显存物理损坏，必须换卡
# - Remapped Rows: 计数持续增长 = 老化预警
```

------

### 第五层：软件与应用层

#### 3.5.1 CUDA 与驱动兼容性

```
# 查看 CUDA 版本
nvcc --version
cat /usr/local/cuda/version.json 2>/dev/null || ls /usr/local/cuda*

# 兼容性矩阵（关键）
# CUDA 12.x 需要驱动 >= 525.60.13
# CUDA 11.8 需要驱动 >= 450.80.02

# 若应用报 CUDA error 35 / 999
# = 驱动/CUDA/应用版本三角不匹配
```

#### 3.5.2 应用级调试

```
# CUDA 内存检查
cuda-memcheck ./your_app

# Nsight 详细分析
nsys profile -t cuda,nvtx,osrt -o report.qdrep ./your_app
ncu --metrics sm__throughput.avg.pct_of_peak_sustained_elapsed ./your_app
```

------

## 四、故障定位速查命令集

```
# ========== 30 秒快速诊断 ==========
nvidia-smi                                    # 基础状态
nvidia-smi -q | grep -E "Serial|Product|Temp|Power|ECC|Remap"  # 关键信息
dmesg | tail -50 | grep -iE "nvidia|pcie|error|warn"           # 内核日志
lspci | grep -i nvidia                        # 硬件识别
sudo ipmitool sel list | grep -iE "gpu|pcie|temp|fan"          # 带外日志

# ========== 深度诊断 ==========
nvidia-smi -q -d ECC,TEMPERATURE,PERFORMANCE,POWER,CLOCK,PCIE  # 全维度
cat /proc/driver/nvidia/gpus/*/information                     # 每卡详情
sudo nvidia-bug-report.sh                                      # 官方诊断脚本

# ========== 压力验证 ==========
./gpu_burn 300 -m 100%                      # 核心+显存满载
./gpu_burn 600                              # 长时间稳定性
```

------

## 五、典型故障案例

### 案例 1：训练中途 loss 突变为 NaN

| 排查            | 结果                    |
| --------------- | ----------------------- |
| `nvidia-smi -q` | ECC SBE 计数 10万+      |
| 显存压力测试    | 10 分钟内新增 50 个 SBE |
| 根因            | 显存老化，偶发位翻转    |
| 处理            | 隔离该卡，更换后正常    |

### 案例 2：8 卡集群随机掉卡

| 排查        | 结果                                         |
| ----------- | -------------------------------------------- |
| `lspci -vv` | 掉线卡显示 `LnkSta: Speed 2.5GT/s, Width x4` |
| 正常卡      | `LnkSta: Speed 16GT/s, Width x16`            |
| 根因        | PCIe 延长线接触不良，协商降级                |
| 处理        | 重插线缆，固定卡扣，正常                     |

### 案例 3：新装机 nvidia-smi 无输出

| 排查         | 结果                                            |
| ------------ | ----------------------------------------------- |
| `dmesg`      | `NVRM: The NVIDIA probe routine was not called` |
| `secureboot` | BIOS 中 Enabled                                 |
| 根因         | Secure Boot 阻止未签名驱动                      |
| 处理         | BIOS 关闭 Secure Boot，正常                     |

------

## 六、预防性维护建议

| 周期 | 动作                    | 工具                         |
| ---- | ----------------------- | ---------------------------- |
| 每日 | 监控 ECC 错误趋势       | `nvidia-smi -q` + Prometheus |
| 每周 | 温度/功耗基线对比       | `nvidia-smi dmon`            |
| 每月 | 压力测试验证稳定性      | `gpu_burn 600`               |
| 每季 | 物理清灰，硅脂检查      | 目视 + 温度压测              |
| 每年 | 全卡 ECC 清零，趋势分析 | `nvidia-smi --ecc-reset`     |



常见GPU故障问题排查步骤

## 一、理解「瞬冲」与「稳态」

| 测试类型     | 代表工具                | 特点                                 | 适用场景               |
| ------------ | ----------------------- | ------------------------------------ | ---------------------- |
| **瞬冲极限** | FurMark、gpu-burn       | 人为解锁功耗墙，散热允许下的绝对极限 | 散热设计验证、出厂烤机 |
| **稳态负载** | 实际训练任务、stress-ng | 持续可预期的负载模式                 | 日常稳定性评估         |
| **随机轰炸** | stress-ng 混合模式      | CPU/内存/IO/中断同时扰动             | 系统级鲁棒性测试       |

**关键认知**：

- 压测工具的「瞬冲」是 **人为解锁 + 散热允许** 的极限场景
- 日常训练/推理 **不会触及** 这种极限（有自动降频、队列调度）
- 故障定位时，**先稳态复现，再瞬冲确认**

------

## 二、CPU 压力测试

### 2.1 基础满载测试

```
# 全核满载 5 分钟（自动选择最优算法）
stress-ng --cpu 0 --timeout 5m --times

# 指定 8 线程跑矩阵乘法 30 分钟（AVX/AVX-512 自动启用）
stress-ng --cpu 8 --cpu-method matrixprod --timeout 30m
```

### 2.2 温度与节流观察

```
# 全核满载 + 实时温度监控（10 分钟）
stress-ng --cpu 0 --matrix 0 --tz -t 600

# 90% 负载非满血（观察动态调频行为）
stress-ng --cpu 0 --cpu-load 90 --timeout 10m
```

**关键指标**：

- `tz` 列显示温度，超过 85°C 观察是否触发 `CPU MHz` 降频
- `bogo-ops/s` 突降 = 热节流发生

### 2.3 系统级随机轰炸

```
# CPU + IO + VM + 磁盘同时扰动（模拟混沌生产环境）
stress-ng --cpu 4 --io 4 --vm 2 --hdd 2 --timeout 5m --times
```

------

## 三、内存压力测试

### 3.1 基础压测

```
# 安装
sudo apt install stress-ng

# 4 个 worker 分配 4GB，占住不释放，20 分钟
stress-ng --vm 4 --vm-bytes 4G --vm-keep --timeout 20m

# 按总内存百分比施压（24GB 系统压 20% ≈ 4.8GB）
stress-ng --vm 0 --vm-bytes 20% --vm-keep --timeout 10m
```

### 3.2 ECC 错误检测（企业级关键）

```
# 压测同时开另一个终端监控
sudo dmesg -w | grep -iE 'edac|ecc|corrected|uncorrected|hardware error'

# 或通过 IPMI 查看系统事件日志
sudo ipmitool sel list | grep -iE 'memory|ecc|dimm'

# 查看 EDAC 驱动统计
cat /sys/devices/system/edac/mc/mc*/csrow*/ch*_ce_count   # 可纠正错误
cat /sys/devices/system/edac/mc/mc*/csrow*/ch*_ue_count   # 不可纠正错误
```

### 3.3 故障内存条定位流程

```
# 步骤 1：带外日志定位故障 DIMM 槽位
sudo dmidecode -t memory | grep -B5 -A5 "Locator:.*DIMM.*" | grep -E "Locator:|Size:|Type:|Speed:"

# 步骤 2：物理拔出后，单条压力测试验证
stress-ng --vm 4 --vm-bytes 80% --vm-method flip -t 5m --times

# 步骤 3：复测带外日志确认无新增 ECC
sudo ipmitool sel clear && stress-ng ... && sudo ipmitool sel list
```

**关键参数 --vm-method flip**：
对内存地址做位翻转（bit flip），专门触发潜在硬件缺陷。

------

## 四、磁盘与 I/O 压力测试

```
# 4 路并发随机写，每路 8GB，5 分钟
stress-ng --hdd 4 --hdd-bytes 8G --timeout 5m

# 同时压测 + IO 延迟监控
iostat -x 1 &
stress-ng --hdd 8 --hdd-bytes 10G --timeout 10m
kill %1
```

**观察指标**：

- `%util` 接近 100% 但 `await` < 10ms = 健康
- `%util` 100% 且 `await` > 50ms = 磁盘瓶颈或故障

------

## 五、GPU 压力测试（核心章节）

### 5.1 工具安装

```
# 官方源（国内可能慢）
git clone https://github.com/wilicc/gpu-burn.git

# 国内加速镜像
git clone https://ghfast.top/https://github.com/wilicc/gpu-burn.git

cd gpu-burn && make
```

### 5.2 基础压测

```
# 全卡满载 120 秒（显存 100% + 核心 100% + Tensor Core）
./gpu_burn 120 -m 100%

# 稳定 80% 负载 500 秒（模拟实际训练强度）
./gpu_burn 500

# 指定显卡（0 号和 3 号卡）
export CUDA_VISIBLE_DEVICES=0,3
./gpu_burn 100
```

### 5.3 与 FurMark 的对比

| 特性           | FurMark           | gpu-burn                  |
| -------------- | ----------------- | ------------------------- |
| 平台           | Windows/Linux GUI | Linux CLI                 |
| 负载类型       | 图形渲染          | CUDA GEMM 计算            |
| 覆盖单元       | 核心 + 显存       | 核心 + 显存 + Tensor Core |
| 自动化         | 难                | 易（脚本化）              |
| 数据中心适用性 | 低                | **高**                    |

### 5.4 温度与故障定位

```
# 实时观察（另开终端）
watch -n 1 nvidia-smi

# 关键指标
nvidia-smi -q -d TEMPERATURE,PERFORMANCE,POWER
```

**过热处理流程**：

```
# 1. 识别故障卡 PCI 槽位
lspci -vv -s 0000:41:00.0 | grep -i "physical slot"
# 或
sudo dmidecode -t slot

# 2. 获取 SN 码（报修用）
nvidia-smi -q | grep "Serial Number"

# 3. 若以上无效，跑压力测试 + 带外温度对比定位
./gpu_burn 60 &
# 然后到 BMC/IPMI 查看各 PCIe 设备温度，最高即目标卡
```

------

## 六、高级：GPU 热插拔与维护

### 6.1 软件层面卸载（内核 4.19+）

```
# 查看卡槽地址
nvidia-smi -q | grep "Bus Id"
# 输出：Bus Id : 0000:41:00.0

# 热卸载（需无进程占用）
sudo nvidia-smi drain -p 0000:41:00.0 -m 1

# 验证状态
nvidia-smi
# 显示：|   2  Tesla V100-PCIE...  Off  | 00000000:41:00.0 Off | **Drain**
```

### 6.2 重新启用

```
# 1. 解除 drain
sudo nvidia-smi drain -p 0000:41:00.0 -m 0

# 2. 重扫 PCIe 总线
echo 1 | sudo tee /sys/bus/pci/rescan

# 3. 验证
nvidia-smi
```

------

## 七、完整验收测试脚本

```
#!/bin/bash
# hardware_stress_test.sh - 出厂验收全流程

LOG="stress_$(date +%F_%H%M).log"
echo "=== 硬件压力测试开始 $(date) ===" | tee $LOG

# 1. CPU 10 分钟满载 + 温度
echo "[1/4] CPU 压力测试..." | tee -a $LOG
stress-ng --cpu 0 --matrix 0 --tz -t 600 --times 2>&1 | tee -a $LOG

# 2. 内存 20 分钟 + ECC 监控
echo "[2/4] 内存压力测试..." | tee -a $LOG
stress-ng --vm 0 --vm-bytes 80% --vm-method flip -t 20m --times 2>&1 | tee -a $LOG &
PID=$!
sleep 10
echo "ECC 错误统计：" | tee -a $LOG
cat /sys/devices/system/edac/mc/mc*/csrow*/ch*_ce_count 2>/dev/null | tee -a $LOG
wait $PID

# 3. 磁盘 5 分钟
echo "[3/4] 磁盘压力测试..." | tee -a $LOG
stress-ng --hdd 4 --hdd-bytes 8G -t 5m --times 2>&1 | tee -a $LOG

# 4. GPU 2 分钟满载
echo "[4/4] GPU 压力测试..." | tee -a $LOG
if [ -x ./gpu_burn ]; then
    timeout 130 ./gpu_burn 120 -m 100% 2>&1 | tee -a $LOG
else
    echo "gpu-burn 未安装，跳过" | tee -a $LOG
fi

echo "=== 测试完成 $(date) ===" | tee -a $LOG
echo "日志保存至: $LOG"
```

------

## 八、关键结论与建议

| 场景         | 推荐工具                                  | 时长      | 通过标准                      |
| ------------ | ----------------------------------------- | --------- | ----------------------------- |
| 出厂验收     | 上述完整脚本                              | 40 分钟   | 无 ECC 错误、无热节流、无掉卡 |
| 日常巡检     | `stress-ng --cpu 0 -t 60`                 | 1 分钟    | 温度 < 80°C                   |
| 故障内存定位 | `stress-ng --vm-method flip` + 单条测试   | 5 分钟/条 | 故障条复现 ECC，健康条无错    |
| GPU 散热验证 | `gpu_burn 300`                            | 5 分钟    | 温度 < 83°C 无降频            |
| 混沌测试     | `stress-ng --cpu 4 --io 4 --vm 2 --hdd 2` | 10 分钟   | 系统不崩溃、服务不中断        |

------

