Smollm3: Smolで多言語対応の長文コンテキスト推論LLM

321日前原文(huggingface.co)

概要

SmolLM3 は、3Bパラメータ規模の高効率オープンソース言語モデル
Llama-3.2-3BやQwen2.5-3Bを上回り、4Bモデルとも競合可能な性能
11兆トークン による多段階事前学習と独自の効率化アーキテクチャ
長文対応・推論モード など多彩な機能と6言語マルチリンガル対応
全工程・データ配合・設計思想を完全公開し、再現性と発展性を重視

SmolLM3: 3B規模の効率特化・高性能オープンモデル

SmolLM3 は、3Bパラメータ規模で最高水準の性能を目指した完全オープンな言語モデル
Llama-3.2-3B や Qwen2.5-3B を上回り、Qwen3やGemma3など4Bモデルと肩を並べる競争力
ベースモデル と 推論対応Instructモデル を公開
- Base: https://hf.co/HuggingFaceTB/SmolLM3-3B-Base
- Instruct: https://hf.co/HuggingFaceTB/SmolLM3-3B
6言語 （英・仏・西・独・伊・葡）マルチリンガル対応
コンテキスト長128k 対応（NoPE, YaRN活用）

アーキテクチャと訓練手法

Transformerデコーダ アーキテクチャ＋埋め込み層共有
Grouped Query Attention(GQA) ：Multi-headより効率的、KVキャッシュ削減
NoPE （「RoPE to NoRoPE and Back Again」論文）：4層ごとにRoPE除去、長文性能向上
Intra-Document Masking ：異文書間の情報漏洩防止、長文学習安定化
Embedding層Weight Decay除去 ：OLMo 2方式で学習安定性向上
検証済みアブレーション ：各工夫が性能維持または向上を確認
訓練設定 ：
- バッチサイズ：2.36Mトークン（シーケンス長4096）
- 学習率：2e-4、AdamW（β1:0.9, β2:0.95）
- WSDスケジューラ、ウォームアップ2000ステップ、最終10%で線形減衰
- nanotron （訓練）、 datatrove （データ処理）、 lighteval （評価）
- H100 GPU 384枚で24日間 分散訓練

データ配合と多段階事前学習

3段階事前学習 （SmolLM2方式継承、11.2兆トークン使用）
- Stage 1 （0T→8T）：Web85%（多言語12%含）、Code12%、Math3%
- Stage 2 （8T→10T）：Web75%、Code15%、Math10%（高品質データ追加）
- Stage 3 （10T→11.1T）：Web63%、Code24%、Math13%（高品質データ増量）
データ詳細・配合比 はnanotron設定ファイルで公開
中間チェックポイント・訓練ログ も共有予定

ミッドトレーニング：長文・推論能力強化

長文対応訓練 ：
- 追加100Bトークンで4k→32k（RoPEθ=1.5M）、32k→64k（RoPEθ=5M）へ段階拡張
- コード・書籍・長文Webをアップサンプリング
- NoPE＋長文データ＋RoPE調整 で64kまで競争力、YaRNで128kまで拡張
推論能力訓練 ：
- OpenThoughts3-1.2M や Llama-Nemotron-Post-Training-Dataset-v1.1 などから35Bトークン
- ChatMLテンプレート とラップドパッキングで構造過多を回避
- 4エポック（約140Bトークン）訓練

ポストトレーニング：デュアルモード指示モデル構築

DeepSeek R1 や Qwen3 のような推論能力＋指示追従モデルを完全公開レシピで再現
Anchored Preference Optimization (APO) でアライメント調整
チャットテンプレート ：
- /think, /no_thinkフラグで推論・非推論モード切替
- 非推論時は空のthinkブロックを自動挿入（Qwen3類似）
- ツール呼び出し （XML/Python両対応）もテンプレートに明示
- システムメッセージ・メタデータを柔軟に切替可能
SFT（Supervised Finetuning） ：
- 推論・非推論両モードをバランス良く鍛えるデータ設計
- 1.8Bトークン （非推論1B、推論0.8B）、12種非推論・10種推論データセット
- 推論痕跡不足領域はQwen3-32Bを活用した合成データ生成で補完
- 数学・コード・一般推論・指示・多言語・ツール呼び出しを網羅

まとめ

SmolLM3 は、効率・拡張性・再現性・多様性を追求した3B規模の新基準モデル
全設計・訓練・データ配合・アライメント手法を公開、研究・応用・再現性に最適
小型モデルの限界拡張 と オープンAIコミュニティの発展 を牽引

Hackerたちの意見

小さい（3B）けど、ベンチマークでは素晴らしいパフォーマンスを発揮するよ。これはエッジやモバイル向けのモデルだから、gemma3-4bに対する利点はかなり大きい。デュアルモードの推論/非推論があって、フルトレーニングメソッドも公開されたんだ。

「SmolLM3をエンジニアリングブループリントと共にリリースします。アーキテクチャの詳細や、3段階の事前トレーニングアプローチでパフォーマンスを徐々に向上させるためのデータミックスの正確な情報、ハイブリッド推論モデルを構築するための方法論が含まれています。通常、これらの結果を達成するには数ヶ月のリバースエンジニアリングが必要ですが、今回はフルメソッドを提供します。」

https://web.archive.org/web/20250708164705/https://huggingfa...

どの小さいモデルが様々な企業データセットにファインチューニングするのに良いかな？うちのビジネスユニットは、RAGやクラウドリソースを使わずに、ブラウザやモバイルデバイスで小さいモデルを動かしたいって言ってるんだ。

└

自分で全部試して、ちゃんとしたベンチマークを持つ必要があるよ。機械学習は専門外だけど、Mistral 7Bを公式ガイドとツールセットに従ってファインチューニングしてみたけど、結果には満足できなかった。データセットからの特定の質問があって、どんなにファインチューニングしても正しい情報を返せなかったんだ。ベクトル検索とキーワード検索の組み合わせの方が、情報を学習させるよりも正しい質問の文脈を作るのにはまだ良いと思う。事前トレーニングされたデータセットアプローチを使ったけど、データセットを基にした合成質問と回答を作る方が良い結果が出るかもしれないけど、そのアプローチを試す時間がなかったんだ。

└

小さなモデルは知識を持つのが苦手だね。小さなモデルに知識をトレーニングするのは、あまり良い方法じゃないと思う。オフラインで埋め込まれたRAGシステムを作って、wasmとして展開できるようにするのもいいかも。これで成功してる人もいるみたいだよ。

└

こういう風にモデルをファインチューニングすることで、何を達成したいの？

└

Gemma 3N 2Bをファインチューニングしたけど、結構いい感じ。ただ、S23Uで読み込みが遅いんだよね。読み込んじゃえば問題ないけど。SmolVLM 256Mと500Mも試してみたけど、こっちは早く読み込めて、アセットに埋め込むこともできる。使い方さえ分かってればちゃんと動くよ。ただ、小さいモデルはパラメータが限られてるから、性能はあんまり良くないことを忘れないでね。それと、AndroidではJavaの圧縮問題で2GB以上のファイルを送れないから、モデルは別にダウンロードしなきゃいけない。ダウンロードフォルダからモデルを読み込むことはできなくて、アプリのフォルダにコピーしないといけないから、3.14GBのGemma 3N 2Bモデルだと、ユーザーのスマホに少なくとも7GBの空きスペースが必要になるよ。

3BレベルでほぼSOTAのパフォーマンスだね。完全な情報開示、コード、再現するためのレシピを提供する小さくて本当にオープンなモデルのクラブにとって、注目すべき追加だと思う。自分でトレーニングするには、だいたい100万ドル分のGPU時間がかかるみたい（4000 GPU/24日）。彼らの学びをシェアしてくれる素晴らしい記事だね。これはしっかりした、ポジティブな貢献だよ。

└

384のH100を24日間使って、コストは50万ドル以下だよ。

└

今朝、Phi-4-miniのベンチマークと照らし合わせるのに10分くらいかけたんだけど、リーダーがベンチマークに含まれてないのはおかしいし、全体的に遅れをとってる感じがした。ちなみに、私はLLMクライアントを開発してて、ローカルをクラウドとできるだけ近づけるのが重要なポイントなんだ。（llama.cpp経由で）マイクロソフト以外の企業は、ローカルAIを真剣に扱ってないのが現状だね。普段なら黙ってるところだけど、HFは素晴らしい存在だし、これが一回限りだとは思わない。でも、何ヶ月もローカルの最先端技術が無視されてるのを見て、業界にとっての神の恵みなのに、称賛がある一方でそれを無視するのは良くないと思う。だから、隠れるんじゃなくて、ちゃんと言うのが大事だと思うんだ。

ここにはイギリスのコメディスキットが潜んでるね。「それって小さな大きな言語モデルなの？」「ああ、そうだよ、すごく小さい。」「どうして同時に小さくて大きいの？」「大きな言語モデルの基準では小さいからだよ。」「じゃあ、大きいってこと？」「ああ、すごく大きい。」「何と比べて大きいの？」「小さな言語モデルと。」「じゃあ、ChatGPTみたいなのは、正確には何になるの？大きな大きな言語モデル？」「そう、まさにそれ。LLLMだよ。」

└

ビッグリトルプラネット、それともスモールビッグプラネット？

└

スタンダードも変わってきたよね。Gpt2は「大きい」とされてたけど、今はこれの半分のサイズだし。あと、サム・アルトマンがリリースするのは危険すぎるって言ってたし。今のところ、消費者向けハードウェアで動かせないくらい大きいものは「大きい」と考えてるけど、正確な定義を議論するのはちょっと無意味だよね。

└

ミニチュアの巨大宇宙ハムスターには手を出すな！

└

オーストラリア人だね。これはまさにクラークとドーウ / ユートピアそのものだ。

わあ、Qwen3の蒸留版に近いサイズで75%の大きさだね。素晴らしい！自分のファインチューニングにはsmollmのベースモデルを使ってるけど、品質が高いから、近い将来ローカルエージェントやコード補完に使うかもしれない。彼らのRLアルゴリズムは面白そうだね。今はOpenAIのアルゴリズムを使ってるけど、自分のコードがかなり古くなってるから、SOTAをチェックするつもりなんだ（この分野は進化が早いからびっくりだよね）。

アントンたち、いい仕事してるね！50-100Mパラメータのモデルを続けてほしいな。CPUでサクッと解決できるケースもあると思うし、LLMのテストケースに役立つかも。

聞いたところによると、llama3モデルはファインチューニングが結構簡単らしいけど（もし間違ってたら教えてね）、smollm3のファインチューニングはどれくらい簡単なの？MoE LLMはこの点で結構気まぐれなことが多いって聞いたけど。

自分たちのRLをモデルに適用しなかったのは面白いね。代わりに、大規模データセットの推論トレースを使ってファインチューニングしたり、より大きなモデルから推論トレースを生成したりしてるみたい。

└

確かに、オフライン手法のAnchored Preference Optimizationを選んだのは、Open R1プロジェクトで小さなモデルのマルチタスクRLをうまくやるのがかなり面倒だと分かったから。オフライン手法だと、データセットのキュレーションや生成にもっと集中できるし、それでもモデルのスケールに対しては早いイテレーションサイクルを提供してくれるよ！

llama.cppと他の推論エンジンのチャットテンプレートの問題を修正したよ！実行するには、次のコマンドを使ってね：./llama.cpp/llama-cli -hf unsloth/SmolLM3-3B-GGUF:Q4_K_XL --jinja -ngl 99

ハクソク