GLM-5.3-Flash Vision: ส่งภาพสู่โมเดล AI บริบท 1 ล้าน

โมเดลวิชันส่วนใหญ่มักให้เลือกส่ง “รูปภาพ” หรือ “ข้อความจำนวนมาก” แต่ไม่ค่อยทำทั้งสองอย่างได้ดีพร้อมกัน GLM-5.3-Flash รับรูปภาพเป็นบล็อกเนื้อหาภายในหน้าต่างบริบท 1,048,576 โทเค็น จึงวิเคราะห์รูปภาพ โค้ด และเอกสารยาว ๆ ในคำขอเดียวกันได้

ลองใช้ Apidog วันนี้

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

มัลติโมดัลแบบเนทีฟ ไม่ใช่อะแดปเตอร์

โมเดลวิชันก่อนหน้าของ Z.ai เช่น GLM-5V-Turbo และ GLM-4.6V เป็นปลายทางแยกต่างหาก ต้องใช้รหัสโมเดลและเส้นทางรับส่งข้อมูลสำหรับรูปภาพโดยเฉพาะ ส่วน GLM-5.3 ใช้อะแดปเตอร์สำหรับวิชัน

GLM-5.3-Flash เป็นโมเดลแรกในซีรีส์ GLM-5 ที่รองรับรูปภาพเป็นอินพุตระดับเฟิร์สคลาสภายในการเรียกใช้เดียวกันและบริบทเดียวกันกับข้อความ

ผลลัพธ์คือ:

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

หากยังใช้เส้นทางเดิม ดู คู่มือ API GLM-5V-Turbo และคู่มือ GLM-4.6V

ส่งรูปภาพด้วย Content Blocks

แทนที่จะส่ง content เป็นสตริง ให้ส่งเป็นอาร์เรย์ของบล็อกเนื้อหา:

from openai import OpenAI
import os

client = OpenAI(
    [REDACTED CREDENTIAL],
    base_url="https://api.z.ai/api/paas/v4/",
)

response = client.chat.completions.create(
    model="glm-5.3-flash",
    messages=[
        {
            "role": "user",
            "content": [
                {"type": "text", "text": "What is wrong with this layout on mobile?"},
                {
                    "type": "image_url",
                    "image_url": {"url": "https://example.com/mobile-view.png"},
                },
            ],
        }
    ],
)

print(response.choices[0].message.content)

สำหรับรูปภาพในเครื่องหรือรูปภาพส่วนตัว ให้ส่งเป็น base64 data URL:

import base64
from pathlib import Path

def image_block(path: str) -> dict:
    data = base64.b64encode(Path(path).read_bytes()).decode("utf-8")
    suffix = Path(path).suffix.lstrip(".").replace("jpg", "jpeg")
    return {
        "type": "image_url",
        "image_url": {"url": f"data:image/{suffix};base64,{data}"},
    }

ส่งหลายรูปด้วยหลายบล็อก image_url:

content = [
    {"type": "text", "text": "Image 1 is the design. Image 2 is what we built. List the differences."},
    image_block("design.png"),
    image_block("built.png"),
]

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

ดูการตั้งค่าและการยืนยันตัวตนในคู่มือ API GLM-5.3-Flash

เวิร์กโฟลว์ที่ใช้งานได้จริง

ดีบัก UI จากภาพหน้าจอ

ส่งภาพหน้าจอที่ผิดพลาดพร้อมซอร์สโค้ดในคำขอเดียว เพื่อให้โมเดลวิเคราะห์ผลการเรนเดอร์จริงแทนคำอธิบายปัญหา:

content = [
    {"type": "text", "text": "This component renders incorrectly below 400px. Here is the screenshot and the source."},
    image_block("bug-mobile.png"),
    {"type": "text", "text": f"```
{% endraw %}
jsx\n{component_source}\n
{% raw %}
```"},
]

แนวทางนี้เหมาะกับการดีบัก CSS, responsive layout และองค์ประกอบ UI ที่ผิดจากที่คาดไว้ โดย Z.ai อธิบายการใช้งานวิชันของโมเดลว่าเน้นอินเทอร์เฟซ ผลลัพธ์การเรนเดอร์ และผลจากการโต้ตอบ

เปรียบเทียบดีไซน์กับสิ่งที่สร้างจริง

ส่งภาพดีไซน์และภาพหน้าจอของระบบที่สร้างแล้ว จากนั้นขอให้โมเดลระบุความแตกต่าง

ใช้ใน CI ได้เป็นชั้นคัดกรองเบื้องต้น:

1. เครื่องมือ visual diff ตรวจจับว่าพิกเซลเปลี่ยน
2. โมเดลช่วยประเมินว่าการเปลี่ยนนั้นมีความสำคัญหรือไม่
3. มนุษย์ตรวจสอบความแตกต่างที่ถูกจัดลำดับความสำคัญแล้ว

อย่าใช้ผลของโมเดลเป็นเกณฑ์ deploy เพียงอย่างเดียว เพราะเป็นการตัดสิน ไม่ใช่การยืนยันความถูกต้อง

ตรวจเอกสารกับข้อกำหนด

หน้าต่างบริบท 1M ช่วยให้ส่งข้อกำหนดยาว ๆ เป็นข้อความ พร้อมภาพผลลัพธ์ที่สร้างขึ้น แล้วตรวจว่าเป็นไปตามข้อกำหนดหรือไม่:

content = [
    {"type": "text", "text": f"Specification:\n\n{spec_text}"},
    {"type": "text", "text": "Below is the generated report. Does it satisfy every requirement above? List gaps."},
    image_block("generated-report.png"),
]

การส่งข้อกำหนด 40 หน้าและรูปภาพในพรอมต์เดียวทำได้ยากกับหน้าต่างบริบท 128K หรือวิชันผ่านอะแดปเตอร์ บันทึกการเปิดตัวของ Z.ai ยังระบุเอกสารสำนักงานและเวิร์กโฟลว์วิจัยการเงินเป็นกรณีใช้งานของพฤติกรรมเชิงตัวแทน

แยกข้อมูลจากแผนภูมิและแดชบอร์ด

ขอผลลัพธ์เป็น JSON แล้วตรวจสอบกับ Schema:

content = [
    {"type": "text", "text": "Extract the series in this chart as JSON: [{label, values: [...]}]. Return only JSON."},
    image_block("quarterly.png"),
]

การตรวจ Schema ตรวจจับโครงสร้างผลลัพธ์ที่ผิดรูปแบบได้ แต่ไม่รับประกันว่าตัวเลขที่อ่านจากแผนภูมิถูกต้อง หากข้อมูลมีความสำคัญ ให้ใช้ข้อมูลต้นทางแทนการอ่านจากภาพ

สำหรับการแยกเอกสารโดยเฉพาะ GLM-OCR สำหรับการทำความเข้าใจเอกสาร อาจเหมาะกว่าโมเดลทั่วไป

วิดีโอและไฟล์

เอกสารของ Z.ai ระบุว่ารองรับวิดีโอและไฟล์ผ่านกลไก content blocks เดียวกันกับรูปภาพ

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

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

ข้อจำกัดที่ต้องออกแบบเผื่อไว้

ตัวเลขจากแผนภูมิอาจมั่นใจแต่ผิดพลาด

Schema ตรวจรูปแบบได้ แต่ไม่ตรวจความถูกต้องของค่าที่ดูสมเหตุสมผล หากตัวเลขสำคัญ ให้ดึงจากข้อมูลต้นทาง

ข้อความขนาดเล็กมีความแม่นยำลดลง

UI ที่หนาแน่น ตารางความละเอียดต่ำ หรือโค้ดในภาพที่บีบอัดอาจอ่านผิดได้ ควรครอบตัดเฉพาะบริเวณที่สนใจแทนการย่อทั้งภาพ

ความแม่นยำเชิงพื้นที่มีจำกัด

โมเดลระบุปัญหาเชิงเลย์เอาต์ได้ดี เช่น “ปุ่มทับช่องป้อนข้อมูล” แต่ไม่ควรเชื่อการวัดระดับพิกเซล เช่น “ห่างจากขอบซ้ายเกิน 12 พิกเซล”

รูปภาพหลายรูปอาจทำให้การอ้างอิงสับสน

ติดป้ายกำกับรูปภาพในข้อความให้ชัดเจน และลดจำนวนรูปภาพต่อคำขอเมื่อความแม่นยำสำคัญ

ข้อจำกัดเหล่านี้เป็นเรื่องปกติของ vision language model รวมถึงโมเดลที่มีคะแนนดัชนีอัจฉริยะ 57 ดังนั้นเวิร์กโฟลว์ควรออกแบบให้ตรวจจับคำตอบผิดพลาดได้ก่อนนำไปใช้จริง

ค่าใช้จ่าย

รูปภาพใช้โทเค็นอินพุตและไม่มีค่าธรรมเนียมรูปภาพแยกต่างหาก

• ราคาปกติ: $0.15 ต่อหนึ่งล้านโทเค็นอินพุต
• ราคาเปิดตัว: $0.075 ต่อหนึ่งล้านโทเค็นอินพุต
• ราคาเปิดตัวใช้ได้ถึง 9 กันยายน 2026

ความละเอียดสูงใช้โทเค็นมากขึ้น จึงควรลดขนาดภาพก่อนส่ง เว้นแต่รายละเอียดเล็ก ๆ คือประเด็นหลักของคำขอ

reasoning_effort มีค่าเริ่มต้นเป็น max และคิดค่าใช้จ่ายเป็นโทเค็นเอาต์พุต สำหรับการแยกข้อมูลจากภาพแบบตรงไปตรงมา low มักเพียงพอและประหยัดกว่า ดูรายละเอียดในการแจกแจงราคา GLM-5.3-Flash

ควบคุมต้นทุนรูปภาพ

แนวทางที่ควรใช้:

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

ตรวจค่าใช้จ่ายจริงจากออบเจ็กต์ usage ในแต่ละการตอบกลับ แทนการเดาจากขนาดไฟล์

ทดสอบคำขอมัลติโมดัล

การทดสอบคำขอมัลติโมดัลด้วยมือทำได้ยาก เพราะ base64 data URL ยาวมากและคำตอบเป็นข้อความอิสระ

แนวทางที่ใช้งานได้:

1. สร้างชุดรูปภาพอ้างอิงขนาดเล็กพร้อมคำตอบที่คาดหวัง
2. รันชุดทดสอบซ้ำเมื่อเปลี่ยนโมเดลหรือผู้ให้บริการ
3. ตรวจผลลัพธ์ JSON ด้วย Schema แทนการตรวจด้วยสายตา

Apidog ช่วยจัดเก็บเพย์โหลดรูปภาพในคำขอที่บันทึกไว้ เก็บ API key เป็น environment variables และเพิ่ม assertions สำหรับผลลัพธ์ JSON ได้ เมื่อโมเดลหรือผู้ให้บริการเปลี่ยนแปลง คุณจะตรวจได้ทันทีว่าเส้นทางวิชันยังทำงานถูกต้องหรือไม่

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

GLM-5.3 รองรับรูปภาพด้วยหรือไม่?

ไม่ใช่แบบเนทีฟ GLM-5.3 ส่งวิชันผ่านอะแดปเตอร์แยกต่างหาก ส่วน Flash เป็นโมเดลมัลติโมดัลแบบเนทีฟ ดูการเปรียบเทียบ GLM-5.3-Flash กับ GLM-5.3

ส่งได้กี่รูปภาพต่อคำขอ?

ส่งได้หลายรูป โดยแต่ละรูปต้องเป็นบล็อก image_url ของตัวเอง ขีดจำกัดจริงขึ้นอยู่กับบริบทที่ใช้

ควรใช้ URL หรือ base64?

ใช้ได้ทั้งคู่ ใช้ URL สำหรับภาพสาธารณะที่เข้าถึงได้อยู่แล้ว และใช้ base64 สำหรับภาพในเครื่องหรือภาพส่วนตัว

รองรับวิดีโอหรือไม่?

Z.ai ระบุว่ารองรับวิดีโอ แต่ฟีเจอร์ยังใหม่ ควรทดสอบกับสื่อและผู้ให้บริการของคุณก่อนใช้งานจริง

รูปภาพคิดค่าบริการแยกหรือไม่?

ไม่ รูปภาพใช้โทเค็นอินพุต ดังนั้นความละเอียดของภาพมีผลโดยตรงต่อค่าใช้จ่าย