Sebastian Petrus

Posted on Aug 27 Originally published at apidog.com

Cách kiểm tra API GLM-5.3-Flash trong Apidog

Kiểm tra GLM-5.3-Flash bằng Apidog: văn bản, hình ảnh, gọi công cụ và CI

Thay đổi ID LLM chỉ là một dòng code, nhưng có thể làm đổi độ trễ, chi phí token, định dạng đầu ra, hành vi gọi công cụ và khả năng xử lý ảnh. GLM-5.3-Flash rẻ hơn GLM-5.3 khoảng chín lần, hỗ trợ hình ảnh nguyên bản trong khi GLM-5.3 không hỗ trợ, nhưng tốc độ tạo văn bản chỉ bằng khoảng một nửa. Cách đáng tin cậy để chọn mô hình là chạy cùng các yêu cầu thực tế trên cả hai.

Dùng thử Apidog ngay hôm nay

Hướng dẫn này tạo một bộ sưu tập kiểm thử có thể tái sử dụng trong Apidog cho GLM-5.3-Flash: chat văn bản, thị giác, function calling, xác nhận phản hồi và so sánh mô hình.

Vì sao không chỉ dùng curl?

Bạn có thể bắt đầu bằng curl; hướng dẫn API của chúng tôi có ví dụ đầy đủ. Nhưng khi cần chạy lại nhiều lần, hai vấn đề nhanh chóng xuất hiện:

Ảnh Base64 khó quản lý. URL dữ liệu có thể dài hàng nghìn ký tự, khiến lệnh terminal khó đọc, khó sửa và không phù hợp để tái sử dụng.
Không có xác nhận tự động. Curl chỉ cho biết request thành công; không đảm bảo phản hồi vẫn chứa các trường mà ứng dụng phụ thuộc.

Một collection đã lưu giải quyết cả hai: payload có thể chỉnh sửa và các assertion được chạy ở mỗi lần gửi yêu cầu.

1. Thiết lập môi trường

Tạo environment với các biến sau:

Biến	Giá trị
`base_url`	`https://api.z.ai/api/paas/v4`
`api_key`	khóa Z.ai của bạn
`model`	`glm-5.3-flash`

Giữ model ID dưới dạng biến để bạn có thể chạy lại toàn bộ collection với mô hình khác. Lưu API key trong environment thay vì dán vào header để tránh vô tình xuất hoặc chia sẻ khóa.

2. Kiểm tra hoàn thành văn bản

Tạo request POST tới:

{{base_url}}/chat/completions

Headers:

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

Body:

{
  "model": "{{model}}",
  "messages": [
    {"role": "user", "content": "Reply with exactly: OK"}
  ],
  "reasoning_effort": "low"
}

Đặt reasoning_effort thành low. Mặc định của mô hình là max, và token lý luận được tính phí như token đầu ra. Với kiểm tra kết nối cơ bản, chi phí đó không cần thiết.

Thêm các assertion:

Status code là 200
choices[0].message.content tồn tại
choices[0].finish_reason là stop
usage.total_tokens tồn tại

Kiểm tra finish_reason rất quan trọng. Giá trị length cho biết đầu ra đã bị cắt ở giới hạn token, không phải hoàn thành bình thường. Đây là cách rõ ràng để phát hiện phản hồi bị truncation.

3. Kiểm tra đầu vào hình ảnh

GLM-5.3-Flash hỗ trợ hình ảnh nguyên bản; GLM-5.3 thì không. Dùng cùng endpoint nhưng thay content bằng mảng block:

{
  "model": "{{model}}",
  "messages": [
    {
      "role": "user",
      "content": [
        {"type": "text", "text": "What color is the dominant shape in this image? Answer with one word."},
        {"type": "image_url", "image_url": {"url": "{{test_image_url}}"}}
      ]
    }
  ],
  "reasoning_effort": "low"
}

Thêm test_image_url vào environment. Hãy dùng ảnh công khai, ổn định và có đáp án rõ ràng để biến request này thành regression test thay vì demo.

Với ảnh cục bộ, lưu URL dữ liệu Base64 vào biến môi trường:

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

Các assertion nên có:

Status code là 200
choices[0].message.content chứa đáp án mong đợi
usage.prompt_tokens lớn hơn request chỉ có văn bản

Assertion token đặc biệt hữu ích: ảnh tiêu thụ token đầu vào. Nếu prompt_tokens không tăng, ảnh có thể đã bị bỏ qua dù API vẫn trả về 200.

Xem thêm hướng dẫn thị giác GLM-5.3-Flash để biết luồng xử lý ảnh và các chế độ lỗi.

4. Kiểm tra function calling

Nếu ứng dụng dùng function calling, hãy kiểm tra trực tiếp định dạng tool call. Đây là phần dễ bị ảnh hưởng nhất khi nhà cung cấp hoặc phiên bản mô hình thay đổi.

{
  "model": "{{model}}",
  "messages": [
    {"role": "user", "content": "Is the checkout-api service healthy?"}
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_deployment_status",
        "description": "Returns the current status of a named deployment.",
        "parameters": {
          "type": "object",
          "properties": {
            "service": {"type": "string", "description": "The service name."}
          },
          "required": ["service"]
        }
      }
    }
  ]
}

Thêm các assertion:

choices[0].message.tool_calls tồn tại và không rỗng
choices[0].message.tool_calls[0].function.name là get_deployment_status
choices[0].finish_reason là tool_calls

Đừng chỉ kiểm tra sự tồn tại của tool call. Kiểm tra tên hàm giúp phát hiện mô hình gọi sai tool khi bạn có nhiều công cụ.

Nếu đã có API, bạn có thể biến đổi spec OpenAPI thành công cụ tác tử thay vì viết schema thủ công.

5. So sánh với GLM-5.3

Nhân đôi environment, rồi đổi:

model = glm-5.3

Chạy lại cùng collection và so sánh ba điểm:

Tính đúng đắn: Các assertion có còn qua không? Request hình ảnh sẽ không qua vì GLM-5.3 không hỗ trợ ảnh nguyên bản. Đây là một phát hiện hợp lệ, không phải lỗi test.
Độ trễ: Apidog hiển thị response time cho từng request. Với đầu ra dài, GLM-5.3 có thể nhanh hơn: khoảng 86 token/giây so với 49 token/giây của Flash.
Chi phí: Dùng usage.prompt_tokens và usage.completion_tokens, sau đó nhân với đơn giá của từng model. Bạn sẽ có chi phí thực tế theo request thay vì con số marketing tổng quát.

Xem phân tích giá GLM-5.3-Flash và so sánh GLM-5.3-Flash với GLM-5.3.

Theo dõi kỹ completion_tokens ở các mức reasoning_effort. Chạy cùng prompt với low, high và max để xác định mức suy luận mà workload thực sự cần.

6. Kiểm tra triển khai cục bộ

Nếu tự host trọng số, vLLM và SGLang đều có endpoint tương thích OpenAI. Chỉ cần thay base_url bằng URL máy chủ của bạn rồi chạy lại collection.

Đây là cách phát hiện các lỗi mà smoke test không thấy: bản lượng tử hóa có thể trả lời chat cơ bản bình thường nhưng xử lý sai tool schema hoặc giảm chất lượng đầu vào hình ảnh. Hướng dẫn chạy GLM-5.3-Flash cục bộ bao gồm phần triển khai.

7. Đưa collection vào CI

Khi collection ổn định, chạy nó trong CI hoặc theo lịch:

Trước khi chuyển model, làm tín hiệu chấp thuận hoặc từ chối.
Theo lịch, để phát hiện thay đổi phía nhà cung cấp.
Sau khi cập nhật SDK hoặc dependency, để phát hiện thay đổi trong serialization request.

Nhà cung cấp có thể cập nhật mô hình phía sau một model ID ổn định. Kiểm tra định kỳ giúp bạn biết hành vi đã thay đổi trước khi người dùng phát hiện.

8. Kiểm tra ngoài happy path

Sau khi các request cơ bản hoạt động, bổ sung:

Context dài bằng đúng độ dài ứng dụng thực tế sử dụng; hành vi ở 500K token không thể suy ra từ 5K token.
Đầu vào lỗi để xác nhận xử lý lỗi.
Phản hồi rate limit để kiểm tra retry logic.
Nhiều ảnh trong một request; mỗi ảnh cần block image_url riêng.
Streaming nếu ứng dụng dùng stream, vì cấu trúc phản hồi khác completion thông thường.

Kết luận

Giá trị của collection không nằm ở từng request mà ở khả năng lặp lại. Khi giá thay đổi, Z.ai phát hành bản sửa đổi mới, hoặc đội ngũ cân nhắc đổi nhà cung cấp, bạn có thể đánh giá lại quyết định model trong khoảng ba mươi giây.

Apidog miễn phí để bắt đầu. Nhập schema tương thích OpenAI để thiết lập nhanh phần lớn request, sau đó giữ collection như một regression suite cho mọi lần thay đổi mô hình.

Câu hỏi thường gặp

Tôi có cần gói Apidog trả phí không?

Không. Collection có environment variables và assertion hoạt động trên gói miễn phí.

Làm cách nào để kiểm tra ảnh Base64 mà không làm body khó đọc?

Lưu data URL trong environment và dùng {{test_image_url}} trong request body.

Tôi có thể kiểm tra endpoint coding-plan tương tự không?

Có. Đổi base_url thành:

https://api.z.ai/api/coding/paas/v4

Endpoint này khác API tiêu chuẩn; xem hướng dẫn Claude Code và Cline.

Các test này có dùng được với nhà cung cấp khác không?

Phần lớn có. OpenRouter, Cloudflare Workers AI và Vercel AI Gateway đều có giao diện tương thích OpenAI. Thay base_url và model ID namespace phù hợp.

Làm sao xác nhận phản hồi không xác định trước?

Xác nhận cấu trúc và ràng buộc thay vì toàn bộ văn bản: sự tồn tại trường, kiểu dữ liệu, số token, finish_reason và chuỗi con cho câu hỏi có đáp án đã biết.

DEV Community