HNがこの投稿に食いついた理由

Hacker Newsはこの話を「機内でAIコーディングしてみた」という軽い武勇伝としては読まなかった。ネット接続が消えたとき、local inferenceが実務でどこまで持つのかを数字で見せた実験記として扱った。元記事でDmitri Lerkoは、128GB unified memoryと40コアGPUを積んだM5 Max MacBook ProにGemma 4 31BとQwen 4.6 36BをLM Studioで載せ、ロンドンからラスベガスまでの10時間フライト中にDuckDBベースの請求分析ツールを作ったと書いている。小さめのリファクタ、CLIの足場作り、ドキュメント整備まで含めると、およそ4M tokensも処理したという。

ここまでは「かなり使える」という話だ。HNが本当に見たのは、その先でどこが最初に崩れるかだった。

投稿に重みを与えた具体値

元記事はかなり具体的だ。持続負荷ではバッテリーがほぼ1分1%のペースで減る。しかも機内電源につないでも、使っていたケーブルのせいで実際の供給は60Wしか出ていなかった。一方で本体は70〜80W級の熱を出し、膝に直接置くのがつらくなり、毛布と枕で熱をしのいだと書かれている。文脈長も100k tokensを超えると目に見えて遅くなり、いくつかのpromptはlocal stackを無限ループへ送り込み、人間が止める必要があった。

この投稿が説得力を持ったのは、著者が計測まで自作していたからだ。powermonitorでMacの電力telemetryを読み、lmstatsでLM Studioのthroughputとlatencyを追跡した。そして最終的に、問題の一部はモデルではなくケーブルだと突き止める。iPhoneケーブルでは60W、MacBookケーブルでは94W。帰路の改善余地はモデル差より給電経路にあった。

HNコメントが加えた視点

コメント欄はかなり現実的だった。ある読者はエコノミー席では推論性能よりスペース不足が先に来ると言い、別の読者は発熱のほうが印象的だと書いた。さらに、QwenやGemmaをlocalで回すと意味のあるagent taskでループに入りやすいという声も目立った。これは元記事の結論とも噛み合う。local LLMは確かに役に立つが、現場で気持ちよく回るとはまだ言いにくい。

なぜこの投稿が伸びたのか

このスレッドが強かったのは、local LLMの議論を抽象論からワット数、熱、文脈長、人間の我慢へ引きずり下ろしたからだ。記事そのものも、localがcloud frontier modelを置き換えるとは言っていない。射程はもっと狭い。短いコーディング、探索的ツール作り、cloud推論を使うほどではない仕事なら十分使える。だが長い文脈推論、不安定なtool use、長時間のagent sessionではまだ粗い。その粗さこそが現実だとHNは受け取った。

出典: 元ブログ · Hacker News議論

#offline

10時間フライトのオフラインLLM実験 HNが見たのは電力・発熱・ループの現実

10時間フライトのオフラインLLM実験　HNが見たのは電力・発熱・ループの現実