DGX Monarch - ComfyUI를 활용한 듀얼 Spark 렌더링

ComfyUI로 이미지/비디오 생성을 위해 듀얼 Spark 클러스터를 사용하고 싶었던 분들께, 오늘이 바로 그날입니다. 저는 올해 4월에 이 개인 프로젝트를 시작했고, 이제는 공개적으로 배포해도 괜찮은 지점에 이르렀습니다. 가장 간단하게 말씀드리자면, 이 저장소(repo)를 통해 거의 2배의 렌더링 속도를 얻을 수 있습니다. 결과는 모델과 설정에 따라 다릅니다. BF16/FP8/NVFP4/INT8 등 다양한 형식을 지원하며, 이는 모델에 따라 달라집니다. GGUF는 지원하지 않습니다. 저장소 링크: https://github.com/Deen-Media/dgx-monarch (README 다음의 FAQ를 읽어보시길 강력히 권장합니다). 나머지 내용은 훨씬 더 지루할 것이므로, 사용을 바로 시작하고 싶다면 건너뛰셔도 됩니다. 경고드립니다. 지금까지 읽은 시간과 특히 이 게시물의 나머지에 대해서는 환불해 드릴 수 없습니다. 말이 너무 많네요. 쓸데없는 말 네 개가 더요. 그냥 확인하는 겁니다. 질문하시기 전에 말씀드리자면, 네, 저는 AI를 많이 사용하여 이것을 개발했습니다. 하지만 제 시간의 대부분은 결과물과 성능을 검증하고 실제로 이 프로젝트를 사용하는 데 할애되었습니다. 유지보수 측면에서 보자면, 제가 구축한 개발 워크플로우가 최신 상태로 유지되도록 노력해 왔고 앞으로도 그렇게 할 것이며, 이를 통해 새로운 모델들이 아무 문제 없이 안전하게 추가될 수 있도록 할 것입니다. 저는 이러한 개발 워크플로우를 공유할 의도는 없습니다. 왜냐하면 그것을 공유하기 위해 제가 들여야 하는 노력 대비 가치가 없다고 개인적으로 생각하기 때문입니다. 명확히 하자면, 여기서 말하는 것은 예시 ComfyUI 워크플로우가 포함된 저장소의 워크플로우가 아니라 저의 개인 AI 에이전트 개발 워크플로우를 의미합니다. 제 의견으로는 이러한 워크플로우는 사용자가 직접 만들고 맞춤화해야 하는 것입니다. 저는 AI가 생성한 PR(Pull Request)을 기대하고 있으며, 결국은 제가 만든 것과 사용자님이 만드신 것을 비교하는 것이라는 점을 알고 있습니다. 제가 요청하는 것은 여러분이 실제로 앉아서 변경 사항을 검증/렌더링/테스트하고 그 결과를 포함해 주시는 것입니다. 저도 그것들을 검토하고 테스트할 시간이 필요하니, 부디 인내심을 가져주세요. 저는 이 도구를 사용하는 것을 정말 즐기며 계속 그렇게 하고 싶습니다.

개인적으로는 유지보수(Maintaining)가 두 번째로 중요하지만, 아이러니하게도 사용과 유지보수는 함께 간다. 작은 프로젝트를 '감'으로 코딩하는 것은 쉽지만, 대규모 프로젝트를 '감'으로 유지보수하는 것은 매우 어렵고 비용이 많이 든다 (시간뿐만 아니라 돈). 투명성을 위해 말씀드리자면, 이 같은 프로젝트는 시작된 이후 매주 다음 구독 서비스들을 소진시켰다 (그리고 저는 0%/평탄화 상태로 만들었다): OpenAI: - Astra 계정 1개 × $200* (현재 Astra 계정 $500) - Business Astra 좌석 1개 *저는 모든 예비/글로벌 리셋을 활용했고 글로벌한 것에서 정말 운이 좋았다. **엄밀히 말해, 매우 빠르게 추가적인 미흡한 PR(Pull Request)들을 처리하기 위해서이며 초고속으로 작동한다 (하지만 실제로는 커뮤니티가 한두 시간 전에 통보받는 자발적인 글로벌 리셋을 활용하기 위함이다). 게다가 예전과 비슷한 사용량을 얻기 위해 두 배 이상 지불하는 것도 즐긴다. Anthropic: - Fable 계정 1개 × $200 - Business Fable 좌석 1개 Cursor: - Fable 계정 1개 × $200 (Grok은 작동 코드에는 건드리지 않았다 - 다른 사용 사례가 있었다) Google: - Ultra 계정 1개 × $250 (놀라지 마세요 - Gemini는 작동 코드를 건드리지 않았습니다) (참고: Astra/Fable은 이 프로젝트가 시작될 때 존재하지 않았다. 재미있었다.) 저는 앞으로 몇 달 동안 여기에 출시할 다른 프로젝트들(더 DGX에 특화된 것들)이 있기 때문에, 합리적으로 가능한 한 오랫동안 이 구독들을 유지할 것이다. 하지만 모든 구독을 유지하는 것이 의미가 없어지는 시점은 분명히 올 것이다. 그것이 로컬 모델들이 마침내 제 워크플로우를 처리하기에 충분하거나 효과적이게 되거나, 프론티어 비용(frontier costs)이 급등하거나, 보조금 시대가 끝나면서 사용 허용량이 줄어들거나, 아니면 프로젝트 자체가 높은 수준의 유지보수가 더 이상 필요하지 않기 때문일 수 있다 (가능성은 낮다). 그게 전부입니다. 읽어주셔서 감사합니다. /u/Historical-Internal3 제출 [링크] [댓글]