オフサイトで勉強会に行くのは何年ぶりだろうか
これに行ってきましたです。開発者視点のローカルLLMはどう見えてるのか？と言うのが気になりました。
福岡でも有名なエンジニアさんであるきしだ(@kis)さんが主宰されており、会場は博多駅から近いLINEヤフーさんのオフィスでして、しかしながら当日は土砂降りの雨で、妻に近くの駐車場まで送ってもらい、足元を濡らしながらひぃひぃ杖つきながら会場入りしました。
登壇資料はこちらで紹介されています。Qwen3.6-27Bモデルを駆使してプロダクトを作らせる際の注目ポイントや、アーキテクチャを見たときの強み・弱みの見極め方などが紹介されており、ローカルLLMに対して興味がある人はぜひ見ておいた方がいいよという内容がたくさん盛り込まれてるように思います。
私としては素直な開発者視点からみたローカルLLMについて述べられてたんで、ものすごく勉強になりました。と同時に、「ああ、私ってやっぱりITインフラ脳なんだなー」って思っちゃいました。視野を広げるにはすごくいい機会だったと思います。トピックとしては
- やっぱりCodingを前提にしてる：
私の場合、ドキュメントの校正、アイデアだしとか、壁打ちとかテキストベースの一般的なチャットのやり取りを前提にして使うことが多いです。その際に役立つのは「文章の校正力・まとめ力」ですが、きしださんの解説を拝聴すると、やっぱりCoding能力を重視してみているように見受けられました。 - モデルに対する回答精度のハードルがものすごく高い：
出力させるものがCodeであるがゆえにトークン量も膨大です。それにかかる時間を考慮したときに、Codeの精度、詳細における内容の正しさに対する目の厳しさははっとさせられるものがありました。私はVibeするにしても運用ツール程度しか考慮しないので、やっぱり「動けば御の字」で作ることが多いんですけど、そこを細かく見ながら実行されてるんだなと言うところをすごく感じました。 - かなり大きなモデルをターゲットに見ていらっしゃる：
きちんとプロダクトを作成するのならやはり数百B程度のモデルじゃないとダメだ、知識総量の差が出てしまうという説明にものすごい説得力を感じました。
CodingAgentとして動かそうと考えるならかなり大規模なモデルじゃないと厳しいんだなと。私が会社員時代から取り扱ってきたモデルは主力でも35B程度のSLMでしたから。
知識量が少ない分、詳細なところで曖昧さを含んでしまい、そこから仕様の誤解を生じさせているというところについても、「なるほどなぁ」と言わざるを得ないものがありました。はい。
それにしてもきしださんが作ってるツールは非常に面白くて、ローカルLLMを走らせて、１ターン分の推論をする中でMoEアーキテクチャのExpertsがどの程度利用されているかリアルタイムで様子を見ることができる上、それを累積カウントしてヒートマップ化することができるとか、そうした可視化を実現させてるところに「うわー、あれどうやってんだろう」とか思いながらまじまじと画面に見入りました。すごく実りのある話だったと思います。
２本目はそのだ (@sonoda_mj)さんのDGX-Spark2台を用いてDeepSeek-V4-Flashを動かし、シューティングゲームをVibeCodeで実現させていく過程をデモンストレーションされてました。結局はメモリボトルネックが影響した感じにはなってましたが、個人的にはインフラ観点である「インターコネクトは結局どういう通信をしてるか？」までの追跡がされたらもっと面白いんだろうなーとか思ってみてました。
確かあのインターコネクトはRoCE/RDMAを使ってるんじゃないかなーと言う気がしており。
それにしてもDGX-Spark2台構成と言うのは傍から見ていてもやっぱり羨ましいなぁと思います。
インフラ脳からみた、ローカルLLMのとらえ方の違い
ただ、全面的にその通りだ！と言うつもりはなくて、少々自分なりに思ったところと言うか、こういう考え方もあるよ的な意味合いで書き出してみます。
分散方法にもいろいろありまして
過去にも紹介したネタですが、分散方法にもいろいろあります。Tensor分散とLayer分散に大別されますが、Tensor分散をすると高効率にGPU分散が出来ますが、InterConnect（それはバスだったりNVLinkだったり）に多大なる負荷がかかります。特にPCI-Exバスを使ってる場合は劇的に遅くなります。
また、実はGemma-4においては共有KVキャッシュと言って、本来レイヤー単位で個別に持つKVキャッシュ情報を動的更新しながら共有するロジックを持っているため、これもバス帯域を圧迫します。マルチGPUを使う場合はこうしたところに注意が必要です。
llama.cppもそれなりにサーバとして十分動かせるようになってますヨ。
以前、llama.cppって個人でローカル環境で動かすことを前提にしており、いろいろな機能がのっかっているものの、それ自体がサーバとして供給することを阻んでいました。が、このあたりはだいぶ改善されていたりします。
ただ、それ単独でサーバとして供給するにはAPIキーの管理機能が貧弱すぎですので、LiteLLMみたいなプロダクトが別途必要です。どちらかと言うと推論エンジンの中でもバックエンドの位置にllama.cppが来る感じです。
もっとも厄介なのは、プロンプトキャッシュ機能でした。この機能が邪魔して、他のセッションがInferenceしたときのキャッシュがノイズとなり、ユーザの求めに対して変な応答をするケースが多かったのです。これを避けるために事前にキャッシュクリアのAPI送信を必要としてロジックが複雑になる問題もあったのですが、現在はこのあたりが改善され、プロンプトキャッシュだけを完全に無効化できるようになりました。
llama.cppの嬉しいポイントは、同時アクセスの設定が可能である点、そしてそこを超えるアクセスが来た場合に自動キューイングする仕組みがあることです。これにより、クライアント側がタイムアウトしない限りは一定量のリクエストを収容することができます。後述する負荷分散ロジック等を組み合わせれば実は決してサーバとして成り立たないプロダクトではないんですね。このあたりはそれこそITインフラの専門分野になるんじゃないかなと言う気がします。（私は逆にロジックが複雑すぎるvLLMが大嫌いです。触り始めの時期が悪かったといえば悪かったんですけど）
可用性維持は周辺プロダクトで補いながら実現できる
ここはまさにITインフラの領域であり、ITインフラはプロダクトソリューションやってなんぼの領域でもあります。
llama.cppはDockerでも動かせますので、DockerオーケストレータであるKubernetesと、GPUOperatorを使うことでそのサービスを流動的に構成することが可能かなと思いますし、その前段にLiteLLMを組むことでAPIキーの払い出しと負荷分散を対応させることが可能だったりします。
場合によってはハードウェアアプライアンス(BIG-IPとか)を設置してバランシング部分も高可用性構成を取らせるのもありでしょう。多くの人が触れられるようにするには、そうした考慮を必要とするのだろうと思います。
ただ、Coding Agentを活用した場合のトークン上昇率もなかなかすごいことは私自身Hermes Agentを触り始めて感じているところであり、例えば数百-千人ぐらいのワーク用に提供するにはそれなりの基盤を構成する必要がありそうです。
蛇足：私のワークステーション、結局いくらしたんやろ？
個人にはこういうのとても無理だ・・と言う話をよく聞いており、そういえば、自分のマシンは現状コストをいくらぐらいかけたんだろうか？と言うことでコスト計算をしてみました。クッソふるいZ440 WORKSTATION（かっこよさだけで選んだ）にあれこれごたごたつけたものなんですが・・
こんなもんです。10万円行ってません。個人だからこそ敢えて中古例としてこれを並べたんですが、きしださんが利用されてた27Bモデルを動かすことはできないまでも、少なくとも12Bモデル＋その他複数モデルを同時実行させてRAGを行わせるぐらいのことは出来たりします。
文章系タスクだと12Bモデルでも十分です。さすがにLFM2.5-8B-A1Bでは文章まとめをさせるので精いっぱいだった感があり、モデルは選ぶ必要がありますけれど、動きを見て見たい！とかのレベルであればこれ or これ以下のレベルでも十分楽しめるかと。
私が2022年頃にWhisperをファインチューニングしてた頃は、それこそGPUなんてRTX-3060 x1だけで行ってましたので、それらは余裕で達成できるんじゃないかな？と思います。実際「だったらやってみよう！」ってなるのはごく僅かかもしれませんが、推測で「あのブドウは酸っぱいに決まってる」とか決めつけるぐらいならまずは食ってみませんか？ぐらいの勢いで、趣味でもいいから踏み込んでみてはどうでしょうか？
コメント