Hầu hết các mô hình thị giác yêu cầu bạn chọn. Bạn có thể gửi một hình ảnh, hoặc bạn có thể gửi nhiều văn bản, nhưng mô hình làm tốt cái này hiếm khi làm tốt cái kia.
GLM-5.3-Flash không bắt bạn phải lựa chọn. Nó chấp nhận hình ảnh dưới dạng các khối nội dung bên trong cửa sổ ngữ cảnh 1.048.576 token, trong cùng một yêu cầu với mọi thứ khác. Sự kết hợp đó, đầu vào hình ảnh gốc cộng với không gian một triệu token, mở ra các quy trình làm việc mà không khả năng nào có thể thực hiện được một mình.
Hướng dẫn này bao gồm tải trọng, các quy trình làm việc đáng xây dựng và những phần vẫn chưa được kiểm chứng.
Gốc, không dựa trên bộ điều hợp
Công việc thị giác trước đây của Z.ai được phát hành dưới dạng các mô hình riêng biệt. GLM-5V-Turbo và GLM-4.6V là các điểm cuối riêng biệt với các ID mô hình riêng biệt, và việc sử dụng chúng có nghĩa là định tuyến lưu lượng hình ảnh đến một nơi khác với lưu lượng văn bản của bạn. GLM-5.3, phiên bản lớn hơn của mô hình này, định tuyến thị giác thông qua các bộ điều hợp chứ không xử lý nó một cách tự nhiên.
GLM-5.3-Flash là mô hình đầu tiên trong dòng GLM-5 nơi hình ảnh là đầu vào hạng nhất cho cùng một mô hình, trong cùng một lời gọi, chia sẻ cùng một ngữ cảnh.
Thực tế, điều đó có nghĩa là một ID mô hình, một dòng thanh toán, một tập hợp các giới hạn tỷ lệ, và quan trọng nhất, một cửa sổ ngữ cảnh chứa cả hình ảnh và văn bản của bạn cùng một lúc. Nếu bạn đang duy trì một thứ gì đó trên đường dẫn cũ, hướng dẫn API GLM-5V-Turbo của chúng tôi và hướng dẫn GLM-4.6V bao gồm các mô hình đó.
Tải trọng
Đầu vào hình ảnh hoạt động thông qua các khối nội dung đã được định kiểu. Thay vì content là một chuỗi, nó trở thành một mảng:
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)
Đối với hình ảnh cục bộ hoặc riêng tư, hãy sử dụng URL dữ liệu base64:
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}"},
}
Nhiều hình ảnh có nghĩa là nhiều khối. Không có mảng URL viết tắt:
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"),
]
Thứ tự quan trọng. Mô hình đọc mảng theo trình tự, vì vậy hãy đặt văn bản định khung trước các hình ảnh mà nó tham chiếu, và gắn nhãn hình ảnh rõ ràng khi bạn gửi nhiều hình ảnh. "Hình ảnh 1 là thiết kế" cung cấp cho mô hình một cái gì đó để neo câu trả lời của nó.
Thiết lập cơ bản và xác thực được đề cập trong hướng dẫn API của chúng tôi.
Các quy trình làm việc đáng xây dựng
Gỡ lỗi ảnh chụp màn hình
Quy trình rõ ràng, và là quy trình mà Z.ai dựa vào. Tài liệu của họ mô tả mô hình quan sát "giao diện, kết quả hiển thị và phản hồi tương tác," đây là một khung giải thích theo kiểu tác nhân lập trình hơn là mô tả ảnh.
Gửi kết xuất bị lỗi và mã nguồn tạo ra nó trong cùng một yêu cầu:
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```"},
]
Mô hình suy luận về kết xuất thực tế thay vì mô tả của bạn về nó. Điều đó loại bỏ bước mất mát nhất trong hầu hết các cuộc trò chuyện gỡ lỗi front-end, đó là việc con người dịch một vấn đề trực quan thành lời.
So sánh thiết kế
Hai hình ảnh và một câu hỏi. Hữu ích trong CI như một kiểm tra mềm về hồi quy hình ảnh, nơi một công cụ so sánh cho bạn biết các pixel đã thay đổi và một mô hình cho bạn biết liệu sự thay đổi đó có quan trọng hay không.
Hãy thực tế về độ tin cậy ở đây. Một mô hình so sánh ảnh chụp màn hình là một đánh giá, không phải là một khẳng định. Hãy sử dụng nó để phân loại sự khác biệt nào mà con người nên xem xét, chứ không phải để chặn triển khai dựa vào nó một mình.
Tài liệu cùng với đặc tả của chúng
Đây là nơi ngữ cảnh 1M phát huy tác dụng. Đặt một đặc tả dài vào lời nhắc dưới dạng văn bản và một tạo phẩm đã được hiển thị dưới dạng hình ảnh, sau đó hỏi liệu chúng có khớp nhau không.
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"),
]
Một đặc tả 40 trang và một hình ảnh trong một lời nhắc không phải là điều bạn có thể làm trên một mô hình có cửa sổ 128K và thị giác dựa trên bộ điều hợp. Đó chính là khả năng mới thực sự.
Ghi chú phát hành của Z.ai cũng đề cập đến các quy trình làm việc tài liệu văn phòng và nghiên cứu tài chính như là mục tiêu cho hành vi tác nhân của mô hình.
Biểu đồ và bảng điều khiển
Đọc một hình ảnh biểu đồ và trả về dữ liệu có cấu trúc là một tác vụ trích xuất tiêu chuẩn. Yêu cầu JSON và xác thực nó:
content = [
{"type": "text", "text": "Extract the series in this chart as JSON: [{label, values: [...]}]. Return only JSON."},
image_block("quarterly.png"),
]
Xác thực đầu ra dựa trên một lược đồ thay vì tin tưởng nó. Đọc biểu đồ chính xác là loại tác vụ mà một mô hình có thể tự tin đưa ra các con số sai, và xác thực cấu trúc sẽ bắt lỗi về hình dạng ngay cả khi nó không thể bắt lỗi về giá trị.
Đối với việc trích xuất tài liệu chuyên dụng, một chuyên gia vẫn có thể vượt trội hơn một người tổng quát. GLM-OCR để hiểu tài liệu bao gồm con đường đó.
Video và tệp
Tài liệu của Z.ai liệt kê đầu vào video và tệp cùng với hình ảnh, sử dụng cùng một cơ chế khối nội dung.
Hãy cẩn thận với điều này. Hỗ trợ video trong mô hình này là mới, được tài liệu hóa sơ sài và ít được sử dụng công khai so với đầu vào hình ảnh, vốn đã được nhiều người dùng thử. Hỗ trợ từ nhà cung cấp cũng khác nhau: một khả năng của mô hình không giống với một tính năng có sẵn trên cổng API mà bạn sử dụng.
Nếu video quan trọng đối với ứng dụng của bạn, hãy kiểm tra trực tiếp với phương tiện và nhà cung cấp của riêng bạn trước khi bạn thiết kế xung quanh nó. Đừng coi một dòng trong bảng khả năng như một tính năng hoạt động.
Những hạn chế
Đa phương thức gốc không giống như đa phương thức đáng tin cậy. Bốn chế độ lỗi đáng biết trước khi bạn triển khai một cái gì đó.
Con số tự tin từ biểu đồ. Đọc các giá trị từ một đường đồ thị là nhiệm vụ rất dễ tạo ra một câu trả lời trôi chảy, định dạng chính xác nhưng sai. Xác thực lược đồ có thể bắt lỗi đầu ra không đúng định dạng; nó không thể bắt một con số hợp lý nhưng đơn giản là không chính xác. Nếu các con số quan trọng, hãy lấy chúng từ dữ liệu cơ bản thay vì một hình ảnh.
Văn bản nhỏ. Ảnh chụp màn hình giao diện người dùng dày đặc, bảng trong các ảnh chụp độ phân giải thấp và mã trong các hình ảnh nén đều bị giảm chất lượng. Việc giảm kích thước để tiết kiệm token làm cho vấn đề này tồi tệ hơn, vì vậy có một sự căng thẳng trực tiếp giữa yếu tố chi phí và độ chính xác. Hãy cắt đến vùng quan tâm thay vì thu nhỏ toàn bộ khung hình.
Độ chính xác không gian. Các mô hình mô tả bố cục tốt nhưng đo lường kém. "Nút chồng lên ô nhập liệu" thường đúng. "Nút lệch sang trái 12 pixel" thường không đúng.
Nhầm lẫn thứ tự và tham chiếu. Với nhiều hình ảnh trong một yêu cầu, mô hình có thể gán một chi tiết cho hình ảnh sai. Hãy gắn nhãn chúng rõ ràng trong các khối văn bản và giữ số lượng thấp khi độ chính xác quan trọng.
Không có hạn chế nào trong số này là độc nhất của GLM-5.3-Flash. Chúng là những giới hạn tiêu chuẩn của các mô hình ngôn ngữ thị giác, và điểm số Chỉ số Thông minh 57 không miễn trừ nó. Hãy thiết kế quy trình làm việc sao cho một câu trả lời sai được phát hiện thay vì được thực hiện theo.
Chi phí
Hình ảnh tiêu thụ token ngữ cảnh và được tính phí như đầu vào. Không có phụ phí hình ảnh riêng biệt.
Theo giá niêm yết là 0,15 USD cho mỗi triệu token đầu vào, hoặc 0,075 USD trong thời gian giảm giá ra mắt kéo dài đến ngày 9 tháng 9 năm 2026. Hình ảnh độ phân giải cao tiêu thụ một lượng token đáng kể, vì vậy độ phân giải là một yếu tố chi phí: hãy giảm kích thước trước khi gửi trừ khi chi tiết nhỏ là mục đích của yêu cầu.
reasoning_effort mặc định là max, tính phí suy luận như token đầu ra. Đối với việc trích xuất trực tiếp từ một hình ảnh, low thường là cài đặt phù hợp và rẻ hơn đáng kể. Bảng phân tích giá của chúng tôi bao gồm cả hai yếu tố này.
Kiểm soát chi phí hình ảnh
Hình ảnh được tính phí dưới dạng token đầu vào, vì vậy độ phân giải là một yếu tố chi phí trực tiếp, và việc tối ưu hóa rõ ràng lại mâu thuẫn với các lưu ý về độ chính xác ở trên.
Thứ tự hoạt động khả thi:
- Cắt trước khi thay đổi kích thước. Gửi vùng liên quan ở độ phân giải đầy đủ tốt hơn là gửi toàn bộ màn hình ở độ phân giải một nửa. Bạn mất ngữ cảnh mà mô hình không cần và giữ lại chi tiết mà nó cần.
- Khớp độ phân giải với câu hỏi. "Bố cục có bị hỏng không?" vẫn giữ được độ chính xác khi giảm kích thước mạnh. "Thông báo lỗi này nói gì?" thì không.
- Đừng gửi lại hình ảnh không thay đổi. Trong một cuộc trò chuyện đa lượt, một hình ảnh đã gửi một lần đã nằm trong ngữ cảnh. Đính kèm lại nó trong mỗi lượt sẽ phải trả phí cho nó trong mỗi lượt.
- Đặt
reasoning_effortmột cách có chủ ý. Nó mặc định làmax, và suy luận được tính phí như đầu ra. Việc trích xuất đơn giản hiếm khi cần đến nó.
Đối tượng usage trong mỗi phản hồi cung cấp cho bạn số lượng token thực tế cho mỗi cuộc gọi, đây là cách duy nhất để biết chi phí thực sự của một hình ảnh thay vì đoán từ kích thước tệp của nó.
Kiểm thử các cuộc gọi đa phương thức
Các yêu cầu đa phương thức rất khó để kiểm thử thủ công. Một URL dữ liệu base64 có hàng nghìn ký tự, điều này làm cho lệnh curl khó đọc và thực tế là không thể chạy lại bằng cách chỉnh sửa. Các phản hồi là văn bản dạng tự do, vì vậy các lỗi hồi quy rất dễ bị bỏ qua.
Hai thói quen giúp ích. Giữ một tập hợp nhỏ các hình ảnh tham chiếu và câu trả lời mong đợi cố định, để bạn có thể biết khi nào hành vi thay đổi. Và xác thực việc trích xuất có cấu trúc dựa trên một lược đồ thay vì chỉ nhìn qua.
Apidog là một công cụ thiết thực cho việc này. Lưu trữ tải trọng hình ảnh trong một yêu cầu đã lưu thay vì một lệnh shell, giữ khóa API làm biến môi trường và đính kèm các xác nhận vào JSON mà các lời nhắc trích xuất của bạn trả về. Khi bạn chuyển đổi mô hình hoặc nhà cung cấp cập nhật một cái gì đó, việc chạy lại bộ kiểm thử sẽ cho bạn biết liệu đường dẫn thị giác có vẫn hoạt động đúng không thay vì để bạn phải tìm hiểu từ người dùng.
Câu hỏi thường gặp
GLM-5.3 có hỗ trợ hình ảnh không? Không phải gốc. GLM-5.3 định tuyến thị giác thông qua các bộ điều hợp riêng biệt. Flash là mô hình đa phương thức gốc, được đề cập trong bài so sánh của chúng tôi.
Mỗi yêu cầu có thể gửi bao nhiêu hình ảnh? Nhiều hình ảnh, mỗi hình ảnh là một khối image_url riêng. Giới hạn thực tế là ngân sách ngữ cảnh của bạn.
URL hay base64? Cả hai đều hoạt động. Sử dụng URL công khai khi hình ảnh đã được lưu trữ và có thể truy cập; sử dụng base64 cho hình ảnh cục bộ hoặc riêng tư.
Nó có chấp nhận video không? Z.ai có tài liệu về đầu vào video, nhưng nó còn mới và ít được sử dụng. Hãy xác minh với phương tiện và nhà cung cấp của riêng bạn trước.
Hình ảnh có được tính phí khác không? Không có phụ phí. Chúng tiêu thụ token đầu vào, vì vậy độ phân giải ảnh hưởng đến chi phí.