dimhold.by
← Артыкулы

earshot абяцаў нуль сеткавых выклікаў, а onnxruntime парушыў гэта ў дзень адкрыцця рэпазіторыя

earshot, мой лакальны транскрыбатар, мае ўверсе README зялёны значок “Network calls: none”. Ніжэй у README напісана “No account, no key, no telemetry” і “After that you can run earshot with the network off”. Тэкст --help заканчваецца фразай “Nothing leaves the machine. There is no network call anywhere in the pipeline.” Мадэль base.en з faster-whisper, 145 МБ, спампоўваецца адзін раз.

Усё гэта я напісаў па задуме. Ніхто гэтага не вымяраў, у тым ліку я. Код транскрыбацыі ўзяты з прыватнага праекта, які я пісаў у канцы мая і пачатку чэрвеня. У сярэдзіне жніўня я скараціў яго да earshot і напісаў README. На гэтым тыдні я ўсталяваў earshot з нуля ў пустую папку, так, як README раіць рабіць гэта чужому чалавеку. Потым сачыў за яго сокетамі.

Стэнд

Ubuntu 24.04 на віртуалцы з 4 ядрамі, Python 3.12.3, Node 22, ffmpeg 6.1.1, earshot на каміце 15da817. requirements.txt жорстка фіксуе толькі faster-whisper==1.1.0, астатняе выбірае pip. 11 кастрычніка 2026 года ён выбраў huggingface_hub 2.2.0 і onnxruntime 1.31.0.

Каб сачыць за сеткай, я запускаў усё дрэва працэсаў, Node, ffmpeg і сайдкар на Python, пад strace -f -e trace=connect. Каб выключыць сетку, машыну я не чапаў. strace можа прымусіць кожны connect() працэсаў, за якімі ён сочыць, завяршацца памылкай ENETUNREACH. Гэтую памылку атрымліваеш, калі да сеткі няма маршруту. Гукам былі 10 запісаў гарвардскіх сказаў з Open Speech Repository, усяго 342 секунды, я падаваў іх праз earshot --source file.

Без сеткі ён працуе

Усе 10 запісаў расшыфраваліся з адрэзанай сеткай. Тэкст супаў з тэкстам прагону пры ўключанай сетцы, 10 з 10. Доля памылковых слоў у параўнанні з апублікаванымі сказамі склала 13,1%, у асноўным таму, што запісы тэлефоннай якасці, 8 кГц. “The birch canoe slid” ператварылася ў “The birch can use lid”. Запуск займаў 1,6 секунды без сеткі і 1,9 з сеткай, без ніводнага папярэджання ў логу.

Лічба 145 МБ дакладная толькі для аднаго файла. model.bin важыць 145 216 508 байтаў, папка мадэлі 148 МБ. Віртуальнае асяроддзе Python, у якім яна працуе, важыць 472 МБ. 132 МБ з іх гэта PyAV са сваімі бібліятэкамі ffmpeg. Для дэкадавання earshot іх не выкарыстоўвае, ён запускае сістэмны ffmpeg і аддае сайдкару сырыя сэмплы. З npm install выходзіць 658 МБ на дыску.

earshot на дыску пасля ўсталёўкі па README, МБ model.bin (base.en) 145 астатняе ў папцы мадэлі 3 CTranslate2 141 PyAV з бібліятэкамі ffmpeg 132 onnxruntime 69 numpy 68 іншыя пакеты Python 62 node_modules (зборка) 38 разам каля 658 МБ, лічба з README гэта першы слупок
Замер du у свежым клоне 11 кастрычніка 2026 года, пасля pip install -r python/requirements.txt, npm install і спампоўкі мадэлі. Мегабайты дзесятковыя.

З сеткай ён пытаецца ў Hugging Face пры кожным запуску

Кожны запуск сайдкара адкрываў злучэнне TLS з huggingface.co. Лог запытаў паказвае 1 запыт:

GET https://huggingface.co/api/models/Systran/faster-whisper-base.en/revision/main

faster-whisper пытаецца ў Hub, ці няма ў мадэлі новай рэвізіі, перш чым адкрыць файлы з кэша. Нічога з майго гуку туды не трапляе, але Hugging Face бачыць мой IP-адрас і назву мадэлі пры кожным запуску earshot. Зменная HF_HUB_OFFLINE=1 гэта спыняе. З гэтай зменнай сайдкар зрабіў 0 злучэнняў з Hugging Face.

Пры дрэннай сетцы яшчэ горш. Я накіраваў Hub на адрас, які адкідае пакеты. Сайдкар быў гатовы праз 135 секунд замест 1,6. Столькі Linux чакае, перш чым адмовіцца ад спробы ўсталяваць злучэнне TCP. Потым я падставіў проксі, які прымае злучэнне і нічога не адказвае, як мёртвая старонка ўваходу ў гасцінічным вайфаі. Праз 900 секунд сайдкар усё яшчэ загружаўся і я яго забіў. Кліент HTTP у huggingface_hub 2.2.0 ствараецца з timeout=None.

Другі сервер гэта Microsoft

Дрэва працэсаў злучалася яшчэ і з mobile.events.data.microsoft.com. Злучэнне ішло з патоку сайдкара. Адрас ушыты ў скампіляванае пашырэнне onnxruntime для Python.

faster-whisper выкарыстоўвае onnxruntime для адной справы: фільтра галасавой актыўнасці Silero. Сайдкар earshot уключае гэты фільтр па змаўчанні, хоць у самым сайдкары ўжо ёсць опцыя --no-vad, у даведцы да якой напісана “earshot already segments”. Node рэжа гук на выказванні да таго, як яго ўбачыць Python, так што фільтр паўтарае нарэзку, якую Node ужо зрабіў.

onnxruntime шле тэлеметрыю на Linux з версіі 1.29.0. Я праглядзеў пакеты wheel: у 1.28.0 і больш ранніх адраса калектара няма, у 1.29.0, 1.30.0 і 1.31.0 ён ёсць. Усталёўка earshot з 1.28.0 зрабіла 0 злучэнняў з Microsoft. Калі я пісаў README у сярэдзіне жніўня, pip усталёўваў 1.28.0, так што значок быў праўдай. Рэпазіторый я адкрыў 17 жніўня. 1.29.0 з’явіўся на PyPI позна ўвечары таго ж дня па UTC. У маім кодзе і ў requirements.txt не змянілася нічога. З наступнай усталёўкі значок стаў няпраўдай.

Трэба аддаць належнае Microsoft: у нататках да выпуску 1.29.0 пра гэта ёсць адзін радок, там жа названы выключальнік, ORT_DISABLE_TELEMETRY=1. Проста я не чытаў нататкі да выпуску залежнасці маёй залежнасці.

Сесія без сеткі на 1.31.0 пакінула ў лакальнай чарзе 1 падзею пад назвай ProcessInfo. Я прачытаў яе проста ў чарзе. У ёй хэшаваны ідэнтыфікатар прылады, АС і яе версія, мадэль працэсара, агульны аб’ём памяці, тып віртуалкі, тып сеткі (“Wired”) і поўны шлях да выканальнага файла Python, у якім ёсць ваша імя карыстальніка, калі клон ляжыць у хатняй папцы. Зыходны ідэнтыфікатар прылады, без хэша, гэта UUID, які onnxruntime піша ў ~/.cache/Microsoft/DeveloperTools/.onnxruntime/deviceid.

Выцягнуты кабель толькі адкладвае адпраўку

Калі сетка адрэзана, падзея не выкідаецца. onnxruntime захоўвае яе ў файле SQLite побач з файлам ідэнтыфікатара, onnxruntime.db. У чыстай папцы кэша 2 сесіі без сеткі пакінулі ў чарзе 2 падзеі. Потым я запусціў 1 сесію з сеткай. Падчас яе сайдкар злучыўся з Microsoft. Пасля яе 2 падзеі, запісаныя без сеткі, з чаргі зніклі.

адна чыстая папка кэша, 3 сесіі запар сесія 1 сетка адрэзана у чарзе: 1 Microsoft: злучэння няма сесія 2 сетка адрэзана у чарзе: 2 Microsoft: злучэння няма сесія 3 сетка ёсць старыя падзеі: зніклі Microsoft: ёсць злучэнне файл з ідэнтыфікатарам прылады адзін на ўсе 3
onnxruntime 1.31.0, падзеі ў чарзе лічыліся праз sqlite3 пасля кожнай сесіі, злучэнні паводле strace. У паўторным прагоне 2 падзеі без сеткі пасля сесіі 3 таксама зніклі, а 2 новыя падзеі з гэтай сесіі засталіся чакаць.

Расшыфроўка застаецца на машыне, але запіс пра машыну і сесію чакае ў чарзе і, хутчэй за ўсё, сыдзе, як толькі вы зноў выйдзеце ў сетку.

З абедзвюма зменнымі ўсё дрэва зрабіла 0 злучэнняў і не стварыла файла з ідэнтыфікатарам. Расшыфроўка не змянілася.

Што выправіць

Сайдкар запускаецца з whisperRecognizer.ts са зменнымі асяроддзя, дзе зададзена HF_HOME. У каментарыі там напісана: “Nothing here needs to phone home once the model is on disk.” Абедзвюм зменным месца якраз там. Пакуль іх няма ў рэпазіторыі, задавайце іх самі перад запускам earshot. Можна таксама зафіксаваць onnxruntime ніжэй за 1.29, але наступная транзітыўная залежнасць можа зрабіць тое самае і я зноў даведаюся пра гэта выпадкова.

Значок павінен стаць тэстам, які запускае сесію пад strace з адрэзанай сеткай і не праходзіць пры любым connect() да IP-адраса. Такога тэсту ў мяне не было, таму змена ў onnxruntime прайшла незаўважна.

Чаго я не правяраў

Правяраў толькі Linux. У нататках да 1.29.0 сказана, што выключальнік распаўсюджваецца на тэлеметрыю па-за Windows. Трафік TLS я не расшыфроўваў, так што пра тое, што дайшло да Microsoft, я мяркую па лакальнай чарзе. Што падзеі без сеткі зніклі з чаргі таму, што адпраўка ўдалася, я не даказаў. У паўторным прагоне яны таксама зніклі, але 2 новыя падзеі з сесіі з сеткай засталіся чакаць. Праверкі з проксі і з адкіданнем пакетаў прагнаныя па 1 разе. Час запуску мераў па 3 прагоны на кожны варыянт, доля памылковых слоў па 1 прагоне на запіс.