ONNX 런타임 웹, 페이지당 스레드 수를 한 번만 고정하여, 타임아웃 재시도 시 새 Worker를 시작해야 함

(dev.to)

ONNX Runtime Web의 WASM 백엔드는 페이지 레벨 싱글톤이므로, 브라우저 AI 추론의 성능 최적화와 타임아웃 발생 시 안정적인 복구를 위해서는 초기 세션 생성 전 스레드 수를 결정하고 실패 시 새로운 워커를 생성하는 전략이 필수적입니다.

이 글의 핵심 포인트

1ONNX Runtime Web의 WASM 백엔드는 페이지 레벨 싱글톤으로, 첫 세션 생성 전 스레드 수가 결정되어야 함
2crossOriginIsolated 상태가 아니면 멀티스레딩을 사용할 수 없으므로, 성능 저하 시 가장 먼저 확인해야 할 요소임
3워커 스크립트 로드 실패나 세션 생성 지연에 대비해, 초기 실행 전 아주 작은 프로브 워커를 통해 멀티스레딩 가능 여부를 미리 테스트함
4세션 생성 중 20초 타임아웃 발생 시, 기존 워커를 종료하고 싱글 스레드 모드로 동작하는 새로운 워커를 생성하여 복구함
5타임아웃 발생 시 기존 요청은 실패하며, 싱글 스레드 모드는 멀티 스레드 모드보다 실행 속도가 느림

이 글에 대한 공공지능 분석

왜 중요한가?

브라우저 내 AI 추론의 성능과 안정성을 결정짓는 런타임의 핵심 동작 원리를 다룹니다. 특히 멀티스레딩 설정이 페이지 레벨에서 고정된다는 제약을 이해해야만, 실행 중 발생하는 에러에 대해 무의미한 재시도를 반복하는 리소스 낭비를 막을 수 있습니다.

어떤 배경과 맥락이 있나?

WebAssembly(WASM)와 ONNX Runtime을 활용하여 서버 비용 없이 클라이언트 사이드에서 고성능 AI 모델(BiRefNet 등)을 실행하려는 기술적 흐름이 배경입니다. 이는 고비용 GPU 인프라를 대체하려는 웹 기반 AI 서비스 개발자들에게 매우 중요한 주제입니다.

업계에 어떤 영향을 주나?

웹 기반 AI 서비스 개발 시, 단순한 모델 구현을 넘어 브라우저의 보안 격리(COOP/COEP) 상태와 워커 생명주기에 따른 성능 변동성을 설계 단계부터 고려해야 함을 시사합니다. 이는 서비스의 초기 로딩 성능과 에러 핸들링 설계의 표준을 높이는 계기가 됩니다.

한국 시장에 어떤 시사점이 있나?

클라이언트 사이드 AI를 활용해 인프라 비용을 극적으로 절감하려는 한국의 AI 스타트업들에게, 런타임의 저수준 기술 제약을 고려한 정교한 에러 복구 로직 구축이 사용자 경험(UX) 유지와 비용 효율화의 핵심임을 보여줍니다.

이 글에 대한 큐레이터 의견

브라우저 기반 AI 추론 기술은 서버 비용을 획기적으로 줄일 수 있는 강력한 도구이지만, 이번 사례처럼 런타임의 '싱글톤' 특성 같은 저수준의 기술적 제약이 서비스의 안정성을 위협할 수 있습니다. 개발자는 단순히 모델의 정확도에만 집중할 것이 아니라, 브라우저의 보안 격리(Isolation) 상태와 워커 생명주기에 따른 성능 변동성을 설계 단계부터 고려해야 합니다.

물론, 새로운 워커를 생성하여 복구하는 방식은 기존 사용자의 상태를 유지할 수 있다는 장점이 있지만, 타임아웃된 요청 자체는 실패하며 싱글 스레드 전환 시 성능 저하라는 트레이드오프가 발생합니다. 따라서 스타트업은 '성능 극대화'와 '실패 시 복구 가능성' 사이의 균형을 맞추기 위해, 초기 로딩 시점에 환경을 정밀하게 프로빙(Probing)하고 이를 캐싱하는 정교한 초기화 로직을 구축하는 데 기술적 투자를 집중해야 합니다.

원문 보기 →