新しいプロジェクトは、ディープニューラルネットワークをサービス提供するための、モダリティの選択肢の1つを提供するものである。組み込みのCPythonインタープリタを使うことで、本番処理でeagerモード（別名define-by-run）モデルコードを直接利用できる。目標は、モデルを研究段階からエンドユーザに提供するまでのエンジニアリングの労力を削減し、将来の数値Pythonライブラリを移行するための概念実証（PoC）プラットフォームを作成することである。初期のライブラリは、PyTorch C++ API（バージョン1.11）のプロトタイプ機能（torch::deploy）としても利用できる。
API推論のディープネットワークをデプロイするための2つの一般的な方法は、モデルコードをREST/RPCサーバを使って直接コンテナ化（例えば、Python、CUDA、ROCmベースイメージを使う）することと、静的モデルグラフを構築（例えば、TensorflowグラフモードやTorchscriptを使う）することである。コンテナ化することで、モデルを開発から本番に移行するときにアジリティが得られる。一方、グラフモード（別名define-and-run）を使うと、より大規模なサービスインフラストラクチャ内での最適なデプロイができるようになる。どちらの方法にも、必要なエンジニアリングコスト、API遅延、リソースの制約（使用可能なGPUメモリなど）を考慮したトレードオフがある。
アプリケーション分野と企業のインフラストラクチャ要件に応じて、ディープネットワークのデプロイ方法を指定されたニーズに合わせてカスタマイズできる（たとえば、グラフモードを適用したり、コンパイルされたモデルからコンテナを作成したりできる）。しかし、ディープネットワークが急速に進化する性質を持つため、プロジェクトの成功のために迅速な実験ができることが重要となる比較的自由度の高い開発環境が必要とされる。したがって、そのようなモデルを本番環境に導入するための開発コストの削減余地には限界がある。文書で提起されている問題は、パフォーマンスを大きく犠牲にすることなく、C++エコシステム内でeagerモードサービスを有効にすることで、機械学習エンジニアリングの労力を最小限に抑えることができるかということである。
この質問に対する著者の答えはそれほど驚くべきことではない。入力されるリクエストがC++アプリケーション内にパッケージ化された（複数の）CPythonワーカーに渡された場合はどうなるか。プロキシを介した負荷分散により、モデルを直接使うことができ、その際、追加のエンジニアリング作業はない。このようなシナリオにより、機械学習エンジニアが必要なCPythonインタープリタを利用できるため、モデルの開発時に外部ライブラリ（Numpy、Pillowなど）の使用を継続することもできる（これは現在のプロトタイプではまだサポートされていない）。このアプローチでは、複数の分離されたインタープリタを使ってPythonのGILを回避するため、ベースPythonイメージを使ったコンテナー化に似ているように見える。しかし、新しい方法ではC++での実行も可能である（つまり、このアイデアは、前述の2つの一般的な方法を独自の方法で組み合わせている）。
Pythonでのパッケージ化の例を以下に示す。
from torch.package import PackageExporter
import torchvision
model = torchvision.models.resnet.resnet18()
with PackageExporter("my_package.pt") as e:
e.intern("torchvision.**")
e.extern("sys")
e.save_pickle("model", "model.pkl", model)
モデルアーティファクトを保存した後、推論のためにC++ APIで使うことができる。
#include <torch/deploy.h>
#include <torch/script.h>
int n_workers{4};
torch::deploy::InterpreterManager manager(n_workers);
torch::deploy::Package package = manager.loadPackage("path_to_package");
torch::deploy::ReplicatedObj model = package.loadPickle("model", "model.pkl");
レポートで実施されたベンチマークでは、このようなCPythonパッケージングが、特に大規模なモデルの提供に適していることを示されている。それはまだ進行中の作業であるため、プロジェクトにはいくつかの欠点がある。たとえば、外部ライブラリのサポートは、Python標準ライブラリとPyTorchのみに限定されている。また、共有インタプリタライブラリをコピーして各インタプリタにロードする必要があるため、ワーカーのサイズと数がスケーラビリティの因子になる可能性がある。将来的には、コントリビュータはPip/Conda環境ライブラリから直接依存関係をパッケージ化することを計画しているため、本番環境へのデプロイがさらに容易になる。