CPU 노트북용 보안 추론 엔진 구조

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

Patronus Ark는 prompt injection, 위험한 tool call, 민감 문서와 PII를 클라우드로 보내기 전에 endpoint에서 탐지하기 위해 CPU 노트북에서도 실행되는 보안 추론 구조를 구축했습니다. 초기에는 작업별 모델을 양자화하고 축소했지만 메모리가 약 3GB까지 늘어나는 문제가 생겨, 규칙 기반 L1과 저비용 분류기인 L2 NTDBs를 먼저 거친 뒤 필요한 경우에만 mmBERT 기반 L3를 실행하는 cascade로 방향을 바꿨습니다. 공유 tokenizer·embedding·latent representation과 learned gate를 사용해 전체 transformer 실행의 약 76–84%를 제거했고, 다섯 개 pipeline은 항상 L3를 실행하는 기준과 F1 1%p 이내를 유지했습니다. 데스크톱 애플리케이션은 M1 MacBook Air에서 약 750MB RSS, 실제 보안 분석 중앙값 약 500ms를 기록했으며, mmBERT 내부에서도 22개 층 중 12층 전에 약 90%를 판별하고 전체 층이 필요한 사례는 1% 미만인 조기 종료 실험을 진행하고 있습니다.

실용적 조언

보안 추론을 CPU endpoint에 상주시킬 때는 작업별 Transformer를 각각 줄이기보다 native heuristic과 structured detection을 먼저 배치하고, 작은 classifier를 거친 뒤 어려운 입력만 큰 모델로 보내는 cascade를 우선 검토할 수 있습니다.
여러 보안 작업이 같은 입력을 처리한다면 tokenizer, embedding, latent representation을 공유해 chunk당 중복 전처리를 없애고, 저비용 판단 결과를 사용해 full model 진입 여부를 learned gate로 결정하는 방식을 적용할 수 있습니다.
조기 종료 구조는 평균 연산량만 보지 말고 pipeline별 F1 차이, 승격 비율, RSS, 실제 입력 길이, median latency를 함께 측정해야 합니다. 이 사례에서는 L3 승격률이 약 16–24%였고 다섯 개 pipeline만 기준 대비 F1 1 percentage point 이내였으므로, 모든 작업에 동일한 gate 기준을 적용하지 않는 편이 타당합니다.

섹션별 상세

Patronus Ark는 prompt injection, 위험한 tool call, 민감 문서와 PII를 상호작용이 발생한 endpoint에서 처리하려는 AI 보안 inference engine입니다. 전체 prompt나 파일, tool result를 먼저 다른 cloud service로 보내지 않는 것이 목표였고, 동시에 GPU 없는 일반 업무용 laptop에서 상시 실행해야 했습니다. 작업별 모델을 각각 실행하고 양자화하는 초기 방식은 메모리를 약 3GB까지 끌어올려 IDE, browser, local agent와 local LLM이 함께 동작하는 8GB laptop에 부담이 됐습니다.

L1은 ML이 필요하지 않은 입력을 native heuristic과 structured detection으로 빠르게 처리하고, L2 NTDBs는 작은 neural head, LightGBM, logistic regression 같은 저비용 classifier를 사용합니다. L2는 chunk 단위로 처리하면서 document-wide classification에는 attention을 적용하고, L3만 full mmBERT-based classifier를 실행합니다. 세 계층은 독립 모델을 따로 돌리는 대신 tokenizer, embedding, latent representation을 공유하므로 chunk를 한 번 tokenize·embed한 뒤 cheap decision과 learned gate를 거쳐 필요한 경우에만 더 깊은 계산으로 넘어갑니다.

보고 가능한 evaluation pipeline에서 L3로 승격되는 사례는 약 16–24%였고, 이에 따라 full transformer execution의 약 76–84%가 사라졌습니다. 여덟 개 pipeline 중 다섯 개는 항상 full model을 실행하는 방식과 비교해 F1 차이가 1 percentage point 이내였지만, 나머지 세 개는 아직 같은 수준에 도달하지 못했습니다. 따라서 작성자는 이 구조를 정확도 손실 없는 공짜 연산 절감으로 보지 않고, gate 품질과 pipeline별 trade-off가 남은 설계로 판단합니다.

현재 full desktop application은 2021 M1 MacBook Air에서 dynamic PII를 위한 별도 GLiNER path를 포함해 peak 약 750MB RSS를 기록합니다. 실제 desktop 사용 중 median security analysis는 약 500ms였고, 입력은 256-token chunk 하나부터 약 30–40k tokens까지 다양했습니다. 이 수치는 endpoint 상주 애플리케이션이 GPU 없이도 여러 입력 규모를 처리하도록 메모리와 지연시간을 함께 관리해야 한다는 점을 뒷받침합니다.

작성자는 mmBERT 내부 층 사이에도 선택 결정을 넣어 L3 진입 여부를 넘어 필요한 Transformer depth 자체를 줄이는 실험을 진행하고 있습니다. 초기 결과에서는 22개 층 가운데 12층 전에 약 90%의 사례를 판별할 수 있었고, 22개 층 전체가 필요한 사례는 1% 미만이었지만 proper ablation은 아직 필요합니다. agent가 대량의 tool output과 retrieved content를 처리하는 환경에서는 모든 chunk에 최대 깊이를 적용하는 비용이 커지므로, endpoint 제약에서 출발한 selective depth 구조가 high-volume inference에도 연결될 가능성을 살피고 있습니다.

용어 해설

조기 종료 추론(Early-Exit Inference): — 모델의 모든 층을 끝까지 실행하지 않고 중간 층의 예측 확신도가 충분하면 계산을 중단하는 추론 방식입니다. 입력마다 필요한 연산 깊이를 달리해 지연시간과 비용을 줄이는 것이 핵심입니다.
캐스케이드 추론(Cascaded Inference): — 값싼 1차 판별기를 먼저 통과시킨 뒤 어려운 입력만 더 큰 모델로 보내는 다단계 추론 구조입니다. 쉬운 사례의 전체 모델 실행을 생략해 평균 계산량을 낮추는 데 목적이 있습니다.
선택적 Transformer 깊이(Selective Transformer Depth): — 모든 입력에 동일한 Transformer 층 수를 적용하지 않고 입력별로 필요한 깊이를 선택하는 방식입니다. 중간 표현과 게이트를 활용해 조기 종료 지점을 정하며, 정확도와 연산량 사이의 균형이 중요합니다.
RSS 메모리(RSS Memory): — 프로세스가 실제로 점유하는 상주 메모리 크기입니다. 백그라운드에서 실행되는 AI 보안 애플리케이션에서는 운영체제와 IDE, 브라우저, 로컬 모델이 사용할 메모리까지 고려해야 하므로 핵심 제약이 됩니다.
동적 PII 탐지(Dynamic PII Detection): — 입력에 포함된 개인정보를 고정된 규칙만으로 찾지 않고 모델 경로를 통해 문맥에 맞게 식별하는 처리입니다. 이 글에서는 별도의 GLiNER 경로가 동적 PII 처리를 맡습니다.

언급된 도구

LightGBM중립

L2 NTDBs에서 사용하는 저비용 classifier

GLiNER중립

dynamic PII 처리를 위한 별도 경로