7월 16일, Kandinsky 5 저장소(repository)에서 I2V 발생 시 OOM(Out of Memory), Windows에서의 torch 및 torchvision 임포트 문제, NumPy와의 충돌 등 몇 가지 오래된 런타임 이슈(runtime-issue)가 종료되었습니다. 가중치(weights)를 다운로드하려는 사람에게 이는 Kandinsky가 발전하고 있으며 오래된 장애물들이 제거되고 있다는 좋은 신호로 보일 수 있습니다.

하지만 이슈가 종료된 당일, 해당 논의에서 메인테이너(maintainer)들의 새로운 해결책이 제시되지는 않았습니다. 이는 실질적인 해결책이 변하지 않았음을 의미합니다. 즉, 가중치를 로드하기 전에 특정 파이프라인(pipeline), 자신의 OS, CUDA 가시성, torch와 torchvision의 결합, 그리고 메모리 소비 경로를 반드시 확인해야 합니다. closed 상태는 트래커(tracker)의 기록을 설명할 뿐, 귀하의 머신에서 추론(inference)이 성공할 것임을 증명하지 않습니다.

하나의 종료된 티켓이 수정을 의미하지 않는 이유

기록 시점 기준으로 Kandinsky 5 저장소는 796개의 스타(star)와 60개의 포크(fork)를 보유하고 있었습니다. 이는 프로젝트에 대한 관심을 나타내는 지표이지만, 호환성 표는 아닙니다. 오픈 웨이트(open weights)는 통합 작업의 상당 부분을 모델을 실행하는 사람에게 전가합니다. 바로 그 사용자가 가중치, 코드, 드라이버, CUDA, 라이브러리 및 메모리 제한을 연결해야 하기 때문입니다.

이는 이슈(issue) №61에서 특히 잘 드러납니다. 해당 이슈에는 오프로딩(offloading)과 MagCache를 사용했음에도 불구하고 80GB 메모리를 가진 A100에서 I2V 실행 시 발생하는 OOM이 설명되어 있습니다. 동일한 논의에서 한 참여자는 Linux 환경의 4090에서 실행되었던 더 오래된 대안을 언급하기도 했습니다. 이로 인해 최소 VRAM 용량이나 보편적인 레시피를 도출할 수 없습니다. 파이프라인(pipeline), 모드, 환경 및 메모리 작업 경로가 모두 다르기 때문입니다.

결론은 불쾌하지만 유용합니다. "비디오 메모리가 충분할까?"라는 질문은 너무 막연합니다. kandinsky video를 위해서는 어떤 파이프라인(pipeline)을 실행하는지, 어떤 입력값을 사용하는지, 어떤 구성(configuration)인지, 그리고 피크(peak)가 어디에서 발생하는지(로드 시, DiT에서, VAE에서, 또는 결과 디코딩 시)를 묻는 것이 더 중요합니다.

Схема: зависимости, CUDA, pipeline и память как последовательные проверки

임포트 수정만으로는 충분하지 않다

Issue №108은 두 번째 함정을 보여줍니다. 임포트 (import) 오류는 torch와 torchvision 버전 간의 불일치와 관련이 있었으나, 그 이후 Windows 환경에서의 CUDA 장치와 관련된 별개의 문제가 드러났습니다. 첫 번째 오류를 해결했다고 해서 모델이 생성 (generation) 준비가 되었다는 증거가 되지는 않았습니다.

이는 로컬 실행 시 흔히 발생하는 구조입니다. 초기 단계의 오류가 다음 단계로의 접근을 차단하는 방식입니다. 따라서 성공적인 import를 추론 (inference) 준비 완료와 혼동해서는 안 되며, 시스템에 GPU가 나타난다고 해서 선택한 PyTorch 빌드가 이를 인식할 것이라고 착각해서도 안 됩니다.

여기서 강력한 반론이 제기될 수 있습니다. 닫힌 티켓 (closed tickets)은 여전히 유용하다는 점입니다. 티켓은 중복을 제거하고, 논의의 범위를 확정하며, 때로는 문제가 오래되었거나 다른 곳으로 옮겨졌음을 보여줍니다. 이를 무시하는 것은 현명하지 못한 일입니다. 오류는 다른 지점에서 시작됩니다. 바로 티켓의 상태를 재현 가능한 테스트의 결과로 오해할 때입니다.

배지(badge)를 믿는 대신 스모크 테스트 (Smoke test)

대규모 다운로드와 설정을 시작하기 전에 다섯 가지 짧은 관문을 통과하는 것이 유용합니다. 이 과정의 목적은 Kandinsky의 보편적인 작동 가능성을 증명하는 것이 아니라, 사용자의 구성 (configuration)에 대한 답을 빠르게 얻는 데 있습니다.

1. 깨끗한 환경을 생성하고 선택한 torch 및 torchvision 버전을 고정하세요.

2. 정확한 파이프라인 (pipeline)과 그 구성을 선택하세요. 한 작업의 결론을 다른 작업, 특히 이미지(image)에서 I2V(Image-to-Video)로 옮겨 적용하지 마세요.

3. 모델이 실행될 것과 동일한 환경에서 CUDA 가시성을 확인하세요.

4. 생성 없이 임포트 (import)를 수행하세요. 만약 통과하지 못한다면 품질, 메모리 또는 프롬프트 (prompt)에 대한 논의로 넘어가지 마세요.

5. 지원되는 아주 작은 규모의 생성을 실행하고 피크 메모리 사용량을 기록하세요. 그 이후에야 입력 파라미터를 늘리는 것이 의미가 있습니다.

이러한 테스트는 비용 지출의 순서를 바꿉니다. 모든 것을 먼저 다운로드하고, 플래그 (flags)를 맞추고, 스레드에서 조언을 찾는 대신, 먼저 실패의 유형(의존성, 장치, 파이프라인 또는 메모리)을 정의하게 됩니다. 만약 실패가 초기 단계 중 하나에서 머물러 있다면, "이슈 (issue)는 이미 종료되었습니다"라는 문구는 결과에 아무런 도움이 되지 않습니다.

로컬 실행이 정당화되는 경우와 경로를 변경하는 것이 더 나은 경우

로컬 Kandinsky 5 실행이 정당화되는 경우는 목적 자체가 환경에 대한 제어를 요구할 때입니다: 파이프라인 (pipeline) 조사, 재현 가능한 실험, 자체 스택으로의 통합, 또는 가중치 (weights)의 동작 검증 등이 이에 해당합니다. 이 경우 스모크 테스트 (smoke test)는 작업의 일부이지, 성가신 지연 요소가 아닙니다.

만약 로컬 런타임 (runtime)에 대한 조사가 아니라, 단 하나의 제한된 이미지 생성 작업이 필요한 것이라면 목적과 도구를 분리하는 것이 더 현명합니다. 호스팅된 (Hosted) 경로가 리포지토리 (repository)의 의존성 (dependencies) 문제를 해결하거나 이를 로컬 런타임으로 변환해 주지는 않지만, 현재 작업에서 해당 환경을 구축해야 하는 필요성을 제거해 줄 수 있습니다. 이러한 결과 검증을 위해 pro​​vod.ai를 사용할 수 있습니다.

주요 경계는 간단합니다: 종료된 이슈 (issue)는 읽어볼 만한 유용한 신호가 될 수 있지만, 로컬 실행 준비는 여러분의 최소 파이프라인 (pipeline)이 고정된 메모리 내에서 작은 생성 작업을 수행할 수 있는 단계에 도달했을 때 비로소 시작됩니다.

Карточка выбора между локальным smoke test и hosted-задачей

provod.ai — 러시아에서 결제 가능한 글로벌 AI 카탈로그

해외 은행 카드나 우회 결제 방식 없이 필요한 모델을 연결하세요: 러시아 플랫폼을 통해 접속이 가능하며, 잔액은 루블로 충전됩니다.

하나의 카탈로그에서 텍스트 및 미디어용 최신 모델을 만나보세요: 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에 따른 데이터 보호 · provod.ai 메인

당신의 다음 작업에서 무엇이 더 비용이 많이 드나요: 재현 가능한 로컬 스택 (local stack)을 구축하는 데 시간을 소비하는 것인가요, 아니면 제한된 작업에서 결과를 얻기 위해 이를 포기하는 것인가요?