C++ でのニューラル ネットワーク用のオープンソース ライブラリの使用

C++ でのニューラル ネットワーク用のオープンソース ライブラリの使用

C++ でのニューラル ネットワーク用のオープンソース ライブラリの使用

導入

現代の AI は、多くの場合、Python、ノートブック、デモ環境、そしてモデルが初めて機能するのを見たときの当然の興奮を通じて会社に入社します。そのフェーズは現実的で、便利で、少し魔法的ですらあります。それは、好奇心が安く、反復が速いところです。しかし、実際の製品の寿命はデモで終わるわけではありません。顧客にサービスを提供し、バックエンドに適合し、工場のハードウェア上で実行し、デスクトップ製品内で稼働し、劣悪なネットワーク条件に耐えなければならないモデルは、もはや単なるモデルではありません。それはシステムのコンポーネントとなり、システムはエンジニアリングの成熟度が重要になり始める場所です。

それは、C++が部屋に戻った瞬間です。生産現場では、より高いレベルの実験を延期できる期間が限られているような疑問が生じます。プロセスに実際に必要なメモリ量はどれくらいですか?負荷がかかった状態での定常状態のレイテンシはどれくらいですか?起動時間は自動スケーリングに耐えることができますか?ランタイムは既存のネイティブ アプリケーション内に存在できますか?研究スタックを中心に製品全体を再構築せずに、同じ推論パスをサーバー、エッジボックス、オペレーターワークステーションに出荷することはできますか?

オープンソース ライブラリは、ベンダーのブラック ボックスに制御を明け渡すことなく、この移行を可能にします。これらは、安定したランタイム、テンソル抽象化、最適化されたカーネル、量子化された実行パス、ハードウェア対応バックエンド、そして最近の LLM 時代では驚くほど有能なローカル推論エンジンを提供します。しかし、図書館の多さが状況を混乱させる可能性もあります。エンジニアは、どのライブラリが最適であるかをよく尋ねますが、より良い質問は、どのライブラリが目の前の仕事に誠実であるかということです。

この記事では、そのより現実的な道をたどります。 AI の主要な C++ 関連ライブラリを、長所、盲点、および操作上の前提を備えたエンジニアリングの特徴として見ていきます。最終的な目標は、ONNX Runtime、LibTorch、oneDNN、OpenVINO、TensorFlow Lite、llama.cpp がいつ役立つのか、それぞれが重くなりすぎるとき、狭くなりすぎるとき、そして流行に流されずに選択する方法を理解することです。

AI システムが C++ に戻り続ける理由

AI の配信には、明確に名前を付ける価値のあるリズムがあります。一度理解すると、多くのアーキテクチャの選択が理解しやすくなるからです。まず最初に発見段階があります。研究者や製品エンジニアは、そのモデルで何ができるのか、どのようなデータが必要なのか、実際にどこに価値があるのか​​をまだ学んでいる最中です。その段階では、表現力が規律に勝ります。迅速な実験、豊富な Python ツール、および柔軟な研究フレームワークは、まさにチームが必要としているものです。

次に、あまり魅力的ではない第 2 段階が始まり、プロトタイプに義務が蓄積され始めます。サポート チームは障害を理解する必要があります。 SRE チームは、予測可能な起動とメモリの動作を望んでいます。財務部門は、サービス請求額が一時的な急増なのか、それとも永続的な漏れなのかを知りたいと考えています。組み込みの顧客から、モデルがオフラインで実行できるかどうか尋ねられました。セキュリティレビューでは、バイナリ内に正確に何が含まれているのか、またどの部分が監査できるのかが問われます。突然、モデルは研究成果物ではなくなり、実稼働環境の一員になります。

C++ は、エンジニアリング部門が具体的な質問に手を振るのではなく答えられるようになるため、その時点でリピートし続けています。ネイティブ サービスは、割り当て戦略、スレッド プール、ABI 境界、パッケージ化、CPU 固有の最適化、既存のパフォーマンス重視のサブシステムとの統合を制御できます。このコントロールは必要な場合に最も重要であり、そこではレトリックで偽造することが非常に困難です。

ここでは便利な反例が役に立ちます。チームが 1 時間に 1 回実行される、負荷の軽い内部ドキュメント分類器を構築している場合、最も抵抗の少ないパスは、安定したサービス提供フレームワークとネイティブ コードがほとんどない Python サービスである可能性があります。それは何も恥ずかしいことではありません。一方で、同じチームがレイテンシの影響を受けやすい C++ デスクトップ アプリケーション内に推論を埋め込んだり、リソースが限られたエッジ デバイスに送信したり、モデルの実行をホット バックエンド パスに直接挿入したりしている場合、ランタイム言語が問題ではないふりをするのは、すぐにコストが高くなります。言い換えれば、C++ は、システム自体に問題が生じるたびに、最も深刻な解決策の 1 つとして残ります。

エンジニアリングの個性としての図書館

このエコシステムで迷子になる最も簡単な方法は、すべてのライブラリを同じ仕事を求めて競合しているかのように扱うことです。そうではありません。トレーニング指向のフレームワーク、ポータブル推論ランタイム、カーネル ライブラリ、およびローカル LLM エンジンはすべて、さまざまな問題を解決します。これらを AI ライブラリと呼ばれる 1 つのカテゴリに分類すると、システム設計ではなくブランドの馴染みに基づいて選択することになります。

ONNX Runtime は、多くの制作環境において、最も規律があり、煩雑さが少ない選択です。これは、モデルを安定した形式にエクスポートし、実行に重点を置いたランタイムを通じてロードし、アプリケーションがシステムの残りの部分を所有できるようにするという明確な約束に基づいて構築されています。それは簡単に聞こえますが、シンプルさこそが強力な理由です。 ONNX Runtime は、研究フェーズがすでに他の場所で行われており、残っているのは、推論を繰り返し、移植可能に、予測可能な動作動作で提供する地味な作業だけである場合、多くの場合、正しい答えです。画像を受け取り、テンソルを正規化し、既知のグラフを実行し、結果を既存の C++ サービスに返すコンピューター ビジョン バックエンドは、理想的な ONNX Runtime ストーリーです。適合度が低い製品は、その核となる価値が、動的なトレーニング時の動作、アプリケーション内での頻繁なグラフ操作、またはエクスポートを脆弱にする絶えず変化するカスタム演算子のセットに依存する製品です。このような場合、最初はきれいに見えた実行時の境界が摩擦の原因になる可能性があります。

LibTorch は性質が異なります。これは主に軽量の実行境界ではありません。これは、完全な深層学習フレームワークの C++ の顔です。それにより重くなりますが、より表現力豊かになります。ネイティブ アプリケーションが本当にテンソルの所有権、モデルの構築、トレーニングのような操作、または開発と運用全体にわたる PyTorch セマンティクスに近い必要がある場合、LibTorch は ONNX Runtime よりも魅力的になります。製品がランタイム境界ではなくフレームワークを本当に必要とする場合、それを選択することにはある程度の誠実さが必要です。反例も同様に重要です。チームは、単純な静的推論に LibTorch を採用することがあります。これは、権威ある、または将来性があると思われるためです。その後、必要なワークロードよりもはるかに大きな概念的および運用面をインポートしたことに気づきました。安定したモデル グラフをロードすることだけが必要な小規模な推論サービスでは、パッケージのサイズ、複雑さ、デバッグの労力という点で、その決定の代価が支払われる可能性があります。

oneDNN と OpenVINO は金属に近い環境にあり、パフォーマンスをより重視する考え方に報います。 oneDNN は、CPU カーネル、メモリ形式、オペレータレベルの効率が直接注目に値するほど重要になったときに重宝するライブラリです。多くのチームは、より高いレベルのランタイムを通じて間接的にこれを使用していますが、これは多くの場合賢明です。一方、OpenVINO はより戦略的な場所にあります。これは、下位レベルの詳細をすべて手動で管理したくない、インテル指向の導入、グラフの最適化、ハードウェアを意識した実行に関心を持つチームを支援します。実際には、ビジネス上の問題が単に「モデルを実行する」だけではなく、「実際に購入、導入、保守できるハードウェア上で効率的にモデルを実行する」ことになったときに、これらのツールが重要になり始めます。この区別は会議では小さなものに見えますが、予算では非常に大きくなります。

TensorFlow Lite は、まったく別の気質を表します。自粛の声です。エッジ デバイス、モバイル ターゲット、およびリソースに制約のあるシステムでは、完全性は適合性よりも価値が低いことがよくあります。エンジニアはそこに壮大なフレームワークを必要としません。メモリ、パッケージ サイズ、エネルギー使用量、起動時間などの厳しい制約をロードし、実行し、その範囲内に留まるモデルが必要です。 TensorFlow Lite は、デプロイメント ターゲット自体がアーキテクチャを形成する主な力である場合に意味を成します。反例もよくあります。チームは、効率的だと思われるエッジ ランタイムから始めて、それを徐々に拡張して、より広範なサーバー プラットフォームや、サポートするために構築されたものよりも動的なニーズを伴うワークフローに拡張します。エッジでの効率が他の場所で自動的に快適になるわけではありません。

次に、llama.cpp があります。これは、局所推論の感情マップを変更したため、特に注目に値します。 llama.cpp や同様のプロジェクトが主流になる前、多くのエンジニアは、ローカルの大規模言語モデルの提供は研究用のおもちゃかエンタープライズ アプライアンスにとどまると考えていました。 llama.cpp は、さらに興味深いことを実証しました。積極的な量子化、慎重なカーネル作業、規律あるエンジニアリングにより、最新の LLM は通常のシステム内のローカル ネイティブ コンポーネントになる可能性があります。その洞察は、1 つのプロジェクトを超えて重要です。これは、ネイティブ実行、モデル圧縮、および実際のデプロイメントが、集中型の説明が示唆するよりもはるかに速く進む可能性があることを現場全体に思い出させました。しかし、llama.cpp にも自然な境界があります。これは、ジョブがサポートされている変圧器モデルをローカルかつ効率的に実行している場合に優れています。これはディープラーニング エコシステム全体の一般的な代替品ではないため、チームがそれを 1 つになるように要求すると問題が発生します。

誇大広告に惑わされずに選ぶ方法

これらのライブラリの中から選択する最も信頼できる方法は、製品から始めて、後でツールに名前を付けることです。まず、アプリケーションが実際に何を所有し、何を単に消費しているのかを考えることから始めます。システムが主に安定したモデルを使用し、移植性の高い制限された推論を必要とする場合、多くの場合、ONNX Runtime が最も冷静な答えになります。システム自体がテンソル、モジュール、フレームワーク セマンティクスの言語で話さなければならない場合、LibTorch について議論する価値があります。 CPU の効率、グラフの最適化、または Intel を多用する展開が難しい部分である場合は、oneDNN と OpenVINO が中心に近づきます。ターゲットが小さい、オフライン、バッテリーに敏感、または埋め込まれている場合、TensorFlow Lite はより自然になります。製品がネイティブ環境でローカルの量子化言語モデルを実行することを明示的に目的としている場合、llama.cpp は早い段階で候補に上がります。

2 番目の質問も同様に重要です。エンジニアリングの負担は実際にどこで支払われるのでしょうか?チームは、ベンチマークの見出しに従ってライブラリを選択した後、本当の悩みは別のところにあることに気づくことがよくあります。エクスポートが不安定だったり、前処理が面倒だったり、展開パッケージが脆かったりする場合には、驚異的なスループット数値を持つランタイムでも不適切な可能性があります。モデル作成者とシステム保守者の間に明確な境界が作成されるのであれば、実行時間が多少遅くても、ビジネス上の選択としては依然として優れている可能性があります。複数の AI 製品を出荷したエンジニアは、この教訓を深く学びます。最適なライブラリを使用すると、午前 2 時にシステム全体を推論しやすくなります。ベンチマークの勝利だけでは決定は決まりません。

ここで反例が健全になります。ネイティブ ドキュメント分析サービスを構築するチームを考えてみましょう。ファッショナブルな選択は、将来性があると思われる、利用可能な最も重いフレームワークに手を伸ばすことかもしれません。しかし、モデルが静的で、前処理パイプラインが簡単で、実際に必要なのは既存の C++ サービス内での安定した推論であり、ONNX Runtime による長期的な影響は少なくなる可能性があります。次に、逆のことを考えてみましょう。チームは、カスタム テンソル フロー、頻繁なアーキテクチャ変更、PyTorch ベースのトレーニング ロジックとの密結合を使用したネイティブ実験を行っています。 「本番環境に対応している」と思われるからといって、すべてを ONNX に強制的に通すと、誰も心から楽しんでいない脆弱なエクスポート中心のワークフローが作成される可能性があります。どの場合でも間違いは同じです。チームはワークロードを選択する前に ID を選択しました。

優れた統合とは実際どのようなものなのか

成熟した統合ワークフローは、ライブラリではなくデータ コントラクトから始まります。ランタイムについて議論する前に、アプリケーションがモデルに何を与えるか、モデルがアプリケーションに何を返すかを決めてください。テンソル形状、dtype、正規化ルール、トークン化パス、パディング動作、バッチ処理の仮定、およびエラー条件に名前を付けます。これはほとんど官僚的に聞こえますが、これは多くの導入成功の静かな源です。ランタイムの境界が曖昧な場合、システムは失敗します。

データ コントラクトが安定すると、エクスポートやモデルのパッケージ化の検証がはるかに簡単になります。チームは、代表的な入力の下で研究パスと生産パスの間の出力を比較し、許容差を測定し、忠実度がドリフトしている場所を検出できます。ここでエンジニアは、エレガントなアーキテクチャが現実に耐えられるかどうかを発見します。エクスポートされたグラフには問題がなく、前処理の不一致だけが問題である場合もあります。ランタイムが完璧であっても、実際の問題はサービス内の他の場所でのスレッドのオーバーサブスクリプションである場合があります。場合によっては、小規模であるはずのモデルが、実際の同時実行によるメモリ負荷に耐えられないことがあります。これらの発見はどれも役に立ちます。システムが見え始めたということです。

その後、ベンチマークとプロファイリングが行われますが、ここでも同じ古いルールが適用されます。つまり、賢いと感じていたおもちゃではなく、出荷する予定のシステムを測定することです。現実的なリクエストの形状、バッチ サイズ、入力の変動性、およびハードウェア条件の下でモデルのベンチマークを実行します。プロファイルの前処理と後処理も同様です。これは、多くのチームが無意識のうちにモデルのコアのみをベンチマークし、顧客がパス全体に対して料金を支払うことを忘れているためです。本番環境 AI では、60 ミリ秒の回避可能な接着剤で囲まれた 10 ミリ秒のグラフは、依然として 70 ミリ秒の機能です。

最後に、展開を再現可能にします。ネイティブ AI は報酬規律を積み重ねます。バージョンを固定し、コンパイラーとランタイムの前提条件を文書化して、どの実行プロバイダーまたは CPU 機能が必要かを決定し、サポートされる構成の狭いセットを維持します。チームメイトが考古学なしで同じ推論パスを別のマシンで再現できない場合、デモがどれほど印象的だったとしても、スタックは準備ができていません。優れた C++ AI エンジニアリングにより、システムが十分に穏やかになり、速度が理解できる状態になります。

繰り返される間違い

最もよくある間違いは、研究の真実と生産の真実を取り違えることです。ノートブックでは優れているように見えるモデルでも、実際の同時実行下でエクスポート、量子化、埋め込み、観察、実行すると扱いにくくなる可能性があります。だからといってモデルが悪かったわけではありません。これは、システムが実験よりも大きかったことを意味します。 2 番目に繰り返される間違いは、前処理と後処理が二の次であるかのように振る舞うことです。実際の製品では、作業の半分で済むことがよくあります。画像のサイズ変更ポリシー、トークナイザーの動作、特徴の正規化、キャリブレーションしきい値、および出力デコードによるすべての形状の正確性と遅延は、コア ランタイムと同様に確実です。

3 番目の間違いは、フレームワークが現代的または包括的であると感じるために、フレームワークに過度にコミットすることです。エンジニアは、決して到来しないニーズを予測して、可能な限り最大のツールを選択することがあります。製品は、使用しない機能に対して料金を支払います。逆の間違いも存在します。純度の名の下に最も軽いランタイムを選択し、その後、動的な動作、カスタム操作、またはフレームワークレベルのセマンティクスが結局はオプションではなかったことが判明するということです。知恵とは、実際に説明できる力に対してのみ料金を支払うことにあります。

さらに微妙な態度の失敗もあります。一部のチームは、ライブラリの選択がエンジニアリングのストーリー全体を解決するかのように扱っています。そうではありません。良い結果は、出力の検証、ホット パスの測定、回避可能なコピーの削除、起動時の負荷の軽減、パッケージの簡素化、実行時の境界の読みやすさの維持など、地味な作業の繰り返しから得られます。オープンソース ライブラリにより、この作業が可能になります。彼らは私たちに代わってそれを実行するわけではありません。

覚えておく価値のある小さな導入ストーリー

Python ビジョン プロトタイプから始まるチームを想像してください。このデモは社内のサポートを獲得するのに十分な強力なものであり、すぐに会話は、イメージの取り込み、ルールの評価、レポートをすでに処理している既存の C++ サービスとの統合に移ります。チームにはいくつかの誘惑があります。 1 つは、短期的には簡単なので、モデルを別の Python サービスの背後に永久に保持することです。もう 1 つは、深刻に聞こえるため、すべてをすぐに重量のあるネイティブ フレームワークに移行することです。 3 つ目は、入力コントラクトさえ安定させる前に、アーキテクチャについて何週間も議論することです。

より成熟した道は静かです。まず、チームは前処理と出力セマンティクスを慎重に定義します。次に、代表的な画像のエクスポートの忠実度をテストします。問題は静的な推論であり、フレームワーク主導の実験ではないため、ONNX Runtime を選択します。その後、より厳しいハードウェア制約を持つエッジ バリアントの場合、TensorFlow Lite またはより積極的に最適化されたランタイム パスがその製品ブランチにとって意味があるかどうかを評価します。数か月後、同社がローカル アシスタント機能を追加した場合、各ツールがシステムの別の隅に位置を獲得したときに、llama.cpp もアーキテクチャに組み込まれる可能性があります。

これが、これらすべてのライブラリの背後にある深い教訓です。本格的な AI エンジニアリングが純粋さに報われることはほとんどありません。それはフィット感を与えます。最高のオープンソース ライブラリとは、最も多くの支持を得ているライブラリではありません。これは、システムの残りの部分に無理を強いることなく、モデルを実際のシステムの一部にできるようにするものです。

ハンズオン ラボ: 小さな ONNX Runtime CLI を構築する

理論は組み立てられると説得力が増します。

C++ で最小の有用なネイティブ推論プログラムを構築しましょう。目標はモデルをトレーニングすることではありません。目標は、ネイティブのランタイム境界がどのようなものかを自分の手で感じることです。

この演習には次のものが必要です。

  • C++17 コンパイラ
  • CMake
  • 公式リリースからの事前構築済み ONNX Runtime パッケージ
  • 入力が平坦な浮動小数点テンソルである任意の小さな .onnx モデル

プロジェクトのレイアウト

tiny-ort/
  CMakeLists.txt
  main.cpp
  third_party/
    onnxruntime/
  model.onnx

CMakeLists.txt

cmake_minimum_required(VERSION 3.16)
project(tiny_ort LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

set(ORT_ROOT "${CMAKE_SOURCE_DIR}/third_party/onnxruntime")

add_executable(tiny_ort main.cpp)
target_include_directories(tiny_ort PRIVATE "${ORT_ROOT}/include")

if (WIN32)
    target_link_directories(tiny_ort PRIVATE "${ORT_ROOT}/lib")
    target_link_libraries(tiny_ort PRIVATE onnxruntime)
else()
    target_link_directories(tiny_ort PRIVATE "${ORT_ROOT}/lib")
    target_link_libraries(tiny_ort PRIVATE onnxruntime)
endif()

main.cpp

#include <onnxruntime_cxx_api.h>

#include <array>
#include <iostream>
#include <numeric>
#include <vector>

int main() {
    Ort::Env env{ORT_LOGGING_LEVEL_WARNING, "tiny-ort"};
    Ort::SessionOptions opts;
    opts.SetIntraOpNumThreads(1);
    opts.SetGraphOptimizationLevel(GraphOptimizationLevel::ORT_ENABLE_EXTENDED);

    const ORTCHAR_T* model_path = ORT_TSTR("model.onnx");
    Ort::Session session{env, model_path, opts};

    std::vector<int64_t> shape{1, 4};
    std::vector<float> input{0.25f, 0.50f, 0.75f, 1.0f};

    auto mem_info = Ort::MemoryInfo::CreateCpu(
        OrtArenaAllocator,
        OrtMemTypeDefault
    );

    Ort::Value tensor = Ort::Value::CreateTensor<float>(
        mem_info,
        input.data(),
        input.size(),
        shape.data(),
        shape.size()
    );

    const char* input_names[] = {"input"};
    const char* output_names[] = {"output"};

    auto outputs = session.Run(
        Ort::RunOptions{nullptr},
        input_names,
        &tensor,
        1,
        output_names,
        1
    );

    float* out = outputs[0].GetTensorMutableData<float>();
    auto out_shape = outputs[0].GetTensorTypeAndShapeInfo().GetShape();
    auto out_count = std::accumulate(
        out_shape.begin(),
        out_shape.end(),
        int64_t{1},
        std::multiplies<int64_t>{}
    );

    std::cout << "Output values:\n";
    for (int64_t i = 0; i < out_count; ++i) {
        std::cout << "  [" << i << "] = " << out[i] << "\n";
    }

    return 0;
}

建てる

Linux または macOS の場合:

cmake -S . -B build
cmake --build build -j
./build/tiny_ort

MSVC を使用した Windows の場合:

cmake -S . -B build
cmake --build build --config Release
.\build\Release\tiny_ort.exe

これが教えてくれること

この小さなプロジェクトでは、すでに次のようないくつかの生産上の現実に直面する必要があります。

  • ランタイムが存在する場所
  • ネイティブ依存関係がどのようにパッケージ化されるか
  • テンソルの名前と形状は実際には何ですか
  • ネイティブ推論境界での明示的なメモリ処理がどのように感じられるか

まさにそれがポイントです。ライブラリはマーケティング用語ではなくなり、エンジニアリング上の選択肢になります。

愛好家向けのテストタスク

この記事を週末のラボにしたい場合は、次のステップが役立ちます。

  1. ハードコードされた入力ベクトルを、小さなテキスト ファイルまたはバイナリ ファイルからロードされた値に置き換えます。
  2. 入力および出力のテンソル形状を想定するのではなく、動的に出力します。
  3. session.Run の周囲に単純なレイテンシー測定を追加し、1、2、および 4 の演算内スレッドを比較します。
  4. 同様のおもちゃ推論アプリで ONNX Runtime と LibTorch を交換し、何が簡単になったのか、何が重くなったのかを書き留めます。
  5. Python から小さなモデルをエクスポートし、それをこの C++ プログラムにロードし、前処理の違いによって結果が暗黙的に変更されないことを確認します。

これら 5 つのタスクを正直に実行すれば、フレームワーク名を 1 時間暗唱できる多くの人よりも AI デプロイメントについて理解できるようになります。

まとめ

C++ のオープンソース ニューラル ネットワーク ライブラリは、1 つのパレードで行進するわけではありません。これらはさまざまなエンジニアリングのニーズから生まれたものであり、その起源を尊重する場合に最も有用であり続けます。 ONNX Runtime は、問題を絞り込み、運用チームに安定した推論境界を与えるため、強力です。 LibTorch は、ネイティブ アプリケーションがモデル パス全体でテンソルとモジュールの所有権を本当に必要とする場合に役立ちます。 oneDNN と OpenVINO は、低レベルの効率性と特定のハードウェア ファミリへの展開が二次的な問題ではなくなるときに重要になります。 TensorFlow Lite は、デバイス自体がハード制約である場合に輝きます。 llama.cpp が重要なのは、注意深くネイティブ エンジニアリングを行うことで、最新の言語モデルを遠隔サービスではなく実用的なローカル コンポーネントに変えることができることが非常に公に証明されたからです。

したがって、最良の選択が最もファッショナブルなものであることはめったにありません。システム全体を穏やかにするものです。優れたランタイムとは、神話にとらわれずにチームが理解し、ベンチマーク、プロファイル、パッケージ化、テスト、運用できるランタイムのことです。エンジニアがそこから選択すると、オープンソース AI は、フレームワークのわかりにくい動物園のように見えるのをやめ、本当の姿、つまり本格的なネイティブ製品をサポートするのに十分な豊富なツールボックスのように見え始めます。

参考文献

  1. ONNX Runtime C/C++ API: ONNX Runtime
  2. ONNX 公式プロジェクト: https://onnx.ai/
  3. PyTorch C++ フロントエンド ドキュメント: PyTorch
  4. oneDNN 公式ドキュメント: oneDNN
  5. OpenVINO ドキュメント: OpenVINO
  6. LiteRT / TensorFlow Lite C++ API ドキュメント: TensorFlow Lite
  7. llama.cpp リポジトリ: llama.cpp
  8. ONNX Runtime GitHub リポジトリ: ONNX Runtime
  9. PyTorch リポジトリ: PyTorch

    システムにすでに圧力がかかっている場合はどのように見えるか

C++ ai ランタイムの選択は、チームが静かな四半期を望んでいたまさにその瞬間に緊急になる傾向があります。機能がすでに顧客の前に提供されているか、プラットフォームがすでに内部依存性を持っており、システムはその洗練された理論と実行時の動作が丁寧に別々の生活を送っていることを明らかにするために、その特定の週を選択しました。これが、多くの本格的なエンジニアリング作業が和解から始まる理由です。チームは、システムが行うと信じていることと、負荷や変更が加えられた状態、そして誰もが少し創造的になり、賢さが少し低下するような期限の下でシステムが実際に行うことを調和させる必要があります。

ネイティブ AI デプロイメントで最も重要なケースは、通常、ポータブル サーバー推論、制約のあるハードウェアでのエッジ デプロイメント、および既存のネイティブ製品内へのモデルの埋め込みです。このような状況は、技術的、予算、信頼、ロードマップ、そして場合によっては評判にも影響を及ぼします。技術的な問題は、複数のチームがそれに依存した瞬間に政治的に大きくなり、なぜそれが未だに壁の中でアライグマのように行動するのか誰も完全に説明できません。夜はうるさく、場所を特定するのは難しく、無視すると費用がかかります。

そのため、動作圧力と配送の現実というレンズを通して問題を読むことをお勧めします。設計は理論的には美しくても、運用的には破滅的なものになる可能性があります。別の設計は、ほとんど退屈なものであっても、測定可能で修理可能であり、トレードオフについて誠実であるため、製品を何年も使い続けることができます。真剣なエンジニアは、2 番目のカテゴリーを好むようになります。これにより、壮大なスピーチが減りますが、誰もが受動態で話し、誰が近道を承認したかを誰も覚えていないような緊急の振り返りも減ります。

常に老化を続ける習慣

最初の永続的な方法は、1 つの代表的なパスを常に測定し続けることです。チームは多くの場合、曖昧なテレメトリを収集しすぎたり、意思決定品質のシグナルが少なすぎたりします。本当に重要な道を選び、それを繰り返し測定し、議論が装飾的なストーリーテリングに流れないようにしてください。 C++ AI ランタイムの選択を回避する場合、通常は、ランタイムの適合性、統合の摩擦、パッケージングのコスト、定常状態のレイテンシーが有用な対策となります。それらが可視化されると、残りの決定はより人間的になり、神秘的ではなくなります。

2 番目の永続的な習慣は、証拠と約束を分離することです。エンジニアは、システムがその結論を得る前に、ある方向性が正しいと言うよう圧力をかけられることがよくあります。そのプレッシャーに抵抗してください。特にトピックが顧客やお金に近い場合は、最初に狭い証明を作成します。検証されていない大きな野心よりも、検証された小さな改善の方が商業的価値があります。これは、四半期末のレビューで仮説が期限に変わり、組織全体が楽観主義をスケジュール作成の成果物のように扱うようになるまでは、当然のことのように思えます。

3 番目の永続的な習慣は、所有者の言語で推奨事項を書くことです。 「パフォーマンスを向上させる」または「境界を強化する」という文章は、感情的には心地よいものですが、運用上は役に立ちません。月曜日の朝に実際に生き残るのは、誰が何を、どの順序で、どのロールバック条件で変更するかを述べた段落です。多くのテクニカル ライティングが失敗するのはここです。スケジュール可能であることよりも、先進的に聞こえることを望んでいます。

時間を節約する反例

最も一般的な反例の 1 つは次のようなものです。チームはローカルで大きな成功を収め、システムが理解されたと想定し、測定規律をアップグレードすることなく、アイデアをさらに要求の厳しい環境に拡張します。これは工学的に言えば、ホテルのプールで泳ぎ方を覚えてから、海の天気について自信を持って TED トークをするのと同じことです。水ではなくなるまでは水です。

もう 1 つの反例は、ツールのインフレです。新しいプロファイラー、新しいランタイム、新しいダッシュボード、新しいエージェント、新しい自動化レイヤー、古いラッパーとの調和を約束する新しいラッパー。これらはどれも本質的に悪いことではありません。問題は、誰も明確に名指ししていない境界線の補償を求められたときに何が起こるかということだ。その後、システムはさらに装備され、より印象的になり、場合によってはより理解できるようになります。購入者はこれをすぐに感じます。そのような表現がなくても、積み重ねが決断の代償として高価なものになったことを彼らは嗅ぎ分けることができます。

3 番目の反例は、人間によるレビューを自動化の失敗として扱うことです。実際のシステムでは、多くの場合、人間によるレビューが自動化を商業的に受け入れられる状態に保つための制御となります。成熟したチームは、どこを積極的に自動化するか、どこで承認や解釈を可視化するかを知っています。未熟なチームは、スライド内で「すべて」が効率的に聞こえるため、マシンにすべてを実行させたいと考えます。その後、最初の重大なインシデントが発生し、突然手動レビューが変換体験の誠実さによって再発見されます。

弊社が推奨する配信パターン

仕事が順調に進んでいる場合、最初の成果物は、チームに輪廻議論をやめるのに十分な技術的な読み取りを提供することでストレスを軽減するはずです。その後、次の制限付き実装で 1 つの重要なパスが改善され、再テストによってエンジニアリングとリーダーの両方が方向性を理解できるようになります。その順序は、正確なツールの選択よりも重要です。それは、技術スキルを前進に変えるものだからです。

実際的な観点から言えば、最初のサイクルは狭いことをお勧めします。つまり、アーティファクトを収集し、1 つの厳密な診断を作成し、1 つの限定された変更を出荷し、実際のパスを再テストし、次の決定を平易な言葉で書くというものです。分かりやすい言葉が重要です。買い手が明確さを後悔することはほとんどありません。購入者は、領収書が届く前に感動したことを後悔することがよくあります。

ここでもトーンが重要になります。強力な技術的な作業は、以前にプロダクションに対応したように聞こえるはずです。穏やかで、正確で、誇大宣伝に養われるというよりは、それを少し楽しんでいます。そのトーンは操作信号を伝えます。これは、チームがシステム エンジニアリングの古い真実を理解していることを示しています。マシンは高速であり、ロードマップは脆弱であり、詩的であり続けることを許可されていたすべての仮定に対して、遅かれ早かれ法案が到着します。

これが準備完了であると判断する前に使用するチェックリスト

ネイティブ AI デプロイメントでは、準備は気分ではありません。それは結果を伴うチェックリストです。 C++ AI ランタイムの選択を回避し、より広範なロールアウトに備える前に、可能な限り最善の方法でいくつかのことを退屈なものにしておきたいと考えています。代表的な負荷の下で予測どおりに動作する 1 つのパスが必要です。矛盾しない 1 セットの測定値が必要です。私たちはチームに、境界線がどこにあるのか、そしてそれを壊すことが何を意味するのかを知ってもらいたいと考えています。そして、実装室の外にいる誰かがそこから正しい判断を下せるように、作業の出力が十分に明確であることを望んでいます。

そのチェックリストは通常​​、実行時の適合性、統合の摩擦、パッケージングのコスト、定常状態のレイテンシに関係します。数値が正しい方向に進んでいるにもかかわらず、チームが即興でシステムを説明できない場合、作業の準備ができていません。建築が印象的に聞こえても、現場からのささやかな反例に耐えられない場合、その作品はまだ準備ができていません。実装は存在するが、ロールバックの話がタイムスタンプ付きの祈りのように聞こえる場合は、作業の準備ができていません。これらはいずれも哲学的な反論ではありません。それらは単に、高価なサプライズが登場する傾向にある形式にすぎません。

これは、チームが実際の問題を解決しているのか、それともその問題に近い能力を単に練習しているだけなのかを発見する場所でもあります。非常に多くの技術的取り組みは、誰かが再現性、生産の証拠、または予算に影響を与える決定を要求するまでは、成功したように感じられます。その瞬間、弱い作品はぼやけてしまい、強い作品は妙に地味になってしまいます。プレーンが良いです。プレーンとは通常、システムがカリスマ性に依存するのをやめたことを意味します。

結果について話すことを推奨する方法

最終的な説明は、リーダーシップ会議に耐えられるほど簡潔であり、エンジニアリングレビューに耐えられるほど具体的である必要があります。それは思っているよりも難しいことです。過度に専門的な言葉は順序を隠します。過度に単純化された言葉はリスクを隠します。適切な中間点は、勝ち誇ったような感じではなく、穏やかに聞こえる方法で、道筋、証拠、限界のある変化、そして次に推奨されるステップを説明することです。

このような構造を推奨します。まず、どのパスが評価されたのか、そしてそれがなぜ重要なのかを述べます。次に、その道に関して何が間違っていたのか、何が不確実だったかを述べます。 3 番目に、何が変更、測定、または検証されたかを述べます。 4番目に、何が未解決のままなのか、そして次の投資で何が買えるのかを述べます。この構造が機能するのは、エンジニアリングと購買行動の両方を尊重しているからです。エンジニアは詳細を求めています。購入者は順序付けを望んでいます。サプライズを楽しんでいるふりをしている人も含めて、誰もがサプライズを減らしたいと思っています。

このように話すことの隠れた利点は文化的なものです。技術的な作業を明確に説明するチームは、通常、それをより明確に実行します。彼らは曖昧さを洗練されたものとして扱うのをやめます。専門用語では印象を与えることが難しくなり、難しいシステムでは信頼されやすくなります。これは、エンジニアリングの成熟度の最も過小評価されている形態の 1 つです。

私たちがまだ偽造を拒否したいもの

システムが改善された後でも、成熟したチームはネイティブ AI 導入において不確実性を正直に保ちます。弱い測定にはより明確な証拠が必要であり、厳しい境界には平易な言葉が必要で、より穏やかなデモには実際の運用準備が必要です。ある程度の不確実性は軽減する必要があります。正直に名前を付けなければならない人もいます。この 2 つの仕事を混同すると、立派なプロジェクトが高価なたとえになってしまいます。

同じルールが C++ AI ランタイムの選択に関する決定にも適用されます。チームに再現可能なベンチマーク、信頼できるロールバック パス、または重要なインターフェイスの明確な所有者が依然として不足している場合、最も役立つ出力は、より大きな約束ではなく、より明確なノーまたはより狭い次のステップである可能性があります。この規律により、技術的な作業が改善を目的とした現実と一致した状態に保たれます。

このように作業すると、不思議な安心感があります。システムが楽観的なストーリーテリングに依存しなくなると、たとえ作業が困難なままであっても、エンジニアリングに関する会話はよりシンプルになります。そして生産現場では、それは多くの場合、ささやかな恵みとして数えられます。

実際の技術レビューからのフィールドノート

C++ システムの配信では、デモが実際の配信、実際のユーザー、実際の運用コストを満たしたときに、作業が本格化します。それは、きちんとしたアイデアがシステムのように動作し始める瞬間であり、システムは有名なドライなユーモアのセンスを持っています。彼らはキックオフデッキがどれほどエレガントに見えるかなど気にしません。彼らは、境界、障害モード、ロールアウト パス、そしてスタックに関する新しい神話をでっち上げずに次のステップを説明できる人がいるかどうかを重視しています。

Using Open-Source Libraries for Neural Networks in C++ の場合、実際的な問題は、ロードマップ、プラットフォーム、またはセキュリティ レビューにすでにプレッシャーを感じている購入者に対して、より強力な配信パスを作成できるかどうかです。その購入者は、霧の中に磨き上げられた講義を必要としません。彼らは使用できる技術的な読み取りを必要としています。

最初に検査するもの

まず、ネイティブ推論、プロファイリング、HFT パス、DEX システム、および C++/Rust モダナイゼーションの選択肢という 1 つの代表的なパスから始めます。その道は測定するには十分に狭く、真実を明らかにするには十分に広くなければなりません。最初のパスでは、割り当て動作、p99 レイテンシ、プロファイル証拠、ABI 摩擦、および信頼性の解放をキャプチャする必要があります。これらの信号が利用できない場合、プロジェクトは依然として白衣を着た意見がほとんどであり、意見はそれ自体を戦略として宣伝してきた長い歴史があります。

最初の有用な成果物は、ベンチマーク、プロファイリング証拠、および範囲を絞った実装計画を含むネイティブ システムの読み取りです。計画会議で誰もが期待したとおりに動作するのではなく、システムが動作するとおりに示す必要があります。トレース、リプレイ、小さなベンチマーク、ポリシー マトリックス、パーサー フィクスチャ、または反復可能なテストは、多くの場合、別の抽象的なアーキテクチャの議論よりも早くストーリーを伝えます。良い工芸品は驚くほど失礼だ。彼らは希望的観測を中断します。

時間を節約する反例

高くつく間違いは、最初の有用な証明よりも大きな解決策で応答することです。チームはリスクや遅延を認識すると、すぐに新しいプラットフォーム、書き換え、全面的なリファクタリング、またはヨガをしているような名前の調達しやすいダッシュボードに手を出します。場合によっては、そのスケールが正当化されることもあります。多くの場合、これは測定を延期する方法です。

より良い動きはより小さく、より鋭いです。境界に名前を付けます。証拠を捕らえます。重要なことを 1 つ変更します。同じパスを再テストします。次に、次の投資がより大きな投資に値するかどうかを決定します。このリズムは変革プログラムほど劇的ではありませんが、予算、リリース カレンダー、および制作上のインシデントに影響されても存続する傾向があります。

弊社が推奨する配送パターン

最も信頼性の高いパターンには 4 つのステップがあります。まず、代表的な成果物を収集します。次に、これらのアーティファクトを 1 つの難しい技術診断に変換します。 3 番目に、1 つの限定された変更またはプロトタイプを出荷します。 4 番目に、同じ測定フレームで再テストし、次の決定をわかりやすい言葉で文書化します。このクラスの作業では、CMake フィクスチャ、プロファイリング ハーネス、小さなネイティブ再現、およびコンパイラ/ランタイム ノートの方が、一般的な方向性に関する別の会議よりも価値があるのが通常です。

分かりやすい言葉が重要です。購入者は出力を読んで、何が変化したのか、何が依然としてリスクが残っているのか、何を待てばよいのか、次のステップで何を購入するのかを理解できる必要があります。推奨事項をスケジュールしたり、テストしたり、所有者に割り当てることができない場合でも、それは装飾的すぎます。装飾的なテクニカルライティングは楽しいものですが、制作システムがその心地よさをもたらすとは知られていません。

結果が役に立ったかどうかを判断する方法

Open-Source Neural Network Libraries in C++: ONNX Runtime, LibTorch, oneDNN, OpenVINO, TFLite, llama.cpp の場合、結果により配信速度、システムの信頼性、商用化の準備の 3 つのうち少なくとも 1 つが改善されるはずです。これらのどれも改善されない場合、チームは何かを学んだ可能性がありますが、購入者はまだ有用な結果を受け取っていません。その区別が重要です。学ぶことは崇高なことです。有料のエンゲージメントもシステムを動かすはずです。

最も強力な成果は、より狭いロードマップ、危険なパスの自動化の拒否、モデルの境界の改善、よりクリーンなネイティブ統合、書き換えがまだ必要ではないという慎重な証拠、またはリーダーが実際に資金を提供できる短い修復リストなどです。真剣なエンジニアリングとは、より良い意思決定の連続であり、ツールの仮装コンテストではありません。

SToFU はそれにどうアプローチするか

SToFU は、これを最初に配信の問題として扱い、次にテクノロジーの問題として扱います。私たちは関連するエンジニアリングの深さをもたらしますが、その取り組みは、経路、境界、リスク、測定、そして行う価値のある次の変更などの証拠に基づいて行われます。重要なのは、ハードワークを簡単に思わせないことです。重要なのは、次の重大な行動を実行できるほど明確にすることです。

それは、購入者が通常最も重視する部分です。彼らはどこでも意見を採用できます。彼らに必要なのは、システムを検査し、実際の制約に名前を付け、適切なスライスを構築または検証し、通話終了後の混乱を軽減する成果物を残すことができるチームです。騒がしい市場では、明確さはソフトスキルではありません。それはインフラです。

Philip P.

Philip P. – CTO

関連記事

C++、Rust、および Windows Kernel: 安全性が役立ち、境界が依然として厳しい場所

C++、Rust、および Windows Kernel: 安全性が役立ち、境界が依然として厳しい場所

Rust が Windows の低レベル作業に役立つ場所、C++ が依然としてデフォルトのままである場所、および実際の設計上の問題が境界となる理由についての実用的な内容です。

C++、Rust、および高頻度取引: 決定論的なレイテンシーが議論を決定する場合

C++、Rust、および高頻度取引: 決定論的なレイテンシーが議論を決定する場合

C++ が依然としてホットな HFT パスを所有している場所、Rust が真に役立つ場所、そして規律あるチームがそれらの間の境界線をどのように引くかについての実践的な記事。

システムの最新化における C++ と Rust : 書き直すか、ラップするか、それとも放置するか?

システムの最新化における C++ と Rust : 書き直すか、ラップするか、それとも放置するか?

システムの動作について C++ と Rust を比較するモダナイゼーション ガイド。書き換え範囲、FFI 戦略、リスク、実際の移行の経済性に重点を置いています。

ブログに戻る

接触

会話を始める

明確な線が数本あれば十分です。システム、プレッシャー、妨げられている意思決定について説明してください。 または直接書いてください midgard@stofu.io.

0 / 10000
ファイルが選択されていません

代わりに電話をご希望ですか?