2025-07-25

KDEのロックスクリーンでCPU使用率が上がる問題

KDE plasmaを導入してみたんですがロックスクリーンでCPU使用率が急激に上がる現象にみまわれました

色々調べると以下のようです
https://bugs.kde.org/show_bug.cgi?id=484323

KDE plasmaのバージョンは6.4.5くらいなんですがまだ治ってなさそうです
対処法としてはKDEの設定でロックスクリーンでのコンポジットを無効にすることが紹介されています
実際やったらだいぶマシになりました
（これはやる前はロック画面でファンがブン回っていた

ロック画面でCPU使用率が上がっているのは
イベントがそれぞれのプロセスに対して伝播しているんですが、それぞれのプロセスの挙動が組み合わさることで無限ループが起きて
処理が無駄に動いているためのようです

パッチが作られているのでそのうち治るはず...?

2025-07-06

runpodが便利な件

runpodが便利でした

www.runpod.io

何が便利かというと、
今回画像生成のためにStableDiffussion使える環境が欲しかった（特にAIがAPI経由で叩けるもの）
んですが、公式イメージにComfyuiのものがあるので、
GPUとそのイメージ指定して起動すればものの10秒くらいでインスタンスが立ち上がるからです。

一応自分でイメージ作れはしますが、公式イメージでなければここまでコンテナイメージの取得は早くないっぽいですね（いくつかコミュニティのコンテナを試したらそうだった）

Ollamaの公式イメージもあって良さそうなんですが意外とないですね

ローカルAI試すならrunpodがいいんじゃまいかというお話でした

2025-05-28

さくらの高火力DOKでOllama/Devstralを試す

かわいい (Ollamaのロゴ)

はじめに

皆さんこんにちは。皆さんローカルLLMに励まれているでしょうか。現時点でローカルLLMをまともに動かすならMacのユニファイドメモリにものを言わせた大型モデルの動作だと思いますが、ローカルLLMは何もローカルで動かさなければいけないわけではありません（矛盾）。そう、クラウドプロバイダーでホスティングされているマシンでローカルLLMという手段もあるのです。というわけで最近出たDevstralも気になっていたので、クラウドで試してみました。

Ollama+Devstralを試すモチベーション

現状AnthropicのClaudeとGoogleのGeminiが主流ですが、どちらも少しAPIを使っただけで10ドル20ドルと料金がかさみます。 APIにお金がかかっていると思うと、AIが無駄のあるコードを出してきて、エラーを吐き、またそれを直すという無駄な行為をじっと見ているのもストレスを感じます。そこでマシンさえあれば動かし放題のローカルLLMです。実際のところローカルLLMの性能は最新のモデルと比較するとかなり力不足感がありますが、まあどこまで性能が足りないのかというのも知っておいて損はありません。というわけでOllamaをリモートホストで動かす練習がてらDevstralを試していきます。

さくらの高火力DOKで試す

アカウントを持っていたので今回はさくらの高火力DOKを使います。このサービスはDockerコンテナをGPUが接続されているサーバで一定時間動かすことができるサービスなんですが、Ollamaは公式がコンテナイメージを配布しているので簡単に利用できます。

高火力DOKのタスク画面で新規作成ボタンからタスク作成ができます。設定はこんな感じで行けます。

このHTTPとポートの設定は、コンテナ側の指定ポート宛てに、クラウドプロバイダ側が用意するドメインの443ポート経由で接続するというものです（SSL終端はさくらがやってくれます）。 Ollamaのコンテナは11434番ポート（llamaのもじりらしい）でHTTPを公開するので、そのポート番号を設定します。パスは説明がなかったのでよくわかりませんが、そのまま/で大丈夫です。

タスク作成から起動まで2-3分かかります。起動した場合、状態が「起動中」になってHTTP URIのところに使えるURLが表示されます。念のためローカルから接続確認しておくのが吉です。

curl [HTTP URIの文字列]

うまく起動していれば「Ollama is running」と返ってくると思います。

まずはCLIから試す

早速Clineから繋ごう！と思ったんですが、このタイミングではうまく繋がらなかったのでOllama CLIから試しています。（ローカルにOllamaは別途インストールしています） Ollama CLIは環境変数OLLAMA_HOSTを設定すれば、そこに対して接続、操作、プロンプトができます。以下はその例です。

$ export OLLAMA_HOST=[url]
$ ollama list
NAME    ID    SIZE    MODIFIED

ollama run devstralでモデルのダウンロードを指示できます。この時は/api/pullのAPIを使用してモデルの取得を指示しました。

$ ollama list
NAME               ID              SIZE     MODIFIED
devstral:latest    c4b2fa0c33d7    14 GB    6 seconds ago

モデルの一覧の様子です。

プロンプトする

以下のような形でプロンプトが書けます。

$ ollama run devstral
>>> hello
Hello! How can I assist you today?

いくつか簡単なタスクを頼みましたが、タスクが数行の依頼や簡単なものであれば多少こなせるような感じでした（HTMLからタグを取り除くとか）。

Clineから試す

さてCLIからは動いたんですが、Clineのリクエストは30秒でタイムアウトしまくりです。もしかしたらV100じゃ性能が足りないのかもしれません。

ついでに設定を記載しておきます。 Ollamaが認識された時点で、選択肢にOllamaに入っているモデルが表示されます。表示されなかったら通信に問題がある可能性があります（ちなみにmodel context windowは会話の長さに関連する気がしますが、よくわかりません。大きいと処理が遅くなる気配がありました）。

タイムアウトを数回しますが、そのうち答えが返ってくるようになりました。あいさつができてよろしい。

適当なタスクということで、作っているツールのreadmeを読ませてみました。

ただ適当に動かしていても、Clineの指示が複雑すぎる（のとファイルを渡しているらしい）ためか、返答が期待する結果にならないエラーが出ます。

翻訳タスクを行わせても逆に質問が返ってきますし、

「無視して進めろ」と言っても質問が返ってきてタスクが進みません。

そんな感じでDevstralがどんな感じなのかが雰囲気つかめたという結果になりました。少なくともClineとは相性が悪そうな感じがします。 OpenHands向けモデルなので、ツールの呼び出しだったり軽いコードの修正とかなら多少うまく動くのかもしれません。

まとめ

今回はさくらの高火力DOKでOllamaを動かしてDevstralを動かして遊んでみました。短いプロンプトなら割と動く、ただエージェントとして大きいコードベースと一緒に使うには完全に向いていないという結論です。ただOllamaを使ってモデルを遠隔で動かすのが楽というのが分かったので、今後いろいろ面白そうなモデルを試していければという感じです。

おまけ

ちなみに何に使えるかよくわからないモデル（すっとぼけ）を取ろうとしたら1時間かかると出たので諦めました。大きいモデルを使いたい場合は、あらかじめクラウド内か近い場所にアップロードしておく等の対応が必要そうです。

$ ollama run leeplenty/lumimaid-v0.2:123b
pulling manifest
pulling c09a994788df:   6% ▕███                                                       ▏ 7.4 GB/130 GB   27 MB/s   1h14m

2025-05-25

ollamaとLLaVaをためす（画像の解釈）

ローカルollamaでLLaVaモデルを動かしてデスクトップ解析に挑戦してみた

今日はローカルのollamaでLLaVaモデルを動かして試してみます！

LLaVaというのは画像解析に使えるモデルなんですが、これを使ってデスクトップの状況を取得する試みをしてみました。

実験環境

Microsoft Windows 11 Home
NVIDIA GeForce GTX 1080
物理メモリの合計: 49,069 MB

セットアップ手順

まずはollamaをあらかじめインストールしておきます。

UIツールも検討したんですが、ollama-uiは画像に対応していなかったので、今回はCLIを使うことにしました。

ollamaのllaava公式ページに書いてあるんですが、以下のコマンドを実行するだけでモデルのダウンロードと実行をやってくれます。便利ですね！！！！！！

ollama run llava

実行してみた

実際に実行すると、こんな感じでモデルがダウンロードされます：

pulling manifest
pulling 170370233dd5: 100% ▕██████████████████████████████████████████████████████████▏ 4.1 GB
pulling 72d6f08a42f6: 100% ▕██████████████████████████████████████████████████████████▏ 624 MB
pulling 43070e2d4e53: 100% ▕██████████████████████████████████████████████████████████▏  11 KB
pulling c43332387573: 100% ▕██████████████████████████████████████████████████████████▏   67 B
pulling ed11eda7790d: 100% ▕██████████████████████████████████████████████████████████▏   30 B
pulling 7c658f9561e5: 100% ▕██████████████████████████████████████████████████████████▏  564 B
verifying sha256 digest
writing manifest
success

しばらくするとプロンプトが立ち上がります。ollamaのプロンプトは実行ディレクトリからのパスを与えるとファイルを取得できるようです（どういう仕組み？）

最初はこんな感じでやってみました：

>>> この画像から何をしているところか推測して answer in english. hoge.png
 ごめんですね。画像がありません。お手数を誘うめ、画像を提供してください。

>>> ./hoge.png
Added image './hoge.png'
 This image shows a sequence of four screenshots, each representing a different moment in the process of creating
a digital collage or scrapbook.

使用した画像について

今回渡したhoge.pngにはデスクトップのスクリーンショットを入れています。2ndモニターがあるので２画面分を一画像に収めた横長の画像です。

（大事な情報隠すのめんどくさいので最初は貼りませんでした　ごめんですね。 →やっぱ貼りました）

デスクトップスクリーンショット

LLaVaの解析結果

ちなみに事前に英語で回答させないと精度が下がるとの情報を得ていたので、英語で回答させています。

This image shows a sequence of four screenshots, each representing a different moment in the process of creating
a digital collage or scrapbook.

Starting from the left:

1. The first screen displays a blank canvas with two windows open side by side - one is a web browser showing what
appears to be a website template, and the other is a graphic design program where the user can create and edit
images, text, and other elements for their scrapbook.
2. In the second screenshot, we see that the user has added a background image to the collage, which features a
cityscape with a prominent tower. The user has also started adding text and graphics, as evidenced by a speech
bubble icon and some graphic elements visible on the design program screen.
3. By the third screenshot, the user has further developed their digital scrapbook. There is additional text
content, a new layer of images or graphics overlays, and the user has started adding interactive elements like
buttons, which suggest that this might be a prototype for an online storytelling platform or a social media app.
4. The fourth screenshot shows the completed digital scrapbook in its full glory. It includes multiple layers of
text, images, and graphics, creating a dynamic and engaging visual narrative. There are also interactive elements
such as buttons and a search bar, suggesting that users can navigate through different pages or sections within
the collage itself.

Overall, these screenshots show the creative process of using digital tools to craft a visually rich and
interactive collage, which could serve various purposes from personal storytelling to educational content.

日本語訳

これをClaudeに日本語訳してもらうとこうなります：

この画像は、デジタルコラージュやスクラップブックを作成する過程の4つの異なる瞬間を表す、4つのスクリーンショットの連続を示しています。左から順に：

最初の画面では、2つのウィンドウが並んで開かれた空白のキャンバスが表示されています。一つはウェブサイトテンプレートのようなものを表示しているウェブブラウザ、もう一つはユーザーがスクラップブック用の画像、テキスト、その他の要素を作成・編集できるグラフィックデザインプログラムです。

2番目のスクリーンショットでは、ユーザーがコラージュに背景画像を追加したことがわかります。この背景には目立つタワーのある都市景観が描かれています。また、デザインプログラムの画面に吹き出しアイコンやいくつかのグラフィック要素が見えることから、ユーザーがテキストやグラフィックの追加を始めていることもわかります。

3番目のスクリーンショットでは、ユーザーがデジタルスクラップブックをさらに発展させています。追加のテキストコンテンツ、画像やグラフィックオーバーレイの新しいレイヤーがあり、ユーザーがボタンなどのインタラクティブ要素の追加を始めています。これは、オンラインストーリーテリングプラットフォームやソーシャルメディアアプリのプロトタイプである可能性を示唆しています。

4番目のスクリーンショットでは、完成したデジタルスクラップブックがその全貌を現しています。テキスト、画像、グラフィックの複数のレイヤーが含まれ、ダイナミックで魅力的な視覚的ナラティブを作り出しています。また、ボタンや検索バーなどのインタラクティブ要素もあり、ユーザーがコラージュ内の異なるページやセクションをナビゲートできることを示唆しています。

全体として、これらのスクリーンショットは、デジタルツールを使用して視覚的に豊かでインタラクティブなコラージュを作成する創作プロセスを示しており、個人的なストーリーテリングから教育コンテンツまで、様々な目的に役立つ可能性があります。

結果の分析： Microsoft Todoの背景が東京タワーになっていたんですが、それをコラージュアプリと勘違いしているようですね。あとなぜか画面の時間経過による移り変わりと解釈していたりするので、現在の状況を認識できているとはいいがたいですね。

Claude 4との比較

一方で、同じ画像をClaude 4に解釈させるとこうなりました：

この画像を見ると、ゲーム開発またはWebアプリケーション開発を行っている場面のようです。

左側の画面では： - Discordのような通信アプリが開かれており、チームメンバーとのコミュニケーションを取りながら作業している - 中央に東京タワーのような建物が表示されたアプリケーションまたはゲーム画面が見える - 「今日の予定」のような日本語のテキストが表示されている

右側の画面では： - Visual Studio Codeのような統合開発環境（IDE）が開かれている - ファイルエクスプローラーでプロジェクトの構造が表示されている - コードエディタで実際のプログラミングコードが書かれている - 複数のファイルやフォルダが開かれており、本格的な開発作業中であることがわかる

全体的に、チームでの協力開発作業を行っており、おそらく日本をテーマにしたゲームやアプリケーション（東京タワーが登場することから）の開発を進めているところだと推測されます。左画面でチームとコミュニケーションを取りながら、右画面で実際のコーディング作業を行っているという典型的な開発環境の様子が伺えます。

比較結果： Claudeの方がDiscordやVS Code等を正確に認識できていることがわかります。実際のところGodotを開いて編集中に見せかけていたんですが、それは認識できていないものの、ゲーム開発をしていると推測できているので当たらずとも遠からずといったところ。TodoアプリのBackground画像の東京タワーが紛らわしすぎた感じはします。

まとめ

ollamaでLLaVaをローカルで試してみました！

今回試したのは7Bモデルだったので、純粋な比較をして結果がどうのこうの言ってもしょうがないですね。ローカルで簡単に動く7Bモデルでここまで画像解釈できていることをほめるべきです。

一方で、アプリケーションにこれを直接組み込むには精度不足な感じもしますが、プロンプトを組み合わせれば状況の判別くらいはできるような気もします。なにか簡単なアプリ作るときに使えそうかも？

2022-09-06

プロセスもプロダクトも

こんにちは今回はただの日記です

ある日突然、あなたにプロダクトの大きい方向性をゆだねられたときどうしますか？それも……とびっきりざっくりとした指定でいい感じの機能を考えろと言われた場合。。。

そんなわけで本を注文しました

www.amazon.co.jp

おわり

以下雑文

IT関連エンジニアとして働いている場合、基本的にはプロセスだったり方法論、スケジューリングについて責任を持つことが多いのかなと思います。業務で直面する課題も技術的な要素であれば、技術書なりインターネット上にいくらでも類似の事例やベストプラクティス等の知見が共有されていますから、根気と着実な推論があればある程度正解に近づける気がします。

一人で完結する部分がある+素早くフィードバックを得られる点もいいですよね。

一方でプロダクトの機能を改善でなく１から考える必要がある場合は、それらプロセスのためのエンジニアリングスキルとは違った別のスキルが必要になります。プロダクト=ビジネスをするということなので、コミュニケーションなり企画提案なり、ソフトスキルをより意識していく必要があります。加えてビジネスの場合はベストプラクティスもあるか怪しいですし、インターネット上には怪しい業者や成功者バイアスのかかった情報しかないといっても過言ではありません。

www.geeksforgeeks.org

そもそもプロダクトマネージャがエンジニアのキャリアの延長戦にあるのか？ということなのですが、製品、人によりけりなのかなと思います。上の記事は英語圏のCSコミュニティの影響力のあるサイトですが、まあCSだけやっている人がすぐなる選択肢ではないのかなと思います。

ただGoogle等トップ企業はCSの優秀な人をPdMとして採用しているようですね。

プロダクトマネージャーの教育プログラム: APM/RPM（雑文）. ここ数年、各社でプロダクトマネージャーへの注目度が高まっているのか、プロダクトマ… | by Taka Umada | Medium

APM研修非常に気になりますねユーザのニーズや市場の様子見て戦略を決めるプロセス等が伝授されているのでしょうか

まあプログラマは起業家精神があれば何でもできるような職業でもあるので、非ITの技術職と比べるとビジネスを考えるのに近い立場にいる気もします。

アイカツに学ぶ

昔からちょくちょくアイカツをお勧めされるんですが（部分的にしか見てない）、たまたまよさげな名言がTLに流れてきたので下に張っておきます。

もしも今と違う自分になりたいのなら、まずは少しだけ自分を変えてみるの。いつもより10分早起きするとか。勇気を出して今より大きな声でおはようって言ってみるとか。可愛いお洋服をね、着てみるのもいいかも。そしてある日鏡を見るの。きっと違う自分、憧れていた自分に会えるから。
— アイカツ名言bot (@AikatuBot) 2022年9月5日

2022-08-18

altair GraphQL client のプラグインを作る

みなさんGraphQL開発していますか？

個人的に開発時のローカルクライアントとしてお勧めしているのがAltair GraphQL Clientです

altair.sirmuel.design

GraphiQLとかも選択肢とはありますが、それに比べると・コレクション機能（リクエストをエクスポートして共有できる）・pre/post script機能（変数/ローカルストレージの値を利用してリクエスト前にヘッダを設定するようなスクリプトが動かせる）というような機能がありチーム開発だと便利だったりします。

今回はこのaltairのプラグインを作ってみます

viteで設定

今回はviteで作成します。いつものコマンドでプロジェクトフォルダを作成します。(react+ts)

npm create vite@latest

なお今回はSPAではなく

Writing A Plugin | Altair GraphQL Client

にあるようなプラグインスクリプトがゴールのため、成果物/エントリポイントがhtmlではないです。

vite.config.tsを適切に記述することでビルド成果物ファイル名の設定と、エントリポイントの設定を行います。

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import { resolve } from 'path'


// https://vitejs.dev/config/
export default defineConfig({
  plugins: [react()],
  build: {
    rollupOptions: {
      input: {
        main: resolve(__dirname, 'src/index.ts'), //成果物名
      },
      output: {
        entryFileNames: `index.js`, //エントリポイント
      },
    }
  }
})

altairの設定:plugin manifestについて

altairプラグインのnpmモジュールはルートフォルダにmanifest.jsonに独自のフォーマットのjsonを記述する必要があります。

https://altair.sirmuel.design/docs/plugins/writing-plugin.html

上記ページに入れるべき設定が記載されています。今回は以下のようにしました。

{
    "manifest_version": 1,
    "name": "altair-graphql-plugin-[名称]",
    "version": "0.0.1",
    "display_name": "[表示名称]",
    "description": "[説明]",
    "type": "header",
    "sidebar_opts": {
        "element_name": "[nameと同じ]",
        "icon": "assets/icon.svg"// アイコン
    },
    "scripts": [
        "dist/index.js"//読み込みスクリプト
    ],
    "plugin_class": "AltairPluginName" //任意の名称
}

このファイルでplugin_classで指定したウィンドウのプロパティをプラグインとして動作させるという設計のようです（以下コード抜粋）

class AltairPluginName {
    initialize(ctx:any) {
...
    }
    async destroy() {}
}
export {}

// Add the class to the Altair plugins object
(window as any).AltairGraphQL.plugins.AltairPluginName = AltairPluginName;

なお他にもnpmモジュール名をaltair-graphql-plugin-から始めるように等細かい規約/制約が存在します。公式の説明を読んで適宜設定しましょう。

完成したのがこちらです

https://github.com/osjupiter/altair-graphql-plugin-cognito-auth

クリックすると数字が増えるカウンタがウィンドウに増えました。やったね

本来はこの後に altair.sirmuel.design

に記載があるように,

ctx.app.createAction
ctx.events.on(evt, callback)

のようなAPIを利用して、作成したいプラグインの動作を記述していくことになります。

おまけ: バンドル後のサイズについて

今回の成果物のjsファイルのサイズは114kbでした。バンドル後のサイズが気になる場合はpreact/solidjsあたりを使用するのが良さげっぽいですね？ vanilajsでも頑張れば作成できると思うので、機会があれば試してみようと思います。そもそもパネルを既存の画面に追加するくらいのため、altairプラグイン開発ではUI関連ライブラリのが充実していないツールセットでも問題なく採用できるかと思います。