Hacker NewsでHypuraが注目されたのは、Apple Siliconでありがちなlocal inference failure modeを正面から扱っているからだ。model file自体はdiskに置けても、実際のinference開始後にmemory limitを超えてsystemが破綻する、という問題である。Hypuraは、すべてのweightを一つのtierに載せる前提を捨て、model tensorをGPU memory、system RAM、NVMeにまたがって配置するstorage-tier-aware schedulerだと説明している。

repository READMEによれば、Hypuraはmachine profileとGGUF layoutを読み取り、どのtensorをGPUに常駐させ、どれをRAMへ逃がし、どれをNVMeからon demandでstreamするかを決める。normsとembeddingsは毎tokenアクセスされるためcomputeの近くに固定される。MoE modelではschedulerがrouter decisionを捕捉し、実際に発火したexpertだけを読み込む一方、neuron cacheがtoken間のtemporal localityを活用する。dense modelでは大きなFFN weightsをpredictive prefetch付きのbuffer経由でstreamする。

READMEは31 GBのMixtral 8x7Bを32 GB Mac Miniで2.2 tok/sで動かせるとしている。
さらに同じmemory classで40 GBのLlama 70Bを0.3 tok/sで走らせたと報告しており、vanilla llama.cppではOOMになるという。
expert streaming pathではI/Oを75%削減し、warmup後のneuron-cache hit rateは99.5%に達すると主張している。

重要なのは、NVMeが魔法のようにVRAMと同じ速度になるという話ではないことだ。Hypuraの主張は、model architectureを理解すればtiered schedulingは十分に意味を持つという点にある。MoE sparsityによって毎tokenで本当にhotなweightsは一部に限られ、dense modelにもresidentにしておく恩恵が大きいcomponentがある。storageをfatal fallbackではなくcold tierとして扱うことで、「読み込めない」を「遅いが動く」に変えようとしている。

だからこそHNで興味を集めたのだろう。Mac向けlocal LLM toolingはraw GPU performanceよりmemory ceilingに縛られる場面が増えており、Hypuraはそのceilingをscheduling problemへ変換しようとする比較的明快な試みだ。repositoryがOllama-compatible serverも公開していることから、benchmark screenshotだけでなく実際のtool ecosystemとのinteroperabilityも意識していると分かる。

一次情報: Hypura repository。コミュニティ出典: Hacker News thread。

#memory-scheduling

Hacker Newsが注目したHypura、Macで容量超えLLMを階層スケジューリング実行