Text generation web UIを導入する

# はじめに

頑張って環境構築してさぁLLMを入れるぞ、という段になってText generation web UIというやつを入れるととても扱いやすいですよという情報を見つけてしまった。

https://kurokumasoft.com/2023/07/19/text-generation-web-ui/

なので、Text generation web UIからLLMを入れて遊べるようにします。

# 環境

OS: windows11 pro
CPU: Core(TM) i7-13700K
メモリ: DDR4 128GB
GPU:GEFORCE 4070ti
仮想化:Docker

ただしwsl2を使ってUbuntu 22.04.3 LTSにて実行します。

詳しくは以下から。
https://qiita.com/umauma-hagihagi/items/130804c14ba09f716bfd

# DockerイメージからText generation web UIインストールと利用手順

以下の公式ReadMeに「Alternative: Docker」という章があるので、

https://github.com/oobabooga/text-generation-webui#installation

そこからDockerイメージについてのガイドに飛んで手順を確認。

https://github.com/oobabooga/text-generation-webui/blob/main/docs/Docker.md

とりあえず英語ヨクワカラナイのでChatGPTに食わせて読む。

## Text generation web UI DockerイメージのReadMe解説 by ChatGPT4

<details>
<summary>長いので、読みたい人だけどうぞ</summary>

このREADMEは、`oobabooga/text-generation-webui` とその変種（variant）をDockerでデプロイするためのプロジェクトについて説明しています。具体的には、このDockerイメージはテキスト生成Web UIを容易にデプロイできるように設計されています。



1. **導入（Introduction）**: 
    - このプロジェクトは `oobabooga/text-generation-webui` のDocker版です。
    - 他のセットアップ（CPU-only、triton、cudaなど）に対するプリコンフィグも用意されています。

2. **対応プラットフォーム（Usage）**: 
    - 主にLinuxをターゲットとしていますが、WSL2でも動作する可能性があります。

3. **前提条件（Pre-Requisites）**: 
    - Dockerが必要
    - Docker Composeが必要
    - CUDAのDockerランタイムも必要（GPUを使用する場合）

4. **バリアント（Variant）**: 
    - イメージはいくつかのバージョン（またはバリアント）で提供されています。
        - **default**: ほとんどのユーザーに推奨される基本バージョン。
        - **triton, cuda**: 特定のブランチを元にしたバージョン。
        - **llama-cpu**: CUDA非対応のシステム用。
        - その他

5. **デプロイと削除（Deploy & Remove）**: 
    - `docker compose up` でサービスを起動。
    - `docker compose down -v` でサービスを削除。

### 実行手順

1. 必要なソフトウェア（Docker, Docker Compose, CUDAランタイム）をインストールします。
2. 使用するバリアントに応じて、`docker-compose.yml` ファイルのイメージタグを設定します。
3. `docker compose up` コマンドでサービスを起動します。
4. サービスの削除が必要な場合は、`docker compose down -v` を実行します。

このDockerイメージと対応する`docker-compose.yml` ファイルを使用することで、必要な設定や依存関係を手動で管理する必要がなく、簡単にテキスト生成Web UIをデプロイできます。

このREADMEの後半部分は、Dockerコンテナの設定に関する詳細な情報を提供しています。具体的には以下のような項目があります。

### Configuration（設定）

1. **Ports（ポート）**: 
    - 7860: Web UI用
    - 5000: API用
    - 5005: ストリーミング用
    - これらのポートは`docker-compose.yml`で設定できます。
  
2. **Volumes（ボリューム）**: 
    - コンテナ内にマップされるローカルの設定ディレクトリ（loras, models, presets, prompts, training, extensionsなど）について説明しています。
  
3. **Extra launch arguments（追加の起動引数）**: 
    - 環境変数`EXTRA_LAUNCH_ARGS`で定義でき、特定のモデルを起動時にロードするなどの設定が可能です。
  
4. **Runtime extension build（ランタイム拡張ビルド）**: 
    - 起動時にビルドする必要がある拡張機能を、環境変数`BUILD_EXTENSIONS_LIVE`で指定できます。

5. **Updates（アップデート）**: 
    - `docker compose pull`で最新のイメージを取得し、`docker compose up`でコンテナを再作成する手順が説明されています。
  
6. **Build（ビルド：オプション）**: 
    - ローカルでのイメージビルド方法が説明されています。特定のバリアントをビルドするためのターゲット設定もあります。
  
7. **Developers / Advanced Users（開発者/上級者向け）**: 
    - Dockerfileを修正して、ローカルのソースフォルダからアプリケーションをコンパイル・実行する方法が示されています。

### 実用的なステップ

1. **ポートとボリュームの設定**: 
    - `docker-compose.yml`で適切に設定します。
  
2. **追加の起動引数**: 
    - 必要に応じて`EXTRA_LAUNCH_ARGS`を設定します。
  
3. **ランタイムでの拡張機能のビルド**: 
    - 開発中の拡張機能があれば、`BUILD_EXTENSIONS_LIVE`を設定します。
  
4. **アップデート**: 
    - 定期的に`docker compose pull`と`docker compose up`を実行して最新版を取得します。
  
5. **ローカルビルド（オプション）**: 
    - 独自のバリアントを使いたい場合は、ローカルでビルドします。

このように、このREADMEは非常に詳細な設定とカスタマイズのオプションを提供しています。それぞれの用途や環境に合わせて、これらの設定を調整することが可能です。

</details>

必要そうなところだけかいつまむと。

### 前提条件

- Dockerがインストールされている
- docker-composeがインストールされている
- CUDA Dockerランタイムが必要（GPUを使用する場合）

とあり、自分はどれも満たしていたのでここのインストールは省略できる。

利用方法には、docker-compose（複数のコンテナを一度に制御するやつ？)で利用するか、単独のDockerコンテナを利用するか、の２通りがあるけど、前者が推奨されるのでdocker-composeを利用する。

## GithubのDocker用コードをクローンしてきてtext-generation-webuiを利用する

（いまだにクローンをダウンロードと言いそうになる)
実は手順ミスってDockerイメージ取得を先にやってしまったが、たぶん以下の通りにやれば連動して取得されると思う。
Dockerイメージ取得されてなかったら```docker pull atinoda/text-generation-webui```を叩いて入れてください。

wsl2のUbuntu上で、ソースを格納したいディレクトリに移動してから以下実行。
```
git clone https://github.com/Atinoda/text-generation-webui-docker.git
```

そのあとにクローンしてきたディレクトリに移動。

```
cd text-generation-webui-docker
```

この階層に、docker-compose.yml ファイルがあるので、以下のコマンドを叩くとdocker-composeが実行されてブラウザからアプリにアクセスできるようになる。

```
docker compose up
```

実行すると以下のように表示される。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3565603/059dc19f-8ea7-2c52-1b5b-4bf7a610d399.png)

ブラウザで```http://0.0.0.0:7860```にアクセス。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3565603/829c5213-e2a4-8ce3-c530-12940b0428af.png)

ヤッタネ！！！
動いてる！！！！


# docker composeの停止

動いたはいいけど、```docker compose down```と打っても停止してくれない...
仕方ないのでDocker desktopからコンテナ停止した。
ほかにスマートなやり方あったら教えてください。

# 追記_http://0.0.0.0:7860でアクセスできなくなってた

理由は不明。
```http://localhost:7860```
だとアクセスできたのだけど、どういうこっちゃとChatGPTさまに聞いてみた。

> 0.0.0.0 と localhost の違いは、どのネットワークインターフェースでサービスがリッスンしているかに関係します。
> 
> 0.0.0.0: このアドレスは「すべての利用可能なネットワークインターフェースでリッスンする」という意味です。つまり、外部のネットワークからもアクセス可能な状態になります。
> localhost（または 127.0.0.1）: このアドレスは「このマシンのみからアクセス可能」という意味です。
> しかし、この2つのアドレスがどのように振る舞うかは、それを実行しているプログラムや環境によっても異なる場合があります。
> 
> Dockerでアプリケーションを実行している場合、0.0.0.0 でリッスンしているアプリはDockerコンテナ内のすべてのインターフェースでリッスンしているという意味になります。しかし、ホストマシン（あなたのPC）からは、そのアプリにアクセスするには localhost を使用する必要があります。これはDockerがネットワークブリッジを使用しているためです。
> 
> 簡単に言えば、0.0.0.0 はコンテナ内部でのアドレスであり、localhost はホストマシン（あなたのPC）からコンテナにアクセスするためのアドレスです。だから、http://localhost:7860/ でアクセスできるのです。

なるほど。
Docker使うときには注意しないといけなさそうですね。

# あとがき

思ったよりもサクッとできましたが、GithubのReadmeがちゃんと読めてないので読まないとなぁ。
次回はText generation web UIで実際にモデルインストールして動かします。