動画編集者 ⇨ エンジニアです。 最近はローカルLLMがアツいっすよ! クソアプリ生み出したり、動画作ったり、本書いたり、音楽作ったりしてます。飽き性なのをなんとかしたい。わりとマジで。

日本 東京
Joined September 2022
LiteLLMをプロキシに挟んでる人、CVSS 9.9出てる(CVE-2026-114612)。1.91以降はデフォルト設定のままで管理者になりすまし→MCP経由でコマンド実行まで行ける。1.100.4 / 1.101.3 / 1.102.2 / 1.103.1 のどれかに上げといて
12
Argo CD、CVSS 9.9が3件まとめて出てる。repo-serverとKustomize/Helmまわり。3.3.15 / 3.4.10 / 3.5.4 より前を使ってるなら上げといたほうがよさそう
42
横と後ろもAIに描かせて、3枚から3Dにしたら後ろ頭がちゃんと髪になった(色の差は照明を変えたせい)
33
CUDAグラフ、1枚目を素で回してから入れたら通った。けど2.0→1.9秒で誤差みたいなもんやった
5090との差、中を覗いたら行列計算がAmpere世代向けのカーネルで回ってた。帯域も約1/6.5なので、だいたいそれっぽい
48
同じセリフを2つの音声AIにPGXでしゃべらせたら、この程度だった。どっちがマシ?もっと自然にするコツあったら知りたい
3
79
同じのをqwen2.5vlに読ませたら、赤字の「在庫どうする?」まで線のメモとして拾ってきた
「汚い字で」って頼んだらこれが出てきた。箱4つはちゃんと拾ってた
2
65
compile効かんと思ったら入れる場所間違えてた。ちゃんとかけたら1枚3.3秒→2.0秒。CUDAグラフも足したら上書きエラーで止まるし、5090の0.7秒はまだ遠いな〜どうしたらもっと早くなるんだ〜
5090との差、中を覗いたら行列計算がAmpere世代向けのカーネルで回ってた。帯域も約1/6.5なので、だいたいそれっぽい
61
5090との差、中を覗いたら行列計算がAmpere世代向けのカーネルで回ってた。帯域も約1/6.5なので、だいたいそれっぽい
DGX Sparkでも1秒切るかなと思って回してみたら、1024pxで1枚6秒くらいだった。5090の0.7秒は遠い〜 M3 Maxの11秒よりは速いし、絵は4ステップとは思えない出来なんだけど。なんでこんなに差がつくんだろ?
1
165
マスコットって言葉、広すぎてAIに伝わらんよな〜。スタンプなのかフィギュアなのか、何頭身なのかまで言わんと一番ありがちなのが出てくる
50
頼み方が「かわいいマスコット」止まりだったから、箱に目と手足つけただけのやつが出てきた
うちのPGXをマスコットにして3Dまで丸投げしたら、この程度だった。みんなならどうやって良くする?
44
うちのPGXをマスコットにして3Dまで丸投げしたら、この程度だった。みんなならどうやって良くする?
1
4
151
PHPの件で夜中に一斉メンテ…現場の人ほんまにお疲れさまです
【重要】緊急メンテナンス実施のお知らせ このたび、サーバーで使用しているプログラミング言語「PHP」に関する脆弱性が発見されたとの発表を受け、セキュリティ強化及びシステム安全性を確保する緊急メンテナンスを実施いたします。 したがって、現在公式ファンクラブ「HYPSTER」のホームページはシステムメンテナンス状態となります。 ■システムメンテナンス期間 2026/10/21(水)~(未定) お客様にはご不便、ご迷惑をお掛けいたしますが、何卒ご理解とご協力のほどよろしくお願い申し上げます。 #HYPSTER
542
うちのPGXに声まで任せたらこうなった。自分だと良し悪しがわからんのだけど、みんなどう聞こえる?
1
54
llama3.2-visionも並べようとしたら unknown model architecture: 'mllama' で起動すらせず。お手上げでーす
qwen2.5vlに読ませたら、4%でもほぼ読めてた。こっちは1枚33秒
56
qwen2.5vlに読ませたら、4%でもほぼ読めてた。こっちは1枚33秒
レシート薄くしていったら、ギリギリ読めない濃さの時だけ日付と値段を作ってきた
1
84
推論エンジンまで出すの太っ腹すぎる。うちのGB10じゃビルド通らんかったけど
OpenAI→ほぼ全て非公開、パラメータ数すら非公開、gpt oss一回出しただけ、全然オープンじゃ無い DeepSeek→全部出す、モデルも出す、本番環境推論エンジンまで出す どっちがオープンAIなんですかねえ…
2
499
これをそのままフィギュアにした
別々に描いた2枚を渡したら、抱っこさせてくれた。22秒
1
66
別々に描いた2枚を渡したら、抱っこさせてくれた。22秒
家のPGXでも動いた。1枚12〜16秒で着替えてくれる
1
1
4
177
家のPGXでも動いた。1枚12〜16秒で着替えてくれる
ComfyUIがFibo 2.0ネイティブ対応。これはEdit。顔LoRA不要だ(笑) モデルのurlはコメントに。 github.com/Comfy-Org/ComfyUI…
1
4
238
家のGB10でビルドだけ試したけど、NVCC 13.1以上いるってとこで止まった
DeepSeekは、自社の推論フレームワークDeepInferを公開するとともに、DeepSeek V4.1 Flashの大規模推論システムに関する技術報告も公開した。 この報告によれば、V4.1 Flashは単一クラスタで1日あたり155兆トークンを処理し、GPUあたり毎時38ドルのAPI売上換算値を達成している。また、Decodeのベンチマークでは、GPUあたり毎秒14,466トークンという出力スループットを報告している。 この報告では、PrefillとDecodeの分離、Expert Parallelism(EP)、KVキャッシュの長期保存、投機的デコード、負荷分散などについて、実際の運用を踏まえた設計が詳しく説明されている * PrefillとDecodeの並列化 PrefillではExpert Parallelism(EP)を2〜8、Data Parallelism(DP)を2〜8とし、モデルの重みがHBMに収まる範囲で、できるだけ小さいEPを利用する。 DecodeではEP64〜128、DP64〜128という大規模な並列化(Wide EP)を採用している。 V4.1 Flashは各MoE層に256個のRouted Expertを持つためEP64であれば、単純に均等配置した場合、GPUあたり平均4個のExpertが配置される。人気のあるExpertを複製し、各GPUの負荷に応じて再配置するExpert Parallel Load Balancing(EPLB)も導入している。 このようにEPを大きくすることで、各GPUが読み込むExpert重みの量を減らし、同時に多数のトークンを集約してExpertのGEMMを効率化できる。一方で、GPU間通信の負担は増えるため、通信側の負担は大きくなっている。 * KVキャッシュの長期保存と再利用 本番トラフィックでは、入力長の平均が77Kトークンで、そのうち約96%がキャッシュヒットしていると報告されている。 KVキャッシュは分散ファイルシステム3FS上に保存され、どのPrefillノードからでもアクセスできるように設計されている。これにより、リクエストを特定のGPUに固定する必要がなく、柔軟な負荷分散が可能になる。 また、Sliding Window Attention(SWA)はキャッシュ再利用時に必要な状態を厳密に再構築するには、層数分だけ、より長い範囲の再計算が必要になるが、そこを直近128トークンだけの再計算に置き換えている。これは近似だが、Prefill全体の計算量をほぼ半減できると報告している。 * GPUあたりの処理性能と売上 DeepSeekは、GPUあたり毎時38ドルのAPI売上換算値を報告している。これを単純に年間換算すると、GPUあたり約33万ドル(1ドル150円換算で約5,000万円)となる。 主要な処理性能は次の通りである。 - Prefill処理量(キャッシュ込み):約150万トークン/秒/GPU - Prefill処理量(新規計算):約6万トークン/秒/GPU - Decode処理量:約14,000トークン/秒/GPU - Decode同時実行数:約60系列/GPU - 1ユーザーあたりのDecode速度:約230トークン/秒 - PrefillとDecodeのGPU数:約1対1 これらの値とAPI料金を組み合わせると、GPUあたり毎時38ドルという売上換算値と概ね整合する。 1日155兆トークンという処理量からGPU規模を逆算すると、上記のスループットを継続的に達成できるという仮定のもとで、Prefill約1,200基、Decode約1,200基、合計約2,400基という規模が推定される。 この構成が年間を通じて同じ稼働率と売上単価を維持した場合、年間売上換算値は約8億ドルとなる。 例えば、GPU原価を毎時5ドル、その他のインフラ原価を毎時3ドルと仮定すると、GPUあたり毎時38ドルの売上に対して粗利益率は約79%となる。これは原価を仮定した試算であり、実際の利益率を示すものではないが十分採算がとれていることを示している。 * GPUの演算効率 次に、Decode性能をB200やGB200のピーク演算性能と比較してみる。 V4.1 FlashのDecode時のActive Parametersを16Bとすると、1トークンの主要な行列積演算量は約32 GFLOPsとなる。 GPUあたり14,466トークン/秒で生成する場合、出力トークンに対応する演算量は約463 TFLOPS/GPUである。 さらに投機的デコードにおける検証トークンの増加を考慮すると、主要モデルの演算量は約516 TFLOPS/GPUと推定される。 これはB200やGB200のFP8・FP4ピーク演算性能に対して約5〜12%に相当する。 また、GPUあたり60系列を同時に処理し、投機的デコードによって1ステップで平均3.21トークンを生成するとすると、1ステップの処理時間は約13.3ミリ秒と推定される。 * HBM帯域とExpert重みの読み込み メモリ帯域の観点からも考えてみると、仮に552BパラメータをすべてFP4で格納し、EP64で均等に分割すると、GPUあたり約4.31 GBの重みを保持することになる。 これを1ステップごとにすべて読み込むと仮定すると、13.3ミリ秒のステップ時間で平均約324 GB/sの読み込み帯域が必要になる。 B200のHBM帯域は約8 TB/sなので、ステップ全体で平均すればピーク帯域の約4%に相当するので十分間に合う上、重みの読み込みとGEMMは一部をオーバーラップできる。 ただし、13.3ミリ秒の間にはAttention、Expert間通信、GEMMなどの処理も必要であり、重みの読み込みに13.3ミリ秒すべてを使えるわけではなく、例えば重み読み込みに使える時間が1ミリ秒しかないなら、必要帯域は4.31 TB/sとなり、B200のピーク帯域の約54%を使用する計算になる。 * SSDを利用したKVキャッシュ保存 今回の推論インフラでSSDは中心的な役割をはしている。 推論中のKVキャッシュと状態はGPUのHBMに保持される。一方、SWAのKVキャッシュはCPU RAMに、Paged Block KV Cacheは3FS上のSSDに保存される。 SSDはDecode中のKVキャッシュをHBMから退避させるためではなく、主に数日間にわたるPrefixの再利用に使われる。 本番システムでは、KVキャッシュ用のSSDストレージを約100 PiB確保しており、GPUあたりの論理ストレージ容量は約14.4 TBである。 キャッシュ保持期間は、Agentトラフィックで3日間、Chatbotトラフィックで7日間に設定されている。 また、キャッシュヒット率は約96%である一方、API料金ではキャッシュヒットした入力トークンと新規計算が必要な入力トークンの価格差が50倍に設定されており、Prefill売上においてキャッシュヒットした場合とそうでない場合がちょうどバランスされている。 コメント === 今回の報告は、現在の大規模LLM推論インフラについて、実際の利用状況と、それを支えるシステムの構成や設計上の工夫を具体的に示している点で参考になる。 KVキャッシュをSSD上に長期間保存してPrefillの再計算を削減し、Decode側でWide EPを採用してExpert重みの読み込み負担を減す上、単に推論カーネルを高速化するのではなく、ストレージ、通信、負荷分散、投機的デコードまで含めて最適化することで、システム全体のスループットと経済性を改善している。 また、推論フレームワークDeepInferが公開されたことで、今後コミュニティによる性能検証や改善が進むことも期待できる(ただし、本番で使われているKVキャッシュ管理や負荷分散システムなどは公開されていないようである)
3
105