2025-09-23

EVO-X2でLlama.cpp Serverでgpt-oss-120bを動かす

現在のOllamaのDockerイメージではROCm 6系が使われておりEvo-X2に載っているRyzen  AI Max+ 395 (Strix Halo)との組み合わせが性能面で最適とは言えないらしいことは薄々知っていたが、「まあそこそこ動くし」と手軽さ重視でうちのEVO‑X2ではこれまでollama:rocmで運用していた。

blue1st.hateblo.jp

しかし、gpt‑oss:120bを運用していると、単なるチャットでの応答としては差し支えはないものの、Web検索やRAGを絡めたような複雑なことをしたりCLI ツールのcodexなんかを利用しようとするとタイムアウトやエラーが発生して上手く動かないことがしばしばあった。

一方でROCmではなくVulkanを用いたllama.cppのビルドでは結構良い速度で動いてくれるらしい情報を見かけ、llama.cpp公式のDockerイメージの存在に気づいたこともあり、これをOllamaの代替として導入することにしてみたら・・・体感で分かるぐらい速度が改善したし、諸々のエージェントからの利用も上手くいった！

というわけで、思いっきり手のひら返しになっちゃうけど、現状ではllama.cpp serverで運用するのをお勧めしたい。

2025-08-13

ローカルLLMを動かしてVibe Coding、アケコンボタン配置図ツールを作ってみた雑感

コーディング EVO-X2 LLM

EVO-X2を使ってローカルLLMまわりを中心に色々と遊んでいる昨今。

blue1st.hateblo.jp

ここ数週間のうちにQwen3 Coderやgpt-ossがリリースされてローカルLLMを取り巻く状況は大きく変化している。

コーディング用途の視点でいうと、これまでの大きいモデルは推論が重くてエージェントだったりollama側だったり色々な箇所のタイムアウトにひっかかって（そうでなくても遅すぎて）とても実用にはならず、かといって小さいモデルはコーディング性能が低いどころかそもそもエージェントのフォーマットに沿ったやり取りができなくて動かないというようなジレンマがあった。

それが直近でリリースされたモデルなんかはMoEが絶大な効果を発揮していて、大きなモデル並みの柔軟性を備えつつもマシンのメモリ容量に収まって十分な動作速度が出たりする。

以前にVibe Codingの記事を書いたタイミングでは「使えないこともない」ぐらいの感触だったんだけど、僕個人の実感ベースでもQwen3-Coderなんかは今ではすっかり「十分実用に足る」「あれば助かる」ラインに入ってきたなーという印象を持っている。

そんなわけで前置きが長くなったけど、今回の記事では先日リリースしたアケコンのボタン配置図作成ツールの作成の流れと感想を書いてみようと思う。

blue1st.github.io

2025-08-06

レバーレスコントローラのボタン配置図作成ツール作ってみた

習作ガジェットゲームコーディング

Vibe Codingの素振りも兼ねて、EVO-X2上で動かしてるQwen3-Coderの力を借りてレバーレスコントローラのボタン配置図の画像ファイルを作成できるウェブツールを作成してみた。

blue1st.github.io

Vibe Coding作業がどうだったとかの技術面の話は別に書くとして、今回はひとまず作ったものの紹介をば。

追記: 書いた

blue1st.hateblo.jp

2025-07-21

EVO-X2でVibe Coding試してみてる雑感

コーディング LLM EVO-X2

EVO-X2でのローカルLLM運用の延長でコード生成を試してみてる。

blue1st.hateblo.jp

コード生成では素のチャットと違って長いコンテキストのやり取りをすることになる上に表面的な操作の裏で何往復もするので、流石にEVO-X2の性能では「結果」が現れるまでに結構時間がかかる。

与えられるタスクや使いたい言語・ライブラリなんかで出力のクオリティはだいぶ変わる感じがあるし、そもそもLLM自体が応答にランダム性があって同じ条件を与えてもいつでも同じ結果が返ってくるわけじゃないので定量的に評価して「ベストな状態」を見つけるのは難しい。

最近ではLLMモデルは多数リリースされているし、Ollama側にしろコーディングエージェント側にしろ膨大な設定パラメータがあって試行錯誤できる余地はいくらでもあるんだけど、他にもEVO-X2使ってやってみたいことも色々あるので自分自身が一区切りつけるために現時点での感触・知見をまとめてみたいと思う。