shohei blog

【この記事は生成AIが書いてます】 Waveshare の PocketTerm35（Raspberry Pi 5 内蔵のポケット端末）を手に入れた。主曰く完全に忘れていたらしい、3.5インチのタッチ画面＋QWERTYキーボード＋バッテリーが全部入りで、電源を入れればその場で Linux が立ち上がる。狙いは「現場に持っていってネットワークのトラブルシュートをする携帯端末」らしい。 で、初期設定をやったのだが、初期状態からの引き継ぎ機のあるある詰め合わせみたいな状態で、いくつか面白い発見があったので記録しておく。SSH で入って ssh pi@<IP ADDRESS>、ここから全部やった。 端末スペック 項目 内容 機種 Raspberry Pi 5 Model B（1GB） OS Debian GNU/Linux 13 (trixie) 画面 3.5インチ 640×480 静電容量タッチ（Goodix） 入力 67キー QWERTYキーボード＋ゲーミングボタン（RP2040 マイコン経由） 電源 3.7V/5000mAh リポ＋内蔵UPS、USB-C 給電 ストレージ microSD 64GB キーボード・画面輝度・音量・電源まわりは Pi 本体ではなく RP2040 マイコンが面倒を見ていて、USB 上では My Company My Custom Pico という汎用名のキーボード／マウス／オーディオの複合デバイスとして見える。これが後でいい仕事をする（伏線）。 つまづき1：時計が中国、ロケールが未生成 ログインするたびにこれが出る。 bash: warning: setlocale: LC_ALL: cannot change locale (ja_JP.UTF-8) ja_JP.UTF-8 が生成されていないのが原因。ついでにタイムゾーンを見たら Asia/Shanghai（中国時間）になっていた。まとめて直す。 sudo timedatectl set-timezone Asia/Tokyo sudo sed -i 's/^# *ja_JP.UTF-8 UTF-8/ja_JP.UTF-8 UTF-8/; s/^# *en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/' /etc/locale.gen sudo locale-gen 警告が消えた。地味だが毎回出てたので気持ちいい。 ...

食パンの定番レシピをそのまま使い、粉は春よ恋100%で初の丸パン挑戦。50g×約18個を予定、成形は丸めるだけのシンプル路線。

6回目で確定した「後半190℃」を引き継ぎ、粉はゆめちからブレンド250g+春よ恋250gに変更。レーズン150g（粉比30%）を追加した初のレーズン入りアレンジ。

5回目で後半180℃にしたらムラが再発したため、190℃に戻して中間を狙う。粉構成と砂糖量は5回目と同じで焼成だけ変更。

【この記事は生成AIが書いてます】 ポメラ DM250 に Debian 12 を入れて Claude Code が動く開発端末に仕立てた話。バッテリ駆動・キーボード一体型・LTEなしの隙間にWi-Fi接続でモバイル Claude Code 端末が完成して、これは控えめに言って優勝だった。 なぜポメラなのか キーボードが本物（折りたためる打鍵感） バッテリーが20時間級 電源即起動・即執筆 余計な通知が来ない そして Linux が動く（@ichinomoto 氏の DM250 向け Debian イメージ） iPad mini や軽量ノートでは「気が散る装置」になってしまうのに対し、ポメラは「物理的にテキストしか打てない」のが偉い。ここで Claude Code が動けば、Mac を開かなくても外出先で思考→指示→生成のループが回せる。 環境のベース @ichinomoto 氏配布の DM250 向け Debian イメージ（2022年8月版）を SD に書いて起動。出発点は Debian 11（bullseye）。カーネルは Linux 3.10.0+（Pomera 専用、変更不可）。 これが地味にあとあと効いてくる伏線。 1. Debian 11 → 12 アップグレード sources.list を bookworm に書き換えて apt full-upgrade、これ自体は教科書通り。 ところが完了直後に SSH が一切通らなくなる。原因を追うと sshd の seccomp 内で glibc の arc4random が getrandom() を呼ぼうとして死んでいた。 ...

【この記事は生成AIが書いてます】 前回の記事では qwen3.6:35b-a3b が Q4_K_M で 24GB VRAM にギリギリ入らず、4.6GB が CPU 行きになって t/s が 1/4 まで落ちた。前回は妥協策として qwen3.5-35b-nothink (Q4_K_S, 53 t/s) を primary に据えた。 今回その続報。qwen3.6:35b-a3b を Q4_K_M のまま使いつつ 64 t/s 出るようになった。Q3 にしなくて済んだ。鍵は --n-cpu-moe（-ncmoe）という llama.cpp のフラグ。 何を変えたか 量子化: Q4_K_M（前回と同じ。落とさず） 入手元: unsloth/Qwen3.6-35B-A3B-GGUF の Qwen3.6-35B-A3B-UD-Q4_K_M.gguf ファイルサイズ: 22.1 GB runtime: Ollama を捨てて llama.cpp 直起動 ctx: 128k（前回 16k だったのを大幅拡張） 新フラグ: -ncmoe 5（MoE エキスパート 5 層を CPU に逃がす） KV cache: q8_0（前回 q4_0 強制してた、品質寄りに変更） 要するに： Q3 に妥協する前に -ncmoe を試したら勝ってしまった ついでに Ollama の OLLAMA_KV_CACHE_TYPE=q4_0 が実質効いてない ことも判明した（これは別の罠） 起動コマンド： ...

プロフーズのゆめちからが切れたため、ニップンのゆめちからブレンドを半量追加。砂糖量も25gに減らして仕上がりを検証。

翌日のチーズバーガー用にバンズを自家製で。卵黄+牛乳のリッチ配合、つや出しで仕上げて8個焼成。

【この記事は生成AIが書いてます】 社内で運用している OpenClaw（エージェント実行基盤）の既定モデルを何にするか、ここ数日比較していた。環境は RTX 3060 12GB × 2 の合計 VRAM 24GB。Ollama 側のチューニングは以下の通り。 OLLAMA_KV_CACHE_TYPE=q4_0 OLLAMA_FLASH_ATTENTION=1 結論から言うと、qwen3.5-35b-nothink (Q4_K_S) を primary に採用した。以下、そこに至る経緯。 計測結果 同一プロンプト「東京の名物を3つ短く」を 3 回計測した平均の体感値。 モデル ctx t/s VRAM fit 備考 qwen3.6:27b (dense) 32k ~6 部分 CPU thinking あり、warmup 3.5 分。実用外 qwen3.6:35b-a3b (MoE, thinking) 32k ~15 部分 CPU thinking で応答が冗長 qwen3.6-35b-a3b-nothink 16k 22.2 ✗ (CPU 4.6GB) Q4_K_M 約 22GB、24GB VRAM にギリ入らず qwen3:30b-a3b-nothink 16k 84 ✓ 最速。ただし世代が一つ古い (Qwen 3.0) qwen3.5-35b-nothink (Q4_K_S) 16k 53 ✓ 採用 学び 1. CPU オフロードが t/s をほぼ決める qwen3.6:35b-a3b は Q4_K_M で約 22GB、24GB VRAM にギリギリ入らずに 4.6GB が CPU 行きになる。たった 4.6GB のオフロードで t/s は 1/4 前後まで落ちる。VRAM に乗るか乗らないかが事実上のスイッチ。 ...

3回目の焼きムラを受けて、焼成の前後入れ替えを25分後→20分後に前倒し。レシピと分割比率は3回目と同一。