https://vortex.dev がFirefoxで動かないんだけど：アプリケーションエラーが発生しました。vortex.devを読み込む際にクライアント側の例外が発生しました（詳細はブラウザのコンソールを確認してね）。コンソール：webglコンテキストを作成できませんでした。

「なんでパーケットが嫌いなの？」

AIは4.0だと思う。EDIT> もしかしたら、4次元を時間と呼ぶ人がいるけど、実際には4次元の空間があるってことかな。だから、これが3次元データなら、4次元は何になるんだろう？

いくつかの暗号会社がちょっとおしゃれにして、3.0を飛ばして4.0に行こうとしたから、そうなると私たちは5.0、4.0、3.1、2.2、または2.1のどれかになるよね。暗号の世界についてどう感じるか、どのグループを検証してたかによって。

「いや、Web 3.0はセマンティックウェブだったよ。幸いなことに、インターネット全体にメジャーバージョンを持たせるっていう馬鹿げたアイデアは、その時に消えた。今はそれをやろうとする人を無視しても大丈夫だね。」

ちょっと混同してるよ。参考までに言うと、Web3はせいぜい蛇油か願望的な考えに過ぎない。みんなが古いWeb 2.0を批判したがるけど、概念的にはまだまだ通用するよ。もしそれをただのバズワードとしてしか知らないなら、少し戻って勉強した方がいいよ。段階的な変化を求めてるならね。もしかしたら、Web 3.1がエンシティフィケーションから救ってくれるかも。

新しい時代に入ったと思うから、このウェブのバージョンを「AAI 1」と考えてる。来年は「AAI 2」になるし、そんな感じで続いていくと思う。この時代は「AI支配者の年」とか「Anno Domini Artificialis Intellegentiae Artificialis」と呼ばれることになるだろうね（グーグル翻訳によると）。

「どこかでトランザクションについて触れてる？もしかしてOLAPになるのかな？」

記事からすると、OLAPだけの話に聞こえた。

「“mongodbはウェブスケール”って言ってた頃、覚えてる？それが今は“spiralはAIスケール”って感じだね。」

「“革命的”な主張には懐疑的になるくらいデータシステムを作ってきたから、”AI時代のために作られた”みたいな大げさな表現にはちょっと抵抗がある。でも、…革命的な主張や”AI時代のために作られた”みたいな大きなことを言っちゃうけど。」

「多分、友情の力と巨大なドリルで巨大ロボットを倒すか、呪われた村で中毒性のある渦にハマるかのどっちかだね。」

「最近のハードウェアの進化を活かした低レベルの最適化やフォーマット/パイプラインの統一と簡素化のおかげで、すごくパフォーマンスの高いDBになるって読んだ。」

私の理解では、データベースは基本的にGPUに直接供給できるバイナリ形式でデータを保存し、大きなデータのストリーミングやバッチ処理に最適化されるってこと。つまり「機械が消費するために最適化されている」ってことはGPU向けってことだね。彼らのユースケースは、MLモデルのトレーニングで、GPUに大量のデータセットを供給する必要があるってこと。彼らは、トレーニングがGPUにデータを供給する速さによってボトルネックになっていると主張していて、そうでなければGPUはほとんど「IOを待っている」状態で、実際には計算していない。次のデータを取得して、GPU用に変換して、GPUに供給するのに時間がかかるから。でも、私は専門家じゃないから、これは記事からの私の見解に過ぎないよ。

おそらく、単純に生データのサイズとRUの物理的制限が組み合わさって、GPUをフル活用するのが難しいんだと思う。結局、CPU（パーケットの解凍・解釈・アップロード）や帯域幅（S3からの転送）がボトルネックになってしまう。彼らは、S3バケットからGPUへの低オーバーヘッドな経路を目指しているみたいで、同じ圧縮・高速ランダムアクセス、飛行中のS3からのストリーミングエンコーディング、GPUへのゼロコピーを狙っている。詳細は100%クリアじゃないけど、CPU/GPUバスを実際に飽和させることは難しいと思う。ただGPUの利用率を飽和させることはできるけど、それ自体がいくつかのボトルネックに依存していて、一般的にはバス帯域幅には依存しない。これは批判じゃなくて、AIモデルのGPU利用率を改善しない限り、これ以上は無理ってことだよ。

アイデアとしては、作業のパイプラインではスループットが最も遅いコンポーネントによって制限されるってこと。H100 GPUはたくさんのメモリ帯域幅を持ってる。だから、データストアとGPUのメモリの間のボトルネックをどうやって排除するかが問題になる。まずはストレージのボトルネック。ネットワーク接続ストレージは、キャッシュされていないデータにとっては通常ボトルネックになる。次に、データをデコードするためのCPU作業がある。スパイラルは、彼らのテーブルフォーマットがGPUによってロード可能で、さまざまなCPU依存のデコードステージをバイパスできると主張している。ストレージとCPUのボトルネックを排除したら、残るボトルネックはホストメモリとGPUの間にあるPCIバスで、彼ら自身ではそれを解決できない。（バスが飽和しているときに並列化しても助けにはならない。）彼らができるのは、ネットワーク、ホストバス、GPUをより効率的に使うこと。データを圧縮してパッキングすることで、機械的な共感を高めている。商業化の方法については答えがないけど、私の予想では、追加のパフォーマンスや機能を提供するVortexの独自フォークを使うか、商業サービスや統合を提供して使いやすくするんじゃないかな。オープンソースのリリースは、顧客に「信じる理由」を与える、マーケティング用語で言うところの。

そもそも「AIスケール」って何なんだ？

複数のテーブルを1つのファイルに保存するのは、基本的な圧縮されていないtarボールに複数のParquetファイルを保存することで簡単に解決できるよね。これで、全体をダウンロードしなくてもファイルのどの部分にもアクセスできるし。もしくはarやcpioでもいいかも。tarはリンクのサポートとか余計な機能が多すぎるから。基本的には、非常にシンプルなディレクトリ構造を実装していて、予測可能なオフセットにシンプルなインデックスがある、よく標準化された何かがあればいいんだけどね。もしそんなツールがあれば。

LanceはParquetの問題を解決するために既に存在してるけど、ランダムアクセスの速度がめちゃくちゃ速いんだよね。

「1つのファイルに複数のテーブルとデータベースのような意味合いが欲しい」なら、DuckDBがぴったりだよ。モダンなParquetが欲しいなら、Lanceフォーマット（またはDBのようなCRUDセマンティクスのためのLanceDB）がいいね。

スパイラルはVortex上に構築された私たちのデータベースです [...] 何も見るものがないのは当然だよ、基本的には彼らのブログに載せられたプレスリリースだから。