Nedávno som písal o hardvérovej atestácii z pohľadu vášho telefónu: ako podpisovací kľúč vypálený do čipu v továrni umožňuje serveru overiť, že komunikuje s pravou, nezmenenou appkou na pravom, nezmenenom, nerootovanom zariadení, a ako ten istý mechanizmus vás zároveň potichu vyháňa z vlastného hardvéru. Ten článok skončil pri Signale a jeho SGX-based vyhľadávaní kontaktov ako dôkaz, že táto technológia môže fungovať aj naopak – v prospech súkromia, nielen uzamknutia. Toto je pokračovanie: čo sa stane, keď tú istú myšlienku namierite na AI inferenciu.
Problém s prenajatou GPU
Služby ako Claude, GPT od OpenAI, OpenRouter a podobné bežia na naozaj dobrých modeloch. Ale v skutočnosti neviete, čo robia s vašimi promptmi. Väčšinu času je to v poriadku. Niekedy nie je: nemôžete pustiť inferenciu na citlivom projekte, povedzme bezpečnostný audit nezverejneného kódu, cez službu, ktorej jediným sľubom je dokument s politikou ochrany súkromia. A keď máte podpísanú NDA, nemôžete sa spoliehať na sľub od poskytovateľa inferencie, že si nič neloguje.
Extrémne riešenie: kúpiť si hardvér sám
Veľa ľudí sa uchýli k zjavnému riešeniu: kúpiť inferenčný hardvér. Pri naozaj dobrom modeli, ako je nový DeepSeek v4 Flash 0731, to zrejme znamená 2x DGX Spark, poriadny Mac Mini alebo profesionálny GPU cluster. Problém je, že naraz môžete bežať len jeden model, neprepnete jednoducho medzi modelmi, a každá sekunda, kedy hardvér nerobí inferenciu, idú peniaze hore komínom.
Nie je to ani veľmi kapitálovo efektívne. Pri naozaj lacnom modeli, ako je DeepSeek, si spočítajte návratnosť investície: cena API cez tokeny oproti bežaniu vlastného hardvéru na plný výkon, a kedy by sa vám hardvér reálne vrátil. Tokeny DeepSeeku sú cez API extrémne lacné. Vlastný hardvér nie je strategicky výhodný spôsob šetrenia na platbe za tokeny; z tohto pohľadu to ekonomicky nedáva zmysel. A keď sa to skúsite spraviť ekonomickejším zdieľaním stroja (cez cloudového poskytovateľa, pretože ide o open-weight modely, ktoré môžu bežať kdekoľvek), ste späť pri rovnakom probléme: neviete, či ten poskytovateľ neloguje.
Stredná cesta: prenajatý hardvér, ktorý si viete overiť
Dobrou možnosťou je získať prístup k inferenčnému hardvéru, ktorý by si na seba inak nezarobil, bežať rôzne modely, prepínať medzi nimi, používať to z opencode (terminálový AI coding agent) alebo odkiaľkoľvek, a napriek tomu mať šifrovanie. Maple AI a Phala Network sa špecializujú na tento priestor; Venice, širšia AI API služba, to ponúka ako jednu z viacerých služieb. A je ich ešte oveľa viac.
Máte inferenčný hardvér a to, čo na ňom beží, je pevne daný inferenčný kontajner nazývaný enkláva, podobne ako virtuálny stroj. V tomto prípade beží izolovane od zvyšku stroja, takže ani hypervízor nevidí do pamäte kontajnera. Viete si overiť jeho hash, takže viete, čo tam presne beží. Kľúčový pár sa generuje vnútri tejto enklávy. Procesor dosvedčí, že kontajner naozaj bežal, vygeneroval si vlastné kľúče, a že výsledný verejný kľúč naozaj vznikol vnútri enklávy. Privátny kľúč neexistuje nikde inde. Ak sa stroj reštartuje, kľúč je preč; ďalší štart vygeneruje nový.
Keď si teda s poskytovateľom otvoríte session, vyjednávate kľúče a overujete atestáciu – to znamená, že verejný kľúč, ktorý ste dostali, naozaj vznikol vnútri enklávy bežiacej na známom, publikovanom hashi. Je to, ako by ste model bežali sami, len ho nebežíte: presne viete, aký kontajner beží, pretože je open source a publikovaný, a môžete byť istí, že keď zašifrujete svoj prompt na tento verejný kľúč a odovzdáte kľúč na odpoveď, nič podozrivé sa nestalo. Kontajner nemôže logovať zvnútra enklávy, a to si viete overiť z atestácie.
To je teória, a takto to má fungovať. V praxi je toho oveľa viac pod povrchom.
Kde sa to naozaj komplikuje: Venice
Venice potrebuje overovanie API kľúča, evidenciu spotreby, aby vedeli, koľko tokenov a koľko kreditu ste utratili, router k poskytovateľovi a poskytovateľa, ktorý smeruje na skutočný inferenčný stroj. Toto všetko by malo byť end-to-end atestované, ideálne celá cesta, končiaca vaším promptom priamo na inferenčnom stroji.
To celkom nie je to, čo sa deje s Venice dnes. Šifrovanie končí na routeri, nie na inferenčnom stroji. Aj tak to môže funkčne stačiť. Router je atestovaný a otvára TLS spojenie na inferenčný stroj, ktorý je tiež atestovaný, aj keď priamo vidíte iba overenie routera, že to tak je. Veríte tomu, pretože samotný kód routera, ktorý túto kontrolu vykonáva a zlyhá, ak kontrola neprejde, je sám atestovaný. Vieme, že tá kontrola sa deje, pretože sme overili kód, ktorý ju vykonáva. Navyše, volanie na GPU je overené, že smeruje na skutočný Nvidia čip, nie na nejaký logujúci proxy stroj medzi tým. Ak takýchto krokov spojíte dostatok – overíte jeden stroj a ten sa zaručí za ďalší – môžete byť dosť presvedčení, že sa nič nelogovalo end-to-end.
Dá sa to spraviť správne, a bolo by to naozaj užitočné. Apple je jeden príklad firmy, ktorá poskytuje vlastný hardvér na confidential compute. Iní poskytovatelia inferencie by mohli použiť Apple stack, alebo confidential compute postavený na AMD alebo inom výrobcovi procesorov. V takom prípade nie je poskytovateľom inferencie Apple. Apple, AMD, Intel, Nvidia a ostatné hardvérové firmy poskytujú atestovanú vrstvu výpočtu; poskytovateľ ako Venice, Phala alebo Maple by na tom mohol postaviť službu.
Nemusíte mať radi Intel, Apple, Nvidiu, AMD ani žiadnu z týchto firiem. To je rozumný postoj. Prelomiť dôveru enklávy stále vyžaduje buď bezpečnostnú chybu, alebo aktívnu spoluprácu na podvode. Bezpečnostné chyby sa už stali, a keď sa nejaká nájde, viete, že atestáciám z postihnutého hardvéru nemáte veriť, kým to nie je opravené. Druhá možnosť je, že výrobca čipu dá poskytovateľovi inferencie kľúče alebo certifikáty, ktorými môže podpisovať ľubovoľné atestácie. Neviem si predstaviť, že by Intel dal takúto možnosť Phale, Venice alebo Maple. Ide o malých hráčov v porovnaní s Intelom a ostatnými, a keby sa takáto schéma odhalila, reputácia výrobcu hardvéru by bola zničená. To je riziko, ktoré si žiadny z nich rozumne nemôže dovoliť.
Čo ukázal audit
Som autorom venice-e2ee-proxy, postaveného na knižnici venice-e2ee od Elkima. Strávil som pár dní vylepšovaním overovania a testovaním, čo Venice v skutočnosti odhaľuje.
Proxy šifruje prompty na vašom stroji na kľúč, ktorý je v Intel TDX (Trust Domain Extensions) atestácii. Sieť a infraštruktúra Venice vidia iba šifrovaný text. Dešifrovanie sa deje vnútri enklávy operovanej Phalou, ktorú nazývam gateway, a tá odosiela nešifrovaný text na atestovaný inferenčný router a odtiaľ na GPU node. Gateway kontroluje atestáciu ďalšieho stroja a viaže TLS spojenie na kľúč obsiahnutý v tejto atestácii. Overil som reťaz cez druhý hop. Kompletný bezpečnostný audit zároveň odhalil dôležité limity: gateway beží na vývojovom dstack (open-source framework na nasadzovanie TEE aplikácií) image a kompiluje si kód pri štarte pomocou trvalej cache (teda cache je na disku), namiesto toho, aby bežal na pripnutom binárnom súbore, ktorého presný kód je zmeraný (zahashovaný a zaznamenaný v atestácii, takže si každý môže overiť, čo naozaj bežalo); do enklávy môže byť vložený root SSH kľúč a atestácia vám nepovie, či sa to stalo; zmerané nastavenia povoľujú debug logovanie chýb, ktoré by mohlo odhaliť fragmenty zlyhaných requestov; overenie voči nadradenému stroju sa zaznamenáva, ale na strane trasy Venice nie je fail-closed; a serverový softvér a váhy modelu zostávajú mimo zmeraných tvrdení. Atestácia teda dokazuje menej prísnu konfiguráciu, než by mohla naznačovať fráza „privátna inferencia“, ale stále vám dáva podstatne viac dôkazov než obyčajný sľub poskytovateľa, že si nič neloguje.
Nie som jediný, kto sa v tomto vŕta. Andrew Miller (ako to spomenul na X) prevádzkuje awesome-private-inference, živý dashboard, ktorý denne testuje asi dvadsať poskytovateľov confidential inferencie a overuje, čo ich atestácie skutočne dokazujú oproti tomu, čo tvrdia. Jeho metodika a jednotlivé prípadové štúdie žijú v devproof-audits-guide case studies, vrátane samostatnej správy o Venice. Je to nezávislé potvrdenie rovnakého vzoru, aký som našiel ja: atestácia pokrýva len časti pipeline, nie celok, takže tvrdenie poskytovateľa o „privátnej inferencii“ stojí za to overiť, nie hneď prijať.
Dva spôsoby, ako to naozaj použiť
Integrácia má dve podoby. Appka môže overovanie použiť priamo ako knižnicu. Presne toto robí getbased.health, kde kontrola atestácie beží priamo vo vašom prehliadači v JavaScripte pri načítaní stránky. Prehliadač si overenie robí sám, bez vloženia ďalšej služby medzi vás a dôkaz.
Alebo, pre čokoľvek, čo čaká normálne OpenAI-kompatibilné API, opencode, vaše vlastné skripty, čokoľvek, spustíte si lokálny proxy, ktorý na localhoste vytvorí endpoint, ktorý sa tvári ako OpenAI API, pod kapotou vyrieši atestáciu a výmenu kľúčov, a šifruje/dešifruje transparentne. To je prístup venice-e2ee-proxy: rovnaká garancia, iný bod integrácie, výmena jednoduchosti natívnej v prehliadači za kompatibilitu s existujúcimi nástrojmi.
Medzera v použiteľnosti, a je to chyba Venice
Skutočná medzera v použiteľnosti je volanie nástrojov (tool calling). E2EE cesta nedokáže preniesť štruktúrované parametre volania nástrojov, pretože API nepodporuje ich šifrovanie. Knižnica sa musí spoliehať na odhadovanie tool callov z čistého textu odpovede modelu, čo je zo svojej podstaty nespoľahlivé. Spustíte niečo agentické ako opencode cez toto, a vydrží to zopár výmen, potom sa to rozpadne. Toto je prvá vec, ktorú by som na mieste Venice riešil: šifrované volanie nástrojov, a E2EE cesta prestane byť kuriozitou a stane sa niečím, cez čo by ste mohli reálne denne bežať agentov.
Prečo najvyššia úroveň nie je zjavná odpoveď
Vlastný hardvér, extrémne riešenie zo začiatku článku, znie ako zjavná odpoveď, kým si neprepočítate čísla. Zoberme dva DGX Sparky spojené do clustra za približne 10 000 dolárov za pár, ktoré spolu poskytujú dosť zdieľanej pamäte na bežanie modelu v rozsahu 200 miliárd parametrov a viac. Realisticky sa pozeráte na dvojročné okno, kým vás nová generácia hardvéru alebo nová generácia nárokov modelov nedobehne. Táto oblasť sa hýbe dosť rýchlo na to, aby „kúpiť raz, bežať navždy“ nebol svet, v ktorom sme. To je zhruba 417 dolárov mesačne v kapitáli samotnom, ešte bez elektriny. Aj mierne používanie pri pár stovkách wattov pridá ďalších 40 až 60 dolárov mesačne. Povedzme 460 až 480 dolárov mesačne, fixne, či to používate, alebo nie.
Porovnajte to s naozaj lacnou API inferenciou, niečím ako DeepSeek za výrazne menej než dolár za milión tokenov v priemere. Aby sa 460 dolárov mesačne v hardvérových nákladoch vyplatilo oproti tomu, potrebovali by ste spaľovať niekde okolo pol miliardy tokenov mesačne, trvalo. To je enormné množstvo inferencie. Väčšina power userov, aj tí, ktorí bežia viacero denných agentov a pipeline, sa k tomu ani zďaleka nedostane. To znamená, že pre veľkú väčšinu ľudí sa hardvér nikdy nevráti skôr, než zostarne.
A je tu druhá pasca navrch. Ak je vaše používanie dosť ľahké, že ekonomika už favorizuje API, hardvér väčšinu času stojí nečinne, čo je najhoršie možné využitie 10 000 dolárov. Ale ak si používanie zvýšite dosť vysoko, aby ste si vlastníctvo naozaj ospravedlnili, natrafíte na opačný problém: táto trieda hardvéru nie je stavaná na obsluhu veľkého množstva paralelných requestov, takže pri reálnej záťaži sa vaše požiadavky zaraďujú do radu za seba a spomaľuje presne vtedy, keď potrebujete udržať tempo. Buď vlastníte drahý hardvér, ktorý väčšinou stojí nečinne, alebo vlastníte hardvér, ktorý si konečne zaslúži svoje peniaze a je príliš pomalý na to, aby bolo príjemné ho používať. Ekonomika neponúka pohodlný stred.
Zhrnutie
Možnosti tvoria približnú hierarchiu. Na spodku sú poskytovatelia, ktorí otvorene logujú prompty a vydávajú ich, keď to zákon vyžaduje. Nad nimi sú anonymizované inferenčné služby a poskytovatelia, ktorí sľubujú, že si nič nelogujú. Sem patrí privátna vrstva Venice: ochrana je hlavne zmluvná, takže stále dôverujete politike poskytovateľa. Nad tým sú TEE a E2EE systémy, kde vám enklávy a atestácia umožňujú overiť si viac z tohto tvrdenia sami. Na vrchu je vlastný hardvér, kde nie je zapojený žiadny iný operátor.
Vlastný hardvér vám dáva najčistejší model dôvery, ale stojí okolo 10 000 dolárov za dva DGX Sparky, vyžaduje elektrinu a údržbu a rýchlo zastaráva. Pre veľa ľudí môže byť TEE a E2EE vrstva ideálnym bodom: lacnejšia a flexibilnejšia ako vlastníctvo, s viac dôkazmi než sľub od API poskytovateľa.
Nie je to dokonalé, ale je to lepšie, než len tak posielať prompty. A verím, že aj po blogoch ako tento sa služby zlepšia, atestácie budú potvrdzovať viac a budú použiteľnejšie. E2EE inferencie prestane byť kuriozita, ale reálne použiteľná možnosť.