วิธีใช้ MiniMax H3: พรอมpt, การรันในเครื่อง และเสียงที่ไม่แย่

เมื่อวันที่ 4 สิงหาคม Simon Willison ดาวน์โหลดน้ำหนักโมเดลประมาณ 115 GB ชี้พอร์ต MLX ที่ไม่เป็นทางการของ MiniMax H3ไปที่ MacBook Pro M5 Max ของเขา และขอภาพสกั๊งก์สีรุ้งกระโดดข้ามท่อนไม้ที่มีตะไคร่น้ำในซูเปอร์มาร์เก็ต หลังจากนั้นไม่ถึง 45 นาที เขาก็ได้คลิปที่เขาบรรยายว่าน่าประทับใจอย่างแท้จริง — พร้อมแทร็กเสียงที่เขาบรรยายว่าแปลกเหมือนเสียงพูดที่ไม่เป็นภาษา การวินิจฉัยของเขาเองคือส่วนที่มีประโยชน์: เขาไม่ได้ให้ทิศทางด้านเสียงใดๆ แก่โมเดล และไม่ได้อ่านคู่มือการป้อนคำสั่งก่อน นั่นคือบทสรุปที่สั้นที่สุดเท่าที่จะเป็นไปได้ว่าการเริ่มใช้ H3 ซึ่งจำหน่ายในชื่อ Hailuo 3.0 ด้วยนั้นเป็นอย่างไร ภาพมาแบบแทบไม่ต้องพยายาม ทุกอย่างอื่น — เสียง จังหวะการถ่ายทำ ความละเอียด 2K ตัวละครที่ต้องอยู่รอดให้ได้สี่ช็อตติดต่อกัน — คุณต้องขออย่างชัดเจน ในรูปแบบที่เข้มงวดกว่าโมเดลวิดีโออื่นๆ เกือบทั้งหมดที่ใช้งานอยู่ในตอนนี้

นี่คือคู่มือการใช้งาน ไม่ใช่รายงานข่าวการเปิดตัว แหล่งข้อมูลสามระดับถูกใช้ตลอดทั้งเอกสาร และมีการระบุกำกับทุกครั้ง: เอกสารของบริษัทเอง (model card, คู่มือการเขียนพรอมต์สองฉบับที่แนบมากับ repository, เอกสาร API ของแพลตฟอร์ม); ข้อค้นพบจากชุมชน จากผู้ที่ได้ใช้งานจริง — ผู้ดูแล ComfyUI, นักวัดผลอิสระ, เอกสารจากผู้จำหน่ายต่อ และกระทู้สนทนาบน Hugging Face, ทั้งหมดมีวันที่ระหว่าง 31 กรกฎาคม ถึง 5 สิงหาคม 2026; และอีกจำนวนไม่กี่จุดที่เราอ่านไฟล์ต้นฉบับด้วยตัวเองและระบุไว้เช่นนั้น ตัวเลขจากชุมชนเป็นการรายงานจากแหล่งเดียวบนฮาร์ดแวร์ที่ไม่มีการควบคุม เว้นแต่จะระบุไว้เป็นอย่างอื่น ในจุดที่ผู้ใช้งานไม่เห็นพ้องกัน จะรายงานความขัดแย้งนั้นไว้แทนที่จะตัดสินชี้ขาด

ก่อนอื่นเลย: คุณอาจจะไม่ได้รันโมเดลทั้งตัว

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

• H3-Context-IR — ตัวประมวลผลคำสั่งแบบมัลติโมดัล อ่านข้อความ รูปภาพ เสียง และวิดีโอของคุณ วิเคราะห์ความสัมพันธ์ระหว่างข้อมูลเหล่านี้ แล้วส่งออกเป็นตัวแทนเชิงโครงสร้างและเสริมความหมายของสิ่งที่คุณร้องขอ ให้บริการผ่าน API แบบโฮสต์เท่านั้น โดยเปิดให้ใช้งานเป็นประเภทงานเฉพาะของตัวเอง ซึ่งส่งคืนพรอมต์ที่ได้รับการเสริมแต่ง และไม่มีวิดีโอใด ๆ เลย

• H3-Base — โมเดลเจนเนอเรทีฟขนาด 33B พารามิเตอร์ที่สร้างเฟรมและเสียงได้จริง นี่คือส่วนที่เปิดเผยน้ำหนัก

• H3-Regenerate-2K — การสร้างใหม่ในบริบทที่นำผลลัพธ์ 768p ไปสู่ความละเอียด 2K เฉพาะ API แบบโฮสต์เท่านั้น

ผลที่ตามมาสองประการเกิดขึ้นทันที และมันเป็นตัวกำหนดขั้นตอนการทำงานทั้งหมดของคุณ. ประการแรก, การสร้างภาพในเครื่องมีเพดานอยู่ที่ 768p. H3 มีขนาดผืนผ้าใบพื้นฐานที่ขอบสั้น 768 พิกเซล จำกัดไว้ที่ 768×1344 — ซึ่งคร่าวๆ คือ 1344×768 สำหรับ 16:9. ถ้าผลลัพธ์ ComfyUI ของคุณไม่ใช่ 2K ไม่ได้มีอะไรเสียหาย แพ็กเกจที่คุณดาวน์โหลดมาคือ H3-Base และโมดูลอัปสเกลไม่ได้อยู่ในนั้น ประการที่สอง, API แบบโฮสต์จะแก้พรอมป์ที่เลอะเทอะ แต่การติดตั้งในเครื่องของคุณจะไม่ทำ. ทุกอย่างที่ Context-IR ทำสำหรับการเรียก API แบบเสียเงิน — การอนุมานโครงสร้าง การตีความว่าการอ้างอิงใดหมายถึงอะไร การเติมเต็มส่วนที่คุณปล่อยไว้คลุมเครือ — คือขั้นตอนที่ตอนนี้คุณต้องทำด้วยมือ หรือใช้โมเดลอื่น ก่อนที่ H3-Base จะได้เห็นข้อความของคุณ ความไม่สมมาตรเพียงข้อเดียวนี้ อธิบายรายงานส่วนใหญ่ที่ว่า "พรอมป์เดียวกันใช้ได้บน Hailuo แต่ดูพังใน ComfyUI."

ควรสังเกตจากตัว repository เอง: น้ำหนักโมเดลมีminimax-h3-community-license-agreementเป็นแท็กแทนที่จะเป็น Apache หรือ MIT (รายละเอียดเพิ่มเติมด้านล่าง เพราะมันคือส่วนที่กำหนดว่าคุณจะสามารถเผยแพร่ได้หรือไม่) โมเดลถูกระบุว่ามีพารามิเตอร์ 33B ใน F32/BF16 และ ณ วันนี้ มีผู้ให้บริการอินเฟอเรนซ์เพียงรายเดียวคือ fal ที่ระบุว่าให้บริการโมเดลนี้ มีฟินจูน 23 รายการ, ควอนไทซ์ 20 รายการ และ Spaces 31 รายการอยู่บนโมเดลนี้แล้ว ซึ่งเป็นสัญญาณที่บ่งบอกได้ดีว่าชุมชนเคลื่อนไหวเร็วแค่ไหน

รูปแบบพรอมต์: บล็อกช็อต ไม่ใช่ไทม์โค้ด

นี่คือจุดที่ชุมชนและเอกสารขัดแย้งกันอย่างเปิดเผย และมันสำคัญมากกว่าสิ่งอื่นใดในบทความนี้

เทมเพลตที่แพร่เร็วที่สุด — ผ่าน Reddit แล้วก็ถูกนำไปใช้ในคู่มือตีพิมพ์หลายฉบับ — แบ่งคลิปออกเป็นช่วงเวลาไทม์โค้ด: [0s-2s], [2s-5s]และอื่นๆ ตามด้วยโครงสร้างหกส่วน ได้แก่ ข้อกำหนดสไตล์ ไทม์ไลน์ กล้อง เสียง ข้อความที่เขียนชัดเจน และรายการต้องห้าม เทมเพลตนี้ถูกย้อนวิศวกรรมโดยการอ่านตัวอย่างพรอมต์ 45 ตัวอย่างที่บริษัทส่งมา และมันไม่ใช่เรื่องไร้สาระ: ตัวอย่างเหล่านั้นจริงๆ แล้วเป็นรายการช็อตที่มาพร้อมกับแผ่นคิวเสียง โดยมีความยาวมัธยฐานประมาณ 130 ตัวอักษรจีน และอันที่ยาวที่สุดยาวถึง 657 และ 858 ตัวอักษร

แต่ของบริษัทเอง VIDEO_PROMPT_WRITING_GUIDE_base_en.md ซึ่งอยู่ในโฟลเดอร์docs ของ repository ระบุสิ่งที่แตกต่างออกไป โดยจัดระเบียบตามบล็อกช็อต ไม่ใช่ตามช่วงเวลา เราอ่านมันโดยตรง โครงสร้างที่มันต้องการคือ:

• คำแนะนำ — กฎการจัดตำแหน่งภาพ ใช้สำหรับโหมดคีย์เฟรม (I2VA, FL2VA, L2VA) และละเว้นสำหรับการสร้างวิดีโอจากข้อความล้วน

• integrated_multimodal_description — ส่วนหลัก แบ่งออกเป็น [Shot 1], [Shot 2], และอื่นๆ.

• overall_soundscape — หนึ่งถึงสี่ประโยคของเสียงไดเจติก

• ดนตรีนอกเรื่อง — บทบรรยายหนึ่งถึงสามประโยคสำหรับดนตรีประกอบ

ภายในนั้น ธรรมเนียมปฏิบัติมีความเฉพาะเจาะจงเพียงพอที่จะตรวจสอบได้ [Shot 1] ไม่มีการระบุเวลาใดๆ เลย — ช็อตต่อๆ ไปจะเปิดด้วยการตัดแบบ absolute cut โดยใช้ถ้อยคำเช่น "At 00:03.500, the camera cuts to…" การเคลื่อนกล้องเขียนโดยระบุชนิดการเคลื่อนที่ แอมพลิจูด และความเร็ว สอดแทรกเข้าไปในภาษาอังกฤษที่เป็นธรรมชาติแทนที่จะเขียนเรียงเป็นป้ายกำกับ เช่น การดันกล้องเข้าช้าๆ แบบแอมพลิจูดน้อย ไม่ใช่ camera: dolly-in, slow. การเคลื่อนที่ที่มีให้เลือกคือชุดที่คุ้นเคย — zoom, pan, tilt, tracking, arc, POV และ shake ในรูปแบบที่เบาหรือแรง บทสนทนาจะถูกครอบด้วยแท็ก: <d>[English] Get in the car.</d>, โดยเก็บเครื่องหมายวรรคตอนไว้ตรงตามต้นฉบับ และจะไม่มีการแปลหรือถอดความ ผู้พูดจะได้รับ ID ที่คงที่ — (S1), (S2) และ (S1,S2) สำหรับบทพูดร่วม — โดยระบุอายุ เพศ ลักษณะเสียง และสำเนียงเมื่อปรากฏตัวครั้งแรก เสียงพากย์ถูกระบุเป็นบทพูดนอกจอพร้อมหมายเหตุชัดเจนว่าริมฝีปากต้องปิดสนิท ซึ่งเป็นวิธีที่ใช้หยุดไม่ให้โมเดลขยับริมฝีปากตามเสียงบรรยายบนใบหน้า บทสนทนาแบบสลับฉากใช้ <scenetrans> มาร์กเกอร์พร้อมกับข้อความระบุความต่อเนื่อง.

ข้อห้ามที่คู่มือระบุไว้อย่างชัดเจนนั้นให้ข้อมูลได้ไม่แพ้กฎเกณฑ์ของตัวคู่มือเอง: ห้ามใส่ไทม์สแตมป์ในช็อตแรก ห้ามทำซ้ำบทสนทนา เสียงร้อง หรือเพลงที่ปรากฏในฉากภายใน overall_soundscape ห้ามใช้คำบอกอารมณ์เชิงนามธรรมใน non_diegetic_music และห้ามเขียนบทสนทนาท่อนใดใหม่เด็ดขาด และสิ่งที่ขาดหายไปอย่างน่าสังเกต — คู่มือทางการไม่มีส่วนของ negative-prompt เลย ซึ่งหมายความว่ารายการ "การเปลี่ยนภาพต้องห้าม" ในเทมเพลตชุมชนยอดนิยมเป็นสิ่งที่ชุมชนคิดค้นขึ้นเอง ไม่ใช่ฟีเจอร์ที่มีบันทึกไว้อย่างเป็นทางการ

ควรให้ความสำคัญกับความขัดแย้งนี้มากแค่ไหน? ในการสนทนาบน Hugging Face ในคลังเก็บ H3 สมาชิกชุมชนคนหนึ่งโพสต์โครงสร้างแบบ timecode ไว้เป็นแนวทาง และผู้ปฏิบัติอีกคนตอบอย่างตรงไปตรงมาว่าพวกเขาเคยใช้โครงสร้างคล้ายกัน มันผิดทั้งหมด และผู้คนควรอ่านคู่มือที่มาพร้อมกับตัวผลิตภัณฑ์แทน นั่นคือบุคคลหนึ่งขัดแย้งกับอีกบุคคลหนึ่ง ไม่ใช่การตัดสินใจของผู้ดูแล การอ่านหลักฐานของเราคือ: ทั้งสองวิธีทำงานผ่าน API ที่โฮสต์ไว้ เนื่องจาก Context-IR ปรับสิ่งที่คุณส่งไปให้เป็นมาตรฐาน มีเพียงรูปแบบที่ระบุไว้ในเอกสารเท่านั้นที่เชื่อถือได้เมื่อใช้กับ H3-Base โดยตรง หากคุณรันด้วยน้ำหนักของโมเดลในเครื่อง ให้ปฏิบัติตามไฟล์ในที่เก็บโค้ด หากคุณใช้ API และพรอมป์แบบ timecode ได้คลิปที่ดี ตัวประมวลผลล่วงหน้าคือคนทำงานนั้นให้คุณ และคุณไม่ควรสรุปว่ารูปแบบคือสิ่งที่ทำให้ได้ผลลัพธ์

การเรียบเรียงบรีฟแบบคร่าวๆ ให้เป็นภาษาถิ่นของ H3

ใช้พรอมต์สิบสองคำของวิลลิสันเป็นอินพุต — สกังก์สีรุ้งกระโดดข้ามท่อนไม้ที่ปกคลุมด้วยมอสส์ในซูเปอร์มาร์เก็ต เมื่อเขียนตามวิธีที่บันทึกไว้ ก็จะได้ประมาณ: [Shot 1] บล็อกที่เปิดด้วยการระบุสไตล์ (ไลฟ์แอ็กชัน, การถือกล้องด้วยมือ, แสงนีออน) และเฟรม (ทางเดินในซูเปอร์มาร์เก็ต, ท่อนไม้ที่ปกคลุมด้วยมอสส์วางขวางพื้นลิโนเลียม, ชั้นวางของที่ลดหลั่นไปด้านหลัง) จากนั้นจึงระบุตัวแบบและการกระทำตามลำดับทางกายภาพ — การก้าวเตรียมสองก้าว, การย่อตัว, การกระโดด, การลงสู่พื้น — โดยให้กล้องเคลื่อนแบบติดตามอย่างช้าๆ ด้วยแอมพลิจูดต่ำ ซึ่งจบลงที่อีกฟากหนึ่งของท่อนไม้; overall_soundscape ของเสียงกรงเล็บบนพื้นลิโนเลียม, เสียงครูดชื้นๆ ของท่อนไม้, เสียงฮัมของระบบทำความเย็น และเสียงล้อรถเข็นที่อยู่ไกล; และ non_diegetic_music ซึ่งเป็นบรรทัดของคิวเพลงสั้นๆ เบาๆ ที่ได้จากการดีดเครื่องสาย ไม่มีเสียงร้อง ไม่มีอะไรในนั้นที่เป็นความอัจฉริยะเชิงสร้างสรรค์ มันคือแนวคิดเดียวกัน แต่มีสี่สิ่งที่ H3 ต้องการให้ใส่เข้าไปจริงๆ ครบถ้วน — และนี่คือความแตกต่างระหว่าง room tone ที่ไม่มีใครขอ กับซาวด์แทร็กที่คุณออกแบบขึ้นมา

ขั้นตอนนี้เป็นงานที่ทำแบบกลไก ซ้ำซาก และไม่คุ้มค่าที่จะให้คนมาทำ ซึ่งเป็นเหตุผลที่บริษัทปล่อยเครื่องมือสำหรับงานนี้ออกมา แต่แทบไม่มีสื่อรายงานถึงเลย ตัว repository มีไดเรกทอรีที่ชื่อว่า skills ซึ่งรวบรวม agent skills เก้าอย่าง และอันแรก — h3-prompt-writing — ทำสิ่งนี้ได้พอดี: มันรับคำขอแล้วเขียน H3 prompt ที่มีโครงสร้างครอบคลุมทั้งห้าโหมดการสร้าง พร้อมด้วยส่วน soundscape และ music ส่วนอีกแปดอย่างที่เหลือเป็นสูตรประจำแนว (โฆษณาสินค้า, แอนิเมชัน 3D สั้น, คลิปอธิบายแบบ papercraft, ซับไตเติลมิวสิกวิดีโอ, อินโทรเกม co-op, ไฮบริดระหว่างภาพวาดมือกับไลฟ์แอ็กชัน และอื่นๆ) ที่บรรจุรูปแบบเดียวกันเอาไว้ในเวิร์กโฟลว์

การรันสกิลนั้นต้องใช้โมเดลข้อความ ไม่ใช่โมเดลวิดีโอ และนี่คือจุดที่เราเตอร์มีประโยชน์อย่างแท้จริง ไม่ใช่แค่ปลั๊กอิน LLM ของบริษัทเอง MiniMax M3 เป็นตัวเลือกที่เหมาะสมสำหรับงานนี้ และอยู่ใน OrcaRouter ในราคา $0.30 ต่อโทเค็นอินพุตหนึ่งล้านตัว และ $1.20 ต่อโทเค็นเอาต์พุตหนึ่งล้านตัว — ราคารายการของผู้ให้บริการ เนื่องจากเราส่งผ่านโดยคิดมาร์กอัป 0% — พร้อมหน้าต่างบริบท 1M โทเค็น และที่ผิดปกติคือ วิดีโอเป็นประเภทอินพุตที่รองรับ รายละเอียดสุดท้ายนั้นคือสิ่งที่ทำให้มันเหมาะสม: คุณสามารถส่งคู่มือพรอมป์อย่างเป็นทางการ บรีฟของคุณ และคลิปอ้างอิงจริงในการเรียกครั้งเดียว แล้วได้รับ [Shot N] บล็อกที่อธิบายมัน การคอมไพล์พรอมป์มีค่าใช้จ่ายเพียงเศษเสี้ยวเซนต์ เทียบกับการสร้างวิดีโอที่คิดค่าบริการเป็นวินาที ดังนั้นจึงไม่มีเหตุผลที่จะเขียนด้วยมือ ข้อแม้ที่ตรงไปตรงมาสองข้อ: การสร้างวิดีโอ H3 เองไม่ได้รันบน OrcaRouter — คลิปมาจากแพลตฟอร์มของบริษัท fal หรือ GPU ของคุณเอง — และขั้นตอนการคอมไพล์เป็นเพียงความสะดวก ไม่ใช่การรับประกันคุณภาพ สิ่งที่เราเตอร์ให้คุณที่นี่คือ ส่วนข้อความของไปป์ไลน์อยู่เบื้องหลังคีย์เดียวพร้อมการเฟลโอเวอร์อัตโนมัติ ดังนั้นผู้ให้บริการขัดข้องกลางแบตช์จะไม่ทำให้คิวเรนเดอร์ค้าง และการสลับ M3 เป็นโมเดลอื่นเพื่อเปรียบเทียบพรอมป์ที่คอมไพล์แล้วก็เป็นแค่การเปลี่ยนสตริง ไม่ใช่สัญญาใหม่

เสียงคือจุดที่ทุกคนพลาดในวันแรก

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

การรวบรวมคำแนะนำจากคู่มือพรอมpt์อย่างเป็นทางการ ร่วมกับสิ่งที่เอกสารผู้จัดจำหน่ายและผู้รีวิวรายงานว่าใช้งานได้จริง:

• บทสนทนาคือสิ่งที่ยากที่สุดที่จะขอ. จำกัดบทพูดให้เหลือหนึ่งหรือสองประโยคต่อคลิปห้าวินาที. บทพูดที่ยาวเกินไปทำให้พูดเร่งรีบ เสียงเลยเฟรมสุดท้าย หรือลิปซิงค์ดูฝืน — ซึ่งผู้ตรวจทานรายงานตรงกันเสมอ.

• อธิบายผู้พูดก่อนบรรทัด และการส่งเสียงพูดควบคู่กับบรรทัดนั้นอายุ เพศ โทนเสียงและสำเนียงในการปรากฏครั้งแรกตามคู่มืออย่างเป็นทางการ; ใช้หมายเหตุการส่งเสียงพูดที่เรียบง่ายและตรงไปตรงมา (ชัดเจน อบอุ่น ราบเรียบ) แทนการกำหนดทิศทางการแสดงที่ซับซ้อน ซึ่งมีรายงานว่าทำให้การซิงค์แย่ลง

• ผูกเอฟเฟกต์ทุกอย่างเข้ากับเหตุการณ์ที่มองเห็นได้"เสียงจุกก๊อกป๊อปพอดีกับจังหวะที่จุกก๊อกปลิว" แทนที่จะเป็น "เสียง: ป๊อป" คำว่า as, when และ then คือสิ่งที่ทำให้เกิดการซิงโครไนซ์

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

• ซ้อนบรรยากาศในประโยคเดียว ฝนกระทบกระจก เสียงพูดคุยเบาๆ เสียงถ้วยชนกันเป็นครั้งคราว แจ๊สเบาๆ ในพื้นหลัง — รวมอยู่ในประโยคเดียวแทนที่จะแยกเป็นรายการ

• อย่าพูดซ้ำบทสนทนาในส่วน soundscape เป็นข้อห้ามที่ชัดเจนในคู่มือทางการ; แต่ละส่วนถูกออกแบบมาให้แยกจากกัน และการพูดซ้ำบรรทัดในส่วนนั้นจะทำให้ได้มันสองครั้ง

• หากต้องการให้คำใดคำหนึ่งอ่านออกบนหน้าจอ ให้พิมพ์คำนั้นในเครื่องหมายคำพูด. ผู้ตรวจสอบรายงานว่าข้อความที่ระบุเจาะจงแสดงผลได้อย่างเรียบร้อย ในขณะที่คำขอที่คลุมเครือ ("องค์ประกอบ HUD", "ป้าย") กลับกลายเป็นตัวอักษรที่อ่านไม่ออก.

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

อ้างอิง: กำหนดงานให้ทุกไฟล์

ระบบอ้างอิงของ H3 เป็นจุดที่สร้างความแตกต่างที่แข็งแกร่งที่สุด และเป็นจุดที่มักเกิดข้อผิดพลาดในการตั้งค่าบ่อยที่สุด ข้อจำกัดที่ระบุไว้จากเอกสาร API ของแพลตฟอร์ม: สูงสุดถึง รูปภาพ 9 รูป, คลิปวิดีโอ 3 คลิป และคลิปเสียง 3 คลิป รวมทั้งหมดไม่เกิน 12 ไฟล์โดยแต่ละวิดีโอหรือเสียงอ้างอิงต้องมีความยาวระหว่าง 2 ถึง 15 วินาที และความยาวรวมทั้งหมดต้องไม่เกิน 15 วินาที การอ้างอิงเป็นวิดีโอจำเป็นต้องมีรูปภาพหรือวิดีโออย่างน้อยหนึ่งรายการ ไม่อนุญาตให้ใช้เสียงเพียงอย่างเดียว

เทคนิคที่ทั้งคู่มืออ้างอิงอย่างเป็นทางการและรายงานจากชุมชนต่างเห็นพ้องต้องกันคือการ ติดแท็กให้แต่ละอินพุตและกำหนดหน้าที่ให้มัน. อ้างอิงโดยใช้แท็กตามลำดับที่แนบไฟล์ไว้อย่างแม่นยำ — <Picture 1>, <Video 1>, <Audio 1> — จากนั้นระบุในพรอมป์ว่าข้อมูลอ้างอิงใดควบคุมคุณสมบัติใด: เอกลักษณ์ สไตล์ การเคลื่อนไหว กล้อง หรือเสียง ตัวอย่างพรอมป์อย่างเป็นทางการเริ่มต้นด้วยวิธีนี้พอดี โดยระบุว่าภาพแรกเป็นข้อมูลอ้างอิงด้านอารมณ์โดยรวมและสไตล์ ส่วนภาพที่สองเป็นตัวละครหลัก ผู้ใช้งานรายงานว่าการกำหนดอย่างชัดเจนทำงานได้ดีกว่าการโยนภาพเก้าภาพแล้วหวังผลอย่างมีนัยสำคัญ

รายละเอียดสองอย่างที่ทำให้ผู้คนเสียเรนเดอร์:

• <Picture 1> ไม่ใช่มูดบอร์ด — มันคือเฟรมแรกตามตัวอักษรที่เวลา 0.000 วินาที และเป็นของ [Shot 1] อธิบายสิ่งที่อยู่ในนั้น (สไตล์ ตัวแบบ องค์ประกอบ จุดยึดของฉาก) ก่อนจะอธิบายแอ็กชันที่ตามมาจากมัน ให้มองมันเป็นภาพนิ่งที่คุณกำลังทำให้เคลื่อนไหว ไม่ใช่คำใบ้

• มีจุดตรวจสอบแยกกันสองจุด และการใช้จุดผิดจะล้มเหลวอย่างเงียบ ๆ fl2va จัดการงาน text-to-video และงานเฟรมแรก/เฟรมสุดท้าย; ref2va จัดการงาน reference-to-video นี่คือข้อผิดพลาด ComfyUI ที่ถูกรายงานมากที่สุด: กราฟ R2V รันโดยที่ยังเลือกโมเดล FL2VA อยู่ ควรรู้ไว้อีกอย่างว่า ผู้แสดงความเห็นในประกาศ ComfyUI ชี้ให้เห็นว่าเทมเพลต R2V ที่แถมมานั้นแสดงช่องอ้างอิงภาพเพียงสองช่อง ทั้งที่โมเดลรองรับเก้าช่อง — เป็นข้อจำกัดของเทมเพลต ไม่ใช่ข้อจำกัดของโมเดล

ในฝั่งโฮสต์ มีบันทึกเชิงปฏิบัติเพิ่มเติมอีกสองข้อจากเอกสารสำหรับผู้จำหน่าย: พารามิเตอร์ ratio ต้องระบุบน ref2va endpoints และไม่สามารถปล่อยไว้เป็น "adaptive" ได้ และงานที่ซ้อนทับกันจะคืนค่า 429 สำหรับการทำงานพร้อมกันของงานแทนการจัดคิว — ดังนั้นให้ประมวลผลเป็นชุดตามลำดับหรือสร้างคิวของคุณเอง ในฝั่งโลคัล ref_image_size มีค่าเริ่มต้นเป็น match ซึ่งเร็วกว่า; max จะคงด้านสั้นของภาพอ้างอิงไว้ได้สูงสุด 2048 พิกเซล และใช้เวลามากขึ้น

การรันแบบโลคัลจริงๆ แล้วใช้เวลาจริงเท่าไร

การดาวน์โหลดแหล่งเก็บข้อมูลอย่างเป็นทางการทั้งชุดมีขนาด 498 GB และมิเรอร์ที่แพ็กใหม่โดย ComfyUI มีขนาด 343 GB คุณไม่จำเป็นต้องดาวน์โหลดทั้งหมดของทั้งสองแหล่งข้อมูล ไฟล์สี่ไฟล์ที่บทช่วยสอนของ ComfyUI เองระบุไว้สำหรับการสร้างวิดีโอจากข้อความและจากรูปภาพมีขนาดรวมประมาณ 42.5 GB:

• โมเดล Diffusion — minimax_h3_fl2va_pruned_int8_convrot.safetensorsขนาด 20.97 GB ไปยัง models/diffusion_models.

• ตัวเข้ารหัสข้อความ — qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors, 15.69 GB, ลงใน models/text_encoders.

• วิดีโอ VAE — minimax_h3_video_vae_fp16.safetensors, 5.21 GB, ลงใน models/vae.

• Audio VAE — minimax_h3_audio_vae_fp32.safetensors, 0.61 GB, ยังใส่ใน models/vae.

• เพิ่มสำหรับการอ้างอิงถึงวิดีโอ — minimax_h3_ref2va_pruned_int8_convrot.safetensors, อีก 20.97 GB.

42.5 GB นั้นไม่ใช่ตัวเลข VRAM — มันคือพื้นที่ดิสก์ และชิ้นส่วนต่างๆ จะถูกสตรีมและออฟโหลดออกมา เหตุผลที่โมเดลรันบนการ์ดจอระดับผู้บริโภคได้เลยนั้นเป็นเทคนิคทางวิศวกรรมที่ ComfyUI ได้บันทึกไว้: ประมาณ 40% ของพารามิเตอร์อยู่ใน AdaLN modulation branches ซึ่งผลลัพธ์สามารถคำนวณล่วงหน้าและแทนที่ด้วย lookup tables ที่เทียบเท่าเชิงฟังก์ชัน ทำให้โมเดลที่โหลดลดลงจาก 33.12B เหลือประมาณ 20.11B โดยที่ ComfyUI ระบุว่าไม่มีการสูญเสียคุณภาพ ความแม่นยำเต็มรูปแบบ (full precision) จะอยู่ที่ 123.6 GB ส่วน int8 checkpoints ที่ไม่ได้ตัดทอน (34.04 GB ต่อตัว) และ bf16 (66.28 GB ต่อตัว) มีให้หากคุณกำลัง fine-tuning หรือไล่ตามความเที่ยงตรงไม่กี่เปอร์เซ็นต์สุดท้าย

ComfyUI 0.30.0 หรือใหม่กว่าต้องใช้ และมาพร้อมเทมเพลตสามแบบ: T2V, I2V และ R2V พื้นฐานที่ทุกคู่มือและผู้ดูแลเห็นตรงกันสำหรับการรันครั้งแรกนั้นจงใจให้เล็ก: 16:9 ที่ 0.4 MP (864×480), 5 วินาที, 20 สเต็ป, แซมเพลอร์ res_multistep กับ scheduler แบบ simple, denoise 1.0, batch 1. สร้าง MP4 หนึ่งไฟล์ที่มีทั้งวิดีโอและเสียงสเตอริโอออกมาก่อนที่คุณจะไปยุ่งกับความละเอียดหรือความยาว เรื่องแปลกทางเลขคณิตที่ต้องคาดไว้: ระยะเวลาจะถูกจัดให้ตรงกับกริดเฟรม 17k+5 ดังนั้นคำขอ 5 วินาทีจะกลายเป็น 124 เฟรม — ประมาณ 5.17 วินาทีที่ 24 fps — และคำขอ 10 วินาทีจะได้ 243 เฟรม หรือ 10.125 วินาที คำขอในช่วง 5–15 วินาทีเป็นโซนที่ปลอดภัยกว่า

สิ่งนั้นต้องแลกด้วยเวลาจริงเท่าใด จากรายงานของชุมชน (ทั้งหมดเป็นการรันครั้งเดียว ไม่มีการควบคุม ในการตั้งค่าที่ต่างกัน — แผนภูมิด้านบนแสดงแต่ละการกำหนดค่าข้างแถบของมัน): RTX 3060 ขนาด 12 GB พร้อมแรมระบบ 32 GB และ NVMe ที่รวดเร็ว ทำ baseline 864×480 / 124 เฟรม / 20 สเต็ป เสร็จในเวลาไม่ถึงเก้านาทีโดยใช้ dynamic offload โน้ตบุ๊ก RTX 4090 ขนาด 16 GB ที่เปิดใช้งาน SageAttention ทำ 960×540, 5 วินาที, 20 สเต็ป ใน 182 วินาที บิลด์ NVFP4 บน RTX 5090 ตัวเดียวสร้างคลิป 864×480 จำนวน 243 เฟรม (10.1 วินาที) ที่ 10 สเต็ป ภายใน 175 วินาที โดยใช้ VRAM สูงสุด 26.9 GiB และมีไฟล์บนดิสก์เพียง 31.7 GB เอกสารอ้างอิง cookbook ของ SGLang — 1344×768, 124 เฟรม, 50 สเต็ป กระจายบน RTX 5090 สองตัวพร้อม layerwise offload — ใช้เวลา 559.67 วินาที และเส้นทาง Apple Silicon ผ่านพอร์ต MLX ที่ไม่เป็นทางการ ใช้เวลาไม่ถึง 45 นาทีสำหรับคลิปเดียว

บันทึกเชิงปฏิบัติที่สรุปจากรายงานเหล่านั้น:

• หน่วยความจำระบบและความเร็วดิสก์เป็นสิ่งจำเป็น ไม่ใช่ทางเลือกบนการ์ด 12 GB ไฟล์ที่เลือกมีขนาดเกิน VRAM โดยการออกแบบ ดังนั้นเส้นทาง offload จึงวิ่งผ่าน RAM แล้วจึงไปที่ SSD RAM 32 GB ปรากฏในรายงาน VRAM ต่ำที่ประสบความสำเร็จทั้งสองฉบับ ไม่มีผลลัพธ์ 8 GB ที่ได้รับการยืนยัน

• SageAttention เป็นตัวเร่งความเร็วฟรีเพียงตัวเดียว — ประมาณ 2 เท่าเมื่อใช้กับ ComfyUI น้อยกว่านั้นหากการรันของคุณถูกครอบงำด้วยทราฟฟิกออฟโหลด ติดตั้ง wheel ที่ตรงกับบิลด์ PyTorch และ CUDA ของคุณทุกประการ พร้อมทั้ง ComfyUI-KJNodes จากนั้นแทรก Patch Sage Attention KJ ระหว่าง UNET loader กับ guider และตั้งค่าเป็น auto คาดว่าจะมีคำเตือนว่า H3 บางเลเยอร์ไม่ใช่ FP16/BF16 การ fallback นั้นมีเอกสารระบุไว้และเป็นเรื่องปกติ

• จำนวนขั้นตอนสามารถปรับเปลี่ยนได้ เบนช์มาร์ก 5090 รันที่ 10 และเบสไลน์ ComfyUI รันที่ 20 ในขณะที่คอนฟิกอ้างอิง SGLang ใช้ 50 ไม่มีใครเผยแพร่เส้นโค้งคุณภาพต่อขั้นตอน ดังนั้นจงหาค่าต่ำสุดของคุณเองก่อนที่จะสรุปว่าคุณต้องใช้ 50

• เปลี่ยนตัวแปรครั้งละหนึ่งตัวเพื่อออกจากสภาวะ OOM วิธีการกู้คืนตามเอกสารคือลดกลับไปใช้ 0.4 MP, 5 วินาที, batch 1 และปรับค่าทีละหนึ่งค่าในการลองแต่ละครั้ง

• เสียงเงียบหมายความว่า audio VAE ไม่ได้เชื่อมต่อกับโหนดเอาต์พุตวิดีโอ เป็นความล้มเหลวที่ต่างจากปัญหาเสียงที่ไม่ดี และง่ายที่จะเข้าใจผิดว่าโมเดลปฏิเสธที่จะสร้างเสียง

• Apple Silicon ไม่เป็นทางการ เส้นทางของ Willison คือ PipeNetwork/minimax-h3-mlx ซึ่งเป็นพอร์ตจากชุมชน รันผ่าน uv กับไฟล์ requirements ของ MLX เอกสารของบริษัทเองระบุชื่อ SGLang, vLLM, Diffusers และ ComfyUI โดยมีการปรับใช้งานทั่วไปบน GPU สี่ตัวในโหมด BF16 และไม่กล่าวถึง Metal หรือ MPS เลย ควรถือว่าการรองรับ Mac เป็นการดูแลโดยชุมชน

Local เทียบกับ Hosted พร้อมตัวเลข

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

ในเรื่องราคา ควรระมัดระวัง เนื่องจากราคาแตกต่างกันประมาณ 2 เท่าขึ้นอยู่กับว่าซื้อจากใคร และโพสต์บล็อกของผู้จำหน่ายเองไม่ได้ระบุตัวเลขเป็นดอลลาร์ — ระบุเพียงว่า 2K มีราคาต่ำกว่าหนึ่งในสามของรุ่นกระแสหลัก และ 768p มีราคาต่ำกว่าครึ่งหนึ่งของราคา 720p ของคู่แข่ง สิ่งที่เผยแพร่จริง: fal ซึ่งปัจจุบันเป็นผู้ให้บริการอินเฟอเรนซ์เพียงรายเดียวที่ระบุไว้ในคลังข้อมูล Hugging Face คิดค่าบริการ$0.16 ต่อวินาทีที่ 768p และ $0.26 ต่อวินาทีที่ 2K. ส่วนตัวติดตามราคารายอื่นรายงานว่าราคาประกาศของบริษัทเองต่ำกว่าอย่างมีนัยสำคัญ — ประมาณ$0.09–$0.10 ต่อวินาทีที่ 768p และ $0.13–$0.14 ต่อวินาทีที่ 2K — และตัวเลขเหล่านี้ไม่ตรงกันในระดับเซนต์ ดังนั้นให้ถือว่าเป็นเพียงตัวเลขโดยประมาณ และตรวจสอบหน้าราคาของแพลตฟอร์มก่อนวางแผนงบประมาณ นอกจากนี้ ควรกันงบประมาณไว้สำหรับข้อเท็จจริงที่ว่าวิดีโออ้างอิงถูกคิดค่าบริการตามระยะเวลาของตัวมันเอง เช่นเดียวกับผลลัพธ์ที่สร้างขึ้น

ลองคำนวณด้วยตัวเลขจริง คลิปที่จะเก็บไว้ 100 คลิป แต่ละคลิป 8 วินาที รวมเป็นวิดีโอที่สร้างขึ้น 800 วินาที: ประมาณ 112 ดอลลาร์ที่อัตรา 2K $0.14, ประมาณ 208 ดอลลาร์ที่อัตรา $0.26 ของ fal, และประมาณ 76 ดอลลาร์หากส่งมอบที่ 768p ในราคารายการที่ต่ำสุด คลิปที่ถูกทิ้ง 40 คลิปต่อคลิปที่เก็บไว้ 1 คลิปคือสิ่งที่กำหนดค่าใช้จ่าย และคลิปเหล่านั้นคือสิ่งที่ควรสร้างในเครื่อง นี่คือเหตุผลที่ต้องทำให้ราคาที่คุณนำมาเปรียบเทียบตรงไปตรงมา — บน OrcaRouter ฝั่งข้อความของไปป์ไลน์นั้นถูกส่งผ่านด้วยราคารายการผู้ให้บริการโดยมีมาร์กอัป 0% ดังนั้นเมื่อผู้ให้บริการลดราคา ราคาจะมีผลทันทีในวันเดียวกัน แทนที่จะเป็นหลังจากการคำนวณมาร์จิ้นใหม่ สำหรับการสร้างวิดีโอ ย้ำอีกครั้งว่าไม่ใช่ของเรา ประเด็นคือเพียงว่าขั้นตอนคอมไพล์ไม่ควรเป็นรายการที่คุณต้องคิดถึง

อ่านใบอนุญาตก่อนที่คุณจะสร้างผลิตภัณฑ์บนสิ่งนี้

นี่คือส่วนที่คู่มือ "วิธีใช้" ส่วนใหญ่ข้ามไป และสำหรับผู้อ่านจำนวนมาก นี่เป็นส่วนเดียวที่เปลี่ยนการตัดสินใจ เราอ่านไฟล์ LICENSE ในที่เก็บโดยตรง น้ำหนักของโมเดลถูกเผยแพร่ภายใต้ H3 Community License Agreement ซึ่งไม่ใช่สัญญาอนุญาตโอเพนซอร์ส และมีข้อกำหนดที่ผิดปกติพอจะต้องกล่าวถึงโดยสรุป:

• อาณาเขต. ใบอนุญาตกำหนด "อาณาเขตที่ใช้บังคับ" (Applicable Territory) ว่าครอบคลุมทั่วโลก ยกเว้น สหภาพยุโรป สหราชอาณาจักร สาธารณรัฐเกาหลี และสหรัฐอเมริกา หากอ่านตามตัวอักษร ข้อกำหนดนี้ไม่ครอบคลุมคนจำนวนมากที่กำลังโพสต์ผลลัพธ์จากการสร้างในเครื่องอยู่ตอนนี้ — และข้อจำกัดดังกล่าวถูกเขียนขึ้นให้ครอบคลุมถึงผลลัพธ์ที่ส่งออก ไม่ใช่เพียงแค่ตัวน้ำหนัก (weights) เท่านั้น

• การแสดงที่มา การใช้งานเชิงพาณิชย์ต้องแสดง "H3" บนอินเทอร์เฟซของผลิตภัณฑ์ และใบอนุญาตยังสนับสนุนให้แสดงข้อความ "Powered by H3" ด้วย

• เกณฑ์รายได้ องค์กรที่สร้างรายได้มากกว่า 20 ล้านดอลลาร์สหรัฐต่อปีจากผลิตภัณฑ์หรือบริการที่สร้างขึ้นบนนั้น จะต้องได้รับการอนุญาตเป็นลายลักษณ์อักษรแยกต่างหากจากบริษัท

• ห้ามกลั่น คุณต้องไม่ใช้ H3 หรือผลลัพธ์ของมันเพื่อปรับปรุงโมเดล AI อื่นใด ยกเว้นอนุพันธ์ของ H3 ซึ่งตัดความเป็นไปได้ของแนวทางข้อมูลสังเคราะห์มาตรฐาน

• กฎหมายที่ใช้บังคับ เขตบริหารพิเศษฮ่องกง โดยให้ศาลในฮ่องกงมีเขตอำนาจศาลแต่เพียงผู้เดียว

• องค์ประกอบหนึ่งที่เปิดกว้างอย่างแท้จริง ตัวเข้ารหัสข้อความ Qwen3-VL-32B อยู่ภายใต้สัญญาอนุญาต Apache 2.0; ข้อจำกัดข้างต้นใช้กับน้ำหนัก (weights) ของ H3 เท่านั้น

เราไม่ใช่ทนายความของคุณ และนี่ไม่ใช่คำแนะนำทางกฎหมาย — อ่านสัญญาอนุญาตและเอกสารถาม-ตอบที่บริษัทส่งมาคู่กับสัญญานั้น และหากคุณกำลังสร้างผลิตภัณฑ์เชิงพาณิชย์ในเขตพื้นที่ที่ถูกยกเว้น จงปรึกษาทนายความแทนที่จะอ่านตามบล็อก ทางแยกในทางปฏิบัติคือ: API แบบโฮสต์เป็นธุรกรรมที่แยกต่างหากซึ่งมีเงื่อนไขที่แตกต่างจากสัญญาอนุญาตแบบชุมชนที่ใช้กับตัวน้ำหนัก (weights) ดังนั้นหากสัญญาอนุญาตในพื้นที่ไม่เหมาะกับคุณ เส้นทาง API ก็อาจยังใช้ได้ โปรดตรวจสอบเงื่อนไขของแพลตฟอร์มที่คุณซื้อจาก

แผนการทดสอบสัปดาห์แรก

การรันห้าครั้ง ตามลำดับนี้ เพียงพอที่จะรู้ว่า H3 เหมาะกับไปป์ไลน์ของคุณหรือไม่:

• Run 1 — พิสูจน์โครงสร้างพื้นฐาน.เทมเพลต T2V, 864×480, 5 วินาที, 20 สเต็ป, res_multistep/simpleเกณฑ์ความสำเร็จคือได้ไฟล์ MP4 ที่มีเสียงสเตอริโอในไฟล์ ไม่ใช่คลิปที่ดี.

• รัน 2 — พิสูจน์ว่ารูปแบบมีความสำคัญ หัวข้อเดียวกันสองครั้ง: ครั้งหนึ่งเป็นคำอธิบายบรรทัดเดียวแบบคร่าว ๆ อีกครั้งเขียนเป็น [Shot 1] บวกกับ overall_soundscape บวกกับ non_diegetic_music. หากแบบที่สองไม่ได้ดีกว่าอย่างชัดเจนเมื่อเทียบกับ H3-Base แสดงว่าการตั้งค่าของคุณมีบางอย่างผิดพลาด

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

• รัน 4 — วินัยการอ้างอิง. R2V กับ ref2va checkpoint โดยมีข้อมูลอ้างอิงสองหรือสามรายการ แต่ละรายการถูกแท็กอย่างชัดเจนและได้รับมอบหมายหน้าที่ โดยให้ <Picture 1> ถูกอธิบายว่าเป็นเฟรมแรกที่แท้จริง จากนั้นจงละเมิดมันโดยเจตนา: แนบข้อมูลอ้างอิงเดียวกันโดยไม่มีการกำหนดหน้าที่ แล้วเปรียบเทียบ.

• รัน 5 — บทสรุป นำพรอมพ์ต์ 768p ในเครื่องที่ดีที่สุดของคุณไปยัง API ที่โฮสต์ไว้ที่ระดับ 2K แล้วดูว่า Context-IR และการประมวลผลซ้ำ (regeneration pass) เพิ่มอะไรเข้ามา ความต่างที่ได้คือสิ่งที่ราคาต่อวินาทีมอบให้ และนี่คือวิธีเดียวที่จะตั้งราคาเวิร์กโฟลว์แบบไฮบริดอย่างซื่อตรง

คำถามที่พบบ่อย

ฉันขอ 2K จากน้ำหนักในเครื่องได้ไหม?

ไม่ แพ็กเกจโอเพนคือ H3-Base ซึ่งแคนวาสดั้งเดิมมีขอบสั้น 768 พิกเซล (สูงสุด 768×1344) ความละเอียด 2K มาจาก H3-Regenerate-2K ซึ่งเป็นโมดูลรีเจนเนอเรชันในบริบทแยกต่างหากที่บริษัทเก็บไว้บน hosted API คุณสามารถอัปสเกลในเครื่องด้วยอัปสเกลเลอร์เอนกประสงค์ใดก็ได้ แต่นั่นเป็นการทำงานที่แตกต่างจากการรีเจนเนอเรชันพาสของ H3 เอง และจะไม่ตรงกับมัน

เหตุใดพรอมต์เดียวกันจึงมีพฤติกรรมแตกต่างกันบน API และใน ComfyUI

เนื่องจาก API เรียกใช้ H3-Context-IR ก่อนเป็นขั้นแรก มันจะอ่านข้อความของคุณและข้อมูลอ้างอิงของคุณ วิเคราะห์ความสัมพันธ์ระหว่างสิ่งเหล่านี้ แล้วส่งคำสั่งที่มีโครงสร้างและสมบูรณ์ให้กับ H3-Base ในกรณีการใช้งานแบบโลคัลไม่มีขั้นตอนดังกล่าว — H3-Base ได้รับข้อความดิบของคุณโดยตรง พรอมptที่คลุมเครือซึ่งให้ผลลัพธ์คลิปที่ใช้งานได้ดีผ่าน API นั้นกำลังถูก "ช่วยเหลือ" โดยตัวประมวลผลล่วงหน้า (preprocessor) ที่คุณไม่ได้ติดตั้งไว้ นี่คือเหตุผลที่รูปแบบพรอมptที่ระบุไว้ในเอกสารมีความสำคัญต่อผู้ใช้โลคัลมากกว่าผู้ใช้ API อย่างมีนัยสำคัญ

เทมเพลตไทม์โค้ด [0s-2s] ผิดหรือไม่?

นี่ไม่ใช่สิ่งที่คู่มือที่แถมมากำหนดให้ ไฟล์ของบริษัท VIDEO_PROMPT_WRITING_GUIDE_base_en.md จัดระเบียบตามบล็อก [Shot N] โดยไม่กำหนด timestamp ให้ Shot 1 และระบุจุดคัตถัดไปเป็นเวลาแบบสัมบูรณ์ ("At 00:03.500, the camera cuts to…") อีกทั้งยังไม่มีส่วนของ negative-prompt ดังนั้นรายการ "banned transitions" ในเทมเพลตยอดนิยมจึงเป็นส่วนเสริมจากชุมชน อย่างไรก็ตาม ผู้ใช้งานรายงานผลลัพธ์ API ที่ดีเมื่อใช้รูปแบบ timecode ซึ่งน่าจะเป็นเพราะ Context-IR ทำให้ข้อมูลเป็นมาตรฐาน การตีความของเรา: ให้ใช้รูปแบบที่ระบุในเอกสารเมื่อทำงานกับ local weights และอย่าให้เครดิตแก่วงเล็บ timecode สำหรับผลลัพธ์ API ที่ตัวประมวลผลล่วงหน้าอาจเป็นผู้ทำให้เกิดขึ้นจริง

บริษัทในสหรัฐฯ หรือสหภาพยุโรปสามารถใช้น้ำหนักแบบเปิดเผย (open weights) ในเชิงพาณิชย์ได้หรือไม่?

ข้อความใบอนุญาตที่เราอ่านไม่รวมสหภาพยุโรป สหราชอาณาจักร เกาหลีใต้ และสหรัฐอเมริกาออกจากเขตพื้นที่ที่ใช้บังคับ (Applicable Territory) และข้อความยกเว้นนี้เขียนให้ครอบคลุมทั้งผลลัพธ์และค่าน้ำหนัก นี่เป็นอุปสรรคสำคัญต่อการนำไปใช้เชิงพาณิชย์ในพื้นที่เหล่านั้น และเป็นคำถามทางกฎหมายมากกว่าทางเทคนิค — โปรดอ่านใบอนุญาตและไฟล์คำถาม-คำตอบด้วยตนเองและขอคำแนะนำ บริการ API ที่โฮสต์นั้นอยู่ภายใต้ข้อกำหนดของแพลตฟอร์มเอง ไม่ใช่ใบอนุญาตชุมชน ดังนั้นจึงควรประเมินแยกต่างหาก แทนที่จะสรุปว่าถูกจำกัดเท่าเทียมกัน

สิ่งที่ต้องตรวจสอบก่อนคอมมิต

H3 ให้ความคุ้มค่าที่ดีผิดปกติสำหรับงานรูปแบบเฉพาะ: คลิปสั้นที่ออกแบบเสียงอย่างดีและสอดคล้องกับ reference ซึ่งคุณยินดีจะเขียนช็อตลิสต์จริงจัง มันเข้มงวดผิดปกติเกี่ยวกับวิธีที่คุณถาม สามสิ่งที่ควรตรวจสอบด้วยตัวเอง เพราะเป็นสิ่งที่เปลี่ยนแปลงเร็วที่สุด: จะมีผู้ให้บริการ inference ปรากฏขึ้นถัดจาก fal หรือไม่ (ซึ่งจะทำให้ราคาต่อวินาทีลดลง), เทมเพลต ComfyUI R2V จะขยายเกินสองช่อง reference ไปจนถึงเก้าช่องของโมเดลหรือไม่, และนิสัยการใช้ timecode ของชุมชนหรือรูปแบบ shot-block ที่บันทึกไว้จะชนะ เมื่อมีใครสักคนรันการเปรียบเทียบแบบควบคุมกับน้ำหนักโมเดลในเครื่อง ยังไม่มีใครเผยแพร่การเปรียบเทียบนั้น จนกว่าจะมี คู่มือใน repository คือทางเลือกที่ดีกว่า — และมันอยู่ในดาวน์โหลดเดียวกันกับที่คุณใช้พื้นที่ 42 GB ไปแล้ว