どうも、マイクです。おはようございます。
八月二十三日、日曜日の朝七時を回りました。「zenncast」今日も元気に始めていきましょう。
この時間は、技術系ナレッジ共有サービス「Zenn」で、きょうトレンド入りしている記事を、いくつかピックアップしてご紹介していきます。コーヒー片手に、ゆるっと耳だけ貸してもらえればうれしいです。
さて、きょうご紹介する記事は、全部で五本です。モバイルアプリ開発から、ノート検索ツール、CPU のディープな最適化、巨大言語モデルの推論エンジン、そして React の新機能まで、なかなか幅広いラインナップになっています。
それじゃあ、さっそく一つ目からいきましょう。
まず一つ目は、Rust で書いたひとつのコードから、iOS と Android のアプリを両方作れてしまう、マルチプラットフォーム開発フレームワーク「Whisker」の紹介記事です。
従来の Dart とか JavaScript 系のクロスプラットフォームフレームワークって、「仮想マシンを起動するからアプリの起動がちょっと遅い」とか、「エンジンまるごと同梱するからアプリサイズが大きくなりがち」とか、「ネイティブの機能にアクセスするたびにブリッジを通るのでオーバーヘッドがある」とか、そういう課題がよく挙げられますよね。
Whisker はそのあたりを、OS 上で直接動く Rust を使うことで、かなり小さくしていこうというアプローチを取っています。
Rust なので、メモリ安全性が高くて、起動も実行も高速。そのうえ、既存の Rust のエコシステムをそのまま活かせるのがポイントです。たとえば、非同期処理の tokio、HTTP クライアントの reqwest、組み込みデータベースの SQLite といった、よく使われるライブラリも、そのまま利用できるようになっています。
UI の書き方も工夫されていて、Rust のマクロを使って宣言的に UI を記述できます。いわゆる JSX っぽいノリで、でも中身は Rust なので、補完やフォーマットも「いつもの Rust」と同じ感覚で効いてくれるんですね。型の安心感を抱えたまま UI を書けるのは、Rust 好きにはたまらないところかもしれません。
さらに、開発体験のところでは、Rust 向けのホットリロード仕組み「subsecond」を取り込んでいて、コードを書き換えてから画面が更新されるまでのサイクルをかなり高速にしています。
レイアウトとスタイルについては、ByteDance がオープンソースで出している「Lynx」という C プラスプラス製のエンジンを利用していて、CSS に近いスタイル指定で、ネイティブアプリにかなり近い見た目を作れるようになっています。
今後のロードマップとしては、この Lynx への依存を少しずつ減らしていって、純 Rust 製の描画エンジンに移行することで、バイナリサイズの削減と性能改善を進めていく予定だそうです。
「Rust で完結するモバイル UI フレームワーク」、このあたりにピンと来る方は、要チェックなプロジェクトだと思います。
。。。。
続いて二つ目は、サービス紹介系の記事です。
Markdown で書いた大量のノートを、日本語を含めて「関連度順」かつ「意味ベース」でさくっと検索できる CLI ツール、「mikke」を作った話です。
「mikke」は Rust 製の単一バイナリで動くツールで、ノートを置いているフォルダごとに、隠しディレクトリの「ドット・ミッケ」配下に、SQLite ベースの全文検索用インデックスを作ります。オプションで、ローカル実行の embedding、つまり意味ベクトルもそこで生成してくれます。
日本語対応も工夫されていて、SQLite の FTS ファイブという全文検索機能に、トライグラム方式を組み合わせることで、辞書なしでも日本語の検索を扱えるようにしています。コマンドは短いものが用意されていて、全文検索、タグ検索、タイトル検索、最近書いたノートの一覧表示なんかを、ターミナルからささっと呼び出せるようになっているそうです。
意味検索の部分では、multilingual イー・ファイブという多言語対応のモデルを、ローカル CPU で動かしていて、古典的な BM 二五 と組み合わせたハイブリッド検索にも対応しています。ここで大事なのが、「ノートの内容を外部 API に送らない」という設計になっているところですね。全部ローカルで完結するので、個人のナレッジベースでも安心して使える、というわけです。
ノートのメタデータは、YAML のフロントマターで書くスタイルを採用していて、タイトル、タグ、サマリーなんかを任意で設定できます。これは Obsidian みたいな特定のツールにロックインされないように、他のツールにも持ち運びしやすいように、という狙いがあるようです。
面白いのが、AI エージェントとの連携のところで、「CLAUDE ドットエムディー」とか「AGENTS ドットエムディー」みたいなファイルや、「Agent Skills 仕様」に沿ったスキルのファイルに手順を書いておくだけで、各種 AI エージェントに対して、「まず mikke でノートを検索して、上位だけ読む」というワークフローを組み込めるようになっています。
つまり、「自分のノートを、AI の長期記憶として活かす」ことができるのが、このツールの一番おもしろいところだと紹介されています。AI に仕事を手伝ってもらいつつ、そのベースに自分の知識ベースを使ってもらう、という発想ですね。
。。。。
三つ目は、一気にハードウェア寄りの話題です。最近の Intel CPU で、連続した即値付きの add や sub 命令を、内部でまとめて処理する仕組みがある、というのを実験から明らかにしている記事です。
具体的には、たとえば Sapphire Rapids とか Golden Cove といった世代のコアで、「add rax, 一」という命令を何回も並べて実行してみると、本来の理論値よりもかなり少ないサイクル数で処理が終わる、という結果が出ています。さらに、perf カウンタを見てみると、実行ポートに渡されているマイクロ命令の数も、期待値より減っていることが確認できるそうです。
これは何が起きているかというと、CPU の中で、連続した小さな定数加算をひとまとめにして処理する、「フュージョン」と呼べそうな最適化が走っているのではないか、という話なんですね。
ただし、このフュージョンには条件があって、使っている即値の大きさとか、その合計値が収まる範囲に制限があります。また、世代ごとに挙動が違っていて、Golden Cove、Lion Cove、Skymont など、それぞれで有効になる即値の範囲や、どこまで最適化してくれるかが変わってきます。
対象となる命令も、add や sub だけではなくて、inc 命令や、一部の lea 連鎖でも同様の挙動が見られるケースがあるそうです。さらに、P コアなのか E コアなのかによっても、挙動が変わるという結果が出ていて、かなり奥深い内容になっています。
要するに、「最近の Intel コアは、命令を発行する段階で、『これは連続した小さな定数加算だな』と見抜いて、余分な命令を内部で消しちゃっている。そのおかげで、実際に演算する回数を減らせているのではないか」という考察ですね。
ただし、この機能については、公式のマニュアルにはほとんど説明がなくて、将来の世代でも同じように動くかどうかは分からない、隠れた最適化である、という点も強調されています。マイクロアーキテクチャを実験で炙り出していく、マニアックだけどワクワクする記事です。
。。。。
四つ目は、巨大な Mixture-of-Experts、いわゆる MoE モデルを、家庭用の GPU マシンで動かすことに特化した推論エンジン、「FreeToken」についての解説と検証記事です。
筆者の検証環境は、RTX 五千九十、ビデオメモリ三十二ギガバイトに、メインメモリ百二十八ギガバイトというマシン。ここに、三十五ビリオン級のモデルと、百二十ビリオン級の MoE モデルを載せて、FreeToken、vLLM、それから llama ドット cpp の三つのエンジンで比較しています。
結果として、まず分かったのは、ビデオメモリにすっぽり収まる三十五ビリオン級のモデルの場合、FreeToken は PCI Express 転送のオーバーヘッドだけが増えてしまって、llama ドット cpp や vLLM よりも遅くなる、という点です。
一方で、パラメータが六十五ギガバイト超とか、八十ギガバイト超といった、百二十ビリオン級の MoE モデルになってくると、そもそも他のエンジンではモデルをロードすること自体が難しくなってきます。そのなかで FreeToken は、そういったサイズのモデルを、実用的といえる速度で動かせる、というのが実験で示されています。
特に、gpt オーエスエス・ワンハンドレッドトウェルブイリオン、百二十ビリオンのモデルでは、ビデオメモリ三十二ギガの環境にもかかわらず、単発百二十七トークン毎秒という、かなり高速な生成速度が得られています。
ここで効いているのが、FreeToken の設計思想である、「ビデオメモリに入りきらない MoE モデルを、メインメモリへのオフロードと、エキスパートのキャッシュを組み合わせて動かす」という部分ですね。必要なエキスパートだけをうまく出し入れして、高速化とメモリ節約のバランスを取っています。
筆者の結論としては、「FreeToken の価値は、単純な速度勝負ではなくて、一般的な GPU マシンで扱えるモデルのサイズ上限を押し広げることにある」というところに落ち着いています。
「自宅のマシンで、より大きな MoE モデルを試したい」「でもエンタープライズ級の GPU は持っていない」という人にとって、かなり希望の持てる検証結果になっていました。
。。。。
最後、五つ目の記事は、React 一九・三で入る予定の `browser()` という API の紹介と、その API を OSS ルーターの FUNSTACK Router にどう応用しているか、という解説記事です。
`browser()` は、コンポーネントの中で `use(browser())` と書くことで、「このコンポーネントはサーバー側では描画できないよ。ブラウザ上でだけ描画する必要があるよ」と React に伝えるための仕組みです。
どういう挙動になるかというと、サーバーサイドレンダリング、SSR の最中にそのコンポーネントをレンダリングしようとすると、近くにある Suspense がフォールバック UI に切り替わります。そして、クライアント側で hydration、ブラウザでの再描画と状態の復元が終わったあとに、はじめて本来のコンテンツが表示される、という流れになります。
FUNSTACK Router では、この API を、「パスレス SSR」と呼んでいるモードに組み込んでいます。
「パスレス SSR」というのは、URL がまだ決まっていない状態でとりあえず SSR を走らせる、というようなユースケースですね。ここで問題になるのが、「SSR のときには分からなかった URL が、クライアント側で決まった結果、サーバーとクライアントでレンダリング結果が食い違ってしまう」という、ハイドレーションミスマッチのエラーです。
これを避けるために、FUNSTACK Router では、ルートの中身を実際に描画する `<Outlet />` コンポーネントに `browser()` を組み込んでいます。URL がまだ決まっていないときは、`<Outlet />` が `browser()` 経由でサスペンドしてくれるので、SSR の段階では Suspense のフォールバックだけを出す、という形になります。
そして、クライアント側で URL が決まり、hydration が終わったところで、本当の画面を描画する。こうすることで、「SSR の結果とクライアント側の結果がズレて、エラーになる」というのを回避しているわけですね。
SSR とクライアントサイド、両方をしっかりやろうとすると、どうしても避けて通れないハイドレーションの問題に対して、React 本体の新 API とルーター側の工夫でうまく付き合っていこう、という内容になっています。
。。。。
ということで、きょうの「zenncast」、お届けしてきた記事を、最後に駆け足でおさらいしておきます。
まずは、Rust 一本で iOS と Android のアプリを作れるマルチプラットフォームフレームワーク「Whisker」。Rust の性能と安全性を活かしつつ、Lynx や subsecond を組み合わせた、これからが楽しみなプロジェクトでした。
二つ目は、Markdown ノートを、日本語も含めて関連度順と意味ベースで検索できる CLI ツール「mikke」。ローカル完結の全文検索と意味検索で、自分のノートを AI の長期記憶として活かそう、という面白い取り組みでした。
三つ目は、最近の Intel CPU が、連続した即値付き add／sub を内部でまとめて処理しているらしい、というマイクロアーキテクチャの実験記事。世代やコアごとに挙動が違う、隠れた最適化の姿が見えてきました。
四つ目は、巨大な MoE モデルを家庭用 GPU マシンで動かすことに特化した推論エンジン「FreeToken」。ビデオメモリに入らない百二十ビリオン級モデルを、RAM オフロードとエキスパートキャッシュで現実的な速度まで持っていく、という検証でした。
そして最後は、React 一九・三の `browser()` API と、FUNSTACK Router での「パスレス SSR」への応用。ブラウザ専用コンポーネントをきれいに扱って、ハイドレーションミスマッチを避けるテクニックを紹介していました。
気になった記事があった方は、この番組のショーノートに詳細をまとめておきますので、あとでゆっくりチェックしてみてください。
「zenncast」では、番組の感想や、「こんなテーマを取り上げてほしい」といったリクエストも、いつでもお待ちしています。技術の話でも、雑談でも、お気軽に送ってください。
それでは、きょうはこのへんで。お相手はマイクでした。
また次回の「zenncast」でお会いしましょう。さようなら。