โมเดลวิชันส่วนใหญ่จะให้คุณเลือก คุณสามารถส่งรูปภาพ หรือส่งข้อความจำนวนมากได้ แต่โมเดลที่ทำงานอย่างใดอย่างหนึ่งได้ดี มักจะไม่ใช่โมเดลที่ทำงานอีกอย่างหนึ่งได้ดีเช่นกัน
GLM-5.3-Flash ไม่ได้ให้คุณเลือก มันยอมรับรูปภาพเป็นบล็อกเนื้อหาภายในหน้าต่างบริบทขนาด 1,048,576 โทเค็น ในคำขอเดียวกันกับสิ่งอื่น ๆ ทั้งหมด การรวมกันนี้ ซึ่งเป็นการป้อนข้อมูลรูปภาพแบบเนทีฟพร้อมกับพื้นที่หนึ่งล้านโทเค็น เปิดช่องทางให้การทำงานที่ความสามารถใด ๆ เพียงอย่างเดียวไม่สามารถทำได้
คู่มือนี้ครอบคลุมถึงเพย์โหลด, ขั้นตอนการทำงานที่น่าสร้างสรรค์ และส่วนที่ยังไม่ได้รับการพิสูจน์
แบบเนทีฟ ไม่ใช่แบบอแดปเตอร์
Z.ai’s งานวิชันก่อนหน้าถูกส่งออกมาในรูปแบบโมเดลแยกต่างหาก GLM-5V-Turbo และ GLM-4.6V เป็นปลายทางที่แตกต่างกันพร้อมรหัสโมเดลที่แตกต่างกัน และการใช้งานหมายถึงการกำหนดเส้นทางการรับส่งข้อมูลรูปภาพไปยังที่อื่นที่ไม่ใช่การรับส่งข้อมูลข้อความของคุณ GLM-5.3 ซึ่งเป็นพี่ใหญ่ของโมเดลนี้ กำหนดเส้นทางวิชันผ่านอะแดปเตอร์แทนที่จะจัดการแบบเนทีฟ
GLM-5.3-Flash เป็นโมเดลแรกในซีรีส์ GLM-5 ที่รูปภาพเป็นอินพุตระดับเฟิร์สคลาสสำหรับโมเดลเดียวกัน ในการเรียกใช้เดียวกัน และแชร์บริบทเดียวกัน
ในทางปฏิบัติ นั่นหมายถึงรหัสโมเดลเดียว, บรรทัดการเรียกเก็บเงินเดียว, ชุดข้อจำกัดอัตราเดียว และที่สำคัญที่สุดคือ หน้าต่างบริบทเดียวที่เก็บทั้งรูปภาพและข้อความของคุณพร้อมกัน หากคุณกำลังดูแลสิ่งใด ๆ บนเส้นทางเก่า คู่มือ API GLM-5V-Turbo ของเรา และ คู่มือ GLM-4.6V ครอบคลุมโมเดลเหล่านั้น
เพย์โหลด
การป้อนข้อมูลรูปภาพทำงานผ่านบล็อกเนื้อหาแบบมีประเภท แทนที่ content จะเป็นสตริง มันจะกลายเป็นอาร์เรย์:
from openai import OpenAI
import os
client = OpenAI(
api_key=os.environ["ZAI_API_KEY"],
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}"},
}
รูปภาพหลายรูปหมายถึงบล็อกหลายบล็อก ไม่มีอาร์เรย์ทางลัดของ 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 ของเรา
ขั้นตอนการทำงานที่น่าสร้างสรรค์
การดีบักด้วยภาพหน้าจอ
เป็นสิ่งหนึ่งที่ชัดเจนและ Z.ai ให้ความสำคัญ เอกสารของ Z.ai อธิบายว่าโมเดลสังเกต “อินเทอร์เฟซ, ผลลัพธ์การเรนเดอร์ และการตอบสนองจากการโต้ตอบ” ซึ่งเป็นการกำหนดกรอบในเชิงตัวแทนการโค้ดมากกว่าการอธิบายรูปภาพ
ส่งการเรนเดอร์ที่เสียและซอร์สโค้ดที่สร้างมันมาในคำขอเดียวกัน:
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"```jsx\n{component_source}\n```"},
]
โมเดลจะให้เหตุผลเกี่ยวกับการเรนเดอร์จริง ๆ แทนที่จะเป็นคำอธิบายของคุณ นั่นช่วยขจัดขั้นตอนที่ข้อมูลสูญหายมากที่สุดในการสนทนาการดีบักส่วนหน้าส่วนใหญ่ ซึ่งก็คือการที่มนุษย์ต้องแปลปัญหาทางภาพเป็นคำพูด
การเปรียบเทียบการออกแบบ
รูปภาพสองรูปและคำถามหนึ่งข้อ มีประโยชน์ใน CI เป็นการตรวจสอบเบื้องต้นเกี่ยวกับการถดถอยทางภาพ โดยที่เครื่องมือเปรียบเทียบจะบอกว่าพิกเซลมีการเปลี่ยนแปลง และโมเดลจะบอกว่าการเปลี่ยนแปลงนั้นสำคัญหรือไม่
ควรมีความเป็นจริงเกี่ยวกับความน่าเชื่อถือในที่นี้ การที่โมเดลเปรียบเทียบภาพหน้าจอเป็นการตัดสินใจ ไม่ใช่การยืนยัน ใช้เพื่อจัดลำดับความสำคัญว่าความแตกต่างใดที่มนุษย์ควรตรวจสอบ ไม่ใช่เพื่อใช้เป็นเกณฑ์ในการปรับใช้เพียงลำพัง
เอกสารคู่กับข้อกำหนด
นี่คือที่ที่บริบท 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 แล้วตรวจสอบความถูกต้อง:
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 ระบุการป้อนข้อมูลวิดีโอและไฟล์ควบคู่ไปกับรูปภาพ โดยใช้กลไกบล็อกเนื้อหาเดียวกัน
โปรดระมัดระวังในเรื่องนี้ การสนับสนุนวิดีโอในโมเดลนี้เป็นของใหม่ มีเอกสารประกอบน้อย และมีการใช้งานสาธารณะไม่มากนักเมื่อเทียบกับการป้อนข้อมูลรูปภาพ ซึ่งมีผู้ใช้งานจำนวนมากแล้ว การสนับสนุนของผู้ให้บริการก็แตกต่างกัน: ความสามารถของโมเดลไม่เหมือนกับคุณสมบัติที่มีอยู่บนเกตเวย์ที่คุณใช้
หากวิดีโอมีความสำคัญต่อแอปพลิเคชันของคุณ ให้ทดสอบโดยตรงกับสื่อของคุณเองและผู้ให้บริการของคุณก่อนที่คุณจะออกแบบโดยอิงจากมัน อย่าถือว่าบรรทัดในตารางความสามารถเป็นคุณสมบัติที่ใช้งานได้จริง
จุดอ่อน
มัลติโมดัลแบบเนทีฟไม่เหมือนกับมัลติโมดัลที่น่าเชื่อถือ มีสี่โหมดความล้มเหลวที่ควรทราบก่อนที่คุณจะนำไปใช้งานจริง
ตัวเลขที่มั่นใจจากแผนภูมิ. การอ่านค่าจากเส้นกราฟเป็นงานที่มีแนวโน้มมากที่สุดที่จะสร้างคำตอบที่ดูเหมือนถูกต้อง รูปแบบสวยงาม แต่ผิดพลาด การตรวจสอบ Schema สามารถตรวจจับผลลัพธ์ที่ผิดรูปแบบได้ แต่ไม่สามารถตรวจจับตัวเลขที่ดูน่าเชื่อถือแต่ไม่ถูกต้องได้ หากตัวเลขมีความสำคัญ ให้ดึงมาจากข้อมูลพื้นฐานแทนที่จะเป็นรูปภาพ
ข้อความขนาดเล็ก. ภาพหน้าจอ UI ที่หนาแน่น, ตารางในภาพที่ความละเอียดต่ำ และโค้ดในภาพที่บีบอัด ล้วนมีคุณภาพลดลง การลดขนาดเพื่อประหยัดโทเค็นทำให้แย่ลงไปอีก ดังนั้นจึงมีความขัดแย้งโดยตรงระหว่างตัวแปรด้านต้นทุนและความแม่นยำ ควรครอบตัดไปยังบริเวณที่สนใจแทนที่จะย่อทั้งเฟรม
ความแม่นยำเชิงพื้นที่. โมเดลอธิบายเลย์เอาต์ได้ดีแต่การวัดทำได้ไม่ดี “ปุ่มทับกับช่องป้อนข้อมูล” มักจะถูกต้อง “ปุ่มอยู่ห่างจากขอบซ้ายมากเกินไป 12 พิกเซล” มักจะไม่ถูกต้อง
ความสับสนเรื่องลำดับและการอ้างอิง. เมื่อมีรูปภาพหลายรูปในคำขอเดียว โมเดลอาจระบุรายละเอียดผิดรูปได้ ควรติดป้ายกำกับให้ชัดเจนในบล็อกข้อความ และจำกัดจำนวนรูปภาพให้น้อยเมื่อความแม่นยำเป็นสิ่งสำคัญ
ข้อจำกัดเหล่านี้ไม่ได้เป็นเอกลักษณ์เฉพาะของ GLM-5.3-Flash เป็นข้อจำกัดมาตรฐานของโมเดลภาษาเชิงวิชัน และคะแนนดัชนีอัจฉริยะ 57 ก็ไม่ได้ยกเว้นมัน ออกแบบขั้นตอนการทำงานเพื่อให้คำตอบที่ผิดพลาดถูกตรวจจับได้แทนที่จะนำไปปฏิบัติ
ค่าใช้จ่าย
รูปภาพใช้โทเค็นบริบทและถูกเรียกเก็บเงินเป็นอินพุต ไม่มีค่าธรรมเนียมรูปภาพเพิ่มเติมแยกต่างหาก
ที่ราคาปกติอยู่ที่ $0.15 ต่อหนึ่งล้านโทเค็นอินพุต หรือ $0.075 ในช่วงส่วนลดเปิดตัวที่ใช้ได้ถึง 9 กันยายน 2026 รูปภาพความละเอียดสูงจะใช้โทเค็นจำนวนมาก ดังนั้นความละเอียดจึงเป็นปัจจัยด้านต้นทุน: ควรลดขนาดก่อนส่ง เว้นแต่ว่ารายละเอียดเล็ก ๆ น้อย ๆ เป็นประเด็นหลักของคำขอ
reasoning_effort มีค่าเริ่มต้นเป็น max ซึ่งจะเรียกเก็บเงินสำหรับการให้เหตุผลเป็นโทเค็นเอาต์พุต สำหรับการแยกข้อมูลจากรูปภาพโดยตรง low มักจะเป็นการตั้งค่าที่เหมาะสมและมีราคาถูกกว่ามาก การแจกแจงราคาของเรา ครอบคลุมทั้งสองปัจจัย
การควบคุมค่าใช้จ่ายรูปภาพ
รูปภาพถูกเรียกเก็บเงินเป็นโทเค็นอินพุต ดังนั้นความละเอียดจึงเป็นปัจจัยด้านต้นทุนโดยตรง และการเพิ่มประสิทธิภาพที่ชัดเจนนั้นขัดแย้งกับข้อสังเกตเรื่องความแม่นยำที่กล่าวมาข้างต้น
ลำดับการดำเนินการที่ใช้งานได้จริง:
- ครอบตัดก่อนปรับขนาด. การส่งพื้นที่ที่เกี่ยวข้องด้วยความละเอียดเต็มดีกว่าการส่งทั้งหน้าจอที่ความละเอียดครึ่งหนึ่ง คุณจะสูญเสียบริบทที่โมเดลไม่ต้องการและยังคงรักษาข้อมูลที่ละเอียดไว้ได้
- ปรับความละเอียดให้เข้ากับคำถาม. “เลย์เอาต์เสียหรือเปล่า?” สามารถรอดพ้นจากการลดขนาดอย่างรุนแรงได้ “ข้อความแสดงข้อผิดพลาดนี้ว่าอย่างไร?” ทำไม่ได้
- อย่าส่งรูปภาพที่ไม่เปลี่ยนแปลงซ้ำ. ในการสนทนาแบบหลายรอบ รูปภาพที่ส่งไปแล้วหนึ่งครั้งจะอยู่ในบริบทแล้ว การแนบซ้ำทุกรอบจะทำให้คุณต้องจ่ายเงินทุกรอบ
- ตั้งค่า
reasoning_effortอย่างรอบคอบ. ค่าเริ่มต้นคือmaxและการให้เหตุผลจะถูกเรียกเก็บเงินเป็นเอาต์พุต การแยกข้อมูลแบบตรงไปตรงมาไม่ค่อยต้องการมัน
ออบเจกต์ usage ในแต่ละการตอบกลับจะให้จำนวนโทเค็นจริงต่อการเรียก ซึ่งเป็นวิธีเดียวที่จะทราบต้นทุนที่แท้จริงของรูปภาพ แทนที่จะคาดเดาจากขนาดไฟล์
การทดสอบการเรียกใช้แบบมัลติโมดัล
คำขอแบบมัลติโมดัลเป็นเรื่องที่ทดสอบด้วยตนเองได้ไม่สะดวก base64 data URL มีอักขระหลายพันตัว ซึ่งทำให้คำสั่ง curl อ่านยากและไม่สามารถรันซ้ำได้จริงโดยการแก้ไข การตอบกลับเป็นข้อความรูปแบบอิสระ ดังนั้นข้อผิดพลาดจึงพลาดได้ง่าย
มีสองนิสัยที่ช่วยได้ เก็บชุดรูปภาพอ้างอิงและคำตอบที่คาดหวังไว้จำนวนน้อย ๆ เพื่อให้คุณสามารถทราบได้เมื่อพฤติกรรมเปลี่ยนไป และตรวจสอบความถูกต้องของการแยกข้อมูลที่มีโครงสร้างกับ Schema แทนที่จะใช้การมองด้วยตาเปล่า
Apidog เป็นเครื่องมือที่ใช้งานได้จริงสำหรับสิ่งนี้ จัดเก็บเพย์โหลดรูปภาพไว้ในคำขอที่บันทึกไว้แทนคำสั่งเชลล์, เก็บ API key เป็นตัวแปรสภาพแวดล้อม และแนบข้อกำหนดการยืนยัน (assertions) กับ JSON ที่พรอมต์การแยกข้อมูลของคุณส่งกลับ เมื่อคุณเปลี่ยนโมเดลหรือผู้ให้บริการอัปเดตสิ่งใด ๆ การรันชุดทดสอบซ้ำจะบอกคุณว่าเส้นทางวิชันยังคงทำงานปกติหรือไม่ แทนที่จะปล่อยให้คุณไปรู้จากผู้ใช้งาน
คำถามที่พบบ่อย
GLM-5.3 รองรับรูปภาพด้วยหรือไม่? ไม่ใช่แบบเนทีฟ GLM-5.3 กำหนดเส้นทางวิชันผ่านอะแดปเตอร์แยกต่างหาก Flash เป็นโมเดลแบบมัลติโมดัลที่รองรับแบบเนทีฟ ซึ่งครอบคลุมอยู่ใน การเปรียบเทียบของเรา
กี่รูปภาพต่อหนึ่งคำขอ? หลายรูป แต่ละรูปเป็นบล็อก image_url ของตัวเอง ขีดจำกัดที่ใช้งานได้จริงคือปริมาณบริบทที่คุณมี
URL หรือ base64? ใช้ได้ทั้งคู่ ใช้ URL สาธารณะเมื่อรูปภาพถูกโฮสต์และเข้าถึงได้อยู่แล้ว; ใช้ base64 สำหรับรูปภาพภายในเครื่องหรือส่วนตัว
รองรับวิดีโอหรือไม่? Z.ai มีเอกสารระบุการป้อนข้อมูลวิดีโอ แต่เป็นคุณสมบัติใหม่และยังมีการใช้งานไม่มากนัก โปรดตรวจสอบกับสื่อและผู้ให้บริการของคุณเองก่อน
รูปภาพถูกเรียกเก็บเงินต่างกันหรือไม่? ไม่มีค่าธรรมเนียมเพิ่มเติม รูปภาพใช้โทเค็นอินพุต ดังนั้นความละเอียดจึงมีผลต่อค่าใช้จ่าย