FLUX 3 Image Klein vs FLUX 3 Image Klein Pup: 자신의 프롬프트 작성자와 맞붙은 모델

저장소의 이름은 존재하지 않는 비교를 유도한다. FLUX 3 Image Klein과 FLUX 3 Image Klein Pup은 마치 한 제품군의 두 모델처럼 보인다. 이 블로그의 다른 모든 "vs" 페이지가 서로 다른 강점을 지닌 두 생성기를 짝지어 소개하는 방식처럼. 그러나 그렇지 않다. FLUX 3 Image Klein은 2026년 10월 15일에 출시된 5.6B 이미지 모델이다. 모델 카드에서 "Prompt Upsampler"라는 제목이 붙은 FLUX 3 Image Klein Pup은 9B 언어 모델로, 그 존재 목적 전체는 사용자의 짧은 프롬프트를 이미지 모델이 학습 과정에서 입력받도록 훈련된 길고 상세한 캡션으로 다시 쓰는 것이다.

그래서 진짜 질문은 어느 쪽이 더 나은가가 아니다. 두 번째 것이 선택 사항인지 여부다. Black Forest Labs는 그렇지 않다고 말한다. 모델 카드에는 Klein이 "앞단에 프롬프트 업샘플러 없이 실행되도록 만들어진 것이 아니며", 입력한 그대로 보낸 짧은 프롬프트는 일반적인 출력을 낸다고 분명히 명시되어 있다. 그 주장이 검토해 볼 가치가 있는 이유는, 그것을 받아들이면 메모리 예산, 지연 시간, 라이선스 의무, 그리고 한 가지 특정한 경우에는 편집의 정밀도까지 달라지기 때문이다.

둘 각각이 실제로 무엇인지

이 구분은 이름이 암시하는 것보다 더 명확하다. 한 모델은 비전을 갖고 있고 다른 모델은 그렇지 않으며, 둘 중 하나만 픽셀을 건드린다.

• 역할 — Klein은 이미지를 생성하고 편집하며, Pup은 텍스트를 출력할 뿐 아무것도 렌더링하지 않습니다

• 매개변수 — 생성기 5.6B, 업샘플러 9B이므로 헬퍼가 더 큰 모델입니다

• 계보 — Klein은 FLUX 3 계보의 이미지 모델이고, Pup은 Qwen/Qwen3.5-9B의 전체 파인튜닝이며, Qwen/Qwen3.5-9B 자체는 Qwen3.5-9B-Base에서 파생되었습니다.

• 디스크상 가중치 — Klein은 BF16에서 11.2GB, FP8에서 5.6GB; Pup의 safetensors는 BF16에서 18.8GB

• 라이선스 — Klein용 FLUX Kommunity License($5M 매출 기준 포함), Pup용 Apache 2.0

• 입력 — Klein은 텍스트, 참조 이미지, 경계 상자를 받습니다. Pup은 동일한 요청에 최대 10개의 참조 이미지를 더해 받고 하나의 프롬프트를 반환합니다.

• 출력 — 픽셀 대 영어 텍스트

마지막 행은 사람들이 놓치는 부분입니다. Pup의 출력 언어는 입력 요청이 다른 언어로 되어 있더라도 항상 영어입니다. 파이프라인이 검토를 위해 프롬프트를 기록한다면, 검토자가 보는 프롬프트는 사용자가 입력한 프롬프트가 아닙니다.

8GB라는 숫자는 기본 파이프라인을 거치면 유지되지 않습니다

Klein의 하드웨어 관련 핵심 주장은 INT8 빌드가 8GB의 VRAM만 갖춘 RTX 카드에서 실행된다는 것입니다. 이 주장은 생성기에 관한 것이며, 그 자체로 보면 타당해 보입니다. 양자화된 체크포인트가 이를 위해 만들어졌고, 함께 공개된 타이밍은 NVIDIA가 측정한 것이기 때문입니다.

이제 기본 파이프라인을 추가하세요. Pup의 가중치는 런타임 오버헤드가 붙기 전 BF16 기준 18.8GB입니다. 18.8GB의 가중치를 8GB VRAM에 넣을 수는 없습니다. 두 숫자는 서로 다른 것을 설명하며, 릴리스 자료는 두 숫자를 충분히 가까이 배치해 독자가 이 전체가 구형 카드에서 실행된다고 합리적으로 결론 내릴 수 있게 합니다. 그렇지 않습니다. BFL이 모델에 기대한다고 말하는 구성에서는 말이죠.

정직하게 빠져나갈 방법은 세 가지이며, 그 대가는 각기 다릅니다:

업샘플러를 양자화하세요 — Pup용 커뮤니티 GGUF 빌드는 Q8_0, Q5_K_M, IQ4_XS, IQ3_S 변형으로 존재하며 별도의 비전 프로젝터를 갖추고 있어, 프롬프트 품질을 어느 정도 희생하는 대신 헬퍼를 상당히 축소합니다

• 업샘플러를 다른 곳에서 실행하세요 — 텍스트 모델이므로 생성기와 GPU를 공유할 필요가 없고, 네트워크 홉 하나만 있으면 됩니다.

• --no-pup으로 건너뛰세요 — 무료이고 즉시 적용되지만, BFL이 권장하지 않는 옵션입니다

메모리 계산법은 이 조합에 대해 이해해야 할 것 중 가장 유용한 단일 항목입니다. 이는 또한 한 갈래의 불만이 왜 생기는지도 설명해 줍니다. 누군가 Klein이 느리거나 맞지 않는다고 보고할 때, 그들이 실제로 보고하는 것은 축소된 버전에 맞춰진 하드웨어에서 문서에 나온 파이프라인을 실행했다는 사실입니다.

Pup이 프롬프트에 하는 일

확장됩니다. "개와 함께 걷는 남자, 오후의 햇살" 같은 요청이 피사체, 배경, 조명, 카메라, 구도를 모두 아우르는 전체 장면 캡션이 됩니다. 모델 카드는 중간 설정에서 대략 수백 단어 분량의 긴 캡션이 출력된다고 설명합니다. 그러면 이미지 모델은 여러분의 문장이 아니라 그 캡션을 조건으로 삼습니다.

이것은 실제 기능이지 단순한 속임수가 아닙니다. 확산 스타일 이미지 모델은 프롬프트의 구체성에 민감하며, 다섯 단어짜리 프롬프트는 거의 모든 구성 결정을 모델의 사전 지식에 맡깁니다. 업샘플러는 그러한 결정을 명시적이고 일관되게 내리므로, 기본 파이프라인의 출력이 동일한 체크포인트에 원문 문장을 그대로 입력했을 때의 출력보다 더 의도적으로 보이는 것입니다.

그것은 또한 통제력의 상실이며, 그 상실은 조용히 일어난다. 당신의 문장에는 주석이 달리지 않는다 — 그저 대체된다. 업샘플러가 오후의 빛을 골든 아워로, 개를 보더 콜리로 판단하면, 생성기는 당신이 그런 뜻이 아니었다는 것을 알 방법이 없다. 탐색적 작업에서는 그것이 기능이다. 샷 리스트에서는 그것은 당신이 요청하지 않은 변수다.

네 가지 모드, 그리고 프롬프트보다 모드가 더 중요한 이유

Pup은 하나의 동작만 가진 단일 모델이 아닙니다. Pup은 작업에 따라 시스템 프롬프트를 선택하며, 그 종류는 네 가지입니다: 텍스트-투-이미지, 이미지-투-이미지, 바운딩 박스를 사용하는 텍스트-투-이미지, 바운딩 박스를 사용하는 이미지-투-이미지입니다. 잘못된 모드를 선택하면 잘못된 작업에 대해 잘 작성된 프롬프트가 생성되는데, 이는 모델 품질 문제처럼 보이지만 실제로는 그렇지 않은 실패입니다.

샘플링 설정도 모드에 따라 달라지며, 그 차이는 단순한 겉모습이 아닙니다. 디코딩은 온도 0에서 그리디 방식으로 이루어지고, 최대 3,584개의 새 토큰으로 제한되며 사고 기능은 비활성화됩니다. 존재 패널티는 텍스트-이미지의 경우 1.5, 편집의 경우 0입니다. 그 0은 의도된 것입니다: 반복 패널티는 모델이 새로운 소재를 도입하도록 유도하는데, 이는 편집 지시를 충실히 다시 말하는 것이 작업일 때 정확히 원하지 않는 일입니다. 참조 이미지도 몇 장을 제공하느냐에 따라 다르게 크기가 조정됩니다 — 한 장이면 약 1메가픽셀, 두 장이면 724², 세 장 이상이면 512² — 따라서 참조 이미지 10장 작업은 참조 이미지 1장 작업보다 훨씬 작은 이미지에 조건화됩니다.

라이선스는 정확히 반으로 나뉩니다.

거의 주목받지 못하지만, 아마 주목받아야 할 부분입니다. 파이프라인의 두 축은 서로 다른 라이선스 아래에 있습니다. Klein은 FLUX Kommunity License입니다. 연간 매출 500만 달러 미만이면 상업적 사용이 무료이고, 그 이상이면 유료 라이선스가 필요합니다. Pup은 Apache 2.0으로, 매출 조건이 전혀 없습니다.

따라서 기준치를 넘는 회사는 프롬프트 업샘플러를 자유롭게 사용할 수 있지만, 그것이 입력을 공급하는 제너레이터를 사용하려면 여전히 라이선스가 필요합니다. 그리고 기준치 미만인 회사가 프롬프트 쪽을 미세 조정하려는 경우에는 이미지 쪽을 미세 조정하려는 회사보다 훨씬 더 큰 재량을 갖습니다. 출시를 계획하고 있다면 'Klein 스택'을 하나의 대상으로 취급하지 말고 두 라이선스를 별도로 읽으십시오. 허용적인 절반은 간과하기 쉬운 절반입니다.

그것을 끄면 실제로 무엇이 바뀌나요?

Pup을 끄는 것은 플래그 하나이며, 그 효과는 작업마다 비대칭적입니다.

• {{1}}텍스트-투-이미지{{/1}} — {{2}}가장 큰 성능 저하입니다. 짧은 프롬프트는 평범한 결과로 흐르는데, 이는 바로 BFL이 경고하는 실패이며, 프롬프트가 짧을수록 그 격차는 더 벌어집니다{{/2}}

• 멀티 레퍼런스 — 업샘플러는 "이 세 사람을 한 방에 배치해 줘"라는 요청을 세 레퍼런스 모두를 반영하는 설명으로 바꿔 주는 역할을 합니다. 이것이 없으면 레퍼런스 준수도가 눈에 띄게 느슨해집니다.

• 바운딩 박스 레이아웃 — 이 모드는 공간적 의도를 그대로 보존하는 캡션으로 변환하기 위해 존재하므로, 이를 제거하면 그 부담은 다시 문구 작성 쪽으로 돌아갑니다.

• 정밀 편집 — 가장 애매한 사례이자, 이를 끄면 도움이 될 수 있는 경우

그 마지막 불릿은 직관에 반하는 항목이며, 프레즌스 패널티 0과 같은 근원에서 나옵니다. 편집 지시는 대개 범위가 좁습니다. 이 객체를 바꾸고, 이 요소를 옮기고, 이것을 제거하라는 식이죠. 업샘플러의 역할은 확장이므로, 지시 자체는 물론 지시 주변의 장면까지 확장합니다. 편집이 진정 국소적일 때, 그 주변 확장은 기껏해야 노이즈입니다. 프레임 안의 무언가와 모순될 때는 노이즈보다 더 나쁩니다.

Klein을 국소 편집—객체 하나를 바꾸고, 요소를 경계가 정해진 영역으로 옮기고, 나머지 프레임은 그대로 유지하는—에 실행해 본 우리 경험에 따르면, 모델은 바로 이런 좁은 모드에서 가장 설득력 있습니다. 이는 업샘플러 질문을 완화하기는커녕 더 날카롭게 만듭니다. 생성기가 가장 강력한 작업이 바로 도우미의 확장이 가장 환영받지 못하는 작업이기 때문입니다. 결정하기 전에 자신의 편집 프롬프트에서 두 설정을 모두 테스트하세요. 공급업체의 일률적인 조언과 여러분의 특정 작업 부하가 정당하게 상충할 수 있는 사례입니다.

실제 상황에서의 결정

무언가를 다운로드하는 대신 벤더 API를 호출하고 있다면, 이 대부분은 논외입니다. 호스팅된 엔드포인트는 서버 측에서 자체적인 프롬프트 업샘플링과 픽셀 복원을 적용하므로, 생각하든 하지 않든 이미 확장된 프롬프트 동작을 사고 있는 셈입니다. 이 선택은 가중치를 직접 가져올 때만 비로소 실질적인 의미를 갖습니다.

그렇게 할 때 대략 이렇게 나뉩니다. 프롬프트가 짧거나, 작업이 탐색적이거나, 편집보다 생성 위주라면 Pup을 유지하세요. 카드가 작거나, 편집 범위가 좁고 문자 그대로라면, 또는 프롬프트가 이미 충분히 길고 구체적이어서 확장이 주로 새로운 내용을 더하는 데 그친다면 Pup을 버리거나 양자화 빌드를 실행하세요. 둘 다 원하면서 전체 파이프라인을 한 기기에 맞추는 대가로 약간의 프롬프트 품질 저하를 감수할 수 있다면 양자화하세요.

값싸게 시도할 때 실무적으로 한 가지 참고하자면, 두 절반은 서로 독립적으로 실패하며, 라우팅 계층은 프로덕션 경로를 단일 엔드포인트에 거는 일을 피하는 일반적인 방법입니다. OrcaRouter는 200개 이상의 모델에 대해 0% 마크업으로 하나의 OpenAI 호환 API를 제공하며, 공급자의 정가가 그대로 전달되고, 공급자 간 자동 페일오버를 지원하므로 성능이 저하된 엔드포인트가 실패한 작업이 되지는 않습니다. 다만 이는 Klein 자체에는 도움이 되지 않습니다. Klein은 당사의 210개 모델 카탈로그에 없고, 저희가 제공하는 대상도 아닙니다. 이 파이프라인에서는 가중치와 벤더 API가 경로이며, 라우팅에 대한 논의는 그 주변에 두는 모델에 해당하는 이야기입니다.

답을 바꾸는 것은 무엇인가?

공개된 절제 실험(ablation)이 하나 있다. 같은 프롬프트에서 Pup이 있는 Klein과 없는 Klein을 나란히 비교하고, 해당 연구실이 아닌 누군가가 채점한 결과를 공개한 사람은 아무도 없으며, 바로 그 단 하나의 빠진 표 때문에 이것은 여전히 판단에 맡길 수밖에 없는 사안으로 남는다. 그 표가 존재하기 전까지 방어 가능한 입장은 매력 없고 소박한 쪽이다: 업샘플러는 설계된 그대로 시스템의 일부이고, 8 GB 주장은 이를 포함하지 않으며, 기본값을 합리적으로 우회할 수 있는 유일한 워크로드는 바로 이 모델이 가장 강력한 워크로드다.