SmartEnergyShare.info
Bezpečnost

Bezpečnostní díry v AI infrastruktuře na AWS: trénujete miliony parametrů, ale vaše data možná unikají dřív, než první epoch skončí

Bezpečnostní díry v AI infrastruktuře na AWS: trénujete miliony parametrů, ale vaše data možná unikají dřív, než první epoch skončí

Bezpečnostní díry v AI infrastruktuře na AWS: trénujete miliony parametrů, ale vaše data možná unikají dřív, než první epoch skončí

Trénink jednoho foundation modelu velikosti GPT-3 stojí přibližně čtyři až dvanáct milionů dolarů jen na výpočetním výkonu. To je číslo, které vám zaručeně vyrazí dech. Jenže co většina inženýrů přehlíží: bezpečnostní incidenty během tréninku nebo inference mohou znamenat, že celá ta práce přijde vniveč — nebo hůř, skončí v rukou konkurence. Podívejme se, jak AWS poskytuje stavební bloky pro práci s foundation modely, kde se skrývají bezpečnostní slabiny a jak vLLM přechod z V0 na V1 mění pravidla hry.


AWS SageMaker a EC2: infrastruktura, která vypadá bezpečně, ale není

Amazon Web Services nabízí pro trénink a inference foundation modelů celý ekosystém služeb. Na první pohled je to impozantní: SageMaker HyperPod pro distribuovaný trénink, EC2 P5 instance s H100 GPU, Amazon Bedrock pro spravovanou inferenci, FSx for Lustre jako vysokorychlostní sdílené úložiště. Jenže právě tahle komplexnost je zdrojem problémů.

Typická architektura pro trénink large language modelu na AWS vypadá takto: tréninkový cluster s desítkami P4d nebo P5 instancí komunikuje přes EFA (Elastic Fabric Adapter) s propustností 3,2 Tbit/s, checkpointy letí do S3, tensorboard metriky proudí do CloudWatch. Bezpečnostní problém číslo jedna: IAM role. Vývojáři v zájmu pohodlí dávají instancím přílišná oprávnění. Tréninkový job nepotřebuje přístup k celému S3 bucketu — potřebuje přístup k jednomu prefixu. Každý, kdo tohle ignoruje, otevírá dveře pro únik tréninkových dat.

Druhý problém jsou VPC konfigurace. Při použití SageMaker Training Jobs bez `EnableNetworkIsolation: true` může tréninkový kontejner komunikovat s libovolným externím endpointem. To je zásadní problém, pokud trénujete na proprietárních datech — model mohl (hypoteticky) exfiltrovat data ven z clusteru. AWS tento parametr nabízí, ale málokdo ho zapíná, protože komplikuje debugování.

Ceny EC2 pro srovnání: jedna p4d.24xlarge instance (8× A100) stojí přibližně 32 dolarů za hodinu. Pro trénink modelu střední velikosti potřebujete takových instancí osm až šestnáct, po dobu týdnů. Celkové náklady na netriviální trénink se rychle šplhají k šestimístným číslům v dolarech.


EMO: Mixture of Experts a proč emergentní modularita mění bezpečnostní model

EMO — Pretraining Mixture of Experts for Emergent Modularity — je přístup, který dostává čím dál více pozornosti. Klasický transformer má husté vrstvy, kde se každý token zpracovává přes všechny neurony. Mixture of Experts (MoE) místo toho aktivuje při zpracování každého tokenu jen podmnožinu "expertů" — specializovaných podsítí. Výsledkem jsou modely jako Mistral 8x7B nebo Google Mixtral, které mají sice velký celkový počet parametrů, ale nízké výpočetní nároky při inferenci.

Emergentní modularita v EMO přístupu jde ještě dál: cílem je, aby se specialization u expertů vyvinula přirozeně z tréninkových dat, bez explicitního předpisu. Model sám "přijde na to", že například jeden expert je dobrý na kód, jiný na matematiku, třetí na přirozený jazyk.

Bezpečnostní implikace jsou zajímavé. MoE modely jsou obtížněji interpretovatelné — nevíte přesně, který expert aktivuje konkrétní chování. To komplikuje red-teaming a auditování modelů před nasazením. Pokud trénujete firemní MoE model na AWS, musíte počítat s tím, že standardní interpretability techniky (jako activation patching nebo logit lens) fungují jinak než u hustých modelů.

Na AWS se EMO trénink typicky provádí přes SageMaker s customizovanými tréninkými skripty. Distribuovaný MoE vyžaduje precizní implementaci expertního routingu přes více GPU — Amazon Trainium 2 čipy (Trn2 instance) jsou zajímavou alternativou k NVIDIA H100, za přibližně třetinovou cenu. Trn2.48xlarge stojí kolem 21 dolarů za hodinu. Pro open-source MoE experimenty doporučuji začít s Mixtral na HuggingFace — model je volně dostupný a příklady pro AWS jsou dobře zdokumentované.


vLLM V0 na V1: proč "correctness before corrections" není jen heslo

vLLM je dnes de facto standard pro high-throughput LLM inferenci. V0 verze fungovala výborně — PagedAttention, continuous batching, KV cache management. Jenže V1 přináší fundamentální redesign, a slogan "Correctness Before Corrections in RL" popisuje přístup, který má přímý bezpečnostní dopad.

Konkrétní problém: V0 vLLM mělo několik edge casů, kde při specifických kombinacích parametrů (beam search + temperature sampling + prefix caching najednou) docházelo k deterministicky nesprávným výsledkům. Výstupy modelu byly jiné, než kdyby model běžel jiným inferenčním enginem. Pro většinu aplikací to byl kosmetický problém. Pro reinforcement learning z lidské zpětné vazby (RLHF) nebo pro reinforcement learning obecně to byl katastrofální problém — reward model dostával "jiné" odpovědi, než by produkoval model v produkci.

V1 přidává komprehensivní test suite, která ověřuje numerickou ekvivalenci výstupů oproti referenční implementaci (PyTorch eager mode). Každý PR musí projít correctness testy předtím, než se řeší výkon. Zní to triviálně, ale v praxi jde o zásadní změnu priority.

Pro AWS deployment vLLM: typicky běžíte na EC2 g5 nebo p4d instancích, vLLM server spustíte přes Docker. Konkrétní příkaz:

```bash docker run --runtime nvidia --gpus all \ -v ~/.cache/huggingface:/root/.cache/huggingface \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model mistralai/Mistral-7B-v0.1 \ --tensor-parallel-size 4 ```

Bezpečnostní poznámka: vLLM server ve výchozím nastavení nemá žádnou autentizaci. Pokud ho vystavíte bez reverse proxy s autentizací, kdokoliv s přístupem k portu 8000 může generovat text vaším modelem — a platit z vašeho AWS účtu.


Reálné bezpečnostní hrozby při LLM inference na cloudu

Inference je paradoxně rizikovější než trénink z pohledu bezpečnosti. Trénink je batch job, inference je živý endpoint. Jaké jsou konkrétní hrozby?

Prompt injection přes API. Pokud váš inference endpoint zpracovává uživatelský vstup bez sanitizace a předává ho modelu jako součást systémového promptu, útočník může přepsat instrukce. Na AWS Bedrock je toto částečně mitigováno guardrails funkcí, ale ta není zadarmo — cena je přibližně 0,75 dolaru za tisíc zpracovaných požadavků.

Model theft přes inferenci. Útočník může systematicky dotazovat váš model a pomocí model extraction útoku vytvořit aproximaci. Ochrana: rate limiting, monitoring na neobvyklé vzory dotazů (velké množství krátkých, systematicky se lišících promptů), watermarking výstupů.

Data poisoning při fine-tuningu. Pokud provádíte fine-tuning na datech od třetích stran (customer feedback, webový scraping), existuje riziko backdoor útoku — tréninkový set může obsahovat vzory, které způsobí, že model při specifickém triggeru chová jinak. Amazon Bedrock Fine-tuning nabízí integraci s AWS GuardDuty pro anomaly detection, ale detekce poisoning útoků v datech je stále aktivní výzkumná oblast.

IAM over-provisioning. Znovu. Toto není teoretická hrozba. V roce 2023 unikla tréninkové data z několika startupů právě kvůli nadměrně volným S3 bucket polítics. Minimální práva (least privilege) jsou základní hygienou, ne pokročilou bezpečností.

Pro energetický sektor je toto obzvlášť relevantní. AI modely, které optimalizují spotřebu elektřiny, obchodují s bateriemi nebo predikují spot ceny, pracují s citlivými provozními daty. Smart Energy Share například pracuje s daty z BESS jednotek (50–250 kW), obchodováním odchylek a regulační elektřinou — data z těchto systémů jsou přísně regulovaná a jejich únik by mohl mít závažné provozní i právní důsledky.

Více o zabezpečení AI systémů pro energetiku si můžete přečíst na SmartEnergyShare.cz, kde jsou popsány konkrétní případy nasazení VPP systémů s AI optimalizací.


Open-source alternativy: Ollama, LoRA a jak trénovat za zlomek ceny

AWS není jediná cesta. Pro firmy, které si nemohou dovolit desítky tisíc dolarů za trénink, existují realistické alternativy.

Ollama pro lokální inferenci: spustíte llama3, Mistral nebo Phi-3 model na vlastním serveru bez cloudových nákladů. Příkaz je triviální:

```bash curl -fsSL https://ollama.com/install.sh | sh ollama run llama3.1:8b ```

Na serveru s RTX 4090 (GPU za přibližně 25 000 Kč) běží 8B model bez problémů, inference je srovnatelná s AWS Bedrock pro jednoduchou aplikaci. Bezpečnostní výhoda: data opustí váš on-premise server.

LoRA (Low-Rank Adaptation) pro fine-tuning: místo tréninku celého modelu trénujete jen malé "adaptory" — matice nízké hodnosti přidané k váhovým maticím modelu. Výsledek: fine-tuning Mistral 7B na vlastních datech zvládnete na jedné A100 GPU za hodiny místo dnů. Náklady: jednotky dolarů místo tisíců. Na AWS je to jedna p3.2xlarge instance (cena kolem 3 dolarů za hodinu) na osm hodin.

HuggingFace ekosystém je nezbytný základ. Transformers, PEFT pro LoRA, Accelerate pro distribuovaný trénink — vše open-source, vše integrované s AWS SageMaker. Knihovnu PEFT pro LoRA fine-tuning najdete na HuggingFace.

Bezpečnostní audit open-source modelů je ale vlastní zodpovědností. Modely z HuggingFace nejsou automaticky bezpečné — existují případy modelů s backdoory nebo skrytými funkcionalitami. Základní hygiena: používejte pouze modely od ověřených organizací, kontrolujte model cards, spouštějte modely v izolovaném prostředí.

Fotovoltaika a sdílení energie mají s AI stále více společného — predikce výroby, optimalizace baterií, obchodování odchylek. Více o praktickém nasazení AI v kontextu sdílení energie z FVE čtěte na ShareElectric.cz.


Závěr: bezpečnost není afterthought, ale základ

Foundation modely na AWS nejsou projekt, kde se bezpečnost řeší na konci. IAM role, VPC izolace, endpoint autentizace, monitoring inference požadavků, audit tréninkových dat — to jsou věci, které musí být na místě od prvního dne.

vLLM V1 s přístupem "correctness first" ukazuje správný směr: než budete optimalizovat výkon, ujistěte se, že systém dělá to, co si myslíte, že dělá. Stejná filozofie platí pro bezpečnost — než nasadíte model do produkce, ujistěte se, že víte, co model může a co nemůže říct, kdo k němu má přístup a co se stane s daty, která do něj pošlete.

Pro energetický sektor, kde AI optimalizuje megawattové baterie a obchoduje s regulační elektřinou, jsou bezpečnostní selhání infrastruktury AI infrastruktury doslova drahá. Jedno špatně nakonfigurované IAM oprávnění může stát víc než celý tréninkový budget.


Zdroje