WasmからGPUへのzero-copy inference、HNは速度差の実体を問うた

Community Spark

Hacker Newsの#47820195は113 points、51 commentsを集めた。Abacus Noirのpostは、Apple Silicon上でWebAssembly linear memoryをGPUと共有し、inference pathのcopyを減らせるかを検証している。HNの関心は派手なbenchmarkではなく、境界そのものだった。Wasm sandbox、Metal buffer、unified memoryが同じphysical bytesを見るなら、AI runtimeの設計は変わりうる。

What Was Tested

記事はこのworkをDriftwoodというstateful inference systemのfoundationとして説明している。chainは3段階だ。まずmmapでpage-aligned memoryを確保する。次にMetalのbytesNoCopy pathでそのpointerをGPU bufferとして包む。最後にWasmtimeのMemoryCreatorを使い、Wasm moduleのlinear memoryも同じbacking regionを使うようにする。

end-to-end testは意図的に小さい。128 by 128 matrix multiplyだ。Wasm moduleがmatricesをlinear memoryに書き、GPUがMetal shaderで計算し、結果を同じmemoryへ戻す。著者はpointer identity、hidden memory overhead、computed elementsのzero errorsを確認した。こうしたstackでは、どこか1層がdefensive copyを作るだけで全体の意味が崩れるため、correctness自体が大きなsignalになる。

Why HN Cared

HN threadはすぐに、native host codeと比べて何が得られるのかを問うた。これは妥当なpressure testだ。Wasmが単に遅いnative codeなら、isolation、portability、reproducible actor state、安全なdeploymentといった性質で価値を示す必要がある。さらに、これはbrowser WebAssemblyではなくwasmtimeで動くという指摘もあった。

takeawayは「Apple Siliconならすべて速い」ではない。より狭いが面白い。Unified memoryにより、Wasm actor stateとGPU inference bufferを1つのshared allocationへ結びつけられるかもしれない。conversationをfreezeし、別の場所へmoveし、stateを保ったままthawするruntimeを考えるなら重要だ。HNはbenchmarkではなく、abstraction boundaryが本当に消えたのかを見ていた。