Stable Diffusion WebGPU 데모

• 브라우저에서 직접 실행되는 Stable Diffusion 이미지 생성 데모로, 별도 서버 없이 WebGPU와 WebAssembly 기반으로 동작
• 최신 Chrome에서 "Experimental WebAssembly" 와 "Experimental WebAssembly JavaScript Promise Integration (JSPI)" 플래그를 활성화해야 사용 가능
• Prompt, Negative Prompt, inference step 수를 입력받아 이미지를 생성하며, 모델 파일은 캐싱되어 매번 다시 다운로드할 필요 없음
• 4GB를 초과하는 메모리 할당을 위해 onnxruntime, emscripten, binaryen을 패치하고 Python의 StableDiffusionPipeline을 JS로 포팅한 결과물
• 멀티스레딩 미지원과 WebGPU 연산 미구현 등으로 현재는 속도가 느리지만, 향후 JS 커널 구현과 memory64 지원으로 개선 가능성 제시

---

실행 요구 사항

• 최신 Chrome 브라우저에서 Experimental WebAssembly 및 Experimental WebAssembly JavaScript Promise Integration (JSPI) 플래그 활성화 필요
• Model files는 캐싱되어 재방문 시 재다운로드 불필요

입력 및 동작 방식

• 입력 항목으로 Prompt, Negative Prompt, inference step 수 제공
  • PNDM Scheduler 사용으로 실제 step은 입력값 i에서 i+1로 처리
• 각 step은 약 1분 소요, 이미지 생성을 위한 VAE decoder 실행에 추가로 약 10초 소요
• DevTools를 열어둔 상태에서는 전체 속도가 약 2배 느려짐
• UNET은 CPU에서만 실행되며, GPU보다 10% 빠르고 GPU에서는 올바른 결과를 내지 못해 브라우저 탭이 멈춤
• 수용 가능한 결과를 얻기 위한 최소 step 수는 20이며, 데모 목적으로는 3 step도 무방

FAQ

• protobuf parsing failed 오류

  • DevTools에서 Application → Storage로 이동 후 "Clear site data" 실행

• sbox_fatal_memory_exceeded 오류

  • SD 실행에 필요한 RAM 부족 상태로, 탭 또는 브라우저 재로드로 해결 시도

• 구현 방식

  • Python의 StableDiffusionPipeline을 JS로 포팅
  • onnxruntime과 emscripten+binaryen(WebAssembly 컴파일러 툴체인)을 패치해 4GB 초과 메모리 할당 및 사용 지원
  • 관련 pull request가 릴리스에 반영되면 누구나 브라우저에서 4GB 초과 메모리를 사용하는 코드 컴파일·실행 가능

• 느린 속도의 원인

  • 아직 멀티스레딩 미지원으로 CPU 코어 하나만 사용
  • WebAssembly.Memory 생성자를 통한 SharedArrayBuffer로 64비트 메모리 생성이 불가능
  • "memory64" 플래그 사양 변경을 제안했으며, 채택 후 V8 엔진을 패치해 지원 예정

• GPU 실행 여부

  • GPU에서 실행되지만 onnxruntime의 WebGPU가 초기 단계라 다수 연산이 미구현
  • 데이터가 JS를 통해 CPU와 지속적으로 전송됨
  • 대부분 연산에 JS 커널이 구현되면 속도 대폭 향상 가능

• 로컬 실행 가능 여부

  • 가능하며, 해당 페이지 코드는 stable-diffusion-webgpu-minimal 저장소에서 제공

• transformers.js로 대형 LLM 실행 가능 여부

  • 패치된 onnxruntime 패키지(@aislamov/onnxruntime-web64) 사용 가능하나 모든 경우 동작 보장은 없음
  • 해당 빌드는 8GB 메모리로 제한되어 약 4GB 가중치까지 로드 가능

• onnxruntime 저장소 pull request 계획

  • 진행 예정이며, 이전에 node.js 바인딩에 GPU 가속을 추가한 데 이은 두 번째 작업

[GN⁺]

Hacker News 의견들

• MLC 팀은 이미 3월에 이걸 동작시켰음: https://github.com/mlc-ai/web-stable-diffusion
  더 인상적인 건 이후 여러 대형 언어 모델 지원까지 추가했다는 점임: https://webllm.mlc.ai/

  • 정말 인상적이고 성능도 훨씬 좋아 보임. 나는 사전 수정 없이 임의의 ONNX 모델을 실행하는 다른 접근을 따르고 있었음

• “3.5GB를 로드하고 RAM 8GB를 사용합니다”
  브라우저가 이렇게 된 게 흥미로움. 웹이 운영체제를 먹어버렸음

  • 이 비판은 잘 이해가 안 됨. 브라우저를 통해 내 컴퓨터에서 Stable Diffusion을 실행하는 건데, 다운로드하고 RAM에 올리지 않고 어떻게 할 수 있겠음?
    브라우저 없이 직접 다운로드해 실행해도 내려받는 크기와 RAM 사용량은 거의 같을 것임
  • 웹이 Java의 원래 전제를 먹어버렸음
  • 그래서 운영체제가 곧 브라우저인 노트북을 파는 회사가 있고, 스마트 TV에서도 같은 일을 하는 회사가 있음
  • 대역폭이 늘고 웹 샌드박스가 성숙해지면서, 다운로드·설치·유지관리 대신 그냥 쓰는 앱으로 진화하는 모습을 보는 게 흥미로움. 일부는 싫어하겠지만 대중에게는 많은 문을 열어줌
  • 이제 WebGPU가 실시간 상호작용 WebXR 페이지, 스트리밍 멀티플레이어 상태, 많은 드로우 콜 같은 경우 말고도 이런 용도에 유용하다는 생각이 듦.
    브라우저로 이런 경험을 제공하면 단순해지는 면이 있고, Stable Diffusion을 실행하기에 이보다 쉬운 방법도 없어 보여서 이런 프로젝트가 계속 지원받으면 좋겠음

• Experimental WebAssembly와 Experimental WebAssembly JavaScript Promise Integration (JSPI) 플래그가 켜진 최신 Chrome이 필요하다니, Firefox에 들어올 때까지 기다려야겠네

  • 적어도 Firefox는 이제 CSS 스크롤바 스타일링을 허용하니 그건 좋은 일임
  • Brave에서 요청된 chrome:flags를 켰지만 여전히 동작하지 않았음. M1 Mac들에는 Chrome을 다운로드한 적이 없고, 이제 와서 시작할 생각도 없음
  • Canary에서 켜봤지만 그래도 동작시키지 못했음
  • Chrome에서 시도조차 안 하겠다는 건가?
  • 두 번째 플래그는 뭘 하는 건가?

• 여기에도 이미 구현돼 있음: https://websd.mlc.ai/#text-to-image-generation-demo
  MLC는 Apache TVM으로 WebGPU 코드 생성과 자동 튜닝을 하고, 성능도 꽤 괜찮음

• MLC-AI의 Stable Diffusion을 내 웹사이트에 커스텀 배경 생성기로 통합했음. 모델 데이터는 Hugging Face에서 가져옴
  https://dustinbrett.com/

  • 이 정도로 부드럽고 빠른 걸 보면, 휴대폰의 모든 앱이 화면 몇 개 보여주고 API 호출 몇 번 보내는 데 200MB씩 요구하는 게 슬퍼짐
  • iPhone 12 mini에서 잘 로드됐고 휴대폰이 과열되지도 않았음. 정말 인상적임
  • 웹사이트가 인상적이고 전부 아주 부드럽게 잘 동작함. 결국 Doom을 필요 이상으로 오래 하게 됐음

• CPU에 묶이는 작업은 서비스 워커를 써서 메인 스레드가 멈추지 않게 하는 걸 고려해볼 만함

• 다음은 WebGPU 챗봇인가? 브라우저에서 내 GPU로 ChatGPT식 채팅을 하는 것?

  • 이미 되긴 함. 몇 가지 제한이 있음
    대형 언어 모델은 좋은 모델일수록 RAM/VRAM을 많이 먹어서 WebGPU에서 특히 까다로움
  • https://webllm.mlc.ai/
    이미 구현돼 있음

• 호기심인데, 이걸 어디에 쓰는 건가?
  내가 아는 건 서버가 아니라 브라우저에서 이미지를 생성한다는 점임. 떠오르는 건 이미지를 바꾸거나 새로 생성하려고 페이지를 새로고침할 필요가 없다는 정도임.
  그러면 시각 디자인이 실시간으로 바뀌는 웹사이트가 가능하다는 뜻일 수도 있겠고, 기능적으로도 유의미하게 바뀔 수 있다면 꽤 멋질 듯함. 다만 Stable Diffusion이 사이트의 UI 컴포넌트나 시각 요소 생성에 얼마나 유용할지는 잘 모르겠음

  • 이미지를 대량 생성하는 비용이 비싸기 때문에 유용함. 연산 비용을 클라이언트로 옮기는 셈임
  • 용도는 자기 컴퓨터에서 쉽게 실행하는 것임. 프로그래머일 필요도 없고 애플리케이션을 설치할 필요도 없음
  • 순수하게 로컬에서 모델을 실행하면 프라이버시가 큰 장점임
    민감한 프롬프트가 원격의 누군가에게 새어나가지 않음

• WebGPU에서의 성능과 네이티브 실행 성능을 비교한 지표가 있나?

  • UNET은 WebGPU에서 약 1분 10초, CPU 단일 스레드에서는 1분 정도 걸림. VAE는 CPU에서 2분, GPU에서는 약 10초 걸림.
    VAE용 GPU 연산은 대부분 이미 구현됐지만 UNET용은 그렇지 않아서 그런 듯함. 후자의 경우 브라우저가 매 단계마다 GPU와 CPU 사이로 데이터를 계속 던지고 있음

• 충분히 빠르다면 개인 용도로 이미지를 로컬 렌더링하는 데 쓸 수 있음. 웹사이트는 프롬프트만 전달하고 사용자마다 다른 이미지를 렌더링할 수도 있음.
  그 지점에선 저작권이 어떻게 되는 걸까? 모델 자체가 저작권 대상인가, 아니면 체계가 무너지는 건가?

  • 그 가능성은 흥미롭지만, 지금은 그런 세계와는 아주 멀리 있음. 이 스레드 다른 곳에서도 이게 RAM 8GB를 적극적으로 사용한다고 나옴.
    그리고 많은 웹 디자이너가 모델이 프롬프트를 잘못 해석하거나, 손가락 수가 틀린 왜곡된 결과를 만들거나, 의도하지 않은 맥락에서 성적·폭력적 콘텐츠를 우연히 만드는 위험을 받아들이진 않을 것 같음.
    오늘날 많은 생성 이미지 모델은 보통 열 장 이상 중에서 가장 나은 것을 고르고, 버리는 나머지는 실제로 꽤 나쁠 수 있음.
    웹사이트를 일상적으로 동적으로 삽화화하려면 모델의 품질과 예측 가능성이 지금보다 훨씬 높아져야 함.
    그렇다고 절대 거기까지 못 간다고 말하고 싶진 않음. 최근 모델들은 몇 년 전만 해도 상상할 수 없다고 여겨졌을 일을 이미 하고 있음. https://xkcd.com/1425/와 비교해보면, 젊은 독자들에게는 그 농담의 배경 문제를 설명하는 것조차 어려울 수 있음!