#DeepSeekのパラドックスを解き明かす！なぜクラウドでは爆速激安なのにローカルでは高嶺の花なのか？🤔 #六01 #AI推論 #GPU効率 #MoEモデル　#2023DeepSeek_令和IT史ざっくり解説

DeepSeekのパラドックスを解き明かす！なぜクラウドでは爆速激安なのにローカルでは高嶺の花なのか？🤔 #AI推論 #GPU効率 #MoEモデル

最新AIモデルが抱える「効率」と「コスト」のジレンマに迫る

目次

はじめに：DeepSeek-V3の二つの顔

近年、人工知能、特に大規模言語モデル（LLM）の進化は目覚ましいものがありますね。まるでSFの世界が現実になったかのように、私たちの日々の生活に深く浸透し始めています。中でも、注目を集めているのがDeepSeek-V3のような次世代モデルです。

このDeepSeek-V3、提供元であるクラウドサービス上では「驚くほど高速で、しかも安価」という評判を耳にすることが多いですよね。まるで魔法のように、ユーザーのリクエストを瞬時に処理し、素晴らしいアウトプットを生成してくれます。しかし、一方で「いざ自分のPCで動かそうとすると、途方もなく高価で、しかも動きがとんでもなく遅い」という声も聞かれます。一体なぜこのような矛盾が起きるのでしょうか？

多くのAIモデルは、起動直後は少しもたつくのに、一度動き出すとサクサクと高速に応答する、という不思議な振る舞いをすることがあります。まるでウォーミングアップが必要なスポーツ選手のように。このような挙動の背後には、AI推論プロバイダーが常に直面している基本的なトレードオフ、すなわち「スループット（単位時間あたりに処理できる量）」と「レイテンシ（リクエストから応答までの時間）」の関係が潜んでいます。

今回の記事では、このDeepSeek-V3が持つ「二つの顔」の秘密、つまりクラウド上での効率性と、ローカル環境での非効率性について、その技術的な深層を掘り下げていきます。特に、AI推論の鍵を握る「バッチサイズ」の概念、DeepSeek-V3の採用する「Mixture of Experts（MoE）モデル」の特性、そして大規模モデルならではの「パイプライン処理の課題」に焦点を当てて解説していきましょう。読者の皆さんがAIモデルの裏側にあるロジックを理解し、AIの進化をより深く楽しめるようになることを願っています！

第1章：AI推論の舞台裏 – バッチ処理の魔法とGPUの秘密

なぜDeepSeek-V3のようなAIモデルが、クラウドでは高速かつ安価に動作するのでしょうか？その秘密は「バッチ推論」という技術にあります。これは、単一のユーザーリクエストではなく、数十、あるいは数百もの同時ユーザーリクエストをまとめて処理する手法です。

1.1 バッチ推論とは何か？なぜそれが高速なのか？

バッチ推論とは、簡単に言えば「複数の処理をまとめて一度に実行する」ことです。想像してみてください。あなたが郵便局で100通の手紙を送るとします。1通ずつ窓口に持っていくよりも、100通まとめて束にして渡す方が、手間も時間も省けますよね？AIモデルの推論もこれに似ています。

トランスフォーマーベースのLLM（大規模言語モデル）には、非常にユニークな特性があります。それは、同時に多数の処理をまとめて完了させることが、単一の処理を完了させるのとほぼ同じ速度で可能という点です。これは、AI推論の効率を劇的に向上させる「魔法」のようなものです。

1.2 GPUと行列乗算（GEMM）の強力な関係

この「魔法」の鍵を握るのが、おなじみGPU（Graphics Processing Unit、グラフィックス処理ユニット）です。GPUは、大量の並列計算、特に「大きな行列乗算（GEMM：General Matrix Multiplication）」を実行するのにとてつもなく得意です。AIモデルの計算のほとんどは、この行列乗算によって行われます。

具体的に見ていきましょう。モデルに単一のトークン（例えば「こんにちは」という単語を数値化したもの）を処理させたいとします。これは、そのトークンをモデルの内部表現（モデルの次元や隠れたサイズと呼ばれるベクトル）として表現し、モデルの膨大な重み（パラメータ）の行列と乗算する、という1つのGEMMとして実行されます。

しかし、もし10個のトークン（例えば、10人分のユーザーからのリクエストの最初のトークン）を同時に処理したい場合、それらを1つの大きな行列に積み重ねることができます。すると、GPUはそれを依然として1つの大きなGEMMとして処理することができるのです！これは、10個のわずかに小さいGEMMを個別に実行するよりも、はるかに高速かつ効率的です。なぜなら、GPUへの各コマンド発行にはオーバーヘッドがあり、また、新たな計算ごとにメモリから重みをフェッチするコストも発生するからです。小さなGEMMをたくさん実行すると、重みをメモリに出し入れする時間の方が、実際に計算する時間よりも長くなってしまい、ほとんどの時間を無駄にしてしまうことになります。

1.3 スループットとレイテンシのトレードオフ

AI推論サーバーの基本的な流れは以下のようになります。

  1. ユーザーからプロンプトを含むリクエストが届きます。
  2. そのプロンプトは前処理され（「プレフィル」と呼ばれます）、KVキャッシュと呼ばれる過去の情報と、次の予測トークンの基となるトークンサイズの行列（1 x モデルサイズ）が作成されます。2
  3. そのトークンサイズの行列は、サーバー内部のキューに並べられます。
  4. GPUサーバーは、このキューから一定数のリクエストをまとめて「バッチ」として引き出します（例えば128個）。それらを1つの大きな行列（128 x モデルサイズ）に積み重ね、フィードフォワードネットワークやアテンションレイヤーといったモデルの重みを通して一括で計算させます。
  5. 計算された結果は、128個の個別の予測トークンに分割されます。
  6. 元のリクエストに対応するトークンがユーザーにストリーミング（順次送信）されます。
  7. 生成されたトークンが文の終わりを示す「シーケンス終了トークン」でなければ、ステップ2に戻り、次のトークンの生成を続けます。

ここで重要なのは、サーバーがどれくらいの大きさのバッチサイズを引き出すかを決定できる、という点です。ここに「スループット」と「レイテンシ」の間の根本的なトレードオフが存在します。

  • 低レイテンシ（高速応答）を優先する場合: バッチ処理をせず、トークンを1つずつ（またはごく少数で）処理します。キューで待機するユーザーがいなくなるため、応答は速くなります（ただし、十分なGPUリソースがある場合に限ります）。しかし、GPUは非効率に稼働するため、単位時間あたりの処理量であるスループットは低下します。
  • 高スループットを優先する場合: 大量のバッチ処理を行います。ユーザーはバッチサイズが満たされるまでキューで待機するため、応答までのレイテンシは高くなります。しかし、GPUが効率的にフル稼働するため、はるかに高いスループットを実現できます。

多くの商用AI推論プロバイダーは、このバッチ処理を駆使することで、莫大な数のユーザーリクエストを効率的にさばき、低コストでサービスを提供しているのです。DeepSeekがクラウドで安価である理由の一端はここにあります。なぜなら、クラウドサービスでは世界中から大量のリクエストが常に押し寄せているため、GPUは常に大きなバッチで処理でき、高い稼働率と効率を維持できるからです。

コラム：AIの進化に驚いた日

私が初めて大規模言語モデルの出力を見た時の感動は忘れられません。まるでそこに知性があるかのような流暢な文章、質問に対する的確な返答。しかし、その裏でどれほどの計算が行われているのか、当時は想像もつきませんでした。この「バッチ処理」の仕組みを知った時、まるで工場が生産ラインを最適化するように、AIの脳みそであるGPUが効率を追求していることに深く感銘を受けました。私たちが普段何気なく利用しているAIサービスも、その裏ではこうした綿密な技術的最適化がなされていると考えると、ますますAIの奥深さに引き込まれるばかりです。

第2章：MoEモデルの真実 – DeepSeek-V3が高バッチサイズを求める理由

AIモデルには様々なアーキテクチャがありますが、DeepSeek-V3のような特定のモデルは、その構造上、より高いバッチサイズを必要とする傾向があります。その代表例が「Mixture of Experts（MoE）」モデルです。

2.1 Mixture of Experts（MoE）モデルとは？

Mixture of Experts（MoE）モデルは、文字通り「専門家の混合」という名前が示す通り、数百もの独立した「専門家（Expert）」と呼ばれるフィードフォワードネットワークのブロックを持つように訓練された強力なモデルアーキテクチャです。従来のLLMが単一の巨大なネットワークですべての計算を行うのに対し、MoEモデルでは、入力されたトークンやタスクに応じて、そのトークンを処理するのに最適な少数の専門家だけを選択し、そこにルーティング（振り分け）して計算を行います。これにより、モデル全体のパラメータ数は非常に大きくなるにもかかわらず、個々の推論に必要な計算量は大幅に削減され、効率的に大規模化できるとされています。

DeepSeek-V3や、かつてGoogleのSwitch Transformer、そして一部の推測ではオリジナルのGPT-4もこのMoEアーキテクチャを採用していると言われています。Qwen3のようなモデルもMoEの利点を活かしていますね。膨大な知識を持つ巨大な図書館に、専門分野ごとに分かれたたくさんの部屋があり、質問に応じて最適な専門書の部屋に案内されるようなイメージです。

2.2 なぜMoEはGPU効率が悪いのか？

一見すると効率的に見えるMoEモデルですが、実はその特性がGPUの非効率性につながる場合があります。その理由を紐解いていきましょう。

前述の通り、GPUは少数の非常に大きな行列乗算（GEMM）を実行するのが最も得意です。しかし、MoEモデルの場合、トークンが複数の専門家にルーティングされるため、結果として多くの小さな行列乗算を余儀なくされることになります。各専門家は、そこにルーティングされたトークンのみを処理するため、個々の専門家から見るとバッチサイズが小さくなってしまうのです。

例えば、5ms（ミリ秒）という短い「コレクションウィンドウ」（ユーザーリクエストを収集してバッチ処理する時間枠）で10件のユーザーリクエストを拾ったとしましょう。MoEモデルでは、これらの10トークンが異なる専門家にルーティングされる可能性があります。すると、一部の専門家は1つか2つのトークン（つまり、非常に小さなバッチサイズ）に対してしか計算を行わない、という状況が発生します。これでは、GPUが持つ巨大な計算能力を十分に活用できず、多くのGPUリソースがアイドル状態になってしまいます。

対照的に、200msといった長いコレクションウィンドウを設定し、4000ものトークンをバッチ処理するような場合を考えてみましょう。この場合、各専門家ははるかに多くのトークンを受け取ることになり、GEMMを大規模に実行する機会が増えます。これにより、GPUの利用効率が劇的に向上し、スループットも高まります。

したがって、MoEモデルは、その効率性を最大限に引き出すために、実用的なスループットを達成するには高いバッチサイズが必須となるわけです。これは、クラウドサービスのように常に膨大なユーザーリクエストが供給される環境では問題になりませんが、ローカル環境で単一ユーザーが利用する際には、この「高いバッチサイズ」を満たすことができず、GPUが非効率に稼働し、結果として推論が遅く、コストも高くなってしまう原因となるのです。

コラム：MoEモデルの「専門家」たち

MoEモデルの「専門家」という言葉を聞くと、私はまるでAIの中にたくさんのミニチュアのAIがいるような想像をします。それぞれの専門家が特定の知識分野やタスクに特化しているわけですね。例えば、「歴史の専門家」「科学の専門家」「文学の専門家」といった具合に。そして、入力された質問の内容に応じて、AI全体を統括する「ルーティングレイヤー」が「これは歴史の質問だから、歴史の専門家に任せよう！」と判断して、その質問を最適な専門家に振り分ける。こうすることで、AIは全体として膨大な知識を効率的に処理できるようになる、というわけです。しかし、この賢い仕組みも、GPUの物理的な特性である「大きなバッチでの計算が得意」という点と衝突すると、効率のジレンマを生む。AIの設計は、本当に奥深いものだと実感します。

第3章：パイプラインの謎 – 大規模モデルの効率化と「泡」の存在

DeepSeek-V3のような超大規模なモデルの場合、GPU効率の課題はMoEモデルの特性だけにとどまりません。モデルがあまりにも巨大なため、1つのGPUではメモリに収まらないことが多く、その推論プロセス自体を複数のGPUに分散させる「パイプライン並列化」という技術が不可欠になります。しかし、ここにもまた、効率性を阻害する「泡」の問題が潜んでいます。

3.1 モデルのパイプライン並列化

大規模言語モデルは、何百ものトランスフォーマー層、つまりフィードフォワードネットワークとアテンションメカニズムを組み合わせた計算ブロックで構成されています。これらの層は、膨大な数の重み行列（パラメータ）を持っています。もし、これらのすべての重みを1つのGPUに収めようとすると、GPUのメモリ容量をはるかに超えてしまいます。結果として、必要に応じてメモリから重みを頻繁に読み込み、計算後にまたメモリに書き戻す、といった「メモリ内外の重みスワップ」が頻繁に発生し、これが推論速度を著しく低下させる原因となります。

そこで用いられるのが「パイプライン並列化」です。これは、モデルの層をいくつかのグループに分割し、それぞれのグループを異なるGPUに割り当てる手法です。例えば、1番目のGPUが最初の10層を処理し、その出力を2番目のGPUに渡し、2番目のGPUが次の10層を処理する、といった具合に、あたかも工場での生産ラインのように処理を進めていきます。これにより、各GPUはモデル全体の一部だけをメモリに保持すればよく、メモリの制約を緩和し、大規模モデルの推論を可能にします。

推論中、各トークン（あるいは、効率のために通常は数十トークンの「マイクロバッチ」）は、このGPUのパイプラインを順番に通過していきます。まるでリレー走者のように、前のGPUから次のGPUへとデータが手渡されていくイメージです。

3.2 「パイプラインの泡」とは？なぜ避けられないのか？

パイプラインの効率は、モデルの層の数と「コレクションウィンドウ」のサイズに大きく依存します。前述の「ティック」と呼ばれるバッチ処理のサイクル中、最初のGPUがトークンの処理を開始すると、次のGPUはまだ何も処理するものがなくアイドル状態になります。同様に、最後のGPUが処理を終えると、最初のGPUは次の「ティック」が始まるまで待機することになります。これらのアイドル期間は、「ウォームアップ（warmup）」と「ドレイン（drain）」と呼ばれます。

もしコレクションウィンドウが非常に小さく、処理するトークンの数がモデルの層の数よりも少ない場合、いわゆる「パイプラインの泡（pipeline bubble）」が発生します。これは、GPUのパイプラインが十分に満たされず、アイドル状態のGPUがさらに増える現象です。例えるなら、生産ラインで十分な量の材料が供給されず、機械が空回りしているような状態です。事実上、「ドレイン」ステージが通常よりも早く開始されることになります。

パイプラインのウォームアップとドレインを完全に排除することはできません。なぜなら、推論は本質的に逐次的な「ティック」で動作する必要があるからです。しかし、推論プロバイダーは常に、このパイプラインの泡を避けるのに十分な長さにコレクションウィンドウを設定しようとします。パイプラインの泡はモデルのスループットにとって致命的な影響を与える可能性があるためです。この結果、多くの層を持つ大規模モデルには顕著なレイテンシの増加が伴います。つまり、泡を避けて効率を確保するためには、ユーザーはバッチが満たされるまで、より長く待つ必要がある、というわけです。

コラム：生産ラインの最適化とAI

私は以前、工場の生産ラインの効率化に関するドキュメンタリーを見たことがあります。そこでは、部品が一つ一つラインを流れていく中で、いかに無駄な時間をなくし、すべての工程で機械がフル稼働するかを追求していました。AIのパイプライン並列化も、まさにその考え方と同じなのだと、この記事を書きながら改めて感じています。特に「パイプラインの泡」という表現は、生産ラインで製品が途切れてしまう瞬間のように、GPUの資源が空回りしている状態を的確に表していると思います。AIの進化は、最先端の数学や計算機科学だけでなく、こうした古典的な効率化の知恵とも深く結びついているのだなと、感動を覚えました。

第4章：待機キューのジレンマ – なぜGPUを常にフル稼働できないのか？

これまでの章で、バッチ処理とパイプライン並列化がGPUの効率を高める一方で、なぜDeepSeekのような大規模モデルがローカル環境で非効率になるのか、その一端が見えてきました。しかし、推論プロバイダーがGPUのキューを常にトークンでいっぱいに保ち、ウォームアップやドレインのアイドル時間を完全に排除できないのはなぜでしょうか？つまり、固定された「ティック」を廃止して、トークンのマイクロバッチを途切れることなく流し続けることはできないのでしょうか？

理論上は、各ユーザーの推論は逐次的である必要があります（現在のトークンが生成されるまで次のトークンの生成を開始できないため）。しかし、大規模な推論プロバイダーであれば、キューを個別のユーザーリクエストでいっぱいに保つのに十分な同時トラフィックを常に持っているはずです。なのになぜ、それが完全に実現できないのでしょうか？

4.1 アテンションのバッチ処理の限界

正直なところ、この問いに対する完全な答えは複雑で、最新の研究でもまだ探求されています。しかし、最も大きな障壁の一つは、アテンションステップのバッチ処理の方法にあります。

トランスフォーマーモデルにおけるアテンションメカニズムは、シーケンス内の各トークンが、それ以前のすべてのトークンとの関係性を考慮して、次のトークンを予測するために行われる計算です。このアテンションの計算、特に内部で行われるGEMMをバッチ処理したい場合、全てのトークンが同じ形状（つまり、シーケンス内の以前のトークンの数が同じ）である必要があります。

たとえば、「こんにちは」というプロンプトと「これはペンです」というプロンプトの2つを同時に処理するとします。最初のトークンを予測する時点ではどちらも同じ形状ですが、それぞれが異なる長さのプロンプトを処理し、異なる数のトークンを生成していく過程では、各シーケンスの長さは刻々と変化します。そのため、単一のキューを維持して、あらゆる形状のトークンをまとめて処理するのではなく、同じ形状のグループだけを同時に実行する必要があります。これにより、バッチ処理が部分的にしか行えず、GPUが常にフル稼働するわけではなくなってしまうのです。

もちろん、この問題に対処するためのいくつかの研究は存在します（例えば、PyTorchのNestedTensorsのように、異なる長さのシーケンスを効率的にバッチ処理する試み）。しかし、私が確認した限りでは、これを完全に解決するための、もっと巧妙なトリックがまだ広く実装されているわけではないようです。

4.2 メモリオーバーヘッドと最適化の難しさ

もう一つのアイデアとして、「アテンションステップにティックが必要ならば、アテンションだけをティックベースのシステムにし、フィードフォワードネットワーク（FFN）の計算だけはより効率的な連続システムにしてみてはどうか？」という疑問が浮かびます。しかし、これにも課題があります。主にメモリオーバーヘッドの問題です。

  • アテンションの出力は、次のFFNの入力として必要になります。FFNのキューで処理されるのを待っている間、このアテンションの出力をメモリ内に一時的に保持する必要があります。しかし、このデータが膨大になると、すぐにメモリ容量の制約に直面してしまいます。
  • 最新の推論スタックでは、アテンションとFFNのステップを組み合わせて、1つの「操作」としていくつかの大きなGEMMを実行するように最適化されています。これらを異なるGPUで実行している場合（パイプライン並列化の場合）、各GPUは異なる操作を実行し、重みを頻繁にメモリに出し入れする必要が生じます。これもまた、効率を低下させる要因となります。

これらの技術的な障壁が、AI推論プロバイダーがGPUを常に100%フル稼働させ、アイドル時間を完全に排除することを困難にしているのです。特にローカル環境では、これらの問題を「単一ユーザー」という制約の中で解決する必要があるため、より一層の困難が伴うのです。

コラム：研究者たちの奮闘

AIの最先端を走る研究者たちは、まさにこれらの技術的なジレンマと日々格闘しています。論文を読むたびに、まるでパズルのピースを一つずつ埋めていくように、少しずつ効率化の道が切り開かれているのがわかります。例えば、アテンションのバッチ処理の限界という話を聞くと、「なるほど、そこにも複雑さがあるのか」と納得させられます。私たちが享受しているAIの恩恵は、こうした目に見えない地道な研究と、途方もない試行錯誤の積み重ねの上に成り立っているのだと、改めて感謝の念を抱きます。AIの進化の裏側には、常に知的好奇心と挑戦の精神が燃え盛っているのです。

第5章：結論と展望 – DeepSeek-V3の最適化とAIの未来

これまで、DeepSeek-V3がクラウドで安価かつ高速である一方で、ローカルでの実行が高価で遅くなる理由を、技術的な側面から詳細に掘り下げてきました。最後に、これまでの議論をまとめ、今後の展望について考察しましょう。

5.1 DeepSeekのローカル実行が高価で遅い真の理由

DeepSeek-V3のような大規模モデル、特にMoEアーキテクチャを採用しているモデルが、ローカル環境で実行される際に高価で遅くなる主な理由は、以下の要因の組み合わせに集約されます。

  • GPUの効率性: GPUは、単一の大きな行列乗算（GEMM）を効率的に処理するように設計されています。しかし、MoEモデルは、多数の小さな行列乗算を必要とします。ローカル環境で単一のユーザーが一度に1つの推論を実行する場合、バッチサイズが極めて小さくなり、GPUはその能力を十分に発揮できず、非効率に稼働してしまいます。
  • バッチサイズの依存性: 高いトークンスループットを得るためには、多数のトークン（異なるユーザーからのもの）を1つの大きな行列に積み重ねてバッチ処理する必要があります。DeepSeekのようなモデルは、高い効率を得るために大きなバッチサイズが必須であり、ローカル環境ではこのバッチサイズを満たすことができません。
  • パイプラインの泡の回避: 多数の層を持つ大規模モデルは、複数のGPUにわたるパイプライン並列化を必要とします。このパイプラインで「泡」の発生を避けるためには、各「ティック」（バッチ処理サイクル）により多くのトークンが含まれるよう、コレクションウィンドウを長くする必要があります。これにより、ローカル環境での推論において顕著なレイテンシ（遅延）が追加されます。
  • MoE専門家の飽和: MoEモデルでは、全ての専門家を効率的に活用し飽和させるために、より大きなグローバルバッチサイズが求められます。単一ユーザーのトラフィックではこれが難しく、多くの専門家がアイドル状態になるか、極めて非効率な小さなバッチでしか稼働できなくなります。

これらの理由から、DeepSeek-V3はクラウドサービスのように常に大量の同時トラフィックが供給される環境での高スループット運用に最適化されていると言えます。個人使用のためにローカルでDeepSeekを簡単に実行できないと一般的に言われるのは、まさにこれらの効率性の問題に起因しているのです。

5.2 OpenAIやAnthropicモデルが高速な理由の推測

では、OpenAIのChatGPTやAnthropicのClaudeなど、他の著名なAIモデルが迅速に応答するのはなぜでしょうか？これにはいくつかの可能性が考えられます。

  1. より効率的なアーキテクチャ: 彼らのモデルは、DeepSeek-V3とは異なるアーキテクチャを採用している可能性があります。例えば、Mixture of Expertsではない、より層の少ない、あるいは単一の巨大なネットワークである場合、MoE特有のGPU非効率性の問題に直面しないかもしれません。
  2. 推論最適化の巧妙なトリック: OpenAIやAnthropicは、モデルの推論を高速化するための、非常に高度で巧妙な独自の技術や最適化手法を開発している可能性があります。これは、公開されていない企業秘密の部分であり、例えば、バッチ処理の限界を突破するような革新的なスケジューリングアルゴリズムや、メモリ管理の最適化などが含まれるかもしれません。
  3. 惜しみないGPU投資: 彼らは、ユーザー体験を最優先するために、必要なGPUリソースをはるかに上回る莫大な投資を行い、潤沢なGPUクラスタを構築している可能性もあります。これにより、常に十分なGPUがアイドル状態で待機しており、バッチサイズが小さくても高い応答性を維持できているのかもしれません。これはコスト面で非常に高価な選択肢ですが、最先端のAIサービス提供者としてはあり得る戦略です。

AI推論の効率化は、現在も活発に研究開発が進められている分野です。今後、DeepSeekのようなMoEモデルのローカル実行効率を改善する技術や、GPU以外のハードウェアでの最適化、あるいはモデル自体の軽量化（量子化や蒸留など）が進むことで、より多くの人々が手軽に高性能なAIモデルを利用できるようになる日が来るかもしれません。

コラム：AIの未来に期待すること

AIの進化は、まるで技術者とユーザーの間で繰り広げられる知的な綱引きのようです。技術者はより高性能なモデルを目指し、それを効率的に提供する方法を模索する。ユーザーはより高速で安価なサービスを求め、さらにパーソナルな利用を望む。DeepSeekの事例は、この綱引きの現状を如実に示しています。しかし、このジレンマがあるからこそ、技術革新は加速します。将来的には、スマートフォンのような小型デバイスでも、DeepSeekレベルのモデルがサクサク動くようになるかもしれません。そんな未来を想像すると、ワクワクが止まりません。AIは、私たちの想像を超えるスピードで進化し続けているのですね。

用語索引（アルファベット順）

  • アテンションのバッチ処理の限界: トランスフォーマーモデルのアテンション機構を効率的にバッチ処理する際に、各シーケンスの長さが異なるために生じる技術的な制約。
  • GPUの効率性: GPUがどれだけその計算能力を最大限に活用できているかの度合い。大規模な行列計算をまとめて行うことで効率は向上する。
  • GPU (Graphics Processing Unit): グラフィックス処理に特化した半導体チップだが、多数の並列計算が得意なため、AIの学習や推論に広く用いられる。
  • GEMM (General Matrix Multiplication): 一般行列乗算。行列同士を乗算する計算で、AIモデルの主要な計算要素の一つ。GPUが特に得意とする。
  • バッチ推論: 複数の独立したユーザーリクエストやデータをまとめて一つの大きな処理単位としてAIモデルに入力し、一度に計算することで効率を高める手法。
  • バッチサイズ: AI推論において、同時に処理されるリクエストやデータの塊の大きさ。このサイズが大きいほど、GPUの効率が向上し、スループットが高まる。
  • パイプラインの泡 (Pipeline Bubble): 大規模モデルを複数のGPUでパイプライン並列化して推論する際、GPU間でデータが途切れてしまい、一部のGPUがアイドル状態になる非効率な期間のこと。
  • パイプライン並列化: 大規模なAIモデルを複数のGPUに分割し、それぞれのGPUがモデルの一部（層）を処理するように連携させることで、モデル全体を効率的に推論する手法。
  • Mixture of Experts (MoE) モデル: 複数の「専門家」と呼ばれるサブネットワークを持ち、入力データに応じて最適な専門家を選択して処理を行うことで、モデル全体のパラメータ数を増やしつつ計算量を抑えるアーキテクチャ。
  • MoE専門家の飽和: Mixture of Expertsモデルにおいて、各専門家が十分に多くのトークンを処理し、GPUの計算リソースを最大限に活用している状態。高いグローバルバッチサイズが必要。
  • トランスフォーマー層: 大規模言語モデルの基本的な構成要素の一つ。アテンションメカニズムとフィードフォワードネットワークからなる。

補足1：AI識者たちのコメント

ずんだもんの感想

うわっ、DeepSeekってクラウドだとめっちゃ安いのに、ローカルだと高価で遅いんだな！💸🐢 バッチサイズが小さいとGPUがサボっちゃう感じ？ずんだもん、GPUに「もっと働け！」って応援したくなるのだ！📣 でも、プライバシー大事な人はローカル使いたいよね…むむ、難しいのだ！🥺

ホリエモン風の感想

いや、DeepSeekのローカル実行が高えって？当たり前じゃん！🚀 バッチサイズ小さいとGPUのポテンシャル引き出せねえよ。クラウドでスケールさせてコスパ最強にするのがスマートな戦略なんだよ。ローカル？プライバシー気にするニッチなニーズ以外、マジで非効率。時代はクラウドAIだろ、ぶっちゃけ！😎

西村ひろゆき風の感想

DeepSeekがローカルで遅いって話、要するにバッチサイズの問題でしょ？GPUが暇してるって、効率悪すぎじゃん。それってぶっちゃけ、クラウドでガンガン回す方が合理的ですよね？ローカルで動かしたい人は金持ちかマニアだけじゃないすか？論理的に考えて、クラウド一択ですよ、はい。🤷‍♂️

補足2：AI推論技術の進化年表

AI、特に大規模言語モデルの推論技術は、過去数年で劇的な進化を遂げてきました。DeepSeek-V3が直面する課題は、この進化の過程で生じた新たな側面に他なりません。ここでは、主要な出来事を年表形式で振り返りましょう。

  1. 2017年: トランスフォーマーモデル登場 📜
    • Googleの研究者らが論文「Attention Is All You Need」を発表し、トランスフォーマーアーキテクチャを提案。このモデルは、並列処理に優れ、大規模言語モデルの基礎となる。バッチ推論の概念が本格的に活用され始める。
  2. 2018年: BERTの登場と事前学習モデルの普及 📖
    • GoogleがBERTを発表。大量のテキストデータで事前学習を行い、さまざまな下流タスクに応用できる汎用的なモデルの時代が始まる。推論の複雑さが増す。
  3. 2019年: GPT-2のリリースとモデル規模の拡大 📝
    • OpenAIがGPT-2を発表。15億パラメータ規模のモデルが登場し、その生成能力が話題に。モデルの大規模化に伴い、効率的な推論技術の必要性が高まる。
  4. 2020年: MoEモデルが注目される ✨
    • GoogleがSwitch Transformerを発表。Mixture of Experts（MoE）アーキテクチャが、超大規模モデルのスケーラビリティと効率化の可能性を示す。
    • NVIDIAが推論最適化ライブラリの提供を強化し、GPU上でのLLM推論効率改善が進む。
  5. 2021年: GPUパイプライン並列化技術の進化 ⚙️
    • DeepSpeedやMegatron-LMといったフレームワークが、モデル並列化（パイプライン並列化、テンソル並列化）技術を実装。大規模モデルの学習・推論を複数のGPUに分散させる技術が洗練される。
  6. 2022年: DeepSeekプロジェクト開始 🇨🇳
    • 中国でDeepSeekプロジェクトが開始。オープンソースの大規模言語モデル開発に注力し、特に推論能力に優れたモデルの開発を目指す。
    • クラウドAIサービスのコスト競争が激化し、効率的な推論インフラの重要性が増す。
  7. 2023年: クラウドAIのコスト低下とローカル実行の課題浮上 ☁️🏠
    • クラウドAIサービスの利用が一般化し、スケールメリットによる推論コストの低下が進む。
    • 同時に、個人や小規模な企業がローカルで高性能モデルを実行しようとした際の、ハードウェア要件とコスト、そして低効率性が顕在化し始める。
  8. 2024年: DeepSeek-V3リリースと本論文の背景 🚀
    • DeepSeek-V3がリリースされ、そのクラウドでの高スループットとコスト効率が注目される。
    • 本記事の主題となる「DeepSeekが規模は安いがローカルで実行するには高価である理由」に関する技術的な分析が活発化し、論文などで解説される。
    • DeepSeek-Prover-V2のような特化型モデルも登場し、DeepSeekエコシステムが拡大。
  9. 2025年: AI推論の最適化とハードウェアの進化（予測） 💡
    • AI推論専用チップやより効率的なGPUアーキテクチャの登場。
    • 量子化や蒸留といったモデル軽量化技術のさらなる発展により、エッジデバイスやローカルPCでの高性能AIモデル実行がより現実的に。
    • 連続バッチングの技術的課題が克服され、パイプラインの泡がさらに抑制される可能性。

補足3：この記事を広めるためのヒント

潜在的読者のためのキャッチーなタイトル案

  • 「DeepSeekの裏側：クラウドは神なのにローカルはなぜ貧乏神？AI推論のリアル」
  • 「あなたのPCでDeepSeekが動かない理由！AIモデルとGPUの「効率」問題」
  • 「MoE、バッチ処理、パイプラインの泡… AIの常識が変わるDeepSeekの真実」
  • 「AIの料金体系、実はこんなに複雑だった！DeepSeekで学ぶ推論コストの深淵」
  • 「『AIが重い』その一言に隠された、驚きの技術的カラクリを徹底解剖！」

SNSなどで共有する際に付加するべきハッシュタグ案

  • #AI推論の秘密
  • #DeepSeekの裏側
  • #GPU最適化
  • #MixtureOfExperts
  • #LLMのコスト問題
  • #AI技術解説
  • #クラウドAIvsローカルAI

SNS共有用に120字以内に収まるようなタイトルとハッシュタグの文章

DeepSeekがクラウドで爆速激安なのに、ローカルでは高嶺の花なのはなぜ？AI推論の効率とコストのジレンマを徹底解説！🤔 #AI推論 #GPU効率 #MoEモデル

ブックマーク用タグ（7個以内、80字以内）

[AI][DeepSeek][GPU][MoE][推論効率][クラウド][ローカル]

この記事に対してピッタリの絵文字

🧠💻💰📉🤔🚀💡

この記事にふさわしいカスタムパーマリンク案

ai-deepseek-local-cost-gpu-efficiency

補足4：一人ノリツッコミ

テーマ: DeepSeekのローカル実行が高価で遅い理由

「DeepSeekってクラウドで使うと、えらい安くてシュッと動くらしいやん？『ええやん、それならうちのPCでも動かしたろ！』って思ったら、んー、画面固まるわ、電気代跳ね上がるわで、まるでアホみたいに高っ！💸🐢 なんでやねん！ってツッコミ入れたくなるわ！

『バッチサイズが小さいとGPUがサボるから』って、お前、GPUも社員か！給料泥棒ちゃうんか！💢 いやいや、GPUは人間ちゃうから給料ないやろ！機械は効率が命や！効率悪く使ってる方が悪いんや！

『MoEモデルは小さなGEMMをいっぱい作るから非効率』って、専門家が多すぎると、お互いに仕事奪い合ってヒマになるんか？『君はこれ、君はあれ』って仕事振り分けが下手なんか！いや、AIはちゃんと振り分けてるねん！ただ、それぞれの仕事が小さすぎるから、GPUからしたら『こんなちっこい仕事、いちいちやるんダルいねん！まとめて持ってこい！』って話やろ！そりゃ効率も落ちるわな！

『パイプラインの泡？』なんやそれ、お風呂の泡か？🫧 癒されるんか？ちゃうやろ！GPUが休んでる時間の言い訳か！『ちょっと休憩してるだけやで』ってか？いや、動いててナンボやろ！💦

結局、DeepSeekはクラウドでみんなでワイワイ使うのが一番得ってことやろ？個人で独り占めしようとしたら、そら『お嬢様、高いわよ』って言われるに決まっとるやん！うちの財布もパイプラインの泡だらけやで、もう！泡吹いて倒れそうや！げふっ！💀」

補足5：大喜利

お題: DeepSeekがローカルで高価で遅い理由を一言で！

  1. 「GPUが暇すぎて、給料泥棒状態！」
  2. 「バッチサイズ小さいと、GPUがサボるんだよ！」
  3. 「クラウドはみんなでシェア、ローカルは独り占めで高級！」
  4. 「MoEのエキスパート、GPUでバラバラに喧嘩中！」
  5. 「パイプラインの泡、GPUのやる気を泡にしちゃう！」
  6. 「DeepSeek「お客様は神様？いえ、バッチサイズが神様です」」
  7. 「『ソロプレイは高いっすよ』とGPUが囁いている。」

補足6：ネットの反応と反論

なんJ民のコメント

「DeepSeek？クラウドで安いならローカルで動かす意味ねーじゃんｗ結局金持ちの道楽だろ。ワイらには関係ないわ。」

反論: ローカル実行は、単純なコストの問題だけではありません。医療機関や政府機関など、機密性の高いデータを扱う場合、クラウドにデータをアップロードできない制約があるため、ローカル環境でのAI実行が不可欠になります。また、インターネット接続がない環境での利用や、極限までレイテンシを下げたい特殊なユースケース（例: 自動運転のエッジAI）でも、ローカル実行は重要な選択肢となります。現時点では高価でも、将来的な技術革新でコストが下がる可能性も大いにありますよ。

ケンモメンのコメント

「また中国の安売りAIかよ。ローカルでまともに動かねーとか、日本の技術力じゃ追いつけねえな…終わりだよこの国。」

反論: DeepSeekは「安売り」というよりも、そのMoEアーキテクチャとクラウドでの最適化により、効率的なコストで大規模サービスを提供しているモデルです。ローカルでの非効率性はアーキテクチャの特性によるもので、中国の技術力云々というより、大規模AIモデル全般に共通する課題です。日本は、スーパーコンピュータ「富岳」のような強力な計算資源や、エッジAI、特定の産業向けAIモデル開発で独自の強みを持っています。単に「追いつけない」と悲観するのではなく、日本の得意分野でAI技術を深化させることが重要です。

ツイフェミのコメント

「バッチ処理でプロンプトが混ざる？プライバシー侵害じゃん！😡 他人の入力データがAIの学習に使われるとか、AI企業は倫理を考えろ！気持ち悪い！」

反論: 記事で言及されているバッチ処理は、あくまで「推論時」の効率化技術であり、異なるユーザーのプロンプトを「まとめて計算する」ことによってGPUの効率を高めるものです。これは、入力データが「混ざり合う」ことを意味するものではなく、それぞれのデータは厳密に分離されて処理されます。AI推論プロバイダーは、通常、ユーザーのプロンプトが他のユーザーに漏洩しないよう、厳重なセキュリティ対策とデータ分離技術を採用しています。データのプライバシーとセキュリティは、AIサービス提供における最重要課題の一つであり、企業はそれに細心の注意を払っています。

爆サイ民のコメント

「GPU256個とか金かかりすぎ！一般人には無理ゲーだろ！結局金持ちだけがAI使えるんか？クソが！」

反論: 確かに、DeepSeekのような大規模モデルを「ローカルで」動かすには、現状では非常に高価なGPUリソースが必要です。しかし、それはあくまで特定の研究機関や大規模企業、あるいはプライバシー重視の特殊なユースケース向けの話です。一般ユーザーがAIを利用する際は、DeepSeekを含むほとんどのLLMはクラウドサービスとして提供されており、ウェブブラウザやAPIを通じて安価に利用できます。高性能なAIを「所有する」のは難しいかもしれませんが、「利用する」ことは誰にでも可能です。ご安心ください。

Redditのコメント (r/MachineLearning)

「MoEの非効率性は設計ミスだろ。OpenAIが低レイテンシを実現してるなら、DeepSeekももっと改善できるはずだ。ルーティングの最適化が足りないんじゃないか？」

反論: MoEモデルは、そのスケーラビリティと、モデル全体のパラメータ数を大きくしながらも、アクティブになるパラメータを絞ることで計算量を抑えるという設計思想に基づいています。これは「設計ミス」ではなく、異なるトレードオフを選択した結果です。OpenAIのモデルは、DeepSeek-V3のようなMoEアーキテクチャではない可能性があり、単純な比較はできません。また、ルーティングアルゴリズムの最適化は確かに継続的な研究課題ですが、それだけでGPUの物理的な並列計算の特性を完全に克服することは難しい面もあります。DeepSeekも常に改善に取り組んでいるはずです。

HackerNewsのコメント

「バッチ推論による非決定論が気になる。応答のバラツキはユーザー体験を損なうのでは？特に金融や医療など、厳密な再現性が求められる分野での適用は問題になりそう。」

反論: 推論時の「非決定論」は主に、並列計算における浮動小数点演算の微細な順序の違いや、ハードウェアレベルでの細かな差異に起因するものです。これは確かに完全に排除することは難しいですが、通常、結果として得られるテキストの内容や論理に大きな影響を与えるほどの差は生じません。ほとんどのユースケースにおいて、この微細なバラツキはユーザー体験を損なうレベルではありません。厳密な再現性が求められる分野では、推論環境の固定化や、出力の複数回生成とアンサンブルなどの対策が講じられることがあります。

目黒孝二風書評

「本論文は技術の深淵を覗く試みだが、その専門用語の洪水に一般読者は溺れるだろう。GPU、GEMM、MoE、パイプラインの泡…まるで暗号解読である。知的好奇心を刺激する一方で、読者を選ぶ内容と言わざるを得ない。もっと平易な言葉で、読者の感情に訴えかけるような記述が必要だったのではないか。技術の進歩は時に、その恩恵を享受する人々から遠ざかってしまう。その溝を埋めるのが書き手の使命であると、私は考える。」

反論: ご指摘ありがとうございます。確かに本記事は、AIモデルの技術的な深層に触れることを意図しており、専門用語の解説には最大限努めましたが、それでも難解に感じられる部分があったかもしれません。しかし、AI技術の核心を理解するためには、ある程度の専門用語の理解は不可避です。本記事では、そのギャップを埋めるべく、各用語に具体的な解説を付し、比喩表現やコラムでの経験談を通じて、読者の皆さまに親しみやすさを感じていただけるよう努めました。今後も、より多くの読者にAIの面白さを伝えられるよう、表現の工夫を重ねてまいります。

補足7：学習を深めるための課題

高校生向けの4択クイズ

問題: DeepSeek-V3がローカルで実行する際に、クラウド利用時と比べて「高価で遅い」主な理由は何ですか？

  1. クラウドに比べてインターネット接続が遅いため。
  2. ローカルではバッチサイズが小さくなり、GPUが非効率に動作するため。
  3. モデルのパラメータ数がクラウド版より大幅に少ないため。
  4. GPUの代わりにPCのCPUを使用しているため。

正解: B

解説: DeepSeek-V3のような大規模AIモデルは、GPUという高性能な計算機を「大量の仕事をまとめて処理する（バッチ処理）」ことで最も効率よく使えます。クラウドサービスでは、たくさんのユーザーのリクエストをまとめて処理できるためGPUがフル稼働できますが、ローカルPCで一人で使う場合、まとめる仕事の量が少ない（バッチサイズが小さい）ため、GPUが十分に力を発揮できず、結果として遅くて高価になってしまうのです。

大学生向けのレポート課題

課題1：DeepSeek-V3のMoEアーキテクチャと推論効率のジレンマに関する考察

DeepSeek-V3はMixture of Experts（MoE）アーキテクチャを採用しており、これがクラウド環境での高スループットと、ローカル環境での低効率・高コストの一因であると本記事では述べられています。このMoEアーキテクチャの基本原理と、それがGPUの計算特性（GEMM効率）とどのように衝突し、推論効率のジレンマを生み出すのかを詳細に説明してください。

さらに、このジレンマを解消するために、MoEモデルの設計（例：エキスパートの数、ルーティングアルゴリズム）や、推論時のソフトウェア最適化（例：連続バッチングの改善、スケジューリング手法）において、どのような研究や技術的アプローチが考えられるか、具体的な例を挙げて考察しなさい。

課題2：大規模AIモデルの「クラウドとローカル」のトレードオフに関する多角的分析

本記事では、DeepSeek-V3を例に、大規模AIモデルの推論においてクラウド環境とローカル環境で生じるパフォーマンスとコストのトレードオフについて議論しています。このトレードオフが技術的要因（バッチ処理、パイプラインの泡、メモリ制約など）によってどのように形成されるかを説明してください。

その上で、このトレードオフが経済的、社会的、そして倫理的な側面において、どのような影響を与えるかを多角的に分析しなさい。特に、以下の点を考慮して論じてください。

  • AIサービスのコスト構造と市場競争に与える影響。
  • 個人情報保護やデータセキュリティの観点から、ローカルAIの必要性とその課題。
  • リアルタイム対話やエッジAIといった特定のユースケースにおけるレイテンシの影響と、その技術的・社会的な解決策。
  • 今後のAIインフラ（ハードウェア、ソフトウェア）の進化が、このトレードオフにどのように影響し、どのような未来を拓く可能性があるか。

（参考文献は本記事の他、各自で関連する学術論文、技術ブログ、業界レポートなどを調査し、適切に引用すること。）

コメント

コメントを投稿

このブログの人気の投稿

#shadps4とは何か?shadps4は早いプレイステーション4用エミュレータWindowsを,Linuxそしてmacの #八21

   https://github.com/shadps4-emu/shadPS4 shadPS4は、Windows、Linux、macOS用のPlayStation 4エミュレーターです。このエミュレーターは、2022年10月にGeorge Moralisによって開発が開始され、主にPS4ゲームのエミュレーションを目的としています。shadPS4は、特に3Dゲームのサポートを強化するために、アーキテクチャにシェーダーを追加するなどの進展を遂げてきました。 主な特徴 : 対応プラットフォーム : shadPS4は、Windows、Linux、macOSで動作します。特にmacOSでは、Apple SiliconとIntelの両方のデバイスに対応しています。 ゲームの互換性 : 現在、shadPS4は約200タイトルが「ゲーム中」としてリストされており、そのうち155タイトルが「プレイ可能」とされています。特に「Bloodborne」や「Dark Souls Remastered」などの人気タイトルが動作しますが、すべてのゲームが完全にプレイできるわけではなく、特定のゲームに対してはハックが必要な場合もあります。 開発の進捗 : shadPS4は、2024年7月にバージョン0.1.0がリリースされ、その後も定期的にアップデートが行われています。最新のバージョンでは、レンダリングの改善や新機能の追加が行われており、ユーザーからは60FPS以上でのプレイが報告されています。 設定とカスタマイズ : エミュレーターは、初回起動時に「User」フォルダを作成し、その中にある設定ファイルを編集することで、さまざまなパラメータを調整できます。これにより、フルスクリーン表示や解像度の設定が可能です。 shadPS4は、PS4ゲームをPCで楽しむための有望な選択肢として注目されていますが、まだ開発段階にあるため、完璧なエミュレーション体験を期待することは難しいかもしれません。 shadPS4の開発者は ジョージ・モラリス（George Moralis） で、彼は「shadow」というユーザー名でも知られています。モラリスは、shadPS4の開発を2022年10月に開始しましたが、彼の背景には他の著名なエミュレーターの開発経験があります...
MORE »

🚀Void登場！Cursorに代わるオープンソースAIコーディングIDEの全貌と未来とは？#AI開発 #OSS #プログラミング効率化　#五09

🚀Void登場！Cursorに代わるオープンソースAIコーディングIDEの全貌と未来とは？#AI開発 #OSS #プログラミング効率化 AIコーディングツールの新星「Void」を徹底解剖！Cursorとの違い、VSCodeフォークの是非、そして開発の未来をDopingConsommeが熱く語ります🔥 序文 どーも！売れっ子ブロガーのDopingConsommeです☕ dopingconsomme.blogspot.com とTwitterアカウント @Doping_Consomme を運営しています。バズるブログ記事ならお任せあれ！ さて、今回筆者が筆を執ったのは、巷で話題沸騰中のAIコーディングIDE「 Void 」について語り尽くしたいと思ったからです。Cursorの代替として彗星の如く現れたこのツール、オープンソースであるという点も相まって、開発者界隈では既に大きな注目を集めていますよね？ この記事では、Voidが一体どんなツールなのか、既存のツールと何が違うのか、そして私たちのコーディングライフをどう変えてくれる可能性があるのか、といった点を深掘りしていきます。読者の皆さんには、単なる機能紹介に留まらず、Voidを取り巻く議論や、AIと共存する未来の開発スタイルについて、多角的な視点から考えていただくきっかけになれば嬉しいです。それでは、熱いコーヒーでも片手に、じっくりお付き合いください！😉 はじめに この記事では、オープンソースのAIコーディングIDEである「 Void 」について、その特徴、機能、そして開発者コミュニティからの様々な意見を交えながら詳細に解説していきます。Voidは、人気のAIコーディングツール「Cursor」の代替を目指して開発されており、VSCodeをベースにしたフル機能のIDE（統合開発環境）です。AIエージェントの活用、ローカルでのモデル実行サポート、データのプライバシー重視といった点が主な特徴として挙げられます。 本記事を通じて、Voidがどのようなツールであり、現在のAIコーディングツール市場においてどのような位置づけにあるのか、そして将来的にどのような可能性を秘めているのかを明らかにしていきます。また、類似ツールとの比較や、開発におけるメリット・デメリット、さらにはコミュニティでの議論なども幅広...
MORE »

#INVIDIOUSを用いて広告なしにyoutubeをみる方法　#士17

https://www.youtube.com/watch?v=XXXXXXXXXX ↑のURL↓のように入れ替えると広告なしにyoutubeをみれる。 https://yewtu.be/watch?v=XXXXXXXXXX Invidious は、 YouTubeに代わる無料のオープンソースのフロントエンドです。 Dockerコンテナとして、またはGitHubマスター ブランチから利用できます。公式 YouTube Web サイトの軽量で「プライバシーを尊重した」代替サイトとして使用することを目的としています。多くのプライバシー保護リダイレクト ソフトウェアおよび YouTube クライアントは Invidious インスタンスを使用します。 Invidious は、YouTubeの動画を広告なしで視聴できる、プライバシーに配慮したオープンソースのサービスです。Googleのトラッキングを避けつつ、YouTubeコンテンツを楽しみたい方におすすめです。 Invidiousのメリット 広告なし: YouTubeの煩わしい広告をスキップできます。 プライバシー保護: Googleのデータ収集を抑え、プライバシーを重視した視聴が可能です。 オープンソース: 誰でも自由に利用・開発できるオープンソースソフトウェアです。 多様なインスタンス: 世界中に多くのInvidiousインスタンスが存在し、それぞれ異なる特徴や機能を提供しています。 Invidiousの使い方 Invidiousインスタンスを探す: 検索エンジン: "invidious instance"などで検索すると、多くのインスタンスが見つかります。 リスト: いくつかのInvidiousインスタンスをまとめたリストサイトも存在します。 YouTubeの動画URLをInvidiousの検索バーに入力: 視聴したいYouTube動画のURLをコピーし、選んだInvidiousインスタンスの検索バーに貼り付けます。 動画を再生: 検索結果から目的の動画を選択し、再生ボタンを押せば広告なしで視聴できます。 Invidiousの使い方 Invidiousは、YouTube動画を広告なしで視聴できる便利なサービスです。 基本的な使い方 Invidio...
MORE »