Lycolog

Grafana Logs Drilldownではフィルタ出来るのにExplore > Lokiでクエリを打ってもログを引けなかった。これを引けるようにするのが目的。

確認環境

nginxのログをFluentBitで拾いLokiに送る構成。

やり方

server: mstdn.lycolia.infoで[error]を含むものを検索する場合、こうしておくと引ける。要点はjson msg="log"で別名をつけること。logのままでは構文エラーになる。

{job="nginx"} |= `error` |= `server: mstdn.lycolia.info` | json msg="log" | msg=~`.*\[error\].*`

|= errorについてはQuery best practices | Grafana Loki documentationで、最初にラインフィルタをかけるとパフォーマンスが上がるということで付けている。

server="mstdn.lycolia.info"を指定するとなぜかうまくいかなかった。

この記事は【研究中】そば米２の続きで、ここ最近で自家製のそば米をいい感じに作る方法を、幾つかの作り方で試行錯誤した時のまとめである。

• 作り方
• 製作パターン
  • そば抜き実 150ml、水 1,500ml、収穫量 100ml
  • そば抜き実 120ml、水 250ml、収穫量 120ml
  • そば抜き実 106g、水 250ml、収穫量 93g
  • そば抜き実 120g、水 300ml、収穫量 104g
  • そば抜き実 125g、水 300ml、収穫量 108g
• まとめ
• あとがき

作り方

鍋は直径20cmで満水容量3.0Lのものを使用している。

1. ボールに40度のぬるま湯をたっぷり入れ、そば抜き実を30分漬けておく
2. 鍋に水を入れ、強火で沸騰させる
3. そば抜き実を鍋に入れ、中火にし、蓋をする。そのままだと吹きこぼれるので、吹きこぼれそうになったら弱火に落とす。このまま15分茹でる
4. 15分経過したら火を止め、更に15分放置する（蒸らす）
5. ざるに移しぬめりが取れるまで籾摺り洗いする
6. ざるに平たく並べてベランダに干す
7. 二日ほど天日干しする

※雨天の場合、部屋干しも可能。換気扇を回している風呂場など、洗濯物を部屋干しできるような通気性の良い場所で干すとよい。

製作パターン

そば抜き実 150ml、水 1,500ml、収穫量 100ml

このレシピではぬめり取り時の廃棄が多く、歩留まりが大変悪かった。収穫量が容積ベースであてにしづらいが、それでも66.66%という収穫率のため、非常に歩留まりが悪いことがわかる。

詳細は【研究中】そば米２を参照。

そば抜き実 120ml、水 250ml、収穫量 120ml

茹でたそば抜き実を干している風景。

干し終わり、そば米となったものをカップで計量した時の写真。この時はまだ容積ベースで、重量ベースで測るという発想がなかった。

そば抜き実 106g、水 250ml、収穫量 93g

この時から重量ベースに切り替えたが、容積ベースでも計っていた。

干し終わった後の巻き簾。まだ余裕があり、もっと積めることがわかる。

干し終わった後の状態。容積が干す前より増えていることがわかる。よく見ると隙間が多い。

そば抜き実 120g、水 300ml、収穫量 104g

容積だと160mlくらい。摺り切りがないので正確性はやや微妙な感じもするが、そもそも米と比べると粒がデカいので容積で測ること自体が微妙な気もした。

茹でたそば抜き実を巻き簾に敷き詰めた状態。かなり埋まっているのでほぼ限界に近い。

干し終わった後の状態。干す前は150mlだったのが、200mlくらいまで増えている。やはり隙間が多い。

そば抜き実 125g、水 300ml、収穫量 108g

これまでの結果を勘案し、これがベストだろうというので試した組み合わせ。

容積だと170mlくらい。

茹でたそば抜き実を巻き簾に敷き詰めた状態。乾燥時間とか、収穫時にこぼれないラインだと、今の設備では、これが実運用上の限界だと思う。

干しているときの状態。巻き簾のサイズや、干しかごの入り口の幅からすると、取り回しの良さや、乾きやすさなどはこのくらいが最もベストだと感じた。

干し終わった後の状態。今回は隙間が比較的少なく、170mlくらいに収まっているように見える。

まとめ

水に対するそば抜き実の割合としては40.00%～42.40%辺りが望ましいように感じた。きすみの営農では500g単位で販売されているため、そば抜き実125gで水300mlの組み合わせがキリよく無難だと思う。

また歩留まりについて、そば抜き実の投入量が増えるほど悪化することが傾向から分かった。ただ差は1%程度と、誤差の範疇だとも思うので、そこまで気にしなくてよいと感じた。そば抜き実の投入量は125gが私の環境では最大で、これ以上増やすと巻き簾から溢れたり、密度が上がりすぎて乾きづらそうに感じた。125gでも乾燥後に取り出すときに数粒落ちることがあり、取り扱いとしてはギリギリに感じた。

あとがき

前にも書いたが、そば抜き実からそば米に加工することで、得られるメリットとしては長期保存の実現、調理時間の短縮があると考えている。

長期保存の実現については、実の中にいる可能性がある虫の卵を殺すことができ、虫湧きを予防できることがあると考えている。例えば炊飯した米を干したものである糒は20年持つとされている。調理時間の短縮については事前に茹でて干しておくことで、次回の茹で時間を短縮できると考えている。但しこれは実際に比較して確認したわけではない。

デメリットとしては栄養の欠損、嵩の増加がある。

栄養の欠損についてはゆで汁を捨てることや、ぬめりを取ることで一部の栄養や澱粉が欠損すると考えている。ただ澱粉が減るということは糖質量が減るということでもあるため、低糖質生活の観点から見ると利点である可能性はある。嵩の増加については茹でた時にそば抜き実が割れたり崩れたりするので、容積で計算した時に重量は減っているのに容積は増えていることが起きることを確認している。また、干すときに粒同士がくっついて、そのまま固まりやすいのでバラバラになりづらいのもある。

自家製のそば米は徳島で売られているそば米と比べると粒が荒く、また使っているそばの実が大粒なため、徳島のそば米のように容積で測るより、重量で測ったほうが調理の都合がよいと思った。

仮に投入量の86%をそば米に変換できるとすると、500gから430gのそば米を作れる。そば米汁を作る時だと現状は一回56g使っているため、7.67回分の分量になるようだ。

おまけで加工前のそば抜き実と、加工後のそば米の写真も残しておく。色味など、見た目がだいぶ変わっていることがわかる。加工後のは徳島のそば米感がだいぶある。

加工前（そば抜き実）	加工後（そば米）

【研究中】そば米にもある通り、そば米の制作方法についてはネットで調べた限り、ほとんど情報がなかったため、既存の情報を掛け合わせて私なりに作ってみたわけだが、恐らく作り方を公開している人がいないと思うので、この記事が公開情報としてほぼ唯一のものになるのではないだろうか？

この記事は研究のまとめなので、別途レシピ記事も作ろうと思う。内容的には最後の125g版で書く予定だ。

前回のマシンを更新したのでローカルLLMを軽くベンチマークしてみたでは生成速度だけを見れば十分実用ラインということを確認したが、品質が悪い問題があった。

そこで4月に出て、そこそこ評判を聞くQwen3.6がいかほどのものかというのを軽く試し、ついでにベンチマークもした。

CPU推論とGPU推論が分かれているが、これは初回ベンチマーク時にCUDAのDLLを入れ忘れていたため、GPU推論はDLLを入れてリトライした時の数値、CPU推論はDLLがない状態の数値で書いている。

• 確認環境
  • ハードウェア
  • ソフトウェア
• ベンチ結果
  • [llama.cpp] Qwen3.6-35B-A3B-UD-Q4_K_M
    • 入出力例
    • CPU推論
    • GPU推論
  • [llama.cpp] Qwen3.6-35B-A3B-UD-Q5_K_M
    • 入出力例
    • CPU推論
    • GPU推論
  • [llama.cpp] Qwen3.6-35B-A3B-UD-Q8_K_XL
    • 入出力例
    • CPU推論
    • GPU推論
  • [Ollama] qwen3.6:35b
    • 入出力例
    • CPU推論
• llama.cpp実行コマンド
• まとめ
  • CPU
  • GPU
  • Ollama
• おまけ：Poe上のQwen3.6-Plus
• あとがき

確認環境

ハードウェア

ソフトウェア

実行環境はWindows 11。今回はllama.cppをメインで使っている。

ベンチ結果

[llama.cpp] Qwen3.6-35B-A3B-UD-Q4_K_M

Qwen3.6-35B-A3B-UD-Q4_K_Mを使用。

入出力例

CPU推論時に出した内容。スクショが面倒なのでGPU推論時のはなし

CPU推論

生成速度

リソース消費

GPU推論

生成速度

リソース消費

[llama.cpp] Qwen3.6-35B-A3B-UD-Q5_K_M

Qwen3.6-35B-A3B-UD-Q5_K_Mを使用。

入出力例

CPU推論時に出した内容。スクショが面倒なのでGPU推論時のはなし

CPU推論

生成速度

リソース消費

GPU推論

生成速度

リソース消費

[llama.cpp] Qwen3.6-35B-A3B-UD-Q8_K_XL

Qwen3.6-35B-A3B-UD-Q8_K_XLを使用。

入出力例

CPU推論時に出した内容。スクショが面倒なのでGPU推論時のはなし

CPU推論

生成速度

リソース消費

GPU推論

生成速度

リソース消費

[Ollama] qwen3.6:35b

qwen3.6:35bを使用

入出力例

CPU推論時に出した内容。スクショが面倒なのでGPU推論時のはなし

CPU推論

生成速度

リソース消費

llama.cpp実行コマンド

実行コマンド

このコマンドはRTX 5070 Ti + 9800X3D running Qwen3.6-35B-A3B at 79 t/s with 128K context, the --n-cpu-moe flag is the most important part. |r/LocalLLaMAにあったものを利用している。

llama-server.exe ^
  -m "ここにモデルファイルのパス" ^
  --fit on ^
  --fit-ctx 128000 ^
  --fit-target 256 ^
  -np 1 ^
  -fa on ^
  --no-mmap ^
  --mlock ^
  -b 2048 ^
  -ub 2048 ^
  -ctk q8_0 ^
  -ctv q8_0 ^
  --temp 0.6 ^
  --top-p 0.95 ^
  --top-k 20 ^
  --min-p 0.0 ^
  --presence-penalty 0.0 ^
  --repeat-penalty 1.0 ^
  --reasoning-budget -1 ^
  --chat-template-kwargs "{\"preserve_thinking\": true}" ^
  --host 0.0.0.0 ^
  --port 8033

まとめ

CPU

GPU

Ollama

上の表の指標については明確な根拠を見つけることができなかったため、指標の名前から推測して、おそらくこの指標はこれだろうというので割り当てて書いている。

何故というとAPIレスポンスの仕様書が何処にあるかわからず、Claude Opus 4.7に聞いてもデッドリンクになった仕様書を提示され、後はソースコードを読めと言われたため、わからないのだ。ソースコードなんか一々読んでられない。しかも嘘を教えられたため、自力で解釈した。

さて、処理時間についてだが、これはOllamaよりllama.cppのほうが圧倒的に早いことが判明した。また、ついでに言うとOllamaはどのモデルを実行してるのかが不明なため、単純比較ができない。

またリソース消費を見る感じ、OllamaはCPU・GPU共に遊ばせていたので、これが処理が遅い原因になっていた可能性がある。llama.cppはマニュアルでそのあたりをうまくやっているので早かったのだろう。

生成品質としては前回とそこまで変わらない気がしたが、質問を一回投げているだけなので、正直なところちゃんとした品質を確かめるには叩きまくる必要はあると思う。面倒なのでそこまではしてない。

おまけ：Poe上のQwen3.6-Plus

Qwen3.6-Plusはクラウド専用モデルのため、ローカルでは動かないが、動かしてみた感じ大分品質は良さそうに思った。少なくともローカルモデルのように目立ったハルシネーションは見られない。

あとがき

一般的なマシンで動くローカルLLMは、まだそれなりという感じの次元だが、Qwen3と比べると3.6は気持ち品質が上がったように感じた。とはいってもLLMはコンテキストがある状態で質問したり、コーディングさせたりしないと真価がわからないので、今回のように「神戸市について教えて」と聞くだけではあまり意味のある結果にはならないので、あくまで参考値くらいだろう。

取り敢えずまともなモデルはOpenAIもQwenもクラウドにあって、配布されているモデルは劣化版というのが分かったのが今日の収穫だったように思う。

Qwen公式の比較表を見る限り、Qwen3.6-35B-A3BはClaude Sonnet 4.5よりは賢いようだ。ただSonnetは個人的にはもう使っておらず、レートリミットがない環境で使っているのもあり、もっぱらOpus 4.7しか使っていないので、Sonnet 4.5を超えたところで微妙な感じは否めない。4.5は個人的にERPをするときにOpus 4.7, Sonnet 4.6, Opus 4.6でも返事をしなくなったときに4.5を叩き、その次のターンでOpus 4.6→Sonnet 4.6→Opus 4.7という流れで回帰させるのに使うことが多い。これは何をしているかというとSonnet 4.5の検閲が緩いのを逆手にとって、上位バージョンを騙すためのコンテキストを書かせているわけだ。

Sonnet 4.5が出た時は割と重宝していた記憶もあるのだが、Opus 4.7が優秀なので、もうまともな用途ではOpus 4.7以外全く使わなくなった。Opus 4.6も悪くはないと思うので、Opus 4.6くらいまでローカルLLMが進歩してくれたら助かるところである。

ひとまず今回の収穫はQwen3.6-35B-A3Bという昨今注目されているモデルが、特にメモリの増設なしでも動いた上に、VRAMを使わずRAMだけで実用速度で走らせることができたことだ。

クラウドLLMは高いのでローカルLLMで解決できるようになれば、それに越したことはない。

余談だがQwen3.6-35B-A3Bは検閲モデルだがQwen3.6-35B-A3B-Uncensored-HauhauCS-Aggressiveという無検閲モデルがあり、ERPが機能することを軽く確認している。弾かれないこと程度しか確認してないので品質は謎いが、テストで叩いた感じはそこそこの内容を出してくれたと思う。少なくともGPT-4やGrokよりはよいと思うので、お金を節約したい人にはオススメかもしれない。

前回のAnimaの正式版が出たのでベンチマークやNovelAIと品質比較してみたでは以下の通り、生成時間が長くやや厳しめだったが、もう少し何とかならないかというので試してみた。結論としては速度の向上ができた。

まず前提として私はほとんどのケースで縦長か横長でしか作らないので、前回より基準サイズを落としている。その分Upscalerで拡大する方向だ。

またベースモデルを使うこともないため、カスタマイズされたモデルを使っている。具体的には前回の検証時にはまだベースモデルが出たばかりだったので、ベースモデルしか選択肢がなかったが、Anima Cat TowerがAnima base-v1.0に対応したため、これを利用している。

• 確認環境
• XL：基準サイズ512x768px
  • ノード参考
  • 成果物
• Anima：基準サイズ512x768px
  • ノード参考
  • 成果物
• まとめ
• あとがき

確認環境

ソフトウェア

ComfyUI v0.21.1

ハードウェア

XL：基準サイズ512x768px

まずは比較用のXLから。

ノード参考

成果物

Anima：基準サイズ512x768px

次にAnimaを試す。

ノード参考

詳細は以下の成果物をComfyUIに突っ込めば出るので割愛。

成果物

まとめ

最終成果物の画像サイズが異なるため単純比較はできないが前回18.054sだったAnimaが12.72sになり、出力画像サイズも896x1152pxから1024x1536pxに増えていることから、前回より大きな画像を短時間で生成させることに成功している。

これは基準サイズを推奨値より大幅に落としたことと、Animaに従来のXLのワークフローで使っていた二段KSampler、つまりHire.fixを導入したことと、更にその部分で後段のKSamplerの処理量を落としたり、前段のKSamplerのStepも推奨から落とすことで、全体の負荷を落としたところが大きいと思う。要は推奨値からかなりあれこれ落としている。

しかもそれでいて品質は高く出ているため、現状はいい感じだと思う。まだそんなに生成してないのでどこかに落としな穴がある可能性はあるものの、現時点では満足だ。

あとがき

ブログ用に出している生成画像は毎回似たような画像ばかり出しているが、普段からこんなのを作っているわけではなく、常日頃は全く違う画像を作っている。

ただ流石にここに出すのも微妙な気がするので、このサイトがブログである必要性について考えてみた その２の延長でどうするかは考えている。

恐らくこのサイトの課題として、このブログにすべてが集約されていてノイズが多すぎるところがある。それはよくもあるのだが、ゾーニングも必要だと思う。キッティング記事と料理のレシピと旅行がごちゃ混ぜな時点で探しづらいし、そこに大分アレゲなAI生成画像を突っ込むのはさらにおかしなことになってしまう。

恐らく一定のジャンルごとにサイトを分割するのがよいと思っているが、まだどうするかは考え切れていない。ただ同時に全ての記事のフィードを垂れ流すカオスなハブもあったほうがいいとは思っている。

少なくとも画像を並べるならギャラリーのようなサイトがあることが望ましいだろう。それも内容は間違いなくアレゲなので。

ComfyUIを使ってみる2で先月からComfyUIに移行したわけだが、最近Animaという有力なモデルのプレビュー版が出たということで乗り換えていた。

このAnimaは基本的にComfyUI用で、これまで使ってきたAUTOMATIC1111やreForgeでは使えないという噂で、非常にいいタイミングだった。

そして本日正式版としてbase-v1.0が出たのでベンチマークしてみることにした。また、出力品質が以前と比べて非常に向上しており、絵柄再現やキャラ再現ができたため、NovelAIとの簡単な比較もしている。

• 確認環境
• りこベンチ：XL：基準サイズ448x576px
  • ノード参考
  • 成果物
• りこベンチ：XL：基準サイズ896x1152px
  • ノード参考
  • 成果物
• りこベンチ：Anima：基準サイズ896x1152px
  • ノード参考
  • 成果物
• まとめ
• おまけ
• Animaは絵師指定による絵柄の再現ができる
  • 黒星紅白
  • カントク
  • いとうのいぢ
  • ☆画野郎
• キャラ指定で絵が出せる
  • 天音かなた
  • 樋口楓
  • キノ
  • アスナ
• あとがき

確認環境

ソフトウェア

ComfyUI v0.21.1

ハードウェア

りこベンチ：XL：基準サイズ448x576px

これまでのりこベンチは基準となる画像サイズ（Empty Latent Image）を768x768pxで実施していたが、Animaでは896x1152pxが基準となる。

このため、まずはUpscaleで倍にすることを考え、画像の基準サイズを448x576pxに変更した、りこベンチで計測した。

ノード参考

詳細は以下の成果物をComfyUIに突っ込めば出るので割愛。

成果物

りこベンチ：XL：基準サイズ896x1152px

次はUpscaleなしで等倍の896x1152pxが出る条件で計測した。

ノード参考

詳細は以下の成果物をComfyUIに突っ込めば出るので割愛。

成果物

りこベンチ：Anima：基準サイズ896x1152px

ノード参考

左下に何処にも繋がっていないノードがあるが、これは消し忘れたゴミである

詳細は以下の成果物をComfyUIに突っ込めば出るので割愛。

成果物

まとめ

以上が今回のベンチの結果だが、Upscale前提だと生成速度が3倍にもなっている。これは見方次第ではやや厳しいタイムだ。

しかしComfyUIはWorkflowsを工夫すれば一回叩くだけで複数のシーンを出すことができるため、A1111やNovelAIのように張り付かなくて良い点を考慮すれば、さほど気にならないかもしれない。

またAnimaではHirefix（二段KSampler）なしにXLより高い品質の画像を出力できているように見えるため、ここも良いポイントだ。

生成速度については「Anima-Turbo Coming soon.」と書かれているため、近日中により早いものが出るかもしれない。高品質版かもしれないが何も書いてないので実際のところは謎だ。

おまけ

これはAnimaのプレビュー版であるpreview3-baseから作られたanimaCatTower_v05.safetensorsで作った画像だが、非常に品質がいい。

恐らくbase-v1.0で作り直されれば、より品質が高まるだろう。

Animaは絵師指定による絵柄の再現ができる

NovelAIには劣るものの、これまでLoraがないと厳しかった絵柄の再現がある程度できる。いくつか実際に比較してみた。

黒星紅白

やや破綻が見られるものの、絵柄としてはだいぶ出ていると思う。NovelAIほど正確さがないのはある意味で便利かもしれない。

Anima	NovelAI

カントク

ディティールはそこまでないが、大まかにはそれっぽいのが出せていると思う。NovelAIと比べるとどうしても劣る。

Anima	NovelAI

いとうのいぢ

これがいとうのいぢの絵柄見えたら大分目が悪いと思う。学習量が少ないのか精度が悪い。NovelAIは流石に圧巻である。ただNovelAIも絵柄が古く、ハルヒ時代といった感じだ。最新ののいぢという感じはしない。

Anima	NovelAI

☆画野郎

遠目に見えれば見えなくはないが、だいぶ厳しい。線の丸みと色の淡さはそれっぽいかもしれない。NovelAIの再現性は流石である。

Anima	NovelAI

キャラ指定で絵が出せる

これも従来であればLora或いは、専用のモデルが必要だったが、一応出せるようになっている。

但し単純なプロンプトでは品質が悪くなりがちで、NovelAIと比べると勝負にすらならないレベルだ。とはいえ、それができるようになったというだけでも十分すごい。

天音かなた

ここまでの品質のものは中々出ないので奇跡の一枚に近いが、天音かなたを出すことができる。10回くらい回したが、大半は天音かなたのような何かだったので、安定性はない。

NovelAIでは非常に安定して天音かなたを出力できる。

Anima	NovelAI

樋口楓

これも奇跡の一枚に近いが、泣きボクロがないけど樋口楓に見える何かは出ている。

勿論、NovelAIのほうが再現性が高く安定している。

Anima	NovelAI

キノ

キノに見えなくもないくたびれた男性のようなものが出てきた。これでも奇跡の一枚で、酷いと人の姿さえ出てこないことがあった。

NovelAIは安定しており、何枚か出してみたところ特に指定していないにもかかわらず、パースエイダーを構えているものを出すことさえできた。但し指が破綻していたのでここには載せていない。

Anima	NovelAI

アスナ

いわれてみればアスナに見えなくもないが、他人の空似レベルである。

NovelAIは（ｒｙ

Anima	NovelAI

あとがき

XL系と比べると出力時間が三倍かかるが、品質は大きく向上し、絵柄やキャラの再現もある程度可能になっているためローカルで色々やるにはよくなったと思う。

ただ版権絵を絵柄丸コピーでどうこうするとか、そういった用途に使うにはまだ厳しいと感じた。

絵柄やキャラ再現はLora + Ponyが非常に優秀なので、何もなしで高品質だけど時間がかかるAnimaがどこまでいけるのかは現段階では未知数である。

しかしながらポテンシャルは感じるので、今後GPUの性能向上や、ComfyUIやモデルの進化などによって、より良い方向へ向かう可能性は十分にあるだろう。恐らくRTX7070TiになるころにはXL並みの速度にはなっていると思う。