Karpathy 又整活儿了！一天训练出 GPT-2、成本还骤降 100 倍，网友：dream 老黄把价格再打下来
OpenAI 创始成员、前研究科学家 Andrej Karpathy 最近尝试在 llm.c 中重现了 GPT-2。这里的 GPT-2 是 15.58B 参数的完整版本，最初亮相于 OpenAI 2019 年 2 月 14 日发布的博文《Better Language Models and their Implications》当中。
“2019 年时，GPT-2 的训练工作还是一个涉及整个团队、需要规模化投入的项目。但如今 5 年过去，随着计算（H100 GPU）、软件（CUDA\cuBLAS、cuDNN、FlashAttention）和数据（例如 FineWeb-Edu 数据集）等层面的改进，我们已经能够在 24 个小时之内凭借单个八 H100 节点成功对该模型进行重现，且总成本仅为 672 美元。”Karpathy 说道。
Karpathy 在 2017 年离职后进入特斯拉担任 AI 高级总监，但在 2023 年再次回到 OpenAI 组建团队，并推出了 ChatGPT。一年后，Karpathy 离开了 OpenAI，并出于教育意义开发了 llm.c。llm.c 是简单、纯 C/CUDA 的 LLM（总计约 5000 行代码），无需使用涉及 Python 解释器或者高复杂度深度学习库（例如 PyTorch/JAX、huggingface/transformers 等）的典型训练技术栈。
在 Karpathy 公布了这一结果后，有网友问到当时训练 GPT-2 的成本，Karpathy 回答道：
这些信息从未公开过，但我估计成本要高得多。按乘数倍率来算，数据方面可能要高了 3 倍，硬件利用率方面高 2 倍。2019 年的计算集群可能使用的是 V100 (~100 fp16 TFLOPS)，现在可能换成了 H100 (~1,000)，这样算下来性能大概提高了 10 倍。所以成本方面非常粗略地估计，可能要高出 100 倍，也就是大约 100,000 美元左右？
对此有网友评价道，“随着英伟达对 AI 工作负载加速硬件开发的不断深入，我预计未来几年内，这款硬件的成本可能只有几十美元，并且训练时间只需几个小时。”
至于具体效果，Karpathy 与 19 年的 GPT-2 版本做了对比。同样用的当时博文介绍里的提示词“In a shocking finding, scientist discovered a herd of unicorns living in a remote, previously unexplored valley, in the Andes Mountains. Even more surprising to the researchers was the fact that the unicorns spoke perfect English.” 结果新模型的输出结果相当连贯，质量也大致与 GPT-2 相当。
两个模型生成的文字较长，有兴趣的朋友可以点击查看：http://llmc.s3-us-west-2.amazonaws.com/html/gpt2_vs_llmc30kedu.html
下面我们来看下 Karpathy 的复刻过程。
复现过程首先，Karpathy 强调，使用 llm.c 训练 GPT-2 非常简单，因为它是用 C/CUDA 编写的，所以全程不涉及 minconda、Python、PyTorch 等。只需要一台八 H100 GPU 的设备即可。
“总之，不必担心，llm.c 在算力要求方面非常灵活，哪怕只有一张 GPU，大家也仍然可以训练出自己的 GPT-2——只不过需要等待 8 天，而不是像我这样的 1 天。而如果您拥有 16 张 GPU（例如使用新的 Lambda 1 Click Clusters），还可以开展多节点训练，前后只需要等待 12 个小时。”Karpathy 说道。
在节点启动之后，下面来看看 GPT-2 训练的完整说明，不用担心，Karpathy 表示保证一分钟以内开始执行：
# install cudnn so we can use FlashAttention and run fast (optional)# https://developer.nvidia.com/cudnn-downloads# for me, CUDA 12 (run `nvcc --version`) running on Linux x86_64 Ubuntu 22.04wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.1-1_all.debsudo dpkg -i cuda-keyring_1.1-1_all.debsudo apt-get updatesudo apt-get -y install libcudnn9-dev-cuda-12# "install" cudnn-frontend to ~/git clone https://github.com/NVIDIA/cudnn-frontend.git# install MPI (optional, if you intend to use multiple GPUs)# (you might also have to install NVIDIA NCCL if it doesn't come with your setup)sudo apt -y install openmpi-bin openmpi-doc libopenmpi-dev# download and enter llm.c repogit clone https://github.com/karpathy/llm.c.gitcd llm.c# download the "starter pack" (~1GB download)# contains GPT2-124M weights (used in tests), tokenizer, eval data .bin s./dev/download_starter_pack.sh# download the training dataset (FineWeb-Edu 100B token) .bin data shards# note: this is a total of 1001 data shards. If you only want to test things# out and don't want to do an actual run, feel free to append the number of# training shards to download (e.g. for just 10 shards: ./edu_fineweb.sh 10)# the full dataset is ~200GB, we can store it here in dev/data directory.cd dev/data./edu_fineweb.sh# compile (~1 min 1st time for cuDNN mostly, few sec from then on)cd ../../make train_gpt2cu USE_CUDNN=1# and train! (wait 24 hours here)mpirun -np 8 ./train_gpt2cu \-i "dev/data/edu_fineweb100B/edu_fineweb_train_*.bin" \-j "dev/data/edu_fineweb100B/edu_fineweb_val_*.bin" \-o "log_gpt2_1558M" \-v 250 -s 300000 -g 384 \-h 1 \-b 16 -t 1024 \-d 1048576 \-r 0 \-z 1 \-c 0.1 \-k "cosine" \-l 0.0006 \-q 0.1 \-u 700 \-n 2000 \-x 32000 \-ge 1 \-y 1 \-e "d48"
稍后会对参数做具体解释。接下来开始优化：
num_parameters: 1557686400 => bytes: 3115372800allocated 2971 MiB for model parametersbatch_size B=16 * seq_len T=1024 * num_processes=8 and total_batch_size=1048576=> setting grad_accum_steps=8created directory: log_gpt2_1558Mallocating 40409 MiB for activationsval loss 11.129390allocating 2971 MiB for parameter gradientsallocating 742 MiB for AdamW optimizer state mallocating 742 MiB for AdamW optimizer state vallocating 742 MiB for master copy of paramsstep 1/32000 | loss 11.133732 (+nanz)| norm 52.9732 (+nanz)| lr 8.57e-07 | 3056.36 ms | 42.6% bf16 MFU | 343080 tok/sstep 2/32000 | loss 10.539388 (+nanz)| norm 43.5996 (+nanz)| lr 1.71e-06 | 2747.19 ms | 47.4% bf16 MFU | 381690 tok/sstep 3/32000 | loss 9.894109 (+nanz)| norm 23.2229 (+nanz)| lr 2.57e-06 | 2753.25 ms | 47.3% bf16 MFU | 381259 tok/sstep 4/32000 | loss 9.566241 (+nanz)| norm 28.4920 (+nanz)| lr 3.43e-06 | 2741.47 ms | 47.5% bf16 MFU | 381690 tok/sstep 5/32000 | loss 9.482848 (+nanz)| norm 23.7817 (+nanz)| lr 4.29e-06 | 2752.07 ms | 47.3% bf16 MFU | 381507 tok/sstep 6/32000 | loss 9.332832 (+nanz)| norm 15.9113 (+nanz)| lr 5.14e-06 | 2751.01 ms | 47.3% bf16 MFU | 381431 tok/sstep 7/32000 | loss 9.165650 (+nanz)| norm 10.5941 (+nanz)| lr 6.00e-06 | 2753.03 ms | 47.3% bf16 MFU | 381327 tok/sstep 8/32000 | loss 9.132234 (+nanz)| norm 16.2733 (+nanz)| lr 6.86e-06 | 2748.91 ms | 47.3% bf16 MFU | 381348 tok/sstep 9/32000 | loss 9.097384 (+nanz)| norm 12.1342 (+nanz)| lr 7.71e-06 | 2748.73 ms | 47.3% bf16 MFU | 381367 tok/sstep 10/32000 | loss 9.072879 (+nanz)| norm 10.5923 (+nanz)| lr 8.57e-06 | 2749.40 ms | 47.3% bf16 MFU | 381369 tok/s...
可以看到，每个步骤大约需要 2.75 秒，而其中总共涉及 3.2 万个步骤，所以现在需要等待约 24 个小时。
在每一步中，训练作业的运行都会占用约 100 万个 FineWeb-EDU token（数据内容来自互联网上的教育网页），并对模型的 15.58 亿个权重进行更新，使其能够更好地预测序列中将要出现的下一个 token，到最后将总计处理 3.2 万 x 1048576 = 33.6 B 个 token。随着预测下一 token 的能力越来越强，loss 也会随之下降。
接下来的工作是归一化（将数值范围控制在 0.1 至 1 之间），学习率也在前几个步骤中逐渐升温。从结果来看，这套模型的 flops 利用率（MFU）约为 50%，可说是相当高效了。
现在唯一要做的，就是等待 24 小时让其完成，之后可以使用 dev/vislog.ipynb jupyter notebook 对 main.log 日志文件进行可视化。为此，大家需要安装 Mython 和 matplotlib。
如左图，正在跟踪 FineWeb-EDU 验证数据的 loss。如果大家只运行 OpenAI 发布的 GPT-2 并在此基础上评估其 loss，得到的就是红色水平线（loss 2.83）。而 Karpathy 模型的运行结果快速将其超越，步长约为 5000。
当然，这样的比较并不公平，毕竟 GPT-2 是在从未发布的 WebText 数据集上训练而成，因此素材内容可能存在很大的分布差异。比方说，如果在 LR 1e-4 下对 OpenAI 模型进行 1000 步微调，loss 就会迅速下降至划线（loss 2.61），代表其正在快速适应新的统计数据。
但就个人而言，Karpathy 认为 loss 验证更多只是一种健全性检查，要实际比较模型性能，还是得借助更靠谱的第三方评估。
这时候就要请出 HellaSwag 评估了，这也是目前市面上表现良好、流畅、普及度高、常被引用且能够提供早期信号的评估方案之一。其中提供的都是简单的常识性场景，大模型必须据此做出正确的内容延展。
Karpathy 在右侧窗格中评估了 HellaSwag，并发现在约 25K 步左右与 GPT-2 模型的性能发生交叉（早于 GPT-2，据估计 GPT-2 的训练数据集共有约 1000 亿个 token。但这可能与数据质量的提高有关，之前 Karpathy 在 124M 训练期间也观察到了类似的现象）。绿线为同等参数规模的 GPT-3 模型，其模型架构与 GPT-2 几乎相同、仅存在细微差别（上下文长度从 1024 增长至 2048），同时是针对 3000 亿 token 进行了训练（相当于我们此次实验训练 token 量的 10 倍左右）。
必须承认，HellaSwag 也不能算是完美的单点比较选项，毕竟它测试的主要是简单的英语和常识，并不涉及多语言、数学或者代码内容。也许是因为 WebText 数据集在这几个方面拥有更高的比重，所以才把模型规模推到了这样的水平，但 Karpathy 团队并不确定，毕竟 OpenAI 从未对此做出过解释。
Karpathy 指出，一般来讲，在 GPT-2 等低能力模型上很难获得良好的评估结果，毕竟这类模型无法理解多项选择题；而且其样本质量不够高，无法正常完成涉及标准数学或者代码的评估测试。
参数指南现在让我们仔细看看我们在训练中传递的参数。OpenAI 发布的 GPT-2 虽然包含模型权重，但相关细节却很少；GPT-3 版本并未开放权重，但相关细节较多。因此在多数情况下，我们只能参考 GPT-3 论文中提及的超参数，毕竟 GPT-2 论文几乎没有提到这方面信息：
-i -j 用于训练和验证分割标记文件，需要提前使用 edu_fineweb.sh 进行下载。
-o 是写入日志和检查点的输出目录。
-v 250 要求每 250 步执行评估并记录验证 loss。
-s 300000 要求每 30 万步采样部分 token。因为总步数不足 30 万，所以这其实是一种关闭采样的灵活方式，实际只会在最后采样一次。
-g 384 将最后需要采样的 token 数设置为 384。
-h 1 要求评估 HellaSwag 准确性。
-b 16 将微批次大小设置为 16。如果内存不足，请降低此值，例如依次尝试 8、4、2、1。
-t 1024 将最大序列长度设置为 1024，与原版 GPT-2 保持一致。
-d 1048576 要求总批次大小为 2 的 20 次方，与 GPT-3 论文中的超参数设置相同。代码将确保满足所需的总批次大小，并计算优化所需的梯度累积“内循环”步骤。例如，之前提到 Karpathy 拥有 8 张 GPU，每张 GPU 执行 16 x 1024 个 token，因此每个微步（即一次向前向后）对应 8 x 16 x 1024 = 131072 个 otken，因此代码计算梯度累积步数应该为 8 以满足每步所需的 1M 批次大小。即每向前 + 向后 8 次，而后进行一次更新。
-r 0 将重新计算设置为 0。重新计算是一种在计算与内存之间求取平衡的方法。如果设为 -r 1，则代表在反向过程中重新计算前向传递的一部分（GeLU）。就是说 Karpathy 不必须通过对其缓存来节约内存，但需要付出更高的算力成本。因此如果内存不足，请尝试设置 -r 1 或者 -r 2（同时重新计算 layernorms）。
-z 1 在多个 GPU 上启用 ZeRO-1（即优化器状态分片）。如果使用多于 1 张 GPU 进行训练，则应当选择这样的设置，且基本上应始终将其保持为开启状态。但在单 GPU 上，此设置没有实际效果。
-c 0.1 将权重衰减设置为 0.1。只有（2D）权重的衰减与 GPT-2 完全相同，具体数值来自 GPT-3 论文。
-k "cosine" 设置余弦学习率计划，这里姑且直接使用默认值。
-l 0.0006 将最大学习率设置为 6e-4。根据 GPT-3 论文的解释，Karpathy 这个大小的模型应当使用 2e-4，但这里 Karpathy 将其增加至三倍，似乎训练速度更快且没有引发任何问题。这项参与未经认真调整。
-q 0.1 代表在训练过程中，将学习率衰减至最大 LR 的 10%，取值参考自 GPT-3 论文。
-u 700 表示将在前 700 次迭代中将学习率从 0 提升至最大，总批次大小为 0.5M 时对应 3.5 亿个 token，取值同样来自 GPT-3 论文。
-n 2000 要求每 2000 步保存一次模型检查点。
-x 32000 要求总共 32K 步。之所以选择这个数字是因为其好读好记，而且正好对应 24 个小时。
-ge 1 为 CublasLt 设置最近合并的 gelu 重新计算设置（可选）。
-y 1 用于将“恢复”标记设置为开启。如果训练因任何原因而崩溃或者挂起，则可按下 CTRL+C 并重新运行此命令，其将尝试恢复优化。Llm.c 具备按 bit 确定性，因此大家将获得与崩溃之前完全相同的结果。
-e "d48" 要求从头开始初始化深度为 48 的 GPT-2 模型。
大多数朋友面临的最大限制，可能就是自己的 GPU 内存达不到 80 GB。Karpathy 表示，“没关系，只要有耐心，之前提到的这些任务也都能顺利运行完成，只是速度会稍慢一些。”
但如果模型实在太大，又该如何处理？Karpathy 表示，最重要的是调整微批次大小 -b，尝试将其缩小并保持在合适的水平。例如 16 -> 8 -> 4 -> 2 -> 1。以此为基础，尝试使用重新计算设置 -r，即 0（最快，但占用的内存最大）、1（速度慢得多，但可以节约大量内存）或者 2（稍慢一些，但内存节约量较少）。
下一步优化思路则是禁用 fp32 中的主权重，这里可怜请用 -w 0（默认值为 1）来执行此操作。Karpathy 并没有为参数维护 fp32 副本，因为根据经验，之前的几次运行都没有问题，可能是因为使用了随机舍入。
“但如果大家在亲自尝试时遇到了问题（其实可能性极低），也可以使用 -t 减少最大序列长度，将默认值从 1024 下调至 512、256 等。但这意味着缩小了其最大注意力范围，所以模型的性能也会变得更差。”Karpathy 建议道。
代码“虽然我可能有点倾向性，但 llm.c 真的非常优雅”Karpathy 介绍道：
它只需要基本 CUDA 依赖即可运行。
它是 C/CUDA 中最直接、最小且可读的实现。llm.c 总计约有 5000 行 C/CUDA 代码。Karpathy 主要尝试使用 C，而非 C++，以保持代码简洁。神经网络训练只是对单个浮点数组执行相同的简单算术运算（就是加减乘除）的一个 while 循环，实在没必要搞得太过复杂。
它的编译和运行速度极快（几秒钟内），因此可以执行更多步骤并减少等待时间。
它会在开始时一次性分配所有 GPU 内存，并在之后的训练期间将内存占用量保持恒定。因此只要执行步骤启动，我们就能保证接下来的运行状态始终良好、不会发生 OOM。
具备按 bit 确定性。运行效率很高，MFU 略低于约 50%。
主要入口点和大部分代码位于文件 tarin_gpt2.cu 当中。该文件包含 GPT-2 模型定义和约 2000 LOC 中的训练循环，并从 llmc 目录处导入了一大堆带有各种实用程序和各层实现的辅助文件。cloc llmc 报告了 23 个文件，3170 LOC，而 cloc train_gpt2.cu 目前为 1353 LOC。
如果您是位手握大量 GPU 的“土豪”，llm.c 也支持多节点训练。Karpathy 表示，其见过的 llm.c 训练最多支持约 500 张 GPU。
“个人迄今为止进行过最大的一次运行，是依靠 Lambda 全新一键集群功能上实现的，当时是在 2 个节点上使用了 16 张 H100 GPU。Lambda 团队提供了关于如何在其一键集群上训练 llm.c 模型的详细说明。例如在使用 512-GPU H100 集群时，每小时费用为 2300 美元，这时候整个 GPT-2 训练周期就仅为 30 分钟。当然，这时您需要增加总批次大小（例如增加到约 8M）并稍微调整一下超参数。我还没有尝试过，但相信会有效而且相当爽快！”Karpathy 说道。
PyTorch 比较使用 Karpathy 的并行 PyTorch 实现，与 PyTorch 的运行效果对比应该类似于以下形式：
torchrun --standalone --nproc_per_node=8 train_gpt2.py \--input_bin "dev/data/edu_fineweb100B/edu_fineweb_train_*.bin" \--input_val_bin "dev/data/edu_fineweb100B/edu_fineweb_val_*.bin" \--write_tensors 0 \--model d48 \--batch_size 8 --sequence_length 1024 --total_batch_size 1048576 \--dtype bfloat16 \--compile 1 \--tensorcores 1 \--flash 1 \--num_iterations 32000 \--warmup_iters 700 \--weight_decay 0.1 \--overfit_single_batch 0 \--learning_rate 0.0006 \--zero_stage 1
这里的 PyTorch 代码仅供参考，而非实际实现，因为其中的训练循环在某些位置可能略有不同（例如，数据加载器不会对分片进行置换等），总之大家看看就好。Karpathy 还将默认词汇大小修改为 50257 -> 50304 以提高效率。经过一夜运行，PyTorch 给出以下结果：
step 16/32000 | train loss 8.903997 | norm 8.3474 | lr 1.37e-05 | (3381.88 ms | 310057 tok/s)step 17/32000 | train loss 8.870140 | norm 3.7936 | lr 1.46e-05 | (3381.95 ms | 310051 tok/s)step 18/32000 | train loss 8.875732 | norm 9.4993 | lr 1.54e-05 | (3393.09 ms | 309033 tok/s)step 19/32000 | train loss 8.817432 | norm 2.8345 | lr 1.63e-05 | (3379.75 ms | 310253 tok/s)step 20/32000 | train loss 8.798056 | norm 4.1234 | lr 1.71e-05 | (3386.53 ms | 309631 tok/s)step 21/32000 | train loss 8.777574 | norm 2.8010 | lr 1.80e-05 | (3386.05 ms | 309675 tok/s)...
Karpathy 强调，这份 PyTorch 脚本可能还有很大的优化空间，但至少可以当作观察基准。PyTorch 占用的内存量似乎更大（此次运行约为 80 GB），而 llm.c 仅占用了 57 GB（节约比例为 29%）。内存资源非常重要，因为它能帮助我们容纳更大的训练批次（例如，llm.c 在这里可以将微批次提升至 24 个），从而加快训练速度。
其次，我们看到每次迭代大约为 3386 毫秒，而 llm.c 的迭代为 2750 毫秒，速度要快约 19%。
另外还有一些已知优势，例如 llm.c 包含启动反向传递的融合分类器等优化选项，据 Karpathy 所说，目前的 torch.compile 还做不到。但 Karpathy 表示，这样的性能差异可能是因为他的脚本没有充分调优，所以比较结果仅供大家看看、试试和作为调试思路的启发。
“我想表达的是，llm.c 的优化程度和速度水平已经相当不错，当然只是在 GPT-2/3 训练的特定场景之下。”Karpathy 说道。
最终模型感兴趣的朋友可以参考以下几条链接：
main.log文件。
model_00032000.bin llm.c bin 模型文件
我已经将模型转换为 huggingface transformers GPT-2 并上传至这里: karpathy/gpt2_1558M_final2_hf。
模型导出可以按如下方式进行，例如：
python dev/eval/export_hf.py --input log_gpt2_128M/model_00032000.bin --output gpt2_1558M_export之后大家可以运行 Eleuther 评估工具，或者运行 huggingface 采样管线以获取模型样本：
# take model for spinimport torchoutput = "./gpt2_1558M_final2_hf"# set pytorch seedstorch.manual_seed(42)torch.cuda.manual_seed(42)prompt = "In a shocking finding, scientist discovered a herd of unicorns living in a remote, previously unexplored valley, in the Andes Mountains. Even more surprising to the researchers was the fact that the unicorns spoke perfect English."from transformers import AutoModelForCausalLM, AutoTokenizertokenizer = AutoTokenizer.from_pretrained(output)model = AutoModelForCausalLM.from_pretrained(output, attn_implementation="flash_attention_2", torch_dtype=torch.bfloat16, device_map='cuda')model.eval()tokens = tokenizer.encode(prompt, return_tensors="pt")tokens = tokens.to('cuda')output = model.generate(tokens, max_new_tokens=500, pad_token_id=tokenizer.eos_token_id, do_sample=True, top_k=50, num_return_sequences=4)samples = tokenizer.batch_decode(output)for sample in samples:print('-'*30)print(sample)
另外大家也可以查看 dev/eval 以获取关于如何运行 Eleuther Evaluation Harness、HuggingFace Open LLM Leaderboard 的具体说明。
400B token 运行Karpathy 还尝试用远超 33B token 的规模训练了 GPT-2。具体来讲，Karpathy 将 -x 更改为 400000 以训练 420B token（规模甚至比 300B 的 GPT-3 还要大）。
结果显示，这套模型前半阶段运行得不错，但到大约 33 万步时开始出问题：这套模型在 HellaSwag 上全面碾压了 GPT-2 及同等体量的 GPT-3（最高性能优势可达约 61%），但遗憾的是之后新模型开始不稳定并发生崩溃。
在此过程中虽然也出现过一些较小的峰值，Karpathy 将代码配置为当检测到瞬时不稳定时跳过更新（使用了 -sl 5.0 -sg 5.0 标记），这有助于缓解并推迟问题的出现。但 Karpathy 承认，模型在初始化、激活范围和整体模型训练的稳定性方面还不够谨慎，对很多深层次问题也没有涉及。
这些问题会令模型逐渐变得不稳定，特别是对于规模较大、训练时间较长的模型更是如此。当然，我的实验仍在进行当中。如果大家对稳定模型训练有任何想法和建议，请在评论区中与我们分享。
常见问题解答 Q：我可以从 llm.c 中的模型里采样吗？A：也不是不行，但效率很低而且效果不好。如果大家想要提示模型，推荐使用前文提供的 huggingface 版本。
Q：我能跟它聊天吗？A：还不行，目前这个版本只完成了预训练，还没有接受过聊天微调。
Q：可以在 fp8 精度下训练吗？A：不行，我们目前主要是在 bf16 下训练，但早期版本正在尝试当中。
Q：我的 GPU 不是英伟达的，可以运行 llm.c 吗？A：不行，llm.c 目前仅支持 C/CUDA，但已经提供良好分支。比如 @anothonix 积极维护的 AMD 分叉（https://github.com/anthonix/llm.c）就相当不错。GPT-2(124M)。这里再贴一篇关于在 llm.c 中训练 GPT-2（124M）模型的老帖，其中包含与 llm.c 运行相关的更多信息。124M 属于 GPT-2 迷你系列中的小体量模型，只有 124M 个参数，远低于本文讨论的 1558M 参数。
结束语Karpathy 让我们看到了更多可能，但这似乎也难以意味着未来整个训练成本会下降。不久前，AI 初创公司 Anthropic 的首席执行官 Dario Amodei 就在采访中表示，目前 GPT-4o 这样的模型训练成本约为 1 亿美元，而目前其正在开发的 AI 大模型训练成本可能高达 10 亿美元。他还预计，未来三年内，AI 大模型的训练成本将上升至 100 亿美元甚至 1000 亿美元。
参考链接：
https://x.com/karpathy/status/1811488645175738409
https://github.com/karpathy/llm.c/discussions/677
点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！
今日好文推荐剥离几百万行代码，复制核心算法去美国？TikTok 最新回应来了
大厂期权归属前遭暴力裁员，80 余万期权泡汤；去哪儿宣布每周两天“不坐班”；萝卜快跑是人类远程代驾？客服：无人操控 | Q资讯
软件工程的兴衰轮回：2 年巨变，裁员风暴下小团队逆袭，老技术反迎第二春？