先把话说死：这篇文章不是「跟着命令就能训出 ChatGPT」的教程，也不是某家云厂商的产品手册。
自研大模型，和调一个现成 API，差的不是「会不会写 prompt」，而是你能不能把数据、模型、训练、评测、上线这条链自己走通。链路上每一环都有技术门槛，也对应不同的语言和工具。下面按能力地图摊开讲，每节顺带说清楚：这一步主要用什么技术栈，哪些可以后补。
我自己这阵子也在本机用一张消费级显卡，试着把一条大约 0.3B 参数的小模型预训练链路打通——数据、配置、续训、冒烟都在做。文里会用到这类「先小后大」的思路当例子，但不会假装谁已经训完、已经对齐、已经能对标商业模型。大模型这条路，诚实比口号重要。
若你是从业务开发转过来的：别被「大」字吓住。真正难的往往不是某一行公式，而是把脏活累活做成可重复的工程习惯。
开篇：先认清三件事
第一，目标要写在纸上。 你是要做一个能聊天的通用模型，还是垂直领域（代码、客服、医学文献）？参数量级打算到哪——千万、几亿、还是几十亿？算力是本机一张卡，还是租云、还是有机房？钱和时间各能烧多久？这些不写清楚，后面很容易沦为「跟着论文抄配置」。
第二，自研 ≠ 从零发明 Transformer。 绝大多数团队会站在开源架构和开源数据上起步。自研指的是：数据怎么选、怎么洗，训练怎么稳，评测怎么不自欺，推理怎么控成本——这些决策和工程是你的。
第三，语言不是信仰战争。 训练主链几乎是 Python + PyTorch；要抠性能再碰 CUDA / C++；要上线再补服务端和前端。Java 很适合传统业务后台，但撑不起今天这条开源训练主链。后面每一节都会点到对应技术栈。
一、问题定义与路线
把「做大模型」拆成可验收的里程碑，比一上来堆参数有用。
常见路线是：先用小模型把链路跑通（数据进得去、loss 掉得动、checkpoint 存得住、能续训），再扩数据、扩参数、换多卡。这和盖房子先打通水电再精装是一个道理——水电不通，装潢没意义。
技术栈这一步很轻：Markdown 写需求与实验日志，表格记超参和每次改动。不必上复杂项目管理，但必须可回看——三个月后你一定想不起「那次 loss 暴涨是因为改了学习率还是换了数据」。
一个可执行的小里程碑长这样：① 选定公开语料子集并做校验；② 词表与许可证过目；③ 单卡冒烟（能跑完几十步、loss 不是 NaN）；④ 正式开训并能从 checkpoint 续上；⑤ 用固定探针集看一眼有没有「在变好」。五步都勾上，才叫链路通，而不是「脚本能启动」。
二、数据与语料
模型吃进去的是 token，吐出来的质量很大程度上取决于你喂了什么。
要会的事大致是：采集（公开 dump、授权数据、自有业务文本）、清洗（去 HTML、乱码、重复）、去重（近重复比完全重复更难）、许可审查（能不能用于训练、能不能开源权重）、以及提前留出评测集——别把考题混进复习资料里。
可以把它想成开餐馆：菜单（任务）定了，食材进货单、保鲜、溯源、留样送检，缺一不可。没有许可的「免费语料」踩雷成本极高，权重一旦训进去，很难事后洗干净。
# 伪代码：按行读语料，做极简质检（真实管道会更长）
def keep(sample: dict) -> bool:
text = sample.get("text", "").strip()
if len(text) < 80: # 太短
return False
if "�" in text: # 解码失败残留
return False
return True
技术栈： Python 做清洗与 ETL；体量大时用 SQL / 数仓做统计与抽样；对象存储放原始包与版本。Shell 负责批量下载与校验（比如 SHA256）。这一环几乎用不到 CUDA。
再补一句工程习惯：原始 dump、清洗后的 jsonl、抽样统计表，分目录、带日期、带哈希。哪天有人问「这版权重到底吃过哪些数据」，你能指到具体文件，而不是靠回忆。
三、Tokenizer：给文字做「字典切词」
Tokenizer 负责把字符串切成模型认识的 token ID。可以把它理解成一本会自动切词的字典：英文常按子词切，中文和代码又有各自的坑。词表太小，长文本被切得又碎又贵；太大，Embedding 矩阵臃肿，稀有词学不稳。
还要盯版权：词表与训练脚本的许可证是否允许你商用、是否允许开源权重。多语言、代码、数学符号覆盖不够，后面再补往往要重训或做痛苦的词表扩展。
技术栈： 仍然是 Python；工具层面常见 SentencePiece、Hugging Face tokenizers 等。先读懂 BPE / Unigram 在干什么，比死记 API 重要。
举个大家都能感知的例子：同一句中文，词表 A 切成 12 个 token，词表 B 切成 20 个。推理时按 token 计费或按长度截断，B 就会更贵、更容易被截断。所以 Tokenizer 不是「预处理小工具」，它直接咬进成本和效果。
四、模型架构：乐高说明书
现在主流是 Decoder-only 的 Transformer 变体（大家常说的 GPT / LLaMA 系思路）。你要能读懂几块积木：注意力、前馈、归一化（比如 RMSNorm）、位置编码（RoPE 等）、以及小模型上的取舍——层数、隐藏维、GQA（分组查询注意力）之类。
类比：架构是乐高说明书，不是乐高本身。 说明书决定能搭出什么形状；真正结不结实，还看塑料质量（数据）和你怎么拼（训练）。
小模型阶段，优先选社区验证过、文档清楚、能单卡跑起来的配置，而不是追论文里的奇技淫巧。
读架构时建议带着三个问题：① 信息怎么在层与层之间流动；② 位置信息怎么注入（没有它，模型分不清「我打了你」和「你打了我」的语序）；③ 哪里最吃显存（往往是注意力与激活值）。能用自己的话讲清这三点，比背一堆名词扎实。
技术栈： Python + PyTorch；会对照开源实现读论文。到「自己改注意力内核」那一步，才需要 CUDA。
# 极简：用 Hugging Face 风格接口加载配置（示意，非完整训练）
from transformers import AutoConfig
cfg = AutoConfig.from_pretrained("your-arch-config")
print(cfg.num_hidden_layers, cfg.hidden_size, cfg.vocab_size)
五、预训练：把「读完图书馆」变成可执行任务
预训练的目标，通俗讲就是：让模型在海量文本上学会「下一个词更大概率是什么」。工程上你要处理：优化器（常用 AdamW）、学习率日程、混合精度（如 bf16）、梯度累积（显存不够就积小步当大步）、梯度检查点、checkpoint 与续训、以及各种稳定性问题（loss 尖刺、溢出、数据管道饿死 GPU）。
Checkpoint 就像游戏存档。 训练跑到一半，系统更新重启、停电、显存爆掉——没有存档就得重开；有存档就能读档接着打。很多人第一次训模型，死在「不会续训」而不是「不会写模型」。
# 伪代码：梯度累积 + 定期存档
accum = 128
for step, batch in enumerate(loader, 1):
loss = model(batch).loss / accum
loss.backward()
if step % accum == 0:
optimizer.step()
optimizer.zero_grad()
if step % 100 == 0:
save_checkpoint(model, optimizer, step) # 存档
分布式可以后补：单卡先把正确性跑顺。真上多卡，再谈数据并行、张量并行、流水线并行——那是「多人流水线」：有人切数据，有人扛中间层，有人汇总梯度，节拍不齐就全员等待。
业余时间常见的坑也很土：笔记本合盖睡眠、Windows 自动更新、SSH 断了——训练进程没了。于是你学会三件事：关睡眠或用服务器、checkpoint 勤一点、续训脚本写成「指定 step 就能接着跑」。这些不像论文里的新方法，但决定你能不能把一次预训练跑完。
技术栈： Python / PyTorch 为主；启动、环境、日志、杀进程靠 Shell。多机多卡阶段才会深度用到分布式框架与 NCCL 一类通信库。
六、系统与性能：什么时候该碰 CUDA
显存不够、速度太慢、要写融合算子——这才进入系统层。CUDA / C++ 不是入门第一课；过早钻进去，容易「算子写得很炫，数据与评测一塌糊涂」。
类比：你会开车（Python 训练）就能上路；要自己改发动机（CUDA），是另一份工种。很多个人开发者在小模型阶段，用好 PyTorch、activation checkpoint、合理的 batch / 序列长，就够用了。
什么信号说明你该往系统层走？比如：同样的模型，别人 2 秒出字，你 20 秒；显存总在临界点抖动；或者你确认瓶颈在某个算子，而不是数据加载。那时再学 CUDA / Triton 是「有的放矢」。没信号就钻内核，容易变成表演型优化。
技术栈： CUDA、C++，有时用 Triton 写一点自定义核。推理侧常见 llama.cpp 等 C++ 实现。这层标记为「可后补」，不丢人。
七、评测：别只看 loss
Loss 下降只说明模型越来越会「续写训练语料」，不说明它在你的任务上变好。需要固定的评测集、可重复的脚本、以及「改了数据或超参之后会不会回退」的回归意识。
可以想成备考：模拟考（评测）和复习资料（训练集）必须分开；只看自己有多熟课文，进考场一样可能翻车。
技术栈： Python；把评测做成一键脚本，输出表格或 JSON，便于对比历史实验。有余力再接可视化与实验跟踪工具。
一个最低配做法：固定 50～200 条「你真正在乎」的问题（写作、代码、拒答、格式），每次重要改动都跑一遍，人工抽看。分数可以粗糙，可比性比花哨榜单重要。公开大榜有参考价值，但别拿它当唯一北极星——榜上高分、你的场景仍翻车，太常见了。
八、后训练与对齐：从「会续写」到「能听话」
预训练之后，通常还要：
- SFT（监督微调）：用「问题—好回答」教它按格式办事；
- 偏好对齐：让它更偏向人类喜欢的回答（具体算法族很多，先建立概念即可）；
- 工具调用：让它会查文档、跑代码、调 API——这已经靠近产品。
这一步决定用户体感。只做完预训练就喊「我们有大模型了」，往往名不副实。
打个比方：预训练像让孩子大量阅读，识字、通顺、见多识广；SFT 像请老师教「作文怎么审题、客服怎么礼貌拒答」；偏好对齐则更像根据批改意见调整文风。三段都重要，但职责不同。很多人拿到基座模型就急着做产品壳，结果壳很漂亮，模型却答非所问——缺的是后训练，不是又一个前端框架。
技术栈： 仍以 Python 为主，数据格式与评测脚本和前面一脉相承。
九、安全与合规：流程重于新语言
红队测试（故意诱导模型说出不该说的）、滥用场景、开源许可、训练数据来源——这些常常不是「再学一门语言」能解决的，而是清单、复审和记录。
权重一旦公开或交给客户，许可与数据血统会变成法律问题。技术人容易低估这一环，但踩雷很疼。
技术栈： 文档、清单、用例库；自动化测试可用 Python。语言不是瓶颈，态度才是。
也可以换个生活化类比：开饭店不只会炒菜，还得懂食材检疫、消防和发票。模型侧的「消防」就是红队与滥用场景；「发票与执照」就是数据与开源许可。缺一样，生意越大风险越大。
十、推理与产品化：能用、稳、算得过账
训完只是中点。量化（用更低比特存权重换速度与显存）、本地推理、API 服务、限流与监控、成本账——决定你能不能天天用、能不能给人用。
前端对话页（TypeScript / Vue / React）、网关（Go / Rust 等）属于产品壳。壳可以漂亮，但若模型与评测不过关，壳只是展柜。
成本账也建议早算：一张消费级卡 24 小时开着、电费与机器折旧、云上按小时租 A100/H100——不同路线差出一个数量级很正常。产品决策经常不是「能不能做」，而是「这个效果值不值得这个账单」。
技术栈：
| 方向 | 常见选择 |
|---|---|
| 本地推理 | C++/llama.cpp 一类、或 Python 推理栈 |
| 服务 | Python 先打通；高并发再考虑 Go / Rust |
| 控制台 / 对话页 | TypeScript + Vue 或 React |
| 业务后台 | Java 可以继续用——它负责业务，不负责训练主链 |
十一、一个人怎么排优先级
如果你只有业余时间和一张消费级 GPU，建议顺序是：
- Python + PyTorch 练熟（张量、Autograd、DataLoader、保存/加载）；
- 数据与评测最小闭环（哪怕先用公开维基一类语料）；
- 本机小模型把预训练链路打通（会冒烟、会续训、会看 log）；
- 再考虑 SFT、量化、简易对话页；
- 最后才深度补 CUDA、多机并行、复杂对齐。
「先打通 0.xB 量级的链路，再谈扩规模」——这个顺序，比一上来复制千亿配置现实得多。扩规模时，缺的往往是钱、电、人和数据纪律，不是又一个新框架。
若你已经有传统后端背景（比如 Java），完全可以把业务系统、账号、计费继续放在熟手里；只是请承认：训练主链要另开一条 Python 战线，别指望用 Spring 生态硬训 Transformer。前端同学同理——对话页可以你来做，梯度怎么稳还是得补课或找搭档。
结尾：一张对照，外加几个坑
| 阶段 | 几乎必会 | 可后补 |
|---|---|---|
| 数据 | Python、许可意识、基础 SQL | 大规模数仓 |
| Tokenizer | Python、许可 | 自研词表算法 |
| 架构 / 预训练 | Python、PyTorch、Shell、checkpoint | CUDA、多维并行 |
| 评测 / 后训练 | Python、固定基准 | 复杂对齐算法工程 |
| 安全合规 | 清单与复审 | — |
| 推理产品 | 量化概念、一种推理栈 | 高并发网关、复杂前端 |
常见误区，说直白点：
- 只会调 API，以为那叫自研。 调 API 是产品能力，值得做，但和「自研模型」不是一回事。
- 只会 Java / 前端，硬闯训练。 可以转，但请先补 Python 与深度学习基础，别用错工具硬刚。
- 一上来追千亿、追 SOTA。 链路不通，参数越大浪费越大。
- 不留评测集、不写实验日志。 三个月后你会长出三个互相打架的「最优配置」。
- 忽视许可。 数据与词表的许可证，决定了权重能不能发布、能不能商用。
如果你正在考虑入场：不必先成为 CUDA 专家，也不必先攒齐机房。把问题写清楚，把数据与评测立住，用小模型把「可中断、可续训、可复现」的预训练链路跑通——这本身就是硬功课。等这条路走顺了，再决定要不要加卡、加钱、加人或加参数，也不迟。
最后送一句挨过坑的人常说的话：大模型项目里，看起来最「没技术含量」的日志、存档、许可和评测，往往最救命；看起来最炫的新架构，往往可以等一等。 能力地图摊开，是为了让你知道全貌；真正开工，请从最小闭环开始。
文中涉及的架构与训练实践均为通用工程经验与公开技术路线说明，不构成对任何商业模型的能力对比，也不保证读者按相同步骤即可得到可用产品。涉及开源许可与数据合规时，请以律师与官方许可证文本为准。
