Marker 2 เขียนใหม่ทั้งตัว — แปลง PDF เป็น Markdown ได้ 76.0% บน olmOCR-bench เร็วกว่า MinerU 5 เท่า และโหมดไม่ใช้ GPU ก็ยังอ่านโครงสร้างเป็น

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

Datalab ปล่อย Marker 2.0.0 เมื่อ 20 กรกฎาคม 2026 (เราพลาดไปไม่ได้เขียนตอนออก — ขอเก็บตกในรอบนี้ ยิ่งเมื่อมีการเทียบ benchmark กับคู่แข่งตามมาเมื่อ 24 ก.ค.) เป็นการ เขียนใหม่ทั้งตัว ของ pipeline แปลงเอกสารโอเพนซอร์สที่มีคนใช้กันกว้างมากตัวหนึ่ง โดยโฟกัสสามเรื่อง: ความเร็ว, รันบน CPU ได้เต็มตัว และความแม่นยำ

สร้างบนสามชิ้นส่วนใหม่

Marker 2 ไม่ใช่การอัปเวอร์ชันแบบขัดเงา แต่ประกอบขึ้นจากของที่ Datalab ทยอยปล่อยมาก่อนหน้า:

• Surya OCR 2 — โมเดล OCR ขนาด 650M พารามิเตอร์ ที่รวม layout, การอ่านตัวอักษร และการรู้จำตาราง ไว้ใน vision-language model ตัวเดียว
• โมเดล layout เร็วขนาด 20M พารามิเตอร์ — เล็กพอจะรันบน CPU
• pdftext ที่เขียนใหม่ เร็วขึ้น 3 เท่า — ตัวอ่าน text layer ของ PDF โดยตรง

หัวใจของการออกแบบคือ selective OCR: Marker อ่าน text layer ของ PDF ก่อนด้วย pdftext แล้วเรียก VLM เฉพาะจุดที่จำเป็นจริง ๆ — หน้าที่สแกนมาเละ สมการ ตารางที่ความมั่นใจต่ำ — แทนที่จะ OCR ทั้งเล่มด้วย VLM ทุกหน้า ซึ่งเป็นวิธีที่แพงกว่าหลายเท่าโดยไม่ได้แม่นกว่าเสมอไป

สามโหมด เลือกจุดสมดุลเอง

Marker 2 ให้เลือกจุดแลกเปลี่ยนระหว่างความเร็วกับความแม่น และเลือกโหมดให้อัตโนมัติตามฮาร์ดแวร์ (balanced บน GPU, fast บน CPU/MPS) โดยไม่ต้องใส่ flag:

โหมด	olmOCR-bench	เฉพาะ PDF ดิจิทัล	ความเร็ว (B200 1 ใบ)
balanced (GPU)	76.0	83.5	2.9 หน้า/วิ
fast (GPU)	66.6	71.6	7.4 หน้า/วิ
--disable_ocr (CPU ล้วน)	43.6	55.8	23.7 หน้า/วิ

จุดที่สำคัญสำหรับคนงบจำกัด: โหมด fast --disable_ocr ไม่ต้องมี GPU และไม่ต้องมี inference server เลย โมเดล layout 20M ยังรันบน CPU และยังอ่านโครงสร้างเป็น (คอลัมน์ ตาราง หัวข้อ) — ต่างจากการดึงข้อความดิบที่พังทันทีเมื่อเจอเอกสารหลายคอลัมน์

อีกเรื่องที่ทีมออกแบบมาดีคือ throughput: worker บาง ๆ หลายตัวบน CPU แชร์ inference server ของ surya ตัวเดียว แล้วมีตัวแม่คอยจัดสรรโควตา VLM ให้ ผลคือ throughput ขยายตามความจุของเซิร์ฟเวอร์ ไม่ใช่ตาม VRAM ต่อโปรเซส — นี่คือเหตุผลที่โหมด balanced ทำได้ 2.9 หน้า/วิ ทั้งที่อัตรา single-stream อยู่ราว 0.3 หน้า/วิเท่านั้น

เทียบกับ MinerU, docling, liteparse

Datalab ปล่อย benchmark harness ให้ทำซ้ำได้เองใน benchmarks/ (วัดบน olmOCR-bench: PDF 1,403 ไฟล์ กับเทสต์ผ่าน/ไม่ผ่านราว 8,400 ข้อ ครอบคลุมคณิตศาสตร์ ตาราง ลำดับการอ่าน หัว-ท้ายกระดาษ และสแกนเก่า) — ตัวเลขที่เทียบกับ pipeline โอเพนซอร์สตัวอื่น:

ระบบ	คะแนนรวม	เฉพาะดิจิทัล	ความเร็ว
Marker — balanced (GPU)	76.0	83.5	2.9 หน้า/วิ
MinerU — pipeline (GPU)	72.7	83.3	0.54 หน้า/วิ
Marker — fast (GPU)	66.6	71.6	7.4 หน้า/วิ
docling (GPU)	50.3	64.0	2.1 หน้า/วิ
liteparse (CPU)	22.4	27.3	8.9 หน้า/วิ

ที่ต้องอ่านให้ครบคือ Datalab เองระบุว่านี่คือการเทียบ pipeline system ด้วยกัน — ระบบที่อ่าน text layer แล้ว OCR เฉพาะจุด ถ้าเอกสารของคุณต้องใช้ full-page VLM OCR จริง ๆ (หน้าที่คณิตศาสตร์หนัก สแกนล้วน ต้องการความแม่นสูงสุด) นั่นคือเครื่องมือคนละประเภท — ควรมองไปที่ Chandra (โมเดล VLM เอกสารของ Datalab เอง ทำ 85.8 ในตารางเดียวกัน แบบโฮสต์) หรือ surya โดยตรง

สัญญาอนุญาต และเรื่องภาษาไทย

โค้ดเป็น Apache 2.0 ใช้เชิงพาณิชย์ได้ฟรี แต่ น้ำหนักโมเดลใช้สัญญา AI Pubs Open Rail-M ที่ดัดแปลง — ฟรีสำหรับงานวิจัย ใช้ส่วนตัว และสตาร์ตอัปที่มีเงินทุนหรือรายได้ต่ำกว่า 5 ล้านดอลลาร์ เกินกว่านั้นต้องซื้อสัญญาเชิงพาณิชย์ นี่เป็นรูปแบบ “open weights แต่มีเพดานรายได้” ที่พบบ่อยขึ้นเรื่อย ๆ ในปี 2026 — อ่านให้ชัดก่อนเอาเข้าโปรดักชันขององค์กร

สำหรับงานเอกสารภาษาไทย ตัวเลขที่ต้องรู้: Surya OCR 2 รายงาน pass rate รวม 87.2% บน benchmark ภายใน 91 ภาษา โดย 38 ภาษาทำได้ ≥90% และ 76 ภาษาทำได้ ≥80% — ส่วน ภาษาไทยอยู่ที่ 76.4% ตามตารางภาษาในรีโปของ surya เอง แปลว่ารองรับ แต่ต่ำกว่าค่าเฉลี่ยรวม ถ้างานคุณคือเอกสารราชการไทยหรือสัญญาภาษาไทย ให้ทดสอบกับชุดเอกสารจริงก่อนเสมอ อย่าเหมาว่าคะแนนรวมสะท้อนผลของภาษาไทย

ข้อควรระวังตอนอัปเกรด: ต้องใช้ Python 3.10+, การแพ็กเกจย้ายจาก Poetry ไป uv (แต่ pip install marker-pdf ยังเหมือนเดิม) และ converter สำหรับ structured extraction ถูกถอดออก ใครใช้ฟีเจอร์นั้นอยู่ต้องย้ายไป Datalab API หรือ workflow ที่ใช้ --use_llm

มุมมอง AI Curator

เดือนมิถุนายนเราเขียนถึงคลื่นโมเดล OCR โอเพนซอร์ส (PP-OCRv6, Unlimited OCR, Mistral OCR 4) — Marker 2 เป็นข่าวคนละชั้นของกองเดียวกัน และเป็นชั้นที่คนมักมองข้าม: โมเดล OCR ไม่ใช่ pipeline สิ่งที่ทำให้ระบบใช้งานจริงได้คือการตัดสินใจว่าหน้าไหนต้อง OCR หน้าไหนอ่าน text layer พอ จะจัดคิว GPU อย่างไร จะรักษาลำดับการอ่านของเอกสารหลายคอลัมน์อย่างไร Marker 2 คือข่าวของชั้นนี้ และตัวเลข “เร็วกว่า MinerU 5 เท่าโดยคะแนนสูงกว่า” มาจากงานวิศวกรรมชั้นนี้เกือบทั้งหมด ไม่ใช่จากโมเดลที่ใหญ่ขึ้น

สิ่งที่ผมคิดว่าสำคัญที่สุดสำหรับผู้อ่านไทยคือ โหมด CPU ทีมไทยจำนวนมากที่ผมเห็นติดอยู่ตรงนี้พอดี — มีเอกสารเป็นหมื่นหน้าต้องเข้า RAG แต่ไม่มีงบ GPU และไม่อยากส่งสัญญาลูกค้าขึ้นคลาวด์ต่างประเทศ ทางเลือกที่เคยมีคือ “จ่ายค่า API ต่อหน้า” หรือ “ดึงข้อความดิบแล้วยอมรับว่าตารางเละ” การที่โมเดล layout ขนาด 20M รันบน CPU แล้วยังอ่านโครงสร้างเป็น ทำให้มีทางเลือกที่สามที่ใช้ได้จริงในองค์กรที่ข้อมูลออกนอกบ้านไม่ได้ — ลองประเมินด้วยคะแนน 55.8 บนเอกสารดิจิทัลล้วน ไม่ใช่ 43.6 ถ้าเอกสารของคุณเป็น PDF ที่สร้างจากคอมพิวเตอร์ ไม่ใช่ของสแกน

ข้อที่อยากเตือน: อย่าเลือกเครื่องมือจากคะแนนรวมของ benchmark ต่างประเทศ olmOCR-bench เป็น benchmark ที่ดีและตรวจสอบได้ แต่สัดส่วนเอกสารในนั้นไม่ได้สะท้อนกองเอกสารของคุณ ข้อดีที่แท้จริงของรีลีสนี้จึงอาจไม่ใช่คะแนน 76.0 แต่คือการที่ Datalab แถม harness มาให้รันซ้ำเองได้ — เอาเอกสารไทยจริงของคุณ 50 หน้าไปวัดทั้งสามโหมดเทียบกับของเดิมที่ใช้อยู่ ใช้เวลาไม่กี่ชั่วโมง แล้วคุณจะได้คำตอบที่ตรงกับงานคุณมากกว่าตารางใด ๆ ในบทความนี้

แหล่งข่าว

• Marker 2.0.0 — Release notes (Datalab, 20 ก.ค. 2026)
• datalab-to/marker — README และตาราง benchmark เต็ม
• Surya OCR 2 — โมเดล OCR ที่ Marker ใช้ (ตารางคะแนน 91 ภาษา)
• Datalab Marker v2 vs MinerU, Docling, and Liteparse — MarkTechPost (24 ก.ค. 2026)