ONNX Runtime 1.29.0 sbírá data i na Linuxu, macOS, Androidu a iOS

ONNX Runtime je knihovna Microsoftu, která spouští hotové modely ve formátu ONNX – na procesoru, na grafické kartě i na akcelerátorech v telefonu. Sama o sobě vidět není: sedí pod aplikacemi, které si model do ONNX převedou a pak ho potřebují někde spustit. Vydání 1.29.0 z 12. srpna 2026 do ní přidalo sběr telemetrie pro Linux, macOS, Android a iOS. Do té doby ho měla jen na Windows.

V oficiálních balíčcích je sběr zapnutý

Dokument Privacy.md ve značce v1.29.0 to říká rovnou: telemetrie je v oficiálních sestaveních zapnutá ve výchozím stavu. Na Windows k tomu slouží systémové ETW, na ostatních platformách knihovna 1DS a odesílá se přes HTTPS. Bez telemetrie zůstávají cíle, pro které knihovna žádný odesílač nemá – WebAssembly, tvOS, visionOS, Mac Catalyst, AIX a RISC-V.

Na Linuxu navíc rozhoduje seznam architektur. Funkce target_supports_telemetry v souboru build_args.py jich vyjmenovává jedenáct, od aarch64 a armv6l po x86_64; co v seznamu není, telemetrii nedostane.

Událost o vytvoření relace nese i jméno souboru modelu

Co přesně se posílá, stojí ve zdrojovém souboru telemetry.cc. Jednorázová událost ProcessInfo obsahuje verzi knihovny, popis systému, architekturu, model procesoru, třídu zařízení, počet jader a velikost paměti v megabajtech.

Bohatší je událost SessionCreation, tedy otevření relace nad konkrétním modelem. Nese verzi formátu, jméno a verzi nástroje, který model vytvořil, doménu modelu, jméno souboru, jméno grafu, typ vah, otisk grafu, otisk vah, metadata modelu, seznam použitých execution providerů, typy a výrobce hardwaru a příznak, jestli se počítá v šestnáctibitových číslech.

Jméno souboru je opravdu jen jméno, ne cesta: inference_session.cc volá nad cestou k modelu filename(), takže adresář zůstává doma. Volné textové položky, například chybové hlášky a cesty ke knihovnám, procházejí funkcí ScrubStringForTelemetry; jméno souboru, jméno grafu ani metadata modelu se nezačišťují.

Vzorkování je podle popisu návrhu nastavené na 100 %, takže se neposílá zlomek relací, ale všechny. Na stolních systémech se odesílá solený otisk místně vytvořeného identifikátoru a samotné UUID podle téhož popisu ven nejde; Android a iOS používají identitu, kterou dodá 1DS.

Vypnout to jde třemi způsoby a každý sahá jinam daleko

• Při stavbě. Přepínač --no_telemetry pro build.py nebo build.sh. Odesílač se do knihovny vůbec nedostane.
• Za běhu, mimo Windows. Proměnná prostředí ORT_DISABLE_TELEMETRY=1 nastavená dřív, než se ONNX Runtime inicializuje. Pak nevznikne odesílač, události ani trvalý identifikátor zařízení a rozhodnutí platí po celý život procesu.
• Přes rozhraní. C API a jeho vazby v C#, Pythonu a Javě umí potlačit nepodstatné události. Úvodní událost už ale může být pryč – komentář přímo v telemetry.cc říká, že tohle potlačení nechá odesílač naživu, takže ProcessInfo odejde tak jako tak.

Co je vidět v knihovně z oficiálního archivu

Zkusili jsme to změřit na tom, co si člověk stáhne. V archivu onnxruntime-linux-x64-1.29.0.tgz z příloh vydání má soubor libonnxruntime.so 28 497 752 bajtů a jsou v něm řetězce ORT_DISABLE_TELEMETRY, popSample, ProcessInfo, RuntimePerf a třikrát adresa sběrného serveru https://mobile.events.data.microsoft.com/OneCollector/1.0. V témž archivu pro verzi 1.28.0 má táž knihovna 24 268 848 bajtů a ani jeden z těch řetězců v ní není.

Rozdíl 4,2 MB nepatří celý telemetrii – vydání přineslo i řadu jiných změn a z hotového souboru se podíl jedné knihovny oddělit nedá. A přítomnost řetězce neříká, co se v konkrétním běhu opravdu odešle; říká jen, že kód pro odeslání v dodaném souboru je.

Odesílání muselo pryč z horké cesty

Popis návrhu #27379 uvádí i měření, kvůli kterému se podoba sběru měnila. Původní verze posílala událost synchronně po každém průchodu modelem: v jednom vlákně stál běh 100,4 mikrosekundy se zapnutou telemetrií proti 3,5 mikrosekundy s vypnutou, na osmi vláknech to bylo 11 300 běhů za sekundu proti 306 500, tedy ztráta 96,3 %. Po přesunu odesílání mimo horkou cestu vyšlo 294 300 proti 295 500 běhům za sekundu, což je rozdíl 0,4 %. Měřilo se na modelu mul_1.onnx s odstavenou sítí, měření je součástí návrhu, ne cizí ověření.

Popis návrhu a vydaný kód se u přepínače rozcházejí

V popisu návrhu stojí, že se telemetrie kompiluje jen tehdy, když se stavba nastaví přepínačem --use_telemetry. Ve vydaném kódu 1.29.0 žádný takový přepínač není: build_args.py zná jen --no_telemetry a jeho vlastní nápověda říká, že telemetrie je pro podporované nativní stavby zapnutá ve výchozím stavu. Totéž píše Privacy.md a dodává, že windowsová obálka build.bat předává --no_telemetry sama. Kdo si tedy knihovnu postaví na Windows obvyklým způsobem, sběr nemá; kdo ji postaví na Linuxu přes build.sh, ho ve výchozím stavu má.

Kdo staví přímo přes CMake bez build.py, je na tom ještě jinak: volba onnxruntime_USE_TELEMETRY je v CMakeLists.txt nastavená na OFF a build.py ji pokaždé přebíjí výslovnou hodnotou.

Koho se to týká hned

Nejnovější onnxruntime na PyPI je při psaní tohohle textu pořád 1.28.0 z 25. července 2026, takže pip install onnxruntime zatím nic z toho nepřinese. Týká se to lidí, kteří sáhnou po hotových archivech z příloh vydání, a všech, kdo si knihovnu staví sami na jiné platformě než Windows.

Identifikátor stroje jako klíč k telemetrii přitom v nástrojích kolem modelů nic nového není – rozšíření Cline podle něj rozhoduje, které ze dvou balíčků v instalaci spustí.

Zdroje

• Poznámky k vydání ONNX Runtime 1.29.0, 12. srpna 2026
• Návrh #27379 Add POSIX telemetry, sloučený 24. července 2026
• docs/Privacy.md ve značce v1.29.0
• tools/ci_build/build_args.py a core/platform/posix/telemetry.cc v téže značce
• Archivy onnxruntime-linux-x64-1.29.0.tgz a onnxruntime-linux-x64-1.28.0.tgz, na kterých se měřilo; visí v přílohách vydání 1.28.0 a 1.29.0