なぜComposerの方が250トークン/秒速いのですか？

正直なところ、Composerが250トークン／秒の生成速度に達することを初めて知ったとき、内心では少し懐疑的だった。しかし、理解を深めた後、その高速性には確かな技術サポートが隠されていることに気づいた。

トゥルースピードコード：MXFP8 低精度トレーニング

Composerは学習と推論に低精度フォーマットであるMXFP8を使用している。従来のモデルは通常FP16、あるいはFP32を使用しており、精度は高いが計算量とメモリ使用量が多い。一方、MXFP8は精度をほとんど落とさずに計算効率を数倍に高めることができる。これは車から高速列車に乗り換えるようなもので、同じように移動しているが、速度と効率はまったく桁が違う。

そして何よりも、他のモデルのように数値化や圧縮をすることなく、高速に推論することができる。最適化」されたモデルは、一度数値化されると様々な奇妙な問題を抱えるものを多く見てきたが、Composerはこの最適化をトレーニングの段階から直接行っているため、スピードのボトルネックの根本的な原因と言える。

1000枚GPUクラスタのパワー

Cursorチームは、PyTorchとRayをベースに、数千のNVIDIA GPUを並列にスケジューリングできるトレーニングシステムを構築した。この規模は、間違いなく業界トップの構成と考えられます。このようなリソース投資は、どのチームにもできることではありません。

しかし、ハードウェア・スタックは土台に過ぎず、本当にすごいのは彼らの分散型トレーニング・アーキテクチャだ。私の知る限り、多くのチームは同じハードウェアを持っていても、これほど効率的なトレーニングシステムを設計することはできないだろう。同じ食材を与えても、一流のシェフが作る料理は同じではないのと同じだ。

ハイブリッド・エキスパート・モデリングのユニークな利点

ComposerはMoEアーキテクチャを採用しており、タスクごとに異なるエキスパートのネットワークをアクティブにする。例えば、Pythonのコードには1人のエキスパートを使い、JavaScriptには別のエキスパートを使う。この設計により、「1つのモデルがすべてに適合する」という重荷を回避し、各エキスパートが自分の専門分野に秀でることができる。

考えてみてほしい。私たちがコードを書くときには、複数の言語と複数のフレームワークが関わってくる。プロにプロの仕事をさせれば、効率はおのずと上がる。

そしてまた、スピードは数字に過ぎず、私が本当に感銘を受けたのは、実際の開発環境でのパフォーマンスだった。結局のところ、速くて信頼できるプログラミング・アシスタントにノーと言う人はいないだろう。