Home 論文解説: Qwen2.5-Coder — 5.5兆トークンで学習したオープンソースコーディングLLMの設計と性能
投稿
キャンセル

📄 論文解説: Qwen2.5-Coder — 5.5兆トークンで学習したオープンソースコーディングLLMの設計と性能

本記事は Qwen2.5-Coder Technical Report の解説記事です。

論文概要(Abstract)

Qwen2.5-Coderは、Qwen2.5シリーズのコード特化モデルであり、1.5B・7B・32Bの3サイズで提供される。著者らの報告によれば、5.5兆トークンのコード関連データで学習し、32B-InstructバリアントはHumanEvalで92.7%(GPT-4oの90.2%を上回る)、SWE-bench Verifiedで36.0%を達成している。コード生成・コード推論・コード修正の各ベンチマークでオープンソースモデルのSOTAを達成しつつ、数学(MATH 80.7%)や一般言語タスク(MMLU 82.3%)の能力も維持している。

この記事は Zenn記事: Qwen3.5×RTX 3090でバイブコーディング環境を構築する実践ガイド の深掘りです。Zenn記事で扱うQwen3.5系列の前身であるQwen2.5-Coderの設計思想とコーディング性能を理解するための1次情報として解説します。

情報源

  • arXiv ID: 2409.12186
  • URL: https://arxiv.org/abs/2409.12186
  • 著者: Binyuan Hui, Jian Yang, Zeyu Cui, Jiaxi Yang, Dayiheng Liu 他(Alibaba Group / Qwen Team)
  • 発表年: 2024
  • 分野: cs.CL

背景と動機(Background & Motivation)

コード生成LLMは急速に進歩しているが、オープンソースモデルではプロプライエタリモデル(GPT-4o、Claude 3.5等)との性能差が課題だった。著者らは、データ品質とスケールの両面からこのギャップを埋めることを目指し、以下の戦略を採用している:

  1. 大規模コード特化学習: 5.5兆トークン(うちソースコード60%)の学習コーパス
  2. FIM(Fill-in-the-Middle)訓練: コード補完タスクへの対応
  3. リポジトリレベルコンテキスト: クロスファイルの依存関係理解
  4. 実行フィードバック付きRLHF: コード正当性のシグナルによる強化学習

主要な貢献(Key Contributions)

  • HumanEval 92.7%: 32B-Instructモデルが、GPT-4o(90.2%)を上回るオープンソース最高性能を達成
  • SWE-bench Verified 36.0%: 実際のGitHub Issue修正タスクでのオープンソース最高クラスの性能
  • 92言語対応: Python、JavaScript、Java、C/C++、Go、Rust、TypeScript他
  • 128Kコンテキスト: YaRNによる長コンテキスト拡張

技術的詳細(Technical Details)

モデルアーキテクチャ

Qwen2.5-Coderは、Qwen2.5ベースモデルのアーキテクチャをそのまま継承している:

コンポーネント詳細
ベースアーキテクチャTransformer Decoder
AttentionGQA(Grouped-Query Attention)
活性化関数SwiGLU
位置埋め込みRoPE + YaRN
正規化RMSNorm
語彙サイズ151,646
最大コンテキスト131,072 (128K)

32Bモデルの具体的な構成:

パラメータ
レイヤー数64
隠れ次元5120
Attentionヘッド数40
KVヘッド数(GQA)8
総パラメータ数32B

GQA(KVヘッド8個、Queryヘッド40個)を採用しており、KVキャッシュは標準MHAの1/5に削減されている。これはZenn記事で扱うRTX 3090でのVRAM効率化に直結する設計である。

学習データ構成(5.5兆トークン)

著者らの報告による学習データの内訳:

データカテゴリトークン数割合
ソースコード(GitHub、92言語)約3.3T60%
テキスト-コード関連(ドキュメント、Stack Overflow等)約1.1T20%
数学データ(STEM、推論)約0.55T10%
一般NLPデータ(多言語テキスト)約0.55T10%

データ品質管理の4段階パイプライン:

  1. 収集・重複除去: MinHash LSHによるファイルレベル重複除去 + SimHashによる類似重複除去
  2. 品質フィルタリング: 自動生成コード除外、長さフィルタ(100〜100,000文字)、構文ベースフィルタリング
  3. コード特化品質評価: FastText分類器によるコード品質スコアリング、教育的価値スコアリング
  4. データミキシング: 言語間の比率調整(低リソース言語のアップサンプリング)

FIM(Fill-in-the-Middle)訓練

FIM訓練はコード補完能力を獲得するための手法で、以下の2モードを同時に学習する:

PSM(Prefix-Suffix-Middle)モード:

1
<|fim_prefix|> [prefix] <|fim_suffix|> [suffix] <|fim_middle|> [middle]

SPM(Suffix-Prefix-Middle)モード:

1
<|fim_suffix|> [suffix] <|fim_prefix|> [prefix] <|fim_middle|> [middle]

著者らは学習データの50%にFIM拡張を適用している。FIM訓練により、コード補完タスクで+15%(相対値)の性能向上が得られた一方、標準コード生成性能の低下は1%未満に抑えられたと報告されている。

リポジトリレベルコンテキストモデリング

単一ファイルだけでなく、リポジトリ内の複数ファイルを依存関係グラフに基づいて配置する:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
def pack_repository_files(
    repo_files: list[dict[str, str]],
    max_context: int = 131072,
) -> list[str]:
    """依存関係グラフに基づくリポジトリレベルパッキング

    Args:
        repo_files: ファイル名とコンテンツの辞書リスト
        max_context: 最大コンテキスト長(トークン数)

    Returns:
        パッキングされたテキストチャンクのリスト
    """
    # 1. import文を解析して依存関係グラフを構築
    dep_graph = build_dependency_graph(repo_files)

    # 2. トポロジカルソートで依存順に並べる
    # 依存されるファイル(ユーティリティ、型定義等)が先に来る
    sorted_files = topological_sort(dep_graph)

    # 3. コンテキストウィンドウにパッキング
    chunks = []
    current_chunk = ""
    for file_info in sorted_files:
        file_text = f"# File: {file_info['path']}\n{file_info['content']}\n"
        if len(tokenize(current_chunk + file_text)) > max_context:
            chunks.append(current_chunk)
            current_chunk = file_text
        else:
            current_chunk += file_text

    if current_chunk:
        chunks.append(current_chunk)

    return chunks

著者らの報告によれば、リポジトリレベルデータの導入により、CrossCodeEval(リポジトリレベル補完ベンチマーク)のスコアが約8%(絶対値)向上している。

命令チューニングとRLHF

SFT(Supervised Fine-Tuning): GPT-4やQwen2.5-72Bで生成した合成データ + 人手でキュレートしたコーディングQ&Aデータを使用。Rejection SamplingとEvol-Instruct方式のデータ拡張を適用。

RLHF: 2段階で実施。

  1. コード正当性・スタイル・有用性に関する人間の選好データで報酬モデルを学習
  2. GRPO(Group Relative Policy Optimization)で方策を最適化。コードサンドボックスでの実行フィードバックを使用

GRPOの目的関数は以下の通り(DeepSeek-V2と同様の手法):

\[\mathcal{J}_{GRPO}(\theta) = \mathbb{E}_{q, \{o_i\}_{i=1}^G} \left[ \frac{1}{G} \sum_{i=1}^G \min\left(\frac{\pi_\theta(o_i|q)}{\pi_{\theta_{old}}(o_i|q)} \hat{A}_i, \text{clip}(\cdot, 1-\epsilon, 1+\epsilon) \hat{A}_i\right) \right]\]

ここで、

  • $G$: グループサイズ(同一質問に対する出力サンプル数)
  • $\hat{A}_i = (r_i - \text{mean}({r_j})) / \text{std}({r_j})$: グループ内相対アドバンテージ
  • 別途クリティックモデルが不要なPPOの効率的変形

実装のポイント(Implementation)

RTX 3090での実行: Qwen2.5-Coder-32Bは、Q4_K_M量子化で約18GBのVRAMに収まり、RTX 3090(24GB)で動作可能。Zenn記事ではQwen3.5-35B-A3B(MoE)を推奨しているが、Qwen2.5-Coder-32B(Dense)も代替選択肢として有力である。

Denseモデルとしてのトレードオフ: Qwen2.5-Coder-32BはDenseモデルであるため、推論速度はMoEモデルのQwen3.5-35B-A3B(アクティブ3B)より遅い。Zenn記事の速度比較(約31 tok/s vs 約80-110 tok/s)がこの差を示している。

FIM対応の実用性: Continue.devやAiderでのコード補完(タブ補完)はFIM対応モデルで品質が向上する。Qwen2.5-Coderは50%のFIM訓練率で設計されているため、ローカルLLMでのコード補完に適している。

128Kコンテキスト: YaRNによる128K対応は、リポジトリ全体をコンテキストに含めたい場合に有用だが、RTX 3090のVRAM制約上、Denseモデルでは131Kコンテキストで約24GBに達するため、実質的な上限は65K程度となる。

実験結果(Results)

主要ベンチマーク比較(32B Instruct)

論文のTable相当のデータより:

ベンチマークQwen2.5-Coder-32B-InstGPT-4oDeepSeek-Coder-V2-InstCodestral-22B
HumanEval92.7%90.2%81.1%81.1%
MBPP+79.1%74.1%72.0%68.5%
LiveCodeBench43.0%43.1%43.2%26.4%
SWE-bench Verified36.0%~35%--
CruxEval-O66.2%65.0%60.0%-
MultiPL-E (92言語平均)75.1%72.0%72.6%68.2%
MATH80.7%74.6%75.7%-

モデルサイズ別のHumanEvalスコア

モデルHumanEval (pass@1)
Qwen2.5-Coder-1.5B61.0%
Qwen2.5-Coder-7B84.1%
Qwen2.5-Coder-32B90.2%
Qwen2.5-Coder-32B-Instruct92.7%

一般能力の維持

著者らは、コード特化学習によって一般言語能力が損なわれていないことを報告している:

ベンチマークQwen2.5-Coder-32B
MATH80.7%
GSM8K91.4%
MMLU82.3%

10%の数学データと10%の一般NLPデータの混合が、これらの能力維持に重要であることがアブレーション実験で確認されている。

実運用への応用(Practical Applications)

Qwen3.5との関係: Qwen2.5-Coderの設計思想(5.5Tトークン学習、FIM訓練、リポジトリレベルコンテキスト)はQwen3.5系列にも引き継がれていると考えられる。Zenn記事で扱うQwen3.5-35B-A3Bのコーディング性能の基盤技術として理解することが重要である。

バイブコーディングでの使い分け: SWE-bench Verifiedのスコア(36.0%)は「エージェントスカフォールディング」を含む結果であり、Aider等のツールと組み合わせた場合の性能を示す。単独のコード生成ではHumanEval 92.7%が参考になるが、実際のバイブコーディングではツール統合後の性能が重要。

オフラインコスト: Qwen2.5-Coder-32Bをローカルで動かすと、API課金が不要になる。Zenn記事のコスト試算(RTX 3090で月$12 vs Claude API $50-200)は、この32Bモデルにも適用可能。

関連研究(Related Work)

  • DeepSeek-Coder-V2 (2024): DeepSeek系列のコードモデル。MoEアーキテクチャを採用しており、236Bパラメータでコーディング性能を向上。
  • CodeLlama (Rozière et al. 2023): Meta発のコード特化LLM。LLaMA 2をベースにコード特化学習を実施。Qwen2.5-Coderはデータ規模とFIM訓練でCodeLlamaを上回る。
  • StarCoder2 (Lozhkov et al. 2024): BigCodeプロジェクトのコードLLM。オープンなライセンスと学習データの透明性が特徴。
  • Codestral (Mistral AI 2024): Mistral AIのコード特化モデル。22Bパラメータだが、Qwen2.5-Coder-32Bとは各ベンチマークで差がある。

まとめと今後の展望

Qwen2.5-Coderは、5.5兆トークンの大規模コード特化学習、FIM訓練、リポジトリレベルコンテキストモデリング、実行フィードバック付きRLHFの組み合わせにより、32BスケールでオープンソースSOTAを達成した。著者らの報告によれば、HumanEval 92.7%はGPT-4oを上回る水準である。

Zenn記事で扱うQwen3.5シリーズは、この設計思想をMoEアーキテクチャに拡張し、さらにマルチモーダル対応を加えたものであり、Qwen2.5-Coderのコード能力がその基盤となっている。

参考文献


:::message 本記事はarXiv論文 2409.12186 の解説記事です。論文の主張・実験結果を正確に伝えることを目的としており、筆者自身が実験を行ったものではありません。内容の正確性については原論文をご確認ください。 :::

この投稿は CC BY 4.0 でライセンスされています。

論文解説: PowerInfer — コンシューマGPUでLLM推論を最大11.69倍高速化するCPU-GPUハイブリッドエンジン

NVIDIA Tech Blog解説: CUDA GraphsによるLlama.cpp推論の最適化 — カーネル起動オーバーヘッドの削減手法