2025/11/04

Win11 23H2から25H2へ

Windows11 23H2のサポート期限が2025/11/11が近づいています。

https://learn.microsoft.com/ja-jp/lifecycle/announcements/windows-11-23h2-end-of-updates-home-pro から引用すると

Windows 11 Home and Pro, version 23H2 will reach the end of updates on November 11, 2025. This version was released in October of 2023.

This edition will no longer receive security updates after November 11, 2025. Customers who contact Microsoft Support after this date will be directed to update their device to the latest version of Windows 11 to remain supported.

です。さて、Windows Updateにこの更新が降ってきていれば良いのですが、降ってきていない場合は自分でアップデートする必要があります。

調べるといくつか方法があるようですが、素直に「Windows 11 インストール アシスタント」というのをダウンロードして実行し、画面に沿って進めると、25H2に一足飛びにアップグレードできるようです(少なくとも筆者の場合はそうなりました)。

2025/10/19

リチウムとアルツハイマー病

アミロイドがリチウムを集めてしまって周囲の細胞がリチウム不足になって細胞が正常に機能しなくなるらしい。 そして、アミロイドが集めにくいリチウム塩をアルツハイマー病のマウスに投与すると、認知障害を予防できたらしい。

ほんとかな。マウスでならそうなのかも。

https://doi.org/10.1038/s41586-025-09335-x
https://doi.org/10.1038/d41586-025-02255-w

2025/10/12

生成AIの定義

生成AIの分かりやすい定義をようやく見つけた。

https://www.stateof.ai/で公開されている スライドにこう書かれていた。

Generative AI: A family of AI systems that are capable of generating new content (e.g. text, images, audio, or 3D assets) based on 'prompts'.
つまり、プロンプト(指示文)が入力に必要ということ。そのため、単に入力データを変換するもの、例えば、
  • 画像を入力して何が写っているのかのラベルを出力する
  • 映像を入力して、写っている物体の動作に対してラベルを出力する
  • 映像を入力して、高解像度の映像を出力する
  • テキストを入れたらその内容をしゃべる
  • 音声を入れたらテキストを出力する
  • 日本語を入れたら英語を出力する
のようなものは、たとえTransformerベースのモデルを使っていたとしても、拡散モデルを使っていたとしても、この定義だと生成AIには該当しないことになる。

とても分かりやすい。

人間がLLMを使ってタスクをこなすときの倫理

人間が実行する場合は倫理的な行動をするけれど、同じタスクをLLMに指示して代わりに実行させる場合、直接実行する場合に比べて倫理的な行動が減るらしい。

https://doi.org/10.1038/d41586-025-02819-w
https://doi.org/10.1038/s41586-025-09505-x

2025/08/17

ECoGの信号から音声を合成

https://doi.org/10.1038/s41586-025-09127-3 によると、脳表面に設置した電極(ECoG)から取得したデータを使ってリアルタイムに音声を合成できるようになったらしい。Supplementary Videoを見る限り、速度はまだまだではあるものの、イントネーションも変えられるし、強調もできるような発声ができている。

ここまで出来るようになっているので、普通に発話できるようになるのも時間の問題だと思われる。

一方、ECoGではこのレベルで動くようになっているものの、EEGで同じことをするのはまだまだ難しいのだろう。

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%

のようになります。