`Distributed Smart Maps Assistant` based on `llama.cpp`

[yuiseki]

• 2023年8月27日時点のSmart Maps Assistant（ https://trident.yuiseki.net/ ）は、OpenAI APIに依存している
  • 現状でも不特定多数のユーザーが自由に何回でも使えるようになっているが、OpenAI APIを呼び出す度に、課金が発生している
  • この依存を外すことに、そろそろ真剣に取り組んだほうが良い
• なぜ？
  • 2023年8月27日時点のSmart Maps Assistant（ https://trident.yuiseki.net/ ）は、yuisekiが破産したり失踪したりするだけで止まるし、yuisekiがOpenAI Platformのクレジットカード情報更新のオペミスをするとかですら止まる状況にある
  • 我々はオープンソースやオープンデータを重要視しているが、OpenAIは、名前に反して、そうではないため、
  • オープンソースやオープンデータでSmart Maps Assistantを動作させることには、意義がある
  • UNがOpenAI APIの恩恵を安定的に受け取るという意味では、Microsoft Azure OpenAI Serviceなどを検討したほうがいいし、そちらも適宜案内するべきだと思う
  • 我々はUNIFILに対して、Smart Maps Assistantに関して、明確な予算枠を要求できるような立場ではないため、
  • ランニングコストを可能な限り下げておき、そのリソースの範囲内での提供しかできません、と言える
• どうすればいいか？
  • 現状の整理
  • 2023年8月27日時点のSmart Maps Assistant（ https://trident.yuiseki.net/ ）は、 GPT-3.5やGPT-4よりも遥かに前の世代の、 text-davinci-002 モデルを利用している
  • llama.cpp によって text-davinci-002 モデルよりも遥かに賢いモデルを、Raspberry Pi 4 Model Bですら、動かすことができる
  • ただし、多くのモデルは、英語＋1言語くらいにしか、対応していない
  • UNIFILから現在要求されているのは、少なくとも10言語への対応である
  • llama.cpp は、HTTP サーバーとしての機能も持つ
    • https://github.com/ggerganov/llama.cpp/blob/master/examples/server/README.md
  • そこで、
  • 英語＋各言語に対応したモデルを、各言語ごとのRaspberry Pi 4 Model Bで動かす、という、分散コンピューティング環境を構築することを提案する
  • 各言語ごとの llama.cpp が動作するRaspberry Pi 4 Model Bは、Smart Maps Assistantの各メンバーの自宅で動作する想定である

[hfu]

From #265

• 必ずしも全端末にグローバルIPが必要というものではない。OpenMPI に乗っているものであり、ネットワーク的には様々なアレンジが可能な感じがある。
• JICA 向けに準備をしている @hfu @smellman @mapconcierge サイドのプロジェクトと上手く乗り合えるところを作りたいと @hfu は思った。

[yuiseki]

Raspberry Pi 4 Model B 8GBで、llama.cpp を使い llama-2-7b.Q4_K_M.gguf を動かしてみました。

結論から言うと メチャクチャ遅い です。 Overpass API Queryを生成するプロンプトの推論に6分間も掛かります。 同じプロンプトをノートPCで試してみましたが、GPUの支援無しだと、やはり1分～2分掛かってしまいます。

ちょっと見込みが甘かったと思います。。

llama.cppのOpenMPI実装も試してみましたが、

• 実験段階の機能であり、非常に不安定
  • （私の環境では結局正常に動作させられませんでした）
• 理論上は推論の高速化もできるはずだが、そのためにはllama.cppにまだまだ多くの実装が必要そう

という状態です。

GPU付きのマシンでリクエストを捌くような仕組みを作れないと、結局llama.cppをWebアプリケーションの基盤にすることは難しそうだ、という感触です。