beautifulsoups.dev
Published on

A1111에서 LoRA 50개 로딩도 빠르게 - 최적화

Authors

서로 다른 스타일을 빠르게 실험하려다 보면 LoRA가 금세 수십 개로 불어납니다. 문제는 A1111(WebUI)이 LoRA 목록을 스캔하고 메타데이터를 읽고, 미리보기 이미지를 다루는 과정에서 UI 지연, 프롬프트 입력 딜레이, 탭 전환 버벅임이 발생한다는 점입니다. 특히 LoRA 파일이 여러 폴더에 흩어져 있거나(심볼릭 링크 포함), 미리보기 썸네일이 크거나, 태그/메타가 복잡하면 체감이 커집니다.

이 글은 “LoRA를 50개 로딩해도 안 느리게”를 목표로, 로딩 지연의 병목을 분해하고 A1111에서 적용 가능한 현실적인 최적화 루틴을 정리합니다. (환경마다 차이가 있으니, 아래에서 제안하는 순서대로 측정하면서 적용하는 것이 핵심입니다.)

느려지는 지점부터 쪼개서 보기

A1111에서 LoRA가 많을 때 느려지는 이유는 대략 4가지로 나뉩니다.

  1. 디스크 스캔 비용: 시작 시 또는 새로고침 시 LoRA 디렉터리를 재귀 탐색
  2. 메타데이터 파싱: safetensors 헤더, 학습 정보, 트리거 워드, 태그 등 읽기
  3. 미리보기 로딩: png/jpg/webp 썸네일을 목록에서 즉시 렌더링
  4. UI 렌더링 비용: 수백 개 카드/행을 브라우저가 그리느라 느려짐

즉, “VRAM이 부족해서”라기보다는 I/O + 파싱 + 프론트 렌더링이 주범인 경우가 많습니다. 따라서 최적화도 이 축으로 접근해야 효과가 납니다.

1) LoRA 폴더 구조를 단순화하고 스캔 범위를 줄이기

가장 먼저 할 일은 A1111이 스캔해야 하는 파일 수를 줄이는 것입니다.

권장 폴더 구조

  • models/Lora/ 아래를 지나치게 깊게 만들지 않기
  • 사용 빈도가 낮은 LoRA는 별도 보관소로 분리하고 필요할 때만 옮기기
  • 중복 파일(동일 LoRA의 다른 이름 복사본)을 제거하기

예시:

stable-diffusion-webui/
  models/
    Lora/
      style/
      character/
      camera/
      archive/   # 평소엔 비워두거나 다른 위치로 분리

윈도우에서 심볼릭 링크를 남발하지 않기

심볼릭 링크 자체가 문제는 아니지만, 여러 드라이브를 가로지르는 링크와 복잡한 트리는 스캔 비용이 커질 수 있습니다. 가능하면 LoRA는 단일 SSD 경로에 모아두는 편이 낫습니다.

2) 저장장치 병목 제거: HDD 금지, SSD라도 “폴더 단편화” 주의

LoRA 50개 자체는 용량이 크지 않아도, A1111은 작은 파일들을 많이 열고 닫습니다. 이때 HDD는 체감이 크게 느립니다.

  • LoRA, VAE, Embeddings, Extensions까지 가능하면 NVMe SSD에 두기
  • 외장 SSD(USB) 사용 시 전원 관리로 순간 끊김이 생기면 스캔이 극단적으로 느려질 수 있음
  • 윈도우라면 Defender 실시간 검사 예외에 stable-diffusion-webui 폴더를 추가하는 것도 체감 개선이 큼(보안 정책에 따라 판단)

3) 미리보기(썸네일) 최적화: “큰 PNG”가 UI를 죽인다

LoRA 카드에 보이는 미리보기는 생각보다 비용이 큽니다. 특히 다음 조건이면 브라우저 렌더링이 무거워집니다.

  • 1024px 이상의 큰 미리보기
  • 무압축 PNG
  • LoRA 수가 많아 한 번에 많은 이미지를 DOM에 올리는 경우

권장 미리보기 규격

  • 512x512 또는 384x384
  • webp(품질 75~85) 또는 적당히 압축한 jpg

ImageMagick으로 일괄 변환 예시(원본 백업 후 실행 권장):

# PNG/JPG 미리보기를 512로 리사이즈하고 webp로 변환
magick mogrify -path ./previews_webp -resize 512x512^ -gravity center -extent 512x512 -format webp -quality 82 *.png *.jpg

A1111/확장 구성에 따라 미리보기 파일명 규칙이 다를 수 있으니, 현재 사용 중인 규칙에 맞춰 교체하세요. 핵심은 “목록에서 즉시 보여주는 이미지의 크기와 포맷”입니다.

4) LoRA 메타데이터(태그) 과다를 정리하기

일부 LoRA는 학습 정보나 태그가 매우 길고, UI에서 이를 펼쳐 보여주거나 검색 인덱싱에 포함되면서 지연이 생길 수 있습니다.

  • 트리거 워드/태그를 별도 텍스트 파일로 관리하고, UI에 노출되는 메타는 간소화
  • 불필요한 설명이 과도한 LoRA는 파일명에 핵심 키워드만 남기고 정리

파일명 규칙을 정해두면 검색 비용도 줄고, 무엇보다 “찾는 시간”이 줄어 체감 성능이 올라갑니다.

예시 파일명 규칙:

[category]_[subject]_[style]_[ver].safetensors
character_anya_anime_v2.safetensors
style_filmgrain_cinematic_v1.safetensors

5) A1111 실행 옵션으로 “불필요한 로딩/검사” 줄이기

A1111은 실행 인자에 따라 시작 시 동작이 달라집니다. 환경에 따라 효과가 큰 옵션들이 있습니다.

대표적으로 자주 쓰는 예시:

# Windows: webui-user.bat의 COMMANDLINE_ARGS 예시
set COMMANDLINE_ARGS=--xformers --opt-sdp-attention --no-half-vae

주의: 위 옵션들은 “LoRA 스캔” 자체를 직접 줄이기보다는, 전체 파이프라인의 병목(메모리/어텐션)을 완화해 전반적 버벅임을 줄이는 쪽에 가깝습니다. LoRA 로딩 지연이 UI 렌더링과 섞여 체감되는 경우에 도움이 됩니다.

또한 확장이나 설정에 따라 --skip-torch-cuda-test 같은 옵션을 쓰는 경우도 있지만, 이는 안정성/디버깅에 영향을 줄 수 있어 목적과 상황이 명확할 때만 권장합니다.

6) Extensions 정리: “LoRA가 많아서”가 아니라 “확장이 느려서”일 수도

A1111이 느려지는 원인을 LoRA로 착각하는 경우가 많습니다. 실제로는 다음이 원인인 케이스가 흔합니다.

  • 모델/LoRA 목록을 가공하는 확장(정렬, 필터, 태그 UI)
  • 시작 시 외부 리소스를 읽는 확장
  • Gradio UI를 무겁게 만드는 커스텀 UI 확장

점검 방법(가장 현실적인 A/B 테스트)

  1. 확장 전체 비활성화한 상태로 실행
  2. LoRA 50개 상태에서 UI 반응 확인
  3. 확장을 하나씩 켜며 병목 확장 찾기

확장 비활성화는 보통 extensions/ 폴더를 임시로 이름 변경하거나, A1111의 확장 관리 UI에서 끄는 방식으로 합니다.

이 과정은 CI에서 캐시 미스 원인을 좁히는 방식과 비슷합니다. “한 번에 다 바꾸지 말고, 하나씩 켰을 때 언제 느려지는지”를 찾아야 합니다. 이런 원인 분해 접근은 GitHub Actions 캐시 미스 원인 7가지와 해결에서 다룬 트러블슈팅 방식과도 결이 같습니다.

7) LoRA “항상 로딩” 습관을 버리고, 프리셋/그룹으로 운영하기

A1111은 LoRA를 “설정상 항상 메모리에 올려둔다”기보다, 선택/적용 시점에 가중치를 합성하는 흐름이지만, 사용자는 보통 목록을 계속 열어두고 탐색합니다. 이때 UI 비용이 커집니다.

그래서 운영 전략을 바꾸면 체감이 크게 좋아집니다.

  • 자주 쓰는 LoRA 10~15개만 favorites 폴더로
  • 프로젝트별로 project_x/ 폴더로 나누고 필요할 때만 이동
  • 프롬프트 템플릿(프리셋)에 LoRA 호출을 묶어 “찾는 행위”를 줄이기

프롬프트 템플릿 예시(인라인 코드에서 부등호 금지 규칙 준수):

# preset: cinematic portrait
(masterpiece, best quality), 85mm, f1.8, rim light
lora:style_filmgrain_cinematic_v1:0.7
lora:camera_portrait_depth_v2:0.6
negative: (worst quality, low quality), extra fingers

핵심은 “LoRA 50개를 매번 UI에서 스크롤하며 고르는 작업” 자체를 줄이는 것입니다.

8) 캐시/인덱스가 있다면 적극 활용하고, 깨졌을 땐 과감히 재생성

A1111 및 일부 확장은 모델/LoRA 목록, 썸네일, 메타를 캐싱합니다. 캐시가 꼬이면 오히려 느려질 수 있습니다.

  • 목록이 갱신되지 않거나 새로고침이 과도하게 느려지면 캐시 삭제 후 재생성
  • 확장 업데이트 후 느려졌다면 해당 확장의 캐시/설정 초기화

이때 중요한 운영 팁은 “캐시는 성능을 올리지만, 캐시 무효화가 실패하면 성능이 급락한다”는 점입니다. 시스템 전반에서 캐시를 다룰 때 자주 겪는 함정과 유사하니, 캐시 전략 감을 잡고 싶다면 GitHub Actions 캐시 미스 원인 7가지와 해결도 같이 보면 도움이 됩니다.

9) 브라우저/렌더링 최적화: 의외로 크롬 탭 하나가 병목

A1111은 Gradio 기반 UI라서, 브라우저가 느리면 그대로 체감이 옵니다.

  • 크롬 확장(특히 스크립트 주입형)을 끄고 비교
  • 하드웨어 가속 켜기/끄기 토글 후 비교
  • LoRA 탭(또는 모델 선택 패널)을 열어둔 상태에서만 느린지 확인

“목록 UI를 열어둔 상태에서만 버벅이면” LoRA 계산이 아니라 DOM 렌더링/이미지 디코딩 문제일 확률이 높습니다.

10) 성능 측정 루틴: 바꾸기 전에 숫자부터 잡기

최적화는 감으로 하면 끝이 없습니다. 최소한 아래 3가지는 기록하세요.

  • A1111 실행 후 첫 화면까지 걸리는 시간
  • LoRA 탭 열기/검색 입력 지연(키 입력 후 반응까지)
  • LoRA 새로고침(Rescan) 시간

간단한 체크리스트 형태로 기록 예시:

환경: Win11, NVMe, RAM 32GB, RTX 4070
LoRA 수: 52
- 첫 로딩: 38s
- LoRA 탭 오픈: 2.4s
- 검색 입력 지연: 400ms
- Rescan: 12s

적용: 미리보기 webp 512 + 확장 2개 비활성화
- 첫 로딩: 24s
- LoRA 탭 오픈: 0.9s
- 검색 입력 지연: 80ms
- Rescan: 5s

이런 식으로 “무엇이 얼마나 좋아졌는지”가 보이면, 불필요한 튜닝을 줄이고 재현 가능한 세팅을 만들 수 있습니다. 운영 관점에서 보면 장애 추적과 유사하며, 네트워크/인프라에서 원인 추적하는 방식은 EKS에서 Pod egress만 502? Envoy/NLB 추적기 같은 글의 접근과도 통합니다.

실전 추천 조합(우선순위)

LoRA 50개를 “그냥 두고도” 최대한 안 느리게 만들고 싶다면, 아래 순서가 효율적입니다.

  1. LoRA를 NVMe SSD 단일 경로로 정리(스캔 비용 최소화)
  2. 미리보기를 512 webp로 통일(렌더링 비용 최소화)
  3. 확장 A/B 테스트로 병목 확장 제거
  4. LoRA를 즐겨찾기/프로젝트 단위로 운영(탐색 비용 최소화)
  5. 캐시/인덱스 꼬임 시 재생성(비정상 지연 제거)

마무리

A1111에서 LoRA가 50개라고 해서 반드시 느려지는 것은 아닙니다. 대개는 “파일 스캔 + 메타 파싱 + 미리보기 렌더링 + 확장 UI”가 합쳐져서 병목이 됩니다. 그래서 최적화도 VRAM이나 CUDA 옵션만 만지는 게 아니라, 디렉터리 구조와 미리보기 규격, 확장 구성, 브라우저 렌더링까지 포함해 시스템적으로 접근해야 합니다.

위 체크리스트대로 하나씩 적용하고, 측정값을 남기면서 튜닝하면 LoRA가 많아도 충분히 쾌적한 워크플로를 만들 수 있습니다.

Discuss on Twitter • View on GitHub