Xing4.0-29B-A4Bの名前で最も誤解しやすいのが「A4B」だ。
4Bだけ動くなら、8GBや16GB GPUで4Bモデルのように軽く扱えると思いたくなる。
公式モデルカードでは、Xing4.0-29B-A4Bは総29Bパラメータを持ち、各トークンで4Bを活性化するMoEモデルと説明されている。
ネイティブ256Kコンテキストに対応し、512Kまで拡張可能。Transformers、vLLM、SGLang、KTransformersなどの推論経路も案内されている。
重要なのは、計算に使うパラメータ数と、メモリへ保持する重みの量は別だという点だ。
A4Bは推論時の計算効率には効くが、29B分の専門家重みが消えるわけではない。
Xing4.0-29B-A4BはChina Telecom Artificial Intelligence Technologyが開発するXingシリーズのモデルで、旧TeleChat系列にあたる。
公式モデルカードではAIエージェント時代を意識した次世代モデルとして紹介されている。
アーキテクチャはMoEを採用し、総29Bのうち各トークンで約4Bを活性化する。
長文ではネイティブ256Kコンテキストを持ち、512Kまで拡張可能とされる。
公式配布はTransformers形式で、Hugging Face上のファイル総量は約62.4GB。
41個のSafetensorsへ分割されている。ライセンスはApache 2.0だ。
MoEでは複数の「専門家」ネットワークを用意し、入力トークンごとに一部だけを選んで計算する。
Xing4.0では総29Bのすべてを毎トークン計算するのではなく、約4Bが活性化される。
これによってDense 29Bより計算量を抑えられる可能性がある。
しかし、次のトークンで別の専門家が選ばれるため、推論環境は利用される可能性のある重みへアクセスできなければならない。
したがって「4B active＝4Bモデルと同じVRAM」は成立しない。
A4Bは主に演算量を理解する数字で、メモリ要件を見るときは総重み、量子化、KVキャッシュ、ランタイムを合わせて考える。
Denseモデルではほぼすべてのパラメータを各トークンで使う。
一方MoEはルーターが必要な専門家を選ぶため、1トークン当たりの計算量を減らせる。
しかし専門家の重み自体は保存される。
GPUだけに全量を置けない場合、CPU RAMへ一部を置く、複数GPUへ分散する、低ビット量子化するなどの工夫が必要になる。
MoEの「軽さ」は、モデルファイル容量の軽さではなく、同規模Denseモデルに比べた演算効率として理解すると誤解しにくい。
公式BF16系配布は約62.4GBある。
これを基準に単純換算すると、8bitなら重み部分は概ね半分、4bitならさらに半分へ近づく。
ただし実際のGGUF容量は量子化方式、メタデータ、埋め込み、非量子化テンソルによって変わる。
2026年9月25日時点で、公開する記事では実在するGGUFファイルのサイズを配布元ごとに再確認したい。
理論値を「公式Q4は○GB」と書くのは避ける。
この表は「動作保証表」ではない。
特に16GBではQ4のモデル重みが収まるように見えても、KVキャッシュや計算バッファが必要になるため、全量GPU配置が成立するとは限らない。
16GB GPUで最初に検討するのは低ビット量子化とCPUオフロードだ。
Q4相当でもモデルだけでVRAMを使い切る構成では、コンテキストを伸ばす余裕がない。
そのため一部のレイヤーや専門家をCPU RAMへ置き、GPUには頻繁に使う計算を担当させる構成が候補になる。
ただしPCIeをまたぐデータ移動が増えれば速度は落ちる。
16GBで「起動した」という報告と、毎秒十分なトークン数で長文を扱えることは分けて見る必要がある。
記事公開時にはGPU型番、RAM、量子化、コンテキスト長、tok/sが揃った実測を確認したい。
24GBになるとQ4系をGPUへ多く載せながらKVキャッシュの余白を取りやすくなる。
32GBではQ6やQ8に近い高精度量子化も検討しやすくなるが、実ファイル容量とランタイムのバッファを確認する必要がある。
ただしVRAMが増えても256Kコンテキストを無条件で使えるわけではない。
長い文脈はKVキャッシュを増やし、prefill時間も長くなる。
GPU購入を考えるなら「モデルが入る最小容量」ではなく、自分が常用する文脈長と速度を基準にする。
8K〜32K中心なら、最大256Kを前提にした過剰な構成は不要な場合もある。
CPUオフロードは、VRAMへ収まらない重みをシステムRAMへ逃がす方法だ。
これによって大きなモデルを小さなGPUでも実行できる可能性が広がる。
代償は速度だ。GPU内だけで処理する場合に比べ、CPU演算やPCIe転送がボトルネックになりやすい。
特にMoEでは専門家へのアクセス方法とランタイム最適化で結果が変わる。
Xing4.0の公式ページはKTransformersにも対応するとしている。
MoEをCPU/GPU混在で扱う場合、単純なレイヤーオフロードだけでなく、MoE向け最適化を持つランタイムも比較対象になる。
公式モデルカードの「native 256K」はモデルが扱えるコンテキスト能力を示す。
これは256Kトークンを一般的な16GB GPUで快適に使えるという意味ではない。
KVキャッシュは入力が長くなるほど増える。さらに256Kの文書を読み込むprefill処理自体にも時間がかかる。
ローカル運用では8K、32K、128K、256Kと段階的にメモリと速度を測る必要がある。
長文対応モデルを選ぶときは最大値だけでなく、自分が実際に必要とする長さを見る。
コードリポジトリや大量文書を丸ごと投入する用途でも、検索や分割処理を組み合わせた方が効率的な場合がある。
公式モデルカードではTransformers、vLLM、SGLang、KTransformersとの互換性が案内されている。
APIサーバーとして複数リクエストを処理するならvLLMやSGLangが有力だ。
KTransformersは大規模MoEをCPUとGPUへ分散する構成で比較したい。
一方、GGUFを使った個人PC運用ではllama.cpp系が候補になるが、Xing4.0アーキテクチャへの対応状況は利用時点の最新版を確認する必要がある。
新しいモデルでは、モデルカードに名前があるランタイムでも特定バージョンやtrust_remote_codeが必要になる場合がある。
導入前に公式Quickstartとissueを確認したい。
Xing4.0は複雑なエンジニアリングタスクやエージェント処理を重点領域としている。
ただし中国語・英語中心の公式ベンチから、日本語の文章品質や日本語指示によるコード修正能力をそのまま推定するのは難しい。
日本語利用では、指示理解、長文要約、コードコメント、ツール呼び出し、JSON形式維持などを分けて試すとよい。
量子化後は同じタスクをBF16または高精度版と比較する。
ローカルLLMではモデル選びだけでなく、チャットテンプレートや推論パラメータでも品質が変わる。
公式推奨設定を起点にし、温度などを揃えて比較したい。
公式Hugging FaceリポジトリではライセンスがApache 2.0と表示されている。
一般に商用利用、改変、再配布が可能なオープンソースライセンスだが、ライセンス本文の条件やNOTICE、特許条項を確認する必要がある。
派生GGUFを利用・再配布する場合は、元モデルだけでなく量子化配布者が付けた情報も確認する。
企業では使用したモデルのコミット、量子化方式、ランタイムのライセンスを記録しておくと管理しやすい。
また、モデルのライセンスが許容していても、生成物に含まれる第三者コードやデータの権利まで自動的に保証されるわけではない。
Xing4.0-29B-A4Bを見るとき、最も重要なのは「4B active」と「29B total」を分けることだ。
4Bは各トークンで活性化されるパラメータの規模であり、モデル全体が4Bサイズになるわけではない。
公式BF16配布は約62.4GB。
16GB GPUでローカル運用するなら低ビット量子化やCPUオフロードが候補になるが、Q4だから必ず快適とは言えない。
24GB、32GBとVRAMが増えるほど高精度量子化とKVキャッシュの余裕は増える。
256Kコンテキストも同じで、対応上限と実用長は別だ。
自分が必要とする8K、32Kなどの文脈で、実際のVRAM、RAM、tok/sを測る。
MoEモデルでは、この現実的な測り方がスペック表の「A4B」だけを見るより重要になる。
.png){kind=logo}
