VXNという、AI Nativeを前提にした独自プロトコル／Runtimeを開発している。
最初から「JSONを置き換えよう」と考えていたわけではない。
LLMが生成した情報をJavaScriptやPythonなどの高水準表現へ落とし、それをさらに別のRuntimeへ渡し、また文字列やJSONへ変換する。
この繰り返しを見ていて、一つの疑問が生まれた。
AI同士やAIとRuntimeの間で、本当に人間向けの表現を毎回経由する必要があるのか？
そこからVXNの開発が始まった。
VXNとは何か
VXNは、単なる独自シリアライズ形式ではない。
LLMや各種フロントエンドから入ってきた要求をSemantic IRへ収束させ、Policy、Native Lowering、Compiler、Runtimeを経由して実行するためのAI Native基盤として設計している。
考え方は単純だ。
Vera proposes. VXN compiles. Workstation measures. Evidence decides.
LLMが提案する。
VXNがコンパイルする。
Workstationが実測する。
そして最後はEvidenceで判断する。
今回は、この最後の部分を本気でやってみた。
まずJavaScript、Python、Rust、VXNを戦わせた
最初のBenchmark Arenaでは、同一マシン上で同じ意味処理を実行し、JavaScript、Python、Rust Native、VXNを比較した。
重要なのは、VXNを勝たせるためのベンチマークにしないことだった。
プロセス起動時間と純粋なEngine処理を分離し、warmupを行い、medianだけでなくp95、p99も測定した。
さらにスコアリング式も結果を見る前に固定した。
そのPhase 1で得られたLatency Scoreは次の通りだった。
Rust Native：96.047431
VXN Compile+Execute：84.036673
VXN Precompiled：78.721477
Python：47.657291
Node：9.224473
ここで重要なのは、VXNがRustに勝ったことではない。
Rust Nativeにかなり近い場所まで来たことだった。
RustはVXNが倒すべき相手ではない。
むしろVXNがどこまでNativeへ接近できたかを見るための基準線である。
100,000スケールの試験では、VXN PrecompiledのLatencyはRust Nativeのおよそ1.12倍だった。
一方、同じ試験でNodeに対しては約4.75倍、Pythonに対しては約2.01倍低いLatencyとなった。
もちろんこれは特定workloadに限定された結果であり、あらゆる処理で同じ倍率になるとは主張できない。
しかし「VXNをNative側へ寄せる」という設計思想そのものは、少なくとも実測可能な形になった。
ところが最後に問題が見つかった
本命はJSONとの比較だった。
ところが調査してみると、VXNには正式なWire Codecがまだ存在していなかった。
これではJSONのencode/decodeと公平に比較できない。
そこで対戦を一度止めた。
ベンチマークのためだけに偽物のVXNバイト列を作ることもしなかった。
先にVXNそのものへ正式なWire Codecを実装した。
現在のVXNが持つValueは、
Integers(Vec)
Integer(i64)
Unit
の3種類。
これらを対象として、versioned header、deterministic encoding、bounded length、malformed inputのfail-closed、semantic roundtripを備えた最小Production CodecをRustで実装した。
全テストを通過させてから、ようやくJSONとの最終戦を開始した。
JSON vs VXN 最終戦
条件は事前に固定した。
同一Rust release process。
同一の整数列。
同一Semantic Result。
プロセス起動やファイルI/Oは計測区間から除外。
warmup後に計測。
各scaleで3回実行。
そしてdecode後の意味値が一致しなければ、その計測自体を成立させない。
結果はこうなった。
| 要素数 | JSON Roundtrip | VXN Roundtrip | JSON / VXN |
|---|---|---|---|
| 1 | 0.100 µs | 0.100 µs | 1.00x |
| 100 | 1.100 µs | 0.200 µs | 5.50x |
| 10,000 | 96.900 µs | 47.000 µs | 2.06x |
| 100,000 | 1,329.300 µs | 410.000 µs | 3.24x |
100,000整数のroundtripでは、
JSON 1,329.3µs
に対して、
VXN 410.0µs
となった。
今回のworkloadでは、VXNはJSONの約3.24倍のroundtrip性能となった。
「JSONより速ければOK」
という最初の目標については、少なくともこの実験条件では達成した。
でも、全部勝ったわけではなかった
ここからが面白い。
Payload Sizeを見ると結果が逆転する。
100,000要素の場合、
JSON：588,896 bytes
VXN：800,010 bytes
だった。
つまり現在のVXN Wire Codec v2は、
速度ではJSONを上回った。
しかし、
データ密度ではJSONに負けた。
これは失敗というより、次に何を開発すべきかを非常にはっきり示している。
現在のVXNは整数をNative寄りの固定幅表現として扱っているため、数値の大きさによって文字数が変化するJSONに対して、小さな整数が大量に並ぶ今回のworkloadではサイズ面で不利になる。
逆に言えば、ここにはまだVarInt、delta encoding、packing、semantic-aware compressionなどを検証できる大きな余地が残っている。
ただし、それを今回の対戦結果を見てから追加することはしなかった。
結果を見た後でルールを変えれば、Benchmark Arenaではなくなってしまうからだ。
一番大きかった収穫
今回分かったことは「VXNがJSONより3.24倍速かった」という数字だけではない。
もっと重要だったのは、
VXNを計測可能な技術にできたこと
だと思っている。
アイデアだけなら、いくらでも速いと言える。
AIに聞けば、もっともらしい性能予測も出してくれる。
しかし、それはEvidenceではない。
今回の開発では途中で何度も失敗した。
存在しない型を仮定した。
crate名を間違えた。
Rustの構文を間違えた。
Windowsのcp932でレポート出力まで転んだ。
そのたびに止めて、Rollbackし、Rayで実物を観測し直して、再実装した。
そして最後に残った数字だけを採用した。
この開発方法そのものが、VXN以上に重要なのかもしれない。
LLMに正解を決めさせない。
LLMは仮説を出す。
Compilerが形にする。
Workstationが実行する。
Evidenceが事実を返す。
そしてHumanが判断する。
次は「速いVXN」から「小さくて速いVXN」へ
今回の結果で、次の研究対象は明確になった。
VXN Wire Codecの密度最適化だ。
目標は単純な「JSONより小さい」ではない。
VXNが持っているSemantic情報を失わず、
Nativeに近い処理速度を維持しながら、
Wire上でも高密度にする。
つまり、
Fast Native Runtime
から、
Fast + Dense AI Native Protocol
への進化である。
JSONを否定する必要はない。
外部との互換境界では、JSONはこれからも非常に便利だ。
しかしVertex内部、AI間通信、Runtime間通信まで、すべてを人間向けテキスト形式で運ぶ必要があるのか。
今回の実験は、その問いに対する最初の実測結果になった。
VXNはまだ完成ではない。
むしろ今回、
次に削るべき場所が数字として見えた。
ここからがVersion 2の本番だと思っている。