程式碼預訓練（Code Pretraining）

3 秒看懂

程式碼預訓練 = 用海量原始碼（+ 技術文件）作為主要語料，從零或繼續訓練語言模型，使其獲得”寫程式碼、讀程式碼、改程式碼”的原生能力。它是 Copilot、CodeLlama、DeepSeek-Coder 等 AI 程式設計助手的底座技術。

3 分鐘產業解釋

為什麼單獨訓練”程式碼”？

通用大型模型（GPT-4、Claude 等）已經能寫程式碼，但專業程式碼模型仍有獨立價值：

維度	通用模型	程式碼專用模型
訓練資料	網頁文本為主，程式碼佔比有限	程式碼佔比極高（預估 50%–90%+）
引數效率	需要更大型模型才能達到同等程式碼能力	同等程式碼任務下可更小、更便宜
部署場景	通常雲端端 API	可本地/私有化部署（程式碼敏感）
延遲要求	通用延遲	IDE 補全需極低延遲（<200ms）

商業邏輯：程式碼預訓練讓企業能用較小模型（7B–34B 引數量級）獲得接近大型模型的程式設計能力，降低推論成本、支援私有部署，滿足程式碼不出企業網路的需求。

產業鏈位置

算力層 ─→ 預訓練 ─→ 程式碼模型 ─→ 微調/對齊 ─→ 產品層
(晶片)    (程式碼資料)   (底座)     (RLHF/DPO)    (Copilot/IDE外掛)

程式碼預訓練處於模型底座環節，上游是算力與資料，下游是具體應用。

15 分鐘專家深入

核心技術棧

1. 資料工程——最關鍵的護城河

程式碼預訓練的質量高度依賴資料質量。典型資料管線包括：

原始程式碼倉庫（GitHub/GitLab）
    ↓
許可證過濾（保留寬鬆許可：MIT/Apache/BSD 等）
    ↓
質量過濾（去自動生成程式碼、去二進位制、去低星倉庫等）
    ↓
去重（檔案級 MinHash 去重 + 跨倉庫 near-dedup）
    ↓
程式語言平衡取樣（避免 Python 過度主導）
    ↓
格式化 + 拼接（補全倉庫結構資訊、新增檔案路徑標識）

關鍵細節：

許可證問題是法律紅線——GitHub 上大量程式碼採用 GPL 等傳染性許可，直接用於訓練存在法律風險
去重質量直接影響訓練效率——據 BigCode 專案估算，高質量去重可減少 30%–50% 重複資料
程式碼的”質量”難以定義——星標數、檔案長度、註釋比例等啟發式指標均有侷限

2. Tokenization 針對程式碼的最佳化

通用 BPE 分詞器對程式碼效率低（如縮排空格、括號、下劃線連線符等被切得很碎）。程式碼模型通常：

使用更大詞表（據各廠商公開資訊，32K–200K 不等）
保留空格/縮排的完整 token（Python 縮排語義關鍵）
將常見程式設計關鍵字、API 名稱設為獨立 token

3. 訓練目標

主流採用因果語言建模（Causal LM），即 next-token prediction：

\mathcal{L} = -\sum_{t=1}^{T} \log P(x_t | x_{<t}; \theta)

部分工作探索了：

Fill-in-the-Middle (FIM)：將程式碼切為 prefix + middle + suffix，訓練模型根據上下文補全中間部分。這對 IDE 補全場景更自然
多工混合：在程式碼語料中混入一定比例自然語言文本，保持通用語言能力

4. 架構選擇

程式碼預訓練沒有獨特的模型架構——主流仍是 Transformer decoder-only，與通用 LLM 相同。差異主要在：

上下文長度：程式碼場景需要長上下文（理解完整檔案、跨檔案依賴），主流模型支援 4K–128K tokens
位置編碼：長上下文場景多采用 RoPE 及其變體（NTK-aware scaling、YaRN 等）

技術原理

訓練流程示意

┌─────────────────────────────────────────────────────────────┐
│                    程式碼預訓練流程                              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌──────────┐    ┌───────────┐    ┌──────────────────┐     │
│  │ 程式碼語料  │───→│ Tokenizer │───→│  訓練資料集       │     │
│  │ (TB級)    │    │ (程式碼最佳化) │    │  (token序列)      │     │
│  └──────────┘    └───────────┘    └────────┬─────────┘     │
│                                            │               │
│                                            ↓               │
│                                 ┌──────────────────┐       │
│                                 │ Transformer LM   │       │
│                                 │ (Decoder-only)   │       │
│                                 │                  │       │
│                                 │ · 自注意力層      │       │
│                                 │ · FFN 層         │       │
│                                 │ · 位置編碼 (RoPE) │       │
│                                 └────────┬─────────┘       │
│                                          │                 │
│                                          ↓                 │
│                                 ┌──────────────────┐       │
│                                 │ 程式碼生成/補全/理解 │       │
│                                 └──────────────────┘       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Fill-in-the-Middle (FIM) 機制

原始程式碼:
def hello():
    print("world")

FIM 訓練格式:
 def hello():\n     \n<<|fim_middle|>> print("world")

訓練目標: 預測<|fim_middle|>部分

FIM 讓模型學會”雙向理解”程式碼上下文，而非僅從左到右生成，這對程式碼補全（游標位置在程式碼中間）場景至關重要。

上下文長度與視窗技術

程式碼檔案天然較長（單檔案可達數百行），跨檔案依賴更長。關鍵技術：

RoPE 長度外推：NTK-aware scaling、YaRN 等方法擴充套件訓練上下文
稀疏注意力：部分工作探索對長程式碼的高效注意力機制，但主流仍用標準注意力 + FlashAttention 加速

技術演進史

時間	里程碑	關鍵意義
2021.07	Codex（OpenAI）釋出	首次展示 LLM 程式碼能力，基於 GPT-3 微調，催生 GitHub Copilot
2022	CodeGen（Salesforce）開源	多語言程式碼生成，探索多輪訓練
2023.02	StarCoder（BigCode）開源	社群驅動，15B 引數，強調資料透明與許可證合規
2023.08	CodeLlama（Meta）開源	基於 Llama 2 微調，7B/13B/34B/70B 多規格，支援 FIM
2023.10	DeepSeek-Coder 釋出	國產程式碼模型代表，據公開 benchmark 表現優異
2024.02	StarCoder2 開源	改進資料質量，3B/7B/15B 規格
2024	DeepSeek-Coder-V2 釋出	引入 MoE 架構，更大引數但啟用引數可控

趨勢觀察：

從”閉源 API”到”開源可本地部署”——CodeLlama、StarCoder 系列推動了原生代碼助手普及
從”純程式碼”到”程式碼+自然語言混合”——更貼近實際開發（寫註釋、讀文件、寫 commit message）
從”單檔案”到”多檔案/倉庫級理解”——上下文長度持續擴充套件

技術路線對比

維度	路線 A：通用模型繼續訓練	路線 B：從零預訓練程式碼模型
代表	CodeLlama（Llama 2 → 程式碼）	StarCoder（純程式碼語料訓練）
資料需求	相對少（已在通用語料上學過語言）	大（需從頭學習語言+程式碼）
通用語言能力	保留較好	可能退化（除非混入自然語言）
訓練成本	較低（繼承預訓練權重）	較高
程式碼純粹性	仍受通用知識干擾	更專注於程式碼模式
主流選擇	✅ 目前主流（效率高）	用於特定場景或研究

量化參考（據公開 benchmark 公佈資料，非獨立復現）：

模型	引數量	HumanEval (pass@1)	MBPP (pass@1)	備註
Codex	~12B	~28%	-	早期基線
StarCoder	15B	~33%	~43%	開源社群
CodeLlama-34B	34B	~48%	~55%	Meta 開源
DeepSeek-Coder-33B	33B	~56%*	~65%*	*據官方報告
GPT-4 (通用)	未揭露	~67%*	~73%*	*據 OpenAI 報告

注：不同評估設定（是否含 CoT、取樣溫度等）會影響數值，跨論文比較需謹慎。

上下游

上游

┌─────────────────────────────────────────────────────┐
│                      上 遊                           │
├──────────┬──────────┬──────────┬─────────────────────┤
│   算力   │   資料   │  架構    │      基礎設施        │
├──────────┼──────────┼──────────┼─────────────────────┤
│ GPU/TPU  │ GitHub   │ PyTorch  │ 分散式訓練架構        │
│ (NVIDIA  │ GitLab   │          │ (DeepSpeed/Megatron) │
│  A100/H  │ Stack    │          │                      │
│ 100/TPU) │ Overflow │          │ 資料儲存/處理管線     │
└──────────┴──────────┴──────────┴─────────────────────┘

算力：程式碼預訓練對算力需求與通用 LLM 同級，通常需要數百到數千 GPU 訓練數週
資料：GitHub 是最大程式碼語料來源，但許可證問題是核心風險點
架構：與通用 LLM 訓練共用 PyTorch + 分散式架構

下游

┌─────────────────────────────────────────────────────┐
│                      下 遊                           │
├──────────┬──────────┬──────────┬─────────────────────┤
│ IDE 外掛 │ API 服務  │ 企業私有 │      垂直場景        │
│ (Copilot │ (雲端端呼叫 │ 部署     │                      │
│  Codeium)│  按量付費)│ (程式碼不出 │ 程式碼審計/安全掃描    │
│          │          │  企業網)  │ 測試生成/文件生成    │
└──────────┴──────────┴──────────┴─────────────────────┘

關鍵指標

模型能力評估

指標	含義	說明
HumanEval pass@1	164 道程式設計題，單次生成通過率	最廣泛使用的程式碼評估基準
MBPP	974 道基礎程式設計題	測試基礎程式設計能力
MultiPL-E	HumanEval 多語言擴充套件	覆蓋 C++/Java/JS/Rust 等
DS-1000	資料科學程式碼（NumPy/Pandas 等）	測試實際工程能力
CrossCodeEval	跨檔案程式碼補全	測試倉庫級理解

工程指標

指標	範圍	說明
訓練 token 數	數十億 – 數千億 tokens	程式碼模型通常訓練資料量較大
上下文長度	4K – 128K tokens	長上下文對程式碼理解關鍵
推論延遲	<200ms（IDE 補全場景）	即時補全的核心約束
模型大小	1B – 70B+ 引數	邊緣部署偏好 7B–13B

供需與市場資料

需求側

程式碼補全/生成已成為 AI 最具商業價值的應用場景之一。

GitHub Copilot 付費使用者資料公開報道已達數百萬級別（具體數字需參考 GitHub/Microsoft 最新財報）
企業需求驅動：私有化部署（程式碼安全）、定製化微調（內部程式碼庫）

供給側

供給側玩家	模型/產品	開源/閉源	模式
OpenAI	Codex → GPT-4 程式碼能力	閉源	API
GitHub (Microsoft)	Copilot	閉源	訂閱
Meta	CodeLlama	開源	免費
BigCode	StarCoder/StarCoder2	開源	免費
DeepSeek	DeepSeek-Coder	開源	免費+API
Codeium	自研模型	部分開源	免費/付費
Tabnine	自研模型	閉源	訂閱

市場規模：AI 程式碼工具市場處於快速增長期，據第三方行業報告估算，全球 AI 程式設計助手市場規模預計在 2020 年代末達到數十億美元量級（具體數字需參考最新行業報告）。

代表公司與資本對映

核心玩家

公司	產品/模型	融資/估值	關鍵優勢
GitHub (Microsoft)	Copilot	微軟子公司	與 VS Code/GitHub 深度整合，分發優勢
OpenAI	GPT-4 系列	~$80B+ 估值 [據公開報道]	模型能力領先
Codeium	Codeium	據公開報道已獲數億美元融資	免費策略獲客，企業版變現
Tabnine	Tabnine	據公開報道已獲融資	私有化部署，企業安全合規
Sourcegraph	Cody	據公開報道已獲融資	程式碼搜尋+AI 結合
DeepSeek (幻方量化)	DeepSeek-Coder	自有資金	國產開源代表，價效比

資本對映邏輯

程式碼預訓練投資主線：

1. 工具層：Copilot 類產品（訂閱模式，高粘性）
   → 關注：GitHub（微軟）、Codeium、Tabnine

2. 模型層：開原始碼模型（生態卡位）
   → 關注：Meta（CodeLlama）、DeepSeek

3. 資料層：高質量程式碼資料集（稀缺資源）
   → 關注：資料合規、許可證管理能力

4. 應用層：程式碼安全、測試生成、文件生成
   → 關注：垂直場景 AI 工具創業公司

投資邏輯

核心判斷

1. 程式碼是 AI 最容易變現的場景之一

開發者付費意願高（工具節省時間，ROI 直觀）
訂閱模式粘性強（習慣形成後遷移成本高）
企業預算明確（開發者工具採購）

2. 開源 vs 閉源的博弈

開源模型（CodeLlama、DeepSeek-Coder）持續逼近閉源能力
企業私有部署需求利好開源生態
但閉源在最新能力上仍保持領先（GPT-4 級別）

3. 關注邊際變化

上下文長度擴充套件：能否理解完整倉庫是差異化關鍵
多模態程式碼：圖表/UI → 程式碼的生成能力
Agent 化：程式碼模型從”補全”走向”自主開發”

風險提示

法律風險：程式碼版權訴訟（GitHub Copilot 已面臨相關訴訟）
模型同質化：開源模型能力趨近，差異化空間收窄
使用者遷移成本低：IDE 外掛切換成本相對低

常見誤讀糾偏

❌ 誤讀 1：“程式碼預訓練需要用全新的 Transformer 架構”

✅ 糾正：程式碼預訓練使用的是與通用 LLM 完全相同的 Transformer decoder-only 架構。差異在資料（程式碼語料為主）和 Tokenizer（針對程式碼最佳化），而非架構本身。所謂”程式碼專用架構”的嘗試（如 Graph Neural Network + Transformer 混合）尚未成為主流。

❌ 誤讀 2：“程式碼模型越大越好，必須百億引數以上”

✅ 糾正：對於 IDE 即時補全場景，7B–13B 引數模型 + 量化 + 最佳化推論 是主流部署選擇。34B+ 模型更適合複雜程式碼生成/審查，但推論成本和延遲更高。小模型在特定場景（如單一語言補全）可能更具價效比。

❌ 誤讀 3：“HumanEval 高分 = 好用的程式碼助手”

✅ 糾正：HumanEval 是孤立函式級評估，測試的是演算法題能力。實際程式碼助手需要：① 理解專案上下文；② 遵循程式碼風格；③ 跨檔案推論；④ 與使用者互動。HumanEval 分數與實際使用者體驗的相關性有限，需結合 CrossCodeEval、SWE-bench 等更貼近真實的評估。

❌ 誤讀 4：“程式碼預訓練的語料越多越好”

✅ 糾正：資料質量遠比數量重要。重複、低質量、自動生成的程式碼會降低訓練效果。BigCode 專案的實踐表明，精心去重和過濾後的資料集（遠小於原始爬取量）訓練效果更好。盲目擴大語料規模可能引入噪聲。

學習路徑

入門（1–2 周）

概念理解：閱讀 OpenAI Codex 原始部落格（2021），理解程式碼預訓練的動機
動手體驗：使用 Hugging Face 上的 StarCoder/CodeLlama，體驗程式碼生成
評估入門：跑一次 HumanEval 評估指令碼，理解 pass@1 的含義

進階（1–2 月）

資料工程：研究 BigCode 專案的資料處理管線（The Stack 資料集文件）
訓練實操：用 DeepSpeed/Megatron 在小規模資料上預訓練程式碼模型（驗證流程）
論文精讀：StarCoder、CodeLlama、DeepSeek-Coder 的技術報告

專家（持續）

前沿追蹤：關注 SWE-bench（真實 GitHub issue 修復評估）、CrossCodeEval（跨檔案理解）
領域融合：程式碼 + 安全（漏洞檢測）、程式碼 + 測試（自動化測試生成）
產業分析：追蹤 Copilot 商業化進展、企業採購趨勢

一句話總結

程式碼預訓練是讓 AI “像程式設計師一樣思考”的底座技術——它不改變 Transformer 架構，而是通過精心構造的程式碼語料和針對性最佳化，使模型獲得高效的程式碼生成與理解能力，是當前 AI 最具商業變現潛力的應用方向之一。

延伸閱讀與來源

核心論文/技術報告

Codex: Chen et al., “Evaluating Large Language Models Trained on Code”, 2021 (OpenAI)
StarCoder: Li et al., “StarCoder: May the source be with you!”, 2023 (BigCode)
CodeLlama: Rozière et al., “Code Llama: Open Foundation Models for Code”, 2023 (Meta)
DeepSeek-Coder: Guo et al., “DeepSeek-Coder: When the Large Language Model Meets Programming”, 2024 (DeepSeek)
FIM: Bavarian et al., “Efficient Training of Language Models to Fill in the Middle”, 2022 (OpenAI)

評估基準

HumanEval: github.com/openai/human-eval
BigCode Bench: 更貼近真實場景的程式碼評估

資料集

The Stack: bigcode-project/the-stack (許可證過濾的程式碼資料集)
StarCoderData: bigcode-project/starcoderdata

行業報告（需查閱最新版本）

GitHub Universe 年度開發者報告
Stack Overflow Developer Survey
各投行 AI 程式設計工具行業分析（Goldman Sachs、Morgan Stanley 等）

本文件寫於 2025 年初，基於公開資訊整理。程式碼預訓練領域發展迅速，具體模型效能和市場資料請以最新公開揭露為準。