【ITニュース解説】Community reports 220 tokens/second Qwen3.8–27B

大規模言語モデル（LLM）は、現代のIT技術の中で特に注目されている分野の一つだ。膨大な量のテキストデータを学習することで、人間が書いたかのような自然な文章を生成したり、質問に答えたり、さらにはプログラムコードを作成したりする能力を持っている。今回のニュース記事は、Qwen3.8–27Bという具体的なLLMを、自分のコンピュータである「ローカル環境」で動かし、その処理速度を向上させようと試みた際の経験と、そこで直面した技術的な課題について解説している。

まず、Qwen3.8–27Bというモデル名について少し説明する。この「27B」という部分は、モデルが持つ「パラメータ」の数を指している。パラメータとは、LLMが学習を通じて調整する内部的な数値のことで、これが多ければ多いほど、一般的にモデルの表現力や学習能力が高まるとされている。270億というパラメータ数は、非常に大規模なモデルであることを意味し、これをスムーズに動かすには相応の計算能力を持つハードウェアが必要となる。

LLMの性能を表す重要な指標の一つが「トークン/秒（tokens/second）」だ。LLMはテキストを単語や記号のまとまりである「トークン」という単位で処理する。例えば、「こんにちは」という単語が1トークンだったり、「おはようございます」が「おはよう」「ございます」の2トークンに分割されたりすることもある。この「トークン/秒」という指標は、1秒間にどれだけのトークンを生成できるかを示し、この数値が大きいほど、モデルの応答が速いことを意味する。記事では220トークン/秒という速度が報告されており、これは非常に高速な処理能力であると言える。

では、なぜクラウド上のサービスではなく、自分のローカル環境でLLMを動かすことにこだわるのだろうか。その主な理由としては、クラウドサービスを利用する際の費用を抑えたい、自分のデータを外部に送らずプライバシーを確保したい、インターネット接続がない環境でも使いたい、といった点が挙げられる。しかし、高性能なLLMをローカルで快適に動かすためには、通常、強力なグラフィック処理装置（GPU）や大量のメモリといった、高性能なハードウェアが不可欠となる。

記事の筆者は、このローカル環境でのLLM処理速度をさらに高めるため、「SGLang」と「Drafter」という二つの先進的な技術を導入した。SGLangは、LLMの推論（テキスト生成）プロセスを効率化するためのソフトウェアライブラリやフレームワークだ。これを利用することで、モデルがより少ない計算資源で、より速くテキストを生成できるようになる。

そしてDrafterは、「投機的サンプリング（Speculative Sampling）」と呼ばれる高速化技術の一種と考えられている。この技術は、大きなメインのLLMよりも小さく、高速な別のモデル（「ドラフトモデル」や「下書きモデル」と呼ぶこともできる）を使って、まずテキストの「下書き」を素早く生成する。その下書きを、より大きく正確なメインのLLMがチェックし、間違いがあれば修正して最終的なテキストを完成させるという流れだ。この手法は、メインモデルが最初からすべてのトークンを生成するよりも、はるかに高速にテキストを生成できる利点がある。特に、プログラムコードの生成のように、ある程度の構造を持った出力を期待するタスクでは、このアプローチが効果を発揮すると期待されていた。

筆者は、SGLangとDrafterを組み合わせることで、ローカルでのコード生成速度が大幅に向上し、例えば倍増するだろうと期待していた。しかし、実際にこれらの技術を導入して試してみたところ、期待していたほどの速度向上は得られなかったという。そして、この状況を「PCIeの物理学の授業」を受けたと表現している。

ここで登場するPCIe（PCI Express）とは、コンピュータ内部のCPU、GPU、メモリ、SSDといった主要な部品同士がデータをやり取りするための高速なインターフェースのことだ。例えるなら、これらの部品をつなぐ、非常に多くのデータを同時にやり取りできる高速道路のようなものだと考えると良い。このPCIeには世代があり、新しい世代ほどデータの転送速度（帯域幅）が速くなる。

筆者が「PCIeの物理学の授業」を受けたと表現したのは、導入したSGLangとDrafterによるLLMの処理能力は確かに向上したものの、その高速化された処理能力に見合うだけのデータの転送速度が、既存のPCIeインターフェースでは不足していた、ということを意味している。つまり、ソフトウェアの最適化によってLLMの「エンジン」の性能は上がったが、そのエンジンが処理する膨大なデータを運ぶための「道路」（PCIe）が細すぎて、データの流れが滞ってしまった、という状況だ。この現象を「ボトルネック」と呼ぶ。いくら一つの部分の性能を上げても、他の部分やそれらをつなぐ経路が遅ければ、システム全体の性能は頭打ちになる。

特にDrafterのような投機的サンプリング技術は、メインモデルとドラフトモデルの間で頻繁にデータ転送を必要としたり、GPUメモリとメインメモリの間で大量のデータをやり取りしたりすることが多い。この大量のデータが、PCIeの限られた帯域幅を使い切ってしまい、データの流れがボトルネックとなり、結果として全体の処理速度が期待通りに向上しなかったと考えられる。

この経験は、システム構築において非常に重要な教訓を与えてくれる。いくら個々のソフトウェア技術の性能を高めても、それを動かすハードウェアの物理的な限界、特にデータ転送速度が追いつかなければ、システム全体の性能は向上しないということだ。システムエンジニアを目指す上で、このようなハードウェアの基礎知識、特に部品間のデータ転送速度やボトルネックの概念を理解することは極めて重要となる。ソフトウェアの最適化だけでなく、それを支えるハードウェア構成や、その間のデータがどのように流れるかという全体像を考慮する視点を持つことで、初めて真に高性能で効率的なシステムを設計・構築できるようになる。今回の記事は、最新のAI技術と、それを現実世界で動かすハードウェアの物理的な限界がどのように相互作用するかを示す、非常に興味深い事例であると言える。