企业官网建设流程全解析

1. 项目概述：minimind 到底是个什么东西

minimind 这个名字听起来挺萌，但实际上它是一个相当硬核的极简版大语言模型项目。很多人看到“64M 参数”第一反应是：这么小的参数量，能跑出什么名堂？我自己第一次看到的时候也是这个想法，直到我真正把它跑起来，才发现小模型有小的玩法，而且这套玩法的价值一点不比动辄几十亿参数的大模型低。

这里的核心事实是：minimind 是用纯 PyTorch 从零搭建的、参数量仅约 6400 万的 decoder-only 语言模型。它不依赖任何预训练权重，不加载任何开源大模型的 checkpoint，完全从随机初始化开始训练。我在一颗普通的消费级 GPU 上，花 2 小时左右完成了全部训练流程，跑通了从数据准备到推理部署的整条链路。

这个项目适合谁？两类人最值得看。第一类是刚接触大语言模型训练的新手，你不需要几十张卡，不需要分布式训练框架，一台普通电脑就能把“训练语言模型”这件事从头体验一遍。第二类是想在边缘设备、微信小程序、本地单机环境里跑 AI 的场景开发者，64M 的参数量意味着模型文件只有一两百 MB，量化之后可以压缩到几十 MB，部署起来非常灵活。

我在实测中跑了多个任务，包括文本续写、简单问答、对联生成、小规模文本分类，整体表现虽然远不能和 GPT 这类大模型相提并论，但作为一个“两小时从零训练出来的模型”，它的表现超出了我的预期。这篇文章就把我整个过程的思路、步骤、踩坑记录和最终效果全部拆开来讲清楚。

2. 为什么是 64M 参数，训练 2 小时这个设定有讲究

2.1 参数量级背后的算力现实

先说一个很多人没直观概念的事情：训练大模型的显存和计算量到底有多夸张。以目前主流开源模型为例，7B（70 亿）参数的模型做一次全参数微调，即使使用 LoRA 这类高效微调手段，也至少需要一张 24GB 显存的显卡；如果是全量预训练，没有几十张 A100 基本不用想。这还只是训练端的成本，推理端的显存占用同样让人头疼。

而 64M 参数是什么概念？用 FP32 精度存权重，内存占用约 256MB；用 FP16 就是 128MB；8bit 量化后直接降到 64MB。这意味着它可以在几乎任何带 2GB 显存的设备上跑推理，CPU 上也能勉强跑得动。我在实测中用的是一块 RTX 3060 12GB 的卡，训练过程峰值显存占用仅 5.8GB，训练完以后用同一张卡做推理，显存占用只有不到 1GB。

所以“64M 参数”并不是拍脑袋选的数字，它正好卡在一个非常实用的区间：普通消费级 GPU 能轻松承载训练，边缘设备也能比较舒服地完成推理部署。如果参数再翻一倍到 128M，训练时间会拉长到 4~5 小时，推理性能也会成比例下降，但能力提升并没有明显优势。64M 是一个性价比相当高的平衡点。

2.2 2 小时训练时间的可复现性

“从零训练 2 小时到底能干嘛”这个标题里的“2 小时”也是个关键设定。很多人对大模型训练的印象是“动辄训练几个月”，所以一听 2 小时就觉得不可能。实际上这里有一个核心区别：训练数据量、模型大小和训练步数共同决定了总时长，而大模型动辄数月的训练时间，是因为它在几十 TB 的数据上反复迭代，要求的是“泛化到全世界所有文本”的通用能力。

minimind 的目标则完全不同——它只要求在特定规模和特定数据集上达到可用水平。我在实测中用的训练集是大约 180MB 的中文语料，包括维基百科子集、新闻标题、古诗文片段和对话文本，总计约 500 万条短文本样本。在 batch size=32、序列长度=128 的设定下，一个 epoch 大约需要跑 4000 步，5 个 epoch 就是 20000 步。用 RTX 3060 实测，每秒能跑约 3 步，总时长刚好在 1.8 到 2.2 小时之间。

这个数据量级完美匹配 64M 参数模型的容量——参数少，数据量也不需要特别大即可达到拟合状态。如果用 7B 模型在同样的数据上训练，大概率会严重欠拟合，因为模型容量远超数据信息量，训练时间反而更长且效果未必更好。小模型配小数据，这套组合天然适合“快速验证思路”的工作流。

2.3 零基础实现的核心意义

“从零训练”这四个字是这个项目里最有价值的部分。当前整个 AI 圈子的主流叙事是“加载预训练模型→微调→部署”，很少有人关心模型内部的参数是怎么一步步从随机值变成有意义的表示的。minimind 把这条被跳过的路完整补上了。

从零训练意味着你需要自己准备数据、自己设计 tokenizer、自己写训练循环、自己处理 loss 曲线的震荡和收敛问题、自己调学习率……每一步都会踩坑，但每一步都能让你对语言模型的理解比“调包侠”深一个量级。我用 GPT-2 类似的架构搭建了整个模型，包括 token embedding、位置编码、12 层 transformer block、因果注意力掩码，然后从均匀分布的随机初始化开始训练。第一次看到 loss 从 10.8 慢慢降到 3.5 左右的时候，那种成就感完全不是加载别人权重能比的。

3. 核心原理拆解：64M 模型是怎么把“语言”学出来的

3.1 语言模型的目标函数是“猜下一个词”

很多人对语言模型有误解，以为它有什么神奇机制在“理解”语言。实际上，它做的事情在训练阶段极其朴素：给定前文，预测下一个词的概率分布，计算交叉熵损失，反向传播更新参数。就这么简单。

用 minimind 具体来说，输入一段文本“我喜欢吃”，模型需要产出下一个词的概率分布，正确选项是“苹”或者“苹果”（取决于 tokenizer 的分词粒度）。训练时把这一条样本拆成 input 和 label：input 是「[BOS] 我 喜 欢 吃」，label 是「我 喜 欢 吃 苹」，模型逐个位置输出预测，然后和 label 对比修正误差。

这种“next token prediction”模式虽然简单，但它有个深刻的含义：模型必须从海量文本中学会语言的内在统计规律——哪些词经常一起出现、什么样的语法结构是合理的、什么样的上下文会引出什么样的后续内容。当模型参数量足够大且训练数据足够丰富时，语言能力会从统计规律中“涌现”出来。

64M 参数是典型的“统计规律”型模型，它的能力上限基本由训练数据的分布决定。你在诗词数据上多训练几个 epoch，它就特别擅长写七言绝句；你在代码数据上多训练，它就偶尔能输出像模像样的 Python 函数。参数的每一次更新，本质上都在调整模型对“世界文本分布”的建模精度。

3.2 Transformer 块在 64M 小模型里是怎么工作的

minimind 的模型结构基本复刻了 GPT-2 的架构，只是把各维度规模缩小了。我用了一个 6 层的 transformer block，每层隐藏维度 768，12 个注意力头，FFN 中间维度 3072。这个规模比原始 GPT-2 的 12 层 768 维减小一半，但整体结构完全一致。

每个 transformer block 内部分两个子层。第一个子层是因果自注意力机制——每个位置的输出只依赖它之前的 token，不能“偷看”未来的内容。具体实现时通过一个上三角掩码矩阵，把注意力分数中未来位置的部分设为负无穷，softmax 之后就变成了 0 权重。第二个子层是前馈网络，一个简单的 MLP，对每个位置独立做非线性变换。

训练时整个模型的前向传播过程是：token 序列查 embedding 表拿到向量，加上位置编码保留顺序信息，然后依次穿过 6 个 transformer block，最后过一个线性层映射回词表大小。词表我设了 15000 个 token，所以最后的输出层维度是 15000×768，这个层的参数就有 1150 万，占全模型 6400 万的近 1/5。

有意思的是，如果你把模型结构打印出来看参数量分布，会发现 embedding 矩阵和最后的输出层占了相当大比重，而 6 层 transformer block 本身其实只占一半左右。这说明对小模型来说，token embedding 的巨大参数量是一个需要认真对待的问题——很多优化方向，比如共享 embedding 权重、用更小的词表，都是从省这两块参数入手的。

3.3 训练时的 loss 曲线能看出什么问题

我在训练过程中记录了每个 step 的 loss，画出来的曲线非常有意思。刚开始的几百步，loss 从初始的 10.8 快速下降到 7.0 左右，下降速度极快——这很好理解，模型参数还是随机状态，最容易学到的就是词频统计信息，高频词很快就被模型优先捕捉了。

loss 到 5.0 附近后，下降速度明显放缓，进入一个“平台期”。这个阶段模型开始试图学习更复杂的语法结构和搭配规律，但更新梯度对参数的影响开始变得不显著。我一度怀疑是不是学习率设置有问题，后来把学习率从 3e-4 降到 1e-4 之后，曲线重新开始缓慢下降，最终稳定在 3.4 左右。

整个 2 小时的训练中，loss 曲线呈现典型的“快速下降→平台整理→缓慢下降→二次平台”形态。最后 3000 步基本没有明显下降了，这说明模型已经接近当前数据量和参数规模下的容量上限。如果你想让 loss 进一步降低，只有两条路：加大训练数据量，或者增大模型参数量。但作为 2 小时的从零训练实验，3.4 的最终 loss 在我的预期范围内，生成效果也基本能用。

4. 实操全流程：从零开始训练 minimind 的完整步骤

4.1 环境准备与数据构建

先说硬件环境。我的实测平台是：CPU 为 i7-12700，内存 32GB，显卡是 RTX 3060 12GB，操作系统 Ubuntu 22.04，Python 3.10，PyTorch 2.0.1，CUDA 11.8。这个配置放在 2024 年算是非常入门级了，如果你手头有类似的电脑，完全可以复现。

软件依赖方面其实非常简单，只需要三个核心库就能跑通：torch（模型训练）、transformers（tokenizer）、datasets（数据处理）。如果你不想用 transformers 的 tokenizer 组件，也可以自己写一个 BPE 分词器，训练脚本总共也就两百行代码。我更推荐直接用 transformers 自带的 GPT2TokenizerFast，能省掉不少底层细节的麻烦，把精力集中在模型本身。

数据准备是这个项目里最花时间的一步。网上可以直接下载到不少开放的中文语料，但我实测下来，直接把所有语料混在一起效果并不好。我的做法是做了一个简单的数据混合方案：维基百科占 40%，新闻标题占 25%，古诗文占 15%，对话数据占 20%。总文件大小约 180MB，全部按 UTF-8 编码，以纯文本形式存储，每行一条样本。

数据处理好之后，用 tokenizer 把每行文本切分成 token 序列，设定最大长度 128，超过则截断，不足则补 PAD。处理完之后保存为一个箭头格式的数据集文件，训练时直接读取。这一步不要省时间，数据质量决定了模型全部的上限。

4.2 模型构建的关键代码

模型部分我直接写了一个 mini GPT 结构，没有用 transformers 库封装好的 GPT2 类，目的是为了完全掌控每一步的逻辑。核心代码可以从简，但关键部分必须自己写，这样出了问题才知道去哪里排查。

import torch import torch.nn as nn class MiniMindBlock(nn.Module): def __init__(self, config): super().__init__() self.ln1 = nn.LayerNorm(config.hidden_dim) self.attn = nn.MultiheadAttention( config.hidden_dim, config.num_heads, batch_first=True ) self.ln2 = nn.LayerNorm(config.hidden_dim) self.mlp = nn.Sequential( nn.Linear(config.hidden_dim, config.ffn_dim), nn.GELU(), nn.Linear(config.ffn_dim, config.hidden_dim) ) def forward(self, x, mask): x = x + self.attn(self.ln1(x), self.ln1(x), self.ln1(x), attn_mask=mask)[0] x = x + self.mlp(self.ln2(x)) return x class MiniMind(nn.Module): def __init__(self, config): super().__init__() self.token_embedding = nn.Embedding(config.vocab_size, config.hidden_dim) self.pos_embedding = nn.Embedding(config.max_seq_len, config.hidden_dim) self.blocks = nn.ModuleList([ MiniMindBlock(config) for _ in range(config.num_layers) ]) self.ln_f = nn.LayerNorm(config.hidden_dim) self.lm_head = nn.Linear(config.hidden_dim, config.vocab_size, bias=False) def forward(self, input_ids): seq_len = input_ids.shape[1] mask = torch.triu(torch.full((seq_len, seq_len), float('-inf')), diagonal=1).to(input_ids.device) x = self.token_embedding(input_ids) + self.pos_embedding( torch.arange(seq_len, device=input_ids.device) ) for block in self.blocks: x = block(x, mask) return self.lm_head(self.ln_f(x))

这段代码里需要特别关注的一个细节是因果注意力掩码。torch.triu(..., diagonal=1)生成了一个上三角矩阵，把当前位置右上方的所有区域都置为负无穷。没有这个掩码，模型在训练时就会从未来 token 里“偷看”信息，导致 loss 极其虚低，但实际推理时完全废掉。

模型初始化的方式也会影响训练速度。PyTorch 默认的 Linear 和 Embedding 初始化用的是均匀分布，但对 Transformer 来说，常用的是标准差为 0.02 的正态分布。我实测对比过，用正态分布初始化比默认初始化能让第一个 epoch 的 loss 多下降 0.2 左右。另外，残差连接前的输出层需要按层数开根号缩放，这个细节虽然不致命，但会让训练更稳定。

4.3 训练超参数的选择与调优过程

训练超参数是我花时间最多的地方。第一次跑的时候我用了比较大的学习率 2e-4，batch size 64，结果 loss 曲线震荡非常明显，在 4.8 附近上下波动怎么也降不下去。后来我把学习率降到 1e-4，batch size 改为 32，loss 才开始稳定下降。

最终确认的一组参数如下表所示：

这里有个特别值得强调的细节：不要直接使用恒定学习率贯穿整个训练。我在实验中发现，同样的 20000 步训练，cosine 调度比恒定 1e-4 的效果好得很明显，最终 loss 能多降 0.2 左右。原因是训练后期参数已经接近最优区域，固定的大学习率会在最优值附近来回震荡，而减小学习率可以让参数更精确地落到底部。

训练循环本身就像最普通的监督学习一样：前向传播算 loss，反向传播求梯度，优化器更新参数。唯一需要注意的是，PyTorch 的梯度默认是累积的，所以每个 step 必须手动调用optimizer.zero_grad()，否则梯度会在多个 step 之间叠加，导致训练发散。这是我的老毛病了，每次换框架都会踩一次。

4.4 训练过程的监控技巧

我强烈建议在训练脚本里加上一个简单的日志回调，每 100 个 step 打印一次当前的 loss、学习率和显存占用情况，顺手把每个 step 的 loss 追加到一个 CSV 文件里。训练结束后用 pandas 或者 matplotlib 把 loss 曲线画出来，你会非常直观地看到模型的学习过程。

画图这个步骤不是可有可无的仪式感，而是排查问题的关键工具。比如我在第一次实验中发现 loss 在 3000 步之后出现了一个突然的尖峰，从 4.5 跳到 6.2 然后又掉回 4.4。看数值变化很小，但画图后才发现是学习率调度的 warmup 阶段结束、学习率进入衰减阶段导致的梯度更新幅度变化，属于正常现象。如果只盯着终端里的数字，很容易误判成训练炸了。

另外，训练过程中保存 checkpoint 的策略也很重要。我的做法是每 2000 步保存一次最新的权重，同时保留 loss 最低的那一次。因为你永远不知道训练后期会不会过拟合或者出现奇怪的问题。实测下来，minimind 在第 16000 步左右的 checkpoint 生成的文本质量最好，第 20000 步的最终权重反而有点“过于平滑”，部分场景下生成的句子缺乏一些随机性。这背后的原因可能是数据量过小导致后期过拟合，所以保存多个 checkpoint 并分别测试，是必要的步骤。

5. 实测效果展示：2 小时训练出来的模型能干什么

5.1 直接文本续写：最直观的能力体现

训练完模型之后，我第一件事就是做文本续写测试。写了一个简单的贪心推理脚本，给定一个开头，让模型逐个 token 往后生成，每次取概率最高的那个 token。

测试 1：“春天的花开在”

模型输出：“春天的花开在山间的小路上，远处的树林里传来鸟儿的叫声，一群孩子正在树下玩耍，他们的笑声回荡在春风里。”

这段输出让我相当意外。它的语法完全通顺，两个分句之间逻辑也连贯，甚至出现了“回荡”、“春风里”这种带有一定文学色彩的搭配。考虑到这个模型只在 180MB 数据上训练了 2 小时，且参数量只有 64M，这个表现已经不算是“人工智障”级别了。

测试 2：“人工智能将”

模型输出：“人工智能将在未来改变人类的生活方式，会给我们带来很多便利，但是也会带来一些挑战，需要我们的关注。”

这个回答虽然内容比较空泛，但至少逻辑上是通的——先给出正面评价，然后转折指出挑战，还加了一句“需要我们的关注”来收尾。这种三段式结构明显是从新闻语料里学到的常见论述模式。

不过小模型的局限性也非常明显。我试了一个稍复杂点的开头：“中国的首都是”，模型输出“中国的首都是北京，上海是中国最大的城市之一”。第二句是合理的，但逻辑衔接不够自然。我又试了“1+1=”，模型输出“1+1=2, 2+1=3, 3+1=4, 4+1=5”，虽然第二个等式开始跑偏了，但它确实学到了“等号后面跟数字”以及“数列递增”的模式，这也算是一种统计规律的体现。

5.2 简单问答与对话：能聊，但别指望深度

对话类是更多人关心的场景。我单独构造了一部分问答形式的训练数据，格式是“问题：xxx 回答：xxx”，然后训练模型去续写回答部分。实测效果如下：

提问：“你喜欢什么颜色？” 模型输出：“我喜欢蓝色，因为蓝色代表宁静和智慧。”

提问：“怎么才能学好编程？” 模型输出：“学好编程需要掌握基础知识和基本技能，多做题，多练习，多看一些好的开源项目，还要有耐心和毅力。”

说实话，这两个回答的质量超出了我对 64M 模型的预期。尤其是第二段，虽然内容是网上常见的大路货总结，但句子的流畅度和措辞的合理性都达到了能读的程度。原因也不难理解——这类问答语料在训练数据中重复模式很强，模型本质上是在复用数据里出现频率最高的回答模板。

但稍微一增加问题的复杂度，模型就露馅了。我试了“解释一下什么是相对论？”，模型的回答是“相对论是一种物理理论，它描述了物体在高速运动时的运动规律。”这个回答表面上看是正确的废话，细节层面完全站不住脚。这就是小模型的根本限制：它的参数量只够记住“相对论是一种物理理论”这种高频表达，不够支撑深入的理论细节。

5.3 其他有意思的应用场景测试

除了文本续写和对话，我还测了几个比较有代表性的任务。

诗词生成这块，得益于语料里有古诗文数据，模型的表现出奇地好。给一个上句“床前明月光”，模型接的是“窗前明月光，疑是地上霜。举头望明月，低头思故乡。”虽然是改了两个字，但它确实学到了五言绝句的基本格律。我又试了原创开头“孤舟夜泊寒江上”，模型接“远客天涯故国情，秋风吹尽梧桐叶，又见江南月正明。”虽然平仄不完全工整，但对韵脚的感觉已经有模有样了。

文本分类任务对小模型来说是相对简单的任务，因为本质上是找输入文本和标签之间的统计相关性。我把模型输出的最后一层隐藏状态拿出来，接一个简单的逻辑回归分类器，在情感二分类的 5000 条测试集上达到了 87% 的准确率。这个水平虽然比不过微调 BERT 之类的方案，但考虑到模型是通用的文本生成模型，算是可用水平了。

我甚至试着把它接了一个简单的平台接口，通过 API 方式在微信小程序里调用。方法非常简单：把训练好的模型导出为 ONNX 格式，然后用一个轻量级的推理引擎在服务器上跑。PIN 一个 16MB 的量化模型，服务端推理一张文本输入的耗时在 200ms 左右，响应速度完全足够支撑小程序端的需求。这个方向证明了 64M 小模型确实有落地价值，不是只能拿来“炫技”。

6. 将 minimind 部署到微信小程序与本地电脑：轻量化实践

6.1 ONNX 导出与量化压缩

训练完成后，模型是 PyTorch 的nn.Module，这种格式在部署场景不太方便。我直接用了torch.onnx.export把模型导出为 ONNX 格式，这样后续可以接力 ONNX Runtime 推理引擎，得到更快的推理速度。

在导出前，一个重要的步骤是确认模型的输入输出格式。minimind 的输入是input_ids，一个形状为[batch_size, seq_len]的整数张量，输出是[batch_size, seq_len, vocab_size]的 logits。ONNX 导出时要把动态轴标记出来，尤其是batch_size和seq_len，否则导出后只能接受固定长度的输入，限制使用灵活度。

模型导出为 FP32 的 ONNX 文件后，体积大约 250MB。之后我用onnxruntime的量化工具做了一层 INT8 量化，模型压缩到了约 65MB，精度损失在可接受范围内。

6.2 微信小程序部署的整体思路

微信小程序本身不能直接跑 PyTorch 模型，但它可以通过 HTTPS 请求调用后端推理服务。所以整个链路是：小程序端发送文本 → 后端服务器接收请求并处理 → 模型推理 → 返回生成结果 → 小程序展示。

后端我用的是 FastAPI 搭了一个轻量的 HTTP 服务。请求格式定义为简单的 JSON{"prompt": "春天的花开在"}，响应为{"generated_text": "...完整输出..."}。ONNX Runtime 加载模型后常驻内存，每次请求只需调用一次session.run，性能非常稳定。

我自己实测，在没有 GPU 的小型云服务器上（2 核 4GB 配置），单次推理的平均耗时约 350ms，完全能满足正常交互场景。如果对端延迟有更高要求，可以在服务器上启用 ONNX Runtime 的 GPU 版，把耗时压到 150ms 以内，但成本会增加一些。

6.3 本地电脑部署的另一个方案

如果你不想走服务器部署路线，本地电脑部署反而更简单。直接把训练好的模型以 PyTorch 的.pt格式存在本地，然后写一个简单的推理脚本，用torch.load加载权重，就能本地运行。

本地部署还需要考虑一个问题：如何让其他程序调用模型。我之前在几个项目里总结的方法是封装一个 Python 类，对外提供generate(prompt)和predict(prompt)两个方法。生成方法类似写一个循环，每个 step 把最新的输出 token 拼到输入序列后面，再继续推理；预测方法则在输出层后面接一个softmax，取最大概率的类别。这样一个类接口可以平滑对接本地 CLI 工具、Flask API 或者其他 Python 程序。

6.4 部署过程中的避坑清单

整个部署环节我踩过一些坑，这里分享几个经验：

1. 注意 input_ids 的数据类型。模型训练时用的是torch.long，导出 ONNX 后输入类型也会限定为 int64。如果推理时传入 int32，ONNX Runtime 会直接报错，需要统一。

2. ONNX Runtime 的 opset 版本选择。我用的是 opset 14，太低的版本可能不支持部分算子，导致导出后模型在推理时出现UnsupportedOperator的错误，看着很头疼。

3. 推理时序列长度的问题。ONNX 导出时如果你不设置动态轴，模型只能接受固定长度输入，比如 128。输入短的时候要补 PAD 到 128，输入长了要截断，这个逻辑必须在服务端处理好，否则接口会因为序列长度不对直接崩。

4. 小内存设备上的推理提示。如果目标设备内存很紧张，建议将 INT8 量化后接入 ONNX Runtime 的 CPU 执行提供程序，它的内存占用会进一步下降，但同时推理速度也会下降 30%~50%，需要根据自己的场景做权衡。

7. 常见问题与排查技巧实录

7.1 训练阶段问题速查表

7.2 推理阶段问题速查表

7.3 我个人的一些避坑心得

我在这类小模型实操中最常说的一句话是：“小模型的成败，七分在数据，两分在调参，一分在架构。”很多人一开始就纠结模型层数、注意力头数，但这些在参数规模只有 64M 的情况下，对最终效果的影响真的远小于训练数据的质量和分布。

比如我最初的一个版本，把全部数据混在一起不区分类型，训练完效果非常差，生成的东西逻辑跳跃严重。后来我把数据按领域切分并按比例混合，效果立刻有了质的提升。这背后的原因是：不按比例混合时，新闻文本（数据量大）会主导模型的学习方向，其他领域的表达能力就会被严重压缩。

调参方面，AdamW 的两个 beta 参数偶尔需要额外调整。默认设betas=(0.9, 0.999)，在长序列训练中容易导致训练后期梯度更新偏小。我实测把 beta2 从 0.999 改成 0.98 后，收敛速度快了约 5%，效果略有提升。不过这个参数不是通用的，不同数据规模最优值不同，需要自己跑几次实验对比。

最后想提醒的是：不要对 2 小时训练的 64M 模型抱有超越其能力边界的不切实际期待。它的价值在于“用极低的成本验证语言模型训练的完整流程”，以及“在资源受限场景中找到一个可用的轻量级方案”。如果你需要更强的能力，方向应该是扩大数据量、增大模型、延长训练时间——但这套从零训练的思维模式，在任何规模的模型上都通用。