カテゴリー: 技術系memo

  • メモリ16GBのPCでローカルLLMを動かしてみる

    Intel Core Ultra5、メモリ16GBのLet’s Note SC6で、ローカルLLMを動かしてみた。最初は、WSL上のOllamaでGemmaを動作させてみたが、CLIで他の人に使ってもらうには、少し敷居が高かった。今回は、GUIでLM Studioを使ってみた。

    LM Studioは、GUIツールなので、インストールも楽ちんだった。起動させるのもGUI、モデルを探してダウンロードするのもGUI、当然チャットの部分もGUIで、回答もリッチテキストでよい。便利ではあるのだけど、モデルのダウンロードは少し大変だった。PCスペックに対して、動くかどうかの判定はついているだが、モデル数が多すぎて、選ぶのが大変だった。たとえば、GoogleのGemmaで探しても、Googleのものもあれば、他の組織がチューニングしたものもある。どれが動くのか、見て選んでいく必要がある。ここが結構大変だった。

    Intel Core Ultra5、メモリ16GBのLet’s Note SC6で実際に動作させてみたのは、以下のモデル。

    • Gemma-4-12b-qat
    • Gemma-4-e2b
    • Llama-3-ELYZA-JP-8B
    • Qwen3.5-9b
    • meta-llama3.1-8b-instruct

    Gemma4は、最新なので使えるメモリで使えるサイズのモデルを選択した。12B(120億パラメータ)もサイズが7.2GBでなんとか動作した。

    Llamaはmeta社が開発したモデルだけれど、かなり派生が多いモデルで選ぶのが大変だった。どれがよいのかわからないので、日本語に特化したELYZAを選んでみた。その後、比較のため、Llama3.1のモデルも使ってみた。

    Qwen3は、最新モデルだと少ないメモリで動くモデルがなく、少し前のモデル(3.5の9B、90億パラメータ)を試してみた。

    ここに挙げたモデルは、メモリ16GBのWindows11のPCで動作できた。オンラインのモデルと比べると雲泥の差の応答速度だけれど、まぁまぁの速度で返答の文字が表示されてくる。タスクマネージャーをみてみると、CPUはそれほど使っていないが、GPU(Intel Graphics)は100%まで使って回答をしてくる。

  • MariaDBのバージョンアップでハマった話

    MariaDBを、10.5系から11.8系にバージョンアップをしたのだが、このときの一連の作業でハマったことを書いておく。誰の役に立つのかはわからないけれど。

    なにが起きていたかというと、「10.5系のDB状態が正しい状態ではなかった」と「11.x の新しい仕様制限」の2つの組み合わせで、複合的なエラーが発生して解決できなかった。

    「10.5系のDB状態が正しい状態ではなかった」とは?

    • DBは正常終了させたはずだが、クラッシュした状態になっていた。
    • 以前に、10.5系にバージョンアップしたときに、DBのアップグレードをしたが、そのときから怪しげなログは出ていた。使えるからと放置していたのが、ここにきて問題が顕現した。

    「11.x の新しい仕様制限」は?

    • 11.x からクライアント接続時のSSL要求が厳格化された。mariadb-upgrade –skip-ssl で回避。
    • 10.5 時代の Redo ログ(ib_logfile0)が未消化(クラッシュ)のまま放置されていた。11.x系では、仕様上、直接復旧ができなかった。
    • 10.5 時代で使えていた設定が 11.x で完全撤廃された、というのもあるが、これにはハマっていないはず。

    いろいろと試したけれど、失敗したことなど。

    起動時のエラーが、.errファイルに記録されておらず、エラーログを探しまわることに。messagesにも記録がなく。データファイルの保存場所にあったファイルの更新日付からエラーが記載されたファイルを特定した。wsrep_recovery.failに記録されていた。

    一度、11.8を消して、10.5系のクラッシュの復旧ができる10.11系をインストールして、復旧を試みた。結局、MariaDBの起動時に復旧ができずに、クラッシュして、MariaDBは起動できなかった。

    Redoログファイル(ib_logfile*)をリネームして起動を試す。これは、「MariaDB 11.x(および 10.8 以降)ではセキュリティ・データ保護のための仕様が変更され、未修復(クラッシュ状態)のデータがある状態で ib_logfile0 を削除・退避してしまうと、起動を完全に拒否する仕組み」によって、成功せず。

    最終的にやったこと(成功したもの)

    結局、既存のデータベースファイルを使ったバージョンアップは諦めて、MariaDBを削除(アンインストール)して、データファイルを消して、新規に新しいバージョンのMariaDBをインストールして、初期化してMariaDBを起動させた。ちゃんと起動した後に、ダンプファイルから復元した。

    0. DBのバックアップ用にダンプファイルを取得(OSのバージョンアップ前にやっておく)

    1. MariaDBを削除(アンインストール)

    2. /var/db/mysql を退避・空にする

    3. 新しいバージョンのMariaDBをインストールする

    4. 「mariadb-install-db –user=mysql –datadir=/var/db/mysql」でDBの初期化(システムデータベースをインストール)

    5. MariaDBを起動する

    6. ダンプファイルからリストアする

    7. 復元したデータ構造を MariaDB 11.x 用に最適化(アップグレード検証)して再起動する。

    これで何とかなった。

    なんだかんだで、新しいバージョンをインストールしてダンプから戻すが一番楽かもしれない。

  • Proxmox VE上の仮想マシンを削除する方法

    Proxmox VE上の仮想マシンを削除する手順のメモ

    1. Proxmox VEの管理画面にログインする

    2. サイドメニューから、削除する仮想マシンを選ぶ

    3. 画面の右上側の「Help」の横の「More」をクリックして、「Remove」を選択する

    4. 確認画面で、IDを入力する

    5. 必要に応じて以下のオプションにチェックを入れる
    Purge from job configurations (ジョブ設定から削除する)
    Destroy unreferenced disks owned by guest (ゲストが所有する参照されていないディスクを破棄する)

    6. 「Remove」をクリックする

    7. 下部のTasksを確認して、StatusがOKになっており、リストから消えれば削除は完了。ステータスがErrorになっているときは消えていないので、内容を確認して削除する。

  • Google Workspace Business Standardは、Cloud Identity Freeのライセンス。

    Google Workspace Business StandardやGoogle Workspace Business Starterは、Cloud Identity Freeのライセンスになる。GCPW(Google Credential Provider for Windows)は、利用できるが、設定できる部分が狭い。

    ログインアカウントをGoogle Workspaceのアカウントで統一するだけなら、これだけでも十分。

  • GCPWを使ってログインしたときのWindowsの権限

    GCPWを使ってログインすると、Windowsの権限はユーザ権限になる。

    Google Workspaceの管理画面で、GCPWの設定で、ログインするユーザにAdministrator権限を割り振るためには、「Business Plus 以上、または Enterprise エディション、Cloud Identity Premium が必要」になる。

  • GCPWで設定されたPCに新規Google Workspaceのアカウントでログインしたときの挙動

    GCPW(Google Credential Provider for Windows)の設定をしたWindows11に、新規で作成したGoogle Workspaceのアカウントでログインすると、次の挙動になる。

    1. 「仕事用アカウントでログイン」を選択する。

    2. メールアドレスを入力する。

    3. パスワードを入力する。

    4. 「ようこそ」画面が表示される、「確認しました」をクリックする。

    5. 新しいパスワードの入力画面が表示されるので、パスワードを変更する。

    6. 同意画面が表示されるので、同意する。

    7. Windowsの初回ログインが始まる。

    新しく作成したGoogle Workspaceのアカウントは、初回ログインで、パスワード変更が必要になるのでパスワードはどうするのかと思ったが一連のログインの流れにパスワード変更も組み込まれていた。

    ちなみに、ログインしたGoogle Workspaceのアカウントはユーザ権限になる。アドミン権限はついていないので注意が必要。

  • Windows 11 Proのライセンスには「仮想環境利用権」は含まれていない

    Hyper-Vを使ってWindows 11 Proの仮想マシンを作成する際、ふと疑問に思ったので調べてみた。それは、「Windows 11 Proを持っているので、物理PCと仮想PCを1台ずつ使えるのでは?」ということ。

    調べてみてわかったのは、Windows 11 Proのライセンスには、Windows Serverのような「仮想化利用権(Virtualization Rights)」は含まれていない、ということ。Windows Server Standardには、ライセンスの中に仮想環境でWindows Serverを実行する権利が含まれている。一方で、Windows 11 ProはクライアントOSであり、

    • Windows 11 Pro
    • Windows 11 Pro for Workstations

    のいずれも、仮想マシンを追加で利用する権利は付与されていない。Hyper-Vは使えるが、ライセンスは別問題ということ。Windows 11のワークステーション環境で、もう1つワークステーション環境を動かそうとすると、Windows 11のライセンスを購入しないといけない。

    普段、Windows Serverを使っていると、コンシューマ向けのWindows 11も仮想環境を1つ持てるような感覚になるけれど、別途ライセンスが必要なので注意。短期間であれば、マイクロソフトのサイトから、Windows 11 Enterpriseなどの体験版イメージを使って検証することはできるけれど。

    https://www.microsoft.com/ja-jp/evalcenter

  • Veeam Backup & ReplicationでProxmox VEのバックアップするときはライセンスに注意

    Veeam Backup & ReplicationでProxmox VEのバックアップするときはライセンスに注意が必要。Proxmox VEは、Veeam Backup & Replicationのホストライセンスに対応していないためだ。

    Veeam Backup & ReplicationでVMware ESXiのバックアップを取得しているときは、ホストライセンスを使っていると、仮想サーバのバックアップを台数に関係なく取得できる。この状態から、VMware のESXiライセンスが高いからとProxmox VEに仮想基盤を変えると、Veeam Backup & ReplicationはProxmox VE用のホストライセンスに対応していないので、個別のバックアップライセンスに買い替える必要がある。そうすると、バックアップ費用が高額になるため、注意したほうがよい。

  • Veeam Backup & Replicationのコンフィグバックアップはバックアップコピーできない

    Veeam Backup & Replicationのコンフィグバックアップを自動で取得している。これをバックアップコピーで、遠隔地に保存にも保存しようとしたができない。Veeam Backup & Replicationの設定バックアップはBackup Copyのウィザードで選択できないので、バックアップコピーができない。

  • 日経ネットワークの「AIとネットワーク運用」の特集がよかった

    日経ネットワーク2026年5月号の「AIとネットワーク運用」の特集がよかった。

    どういうシーンで、どういう活用をしているのか、のリアルがあり、参考になった。自分でも怪しいログの解析や解説には、LLMを使うけれど、便利。そういう使い方の例もあり、他にもやっている人がいると思うとなんとなく励みになる。

    あとは、セキュリティ情報をエージェントで集めるのはよいかもしれない。情報収集して、記録して、チャットで流す、くらいは良さそう。ラベルか分類までは、LLMでやれるだろうし。使い所は、いろいろとある(そこに気がつくことができれば)。

    日経の雑誌、普通に売っていないので、めんどくさい。定期購読があるから読んではいるけれど。XTECHへの誘導ばかりで、でもネット記事だけになると積読にならなくなって、たぶん読まなくなる。それもあり、XTECHの加入はやりたくない、きっと読まないという自信あり。

    https://xtech.nikkei.com/atcl/nxt/mag/nnw/18/041600243