AIニュース最前線
最新ニュースAI日報Hacker日報週報動画AIツールトレンド企業

AIニュース最前線

世界中のAI最新情報を日本語で毎時更新

最新ニュース日報トレンド企業プレミアムRSS
© 2026 ainew.jp特定商取引法に基づく表記
ニュース一覧元記事を開く
MarkTechPost·2026年6月20日 18:23·約8分で読める

ヤンデックスがプロトコルバッファ用ゼロコピーワイヤーフォーマット「YaFF」をオープンソース化

#データシリアライゼーション#ゼロコピー#Yandex#Protobuf#システムパフォーマンス
TL;DR

ヤンデックスがオープンソース化した「YaFF」は、Protobuf の .proto ファイルを維持しつつゼロコピー読み取りを実現し、既存の Protobuf エコシステム内で高速化と柔軟性を両立する新たなワイヤーフォーマットである。

AI深層分析2026年6月20日 10:02
4
重要/ 5段階
深度40%
5
関連度30%
3
実用性20%
5
革新性10%
4

キーポイント

1

Protobuf との親和性

YaFF は Protobuf の代替ではなく、同じ .proto ファイルをソースオブジェクトとして扱い、物理的なメモリレイアウトのみを変更するゼロコピー形式である。

2

4 つのレイアウト戦略

固定型(Fixed)、フラット型(Flat)、スパース型(Sparse)、動的型(Dynamic)の 4 つのレイアウトを提供し、スケーラビリティと読み取り速度のトレードオフを柔軟に選択可能。

3

実証されたパフォーマンス

ヤンデックスの実測では、ホットデータの読み取りが FlatBuffers より約 3.8 倍高速であり、生 C++ 構造体の 1.2 倍の性能を達成している。

4

段階的導入と実運用

エッジ部分で双方向変換を行うことで、特定のホットパスにのみ YaFF を導入可能であり、広告推薦システムでは CPU 使用量を 10〜20% 削減している。

5

圧倒的な読み込み速度と構造体への接近

ベンチマークでは、YaFF のフラットレイアウトが FlatBuffers より約3.8倍、Protobuf より約22倍高速で、生C++構造体の1.2倍以内の性能を達成しています。

6

コンパイラエイリアス解析の最適化

YaFF は生成コードに注釈を追加することで、コンパイラがメモリの再利用を安全と判断させ、重複するアクセスパスの再計算を防ぎキャッシュ効率を高めています。

7

制御可能なプロダクション環境での活用

広告推薦システムやメモリマップドインデックスなど、生産者と消費者が同一管理下にある高負荷読み込みシステムで、CPU 使用量を10-20%削減する効果を実証しています。

影響分析・編集コメントを表示

影響分析

この技術は、大規模データ処理やリアルタイム推論システムにおいて、シリアライゼーション/デシリアライゼーションのオーバーヘッドを劇的に削減する新たな標準となり得ます。特に、既存の Protobuf インフラを維持しつつパフォーマンス向上を図りたい企業にとって、FlatBuffers のような完全な移行コストを回避できる重要な選択肢を提供します。

編集コメント

Protobuf ユーザーにとって、性能ボトルネック解消のための現実的な解決策が提示された画期的なニュースです。既存の資産を維持したまま高速化できる点は、大規模システム運用において極めて価値が高いと言えます。

TLDR

YaFF は、Protobuf 向けの Yandex オープンソース・ゼロコピーワイヤーフォーマットです。Apache 2.0 ライセンスで、現在は C++ で実装され、バージョンは v0.1.0 です。

.proto ファイルが真のソースのままであり、物理的なメモリアウトプットのレイアウトのみが変更されます。

Yandex のベンチマークでは、フラットレイアウトによるホットデータの読み込み速度は FlatBuffers より約 3.8 倍速く、生 C++ 構造体との差は 1.2 倍以内です。

4 つのレイアウト(固定、フラット、スパース、ダイナミック)があり、それぞれが読み取り速度とスキーマの柔軟性の間でトレードオフを行います。デフォルトはダイナミックです。

YaFF は Yandex の広告推薦システムで稼働しており、本番環境スケールでは CPU 使用量を 10〜20% 削減した実績があります。

導入は段階的に行われます:ホットパスの 1 つに YaFF を投入し、エッジ部で双方向 Protobuf 変換を行います。

Yandex は Apache 2.0 の下で YaFF(Yet another Flat Format)をオープンソース化しました。これは高性能な C++ シリアライゼーションライブラリです。YaFF は Protobuf エコシステム向けのゼロコピーワイヤーフォーマットを提供します。.proto ファイルは唯一の真のソースとして維持され、フォーマットの変更はデータがメモリ上にどのように配置されるかという点に限定されます。この技術はサーバーサイドランタイムに焦点を当てています。

YaFF とは何か

YaFF は Protobuf の代替品ではありません。それは Protobuf メッセージ向けの代替ワイヤーフォーマットです。同じ.proto スキーマから、プロトタイプのような C++ API が生成されます。読み取りには解析ステップが不要なため、フィールドはバッファから直接取得できます。パフォーマンスに敏感でないコードでは、依然としてワイヤーフォーマットを Protobuf メッセージへパースして戻すことも可能です。この双方向変換こそが、モジュールごとの段階的導入を現実的なものとしています。YaFF はホットパスの 1 つに導入し、残りの部分は引き続き Protobuf を使用します。

それが解決する課題

Protobuf の解析は、高負荷のバックエンドでは CPU の使用率を二桁パーセントまで消費することがあります。大規模なスケールでは、これは数千もの物理コアに相当します。一般的なゼロコピーオプションとして Google 製の FlatBuffers が挙げられますが、FlatBuffers は Protobuf のドロップイン代替ではなく、別個のスキーマと変換レイヤーの維持を必要とします。意味論的に Protobuf と互換性がないため、移行にはスキーマの重複、異なるスキーマ進化ルール、そして手書きによるフィールドコンバータが必要となります。多くのチームは、このコストに見合わないという結論に至ります。YaFF はこのギャップを埋めることを目指し、Protobuf の意味論を維持したままゼロコピー読み取りを実現します。

レイアウトの仕組みについて

レイアウトは、メッセージがバッファ内にどのように保存されるかを決定するものです。これは物理的な表現のみを変更し、スキーマや生成されたインターフェースには変更を加えません。YaFF では 4 つのレイアウトが提供されています。「Fixed」はヘッダーを持たない単純なパッキング済み構造体で、スキーマは固定されます。「Flat」は 2 バイトのヘッダーを追加し、スキーマ進化をサポートします。「Sparse」はメタテーブルを通じてフィールドにアクセスするため、疎なスキーマに適しています。「Dynamic」がデフォルトであり、実行時に Flat または Sparse を選択します。スキーマが許容する場合は Flat を使用し、進化によってフラットなアライメントが崩れた場合に Sparse に切り替えます。

レイアウト 読み取りアクセス メッセージごとのオーバーヘッド スキーマ進化 最適な用途

Fixed 1 回の読み取り、0 回の分岐 0 バイト 固定 小規模なインラインプリミティブ

Flat 2 回の読み取り、1 回の分岐 2 バイト 制限あり(型保存) 密なデータ、ホットデータ

Sparse 4 回の読み取り、2 回の分岐 6 バイト 制限なし 疎なスキーマ、自由な進化

動的(デフォルト)/ランタイム時のフラットまたはスパース / 2 または 6 バイト / 制限なし / 一般的なアプリケーションロジック

ベンチマーク

ヤンデックスは、google/benchmark を使用してビルドされた再現可能なベンチマークスイートをリリースビルドとして提供しています。以下の数値は、AMD EPYC 7713 プロセッサと Clang 20.1.8 コンパイラ環境における、読み取りあたりの中央値ナノ秒数を示しています。数値が小さいほど高速です。ホットな階層ケースにおいて、フラットレイアウトの読み込み時間は 9.79 ナノ秒です。FlatBuffers は 37.30 ナノ秒を要し、Protobuf(プロトコルバッファ)は 219.35 ナノ秒かかります。一方、生 C++ 構造体のベースラインは 8.14 ナノ秒です。つまり、フラットレイアウトはここでは FlatBuffers より約 3.8 倍、Protobuf より約 22 倍高速であり、生構造体との差も 1.2 倍以内に収まっています。

フォーマット 読み込み時間(ナノ秒) 生構造体に対する遅延率

生 C++ 構造体 8.14 1.0×

YaFF フラットレイアウト 9.79 1.2×

YaFF スパースレイアウト 21.23 2.6×

FlatBuffers 37.30 4.6×

Protobuf(プロトコルバッファ) 219.35 26.9×

読み取りあたりの中央値ナノ秒数、階層化/ホット/チェーンキャッシングなし。出典:https://yaff.tech/docs/en/benchmarks/access

注:絶対値はホスト CPU とメモリに依存しますが、フォーマット間の比率はハードウェアを跨いで概ね維持されると予想されます。

コンパイラエイリアシングの詳細

FlatBuffers と YaFF はどちらも、生メモリをターゲット型として再解釈することでフィールドを読み取ります。この型パニングにより、TBAA(Type-Based Alias Analysis)には十分な情報が不足し、LLVM のエイリアス解析は保守的な MayAlias 判定に依存せざるを得なくなります。その結果、コンパイラは繰り返しアクセスが再利用可能であることを証明できず、root.intermediate().leaf().a() を二度呼び出すたびにツリーを再走査することになります。YaFF は生成されたコードに注釈を追加し、再利用が安全なタイミングをコンパイラに伝えます。関連するメモリが読み取り間に修正されていない限り、YaFF の生成コードによる注釈は、コンパイラがアクセスチェーンの再利用を支援できることがよくあります。読み取り間にメモリの書き込みが行われない限り、YaFF は独自にアクセスチェーンをキャッシュします。

適用領域:ユースケース

YaFF は、プロデューサーとコンシューマーの両方を制御できるシステムを対象としています。推薦や広告配信バックエンドが最も明確な適用例です。Yandex によると、YaFF は同社の広告推薦システムで動作しており、本番環境スケールでは CPU 使用量を 10〜20% 削減できると報告されています。メモリモップドインデックスは二つ目の適用領域です。ホストは数十ギガバイトのローカルデータを保持できます。これらの mmap 可能なインデックスは、サービス再起動時に再解析することなく存続します。検索インデックス、特徴量ストア、フィードサービスはいずれも、この読み取り集中型のプロファイルを持っています。計画されているカラムナーレイアウトは、大規模な繰り返しフィールドを持つ分析および機械学習パイプラインを対象としています。YaFF は FlatBuffers よりもコンパクトになる可能性があり、キャッシュ動作の向上に寄与します。

コード概観

読み取りパスは、パースステップを除き Protobuf と同様です。

Copy CodeCopiedUse a different Browser

#include "feed.pb.h" // protoc によって生成

#include "feed.yaff.h" // yaff_generate() によって生成

// 1. 既存の Protobuf メッセージを YaFF バッファにシリアライズする。

feed::FeedResponse proto = LoadFeedResponse();

const auto buffer = yaff::Serialize(proto);

// 2. バッファから直接フィールドを読み取る。パース処理は不要。

const auto& response = yaff::ReadMessage(buffer.Data());

for (const auto& item : response.items()) {

std::string_view title = item.title();

std::string_view author = item.author().name(); // 著者が未設定の場合は空文字

}

// 3. コンシューマーがパース済みメッセージを必要とする場合は、Protobuf に変換する。

feed::FeedResponse restored;

response.ParseTo(restored);

YaFF は CMake (find_package) または Conan を通じて追加します。コード生成では protobuf_generate() の後に yaff_generate() が実行されます。生成された YaFF タイプは protoyaff:: ネームスペースに存在します。ほとんどのプロジェクトでは yaff::core と yaff::proto だけをリンクすれば十分です。

リソース:

GitHub リポジトリとドキュメントをご覧ください。

本記事「Yandex Open-Sources YaFF: A Zero-Copy Wire Format for Protobuf With Near-Struct Read Speed」は、MarkTechPost にて最初に公開されました。

原文を表示

TLDR

YaFF is Yandex’s open-source zero-copy wire format for Protobuf — Apache 2.0, currently C++, v0.1.0.

The .proto file stays the source of truth; only the physical memory layout changes.

On Yandex’s benchmarks, the Flat Layout reads hot data ~3.8× faster than FlatBuffers, within 1.2× of a raw C++ struct.

Four layouts — Fixed, Flat, Sparse, Dynamic — trade read speed for schema flexibility; Dynamic is the default.

YaFF runs in its advertising recommendation system, where it reports 10–20% CPU savings at production scale.

Adoption is incremental: drop it into one hot path, with two-way Protobuf conversion at the edges.

Yandex has open-sourced YaFF (Yet another Flat Format) under Apache 2.0. It is a high-performance C++ serialization library. YaFF provides a zero-copy wire format for the Protobuf ecosystem. Your .proto file stays the single source of truth. The format only changes how data sits in memory. It concentrates on server-side runtimes.

What is YaFF

YaFF is not a replacement for Protobuf. It is an alternative wire format for Protobuf messages. The same .proto schema generates a proto-like C++ API. Reads need no parsing step, so fields come straight from the buffer. Less performance-sensitive code can still parse the wire format back into Protobuf messages. That two-way conversion is what makes module-by-module adoption realistic. You introduce YaFF in one hot path and leave the rest on Protobuf.

The Problem it Targets

Protobuf parsing can consume double-digit percentages of CPU in high-load backends. At scale, that maps to thousands of physical cores. The common zero-copy option is FlatBuffers, also from Google. But FlatBuffers is not a Protobuf drop-in and requires maintaining a separate schema and conversion layer. semantically incompatible with Protobuf. Migrating means duplicated schemas, different schema-evolution rules , and hand-written field converters. Many teams conclude the cost is not worth it. YaFF aims at that gap: zero-copy reads with Protobuf semantics preserved.

How the Layouts Work

A layout decides how a message is stored in the buffer. It changes only the physical representation, leaving the schema and generated interfaces unchanged. YaFF ships four layouts. Fixed is a plain packed struct with no header and a frozen schema. Flat adds a two-byte header and supports schema evolution. Sparse addresses fields through a meta table, fitting sparse schemas. Dynamic is the default and selects Flat or Sparse at runtime. It uses Flat while the schema permits, then switches to Sparse when evolution breaks flat alignment.

LayoutRead accessPer-message overheadSchema evolutionBest for

Fixed1 read, 0 branches0 bytesFrozenSmall inlined primitives

Flat2 reads, 1 branch2 bytesRestricted (type preservation)Dense, hot data

Sparse4 reads, 2 branches6 bytesUnrestrictedSparse schemas, free evolution

Dynamic (default)Flat or Sparse at runtime2 or 6 bytesUnrestrictedGeneral application logic

Benchmark

Yandex ships a reproducible benchmark suite, built with google/benchmark in a Release build. The numbers below are median nanoseconds per read on an AMD EPYC 7713 with Clang 20.1.8. Lower is faster. In the hot hierarchical case, the Flat Layout reads in 9.79 ns. FlatBuffers needs 37.30 ns, and Protobuf needs 219.35 ns. The raw C++ struct baseline is 8.14 ns. So the Flat Layout reads about 3.8× faster than FlatBuffers here, and about 22× faster than Protobuf. It stays within 1.2× of the raw struct.

FormatRead time (ns)Slowdown vs raw struct

Raw C++ struct8.141.0×

YaFF Flat Layout9.791.2×

YaFF Sparse Layout21.232.6×

FlatBuffers37.304.6×

Protobuf219.3526.9×

Median ns per read, hierarchical / hot / no chain caching. Source: https://yaff.tech/docs/en/benchmarks/access

Note: The absolute numbers depend on the host CPU and memory. The ratios between formats are expected to hold across hardware.

The Compiler Aliasing Detail

FlatBuffers and YaFF both read fields by reinterpreting raw memory as the target type. That type-punning leaves TBAA without strong enough facts. So LLVM’s alias analysis falls back to a conservative MayAlias verdict. The compiler then cannot prove that repeated accesses are safe to reuse. Writing root.intermediate().leaf().a() twice re-walks the tree each time. YaFF adds annotations in its generated code that tell the compiler when reuse is safe. YaFF’s generated-code annotations can often help the compiler reuse the access chain, as long as the relevant memory is not modified between reads. As long as nothing writes to memory between reads, YaFF caches the access chain on its own.

Where It Fits: Use Cases

YaFF targets systems where you control both producer and consumer. Recommendation and ad-serving backends are the clearest fit. According to Yandex, YaFF runs in its advertising recommendation system, where it reports 10–20% CPU savings at production scale. Memory-mapped indexes are a second fit. A host can hold tens of gigabytes of local data. Those mmap-able indexes survive service restarts without re-parsing. Search indexes, feature stores, and feed services share that read-heavy profile. The planned Columnar Layout targets analytics and ML pipelines with large repeated fields. YaFF can also be more compact than FlatBuffers, which helps cache behavior.

A Look at the Code

The read path mirrors Protobuf, minus the parse step.

Copy CodeCopiedUse a different Browser

#include "feed.pb.h" // generated by protoc

#include "feed.yaff.h" // generated by yaff_generate()

// 1. Serialize an existing Protobuf message into a YaFF buffer.

feed::FeedResponse proto = LoadFeedResponse();

const auto buffer = yaff::Serialize<protoyaff::feed::FeedResponse>(proto);

// 2. Read fields directly from the buffer. There is no parsing step.

const auto& response = yaff::ReadMessage<protoyaff::feed::FeedResponse>(buffer.Data());

for (const auto& item : response.items()) {

std::string_view title = item.title();

std::string_view author = item.author().name(); // empty if author is unset

}

// 3. Convert back to Protobuf when a consumer needs the parsed message.

feed::FeedResponse restored;

response.ParseTo(restored);

You add YaFF through CMake (find_package) or Conan. Code generation runs protobuf_generate() then yaff_generate(). Generated YaFF types live in the protoyaff::<package> namespace. Most projects only link yaff::core and yaff::proto.

Resources:

Check out the GitHub repository and Documentation.

The post Yandex Open-Sources YaFF: A Zero-Copy Wire Format for Protobuf With Near-Struct Read Speed appeared first on MarkTechPost.

この記事をシェア

関連記事

MarkTechPost★42026年6月20日 18:05

基盤モデルと自動異常検出を用いた TimeCopilot による予測パイプラインの構築方法

MarkTechPost は、TimeCopilot を活用して航空会社乗客データや合成データを処理するエンドツーエンドの予測ワークフローを構築する方法を紹介し、統計モデルや基盤モデルの評価手法を解説している。

MarkTechPost★42026年6月20日 07:51

NVIDIA AI、空間推論のためのトレーニング不要エージェント「SpatialClaw」を発表:コードを行動インターフェースとして活用

NVIDIA Research は、視覚言語モデルの弱点である物体の位置や関係性の判断を改善するトレーニング不要フレームワーク「SpatialClaw」を発表した。同チームは、知能エージェントが知覚ツールを呼び出す際の行動インターフェースこそがボトルネックであると指摘し、コードをそのインターフェースとして扱う解決策を提案している。

MarkTechPost★42026年6月20日 07:06

VibeThinker-3B:Qwen2.5-Coder-3Bを基盤にスペクトルから信号へのポストトレーニングパイプラインで構築された 30 億パラメータの密着型推論モデル

中国の新浪微博研究所が開発した「VibeThinker-3B」は、大規模なパラメータ数に依存しない効率的なアプローチを採用し、検証可能なタスクにおいて数百倍サイズのモデルと同等の性能を発揮する 30 億パラメータの推論モデルとして公開された。

今日のまとめ

AI日報で今日の重要ニュースをまとめ読み

ニュース一覧に戻る元記事を読む