インドが全工程を自前で作った初のオープンソースLLM Sarvam 30B/105B
インドのAIスタートアップ Sarvam AI が2026年3月6日、Sarvam 30B と Sarvam 105B をオープンソースで公開した。特筆すべきは「インドで全工程を完結させた」という点で、事前学習・SFT・RLのすべてをインド国内の計算資源（IndiaAI missionが提供するインフラ）で行っている。
単なるファインチューニングや既存モデルの派生ではなく、アーキテクチャ・データ・推論スタックまでフルスタックで独自開発したモデルとしては、インド初の競合クラスの公開LLMになる。
モデル構成
両モデルとも、Mixture-of-Experts（MoE）トランスフォーマーをベースにしている。MoEはパラメータ数を増やしてもトークンあたりの計算量を一定に保てる設計で、推論コストを現実的な範囲に収めながらモデル容量を稼ぐ手法だ。
| 項目 | Sarvam 30B | Sarvam 105B |
|---|---|---|
| 総パラメータ | 30B | 105B |
| アクティブパラメータ | 2.4B | - |
| アテンション方式 | GQA | MLA |
| エキスパート数 | 128（スパース） | 128（スパース） |
| 事前学習トークン数 | 16T | 12T |
| 主な用途 | リアルタイム会話 | 複合推論・エージェント |
アテンション方式に注目すると、30BではGQA（Grouped Query Attention）を採用してKVキャッシュのメモリを削減し、105BではMLA（Multi-head Latent Attention）に踏み込んでいる。MLAはDeepSeekが採用した圧縮アテンション手法で、長文コンテキストでの推論メモリ要件をさらに下げる。
学習パイプラインの設計
事前学習データはコード・Web・数学・多言語コンテンツで構成される。特徴的な部分をいくつか挙げると、ルーティングスコアにsigmoid関数を使っていることが一つ。通常のMoEでよく使われるsoftmaxより、エキスパートの負荷分散が安定し、学習中のルーティング崩壊を起こしにくい。
RLパイプラインはasynchronous GRPOアーキテクチャで組まれている。GRPOとはGroup Relative Policy Optimizationの略で、生成・報酬計算・ポリシー更新を非同期で分離することで大規模MoEの学習スループットを確保する。KL正則化（参照モデルとのKLダイバージェンス）を意図的に省いているのも特徴で、報酬最大化と方針アンカリングの間の最適化上の衝突を避けるためだ。報酬シェーピングには「構造的な推論・簡潔な回答・正しいツール使用」を促すものを使い、reward collapseが観察されなかったと報告している。
SFTデータには、シミュレーション環境と実世界リポジトリから生成したエージェントトレースも大量に含まれており、ツール呼び出しや環境推論・多段階意思決定の能力を意図的に育てている。
ベンチマーク
Sarvam 105B
| ベンチマーク | Sarvam-105B | GPT-OSS-120B | Qwen3-Next-80B | GLM-4.5-Air |
|---|---|---|---|---|
| Math500 | 98.6 | 97.0 | 98.2 | 97.2 |
| LiveCodeBench v6 | 71.7 | 72.3 | 68.7 | 59.5 |
| MMLU | 90.6 | 90.0 | 90.0 | 87.3 |
| GPQA Diamond | 78.7 | 80.1 | 77.2 | 75.0 |
| BrowseComp | 49.5 | - | 38.0 | 21.3 |
| Tau2（平均） | 68.3 | 65.8 | 55.0 | 53.2 |
| AIME 25（ツールあり） | 88.3（96.7） | 90.0 | 87.8 | 83.3 |
BrowseComp（Webサーチを使うタスク）でのスコア49.5と、Tau2での68.3が目立つ。Tau2はエージェント的な長期推論・タスク完了を評価するベンチマークで、比較対象の中でトップだ。
現世代の大規模フロンティアモデルとの比較では、同クラス（~100B）の既成モデルに対して競合できるレベルに達している。Deepseek R1 0528（AIME25 87.5、HMMT Feb 82.5）と肩を並べており、BrowseCompでは3.2という同モデルのスコアを大きく上回る49.5を記録した。
Sarvam 30B
2.4B のアクティブパラメータという効率的な構成で、Math500 97.0・MMLU 85.1・AIME25 80.0（ツールで96.7）・LiveCodeBench 70.0 を達成。30B クラスとして国際的に競合できる水準に達している。
H100での実測スループットはQwen3ベースラインと比較して 3〜6倍 のスループット/GPU。L40Sでも 1.5〜3倍。MacBook Pro M3上のMXFP4混合精度推論でも20〜40%のトークン生成速度向上が確認されている。
インド言語対応とトークナイザー
対応言語はインド憲法第8附則の22指定言語と英語の計23言語。日本語・中国語・フランス語等は対象外で、汎用マルチリンガルモデルではない。公式が「インドのためのソブリンAI」と位置づけている通り、インド市場に特化したモデルだ。
インドには22の指定言語があり、12の異なる文字体系が存在する。Sarvamはこれら全言語に対応した独自トークナイザーを開発した。
評価指標は fertility score（1単語あたりの平均トークン数）で、低いほど効率的。Odia・Santali・Manipuri（Meitei）のような低リソース言語で特に他社トークナイザーより優位とされる。効率的なインド語トークン化は推論コストとレイテンシに直結するため、インド市場向けのデプロイメントでは実質的なコスト差になる。
インド語ベンチマークはLLM-as-judgeの手法で測定。Sarvam 105B は全評価次元での平均勝率90%、STEM・数学・コーディングでの勝率84%を記録。Sarvam 30B は全体89%・STEM等87%という結果だ。
公開形態
ウェイトはHugging Face（30B・105B）とインド製モデルハブの AI Kosh の双方で配布される。Transformers・vLLM・SGLangでの推論サンプル実装もHugging Faceページに用意されている。
Sarvam 30B は同社の会話エージェントプラットフォーム Samvaad に、Sarvam 105B は複合推論・エージェントワークフロー向けアシスタント Indus にそれぞれ本番導入済みだ。
ハードウェア要件とローカル実行
MoEモデルは「アクティブパラメータが少ないから軽い」と誤解されがちだが、推論時にはすべてのエキスパートのウェイトをメモリに載せる必要がある。アクティブパラメータ数が効くのは計算量（速度）であって、メモリ消費量は総パラメータ数に比例する。
ウェイトサイズと必要VRAM
| モデル | BF16ウェイト | コンテキスト長 |
|---|---|---|
| Sarvam 30B | 約60GB | 65,536トークン |
| Sarvam 105B | 約212GB | 128Kトークン |
上記はウェイトだけの数値で、実際の推論にはKVキャッシュやアクティベーション用のメモリが追加で必要になる。長いコンテキストを使うほどKVキャッシュの消費量が増える。
Sarvam 30Bの実行環境
30BはMoEの中では比較的軽量で、量子化すれば個人のGPUでも動かせる範囲に入る。
コミュニティがGGUF量子化版を公開しており、量子化レベルごとのファイルサイズは以下の通り。
| 量子化 | ファイルサイズ | 目安VRAM |
|---|---|---|
| BF16 | 約64GB | 64GB以上 |
| Q8_0 | 約34GB | 40GB以上 |
| Q6_K | 約26GB | 32GB |
| Q4_K_M | 約19GB | 24GB |
Q4_K_Mなら24GB VRAMのGPU（RTX 4090、RTX 5090等）1枚に収まる。Q6_Kでも32GB VRAMのRTX 5090なら全レイヤーをGPUにオフロード可能。
ただし、llama.cppへのsarvam_moeアーキテクチャ対応は2026年3月時点でまだ本体にマージされていない。PR #20275が進行中で、マージされるまではカスタムビルドのブランチからビルドする必要がある。Ollamaでの対応もllama.cppのマージ待ちの状態。
vLLMでの推論も公式サポートではなく、Sarvam AIのフォーク版か、hotpatch_vllm.pyによるパッチ適用が必要。SGLangではtp=2（2枚のGPUでテンソル並列）で動作するサンプルがHugging Faceページに掲載されている。
RTX 5090（32GB VRAM、CUDA 13.0）でQ8_0/Q6_K/Q4_K_Mの各量子化での推論が確認されている。
Sarvam 105Bの実行環境
105Bはウェイトだけで212GB（BF16）あるため、個人環境でのローカル実行は現実的ではない。
| 構成 | GPU |
|---|---|
| vLLM（公式サンプル） | tp=8（H100 80GB x8等） |
| SGLang（公式サンプル） | tp=4（A100 80GB x4等） |
GGUF版は2026年3月時点で公開されておらず、FP8 Dynamic版がRedHatAI等から提供されている程度。FP8でも約106GBのウェイトになるため、80GB VRAMのGPUが最低2枚必要。
個人が試すなら、クラウドのGPUインスタンスを借りるのが現実的な選択肢になる。RunPod・Lambda Labs・Vast.ai等でH100/A100マルチGPU構成を時間課金で利用できる。
個人で試すなら
現時点で個人が手元で試す最も現実的なルートは、Sarvam 30BのQ4_K_M量子化版をRTX 4090/5090で動かすパターン。ただしllama.cppのカスタムビルドが必要なので、ビルド環境（CMake、CUDA toolkit）の準備が前提になる。
# カスタムブランチからビルド
git clone -b add-sarvam-moe https://github.com/sumitchatterjee13/llama.cpp.git
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release
# 推論実行
./build/bin/llama-cli -m sarvam-30B-Q4_K_M.gguf -p "Hello" -n 512 -ngl 99llama.cppの本体マージとOllama対応が進めば、ollama run sarvam-30bで手軽に試せるようになるはず。PR #20275の動向を追っておくとよい。