大模型相关知识学习整理

分割线

大模型基础

主流架构的对比

特性Dense (稠密模型)MoE (专家混合)SSM / Hybrid (状态空间/混合)
代表模型Llama 3, GPT-3, QwenMixtral 8x7B, DeepSeek V3Mamba, Jamba, RWKV
核心原理所有参数参与计算路由器分配部分专家计算维护固定状态，线性序列处理
计算效率较低 (全量激活)极高 (按需激活)极高 (推理延迟低)
显存压力随上下文增加极大 (需加载全部权重)极低 (无 KV Cache 压力)
长文本支持受限于显存受限于显存天生支持超长序列
主要优势结构稳定、生态成熟兼顾大参数量与低推理成本长文本利器、推理极快
感性比喻一个人干所有的活专家委员会，按需点将边干活边记笔记的高效管家

模型参数规模的演进逻辑

模型参数规模的序列（0.5B / 7B / 14B / 27B / 70B）并不是随意拍定的，它背后交织了显存物理限制、Scaling Laws（缩放定律）和并行效率的考量。

显存的"物理天花板"

模型在推理或微调时必须完整加载到显存中。主流消费级显卡的显存通常是 8GB, 12GB, 16GB, 24GB, 40GB, 80GB。

尺寸FP16 显存占用INT4 显存占用对应显卡
7B - 8B~14 GB~5 GB消费级显卡（RTX 3060 12GB / 4060Ti 16GB）
27B - 32B~54 GB~18 GB单卡 A100/H100 (80GB) 或双卡 3090/4090 量化

Scaling Laws 的倍数效应

OpenAI 和 DeepMind 的研究表明，模型性能与参数量、数据量、计算量呈幂律关系。

  • 性能跨度：参数量增加 2 到 3 倍，能力才有质的飞跃
  • 训练成本：参数翻倍，训练算力（FLOPs）在数据等比例增加时翻 4 倍

尺寸等级与战场

尺寸等级典型代表主要战场
0.5B - 1.5BQwen-1.5B, Gemma-2B手机终端、AI Agent 微型插件
7B - 9BLlama-3-8B, Mistral个人电脑、开发者实验、逻辑门槛模型
14B - 20BQwen-14B, InternLM企业级单机部署、性能与成本平衡
30B - 34BYi-34B, Gemma-27B复杂任务处理、极强的指令遵循能力
70B+Llama-3-70B云端 API、复杂推理、知识库核心

这些数字是硬件厂商与算法厂商之间的"极限拉扯"——在既定成本下能榨取的最高"智力密度"节点。

Transformer 分层结构

目前主流的 LLM（Llama 3、Gemma、Mistral）基本都采用 Decoder-Only 架构，可以拆解为三个主要部分：

A. 嵌入层 (Embedding Layer)

  • 组成：Token Embedding + Positional Embedding（位置编码）
  • 作用：将离散 Token ID 映射为高维连续向量，位置编码告诉模型词序（Llama 使用 RoPE 旋转位置编码）
  • 维度：通常等于隐藏层维度 dmodeld_{model}，如 4096

B. 骨干层 (Backbone / Transformer Blocks)

核心部分，通常由 32 到 80 个相同 Block 堆叠。每个 Block 包含：

  1. 自注意力层 (Self-Attention)

    • 作用：建立 Token 之间的联系（上下文逻辑）
    • 参数：Wq,Wk,WvW_q, W_k, W_v（投影矩阵）和 WoW_o（输出矩阵）

  2. 前馈网络层 (FFN / MLP)

    • 作用：知识存储库，大部分事实性知识存储在 FFN 中
    • 维度：通常进行扩展再收缩，如 4096 → 11008 → 4096（SwiGLU 结构）

C. 输出头 (LM Head)

  • 作用：将最后一层隐藏状态映射回词表大小，通过 Softmax 预测下一个词
  • 维度：[Hidden_Size,Vocab_Size][Hidden\_Size, Vocab\_Size]

各层参数规模参考（Llama-3-8B）

组件参数描述典型维度/数值作用总结
EmbeddingVocab×HiddenVocab \times Hidden128,256×4096128,256 \times 4096词义映射
Attention4×Hidden24 \times Hidden^2每层约 16M捕捉上下文关联
FFN3×Hidden×Intermediate3 \times Hidden \times Intermediate每层约 45M存储事实知识
Total LayersBlock 堆叠数32 层深度特征提取

蒸馏模型 Distilled

Distilled（蒸馏）指知识蒸馏（Knowledge Distillation）：让大模型（Teacher）教小模型（Student）模仿其推理方式。

工作原理

  1. 教师模型（大）输出详细概率分布（不仅知道正确答案，还知道各选项的相对合理性）
  2. 学生模型（小）模仿这个概率分布
  3. 学生学会教师的逻辑特征和推理模式

命名含义

如 DeepSeek-R1-Distill-Qwen-7B：

  • 架构：Qwen-7B（小模型）
  • 灵魂：使用 DeepSeek-R1 生成的推理数据蒸馏训练
  • 结果：7B 模型的推理能力远超普通 Qwen-7B

蒸馏 vs 量化

特性蒸馏 (Distilled)量化 (Quantization)
原理重新训练小模型模仿大模型把权重数字压缩（16-bit → 4-bit）
精度通常比同规模普通模型高比原模型略有下降
结构模型架构变了（70B → 7B）架构不变，数字变小
类比百科全书总结成精华手册高清书压成低清图片

部署建议：先蒸馏（提质减量），再量化（压缩体积）。3090/4090 优先选 Distilled 模型，再叠加 AWQ/GPTQ 量化。

分割线

预训练-pre_train

数据处理

TODO

训练方式对比

从零预训练、增量预训练和 LoRA 微调是三条完全不同的路线。

方案数据需求显存需求时间效果推荐度
从零预训练TB 级多卡 A100数月最强，但成本极高不现实
增量预训练GB 级单卡 16GB数天强，学习领域知识强烈推荐
LoRA 微调MB-GB 级单卡 8GB数小时适配任务风格快速实验

从零预训练

  • 不依赖任何预训练权重
  • 需要海量数据（TB 级文本）
  • 需要超级算力集群（多卡多机）
  • 训练时间：数周甚至数月
  • 成本：几十万到上百万美元
  • 硬件要求：通常需要 A100 80GB 集群

增量预训练 (Continued Pre-training)

介于从零预训练和微调之间的中间路线：

  1. 使用官方权重作为初始化（不是微调，是继续预训练）
  2. 用私有数据继续训练
  3. 让模型学习领域知识
  4. 16GB 显存完全够用

这是最有性价比的方案：保留预训练知识的同时注入领域数据。

分割线

后训练-post_train

拿到 safetensors 之后要做的事

微调-fine_tune

微调层级选择

在 PEFT（参数高效微调）普及的今天，微调的选择通常遵循以下策略：

层级微调对象效果适用场景代价
AttentionWq,WvW_q, W_v 矩阵加旁路改变任务风格、指令遵循能力通用任务/对话适配低（LoRA 经典方案）
FFN前馈网络权重学习新的硬知识深度领域适配（医学、冷门库）高（参数量是 Attention 两倍以上）
Embedding / LM Head词表嵌入层理解新 Token扩充词表（特殊符号、MIDI 编码）易导致预训练知识崩溃

核心选择：微调 Attention 层

  • 为什么：LoRA 最经典的做法是在 WqW_q 和 WvW_v 矩阵上加旁路
  • 效果：微调 Attention 层能最有效地改变模型的任务风格和指令遵循能力
  • 建议：通用任务/对话适配的首选，性价比最高

进阶选择：微调 FFN 层

  • 为什么：如果希望模型学习新的硬知识（特定医学文献、极其冷门的编程库），微调 FFN 更有效
  • 代价：FFN 参数量通常是 Attention 的两倍以上，显存消耗更高

特殊场景：微调 Embedding 或 LM Head

  • 场景：需要扩充词表（加入特殊符号 Token）时，必须微调 Embedding 和 LM Head
  • 风险：全量微调 Embedding 容易导致预训练知识崩溃，除非有极大规模数据集（百万级以上）

总结建议：通用任务用 LoRA 作用于 Attention 的 q,k,v,oq, k, v, o 矩阵；深度领域适配可尝试 FFN；扩充词表才动 Embedding。

LoRA

另一篇文章有提到: LoRA微调训练和量化

主流微调框架对比

框架核心特点适用场景开源协议
LLaMA-Factory零代码 Web UI，支持 100+ 模型，集成 SFT/DPO/PPO 等方法初学者、快速实验、原型验证Apache-2.0
Unsloth显存优化（降低 70%）、速度提升 2x，单卡 GPU 可用显存有限的环境、快速迭代研究Apache-2.0
Self-LLM (Datawhale)针对国内用户，支持全参数/LoRA 微调，教程完善Linux 环境下的入门学习与实践Apache-2.0
GaLore高效梯度存储与优化，适合大规模训练企业级集群、科研场景开源
AxolotlHugging Face 生态深度集成，支持多种训练策略熟悉 HF 的开发者，灵活定制开源
OpenChat专注于对话模型的高效微调聊天机器人、客服场景开源

选择建议

  • 入门/快速实验：推荐 LLaMA-Factory 或 Self-LLM，界面友好，文档完善
  • 显存有限/单卡 GPU：推荐 Unsloth，在 12GB–24GB 显存的消费级 GPU 上也能跑 LoRA
  • 企业/科研大规模训练：推荐 GaLore 或 Axolotl，更适合复杂场景和深度定制
  • 专注对话模型：推荐 OpenChat，针对聊天场景优化

注意事项：这些框架大多依赖 Hugging Face Transformers，需要关注版本匹配。LLaMA-Factory 和 Unsloth 社区增长快，Self-LLM 更适合国内用户。

量化-quantization

另一篇文章有提到: LoRA微调训练和量化

量化节省与精度对比

https://huggingface.co/mradermacher/Qwen3.5-2B-GPT-5.1-HighIQ-INSTRUCT-i1-GGUF
https://huggingface.co/Bedovyy/dasiwaWAN22I2V14B-GGUF/tree/main/HighNoise

有时候找模型会遇到不同精度的量化版本, 以 7B 模型为例, GGUF 量化

格式典型大小精度损失推理速度提升适用场景
FP16~14GB无损基准速度训练、基准推理
q8_0 (8bit)~7.5GB<0.5%~1.3×高精度服务器推理
q6_k (6bit)~6.7GB~0.5–1%~1.5×高精度推理，接近无损
q5_k_m (5bit混合)~4.5GB~1–3%~1.8×推荐的通用量化方案
q4_k_m (4bit混合)~4.4GB~3–5%~2.0–2.2×主流移动端/轻量服务器部署
q4_0 (原始4bit)~3.8GB~8–10%~2.5×基础推理，精度下降明显
q3_k_m (3bit混合)~3.0GB~5–8%~3×移动端极限压缩
q2_k (2bit)~2.7GB>10%~3.5×极端压缩，精度损失大

量化方法和产物

标记全称/含义特点适用场景
QQuantized（量化）表示该模型是量化版本，后缀决定具体策略（如 q4_0、q4_k_m）所有量化模型的通用前缀
KK-quant（分组量化）改进的量化方法，分组存储权重，精度更好主流推荐，如 q4_k_m、q5_k_m
MMixed（混合精度）不同部分使用不同 bit 数量，兼顾精度和体积常见于 q4_k_m、q5_k_m，平衡最佳
LL-quant（低秩优化）针对部分权重做低秩近似，进一步压缩更小体积，但精度略有下降
IQInteger Quantization（整数量化）使用整数存储，推理速度更快新方案，适合 CPU/GPU 高速推理
0原始量化版本最基础的量化实现，速度快，但精度损失较大早期量化方案，适合极限压缩或测试
SSuper-block 分组策略在量化时使用更大的分组（block size），提升精度常见于 q4_k_s，比 _0 精度更好
S#Super-block + 数字（如 S2, S3）表示不同的分组大小或策略，数字越大分组更细，精度更高高精度量化，适合需要更好质量的推理

GPU 量化格式选择

上述表格讲的是 GGUF 格式的量化标记，主要用于 llama.cpp / Ollama / LM Studio 等 CPU/本地推理生态。

但 vLLM 目前不直接支持 GGUF。如果你的目标是 GPU 高并发推理，需要选择专为 GPU 加速优化的量化格式。

vLLM 支持的量化格式

格式位宽特点搜索关键词推荐度
AWQ4-bit保护"显著权重"，精度极高；vLLM 有专门内核优化模型名 + AWQ首选推荐
GPTQ4-bit最老牌、最常见的 GPU 量化格式，资源极多模型名 + GPTQ备选
FP88-bit几乎没有精度损失，利用新显卡硬件特性模型名 + FP8新款显卡必备

FP8 前提：需 NVIDIA H100、4090 或更高级别显卡（Ada Lovelace 架构及以后）。

格式与推理引擎的匹配

需求场景推荐格式推荐推理引擎
高并发、多用户、纯 GPU 推理AWQ / GPTQ / FP8vLLM
个人本地测试、显存不足 (CPU 补位)GGUFOllama / llama.cpp
追求极致吞吐量 (NVIDIA 显卡)FP8 / AWQvLLM / TensorRT-LLM

小贴士：Hugging Face 上找不到 AWQ 版本时，可查找 neuralmagic 发布的量化版本，提供了大量针对 vLLM 优化的 FP8 和 AWQ 模型。

模型发布-huggingface

一般是发到 Huggingface, 部分国内模型会发到魔搭

仓库名称示例核心存储内容角色定位适用场景/工具
*-LoRAadapter_model.safetensors (几十MB)中间产物 (轻量级)二次微调、PEFT 动态加载、研究员交流
*-Fullmodel.safetensors (几个GB)标准产物 (工业级)服务器部署 (vLLM)、Transformers 库加载
*-GGUF*.gguf (不同位宽)分发产物 (消费级)本地离线运行 (Ollama, llama.cpp, LM Studio)

为了让 Hugging Face 自动识别模型之间的血缘关系（如你图中看到的 Tree 结构），你需要在每个仓库的 README.md 顶部配置 base_model 标签。

  1. LoRA 仓库 (*-LoRA)

    声明它是基于哪个原始大模型微调的。

    ---
    base_model: Qwen/Qwen3.5-4B
    library_name: peft
    tags:
      - lora
      - latex
    ---

  2. 完整版仓库 (*-Full)

    它是合并后的模型，通常依然指向原始基座模型。

    ---
    base_model: Qwen/Qwen3.5-4B
    tags:
      - merged
      - latex
    ---

  3. 量化版仓库 (*-GGUF)

    关键点：它的基座应该是你微调合并后的那个仓库。

    ---
    base_model: Weidows/Qwen3.5-4B-LaTeX
    tags:
      - gguf
      - quantization
    ---

模型文件格式

拿到模型权重后，常见的文件格式有三种。需要澄清一个常见误区：.ckpt 和 .pth 在技术上没有本质区别，都是 PyTorch torch.save() 序列化的 pickle 文件，区别只在命名约定和保存内容。

PyTorch 原生格式（.ckpt / .pth）

维度保存完整训练状态仅保存模型权重
常见命名.ckpt.pth
保存内容model + optimizer + epoch + schedulermodel.state_dict()
用途断点续训、恢复训练推理部署、模型分发
文件大小较大（约为权重的 2 倍以上）与权重相当
加载方式torch.load() 后按需提取model.load_state_dict()
# 保存完整训练状态（通常命名为 .ckpt）
torch.save({
    'epoch': epoch,
    'model_state_dict': model.state_dict(),
    'optimizer_state_dict': optimizer.state_dict(),
}, 'model.ckpt')

# 仅保存模型权重（通常命名为 .pth）
torch.save(model.state_dict(), 'model.pth')

# 加载完整状态继续训练
checkpoint = torch.load('model.ckpt')
model.load_state_dict(checkpoint['model_state_dict'])
optimizer.load_state_dict(checkpoint['optimizer_state_dict'])

安全提示：.ckpt / .pth 基于 Python pickle，加载时会执行序列化对象中的代码。从不可信来源下载的权重文件存在代码注入风险。

Safetensors

Hugging Face 推出的安全权重格式，设计上替代 pickle：

特性说明
安全性不执行代码，只存储张量数据，杜绝 pickle 反序列化漏洞
加载速度支持零拷贝（memory-map），大模型加载更快
跨平台格式规范统一，不受 PyTorch 版本差异影响
分片支持单文件 > 2GB 时可自动分片（model-00001-of-00002.safetensors）
兼容性HF 生态原生支持，PyTorch 需安装 safetensors 库
from safetensors.torch import save_file, load_file

# 保存
save_file(model.state_dict(), 'model.safetensors')

# 加载
state_dict = load_file('model.safetensors')
model.load_state_dict(state_dict)

格式选择建议

场景推荐格式原因
训练阶段/断点续训.ckpt需要同时保存优化器状态和 epoch
推理部署/模型分发.safetensors安全、加载快、HF 生态标准
遗留项目/内部使用.pth兼容旧代码，结构简单
多卡大模型存储.safetensors自动分片，避免单文件过大

Hugging Face 已全面转向 safetensors，新发布的模型几乎都以该格式为主。如果你从 HF 下载模型，默认拿到的就是 .safetensors 文件。

分割线

推理部署-inference

推理框架选择

https://github.com/Mega4alik/ollm

速度太慢了, 大部分场景都不适合

https://github.com/GeeeekExplorer/nano-vllm

看起来更新速度不太快, 支持不行, pass

https://docs.vllm.ai/en/stable/

推理加速

核心思路：在资源受限的机器上，推理加速通常是 “减小模型规模”（量化/剪枝/蒸馏）与 “高效执行”（选择合适的框架/内核） 的结合。

主流推理框架对比

框架 / 方法适用场景核心优势推荐配置参数备注
vLLMLLM 大语言模型服务（如 ChatGPT）PagedAttention：通过分页管理 KV Cache，解决显存碎片化问题；支持 Speculative Decoding（推测解码）。在长上下文场景下（如 30K token）表现优越。--max-num-batched-token (控制批处理大小)，--kv-cache-dtype (设置 KV 缓存类型)[[1]][[2]]在小显存机器上，优于 HuggingFace Transformers 2-4 倍吞吐量[[3]][[4]]
OpenVINOIntel CPU / GPU / NPU (如 Xeon, Arc)深度优化：针对 Intel 硬件的异构执行、自动 batch、性能 Hint (Latency/Throughput)。ov::hint::performance_mode(ov::hint::PerformanceMode::THROUGHPUT)对于 CPU 推理（如 ResNet, BERT），往往优于 pure PyTorch/TensorRT[[5]]
TensorRTNVIDIA GPU (A100, H100, RTX)极致加速：张量核心 + FP8/INT8 加速；支持混合精度。--precision (FP8/INT8) [[6]]对于视觉模型 (YOLO, Stable Diffusion) 常见首选[[7]][[8]]
ONNX Runtime跨平台部署 (CPU, GPU, NPU, Edge)通用性：支持 CUDA、DirectML、OpenVINO EP。ExecutionProvider 选择 (如 CUDAExecutionProvider)[[9]]适合 Edge 设备（如 Jetson, Graviton）[[10]]

核心加速技术手段

技术加速原理典型收益适用场景参考
PagedAttention类似 OS 虚拟内存分页，按需分配 KV Cache，减少显存碎片。显存利用率近 100%，解决长上下文卡死问题[[17]]超长上下文 LLM (30K token 以上)vLLM 独有技术[[18]]
Speculative Decoding预先生成多个候选 token，提前并行计算，减少解码串行瓶颈。吞吐量提升 2-4x需要高 QPS 的聊天机器人vLLM 中实现[[19]]
自动 Batch动态聚合多个推理请求，提高 GPU 利用率。吞吐量提升 1.5x-3x低频请求的 API 服务OpenVINO & vLLM 支持[[20]]

MLX (Apple Silicon)

MLX 是 Apple Silicon (M1/M2/M3/M4) 专属的机器学习框架，由苹果 AI 研究团队开发。

核心优势：统一内存架构 (Unified Memory)

  • 在 NVIDIA 显卡上：内存 (RAM) 和显存 (VRAM) 物理分离，模型必须能塞进显存
  • 在 Mac (MLX) 上：CPU 和 GPU 共享同一块内存
    • 一台 128GB 内存的 Mac Studio，MLX 可以直接调用绝大部分来跑模型
    • 这意味着 Mac 可以跑动 3090/4090 完全跑不起来的超大模型（如 Llama-3-70B 或 Qwen-72B）

主要特点

  • 原生性能：专为苹果芯片的 GPU、CPU 和 Neural Engine 优化，速度远超传统 PyTorch
  • 类 PyTorch 设计：API 接近 PyTorch，模型转换成本低
  • 延迟评估 (Lazy Evaluation)：只有真正需要结果时才执行计算，优化显存和算力分配
  • 量化支持：AWQ、4-bit、8-bit 等技术都有对应优化实现

适用场景

场景说明
超大模型尝鲜3090 跑不动的 72B 甚至 400B 模型，大内存 Mac 可用 MLX 慢速跑起来
本地开发利用 Mac 低功耗特性进行模型微调或推理测试
高效推理风扇几乎不转就能处理复杂 AI 任务，适合作为本地 AI 助手

3090 (CUDA) vs. Mac (MLX)

维度NVIDIA RTX 3090Apple Silicon + MLX
生态系统CUDA（最成熟，工业标准）MLX（苹果专属，高性能）
内存限制固定的 24GB（硬伤）动态共享（最高可达 192GB+）
推理速度极快（算力密度高）较快（受限于内存带宽）
适用人群追求速度、专业开发者追求大模型容量、Mac 办公用户

一句话：CUDA 是 AI 界的"通用标准"，MLX 是苹果为自家芯片量身定制的"专业跑车引擎"。如果你主力用 3090，MLX 对你没有直接作用；但如果你有 M 系列 Mac，它是跑超大模型的唯一选择。

常见误区

  1. ”多加一个 GPU 就能跑大模型”：在显存碎片严重时，即使是 2 块卡也可能卡死，PagedAttention 是关键
  2. ”只要量化就行”：直接 INT8 量化有时会导致 LLM 输出乱码，建议先使用 W4A4 (GPTQ) 或者 INT8 + W8A8 (vLLM)

分割线

KV Cache 显存估算

KV Cache 是 LLM 推理时显存占用的核心大头之一，尤其在长上下文场景下很容易成为瓶颈。这里记录一个快速估算公式。

来源: 【硬核科普】KV Cache 到底占了多大显存？

KV Cache 公式

对于量化后的模型（KV Cache 通常为 8-bit，即每个元素占 1 字节），显存占用近似为：

KV Cache (GB)≈2×Layers×Heads×Head Dim×Context Length109KV\ Cache\ (GB) \approx \frac{2 \times Layers \times Heads \times Head\ Dim \times Context\ Length}{10^9}

各项含义：

项含义
2K (Key) 和 V (Value) 两个向量
LayersTransformer 层数
Heads注意力头数量（GQA 架构下为 KV Heads 数）
Head Dim每个头的维度
Context Length上下文 Token 数
10910^9字节转 GB

Qwen3.5 27B 示例：

上下文长度计算过程KV Cache 占用
256k2 x 64 x 4 x 256 x 262144 / 10^9~34.3 GB
8k2 x 64 x 4 x 256 x 8192 / 10^9~1.07 GB

长上下文对显存的压力是指数级的。如果想在 256k 长度跑满，仅 KV Cache 就要吃掉约 34 GB，这还没算模型权重本身。

未量化的情况：如果 KV Cache 用 FP16（每个元素 2 字节），分子需要再乘 2，上述数字直接翻倍。

分割线

多模态模型

CLIP

CLIP（Contrastive Language-Image Pre-training）是 OpenAI 提出的多模态模型，核心思想是同时编码图像和文本，让它们在同一个向量空间中对齐，通过对比学习训练。

基本能力：

输入一张图 + 若干文本描述，CLIP 会计算图文匹配度，找出最相关的描述。例如给一张猫图和三个文本 “a cat” / “a dog” / “a car”，CLIP 会返回 “a cat” 最匹配。

工程应用场景：

场景说明
文本驱动检索用文本搜图，适用于数据集筛选
零样本分类不训练分类器，直接用 prompt 做分类
统一 Embedding 空间做多模态 RAG（图像 + 文本混合检索）
数据清洗过滤不符合描述的脏数据

医疗场景注意事项：

CLIP 是用互联网通用数据训练的，对医学语义（如超声图像）理解较弱，容易产生语义偏移（semantic drift）。

建议的使用路线：

  1. 用 CLIP 做粗筛
  2. 再用领域模型（如自己微调的 LoRA）做精筛
  3. 或者直接训练 Medical CLIP 微调版本

CLIP 只能作为前置过滤层，不能替代领域模型的判断。

分割线

借物表

[1]: LLM

[2]: 【硬核科普】KV Cache 到底占了多大显存？

[3]: 主流开源 LLM 微调框架对比 - 知乎专栏

[4]: Self-LLM 项目 - Datawhale