コアサービスが本番稼働に漕ぎ着けたので、しばらくゆっくりしようと思っていましたが、やることがあるとじっとしていられません。
必要だと思って作った仕組みの上に、新しい必要が見えてくる。
必要は必要の母です。
LLM Broker拡張案にも書いたように、LLM Broker に OpenAI API準拠のインターフェースを追加します。
今日のところは、とりあえずOpen WebUIからOpenAI APIで接続ができるところまで。
上のスクリーンショットはOpen WebUIの接続設定の画面です。
LLM Brokerのエンドポイント http://192.168.0.197:19080/v1 を指定しています。
そして、これがLLM Brokerに設定されているプロフィールです。
profiles:
text_extract:
backend: llamacpp
base_url: http://192.168.0.197:8081
model: gpt-oss-20b-Q4_K_M
temperature: 0.1
timeout_sec: 360
text_conversation:
backend: llamacpp
base_url: http://192.168.0.197:8081
model: gpt-oss-20b-Q4_K_M
temperature: 0.7
timeout_sec: 360
text_extract_ollama_fallback:
backend: ollama
base_url: http://192.168.0.197:11434
model: gpt-oss:20b
temperature: 0.1
timeout_sec: 360
text_conversation_ollama_fallback:
backend: ollama
base_url: http://192.168.0.197:11434
model: gpt-oss:20b
temperature: 0.7
timeout_sec: 360
embedding_profiles:
text_embedding:
backend: llamacpp
base_url: http://192.168.0.197:8082
model: nomic-embed-text-v1.5.f16.gguf
timeout_sec: 60そうするとチャット画面のプロンプト入力エリアにあるモデル選択のプルダウンに、プロフィールで設定した名前が表示されます。
今日の時点では、Open WebUIが求めているStream出力への対応ができていないので、チャットはできません。
後日、Stream出力対応をやります。
なぜ、この開発をするのか
ZIKUUのAIシステムの開発を始める前に、
- Transformerの仕組みを理解するためにLLMをスクラッチから開発する勉強をした
- いくつものLLMをローカルで試した
という経験があって、それを踏まえて、AIシステムを開発する時点で、
- コンテクストウィンドウの肥大化を抑制する必要がある
- 推論専用のチップが増え、推論が速く安く行えるようになるだろう
- 人が判断を手放すようなシステムを作るのはよそう
- モデルサイズ競争はいずれ苦しくなるだろう
と考えました。
1については、CPSやPivot Serviceを開発して、LLMに読ませる知識を制御することで解決の目処が立った。
2については、NVIDIA RTX/DGX SparkやAMDのStrix Halo、スタートアップのチップメーカーが、思っていたより速く推論用のハードウェアを出してきた。
3については、AIに丸投げして答えを出してもらうという使い方ではなく、AIはあくまでも思考や判断を支える助手であるべきだと考えた。
4については、モデル性能競争から離れて、ローカルLLMと小さな計算資源で処理可能なシステム設計をする。そして、システムの機能を損なわずに、手持ちの計算資源の能力に応じてLLMを選べるようにしたいと考えた。それがLLM BrokerやCPSやPivot Serviceの開発につながった。
LLM Brokerは、特に2の観点で、システムの持続性や柔軟性を高める重要なコンポーネントだと判断しました。
小さなGPUを複数挿したGPUサーバーに接続する、小さなサーバークラスターに接続する、必要なら大きなGPU、大きなサーバー、クラウドAIとも接続できる。その時にアプリケーション側の変更は不要、という形態を取れます。
完成したらRustで書き直すと思います。
