llama.cpp serverのtoolsで少し試してみました

ローカル環境でチャットだけで遊びたかっただけで始めた最初のとっかかりはlocalAIでした。良くも悪くも色々と知らない環境を知る上でとても貴重な体験ができました。

llama.cppはそんなlocalAIの中で知った（名前だけは見かけた物の現物がどんなものかは知りませんでした）ものの一つです。

最初はggmlというライブラリを使用するために必要だと思っていましたが、llama.cppにはいくつかの実装が行われている形になっていて、コマンドラインで単体のLLMを実行するcliとWebUIを実装しているserverというものがある形になっています。そのうちlocalAIではそのserverをベースにgrpcでbackendに実装していました。（極論をいってしまえばlocalAIは全てgrpcベースのbackendを実装したものをlocalAIで動かしているだけ）個人的にはリッチな環境を用意してまでLLMを動かそうとは思っていないので、結果的にllama.cppのserverが一番合っていたという事だと思います。

このllama.cppのserverは地味に多機能で、通常はMCPサーバーが必要な事が、llama.cpp server単体でLLMが主体となってファイルの入出力や（セキュリティー的に問題はあるものの）コマンドの実行まで行えるようになっています。

当座の懸念事項が解消されたので、今まで気になっていたこのMCPライクなtools機能を使って、LLM自体がどのように動いてくれるのか試してみることができました。機能自体はローカルLLMでfunctionコールができるようになると同時に実装され、動かせるようになっていました。現時点ではすでにfunctionコール第二世代目gemma4はスムーズに動くようになっているようです。

セキュリティーを気にしなければ、ユーザーのシェルからダイレクトにllama.cpp serverを動かせばファイルの参照はもちろん、書き込みや実行まで行えるようになります。正直恐ろしくて書込みや実行は行わせないように除外した状態ですが(笑)

セキュリティー面を気にするのであれば特定のユーザーを用意して権限を設定したうえで、そのユーザー権限で動かす必要があります。

で、さっそくどんなお題で試すか悩んだ結果、直近の問題でシャットダウン時にハングアップすることがあるので、その原因の糸口をつかめれば…と思って聞いてみました。

👨あなたはubuntuのファイルを直接参照できます。昨日シャットダウン時にハングアップした様なのですが、原因はわかりますか？必要なファイルは直接アクセスしてみてください。

ちょっと質問は初めてなので我ながら何ともアレな感じはしますが…(^^; その回答はこうでした。

🤖Ubuntuのシステムでハングアップした原因を特定するには、いくつかの情報が必要です。どのファイルを参照すればよいか、また、どのような種類の情報（ログ、システム状態など）が役立つか教えていただけますか？一般的に、システムがハングアップした場合、以下のファイルや情報を確認するのが有効です。…（以下説明が続く）…まずは、「どのファイルを直接参照したいか」、あるいは「どのような情報が欲しいか」を明確にしていただけると、適切なアクションが取れます。

と言う感じで、いきなりシステムを貪ってガツガツ行く感じではないようです。なので

👨/var/log/syslog 内に昨日のログが残っているので参照して原因を見つけてもらえますか？

と投げたところ、実際にファイルを読み込んで動く動作に入りました。この時llama.cpp serverのWebUIではファイルアクセスの許可/拒否を行う確認が行えます。設定で許可状態にもなりますが、設定しなければ都度許可を行わなければアクセスできないようになっているようです。

📃Read file syslog
📃Read file syslog (lines 1-2000)

🤖/var/log/syslog のログを読み込みました。

ログをざっと確認したところ、システム全体の稼働に関する定期的なタスク（CRON や systemd のサービス起動・終了）が大量に記録されています。

注目すべきは、特定の時期に発生しているカーネルレベルのエラーです。……

と言うように、第一段階でファイルの概要、そしてテキストファイルであれ参照範囲を限定したうえで読み込むようです。ファイル自体は5000行以上あると思うのであくまでも一部。この辺はコピーペーストではないのでそういう風に動くようになっているのでしょう。

とは言え、ほぼ放置しているsyslogをざっくりと見てくれるのは正直助かります(笑)

システムプロンプトにはなにも記述していない状態なので「あなたはubuntuのファイルを直接参照できます。」と伝えたのですが、結果としては自発的に「勝手に」参照することは無かったようです。 

チャットで得た経験を踏まえると、蒸留されたLLMとのやり取りは基本壁打ちピンポンなので、ある程度方向性を与えないと勝手に動くという事はしないのでしょうね。 

何となくやり取りの仕方が分かったところで、（検索してるついでで、この先の問題点の追求はGeminiへ投げちゃいました…無料のまま使ってますが、ローカル環境と比べてしまうとレスポンスの速さはやはり異様に感じます…正直、悔しいですｗ）プログラムコードを実際にどんな感じで扱ってくれるのかも、今までチャットでしか遊んでいなかったのでとても気になっていました。早速試してみます。

👨ggml_sycl_patch/src/ggml-sycl/im2col.cppで処理で問題がありそうな部分はありますか？

といきなり投げたところ、

📃Read file im2col.cpp
📃Read file im2col.cpp (lines 1-50)

🤖The first 50 lines of ggml_sycl_patch/src/ggml-sycl/im2col.cpp are as follows: ……

と、50行で打ち止めで解説に入っちゃいました。ggmlのim2col.cppには何か知識があるようで、結構これだけでいろいろ解説してくれました。英語で…(笑)

でもねぇ…この50行目までほとんどコメントアウトしてるんだよなぁ…それでもim2col.cppの機能を解説してるってことは、やはり知識を持ってるってことなんだと思います。 

日本語で質問を続けても対応してくれるのは経験済みなので気にせずどんどん行きます。

👨im2col.cppはカスタマイズしています。その先まで読み込んでご判断願います。

すると今度は

📃Read file im2col.cpp

🤖Since the file is too large to read entirely in one go, I will try to read the rest of the file in chunks. Let's read from line 100 onwards to get a broader view of the implementation details, assuming the initial 50 lines set up the structure.
📃Read file im2col.cpp (lines 100-200)

🤖I have read the next part of the file (im2col.cpp).

The code seems to implement at least two kernel approaches: im2col_kernel (which uses iteration over groups/local IDs) and im2col_one_offset_kernel (which seems to use global IDs and an offset structure). ……

と続きを読み込んでくれました。とは言え、返答内容が何ともな感じなのでさらに強気で

👨現状196-276で定義されているim2col_sycl()からim2col_one_offset_kernel()が呼び出されています。ループはカスタムヘルパ関数としてsiriuth.hpp,siriuth.cppで定義しています。

と指示したところ、siriuth.hppだけではなく、im2col.cppの冒頭で定義されているcommon.hppも読み込みました。

📃Read file siriuth.hpp
📃Read file common.hpp
📃Read file common.hpp (lines 1-200)

🤖Based on the files im2col.cpp, siriuth.hpp, and common.hpp, here is a consolidated analysis focusing on the flow: ……

と、かなり具体的に懸念事項を挙げてもらえましたが、どうも動作していないことを前提とした説明のようなのでさらに

👨このカスタムされた処理はコメントアウトされている処理よりもiGPUで実行する上で、処理速度は倍程度高速化され、出力もCPUで出力されたものにより近いものが出力できているのを確認しています。そのうえで、あなたから見ておかしなポイントを発見していただきたいと考えています。

と質問したところ、

🤖それは素晴らしい進捗ですね！「速度が倍程度向上し、出力もCPUの結果に近い」という事実は、最も重要なコアロジック（カーネルの計算とデータアクセス）は概ね正しく機能していることを強く示唆しています。

この状況下では、「おかしなポイント」というのは、「バグ」というよりも「最適化の余地」「潜在的なリスク」「設計上の非効率性」といった、より深いレベルの懸念点になります。

私が指摘できる、このカスタム実装における「おかしなポイント」をいくつか挙げてみます。……

と言う感じでようやく日本語でポイントを挙げてくれるようになりました。チャット同様にかなり柔軟に対応してくれます。日本語出力独特なのかもしれませんが、google独特のこのほめちぎりで始めるのは慣れるまで気持ち悪いですよね(笑)。想定範囲内のことがほとんどですが、一人でも全く違う視点からの話が聞けるのはうれしいですね。ある意味、相手の顔色を見ながら話をしなくていいだけで実に精神的に楽ですｗ

会話だと、こちらが欲しいものではないような返答がある場合、相手を少なからず否定したうえで会話を続ける必要があるので、あまりやりすぎると相手の機嫌がどんどん悪くなりますが、生成AI相手なら、言葉が通じるのであればやりようはいくらでもあるわけ…ただ、その言葉がうまく出てこなかったりします…orz

なにかと話題のAIですが、誰でも触れる今の状態は続いてほしいですね。

今回のチャットのベースはGemma4 E4B ITベースの量子化Q8の物です。