FLUX 3 Image Klein vs FLUX 3 Image Klein Pup: โมเดลปะทะนักเขียนพรอมต์ของตัวเอง

ชื่อบนรีโพซิทอรีชวนให้เกิดการเปรียบเทียบที่ไม่มีอยู่จริง FLUX 3 Image Klein และ FLUX 3 Image Klein Pup ดูราวกับเป็นสองโมเดลในตระกูลเดียวกัน แบบเดียวกับหน้าคู่เปรียบเทียบ "vs" อื่น ๆ ทุกหน้าบนบล็อกนี้ที่จับคู่เครื่องสร้างภาพสองตัวซึ่งมีจุดแข็งต่างกัน แต่ทั้งสองไม่ใช่เช่นนั้น FLUX 3 Image Klein คือโมเดลภาพขนาด 5.6B ที่เปิดตัวเมื่อวันที่ 15 ตุลาคม 2026 ส่วน FLUX 3 Image Klein Pup — ซึ่งมีชื่อว่า "Prompt Upsampler" บนการ์ดโมเดล — เป็นโมเดลภาษาขนาด 9B ที่มีหน้าที่ทั้งหมดคือเขียนพรอมต์สั้น ๆ ของคุณใหม่ให้เป็นแคปชันยาวและละเอียดที่โมเดลภาพได้รับการฝึกมาให้รับ

ดังนั้นคำถามที่แท้จริงจึงไม่ใช่ว่าตัวไหนดีกว่า แต่คือตัวที่สองเป็นทางเลือกหรือไม่ Black Forest Labs บอกว่าไม่ใช่: การ์ดโมเดลระบุตรง ๆ ว่า Klein “ไม่ได้ถูกออกแบบมาให้ทำงานโดยไม่มี prompt upsampler อยู่ข้างหน้า” และการส่งพรอมป์แบบสั้นตามที่พิมพ์จะให้ผลลัพธ์แบบทั่วไป ข้อกล่าวอ้างนั้นคือสิ่งที่ควรตรวจสอบ เพราะการยอมรับมันจะเปลี่ยนงบหน่วยความจำ เวลาตอบสนอง ข้อผูกพันด้านใบอนุญาต และ — ในกรณีเฉพาะกรณีหนึ่ง — ความแม่นยำของการแก้ไขของคุณ

แต่ละตัวในสองตัวนี้คืออะไรกันแน่

การแยกนี้ชัดเจนกว่าที่ชื่อเรียกบ่งบอกไว้ โมเดลหนึ่งมีความสามารถด้านภาพ ส่วนอีกโมเดลหนึ่งไม่มี และมีเพียงโมเดลเดียวเท่านั้นที่แตะต้องพิกเซลจริง ๆ

• บทบาท — Klein สร้างและแก้ไขภาพ; Pup ส่งข้อความและไม่เรนเดอร์สิ่งใดเลย

• พารามิเตอร์ — 5.6B สำหรับเจเนอเรเตอร์, 9B สำหรับอัปแซมเพลอร์ ดังนั้นตัวช่วยจึงเป็นโมเดลที่ใหญ่กว่า

• ที่มา — Klein เป็นโมเดลภาพในสายของ FLUX 3 ส่วน Pup เป็นการไฟน์จูนแบบเต็มรูปแบบของ Qwen/Qwen3.5-9B ซึ่งพัฒนาต่อมาจาก Qwen3.5-9B-Base

• เวตบนดิสก์ — 11.2 GB ที่ BF16 และ 5.6 GB ที่ FP8 สำหรับ Klein; 18.8 GB สำหรับ safetensors ของ Pup ที่ BF16

• สัญญาอนุญาต — FLUX Kommunity License สำหรับ Klein พร้อมข้อกำหนดรายได้ 5 ล้านดอลลาร์; Apache 2.0 สำหรับ Pup

• ข้อมูลนำเข้า — Klein รับข้อความ รูปภาพอ้างอิง และกล่องขอบเขต; Pup รับคำขอเดียวกันพร้อมรูปภาพอ้างอิงสูงสุด 10 รูป และคืนพรอมต์หนึ่งรายการ

• ผลลัพธ์ — พิกเซลเทียบกับข้อความภาษาอังกฤษ

แถวสุดท้ายนั่นแหละคือแถวที่ผู้คนมักมองข้าม ภาษาที่ Pup ส่งออกเป็นภาษาอังกฤษเสมอ แม้คำขอที่ป้อนเข้ามาจะเป็นภาษาอื่นก็ตาม หากไปป์ไลน์ของคุณบันทึกพรอมต์เพื่อการตรวจสอบ พรอมต์ที่ผู้ตรวจสอบของคุณเห็นจะไม่ใช่พรอมต์ที่ผู้ใช้ของคุณพิมพ์

ตัวเลข 8 GB ไม่คงอยู่เมื่อผ่านไปป์ไลน์ค่าเริ่มต้น

ข้อกล่าวอ้างด้านฮาร์ดแวร์ที่เป็นจุดขายหลักสำหรับ Klein คือบิลด์ INT8 ทำงานบนการ์ด RTX ที่มี VRAM เพียง 8 GB ข้อกล่าวอ้างนั้นเกี่ยวกับตัวเจนเนอเรเตอร์ และเมื่อพิจารณาในเงื่อนไขของมันเอง ดูเหมือนว่าจะเป็นความจริง — เช็กพอยต์แบบควอนไทซ์ถูกสร้างมาเพื่อสิ่งนี้ และเวลาที่เผยแพร่พร้อมกันนั้นถูกวัดโดย NVIDIA

ตอนนี้เพิ่มไปป์ไลน์เริ่มต้นเข้าไป น้ำหนักของ Pup มีขนาด 18.8 GB ที่ BF16 ก่อนจะรวมโอเวอร์เฮดใด ๆ จากรันไทม์ คุณไม่สามารถใส่น้ำหนัก 18.8 GB ลงใน VRAM 8 GB ได้ ตัวเลขสองจำนวนนี้อธิบายสองสิ่งที่แตกต่างกัน และสื่อเปิดตัวได้วางตัวเลขทั้งสองไว้ใกล้กันมากพอที่ผู้อ่านจะสรุปได้อย่างสมเหตุสมผลว่าทั้งหมดทำงานบนการ์ดเก่า แต่ก็ไม่ใช่เช่นนั้น ไม่ใช่ในคอนฟิกูเรชันที่ BFL ระบุว่าโมเดลคาดหวัง

มีทางออกที่ซื่อสัตย์อยู่สามทาง และแต่ละทางมีต้นทุนที่แตกต่างกัน:

• ทำการควอนไทซ์อัปแซมเพลอร์ — มีบิลด์ GGUF จากคอมมูนิตี้สำหรับ Pup ในรูปแบบ Q8_0, Q5_K_M, IQ4_XS และ IQ3_S พร้อมตัวฉายภาพ (vision projector) แยกต่างหาก ซึ่งช่วยลดขนาดของตัวช่วยได้อย่างมาก โดยแลกกับคุณภาพของพรอมป์ที่ลดลงบ้าง

• รันตัวอัปแซมเปลอร์ที่อื่น — มันเป็นโมเดลข้อความ จึงไม่จำเป็นต้องใช้ GPU ร่วมกับตัวสร้าง เพียงแค่เชื่อมต่อผ่านเครือข่ายเท่านั้น

• ข้ามขั้นตอนนี้ด้วย --no-pup — ฟรี ทันที และเป็นตัวเลือกที่ BFL ไม่แนะนำ

การคำนวณหน่วยความจำเป็นสิ่งเดียวที่มีประโยชน์ที่สุดที่ควรทำความเข้าใจเกี่ยวกับการจับคู่นี้ และยังอธิบายคำร้องเรียนประเภทหนึ่งได้ด้วย: มีคนรายงานว่า Klein ทำงานช้าหรือไม่พอดี และสิ่งที่พวกเขากำลังรายงานจริง ๆ ก็คือพวกเขาได้รันไปป์ไลน์ตามที่ระบุไว้ในเอกสาร บนฮาร์ดแวร์ที่ถูกกำหนดขนาดมาสำหรับเวอร์ชันที่ตัดทอนลง

สิ่งที่ Pup ทำกับพรอมต์

มันขยายความออกมา คำขออย่าง “ชายคนหนึ่งเดินเล่นกับสุนัขของเขา แสงแดดยามบ่าย” จะกลายเป็นคำบรรยายฉากแบบเต็มรูปแบบที่ครอบคลุมตัวแบบ ฉาก แสง กล้อง และองค์ประกอบภาพ — การ์ดโมเดลอธิบายผลลัพธ์ว่าเป็นคำบรรยายยาวประมาณสองร้อยคำเมื่อตั้งค่าเป็นระดับกลาง จากนั้นโมเดลภาพจะใช้คำบรรยายนั้นเป็นเงื่อนไขแทนประโยคของคุณ

{{1}}นี่คือความสามารถจริง ไม่ใช่แค่ลูกเล่น โมเดลภาพแบบดิฟฟิวชันไวต่อความเฉพาะเจาะจงของพรอมต์ และพรอมต์ห้าคำทำให้การตัดสินใจด้านองค์ประกอบเกือบทั้งหมดขึ้นอยู่กับไพรเออร์ของโมเดล ตัวอัปแซมเปลอร์ทำให้การตัดสินใจเหล่านั้นชัดเจนและสม่ำเสมอ ซึ่งเป็นเหตุผลว่าทำไมเอาต์พุตจากไปป์ไลน์เริ่มต้นจึงดูตั้งใจมากกว่าเอาต์พุตจากเช็กพอยต์เดียวกันที่ป้อนประโยคดิบ{{/1}}{{2}}

นี่คือการสูญเสียการควบคุมเช่นกัน และการสูญเสียนั้นเงียบงัน ประโยคของคุณไม่ได้ถูกใส่คำอธิบายกำกับ — มันถูกแทนที่ ถ้าตัวอัปแซมเพลอร์ตัดสินใจว่าแสงยามบ่ายคือโกลเดนอาวเวอร์ และสุนัขคือบอร์เดอร์คอลลี ตัวสร้างก็ไม่มีทางรู้ว่าคุณไม่ได้หมายความเช่นนั้น สำหรับงานสำรวจ นั่นถือเป็นฟีเจอร์ สำหรับช็อตลิสต์ มันเป็นตัวแปรที่คุณไม่ได้ร้องขอ

สี่โหมด และเหตุใดโหมดจึงสำคัญกว่าพรอมต์

Pup ไม่ใช่โมเดลเดียวที่มีพฤติกรรมเดียว มันเลือก system prompt ตามงาน และมีอยู่สี่แบบ ได้แก่ text-to-image, image-to-image, text-to-image พร้อม bounding box และ image-to-image พร้อม bounding box การใช้โหมดผิดจะสร้างพรอมป์ที่เขียนได้ดีแต่สำหรับงานที่ผิด ซึ่งเป็นความล้มเหลวที่ดูเหมือนปัญหาคุณภาพของโมเดล แต่ไม่ใช่

การตั้งค่าการสุ่มตัวอย่างก็แตกต่างกันตามโหมดเช่นกัน และความแตกต่างนั้นไม่ใช่เรื่องผิวเผิน การถอดรหัสเป็นแบบ greedy ที่อุณหภูมิศูนย์ โดยมีโทเค็นใหม่สูงสุด 3,584 โทเค็น และปิดการคิดไว้ presence penalty คือ 1.5 สำหรับข้อความเป็นภาพ และ 0 สำหรับการแก้ไข การเป็นศูนย์นั้นตั้งใจไว้: บทลงโทษการซ้ำจะกระตุ้นให้โมเดลนำเนื้อหาใหม่เข้ามา ซึ่งเป็นสิ่งที่คุณไม่ต้องการเลยเมื่อหน้าที่คือการถ่ายทอดคำสั่งแก้ไขให้ตรงตามเดิมอย่างซื่อตรง ภาพอ้างอิงยังถูกปรับขนาดแตกต่างกันไปตามจำนวนที่คุณส่งมา — ประมาณ 1 เมกะพิกเซลสำหรับหนึ่งภาพ, 724² สำหรับสองภาพ, 512² สำหรับสามภาพขึ้นไป — ดังนั้นงานที่มีภาพอ้างอิงสิบภาพจึงใช้ภาพที่มีขนาดเล็กกว่างานที่มีภาพอ้างอิงหนึ่งภาพมากในการกำหนดเงื่อนไข

ใบอนุญาตถูกแบ่งครึ่งตรงกลาง

นี่คือส่วนที่แทบไม่ได้รับความสนใจและน่าจะควรได้รับความสนใจ สองครึ่งของไปป์ไลน์อยู่ภายใต้สัญญาอนุญาตที่แตกต่างกัน Klein ใช้ FLUX Kommunity License: ใช้งานเชิงพาณิชย์ได้ฟรีเมื่อรายได้ต่อปีต่ำกว่า 5 ล้านดอลลาร์ และต้องจ่ายค่าอนุญาตเมื่อเกินกว่านั้น Pup ใช้ Apache 2.0 โดยไม่มีเงื่อนไขเรื่องรายได้เลย

ดังนั้น บริษัทที่อยู่เหนือเกณฑ์สามารถใช้ prompt upsampler ได้อย่างอิสระ และยังต้องมีใบอนุญาตเพื่อใช้ generator ที่มันป้อนให้ และบริษัทที่อยู่ต่ำกว่าเกณฑ์ซึ่งต้องการ fine-tune ฝั่ง prompt ย่อมมีความยืดหยุ่นมากกว่าบริษัทที่ต้องการ fine-tune ฝั่ง image อย่างมาก หากคุณวางแผนจะปล่อยผลิตภัณฑ์ ควรอ่านใบอนุญาตทั้งสองฉบับแยกกัน แทนที่จะมอง "the Klein stack" เป็นสิ่งเดียว ครึ่งที่เป็น permissive คือครึ่งที่มองข้ามได้ง่าย

อะไรเปลี่ยนแปลงจริง ๆ เมื่อคุณปิดมัน

การปิด Pup ใช้เพียงแฟล็กเดียว และผลกระทบนั้นไม่สมมาตรกันในแต่ละงาน

• การสร้างภาพจากข้อความ — จุดที่ประสิทธิภาพลดลงมากที่สุด พรอมป์สั้นจะให้ผลลัพธ์แบบทั่วไป ซึ่งเป็นความล้มเหลวที่ BFL เตือนไว้อย่างแม่นยำ และยิ่งพรอมป์ของคุณสั้นลง ช่องว่างก็ยิ่งกว้างขึ้น

• Multi-reference — upsampler คือสิ่งที่เปลี่ยน "put these three people in a room" ให้กลายเป็นคำอธิบายที่ครอบคลุม reference ทั้งสามรายการ หากไม่มีมัน ความแม่นยำในการทำตาม reference จะหลวมขึ้นอย่างเห็นได้ชัด

• เลย์เอาต์แบบกล่องขอบเขต — โหมดนี้มีอยู่เพื่อแปลงเจตนาเชิงพื้นที่ให้เป็นคำบรรยายที่คงเจตนานั้นไว้ ดังนั้นการ移除มันออกจึงทำให้ภาระกลับไปอยู่ที่การเรียบเรียงถ้อยคำของคุณ

• การแก้ไขอย่างแม่นยำ — เป็นกรณีที่ชัดเจนน้อยที่สุด และเป็นกรณีที่การปิดการทำงานนี้อาจช่วยได้

หัวข้อสุดท้ายนั้นเป็นข้อที่ขัดกับสัญชาตญาณ และมันมาจากที่เดียวกับบทลงโทษการมีอยู่เป็นศูนย์ คำสั่งแก้ไขมักมีขอบเขตแคบ: เปลี่ยนวัตถุนี้ ย้ายองค์ประกอบนี้ ลบสิ่งนี้ หน้าที่ของตัวอัปแซมเปลอร์คือการขยาย ดังนั้นมันจึงขยายฉากรอบ ๆ คำสั่งของคุณเช่นเดียวกับตัวคำสั่งเอง เมื่อการแก้ไขเป็นแบบเฉพาะที่จริง ๆ การขยายบริเวณโดยรอบนั้นอย่างดีที่สุดก็เป็นเพียงสัญญาณรบกวน เมื่อมันขัดแย้งกับบางสิ่งในเฟรม มันก็ยิ่งแย่กว่าสัญญาณรบกวน

ประสบการณ์ของเราเองในการใช้ Klein กับงานแก้ไขเฉพาะจุด — การเปลี่ยนวัตถุหนึ่งชิ้น การย้ายองค์ประกอบไปยังพื้นที่ที่มีขอบเขต และการคงส่วนที่เหลือของเฟรมไว้ให้สมบูรณ์ — คือโมเดลจะน่าเชื่อถือที่สุดในโหมดแคบ ๆ นี้พอดี ซึ่งทำให้คำถามเรื่องอัปแซมเพลอร์คมชัดขึ้นแทนที่จะผ่อนลง: งานที่ตัวสร้างทำได้แข็งแกร่งที่สุดก็เป็นงานที่การขยายของตัวช่วยเป็นสิ่งที่พึงปรารถนาน้อยที่สุดเช่นกัน ทดสอบทั้งสองการตั้งค่ากับพรอมป์แก้ไขของคุณเองก่อนตัดสินใจ นี่เป็นกรณีที่คำแนะนำแบบเหมารวมของผู้ขายและภาระงานเฉพาะของคุณอาจขัดแย้งกันได้อย่างสมเหตุสมผล

การตัดสินใจในทางปฏิบัติ

หากคุณเรียกใช้ vendor API แทนการดาวน์โหลดอะไรก็ตาม ส่วนใหญ่ของเรื่องนี้ก็ไม่มีความหมายอีกต่อไป endpoint แบบโฮสต์จะทำการอัปแซมเปิลพรอมป์ตและการฟื้นฟูพิกเซลด้วยตัวเองฝั่งเซิร์ฟเวอร์ ดังนั้นคุณจึงได้พฤติกรรมแบบพรอมป์ตที่ขยายแล้วนั้นอยู่แล้ว ไม่ว่าคุณจะคิดถึงมันหรือไม่ก็ตาม ทางเลือกนี้จะกลายเป็นเรื่องจริงจังก็ต่อเมื่อคุณเอาน้ำหนักโมเดลไปเท่านั้น

เมื่อคุณทำเช่นนั้น การแบ่งจะประมาณนี้ ให้ใช้ Pup ต่อไปหากพรอมป์ของคุณสั้น งานของคุณเป็นการสำรวจ หรือคุณกำลังสร้างมากกว่าการแก้ไข ทิ้งมันไป หรือรันบิลด์แบบควอนไทซ์ หากการ์ดของคุณเล็ก การแก้ไขของคุณแคบและตรงตัว หรือพรอมป์ของคุณยาวและเฉพาะเจาะจงพออยู่แล้วจนการขยายความส่วนใหญ่กลายเป็นการเพิ่มเนื้อหาที่แต่งขึ้นเอง ทำควอนไทซ์มันหากคุณต้องการทั้งสองอย่างและยอมรับการสูญเสียคุณภาพพรอมป์บางส่วนแลกกับการทำให้ทั้งไปป์ไลน์พอดีอยู่ในอุปกรณ์เดียว

หมายเหตุเชิงปฏิบัติข้อหนึ่งเกี่ยวกับการลองสิ่งนี้แบบประหยัด: สองครึ่งล้มเหลวอย่างเป็นอิสระต่อกัน และ routing layer เป็นวิธีปกติในการหลีกเลี่ยงการเดิมพันเส้นทางโปรดักชันกับ endpoint เดียว OrcaRouter ให้บริการ API เดียวที่เข้ากันได้กับ OpenAI ครอบคลุมโมเดล 200+ โมเดล ด้วย markup 0% — ราคาตามรายการของผู้ให้บริการถูกส่งผ่านไปโดยไม่เปลี่ยนแปลง — และมี failover อัตโนมัติข้ามผู้ให้บริการ ดังนั้น endpoint ที่เสื่อมประสิทธิภาพจะไม่กลายเป็นงานที่ล้มเหลว สิ่งนี้ไม่ช่วยคุณกับ Klein เอง ซึ่งไม่อยู่ในแคตตาล็อก 210 โมเดลของเรา และไม่ใช่สิ่งที่เราให้บริการ สำหรับไปป์ไลน์นี้ น้ำหนักโมเดลและ API ของผู้ขายคือเส้นทาง ส่วนข้อพิจารณาเรื่อง routing มีความสำคัญกับโมเดลที่คุณวางไว้รอบ ๆ มัน

อะไรจะเปลี่ยนคำตอบ

การทดลองแบบ ablation ที่ได้รับการเผยแพร่แล้ว ยังไม่มีใครเปิดเผยการเปรียบเทียบแบบเคียงข้างกันของ Klein ที่มีและไม่มี Pup บนพรอมป์ต์เดียวกัน โดยมีผู้ให้คะแนนที่ไม่ใช่ห้องแล็บ และตารางที่หายไปเพียงตารางเดียวนั้นคือสิ่งที่ทำให้เรื่องนี้ยังเป็นการตัดสินใจด้วยดุลยพินิจ จนกว่าตารางนั้นจะมีอยู่ จุดยืนที่ป้องกันได้คือจุดยืนที่ไม่อลังการ: ตัวอัปแซมเปลอร์เป็นส่วนหนึ่งของระบบตามที่ออกแบบไว้ คำกล่าวอ้างเรื่อง 8 GB ไม่ได้ครอบคลุม它包括 และภาระงานเดียวที่คุณอาจมีเหตุผลพอที่จะแทนที่ค่าเริ่มต้น คือภาระงานที่โมเดลนี้แข็งแกร่งที่สุด