整理 | 核子可樂、褚杏娟
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.04
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt-get update
sudo 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 repo
git clone https://github.com/karpathy/llm.c.git
cd 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: 3115372800
allocated 2971 MiB for model parameters
batch_size B=16 * seq_len T=1024 * num_processes=8 and total_batch_size=1048576
=> setting grad_accum_steps=8
created directory: log_gpt2_1558M
allocating 40409 MiB for activations
val loss 11.129390
allocating 2971 MiB for parameter gradients
allocating 742 MiB for AdamW optimizer state m
allocating 742 MiB for AdamW optimizer state v
allocating 742 MiB for master copy of params
step 1/32000 | loss 11.133732 (+nanz)| norm 52.9732 (+nanz)| lr 8.57e-07 | 3056.36 ms | 42.6% bf16 MFU | 343080 tok/s
step 2/32000 | loss 10.539388 (+nanz)| norm 43.5996 (+nanz)| lr 1.71e-06 | 2747.19 ms | 47.4% bf16 MFU | 381690 tok/s
step 3/32000 | loss 9.894109 (+nanz)| norm 23.2229 (+nanz)| lr 2.57e-06 | 2753.25 ms | 47.3% bf16 MFU | 381259 tok/s
step 4/32000 | loss 9.566241 (+nanz)| norm 28.4920 (+nanz)| lr 3.43e-06 | 2741.47 ms | 47.5% bf16 MFU | 381690 tok/s
step 5/32000 | loss 9.482848 (+nanz)| norm 23.7817 (+nanz)| lr 4.29e-06 | 2752.07 ms | 47.3% bf16 MFU | 381507 tok/s
step 6/32000 | loss 9.332832 (+nanz)| norm 15.9113 (+nanz)| lr 5.14e-06 | 2751.01 ms | 47.3% bf16 MFU | 381431 tok/s
step 7/32000 | loss 9.165650 (+nanz)| norm 10.5941 (+nanz)| lr 6.00e-06 | 2753.03 ms | 47.3% bf16 MFU | 381327 tok/s
step 8/32000 | loss 9.132234 (+nanz)| norm 16.2733 (+nanz)| lr 6.86e-06 | 2748.91 ms | 47.3% bf16 MFU | 381348 tok/s
step 9/32000 | loss 9.097384 (+nanz)| norm 12.1342 (+nanz)| lr 7.71e-06 | 2748.73 ms | 47.3% bf16 MFU | 381367 tok/s
step 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 說道。
使用 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 spin
import torch
output = "./gpt2_1558M_final2_hf"
# set pytorch seeds
torch.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, AutoTokenizer
tokenizer = 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 的具體說明。
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
AIGC技術正以驚人的速度重塑著創新的邊界，InfoQ 首期《大模型領航者AIGC實踐案例集錦》電子書，深度對話30位國內頂尖大模型專家，洞悉大模型技術前沿與未來趨勢，精選10餘個行業一線實踐案例，全面展示大模型在多個垂直行業的應用成果，同時，揭秘全球熱門大模型效果，為創業者、開發者提供決策支援和選型參考。關注「AI前線」，回覆「領航者」免費獲取電子書。
在主題演講環節，我們已經邀請到了「蔚來創始人 李斌」，分享基於蔚來汽車 10 年來創新創業過程中的思考和實踐，聚焦 SmartEV 和 AI 結合的關鍵問題和解決之道。大會火熱報名中，7 月 31 日前可以享受 9 折優惠，單張門票節省 480 元（原價 4800 元），詳情可聯絡票務經理 13269078023 諮詢。