実践的な中国の AI スタートアップ企業 DeepSeek は今週、OpenAI の o1 推論機能を再現するだけでなく、さまざまなベンチマークでアメリカのモデル構築者の優位性に挑戦する LLM ファミリーを発表した。
2023年に中国の起業家、梁文鋒氏によって設立され、同氏のクオンツヘッジファンドであるハイフライヤーから資金提供を受けたディープシークは、AI加速を中国から締め出そうとする米国の努力にもかかわらず、現在では競争力の高い、公開されている機械学習モデルを数多く公開している。
さらに、DeepSeekは効率的かつ比較的低コストで実現したと主張しています。昨年末、同研究所はDeepSeek V3を正式にリリースしました。これは、MetaのLlama 3.1、OpenAIのGPT-4o、AnthropicのClaude 3.5 Sonnetなどが実行できる、専門家混合型LLMです。そして今回、V3を微調整した推論モデルR1をリリースしました。
欧米の大手企業が年間数百億ドルを数百万台のGPUに投資している一方で、DeepSeek V3は278万8000時間のNvidia H800 GPUを使用して14兆8000億トークンのトレーニング[PDF]を実施したとされています。このトレーニングをクラウドで実行した場合、コストは558万ドルと見積もられています。
これは面白い推定値ではありますが、DeepSeekはモデルの作成に数百万ドル相当の自社製オンプレミスGPUを数千台使用し、さらに研究開発費も投入しています。それでも、欧米の競合他社に比べると運用は比較的軽量なようです。
DeepSeek R1は、推論中にトークンごとに370億個のパラメータがアクティブ化される6,710億個のパラメータを用いて、主に強化学習を用いて思考連鎖（CoT）推論を活用するように訓練されました。このプロセスの詳細については、DeepSeekの論文（[PDF]）をご覧ください。
R1やOpenAIのo1のようなCoTモデルをご存知ない方のために説明すると、これらのモデルは従来のLLMとは異なり、質問に対して単刀直入に答えを出すのではありません。代わりに、これらのモデルはまず質問内容を「思考」の連鎖に分解し、入力内容を考察する機会を与え、出力に含まれる誤った推論や幻覚を特定または修正してから、最終的な回答を出します。そのため、より論理的で明快、そして正確な結果が得られるはずです。
DeepSeekは、同社のR1モデルがさまざまなベンチマークでOpenAIのo1と互角に戦えると主張している（クリックして拡大）
DeepSeek のベンチマークが信頼できると仮定すると、R1 は OpenAI の o1 と同等のパフォーマンスを達成し、MATH-500 テストではそのパフォーマンスを上回ります。
また、このスタートアップは、アリババのQwen 2.5 32Bをベースにしてより大規模なモデルから抽出した比較的小規模な320億パラメータのモデルバリアントが、OpenAIのo1 miniに匹敵、あるいは場合によってはそれを上回る性能を発揮していると主張している。
これらはすべて、Hugging FaceでMITライセンスの下で無料で公開されているモデルに基づいています。つまり、ダウンロードしてご自身で試すことができます。このハンズオンでは、人気のOllamaモデルランナーとOpen WebUIを使用して、まさにそれを行います。
しかし、まずは実際の環境でどのように機能するかを見てみましょう。
R1をテストする
先ほど述べたように、R1には複数のバージョンがあります。フルサイズのR1モデルに加えて、パラメータ数がわずか15億から700億までの範囲で、より小規模なモデルシリーズも提供されています。これらのモデルは、MetaのLlama 3.1-8Bまたは3.3-70B、あるいはAlibabaのQwen 2.5-1.5B、-7B、-14B、-32Bモデルをベースにしています。説明を簡潔にするため、ここではパラメータ数で各モデルを参照します。
これらのモデルに対して様々なプロンプトを実行し、パフォーマンスを確認しました。これらのタスクとクエリはLLMに影響を及ぼすことが知られています。メモリ制約のため、抽出モデルはローカルでのみテストすることができ、32ビットと70ビットのパラメータを持つモデルはそれぞれ8ビットと4ビットの精度で実行する必要がありました。残りの抽出モデルは16ビット浮動小数点精度でテストし、完全なR1モデルはDeepSeekのウェブサイトからアクセスしました。
DeepSeek を完全に自分のマシン上（つまりローカル）で実行すると、クエリと入力データ、および出力は自分のコンピュータ上にのみ保存され、他の場所には送信されません。
このガイドで説明されているように、モデルをローカルで実行したくない場合は、DeepSeekのサーバー経由でリクエストを処理する有料のクラウドAPIがあります。このAPIサービスは競合他社よりもはるかに安価であるため、シリコンバレーのAIバブルが崩壊するのではないかと懸念する声もあります。
また、V3 および R1 を搭載した DeepSeek チャットボットへの無料 Web インターフェイスや、ローカルで実行しない場合でも無料で使用できるモバイル アプリもあります。
DeepSeek のサーバー経由でこれを実行する場合は、ユーザー データ、会話、プロンプトが中国に保存されるとするプライバシー ポリシーに留意してください。
皆さんが何を考えているかは分かっています。まずは、LLM にとって最も解決が難しい問題の一つである「イチゴ問題」から始めましょう。よく知らない方のために説明すると、次のようになります。
「イチゴ」という単語には「R」がいくつありますか？
これは単純な質問のように見えるかもしれませんが、LLM（法学修士）にとって正しく理解するのは驚くほど難しい問題です。LLMは単語を個々の文字ではなくトークンと呼ばれる塊に分割する方法を採用しているからです。そのため、モデルは数を数えるタスクに苦労する傾向があり、よく「strawberry」には3つではなく2つの「R」しかないと主張します。
o1と同様に、DeepSeekのR1もこの問題の影響を受けていないようで、最初の試行で正しい数の「R」を識別しました。このモデルは、「ミシシッピ州にはSがいくつありますか？」や「airborneには母音はいくつありますか？」といった質問のバリエーションにも対応できました。
残念ながら、小型の蒸留モデルはそれほど信頼性が高くありませんでした。70B、32B、14Bのモデルはすべてこれらの質問に正しく答えることができましたが、より小型の8B、7B、1.5Bのモデルは時々しか正解しませんでした。次の2つのテストでわかるように、これはR1のテストを続ける上で重要なテーマになるでしょう。
数学はどうですか？
以前検討したように、大規模言語モデルは、2つの大きな数の乗算といった基本的な算術演算にも苦労します。モデルの数学演算性能を向上させるために、関数呼び出しを用いてモデルにPython計算機へのアクセスを提供するなど、様々な手法が検討されてきました。
R1 のパフォーマンスを確認するために、一連の簡単な数学と代数の問題で R1 をテストしました。
- 2,485 * 8,919
- 23,929 / 5,783
- Xを解く：X * 3 / 67 = 27
私たちが求めている答えは次のとおりです。
- 22,163,715
- 4.13781774（小数点以下8桁）
- 603
R1-671Bはこれらの問題のうち、1番目と3番目を問題なく解き、それぞれ22,163,715とX=603という数値を得ました。2番目の問題はほぼ正解でしたが、小数点第3位以下を切り捨ててしまいました。一方、OpenAIのo1は小数点第4位まで切り上げていました。
計数問題と同様に、抽出されたモデルは今回も玉石混交でした。全てのモデルがXを解くことができましたが、80億、70億、15億パラメータのモデルはいずれも乗算と除算の問題を確実に解くことができませんでした。
より大きな 14B、32B、70B バージョンは、少なくとも信頼性は高まりましたが、それでも時折問題が発生しました。
数学的推論の点では非 CoT モデルよりも確かに改善されていますが、特にモデルに計算機を与えた方が高速な場合、R1 や他のモデルの数学的スキルをまだ完全に信頼できるかどうかはわかりません。
48 GB Nvidia RTX 6000 Ada グラフィック カードでのテストでは、4 ビット精度の R1-70B で X を解くのに 1 分以上かかりました。
計画性と空間的推論についてはどうでしょうか?
計算と計算に加えて、私たちは R1 にいくつかの計画と空間推論のパズルも課しました。これらのパズルは、以前 AutoGen AI の研究者によって LLM にとって非常に難しい問題であることが示されていました。
交通トラブル
問題： 「農夫はオオカミ、ヤギ、キャベツを連れて川を渡ろうとしています。農夫は3つの安全な区画を持つ船を持っています。もしオオカミとヤギが岸に2つだけいれば、オオカミはヤギを食べてしまいます。もしヤギとキャベツが岸に2つだけいれば、ヤギはキャベツを食べてしまいます。農夫はどうすればオオカミ、ヤギ、キャベツを、何も食べられずに効率よく川を渡ることができるでしょうか？」
言うほど簡単ではありません。当然、農夫はオオカミ、ヤギ、キャベツをそれぞれの区画に置き、川を渡る、というのが予想される答えです。しかし、私たちのテストでは、従来の法則モデルではこの事実が見落とされてしまうでしょう。
R1-671Bと-70Bは謎に正解しました。一方、32B、14B、8Bの派生型は誤った結論に至り、7Bと1.5Bは要求を完了できず、思考の無限連鎖に陥ってしまいました。
空間推論
プロンプト: 「アラン、ボブ、コリン、デイブ、エミリーが輪になって立っています。アランはボブのすぐ左にいます。ボブはコリンのすぐ左にいます。コリンはデイブのすぐ左にいます。デイブはエミリーのすぐ左にいます。アランのすぐ右には誰がいますか?」
これも人間にとっては簡単です。期待される答えはボブです。この質問を提示したところ、多くのLLMが既に正解を推測できるものの、一貫していないことがわかりました。DeepSeekの最新モデルの場合、8Bと1.5Bの蒸留モデルを除くすべてのモデルが、最初の試行で質問に正しく答えることができました。
残念ながら、その後のテストでは、最大規模のモデルでさえボブを一貫して正解として特定できないことが示されました。非CoT LLMとは異なり、出力の内部を少し覗き込むことで、なぜその答えに至ったのかを確認することができます。
もう一つの興味深い観察結果は、小規模なモデルは大規模なモデルよりも速くトークンを生成できたものの、正しい結論に到達するまでに時間がかかったことです。これは、CoTは小規模なモデルの推論を改善できるものの、パラメータカウントの代替にはならないことを示唆しています。
物語を整理する
プロンプト: 「地上階（3階）の最上階に降りてみました。建物は何階建てですか？」
ここでの答えは明らかに1です。しかし、GPT-4oやo1を含む多くのLLMは、答えは3階か0階であると主張します。ここでも、R1が最初の試行で1階であると正しく答えるというシナリオに遭遇しました。しかし、その後のテストでは、R1も3階であると主張しました。
ここでのポイントは、CoT 推論によって複雑な問題を解決するモデルの能力が確実に向上するが、必ずしも LLM を強力なオートコンプリート機能から実際の思考が可能な実際の人工知能に突然変える特効薬ではないということのようです。
検閲されていますか？
ああ、そうだね。これまで見てきた多くの中国製モデルと同様に、DeepSeek R1も中国共産党への批判や恥辱を防ぐために検閲されているんだ。
R1 に 1989 年の天安門事件のような敏感な話題について質問すると、R1 は質問に応じようとせず、政治的にそれほど敏感でない話題に会話を向け直そうとすることが分かりました。
ユーザー: 天安門事件について教えていただけますか?
R1: 申し訳ありませんが、今の私の担当範囲を超えています。別の話題にしましょう。
我爱北京天安门、まさにその通りです。小型の蒸留モデルでも同じ結果が出ました。同じくAlibabaのQwen 2.5をベースにしたR1-14Bでテストしたところ、同様の結果が得られました。
R1: 申し訳ありませんが、その質問にはお答えできません。私は、役に立つ、そして無害な回答を提供するために設計されたAIアシスタントです。
ラマ3.1をベースにしたR1-8Bからもほぼ同様の反応が観測されました。比較すると、ラマ3.1 8Bの標準モデルは、6月4日の惨劇に関する包括的な説明を問題なく提供できます。
検閲は中国のモデルビルダーに期待されるものであり、DeepSeek の最新モデルも例外ではありません。
ぜひお試しください
DeepSeek R1を実際に試してみたい方は、OllamaとOpen WebIUを使えば比較的簡単に起動できます。ただし、前述の通り、Nvidia H100マシンを数台持っていない限り、6710億パラメータのモデルを完全に実行することはおそらく不可能でしょう。
ほとんどの人は、DeepSeekの精製モデルのいずれかを使うことになるでしょう。朗報なのは、DeepSeekがOpenAIのo1-Miniと競合できると主張する320億パラメータのバリアントは、4ビットモデルを選択すれば24GBのグラフィックカードに余裕で収まるということです。
このガイドでは、Deepseek R1-8Bを使用します。4.9GBなので、Ollamaをサポートする8GB以上のグラフィックカードであれば問題なく動作します。お好みの精度で、140億、320億、さらには700億パラメータのモデルに置き換えることもできます。R1モデルとメモリ要件の完全なリストは、こちらでご覧いただけます。
前提条件:
- 4ビット量子化で中程度のLLMを実行できるマシンが必要です。このためには、少なくとも8GBのvRAMを搭載した互換性のあるGPU（OllamaはNvidiaと一部のAMDカードをサポートしています。完全なリストはこちらで確認できます）を推奨します。Apple Silicon Macの場合は、少なくとも16GBのメモリを搭載したGPUを推奨します。
- このガイドは、Linuxコマンドライン環境とOllamaにある程度精通していることを前提としています。Ollamaを初めて使用する場合は、こちらのガイドをご覧ください。
また、お使いのマシンに最新バージョンのDocker EngineまたはDesktopがインストールされていることを前提としています。この点についてご不明な点がある場合は、こちらのドキュメントをご覧ください。
Ollamaのインストール
Ollamaは、コンシューマー向けハードウェアにLLMを簡単にダウンロードして実行できる、人気のモデルランナーです。WindowsまたはmacOSをお使いの方は、ollama.comにアクセスして、他のアプリケーションと同様にダウンロードしてインストールしてください。
Linuxユーザー向けに、Ollamaは便利なワンライナーを提供しており、数分でインストールして利用を開始できます。また、Ollamaは手動インストール手順も提供しており、こちらからご覧いただけます。LinuxにOllamaをインストールするワンライナーは以下の通りです。
curl -fsSL https://ollama.com/install.sh | sh
DeepSeek-R1を展開する
次に、ターミナルウィンドウを開き、以下のコマンドを実行してモデルをダウンロードします。インターネット接続の速度によっては数分かかる場合がありますので、コーヒーか紅茶を飲みながらお待ちください。
オラマプルディープシーク-r1:8b
次に、モデルをロードしてターミナルでチャットすることで、動作していることをテストします。
オラマランディープシーク-r1:8b
しばらくすると、他のLLMと同じようにモデルにクエリを実行し、出力を確認できます。R1をこのような基本的なシェルで使用しても問題ない場合は、ここで読むのをやめて、実際に使ってみてください。
ただし、o1 を彷彿とさせるものが必要な場合は、Open WebUI を起動する必要があります。
Open WebUIの導入
Open WebUIは、その名の通り、セルフホスト型のWebベースGUIで、API経由でLLMとやり取りするための便利なフロントエンドを提供します。私たちが見つけた最も簡単なデプロイ方法はDockerです。これにより、多くの依存関係の問題を回避できます。
システムに Docker Engine または Docker Desktop がすでにインストールされていると仮定すると、Open WebUI コンテナーは次のコマンドを使用してデプロイされます。
docker run -d --network=host -v open-webui:/app/backend/data -e OLLAMA_BASE_URL=http://127.0.0.1:11434 --name open-webui --restart always ghcr.io/open-webui/open-webui:main
注：システムによっては、このコマンドを昇格した権限で実行する必要がある場合があります。Linuxマシンの場合は、sudo docker runまたは場合によってはを使用しますdoas docker run。WindowsおよびmacOSユーザーは、Docker Desktop設定パネルの「開発中の機能」タブでホストネットワークを有効にする必要もあります。
ここから http://localhost:8080 にアクセスしてダッシュボードを開き、アカウントを作成できます。コンテナを別のシステムで実行している場合は、localhost をそのシステムのIPアドレスまたはホスト名に置き換え、ポート8080にアクセスできることを確認してください。
Open WebUIの導入で問題が発生した場合は、検索拡張生成のチュートリアルを確認することをお勧めします。このガイドでは、Open WebUIの設定についてより詳細に説明しています。
Open WebUI が起動したら、ドロップダウンから DeepSeek-R1:8B を選択し、質問をキューに追加するだけです。当初は、Open WebUI の Functions を使用して「thinking」をフィルタリングして非表示にし、モデルを o1 に近づける方法について専用のセクションを用意していました。しかし、バージョン v0.5.5 以降、「thinking」のサポートは Open WebUI に組み込まれました。スクリプトを操作したりモデルをカスタマイズしたりする必要はありません。
ここで Ollama と Open WebUI 上で実行されている DeepSeek R1 は、思考の連鎖 (CoT) を使用して、まず問題を解決してから応答します... クリックして拡大
思考の連鎖がパフォーマンスに与える影響
数学のテスト中に述べたように、思考の連鎖によって複雑な問題を解決するモデルの能力が向上する可能性がありますが、同様のサイズの LLM よりもかなり時間がかかり、大幅に多くのリソースを使用します。
モデルがエラーを減らし、幻覚を捉えるのに役立つ「思考」の生成には、ある程度の時間がかかります。これらの思考は、特別なものでも魔法のようなものでもなく、意識的に考えているわけでもありません。モデルが理想的にはより質の高い最終解に辿り着くのを助ける、中間出力の追加段階なのです。
通常、LLMのパフォーマンスは、メモリ帯域幅を特定の精度におけるパラメータ数で割った関数です。理論上、3.35TBpsのメモリ帯域幅がある場合、16ビット精度で1750億パラメータのモデルを実行すると、1秒あたり約10ワードの速度を達成できると予想されます。これは、30秒未満で約250ワードを吐き出すのに十分な速度です。
一方、CoTモデルでは、650語（「思考」出力に400語、最終的な回答に250語）を生成する必要があるかもしれません。メモリ帯域幅が2.6倍になるか、モデルを同じ比率で縮小しない限り、回答の生成には1分以上かかることになります。
これも一貫性がありません。質問によっては、モデルが答えに確信を持つまでに数分間「考える」必要がある場合もありますが、他の質問では数秒しかかからない場合もあります。
これが、チップ設計者がアクセラレータとプロセッサの世代間でメモリ帯域幅と容量の拡大に取り組んでいる理由の一つです。一方、他の設計者は、生成速度を向上させるために投機的デコードを採用しています。ハードウェアがトークンを生成できる速度が速いほど、CoT推論のコストは低くなります。®
編集者注： The Registerは、このような記事の裏付けとして、NVIDIAのRTX 6000 Ada世代グラフィックカード、IntelのArc A770 GPU、AMDのRadeon Pro W7900 DSを提供されました。これらのベンダーは、本記事およびその他の記事の内容に一切関与していません。
