LDG-33: Add LLM membership inference attack (ez-mia) - #454
Draft
Muhaddisabarat wants to merge 8 commits into
Draft
Muhaddisabarat wants to merge 8 commits into
Muhaddisabarat wants to merge 8 commits into
Conversation
…ument ts2vec HPU gap Continues the HPU integration work: the notebook now picks up the shared device utility instead of hardcoding CUDA/CPU, and notes that TS2Vec should be dropped from audit.yaml's signal list on Habana. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds the ez-mia error-zone membership inference attack for causal LLMs as leakpro/llm_attacks/mia, a new top-level attack category (sibling to attacks/ and synthetic_data_attacks/) for text/LLM-targeted attacks. It stays standalone rather than plugging into AbstractMIA/AttackFactoryMIA: LeakPro's classic MIA attacks audit a pre-trained classifier via shadow models, while this attack trains its own target LLM and a single reference model (base/distillation/SFT) and scores membership from per-token log-probabilities, which doesn't fit that shadow-model/logit-caching machinery. Device selection is swapped from ez-mia's own HPU/CUDA/CPU detection to leakpro.utils.device.get_device()/mark_step(), and RNG seeding is now based on the selected device (respecting LEAKPRO_DEVICE overrides) rather than independently probing CUDA/HPU availability. Everything else (CLI, YAML configs, results.csv output) is unchanged from ez-mia. Adds an `llm-mia` optional-dependency group for its HF/PEFT/OmegaConf stack, and excludes the module from ruff's strict house-style lint pass (same treatment as leakpro/webapp) since it keeps ez-mia's own style rather than being rewritten to LeakPro's ANN/docstring conventions. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
# Conflicts: # examples/mia/time_series_mia/main.ipynb # pyproject.toml
Gives leakpro.llm_attacks.mia the same open-and-run experience as the other examples/mia/* notebooks, even though it doesn't go through Leakpro(...)/audit.yaml: it calls run_attack(cfg) directly, with a small smoke-test config and a full run loaded from one of the shipped YAML configs. Verified end to end on this machine (CPU override via LEAKPRO_DEVICE=cpu, since the physical HPU was held by another process). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Each Habana card is exclusive to one process (confirmed via hl-smi and a
memory_stats() repro: a process reserves ~101GB, the whole card, the
instant it touches the HPU, independent of actual workload size). On this
shared machine, if the notebook's kernel and another job end up on the
same physical card, Habana's runtime can hard-crash the loser mid-run
with no Python traceback ("kernel crashed"). Confirmed this is contention,
not a leak in the port: a controlled repro at comparable batch/sequence
shapes showed flat HPU memory usage (~1-2GB) across training and eval.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Matches the examples/mia/*/train_config.yaml convention used by the other attacks, though the schema here is leakpro.llm_attacks.mia's own AttackConfig (dataset/model/training hyperparameters consumed directly by run_attack), not the target-model-training config those examples use -- llm_mia doesn't go through that pipeline. The notebook's YAML-config cell now loads this local file instead of one of the module's bundled configs, so editing dataset/model/hyperparameters means editing the file next to the notebook, as with the other examples. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Every field the smoke test set (dataset, ref_variant, model_name, seed, train_total, eval_total, val_total, epochs, batch_size, sequence_length) is a real AttackConfig field, so the same fast sanity check is just train_config.yaml with smaller values -- no need for a second, hardcoded config path in the notebook. Down to one config-driven flow: imports -> train_config.yaml -> run_attack. Verified end to end with the values temporarily lowered, matching the new instructions in the notebook's markdown cell. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
Check out this pull request on See visual diffs & provide feedback on Jupyter Notebooks. Powered by ReviewNB |
Muhaddisabarat
changed the title
The first cell was unconditionally setting PT_HPU_LAZY_MODE and HABANA_VISIBLE_MODULES regardless of what hardware is actually present. Harmless on GPU/CPU-only machines (Habana's runtime just never reads them), but it read as HPU-first rather than device-agnostic. Now it only touches Habana-specific setup when habana_frameworks is actually installed (checked via importlib.util.find_spec, not an import, since the vars must be set before any torch/habana import to take effect). The real HPU -> CUDA -> CPU dispatch is unchanged: it still happens via leakpro.utils.device.get_device() regardless of what this cell does. Verified both branches directly (habana_frameworks present vs. a nonexistent package name standing in for "absent", with a cleared environment to rule out this machine's own exported Habana env vars), and re-ran the notebook's full pipeline end to end afterward. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Muhaddisabarat
changed the title
Muhaddisabarat
marked this pull request as draft
September 17, 2026 07:57
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
leakpro/llm_attacks/mia, a new top-level attack category for text/LLM-targeted attacks (sibling toattacks/andsynthetic_data_attacks/).AbstractMIA/AttackFactoryMIA: this attack trains its own target LLM and a single reference model (base/distillation/SFT) and scores membership from per-token log-probabilities, which doesn't fit LeakPro's shadow-model/logit-caching classifier machinery.leakpro.utils.device.get_device()/mark_step(), so it follows the same device-selection convention as the rest of the codebase (hence targeting this branch rather thanmain).examples/mia/llm_mia/main.ipynb+train_config.yaml, giving it the same open-and-run experience as the otherexamples/mia/*notebooks.llm-miaoptional-dependency group inpyproject.tomlfor its HF/PEFT/OmegaConf stack, and excludes the module from ruff's strict house-style lint pass (same treatment asleakpro/webapp) since it keeps ez-mia's own code style rather than being rewritten to LeakPro's ANN/docstring conventions.Test plan
python -m leakpro.llm_attacks.mia --helpworksruff check leakpro --exclude examples,leakpro/tests,leakpro/webapp,leakpro/llm_attackspassesexamples/mia/llm_mia/main.ipynbverified end-to-end on CPU and HPUleakpro.utils.device.get_device(); thepin_memory/empty_device_cacheCUDA branches are unchanged from ez-mia's original code), andleakpro's owntest_device.pyexercises the CUDA path via mocking, but this has not been run on real GPU hardwaresyn_text_pii_scanner🤖 Generated with Claude Code