2025/04/05

OpenHandsをローカルLLMで動かす

OpenHandsをローカルLLMで動かしてみます。

OpenHandsの準備


https://github.com/All-Hands-AI/OpenHands/のQuick Startに従って、dockerを動かすだけです。 Rootless dockerでも動作します。

/var/run/docker.sockを使ってOpenHandsがdockerを制御するようでしたので、今回は、KVM上でUbuntu24.04を動作させ、その中でAllHandsを動作させました。

ollamaの準備


ローカルLLMについてはollamaで動作させます。

ollamaもdockerイメージがhttps://hub.docker.com/r/ollama/ollamaで配布されているのでそれをそのまま利用します。 こちらもrootless dockerでも動作します。

$ docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama
を実行するとollamaが立ち上がります。
$ docker exec -it ollama bash
でdocker内に入って、ollamaを実行すると
root@xxxxxxxx:/# ollama
Usage:
  ollama [flags]
  ollama [command]

Available Commands:
  serve       Start ollama
  create      Create a model from a Modelfile
  show        Show information for a model
  run         Run a model
  stop        Stop a running model
  pull        Pull a model from a registry
  push        Push a model to a registry
  list        List models
  ps          List running models
  cp          Copy a model
  rm          Remove a model
  help        Help about any command

Flags:
  -h, --help      help for ollama
  -v, --version   Show version information

Use "ollama [command] --help" for more information about a command.
となり、ollamaが実行できることが確認できます。

ollamaのモデルの準備


試している環境ではGPUメモリが8GBなので、小さめのLLMを探してきます。

以下のものを試してみましたが、hhao/qwen2.5-coder-tools:7bがかろうじて動く程度で、ほかはOpenHandsで使うには適切ではないLLMでした。

hhao/qwen2.5-coder-tools:7b    1fbf62f22cd4    4.7 GB
codegemma:7b                   0c96700aaada    5.0 GB
llama3.2:3b                    a80c4f17acd5    2.0 GB
codellama:7b                   8fdf8f752f6e    3.8 GB
qwen2.5-coder:3b               e7149271c296    1.9 GB
opencoder:1.5b                 8573dfc23c16    1.4 GB
opencoder:8b                   cd882db52297    4.7 GB
もっと良いLLMがあるかもしれませんが、ここではhhao/qwen2.5-coder-tools:7bを使って進めます。runすると
/# ollama run hhao/qwen2.5-coder-tools:7b
>>> Send a message (/? for help)
と表示され、OpenHandsからアクセスできる状態になりました。試しにメッセージを入れてみると、
>>> Pythonでhelloと出力するスクリプトを作成してください
```python
print("hello")
```
とか
>>> rustでhelloと出力するコードを書いて、ビルドして実行する方法を書いてください
```json
{
  "name": "create_file",
  "arguments": {
    "filename": "main.rs",
    "content": "fn main() {\n    println!(\"Hello\");\n}"
  }
}
```
のように出力されました。日本語でも動きそうです。OpenHandsから呼び出すときにollama runが実行されている必要はありません。

OpenHandsの設定


KVM内からollamaにアクセスできることを確認します。
curl http://host.ip.address:11434/api/generate -d '{
  "model": "hhao/qwen2.5-coder-tools:7b",
  "prompt":"Write a bash script that prints hello"
}'
json形式の応答が返ってくれば、動作しています。

docker run -it --rm -e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:0.29-nikolaik \
       -e LOG_ALL_EVENTS=true \
       -e LOG_JSON=false \
       -e LOG_LEVEL=DEBUG \
       -e DEBUG=true \
       -e OLLAMA_API_BASE=http://host.ip.address:11434 \
       -v /var/run/docker.sock:/var/run/docker.sock \
       -v ~/.openhands-state:/.openhands-state \
       -p 3000:3000 \
       --add-host host.docker.internal:host-gateway  \
       --name openhands-app \
       docker.all-hands.dev/all-hands-ai/openhands:0.29
host.ip.addressは適切な値に書き換えてください。

KVM内のブラウザでlocalhost:3000にアクセスします。 左下の⚙アイコンをクリックして、

Custom model: ollama/hhao/qwen2.5-coder-tools:7b
Base URL: http://host.ip.address:11434
API Key: なんでもOK
Agent: CodeActAgent
と設定します。

これで動くようになります。指示として例えば

Could you write a bash script that just prints "こんにちは" ?
を入力すると動き始め、下図のようになりました。
ただ、ファイルはつくれたもののその後はうまく動作しなくなってしまいました。

OpenHandsを活用するには、もっと賢いLLMが必要なようです。

2025/02/22

FLUX.1で画像生成

FLUX.1のSchnellモデルを使った画像生成をしてみます。

FLUXのオリジナルの実装


オリジナルの実装はこちらです。

モデル: https://huggingface.co/black-forest-labs/FLUX.1-schnell
コード: https://github.com/black-forest-labs/flux

指示にしたがって環境を設定し、実行すると、44.5GBのダウンロードがはじまります。

これは src/flux/util.py を読むと google/t5-v1_1-xxl をロードするようになっており、 https://huggingface.co/google/t5-v1_1-xxl/tree/main を見るとちょうどモデルサイズが44.5GBなので、おそらくこれをダウンロードしようとしているのだと思われます。

https://huggingface.co/black-forest-labs/FLUX.1-schnell/tree/main に配置されているテキストエンコーダが使われない理由は謎です。

ダウンロードサイズは大きいですが https://github.com/black-forest-labs/flux/issues/7 によると、16GBくらいVRAMがあればよさそうです。sequential offloadをすれば2GBくらいらしいのですが、cli.pyのオプションを見てもそれらしきものを見つけることができませんでした。

量子化版


とはいえもう少し小さいモデルでまずは動かしてみたいので、量子化済みのモデルで試してみます。いくつかHuggingFaceにアップロードされていますが、今回はhttps://huggingface.co/aifoundry-org/FLUX.1-schnell-Quantizedを使ってみます。

現時点では[WIP]と書かれているものの動かし方がいちおうは記載されているので、そのとおりに実行してみます。

最初に table-diffusion.cpp をダウンロードしてビルドします。

次に、 Schnell-Q2_KAutoencoderCLIP_LT5XXL をダウンロードして、models/以下に配置します。

これで準備は完了です。先ほどダウンロードした一番小さいモデル(Q2_K)で試してみます。

./build/bin/sd --diffusion-model models/flux1-schnell-Q2_K.gguf --vae models/ae.safetensors --clip_l models/clip_l.safetensors --t5xxl models/t5xxl_fp16.safetensors -p "a frog holding a sign saying 'hi' " -o ../frog.png -v --cfg-scale 1.0 --sampling-method euler -v --seed 42 --steps 4
を実行します。

以下の様な蛙の画像が出力されます。

他にも

./build/bin/sd --diffusion-model models/flux1-schnell-Q2_K.gguf --vae models/ae.safetensors --clip_l models/clip_l.safetensors --t5xxl models/t5xxl_fp16.safetensors -p "Photo-realistic Rabbit running in meadow" -o ../frog.png -v --cfg-scale 1.0 --sampling-method euler -v --seed 10 --steps 20
を実行すると

となります。

T5XXLはモデルサイズは大きいもののGPUメモリはあまり必要ないようで、デフォルトの512x512のサイズの画像生成時に観測できた範囲ではGPUメモリの使用量は4.7GBくらいでした。

./build/bin/sd --diffusion-model models/flux1-schnell-Q4_K.gguf --vae models/ae.safetensors --clip_l models/clip_l.safetensors --t5xxl models/t5xxl_fp16.safetensors -p "Photo-realistic Rabbit running in meadow" -o ../frog.png -v --cfg-scale 1.0 --sampling-method euler -v --seed 13 --steps 20
のようにQ2_KではなくQ4_Kを使ってみると
となります。

Q2_KではなくQ4_Kのモデルの方を使った場合、デフォルトの512x512のサイズの画像生成時に観測できた範囲ではGPUメモリの使用量は7.4GBくらいでした。

試した範囲では実行結果に再現性があり、コマンドの引数が同じであれば同じ結果が出力されるようです。

2025/02/10

Landlockによる制限をかけるときにGPUを使うには

Landlock (を使ったsandboxer) による制限をかけるときにnvidia-smiを実行するには、次のパスを許可すれば良いようです。

LL_FS_RW=$(ls /dev/nvidia* | tr '\n' ':' | sed 's/:$//') LL_FS_RO="/usr/lib:/usr/bin" ./sandboxer nvidia-smi
RO側はもう少し制限をかけることができるかもしれません。

nvidia-smiだけでなく、NVidiaのGPUを計算に利用するには、

LL_FS_RW="/proc:"$(ls /dev/nvidia* | tr '\n' ':' | sed 's/:$//') LL_FS_RO="/usr/lib:/usr/bin" ./sandboxer /path/to/app
のように/procを読み書き権限で追加する必要があるようです。 アプリケーション依存かもしれませんので、必ずしもこれだけで使えるようになるとは限りません。

2025/02/02

uvのインストール

最近のUbuntuやDebianのシステムに入っているPythonでpip installしようとすると、

error: externally-managed-environment
と言われ、venv環境を作れと言ってきます。

全体で使いたいパッケージをいちいちvenv環境に入ってインストールして、というのは手間なので、 エラーメッセージに書かれているとおり、Debian/Ubuntuのパッケージにある pipx をインストールします。

そのうえで、

$ pipx install uv
とすると、uvをインストールできて、全体でuvが使えるようになります。

編集距離の計算

編集距離(Edit Distance, Levenshtein Distance)の計算のライブラリは今となってはたくさんありそうですが、 いい感じに表示できる jiwer (https://jitsi.github.io/jiwer/) というPythonのライブラリがあったので、メモ。

こんな感じで書けます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
import jiwer
import jaconv

def main():
    reference = "hello world"
    hypothesis = "hello duck"

    error = jiwer.wer(reference, hypothesis)
    print(error)
    error = jiwer.cer(reference, hypothesis)
    print(error)
    print("--------------")
    output = jiwer.process_characters(reference, hypothesis)
    print(jiwer.visualize_alignment(output))

    print("--------------")
    output = jiwer.process_characters("あいうえお", "あううお")
    prev_hyp = False
    for line in jiwer.visualize_alignment(output).split("\n"):
        zen = False
        if prev_hyp:
            prev_hyp = False
            zen = True
        if line[:4] == "REF:":
            zen = True
        if line[:4] == "HYP:":
            zen = True
            prev_hyp = True
        if zen:
            line = jaconv.h2z(line, kana=True, digit=True, ascii=True)
        print(line)

if __name__ == "__main__":
    main()
結果は
0.5
0.45454545454545453
--------------
sentence 1
REF: hello world
HYP: hello duck*
           SSSSD

number of sentences: 1
substitutions=4 deletions=1 insertions=0 hits=6

cer=45.45%

--------------
sentence 1
REF: あいうえお
HYP: あうう*お
      S D 

number of sentences: 1
substitutions=1 deletions=1 insertions=0 hits=3

cer=40.00%

のようになります。