7월 20일, AI Doomsday Toolbox v0.948의 저자는 단일 네트워크 내의 여러 Android 기기를 통해 Stable Diffusion을 실험적으로 실행하는 모습을 보여주었습니다. 이 의도는 세 대의 전화기가 GPU 스테이션을 앞지르는 것이 아닙니다. 그 목적은 훨씬 더 현실적입니다. 즉, 단일 기기의 메모리에 들어가지 않는 모델을 실행해 보는 것입니다.

이는 생성 욕구가 아니라 가용 하드웨어의 한계에 부딪힌 모든 이들에게 중요한 차이점입니다. 전화기 클러스터는 총 용량을 확장할 수 있지만, 그 대가로 지연 시간(latency), 조정(coordination) 및 오류 위험을 감수해야 합니다. 따라서 올바른 질문은 "더 빨라질 것인가?"가 아니라 "이 방식이 필요한 모델을 실행할 기회를 제공하며, 내 작업에 적합한 상태를 유지할 수 있는가?"가 되어야 합니다.

저자가 분산시키고자 제안하는 것

설명된 방식에서는 text encoder와 VAE는 하나의 기기에 남겨두고, diffusion model을 세 대의 기기 사이에 분할합니다. 이것은 독립적인 성능 테스트도 아니며, 모든 시나리오를 위한 완성된 모드를 약속하는 것도 아닙니다. 저자 스스로 이 기능이 실험적이라고 직접 언급하며 타협점을 설명했습니다. 즉, 더 큰 모델을 속도를 희생하여 더 쉽게 사용할 수 있게 된다는 것입니다.

이 프로젝트는 이미 master/worker 스레드, Stable Diffusion을 통한 로컬 이미지 및 비디오 생성, 그리고 여러 Android 기기를 통합된 RAM 및 연산 자원으로 포지셔닝한다고 발표했습니다. 7월 13일에 업데이트된 Google Play 페이지에는 SD 1.5, SDXL, FLUX, LoRA 및 VAE가 나열되어 있습니다. 하지만 7월 20일의 게시물은 v0.948이 아직 Play 스토어 승인을 기다리고 있다고 별도로 경고했습니다. 따라서 이 특정 빌드가 이미 스토어를 통해 배포되었다고 주장하며 플랫폼 설명을 대체해서는 안 됩니다.

Схема распределённого Stable Diffusion между Android-устройствами

여기서 얻는 것은 속도가 아니라 가능성입니다

이 경우 "장치가 많을수록 더 빠를 것이다"라는 직관은 기만적입니다. 분산 방식(distributed scheme)에는 단일 장치에서 실행할 때는 없는 작업이 발생합니다. 즉, 노드(nodes)들이 각자의 부분을 조화롭게 수행하고, 데이터를 전달하며, 참여자의 탈락(dropout) 상황을 견뎌내야 합니다. 속도를 희생한다는 저자의 표현은 여기서 그 어떤 상상 속의 이득보다 더 중요합니다.

그렇기 때문에 이 실험은 두 가지 서로 다른 관점에서 평가되어야 합니다:

여기에 반전이 있습니다. 만약 작업이 이미 단일 장치에서 해결 가능하다면, 두 대의 휴대폰을 더 연결하는 것은 마찰(friction)만 가중시킬 뿐입니다. 클러스터가 의미를 갖는 시점은 제약 조건이 명확할 때입니다. 즉, 선택한 모델이 단일 휴대폰의 메모리(memory) 용량을 초과하지만, 로컬 실행이 최소한의 지연 시간(latency)보다 여전히 더 중요할 때입니다.

시작은 큰 모델이 아니라

여기서 가장 유용한 첫 번째 단계는 "세 대의 장치를 모아서 즉시 최대치를 로드하는 것"이 아닙니다. 이는 메모리 문제와 네트워크 및 분산 문제를 분리해내는 카나리(canary) 테스트입니다.

1. 단일 휴대폰에서 잘 알려진 작은 모델을 실행합니다.
2. 프롬프트(prompt), 시드(seed), 스텝 수(number of steps)를 고정합니다.
3. 동일한 작업을 두 대, 그다음 세 대의 장치에서 반복합니다.
4. 각 실행마다 모델이 메모리에 들어갔는지, 결과에 도달하기까지 전체 경로가 얼마나 걸렸는지, 실패나 재시도가 있었는지, 설정된 파라미터에 따라 출력이 예상과 일치하는지를 기록합니다.
5. 그 이후에야 비로소 분산 처리가 필요했던 모델을 시도합니다.

이러한 테스트는 클러스터가 "더 빠르다"는 것을 증명하지는 않습니다. 대신 초기 데모에서 흔히 부족한 해결책을 제공합니다. 즉, 제약 조건이 정확히 메모리 적합성(memory fit)인지, 그리고 추가적인 복잡성을 감수하면서 실제로 필요한 용량을 확보할 가치가 있는지를 알려줍니다.

중단 조건(stop-condition)을 미리 정의해 두는 것이 유용합니다. 만약 두 번째 또는 세 번째 노드(node)가 정기적으로 재실행을 요구하고, 필요한 모델이 여전히 수용 가능한 작동 사이클을 제공하지 못한다면, 실험은 제 역할을 다한 것입니다. 즉, 이 설계의 한계를 보여준 것입니다. 여기서 실패한 카나리(canary)는 실패가 아니라, 여러 대의 휴대폰을 끝없는 인프라 유지보수 프로젝트로 전락시키지 않기 위한 방법입니다.

실질적인 위험이 발생하는 지점

로컬 네트워크에서는 토폴로지(topology)와 장치 구성을 제어할 수 있지만, 참여자 수가 늘어남에 따라 장애 지점(point of failure)도 늘어납니다. 연결 끊김, 특정 장치 세트의 호환성 문제, 또는 단일 워커(worker)의 오류는 전체 실행을 중단시키거나 재실행을 요구할 수 있습니다. 따라서 결과는 파이프라인(pipeline)의 개별 부분이 아니라, 작업 전송부터 완성된 이미지까지의 엔드 투 엔드(end-to-end) 관점에서 평가해야 합니다.

단순한 보안 한계도 존재합니다. 워커 서비스(worker-services)를 공용 네트워크에 노출해서는 안 됩니다. 실험은 어떤 장치가 참여하고 누가 이를 관리하는지 명확히 알 수 있는 신뢰할 수 있는 로컬 루프(local loop) 내부에서 유지하는 것이 의미가 있습니다.

폰 클러스터(phone cluster)에 대한 강력한 반론도 타당합니다. 목표가 짧은 대기 시간으로 정기적인 생성을 수행하는 것이고 로컬 자율성이 필수 요구 사항이 아니라면, GPU나 클라우드 서비스가 거의 확실히 더 직접적인 경로가 될 것입니다. 휴대폰 클러스터는 단순히 여러 장치를 합친다고 해서 워크스테이션(workstation)을 대체할 수 있는 것은 아닙니다.

자체적인 분산 설계를 유지하는 것보다 기성 모델을 사용하는 것이 더 중요한 작업의 경우, provod.ai는 다른 운영 모델(operating model)을 제안합니다: 휴대폰 오케스트레이션(orchestration) 없이 호스팅된 모델(hosted-models)을 사용하는 방식입니다. 이는 Stable Diffusion 인프라가 아니며 장치를 클러스터로 만드는 방법도 아니지만, 로컬 작업의 수를 줄이는 방향을 선택한 것입니다.

실험이 정당화되는 경우

분산 실행(distributed launch)을 시도해 볼 가치가 있는 경우는 다음 세 가지 조건이 동시에 충족될 때입니다: 필요한 모델이 하나의 Android 장치에 들어가지 않고, 로컬 작업이 귀하의 시나리오에서 가치가 있으며, 추가적인 대기 시간이 허용 가능한 경우입니다. 예를 들어, 이미 보유하고 있는 장치에서 사용 가능한 용량을 확인하거나 자율적인 기술 실험을 수행하는 경우 등이 해당됩니다.

만약 예측 가능한 생성 시간, 스트리밍 작업(streaming work) 또는 유지보수의 단순함이 더 중요하다면 분산 실행으로 시작해서는 안 됩니다. 이 경우 클러스터의 가치는 사라집니다. 클러스터는 귀하의 사례에 존재하지 않을 수도 있는 용량 문제(capacity problem)를 해결하려 하기 때문입니다.

Выбор между локальной ёмкостью и меньшей оркестрацией

provod.ai — 제품을 다시 작성하지 않고도 AI 스택을 업데이트하세요

수요가 있는 모델이 등장하면 이미 익숙한 경로를 통해 연결하세요: API, 키, 잔액 및 팀의 도구는 그대로 유지되며, 현재 가용성은 카탈로그에서 확인할 수 있습니다.

하나의 카탈로그에서 텍스트 및 미디어용 최신 모델을 만나보세요: OpenAI의 GPT, Anthropic의 Claude, Google의 Gemini, xAI의 Grok, DeepSeek, Qwen, GLM, Kimi 및 MiniMax; 이미지용으로는 Nano Banana 2 Pro 및 GPT Image; 비디오용으로는 Seedance, Kling, Veo 및 Google Omni의 최신 버전이 준비되어 있습니다. 또한 추론(reasoning), 검색, 문서, 임베딩(embeddings), 음악 및 오디오를 위한 모델도 사용할 수 있습니다.

새로운 기능에 대한 플랫폼의 추가 마진은 없습니다: 새로운 모델의 공식 요금이 provod.ai의 추가 할증 없이 1:1로 적용됩니다.

새로운 모델을 더 빠르게 연결하세요: 등록 양식 · 모델 가격 · 152-FZ에 따른 데이터 보호 · API 및 통합

귀하의 작업에 있어 무엇이 더 비용이 많이 드나요: 예측 불가능한 지연 시간(latency)을 감수하더라도 더 큰 모델을 로컬에 수용할 수 있는 능력인가요, 아니면 다른 운영 모델(operating model)과 더 적은 로컬 오케스트레이션(local orchestration)을 위해 이러한 자율성을 포기하는 것인가요?