LocalAI v4.3.2 主にパッケージバージョンやbackend関連のバージョン更新等

なかなか順調に落ち着いているようです。個人的にはLocalAIベースで動かす前段階で細かな動作確認でお腹いっぱいの状態で触れていないのですが、いろいろなモデルの対応や機能拡張が行われているようです。

v4.3.1からか今回からかはわかりませんが、ネイティブ環境(ベースはUbuntu  24.04.4 LTSサーバー)でビルドするために新たにnode.jsのバージョンを更新する必要がありました。

You are using Node.js 18.19.1. Vite requires Node.js version 20.19+ or 22.12+. Please upgrade your Node.js version.

解決方法としてはnode.jsのバージョンを上げる必要がありますが、これによって問題が発生する場合は別の方法をとる必要がありますが、とりあえず下記を参照し22.xに上げました。 

参考：https://qiita.com/asa129/items/3084b79e55cef0405954

実際に実行したものは下記の通り。 

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install nodejs -y

結構こんなコマンドをワンライナーで実行するのは抵抗がありますがｗ気になる場合はパイプ部分を切り離してaptのリポジトリの変更内容を確認してから実行すればよいと思います。

nodejsパッケージが無事バージョンアップされた後に再度失敗したmake buildを実行すると無事localAIのビルドが完了します。 

今後の作業簡略化のためにgithubでforkしていくつかのリポジトリを作成してみましたが、やっていることはllama-cppのビルドで常に引っかかるgrpcライブラリの参照を軽くすることとllama.cppのggml-sycl.cppのパッチです。 

LocalAI v4.3.1

サクッとアップされていますね(笑)主な変更点はバックエンドの最新バージョンへの差し替えがいつくかあるのと、バックエンドのkokoroの修正でした。 

LocalAI v4.3.0 リリース

v4.2.6がリリースされて約１週間。ようやく落ち着いたと思った後、小数点1桁がupされました。

結構気になるのがllama-cppのプロンプトキャッシュをデフォルトで有効にしたとのこと。（逆になぜ今まで無効にしていたのかと…）ちょっと試してみたいですね。

他にも結構テコ入れされていると思いますので試してみたいかな。 

LocalAI v4.2.4 なんか収集つかなくなってそう…

昨日の昼の時点で4.2.3がリリースされていることに気づき、夜には4.2.4のリリース。
で、手元の環境で動かしてみたのですがチャットを試していますがなんか節々がダメそうｗ

移動中に気づいたんですがv4.2.3がリリースされてました

backend元のcommit具合でリリースが頻繁に行われているのはとてもいいと思いますｗ

寝る前に今日こそビルドできたらいいかな…。llama-cppにもSYCLパッチあてて試してみたいし… 

1min ago

寝る前にちょっと見てみると、さらにリリースがｗ

まさに今でした(笑)
 

LocalAI v4.2.1 がリリースされました。

１３時間前にリリースされてました。(ggmlのsyclのwait()の周りを見ていて気付くのが遅れました)

LocalAI backend llama-cpp

LocalAIのリリースが行われないかと今か今かと待っている人間です…内部が結構拡張されているのでそろそろリリースされるかと期待して、早１０日…なしのつぶてです😢

stablediffusion-ggml で F16をfalseにしたらヤバかったｗ

とりあえず、llama-cpp側のF16の件が自分の中で落ち着いた（詳細は見ていないが固定値でせっていしても変化が分からなかった）のと、画像を渡しても落ちなくなったので、先週ぶりにstablediffusion-ggmlをもう少し触ってみようかと。

設定のyamlが動くようにはなっていたものの、なんだか全く記憶に残ってない…。

なんかF16の設定もあってfalseになってるみたいだからとりあえず画像作成してみましょうかね…一番ちっちゃいさいずならかかっても5分で終わるでしょう…時間がかかる…のは仕方がないですｗ

あんまり変わらんかったｗ

LocalAI経由で動作確認してるのが悪かったわけですが、結構手間取りました。

結果として、ggml-cpu : re-enable fast gelu_quick_f16(b8937)が含まれた状態のb8940をベースにしたllama-cppと、直前のリリース(b8936)をベースにしたllama-cppのバイナリを作って動作確認してみました。

LocalAI の.yamlファイル内の設定値

v4辺りから派手に変えたなぁと言う印象だったんですが、実際に動作を確認していたところどうもパフォーマンスの差が誤差範囲レベルでしか差が出ないという結果に。

普段いじらないthreads値を変えて、htopで見てみると、どうもスレッド数が制御されていない。

LocalAI v4.1.3 ベースで最新のllama.cppを使ってmake

なかなか魅力的な修正が入っているので現時点での最新のリリース（b8929）をベースとして実行したかったので、/backend/cpp/llama-cpp/grpc-server.cppへのLocalAIのmasterに反映されている部分の一部を取り込むことで何とかmakeしてみました。

stablediffusion-ggml 上手く動かないｗ

 ベースとなるモデルが動いたので、他のモデルも簡単に動かせるかと期待したものの、結果から言えばほぼ全滅…昨日の夜からいろいろ試してみた物の何の成果も出ませんでした…。

遅いとか早いとか以前の問題ですね。ただ、どんな形でモデルが絡み合っているのかは見えてきました。とはいえ、ドキュメントはあくまでも参考程度で、ソースを見なければ設定した値がどのようにbackendに引き渡されるのかわからなかったりしますね。普通はこの辺りの事どうしてるんでしょうかね？

LocalAI v4.1.3 ベースで最新のllama.cppからのmakeが厳しくなってきた…

現状 LocalAI v4.1.3 に /backend/cpp/llama-cpp/grpc-server.cppをmasterから上にかぶせてmakeしていたのですが、どうも5日前からLocalAIのgrpcインターフェースの変更が反映されてしまっているようで…

バックエンドのmakeとか

実際にmakeして動かしてみるとSYCLを利用すると結構不安定な状態になるので、ほかのbackendとしてvulkanにしてみたら変わるのだろうか？という疑問が湧いてきていてもたってもいられなくなってしまいました。

LocalAI backend stablediffusion-ggml

 llama.cppのリリースが落ち着いている様だったので他のバックエンドも様子を見てみようかと。

今までイメージ出力が上手く行っていなかったので、LocalAIでcommitされていたbackendのstablediffusion-ggmlをビルドしてみました。

結構精力的に活動が活発なようですが、今度はturboquantですか…

なんかこちらもホットなllama.cppフォークの様で…kvキャッシュの量子化で小さくすることで高速化するとか。確かに…

cpuのみで動作させてるはずなのに、xpu-smiが表示される。

htopでcpuとメモリーの監視を行いながら、動作確認を行っているとなぜかxpu-msiというプロセスが動いていることに気づきました。

MedGemma1.5が日本語で推論しはじめた！？

しまい込む前にモデルの設定ファイル(.yaml)のF16: falseにしたり効果はないもののreasoning: disable: true にして、ちょっと真面目に？聞いてみました。

local-ai ik-llama-cppを早く動かしてみたくて…

とりあえず、素のik-llama.cppをビルドしてみました。

レスポンスのトークンが３倍以上に跳ね上がるグラフを見てうずうずが止まりませんでした。（グラフの見方も良く分からんかったりするわけですがｗ）

仮に、１分のものが２０秒ぐらいで返ってくるのはでかいよなぁ？とか涎が止まらなくなりそうな状態のまま、書いてある手順に従ってサクッとmakeしてcpu単体で動かしてみました。