新規モデル · 2026.10.05
Xing4.0をローカルで実行：コーディングモデルの導入とGPU・メモリ選び
コーディング依頼を送る前に、全29Bモデルに必要なGPUとruntimeを選びます。
Xing4.0-29B-A4Bは総29Bのうちtoken1ごとに約4Bが活性化するMoE2エージェントモデルです。開発元は2026-09-17にBF163・FP84・GGUF5を公開したと記載し、Apache-2.0ライセンスとコーディング・tool use向けの経路を用意しています。活性4Bは重みを4B分だけ保存・読み込みすればよいという意味ではありません。公式vLLM例はtensor parallel6 2とcontext 256Kを使いますが、上流runtime7への対応PRは確認中とリポジトリに記載されています。
29Bモデルはtokenごとに約4Bのexpertを使います
Xing4.0-29B-A4Bはコードを読み、修正案を作り、tool call8を続けるために設計されたopen-weightエージェントモデルです。全体は約29Bパラメータで、MoE構造がtoken計算時に活性化するのは約4Bです。エージェントframeworkからコードやエラーログを渡すと、モデルが次の行動やコード応答を生成し、別のrunnerがtool callを実行します。開発元の公式モデルカード
ここでは一つの作業を通して見ます。repositoryの3ファイルを調べ、bugを確認するtestを実行し、変更点を説明します。モデルはtool callingとcontext 256Kに対応すると紹介されていますが、実際の作業にはコードrunner、repository権限、対応runtimeも必要です。benchmarkスコアだけでは、ファイル編集・test・変更取り消しを確実に実行できるとは判断できません。
活性4BからVRAMを計算しないでください
活性パラメータはtoken計算で選ばれるexpertの規模を示します。他のexpertをメモリから取り除くものではありません。全重みをBF16として単純計算すると29B×2 bytes≒58GBです。これは重みデータのおおよその量であり、実際のcheckpoint9容量や実行メモリを測定した値ではありません。KV cache10、runtime、作業用の余裕も必要です。
メモリ検討は精度と配布ファイルから始めます。公式repositoryには2026年9月17日にBF16、FP8、GGUFを公開したと記録されています。形式ごとにファイル容量は異なりますが、GGUFがあるだけで特定GPU11に収まるとは判断できません。選んだruntimeがarchitectureと量子化12ファイルの両方に対応しているか確認します。公式公開記録
| 数値 | 意味 | 機材検討での使い方 |
|---|---|---|
| 総29B | checkpoint全体のexpert・重み規模 | ファイル・メモリ条件を確認 |
| 活性約4B | token計算で選ばれるexpert規模 | tokenごとの計算量の理解に使う |
| BF16単純計算で約58GB | 29B×2 bytesで計算した重みデータ推定 | 実行最低メモリとして扱わない |
メモリを計画するとき全重みとtokenごとの計算量を分けます。
総29B
- 意味
- checkpoint全体のexpert・重み規模
- 機材検討での使い方
- ファイル・メモリ条件を確認
活性約4B
- 意味
- token計算で選ばれるexpert規模
- 機材検討での使い方
- tokenごとの計算量の理解に使う
BF16単純計算で約58GB
- 意味
- 29B×2 bytesで計算した重みデータ推定
- 機材検討での使い方
- 実行最低メモリとして扱わない
コーディングエージェントのスコアにはtoolと実行条件が含まれます
モデルカードはSWE-bench Verifiedで75.0を報告しています。開発元は`SWE-agent`、temperature 1.0、top_p 0.95、repetition penalty 1.05、context 210Kで評価したと記載しています。このスコアはrepository課題を解くagent評価であり、単一のコード補完応答やローカルtok/sとは異なる指標です。Xing4.0公式評価説明
Terminal-Bench 2.1のスコアは57.5です。カードによると`terminus-2`、temperature 0.8、top_p 0.95、repetition penalty 1.05、最大64K output token、課題ごとに24時間制限で3回実行した平均です。agent toolと長いtimeoutを含む評価であり、モデルが1行を書く速度を示すものではありません。自分のrepositoryでは編集の成功、test結果、許可したtool範囲を別に記録します。
| 評価 | 公開スコア | 主な条件 |
|---|---|---|
| SWE-bench Verified | 75.0 | SWE-agent、context 210K、temp 1.0。その他は公式カード参照 |
| Terminal-Bench 2.1 | 57.5 | terminus-2、最大64K出力、課題ごと24時間、3回平均 |
公式スコアは異なるコーディングagent評価の結果です。
SWE-bench Verified
- 公開スコア
- 75.0
- 主な条件
- SWE-agent、context 210K、temp 1.0。その他は公式カード参照
Terminal-Bench 2.1
- 公開スコア
- 57.5
- 主な条件
- terminus-2、最大64K出力、課題ごと24時間、3回平均
runtime対応はmerge前の経路を確認します
開発元repositoryはTransformersとvLLM・SGLang・KTransformersの設定を案内しています。同時に、2026-10-05確認時点でvLLM、SGLang、llama.cppなどへの上流対応pull requestはまだmerge前と記載しています。標準の最新版packageにXing対応が含まれていると仮定せず、公式repositoryが案内するPR branchまたは事前build済みcontainerを使います。公式実行経路とPR状況
コード実行権限はモデルとは分けて設定します。まず読み取り専用で始め、次にtest実行を追加し、diffを確認できる段階でファイル編集を許可します。agent frameworkがrepositoryとterminalを接続しても、モデル出力だけでcommandが自動実行されるか、途中に承認があるかを先に確認します。agentスコアは手元のtool権限の安全性や実repositoryでの修正成功を測るものではありません。
python -m venv .venv
source .venv/bin/activate
pip install -U torch transformers accelerate huggingface_hub
hf download XingChen-AGI/Xing4.0-29B-A4B公式Transformers例で短いコード質問を送ります
公式repositoryのTransformers例では`trust_remote_code=True`を指定してモデルを読み込みます。repository提供のモデルコードを使うため、公式モデルファイルを確認してから実行します。以下の例は質問を固定し、最大1,024 tokenを生成して読み込みと応答形式を短く確認します。実際のrepository作業では必要な説明やコード変更に合わせて出力上限を調整します。Xing公式Transformers quickstart
正常に実行されると、Python errorの短い説明がterminalに表示されます。未対応architectureのerrorではTransformersの対応状況を確認します。メモリ不足では、BF16重みだけの単純計算で約58GBになることに加え、contextとruntimeのメモリも考慮します。`max_new_tokens`を減らすと生成長は短くなりますが、重み読み込み時に発生したメモリ不足は解消しない場合があります。公式architectureと推論例
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer
model_id = "XingChen-AGI/Xing4.0-29B-A4B"
tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True)
model = AutoModelForCausalLM.from_pretrained(
model_id, trust_remote_code=True, device_map="auto", dtype=torch.bfloat16
)
messages = [{"role": "user", "content": "Explain this Python error and suggest a minimal fix: KeyError: 'id'"}]
prompt = tokenizer.apply_chat_template(
messages, tokenize=False, add_generation_prompt=True
)
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
with torch.inference_mode():
output = model.generate(
**inputs, do_sample=True, top_p=0.95, temperature=0.8,
repetition_penalty=1.05, max_new_tokens=1024
)
print(tokenizer.decode(
output[0][inputs.input_ids.shape[-1]:],
skip_special_tokens=False, spaces_between_special_tokens=False
))vLLMレシピはGPU 2枚と同時request数の制限を使います
開発元のvLLM例は`--tensor-parallel-size 2`、`--gpu-memory-utilization 0.90`、`--max-model-len 262144`、`--max-num-seqs 4`を指定します。これは2枚のGPUへ分割するserving経路で、最大4 sequenceを設定します。すべてのpromptに256Kを使うという意味ではなく、contextが長いほどKV cacheも増えます。使うprompt長と同時利用数を決め、その構成がメモリに収まるか確認します。公式vLLM commandと基本設定
開発元のKTransformers例はCPU13とGPUを併用するheterogeneous経路です。GPUに配置するexpert数とCPU推論threadも設定します。そのため「GPU 1枚で実行可能」とは、全重みがGPUメモリに収まるという意味ではなく、選んだruntimeが一部処理をCPUへ割り当てる場合があります。公式資料に正確な最低RAM14や推論速度はないため、実行環境で個別に測定します。
serverが起動すると、vLLM API15は`http://localhost:8000/v1`で応答します。起動時にarchitectureやparserのerrorが出たら、一般的なvLLM buildではなく、開発元のprebuilt imageまたはrepositoryが案内するPR branchを使っているか確認します。メモリ不足ではまずcontextと同時sequence数を減らし、GPU 2枚が認識されているか確認します。調整後の速度は直接試すまでは未測定です。公式vLLM設定と対応経路
| 経路 | 公開設定 | 追加確認事項 |
|---|---|---|
| Transformers | device_map=auto、BF16例 | 実際のメモリ配置と対応ハードウェア |
| vLLM | TP=2、最大context 256K、最大4 sequence | upstream PR未merge、公式PR branch/imageを使用 |
| KTransformers | CPU/GPU併用の設定例 | システムRAMと処理時間は未公開 |
公式serving経路の実行前提を比較します。
Transformers
- 公開設定
- device_map=auto、BF16例
- 追加確認事項
- 実際のメモリ配置と対応ハードウェア
vLLM
- 公開設定
- TP=2、最大context 256K、最大4 sequence
- 追加確認事項
- upstream PR未merge、公式PR branch/imageを使用
KTransformers
- 公開設定
- CPU/GPU併用の設定例
- 追加確認事項
- システムRAMと処理時間は未公開
小さなrepository作業で適性を判断します
Pythonの`KeyError: 'id'`への説明が出たら、次は小さなrepository bugを読み取り専用で調べます。再現commandと関連ファイルを渡し、実行するtestを提案するよう依頼します。agentにファイルを変更させる前に、回答のpath・原因・検証手順が合っているか確認します。その後、限定したdirectoryだけ編集を許可し、人がdiffとtest結果を読みます。
機材を選ぶときはcheckpoint保存領域、重みと入力を載せるメモリ、普段使うapp用の余裕を合わせて考えます。公式TP=2経路にはGPU 2枚とruntime環境が必要です。KTransformersのCPU/GPU併用構成はGPUメモリが足りない場合に他のメモリ資源を使いますが、完了時間は変わる可能性があります。このモデルが必須の作業でなければ、同じrepository issueをより小さなcoding modelでも試してから機材費を判断します。
用語の注釈
トークン — モデルが入力や出力を分けて処理する単位です。
本文に戻るMoE — 複数の専門家サブネットワークから入力に応じて一部を選ぶモデル構造です。総パラメータ数と1トークン処理時に有効な数は異なることがあります。
本文に戻るBF16 — モデルの数値を保存・計算する16ビット浮動小数点形式です。利用可否はハードウェアと実行環境によります。
本文に戻るFP8 — 8ビット浮動小数点形式の総称です。具体的な形式や対応範囲はハードウェアとソフトウェアによって異なります。
本文に戻るGGUF — モデル情報を格納するファイル形式で、llama.cpp系のツールで広く使われます。
本文に戻るテンソル並列 — モデルの層内の演算と重みを複数の装置に分割する方式です。装置間の通信も必要なため、高速化の度合いは接続と実装に左右されます。
本文に戻るランタイム — プログラムの実行時に必要な機能を提供するソフトウェア環境です。ローカルAIではモデル実行エンジンを指すこともあります。
本文に戻るツール呼び出し — ファイル読み取り、検索、コマンド実行などの外部機能を、名前と引数でモデルが要求する形式です。実行の有無はエージェントランタイムと権限設定が決めます。
本文に戻るチェックポイント — 学習済みモデルの重みなどを保存したファイルです。同じモデル系列でも、版や用途によって異なるチェックポイントを使うことがあります。
本文に戻るKVキャッシュ — 過去トークンのAttention用キー・バリューを保存し、後続トークン生成で再利用するメモリです。容量はコンテキスト長やバッチサイズで変わります。
本文に戻るGPU — 多くの計算を並列に処理するプロセッサーです。AIモデルの実行ではモデル計算を担います。
本文に戻る量子化 — モデルの数値を少ないビット数で表す方法です。メモリ使用量のほか、精度や実行速度も変わることがあり、影響は形式と実装によります。
本文に戻るCPU — コンピューターで汎用のプログラム命令を実行する中央処理装置です。AI処理ではGPUなど他のプロセッサーと役割を分けることがあります。
本文に戻るシステムRAM — プログラムの実行中にデータを一時保存するシステムメモリです。
本文に戻るAPI — 別のコードからプログラムの機能を呼び出すための決められたインターフェースです。
本文に戻る