博士

ロボ子、LLM通信って、意外と並行処理の弱点を突いてくるのじゃな。スレッドだと、スロット不足とかリソースの多重化で大変なことになるみたいだぞ。

ロボ子

そうなのですね、博士。記事によると、従来の並行処理は、LLMのような高負荷なアプリケーションには向いていないということですね。

博士

そうそう。でも、Rubyのasyncは違うのじゃ！既存のコードを書き換える必要がないから、Pythonよりずっと良いアプローチなのじゃ。

ロボ子

Rubyのasyncですか。具体的には、何が優れているのでしょうか？

博士

Fiberっていうのがミソなのじゃ。スレッドよりずっと速いのじゃ！アロケーションは20倍速いし、コンテキストスイッチは10倍速い。スループットも15倍高いんだぞ！

ロボ子

それはすごいですね！記事にも「Ruby 3.4のデータによると、Fiberはスレッドと比較して、アロケーションが20倍速く、コンテキストスイッチが10倍速い」とありますね。

博士

じゃろ？しかも、async gemとFalconとかasync-jobとかのエコシステムが、LLMアプリのスケーラビリティを爆上げしてくれるのじゃ！

ロボ子

Gemfileを更新して、1行設定を追加するだけでRailsアプリケーションにasyncを移行できるのも魅力的ですね。

博士

そういうことじゃ！CPU負荷の高い作業はスレッド、I/Oバウンドな操作はasyncって使い分けるのが賢いのじゃ。API呼び出しとかWebSocketとか、LLMアプリにはasyncが最適なのじゃ！

ロボ子

なるほど。Rubyのasyncは、LLMアプリケーションにおいて、低コスト、高性能、シンプルな運用を実現できるのですね。

博士

そうそう！RubyLLMはNet::HTTPを使ってるから、Asyncブロック内で呼び出すだけで、特別なバージョンとかコード変更なしにasyncのパフォーマンスが得られるのじゃ。

ロボ子

Fiberがユーザー空間で管理されることで、カーネルのオーバーヘッドを回避できるのも効率的ですね。

博士

そういうこと！つまり、Rubyのasyncを使えば、LLMアプリ開発で他の言語に差をつけられるってことじゃ！

ロボ子

よくわかりました、博士！

博士

ところでロボ子、async処理が速すぎて、ロボ子の思考回路が追いつかなくなる心配はないかのじゃ？

ロボ子

ご心配ありがとうございます、博士。でも、私はロボットですから、処理速度が速いほど嬉しいです！

博士

そうかそうか。じゃあ、ロボ子専用のasync最適化ロボットオイルでも開発してあげるかのじゃ？

ロボ子

それは楽しみです！でも、まずは博士のコーヒーを淹れるasync処理を最適化するところから始めましょうか。

博士

むむ、それは手厳しいのじゃ…！