Thanawat Wongchai

Posted on Aug 27 Originally published at apidog.com

วิธีทดสอบ GLM-5.3-Flash API ใน Apidog

ทดสอบและเปรียบเทียบ GLM-5.3-Flash กับ GLM-5.3 ด้วย Apidog

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

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

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

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

ทำไมไม่ใช้แค่ curl

คุณสามารถทดสอบ API ด้วย curl ได้ และ คู่มือ API ของเรา ก็แสดงตัวอย่างไว้ แต่เมื่อการทดสอบมีมากกว่าคำขอแรก จะเกิดข้อจำกัดสองประการ:

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

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

ตั้งค่าสภาพแวดล้อม

สร้าง environment variables สำหรับค่าที่อาจเปลี่ยนระหว่างการรัน โดยเฉพาะรหัสโมเดล วิธีนี้ทำให้คุณสลับโมเดลทั้งชุดได้โดยไม่ต้องแก้ทุกคำขอ

ตัวแปร	ค่า
`base_url`	`https://api.z.ai/api/paas/v4`
`api_key`	คีย์ Z.ai ของคุณ
`model`	`glm-5.3-flash`

เก็บ API key เป็น environment variable แทนการใส่ไว้ในส่วนหัวโดยตรง เพื่อป้องกันการส่งออกหรือแชร์คีย์โดยไม่ตั้งใจเมื่อแชร์ชุดข้อมูลกับทีม

คำขอที่ 1: การเติมข้อความ

สร้างคำขอ POST ไปยัง {{base_url}}/chat/completions

ส่วนหัว:

[REDACTED CREDENTIAL] {{api_key}}
Content-Type: application/json

เนื้อหา:

{
  "model": "{{model}}",
  "messages": [
    {"role": "user", "content": "ตอบว่า: OK"}
  ],
  "reasoning_effort": "low"
}

สำหรับโมเดลนี้ ค่าเริ่มต้นของ reasoning_effort คือ max ซึ่งจะนับโทเค็นการให้เหตุผลเป็นโทเค็นเอาต์พุต สำหรับการตรวจสอบการเชื่อมต่อ ให้ใช้ low เพื่อลดค่าใช้จ่ายที่ไม่จำเป็น

เพิ่มการยืนยันผลต่อไปนี้:

รหัสสถานะเท่ากับ 200
choices[0].message.content มีอยู่
choices[0].finish_reason เท่ากับ stop
usage.total_tokens มีอยู่

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

คำขอที่ 2: การเรียกใช้รูปภาพ

คำขอนี้แสดงความคุ้มค่าของ GLM-5.3-Flash ได้ชัดเจน เพราะโมเดลรองรับรูปภาพโดยตรง ขณะที่ GLM-5.3 ไม่รองรับ

ใช้ปลายทางเดิม แต่เปลี่ยน content เป็นอาร์เรย์ของบล็อกที่มีประเภท:

{
  "model": "{{model}}",
  "messages": [
    {
      "role": "user",
      "content": [
        {"type": "text", "text": "รูปทรงที่เด่นชัดในภาพนี้มีสีอะไร? ตอบด้วยคำเดียว"},
        {"type": "image_url", "image_url": {"url": "{{test_image_url}}"}}
      ]
    }
  ],
  "reasoning_effort": "low"
}

เพิ่ม test_image_url ใน environment โดยชี้ไปยังรูปภาพที่:

เข้าถึงได้จากสาธารณะ
มี URL ที่เสถียร
คุณทราบคำตอบที่ถูกต้องล่วงหน้า

คำถามที่กำหนดตายตัวกับรูปภาพเดิมทำให้คำขอนี้เป็น regression test ไม่ใช่เพียงการสาธิต

สำหรับรูปภาพในเครื่อง ฟิลด์เดียวกันสามารถรับ Base64 data URL ได้:

data:image/png;base64,iVBORw0KGgo...

เก็บค่าไว้ใน environment variable เพื่อให้เนื้อหาคำขอยังคงอ่านง่าย:

{{test_image_url}}

การยืนยันผล:

รหัสสถานะเท่ากับ 200
choices[0].message.content มีคำตอบที่ทราบอยู่แล้ว
usage.prompt_tokens มากกว่าจำนวนโทเค็นของคำขอข้อความเท่านั้น

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

อ่านรายละเอียดช่องทางวิชั่นและโหมดความล้มเหลวเพิ่มเติมใน คู่มือ GLM-5.3-Flash vision ของเรา

คำขอที่ 3: การเรียกใช้เครื่องมือ

หากแอปใช้ function calling ให้ทดสอบเส้นทางนี้โดยตรง เพราะรูปแบบ tool call เป็นส่วนที่ละเอียดอ่อนของการผสานรวมโมเดล และมักได้รับผลกระทบจากการอัปเดตของผู้ให้บริการ

{
  "model": "{{model}}",
  "messages": [
    {"role": "user", "content": "บริการ checkout-api ทำงานปกติดีหรือไม่?"}
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_deployment_status",
        "description": "ส่งคืนสถานะปัจจุบันของการติดตั้งใช้งานที่ระบุชื่อ",
        "parameters": {
          "type": "object",
          "properties": {
            "service": {"type": "string", "description": "ชื่อบริการ"}
          },
          "required": ["service"]
        }
      }
    }
  ]
}

การยืนยันผล:

choices[0].message.tool_calls มีอยู่และไม่ว่างเปล่า
choices[0].message.tool_calls[0].function.name เท่ากับ get_deployment_status
choices[0].finish_reason เท่ากับ tool_calls

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

หากต้องสร้าง tool definition จาก API ที่มีอยู่แล้ว การเปลี่ยน OpenAPI spec ให้เป็นเครื่องมือของเอเจนต์ อธิบายวิธีทำโดยไม่ต้องเขียน Schema ด้วยมือ

เปรียบเทียบกับ GLM-5.3

การเก็บรหัสโมเดลไว้ใน environment ทำให้การเปรียบเทียบทำได้ง่าย:

ทำสำเนา environment
เปลี่ยน model เป็น glm-5.3
เรียกใช้ชุดทดสอบเดิม
เปรียบเทียบผลลัพธ์ทั้งสามด้านต่อไปนี้

1. ความถูกต้อง

การยืนยันผลยังผ่านหรือไม่?

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

2. เวลาแฝง

Apidog รายงานเวลาตอบสนองของแต่ละคำขอ โดย GLM-5.3 คาดว่าจะเสร็จเร็วกว่าในเอาต์พุตที่ยาวกว่า เพราะสร้างได้ประมาณ 86 โทเค็นต่อวินาที เทียบกับ 49 โทเค็นต่อวินาทีของ Flash

3. ค่าใช้จ่าย

อ็อบเจกต์ usage ให้ค่า prompt_tokens และ completion_tokens ต่อคำขอ เมื่อนำไปคูณกับอัตราของแต่ละโมเดล คุณจะได้ค่าใช้จ่ายจริงต่อคำขอแทนตัวเลขทางการตลาดแบบรวม

ดูอัตราปัจจุบันได้จาก การวิเคราะห์ราคาของเรา และอ่านข้อดีของแต่ละโมเดลได้จาก การเปรียบเทียบโมเดลฉบับเต็ม

ตรวจสอบ completion_tokens โดยเฉพาะเมื่อเปลี่ยน reasoning_effort ค่าเริ่มต้น max จะเรียกเก็บโทเค็นการให้เหตุผลเป็นเอาต์พุต ดังนั้นคำตอบที่ดูสั้นอาจมีจำนวนโทเค็นสูงอยู่เบื้องหลัง

ให้รันพรอมต์เดียวกันด้วยค่า low, high และ max แล้วเปรียบเทียบจำนวนโทเค็น เพื่อดูว่าปริมาณงานของคุณต้องการระดับใดจริง ๆ

ทดสอบการติดตั้งใช้งานในเครื่อง

หากโฮสต์โมเดลเอง ทั้ง vLLM และ SGLang ต่างก็เปิดเผยปลายทางที่เข้ากันได้กับ OpenAI เพียงเปลี่ยน base_url ไปยังเซิร์ฟเวอร์ของคุณ แล้วรันชุดทดสอบเดิม

นี่เป็นประโยชน์สำคัญของชุดทดสอบแบบทำซ้ำได้ รุ่น quantized อาจผ่านการทดสอบแชทพื้นฐาน แต่ยังจัดการ tool schema ผิดพลาดหรือประมวลผลรูปภาพได้แย่ลง ซึ่งเป็นปัญหาที่มักปรากฏใน production มากกว่าการตรวจสอบเบื้องต้น

ดูรายละเอียดการติดตั้งใช้งานได้จาก คู่มือการรันในเครื่องของเรา

นำไปใช้ใน CI

เมื่อชุดทดสอบเสถียรแล้ว ให้เรียกใช้ตามกำหนดเวลาหรือใน pipeline โดยใช้ trigger เหล่านี้:

ก่อนย้ายโมเดล เพื่อยืนยันว่าพร้อมดำเนินการต่อ
ตามกำหนดเวลา เพื่อตรวจจับการเปลี่ยนแปลงจากผู้ให้บริการที่ไม่ได้ประกาศ
หลังอัปเดต dependency เพื่อจับการเปลี่ยนแปลงที่ SDK อาจทำกับคำขอ

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

สิ่งที่ควรทดสอบเพิ่มเติม

เมื่อกรณีปกติผ่านแล้ว ให้เพิ่มกรณีต่อไปนี้ตามการใช้งานจริง:

บริบทขนาดยาวในความยาวที่ระบบใช้จริง พฤติกรรมที่ 500K โทเค็นไม่จำเป็นต้องเหมือนกับที่ 5K โทเค็น
อินพุตผิดรูปแบบ เพื่อยืนยันการจัดการข้อผิดพลาด
การตอบกลับแบบ rate limit หากสามารถจำลองได้ เพื่อตรวจสอบ retry logic
รูปภาพหลายภาพในคำขอเดียว โดยแต่ละภาพต้องมีบล็อก image_url ของตัวเอง
การสตรีม หากแอปใช้ เพราะรูปแบบการตอบกลับแตกต่างจากการเติมข้อความปกติ

สรุป

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

Apidog เริ่มต้นใช้งานได้ฟรี และการนำเข้า Schema ที่เข้ากันได้กับ OpenAI ช่วยลดเวลาตั้งค่า ชุดทดสอบที่ได้จะเปลี่ยนการสลับโมเดลครั้งต่อไปจากการก้าวกระโดดครั้งใหญ่ให้เป็นการเปลี่ยนแปลงที่ตรวจสอบได้

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

ฉันจำเป็นต้องมีแผน Apidog แบบเสียเงินหรือไม่?

ไม่จำเป็น ชุดข้อมูลที่มี environment variables และการยืนยันผลทำงานได้ในระดับฟรี

ฉันจะทดสอบรูปภาพ Base64 โดยไม่ทำให้เนื้อหาคำขออ่านยากได้อย่างไร?

เก็บ data URL เป็น environment variable แล้วอ้างอิงด้วย {{test_image_url}}

ฉันสามารถทดสอบปลายทาง coding-plan ด้วยวิธีเดียวกันได้หรือไม่?

ได้ เปลี่ยน base_url เป็น https://api.z.ai/api/coding/paas/v4 แต่โปรดทราบว่าปลายทางนี้แตกต่างจาก API มาตรฐาน ตามที่อธิบายไว้ใน คู่มือ Claude Code and Cline ของเรา

การทดสอบนี้ใช้กับผู้ให้บริการรายอื่นได้หรือไม่?

ส่วนใหญ่ได้ OpenRouter, Cloudflare Workers AI และ Vercel AI Gateway ต่างก็มีส่วนเชื่อมต่อที่เข้ากันได้กับ OpenAI เพียงเปลี่ยน base_url และ namespace ของรหัสโมเดล

ฉันจะยืนยันการตอบกลับที่ไม่แน่นอนได้อย่างไร?

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

DEV Community