🏢
§0 大模型部门组织总览
一个完整的工业级大模型研发部门，通常按照模型生命周期来划分团队。以字节跳动（豆包）、百度（文心一言）、阿里（通义千问）、DeepSeek 为典型参考：
🗺️ 六大职能组 & 核心职责一句话
| 职能组 | 核心职责 | 产出物 | 对应流水线阶段 |
|---|---|---|---|
| ① 预训练组 | 从 0 训练 Base Model | Llama/GPT 级别的基础模型权重 | 预训练 |
| ② 后训练对齐组 | 把 Base Model 变成 Chat Model | 对外发布的对话模型 | SFT + RLHF/DPO |
| ③ 推理效率组 | 让模型跑得快、成本低 | 服务系统、量化方案、优化内核 | Serving 层 |
| ④ 评估组 | 客观衡量模型能力 | 评测 Pipeline、排行榜 | 贯穿全程 |
| ⑤ 多模态组 | 扩展视觉/音频/视频输入输出 | 图文/视频理解&生成模型 | 预训练+后训练 |
| ⑥ 应用 Agent 组 | 模型能力→产品功能 | RAG系统、工具调用、Agent 框架 | 应用层 |
规模参考：字节豆包大模型团队据报道约 1500+ 人，百度文心约 1000+ 人，DeepSeek 仅约 200 人却做出了 R1。规模不决定效果，数据质量 + 算法创新 + 算力效率才是关键。
🔬
§1 预训练组（Pre-training）
1.1 在做什么——「把互联网喂给模型」
预训练组的任务是：在数万亿 token 的语料上，从随机初始化开始，把一个参数全是随机数的神经网络训练成一个"无所不知"的语言模型。
这是整个 LLM 研发中成本最高、周期最长、技术难度最大的环节。GPT-4 的预训练据估算花费超过 $1 亿美元。
📦 数据工程子团队
从全网爬取、清洗、去重、过滤语料。处理量级：每天数十 TB 新数据。
- CC（Common Crawl）清洗 pipeline
- 语言检测、质量过滤、PII（隐私信息）去除
- 数据配比实验：中文/英文/代码/数学的最优比例
- 合成数据生成（用强模型生成更多高质量数据）
🏗️ 模型结构子团队
研究和改进 Transformer 架构，在大规模训练前用小模型做 ablation。
- 注意力机制改进：MHA → MQA → GQA → MLA
- MoE（混合专家）架构 vs 稠密架构权衡
- 位置编码：RoPE、ALiBi、YaRN（长上下文）
- 激活函数：SwiGLU vs GELU 等细节调优
⚙️ 训练系统子团队
让几千张 GPU 稳定高效地协同工作，是极其复杂的分布式系统工程。
- 并行策略：数据并行 + 流水线并行 + 张量并行（3D 并行）
- 混合精度训练（BF16/FP8）
- 梯度检查点（节省显存）
- 故障恢复：某台机器挂了怎么从最近 checkpoint 恢复
📏 扩展规律子团队
研究 Scaling Laws，预测不同规模模型的最终性能，指导资源分配决策。
- Chinchilla Scaling：模型参数量与数据量的最优比例
- 根据算力预算预测最终 loss
- 小模型实验推断大模型行为
- 学习率调度策略（Cosine、WSD 等）
1.2 核心技术栈
框架层
PyTorch
JAX / XLA（Google TPU）
Megatron-LM（NVIDIA，大规模训练标配）
DeepSpeed（微软，ZeRO 内存优化）
NeMo
通信层
NCCL（NVIDIA GPU 集合通信）
InfiniBand（GPU 服务器间网络）
All-Reduce / Ring-AllReduce
MPI
算子层
FlashAttention（注意力计算加速，省显存 3–5x）
CUDA Kernel 定制
Triton（GPU 编程语言）
cuBLAS / cuDNN
数据处理
Spark / Flink（大规模数据处理）
MinHash LSH（大规模去重）
fasttext（语言检测）
SentencePiece / tiktoken（分词）
Arrow / Parquet（高效存储格式）
监控与基础设施
Prometheus + Grafana（GPU 利用率监控）
Weights & Biases / TensorBoard（实验追踪）
HDFS / S3（模型 checkpoint 存储）
Kubernetes（集群调度）
1.3 一个预训练工程师的典型一天
09:00
查看昨夜的训练 loss 曲线是否正常。发现 step 82000 处 loss 突刺——检查是不是那批数据有问题（如混入了 HTML 乱码），还是超参导致
10:00
数据配比会议：讨论加入 10% 更多代码数据对数学 benchmark 的影响，和数据团队对齐下周的数据配方
11:00
在 1B 小模型上跑 MoE vs 稠密架构的对比实验，写代码、提交任务、等结果
14:00
主训练任务挂了（3 台机器 OOM），拉 oncall 群紧急处理。查日志发现是某个 batch 里有超长序列。修 padding 策略，重启任务
15:30
Review 同事的 FlashAttention 优化 PR，讨论 causal mask 的实现细节
16:00
看最新的 scaling law 论文（如 DeepSeek 的技术报告），讨论能不能用在下一版训练配置上
17:00
写本周的实验进度文档，记录 ablation 结论（"3:1 的中英文比例比 5:1 的中英文 MMLU 高 0.8%"）
预训练组 KPI
- Perplexity / Loss：验证集上的语言模型 loss，越低越好
- Benchmark 分数：MMLU（知识）、HumanEval（代码）、GSM8K（数学）、C-Eval（中文）
- GPU 利用率（MFU）：Model FLOPs Utilization，衡量算力是否被高效使用（顶级团队能做到 50–60%）
- 训练稳定性：无 loss spike、无训练中断、checkpoint 完整
💡 举例：DeepSeek-V3 的预训练一些公开数据
- 训练数据：14.8 万亿 token（~15T tokens），含中英文/代码/数学
- 训练算力：2048 张 H800，约 2,788,000 H800 GPU·小时
- 花费：按 H800 市价约 550 万美元——相比同级别模型（GPT-4 估计 $1 亿+）低了约 20 倍
- 核心节省手段：MLA（减少 KV Cache）+ MoE（稀疏激活）+ FP8 混合精度训练
🎯
§2 后训练对齐组（Post-training / Alignment）
2.1 在做什么——「把原材料加工成可用产品」
后训练组接手预训练组产出的 Base Model，目标是把这个"只会续写文本"的基础模型，变成一个"有帮助、无害、诚实"的对话助手。对应流水线里的 SFT + 奖励模型训练 + RLHF/DPO/GRPO 阶段。
后训练组与预训练组的分工边界：
预训练组关心"loss 下降多少、benchmark 提多少分"，后训练组关心"用户用了是否满意、有没有说坏话、能不能完成复杂任务"。前者面向模型本身，后者面向用户体验。
📊 SFT 数据工程子方向
SFT 数据质量直接决定对话能力上限，比数量更重要。
- 数据源筛选：ShareGPT、OpenHermes、WizardLM 等开源数据集的清洗
- 合成数据：用强模型（GPT-4）生成难题，用弱模型过滤
- 拒绝采样（Rejection Sampling）：让当前模型生成 N 个答案，只保留通过奖励模型阈值的
- 数据飞轮：上线收集真实用户 query → 标注 → 加入训练 → 模型更强 → 循环
🏆 奖励模型（RM）子方向
奖励模型是整个 RLHF 的"分数引擎"，准确率直接影响对齐效果。
- 偏好数据收集：设计标注指南、管理标注员、校验一致性
- RM 架构：通常是同规模语言模型 + 线性打分头
- RM 评估：在留出集上测准确率，避免 RM 被 hack
- Process Reward Model（PRM）：逐步骤打分（用于数学推理），而不是只给最终结果打分
⚡ RL 训练子方向
跑 RLHF/DPO/GRPO 等对齐算法，是对计算资源要求第二高的环节。
- PPO 超参调优（β、ε、learning rate 的配合）
- DPO vs RLHF 的 trade-off 分析
- GRPO 用于代码/数学（规则奖励）
- Online DPO / Iterative DPO（在线不断迭代偏好数据）
- 评估 Win Rate（vs 上一版模型，vs 竞品 ChatGPT）
🛡️ 安全对齐（Safety / Red Team）
专门负责找模型的安全漏洞并修复，是大厂里不可缺少的方向。
- Red Teaming：人工或自动化尝试各种越狱 prompt，记录失败 case
- Constitutional AI：用宪法原则约束模型（Anthropic 方案）
- 拒绝率调控：太保守用户体验差，太宽松有安全风险，日常在做 trade-off
- 幻觉检测：识别模型编造的事实，构建 factuality benchmark
2.2 核心技术栈
对齐训练框架
TRL（Hugging Face，DPO/PPO/GRPO 标准库）
OpenRLHF（开源 RLHF 框架）
veRL（字节开源，分布式 RLHF）
LLaMA-Factory（快速 SFT 微调）
Axolotl
数据处理与标注
Argilla（标注平台）
Label Studio
自研数据飞轮系统
数据质量过滤（perplexity filter、IFD 打分）
评估工具
lm-evaluation-harness（EleutherAI 标准评测套件）
MT-Bench（多轮对话评测）
AlpacaEval（GPT-4 做 Judge）
FastChat / Arena（人类对战评测）
2.3 典型工作案例（有对话例子）
💡 案例 A：发现模型"过度拒绝"问题并修复
现象：用户问"帮我写一段关于侦探故事的凶杀场景描写"，模型回复"我无法帮您生成包含暴力内容的文字……"
后训练工程师的工作：
- 从线上日志捞出所有被拒绝的 query，人工标注哪些是合理拒绝、哪些是过度拒绝
- 发现拒绝率中，42% 属于过度拒绝（合理的创作类请求）
- 构建"正向样本"：标注员写出理想的"写侦探故事但不美化暴力"的回答
- 把这批数据加入 SFT，同时在奖励模型里加入"合理创作请求不应该被拒绝"的偏好数据
- 重跑 DPO，验证修复后拒绝率降低但安全问题没有增加
💡 案例 B：DeepSeek-R1 的 GRPO 数学对齐
目标：让模型在数学竞赛题上学会"先思考，再回答"的 CoT 推理
做法：
- 收集 MATH、GSM8K、AMC/AIME 等数学数据集（有答案的题目）
- 奖励函数直接用规则：答案格式正确 +0.1，答案数值正确 +1.0（不需要人工打分）
- 让模型对每题生成 8 个不同的解题过程（GRPO 的"组"），按正确率计算组内相对优势
- 跑 GRPO 几千步后，模型自发涌现出"hmm, 让我重新检查一下"的自我验证行为——没有人教它这么做
结果：AIME 2024 准确率从 15.6% 提升到 79.8%，媲美 OpenAI o1
后训练对齐组 KPI
- Win Rate：人类评估中，新版本 vs 旧版本的胜率（目标：持续为正）
- MT-Bench / AlpacaEval 分数：标准化的指令跟随能力评测
- 安全拒绝准确率：应拒绝的拒绝了多少，不该拒绝的拒绝了多少
- Hallucination Rate：在 TruthfulQA / FactScore 上的幻觉率
⚡
§3 推理效率组（Inference / Serving）
3.1 在做什么——「让用户 0.1 秒看到第一个字」
预训练和后训练解决"模型能力"问题，推理效率组解决"模型商业化"问题：如何用最低的成本、最短的延迟，服务几百万并发用户。
一个 70B 模型，朴素推理一次请求需要 4 张 A100 跑 3 秒。推理效率组的目标是让它变成 1 张 A100 跑 0.3 秒。
📊 推理效率的三个核心指标
TTFT
Time To First Token
用户发出请求到看到第一个字的时间，直接影响"响应感"
TPS
Tokens Per Second
每秒生成多少 token，决定"打字速度感"
Cost/1K
每千 Token 成本
直接决定产品能否盈利，GPT-4 从 $0.03 降到 $0.002 有 15x 优化
关键技术方向 1：KV Cache 优化
LLM 自回归生成时，每个新 token 都需要访问之前所有 token 的 Key/Value，这叫 KV Cache。随着序列变长，KV Cache 会占满显存。
PagedAttention（vLLM，把 KV Cache 像分页内存一样管理，GPU 利用率 +50%）
MLA（DeepSeek-V3，把 KV Cache 压缩到原来的 1/11）
GQA（Grouped Query Attention，多个 Query 共享 KV，减少 Cache 量）
Prefix Caching（系统 prompt 的 KV Cache 复用）
关键技术方向 2：量化（Quantization）
把模型权重从 FP32/BF16 压缩成 INT8/INT4/FP8，精度损失极小但速度提升显著。
| 量化方式 | 精度损失 | 速度提升 | 代表工具 | 适用场景 |
|---|---|---|---|---|
| INT8 | 几乎无损（<0.5%） | 1.5–2x | bitsandbytes、GPTQ | 生产部署标配 |
| INT4（GPTQ/AWQ） | 小（1–2%） | 3–4x | AutoGPTQ、AutoAWQ | 消费级 GPU 部署 |
| FP8 | 几乎无损 | 1.5–1.8x | TensorRT-LLM、vLLM | H100/H800 生产首选 |
| GGUF（llama.cpp） | 中等 | CPU 可用 | llama.cpp | 边缘/本地部署 |
关键技术方向 3：投机解码（Speculative Decoding）
大模型每次生成一个 token，很慢。投机解码：用一个小模型先快速草稿生成 K 个 token，然后让大模型一次性验证——若草稿正确则接受（相当于大模型一次生成了 K 个 token）。
💡 举例：投机解码的实际效果
- 小模型（70M）草稿速度：2000 tokens/s
- 大模型（7B）逐步生成：60 tokens/s
- 小模型草稿 5 个 token，大模型一次验证接受 4.2 个（接受率 84%）
- 等效速度：大模型达到 ~200 tokens/s（提升 3.3x），同时输出质量与大模型完全一致
关键技术方向 4：调度系统（Continuous Batching）
传统 batch 推理等所有请求生成完才开始下一批，严重浪费 GPU。Continuous Batching 动态填充空位，新请求随到随加入当前 batch。
vLLM（PagedAttention + Continuous Batching，开源推理引擎标配）
TensorRT-LLM（NVIDIA，性能最强但复杂）
SGLang（RadixAttention，前缀复用效率更高）
TGI（Hugging Face Text Generation Inference）
关键技术方向 5：Prefill / Decode 分离
LLM 推理分两个阶段：Prefill（处理 prompt，计算密集）和 Decode（逐步生成，访存密集）。两者特性不同，放在同一台机器上互相干扰。分离部署：Prefill 用高算力 GPU，Decode 用高带宽 GPU。
3.2 核心技术栈汇总
vLLM
SGLang
TensorRT-LLM
FlashAttention-2/3
FlashInfer
CUDA / Triton（自定义算子）
INT4/INT8/FP8 量化工具链
Kubernetes + 自定义调度器
gRPC / HTTP/2（接口层）
Prometheus / Grafana（在线监控）
推理效率组 KPI
- TTFT（首 token 延迟）：P50/P99，用户感知最直接
- TPS（生成速度）：tokens/s/GPU，越高越好
- GPU 利用率：服务期间 GPU 实际工作时间占比
- 成本：每百万 token 的 GPU 费用（每季度降低 20–30% 是正常预期）
- SLO 达标率：TTFT < 500ms 的请求比例
工程师视角的真实感受：推理效率组是大模型部门里最接近传统系统工程的方向，需要深入理解 CUDA 编程、GPU 架构（SM 数量、内存带宽、FLOPS）、网络通信（RDMA、InfiniBand）。写一个高效的 CUDA Kernel 可能需要花几周时间，但成功后能让整个产品的成本下降 30%。
📏
§4 评估组（Evaluation）
评估组是大模型研发中经常被忽视但极其重要的一组。一句话概括：没有可靠的评估，就不知道模型有没有变好。
在做什么
🔬 Benchmark 维护
- 维护内部评测套件，防止 benchmark 污染（训练数据里混入了测试题）
- 持续添加新 benchmark（追踪学术界最新评测方向）
- 每次模型迭代都跑完整 benchmark suite，出报告
- 维护竞品对比面板（GPT-4o、Claude 3.5、Gemini 1.5 Pro 的横向对比）
👩⚖️ LLM-as-Judge
- 用 GPT-4 / 自家强模型作为"裁判"评分，代替人工逐条评估
- 解决开放式问题无法用规则评测的问题（如"写一篇文章"好不好？）
- MT-Bench 就是用 GPT-4 打 1–10 分，AlpacaEval 用 GPT-4 做 A/B 对比
- 校准 Judge 模型的偏见（位置偏见、长度偏见）
🤝 人工评估体系
- 设计标注指南（什么叫"好回答"），培训标注员
- 计算 Inter-Annotator Agreement（IAA）：标注员之间的一致性
- Side-by-side 评估：新旧版本对战，统计 Win/Tie/Lose
- 每次大版本发布前的人工评估报告
🔍 能力分析
- 细粒度能力拆解：代码/数学/中文/创作/多轮对话分别是什么水平
- 错误归因：benchmark 下降是训练数据问题、还是对齐导致的能力退化？
- 长尾分析：找出模型系统性不擅长的 case 类型，反馈给预训练/后训练
核心技术栈
lm-evaluation-harness（EleutherAI，标准化评测）
OpenCompass（上海 AI Lab，中文评测全面）
HELM（斯坦福，多维度评估）
Chatbot Arena / FastChat（人类偏好在线对战）
BigBench Hard（复杂推理）
自研评测 Pipeline（内部 benchmark + CI/CD 集成）
评估组的核心挑战：Benchmark 污染问题
如果训练数据里包含了 MMLU 的测试题（哪怕是网页上的讨论），模型会"背题"，benchmark 分数虚高。大厂评估组会专门做污染检测（n-gram 匹配训练数据），并定期发布新的动态 benchmark（题目随机生成，无法提前背诵）。
如果训练数据里包含了 MMLU 的测试题（哪怕是网页上的讨论），模型会"背题"，benchmark 分数虚高。大厂评估组会专门做污染检测（n-gram 匹配训练数据），并定期发布新的动态 benchmark（题目随机生成，无法提前背诵）。
🎨
§5 多模态组（Multimodal）
多模态组的目标是让 LLM 不只能处理文字，还能看图、听音频、理解视频，甚至生成图像/视频。快手有可灵（视频生成），字节有即梦（图片生成），这些都属于多模态方向。
主要子方向
🖼️ 图文理解（MLLM）
把图像编码器（ViT）的特征接入 LLM，让模型能回答关于图片的问题。
- 视觉编码器：CLIP、SigLIP、EVA-CLIP
- 特征对齐：MLP Projector / Q-Former / 视觉 Token 压缩
- 代表模型：LLaVA、InternVL、Qwen-VL、GPT-4V
🎥 视频理解
处理视频比图片难得多——一个 1 分钟视频有 1800 帧，全部处理 context 爆炸。
- 帧采样策略（均匀采样 vs 关键帧提取）
- 时序建模（每帧特征如何聚合）
- 长视频处理（Memory、Streaming 方案）
🎬 视频/图像生成
把文本描述转化为图片或视频，是快手可灵的核心。
- Diffusion Model：U-Net / DiT（Diffusion Transformer）
- VAE（变分自编码器，压缩视频到隐空间）
- Flow Matching（Stable Diffusion 3 / FLUX 方案）
- 视频一致性：帧间时序连贯性建模
核心技术栈
ViT（Vision Transformer，图像编码器）
CLIP / SigLIP（图文对齐预训练）
Diffusion Models（DDPM / DDIM / Flow Matching）
DiT（Diffusion Transformer，Sora 用的架构）
VAE（视频/图像压缩到隐空间）
xFormers / Flash Attention（多模态训练加速）
💡 举例：快手可灵的技术架构（公开信息）
- 生成框架：基于 Diffusion Transformer（DiT）架构，在时序维度建模帧间依赖
- 训练数据：快手平台海量短视频（天然的大规模视频数据）
- 核心难题：物理一致性（人走路姿势要自然）、长镜头连贯性、文本和视觉精准对齐
- 工程挑战：生成一个 5 秒 720P 视频需要数分钟，怎么优化到秒级是推理效率组和多模态组共同攻克的问题
🤖
§6 应用 Agent 组（Application / Agent）
应用 Agent 组是离用户最近的团队，他们的工作是把模型能力变成用户真正用得到的功能。技术含量不如预训练高，但需要对产品有深刻理解，且需要快速迭代。
主要方向
🔍 RAG（检索增强生成）
让模型能访问最新信息或企业私有知识库，解决"知识截止日期"和"幻觉"问题。
- Embedding 模型：把文档变成向量（BGE、E5、text-embedding-ada）
- 向量数据库：Milvus、Chroma、Weaviate、Qdrant（快速检索相似文档）
- Reranker：检索回来的文档再用交叉编码器精排（BGE-Reranker）
- Chunk 策略：如何切割长文档（固定长度/语义切割/文档结构感知）
- HyDE：先让模型生成假设性答案，再用答案检索（更准确）
🛠️ Function Calling / Tool Use
让模型能调用外部 API、执行代码、操作文件系统，从"会说"到"会做"。
- 工具定义协议：JSON Schema 定义工具参数格式（OpenAI Function Calling 标准）
- CoT + Tool：模型先推理该调哪个工具，再生成调用参数
- Code Interpreter：模型写代码 → 沙箱执行 → 把结果喂回模型
- 错误处理：工具调用失败时模型能自动 retry 或换方案
🧠 长期记忆 / 多轮对话
- 对话历史压缩：超出 context 长度时如何保留关键信息
- 用户画像持久化（跨会话记住用户偏好）
- 记忆召回：当前问题相关的历史记忆精准检索
🕸️ Multi-Agent 系统
- Planner Agent 拆解任务，多个 Worker Agent 并行执行
- Agent 间通信协议（ReAct、AutoGen、LangGraph）
- 任务状态管理、失败回滚
- 代表框架：LangChain、AutoGen、CrewAI、Dify
核心技术栈
LangChain / LlamaIndex（RAG 框架）
Milvus / Qdrant（向量数据库）
OpenAI Function Calling / MCP 协议
AutoGen / CrewAI（Multi-Agent 框架）
Sandbox（代码安全执行）
Prompt Engineering / System Prompt 设计
和推荐系统的联系：快手推荐团队也在探索 Agent 方向——比如用 LLM Agent 自动分析用户行为日志、生成特征工程方案，或者用 Multi-Agent 做 A/B 实验的自动分析。这是推荐和大模型融合的具体落地方向之一。
🗺️
§7 总结：各组关系 & 与推荐系统的融合趋势
各组职责一张表总结
| 职能组 | 输入 | 输出 | 核心技术 | 典型难题 |
|---|---|---|---|---|
| 预训练组 | 数万亿 token 的原始文本 | Base Model 权重 | Megatron/DeepSpeed 分布式、FlashAttention、数据清洗 | 训练稳定性、GPU 利用率、数据配比 |
| 后训练对齐组 | Base Model + 人类标注偏好数据 | Chat Model / Instruct Model | SFT、RLHF/DPO/GRPO、奖励模型 | 过度拒绝 vs 安全风险、幻觉、数据飞轮 |
| 推理效率组 | 对齐后的模型 | 高性能服务系统 | vLLM/SGLang、量化、投机解码、KV Cache 优化 | TTFT/TPS/成本的 3-way trade-off |
| 评估组 | 任意模型版本 | 能力评估报告 | Benchmark 套件、LLM-as-Judge、人工评估体系 | benchmark 污染、judge 偏见、动态评测维护 |
| 多模态组 | 图/文/视频数据 + LLM 底座 | 图文/视频理解&生成模型 | ViT/CLIP、Diffusion/DiT、多模态对齐预训练 | 时序一致性、超长视频处理、生成成本 |
| 应用 Agent 组 | 部署好的模型 API | 面向用户的产品功能 | RAG、Function Calling、Multi-Agent 框架 | 幻觉控制、工具调用可靠性、长期记忆 |
LLM × 推荐系统的融合趋势
你在快手做推荐侧模型，和大模型部门的交叉点正在快速扩大：
📐 Semantic ID（本博客已有笔记）
用 LLM 为商品/视频生成语义 Token，替代推荐系统里的随机哈希 ID。
TRM、SemID 论文都在做这件事，两个部门的技术开始直接融合。
🤖 LLM 做特征工程
用 LLM 自动分析用户行为日志，生成高质量的文本特征（用户画像摘要、商品描述 embedding），补充传统 ID 特征的语义信息。
🎯 生成式推荐
从"给 item 打分选 Top-K"转变为"直接生成推荐列表"。TIGER、COBRA、OneRec 等论文都在探索这个方向。快手的 OneRec 就是这个方向的工业落地。
大模型部门和推荐系统团队的边界正在模糊。未来的推荐算法工程师，需要同时理解传统精排模型（CTR 预估、特征工程）和 LLM 技术栈（Transformer 架构、RLHF 对齐、语义表征），这正是你现在阅读这些笔记的价值所在。