HPCシステムを使って大規模言語モデルへの安全なアクセス

大規模言語モデル（LLM）の登場で、これらを効率的、安全、プライベートに使うためのシステムの需要が高まってるんだ。研究者や組織は、データのプライバシーを守りつつカスタマイズされたLLMを運用したいと思ってる。主に使われるシステムは、高性能コンピューティング（HPC）システムとクラウドベースのシステムの2種類。HPCシステムは強力なGPUを持っててLLMのトレーニングには最適だけど、リアルタイムアプリケーションには向いてない。一方、クラウドシステムはウェブサービスには良いけど、高速処理に必要な強力なGPUが不足してることが多い。

この論文ではこれらの課題に対処する新しいセットアップを提案するよ。私たちのアプローチは、クラウドの仮想マシン（VM）上で動くウェブサービスで、安全に柔軟なバックエンドに接続するっていうもの。バックエンドはHPCシステム上でさまざまなLLMを実行する。私たちは、地元の大学や研究センターの信頼できる環境を利用して、商業LLMサービスの代わりにプライベートで安全な選択肢を提供しているんだ。

私たちのシステムは、HPCバッチスケジューラのSlurmと連携するように設計されていて、既存のHPCリソースにスムーズに適合できる。このセットアップは、通常のSlurmタスクと並行して動作できて、ダウンタイムを利用してLLMリクエストを処理することができる。HPCシステムを安全に保つために、クラスタに影響を与える攻撃を防ぐための保護策を実装しているよ。

#背景

大規模言語モデル（LLM）は人気が高まっていて、多くの機関がこれらの先進的なツールをどう使うかを考えている。彼らは厳しい決断を迫られていて、OpenAIのような外国企業にデータを扱わせるか、ユーザーのプライバシーを守るために自分たちでLLMをホストするかっていう選択だ。最近では、多くの組織がLLMモデルを無料で提供していて、選択肢が増えてる。

小さいモデルは普通の消費者用GPUで動かせるけど、大きいモデルは効果的に使うために高価なハードウェアが必要なんだ。これが、必要なリソースを持てる人と持てない人の間に格差を生んでる。多くの研究センターや大学はすでにHPCシステムを持っていて、LLMをホストするのに適しているよ。

#課題

#ウェブサービスのためのHPCシステムの利用

HPCシステムは常時ウェブサービスのために作られてないから、大きなバッチジョブを走らせるのに適してる。この違いが、ユーザーとのリアルタイムの会話のようなインタラクティブなサービスを提供する際の課題になってる。ジョブスケジューラのSlurmはリソースの可用性に基づいてジョブを処理するから、ユーザーがリクエストの処理を待たなきゃいけないこともあるんだ。

#セキュリティの懸念

ウェブサービスがインターネットに公開されると、攻撃者の標的になりやすい。HPCセンターでは、敏感なデータや計算リソースを守るために厳しいセキュリティ対策が取られてる。ユーザーがアクセスできるサービスを安全にホストすることについて慎重に考える必要があるんだ。

#パフォーマンスの問題

HPCシステムでサービスを運用するのはパフォーマンス的に限界があるんだ。需要が高いときにモデルの読み込みや処理に時間がかかると、ユーザーは遅延を感じることになる。ユーザーの需要に応じてスケールすることが必要だけど、大きなLLMに必要なリソースを考えると複雑なんだよね。

#提案するアーキテクチャ

私たちの解決策は、ウェブサーバーとHPCインフラの2つの主要なコンポーネントから成り立ってる。ウェブサーバーはユーザーとのインタラクションを管理し、HPCインフラはモデルの処理を担当する。

#ウェブサーバー

ウェブサーバーはリバースプロキシとして動作し、ユーザーとHPCインフラの間の安全な接続を確保する。ユーザーがログインすることでデータを守るための認証方法を使ってる。このステップで、無許可のユーザーが敏感なデータにアクセスできないようにしてるんだ。

#HPCインフラ

HPCインフラはSlurmを使ってタスクを効率的に管理する。ウェブサーバーとHPCシステム間の通信はSSHを通じて行われて、さらにセキュリティが強化される。ウェブサーバーはHPC環境にリクエストを送り、それがLLMによって処理されるんだ。

#コンポーネント機能

#APIゲートウェイ

APIゲートウェイはリクエストを適切なサービスに導く役割を担ってる。アーキテクチャ内でトラフィックやユーザーアクセスを効率的に管理して、リクエストの制御や監視を助けてる。

#HPCプロキシ

HPCプロキシはウェブサーバーとHPCクラスター間の安全な通信を可能にして、受信リクエストのためのオープン接続を維持する。このセットアップにより、リクエストが迅速かつ効率的に処理されることが確保されてる。

#クラウドインターフェーススクリプト

このスクリプトはHPCサービスノード上で動作し、リクエストとモデルの橋渡しをする。リクエストを正しいモデルに導いて、応答を集め、その後プロキシを通じてユーザーに返すんだ。

#データプライバシー

ユーザーデータの保護は私たちのアプローチの最優先事項だよ。敏感な情報が不必要に保存されないように厳格なガイドラインに従ってる。システムはユーザーのプロンプトや応答をサーバーに保持しない。代わりに、この情報はユーザーのデバイス上にのみ保持されていて、完全にデータのコントロールを可能にしてる。

#セキュリティ対策

複数のセキュリティレイヤーを適用することで、侵害の可能性を最小限に抑えてる。各コンポーネントは、もし一部が侵害されても、残りがシステムを守るように設計されてる。SSHは安全な接続のために専用に使われてて、ユーザーアカウントは異常な活動を検出するために監視されてる。

#パフォーマンス評価

システムがリクエストをどれだけうまく処理し、どれだけ速く応答するかを測定するためのテストを行ったよ。これらのテストはシステム内のボトルネックを特定するのに役立って、ユーザーが速く応答が得られる体験を保証してる。

#レイテンシ測定

リクエストが処理されるまでの時間を追跡した。平均して、ユーザーはタイムリーに応答を受け取れるけど、待機時間の大部分はLLMの処理速度に起因してる。

#スループットテスト

スループットテストはシステムが一度にどれだけのリクエストを処理できるかを測定した。アーキテクチャは同時にかなりの数のユーザーをサポートできることがわかって、実際のアプリケーションに対応する準備ができてることを示してる。

#ユーザー採用

サービスが開始されて以来、さまざまな学術機関のユーザーの間で人気が出てきた。成長は一貫していて、多くのユーザーが平日に定期的に利用してる。新機能やモデルを導入した後は、ユーザーのエンゲージメントがさらに増えたよ。

#限界

成功があった一方で、私たちのアーキテクチャには改善すべき点もある。信頼性は依然として課題で、サービスが常に利用可能で中断なく提供されることが重要だ。さらに、さらなる自動化が新しいモデルや機能を追加するのをスムーズにするかもしれない。

#今後の取り組み

今後、システムの改善を続ける予定だよ。提供するサービスを拡大する機会があって、ユーザーのリクエストに応じて能力を向上させることができる。例えば、LLM以外のAIサービスを幅広く取り入れる機能を追加すれば、さらに多くのユーザーを引きつけられるかもしれない。

私たちの目標は、既存のインフラを改善し続けて、より良い管理とスケーラビリティのためにKubernetesベースのセットアップに移行する可能性もあるんだ。

#結論

要するに、私たちは既存のHPCインフラを使ってLLMに安全でプライベートなアクセスを提供するソリューションを開発したってこと。これらのリソースを効果的に活用することで、研究者や機関のニーズに沿った応答性の高いウェブサービスをサポートできる。データプライバシー、セキュリティ、パフォーマンスに注力することで、私たちのシステムが学術および研究環境に大きな影響を与える可能性を示しているよ。このアーキテクチャが、ウェブサービスやAIアプリケーションの分野での今後の発展や革新の道を開くことを願ってるんだ。