Tự host GLM-5.3: Chuẩn bị cho đợt phát hành trọng số mở

Zhipu AI đã phát hành GLM-5.3 vào ngày 14 tháng 8 năm 2026. Thông tin quan trọng với các nhóm hạ tầng là: trọng số mở dự kiến có mặt sau khoảng hai tuần, vào khoảng ngày 28 tháng 8, trên tổ chức Hugging Face của Zhipu. Khoảng chờ này là thời gian để bạn ước tính phần cứng, chọn ngăn xếp phục vụ và tạo đường cơ sở hồi quy với API được lưu trữ trước khi các phân mảnh safetensors xuất hiện.

Dùng thử Apidog ngay hôm nay

Theo các đánh giá nội bộ của Zhipu, GLM-5.3 cải thiện khả năng lập trình 50% so với GLM-5.2; điểm Terminal-Bench 3.0 tăng từ 4.6 lên 28.3; và hiệu năng tác nhân được mô tả là “tiệm cận Claude Fable 5”, theo báo cáo ra mắt. Để xem toàn bộ điểm chuẩn, bao gồm các hạng mục mô hình vẫn thua kém các hệ thống tiên tiến, hãy đọc giải thích về GLM-5.3.

Bài viết này tập trung vào việc cần chuẩn bị để tự phục vụ GLM-5.3 ngay khi trọng số được phát hành.

Tại thời điểm viết bài, trọng số GLM-5.3 chưa thể tải xuống. Những nội dung chưa được Zhipu xác nhận được ghi rõ là kỳ vọng, không phải thông tin chắc chắn. Bạn vẫn có thể bắt đầu ngay: dùng Apidog để lưu phản hồi từ API được lưu trữ, sau đó phát lại cùng bộ kiểm thử với endpoint cục bộ.

Tóm tắt

• GLM-5.3 được phát hành ngày 14 tháng 8 năm 2026. Zhipu cho biết trọng số mở dự kiến xuất hiện khoảng ngày 28 tháng 8 sau quy trình đánh giá rủi ro. Nơi phát hành dự kiến: huggingface.co/zai-org.
• Dòng GLM-5 sử dụng kiến trúc Mixture of Experts (MoE): 744 tỷ tham số tổng, khoảng 40 tỷ tham số hoạt động mỗi lượt suy luận, ngữ cảnh 200K, theo tài liệu Z.ai.
• Trọng số BF16 chiếm gần 1.5 TB; FP8 chiếm khoảng 744–745 GB, chưa tính KV cache. Bạn cần hạ tầng đa GPU để tự phục vụ ở độ chính xác đầy đủ.
• Dựa trên các bản GLM-5 trước đây, có thể kỳ vọng kho GLM-5.3 và GLM-5.3-FP8 xuất hiện ngay ngày đầu. Các bản GGUF do cộng đồng chuyển đổi có thể đến muộn hơn.
• vLLM và SGLang là hai lựa chọn phục vụ phù hợp vì đều có endpoint tương thích OpenAI.
• Hãy xây dựng bộ hồi quy ngay từ bây giờ: một collection, hai môi trường hosted và local, cùng các assertion về cấu trúc và nội dung phản hồi.

Zhipu sẽ phát hành gì và khi nào?

Zhipu, với thương hiệu quốc tế là Z.ai, đã ra mắt API GLM-5.3 và cho biết trọng số mở sẽ được đưa lên Hugging Face sau khoảng hai tuần, tức khoảng ngày 28 tháng 8 năm 2026.

Theo Zhipu, khoảng chờ này phục vụ quy trình đánh giá rủi ro toàn diện. Đây là điểm cần lưu ý vì mô hình đạt 84.5% trên CyberGym, cao hơn một chút so với Claude Mythos 5 và GPT-5.6 Sol. Seeking Alpha xem đây là nỗ lực của Zhipu nhằm duy trì vị thế trong thị trường mô hình mở, nơi hãng cạnh tranh với DeepSeek.

Hai chi tiết cần quan tâm khi tự lưu trữ:

1. Mô hình cơ sở không thay đổi. GLM-5.3 là GLM-5 base model với hậu huấn luyện mở rộng. Điều này có nghĩa ngăn xếp đã chạy GLM-5 hoặc GLM-5.2 nhiều khả năng sẽ tiếp tục phù hợp. Không có thay đổi attention hoặc tokenizer mới được công bố.
2. Mẫu phát hành đã rõ ràng. Hugging Face của Zhipu đã có GLM-5, GLM-5.1 và GLM-5.2, mỗi bản đều có biến thể FP8. Vì vậy, kỳ vọng hợp lý là GLM-5.3 cũng có safetensors BF16 và bản FP8 chính thức.

Điều khoản giấy phép của GLM-5.3 chưa được xác nhận trong thông báo ra mắt. Trước khi đưa mô hình vào sản phẩm thương mại, hãy đọc kỹ model card và giấy phép trong kho phát hành.

744 tỷ tham số tổng cộng, 40 tỷ tham số hoạt động: phần cứng cần gì?

Dòng GLM-5 sử dụng MoE, với 744 tỷ tham số tổng cộng, khoảng 40 tỷ tham số hoạt động ở mỗi lượt chuyển tiếp và ngữ cảnh 200K, theo tài liệu GLM-5 của Z.ai. Các kho Hugging Face có thể ghi tổng số cao hơn một chút do bao gồm embeddings.

Với MoE, chi phí tính toán và bộ nhớ không tỷ lệ giống nhau:

• Tính toán gần với mô hình dense 40B. Chỉ các expert được router chọn mới hoạt động cho mỗi token, nên thông lượng có thể tốt hơn nhiều so với một mô hình dense 744B.
• Bộ nhớ gần với mô hình 744B. Tất cả expert phải nằm trong bộ nhớ có thể truy cập. Với BF16, 744 tỷ tham số cần khoảng 1.5 TB; với FP8, cần khoảng 744 GB. Các số liệu này chưa tính KV cache.

Độ chính xác	Kích thước trọng số ước tính	Môi trường phù hợp
BF16	~1.5 TB	Cụm đa nút hoặc máy chủ đơn với cấu hình GPU rất lớn
FP8 chính thức	~745 GB	Máy chủ đa GPU cao cấp trong một nút
INT4 từ cộng đồng	~370–400 GB	Cụm nhiều GPU nhỏ hơn; cần tự đánh giá chất lượng

Nếu bạn chỉ có một GPU tiêu dùng, không nên đặt mục tiêu chạy toàn bộ trọng số GLM-5.3. Các lựa chọn thực tế hơn:

• Thuê GPU theo giờ để benchmark.
• Chờ lượng tử hóa từ cộng đồng.
• Giữ GLM-5.3 trên API được lưu trữ.
• Chạy các mô hình mở nhỏ hơn tại chỗ.

Xem thêm hướng dẫn LLM cục bộ tốt nhất năm 2026 để chọn mô hình phù hợp với một GPU hoặc workstation.

Ngoài trọng số, cần tính KV cache. Với ngữ cảnh 200K, KV cache tăng theo độ dài context và batch size. Đừng mặc định phục vụ ở 200K token: hãy đặt max_model_len theo từng cấp hạ tầng và workload thực tế.

Chọn ngăn xếp phục vụ trước ngày phát hành

Ba nhóm công cụ phục vụ cần cân nhắc:

vLLM

vLLM là lựa chọn mặc định cho mô hình ở quy mô này. Nó đã hỗ trợ dòng GLM-5, định tuyến MoE, tensor parallelism, expert parallelism và OpenAI-compatible server.

Sau khi kho mô hình xuất hiện, lệnh khởi chạy có thể có dạng:

vllm serve zai-org/GLM-5.3-FP8 \
  --tensor-parallel-size 8 \
  --max-model-len 65536 \
  --served-model-name glm-5.3

Đây là mẫu cấu hình, không phải cấu hình cố định. Bạn cần điều chỉnh:

• --tensor-parallel-size theo số GPU và VRAM.
• --max-model-len theo KV cache có thể cấp phát.
• Tên kho theo model ID thực tế trên Hugging Face.
• Các tham số parallelism theo topology cụm của bạn.

SGLang

SGLang là lựa chọn thay thế đáng cân nhắc, đặc biệt với workload tác nhân có các tiền tố dài dùng chung. Radix tree prefix cache có thể hữu ích khi nhiều request tái sử dụng system prompt hoặc context chung.

SGLang cũng cung cấp endpoint tương thích OpenAI, nên việc đổi giữa vLLM và SGLang không buộc bạn viết lại client.

llama.cpp, Ollama và LM Studio

Dòng llama.cpp cần bản GGUF. Các bản này thường do cộng đồng chuyển đổi sau khi safetensors được phát hành, có thể mất vài ngày đến vài tuần.

Đường đi này có thể giúp mô hình tiếp cận phần cứng nhỏ hơn qua lượng tử hóa, nhưng bạn cần benchmark so với đường cơ sở thay vì giả định chất lượng tương đương.

Việc nên làm ngay

Cài đặt vLLM hoặc SGLang ngay trong tuần này và chạy thử bằng GLM-5.2 hoặc một mô hình MoE nhỏ hơn. Mục tiêu là loại bỏ trước các lỗi có thể tránh được như:

• Driver CUDA không tương thích.
• Phiên bản PyTorch hoặc kernel không phù hợp.
• Lỗi NCCL trong cấu hình multi-GPU.
• Sai cấu hình mạng hoặc endpoint.
• Thiếu dung lượng lưu trữ cho checkpoint và cache.

Dùng API được lưu trữ làm đường cơ sở

Trước khi tự lưu trữ, hãy ghi lại đầu ra từ triển khai tham chiếu. API được lưu trữ của Zhipu là đường cơ sở để bạn xác định khác biệt sau này đến từ đâu:

• Lượng tử hóa làm giảm chất lượng.
• Cấu hình serving stack có lỗi.
• Tool calling hoặc structured output khác hành vi.
• Sampling có biến động bình thường.

API tương thích OpenAI:

• Quốc tế: https://api.z.ai/api/paas/v4/chat/completions
• Trung Quốc đại lục: https://open.bigmodel.cn/api/paas/v4/chat/completions
• Xác thực: Authorization: Bearer <key>

Tài liệu của Z.ai hiện liệt kê glm-5. Với glm-5.3, hãy xác nhận model ID chính xác trong tài liệu chính thức. Bạn cũng có thể xem hướng dẫn bắt đầu nhanh API GLM-5.3.

Ghi lại phản hồi ở nhiệt độ 0 với prompt cố định:

curl https://api.z.ai/api/paas/v4/chat/completions \
  -H "Authorization: Bearer $GLM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.3",
    "temperature": 0,
    "messages": [
      {
        "role": "user",
        "content": "Write a Python function that parses RFC 3339 timestamps and returns UTC datetimes. Include error handling for invalid input."
      }
    ]
  }' > baseline-rfc3339.json

Tạo khoảng 20–50 test case phản ánh workload thực tế:

• Sinh và refactor mã.
• Tool calling của agent.
• Trích xuất dữ liệu có cấu trúc.
• Tóm tắt context dài.
• Phân tích lỗi.
• JSON mode hoặc schema-constrained output.

Nhiệt độ 0 không đảm bảo đầu ra giống tuyệt đối, nhưng đủ để làm lộ các suy giảm rõ ràng do lượng tử hóa hoặc cấu hình serving.

Xây dựng bộ kiểm tra hồi quy trong Apidog

cURL phù hợp với một request đơn lẻ. Khi bạn cần so sánh hai endpoint, nhiều mức lượng tử hóa và nhiều cấu hình serving, hãy dùng một collection có cấu trúc.

Đây là bài toán kiểm thử hồi quy API tiêu chuẩn, tương tự cách tiếp cận trong hướng dẫn kiểm thử API cho kỹ sư QA.

Thiết lập đề xuất trong Apidog:

1. Tạo một collection chứa toàn bộ prompt cơ sở.
   
   Mỗi prompt là một request tới endpoint chat completions. Vì schema tương thích OpenAI, bạn có thể dùng cấu trúc request quen thuộc và xác thực payload.

2. Tạo hai environment: hosted và local.
   
   Cấu hình ví dụ:

| Biến | hosted | local |
| --- | --- | --- |
| base_url | https://api.z.ai/api/paas/v4 | http://localhost:8000/v1 |
| api_key | API key của Z.ai | local-serving |
| model | glm-5.3 | glm-5.3 |

Trong request, dùng biến môi trường:

   {{base_url}}/chat/completions

1. Kiểm tra cấu trúc trước, nội dung sau. Các assertion cơ bản nên gồm:

• HTTP status là 200.
• choices[0].message.content không rỗng.
• Có trường usage.
• Số token trả về hợp lý.
• Không có error object.

Với test sinh mã, thêm assertion chịu được khác biệt câu chữ:

   response chứa "def "
   response chứa "datetime"
   response chứa "try"

1. Lưu phản hồi hosted làm fixture tham chiếu.
   
   Đây là dữ liệu để bạn so sánh sau khi chạy cục bộ.

2. Chạy collection từ CLI.
   
   Dùng runner của Apidog để chạy lại cùng bộ test cho từng biến thể:

• BF16 so với FP8.
• vLLM so với SGLang.
• Context 32K so với 64K.
• Trước và sau khi thay đổi parallelism.
• Trước và sau khi thay đổi prefix cache.

Mục tiêu vào ngày phát hành là trả lời bằng dữ liệu cho câu hỏi:

Triển khai cục bộ của tôi có hoạt động đủ gần với API được lưu trữ không?

Thay vì đánh giá bằng cảm nhận, bạn sẽ có pass/fail cho từng prompt.

Mã client không cần thay đổi

Nhờ OpenAI compatibility, ứng dụng hiện dùng API được lưu trữ có thể chuyển sang endpoint tự phục vụ chỉ bằng thay đổi cấu hình.

Ví dụ Python:

import os
from openai import OpenAI

# Hosted: GLM_BASE_URL=https://api.z.ai/api/paas/v4
# Local:  GLM_BASE_URL=http://localhost:8000/v1
client = OpenAI(
    base_url=os.environ["GLM_BASE_URL"],
    api_key=os.environ.get("GLM_API_KEY", "local-serving"),
)

response = client.chat.completions.create(
    model="glm-5.3",
    temperature=0,
    messages=[
        {
            "role": "user",
            "content": "Refactor this function to remove the nested loops: ..."
        }
    ],
)

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

Nếu phục vụ với vLLM, dùng --served-model-name glm-5.3 để giữ nguyên model ID giữa hosted và local.

Dù bề mặt API giống nhau, vẫn nên hồi quy riêng các tính năng dễ khác biệt:

• Streaming.
• Tool/function calling.
• JSON mode.
• Structured output.
• Usage token accounting.
• Stop sequences.
• Error format và status code.

Khung chi phí: API được lưu trữ hay GPU riêng?

Zhipu chưa công bố giá API cụ thể cho GLM-5.3 tại thời điểm ra mắt. Hãy kiểm tra trang giá chính thức trước khi xây dựng mô hình chi phí.

Với mô hình MoE 744B, tự lưu trữ nghĩa là bạn trả chi phí GPU ngay cả khi không có token nào được xử lý. Cách này hợp lý khi:

1. Mức sử dụng liên tục đủ cao để chi phí API theo token vượt chi phí GPU đã khấu hao hoặc thuê.
2. Yêu cầu quản trị dữ liệu bắt buộc prompt và dữ liệu phải ở trong hạ tầng của bạn.
3. Bạn cần kiểm soát latency, availability hoặc routing mà API dùng chung không đảm bảo.

Nếu chưa đạt các điều kiện này, API được lưu trữ thường là phương án hiệu quả hơn. Thuê GPU theo giờ để đánh giá cũng an toàn hơn mua phần cứng cho mô hình chưa được xác thực trong workload của bạn.

Trọng số mở cũng là một biện pháp giảm rủi ro nhà cung cấp. Giá API có thể thay đổi, như trường hợp được đề cập trong phân tích tăng giá API DeepSeek. Khi đường tự lưu trữ đã được kiểm chứng, bạn có thêm lựa chọn nếu giá hosted thay đổi.

Danh sách kiểm tra ngày phát hành

Các mục từ 1 đến 6 có thể thực hiện ngay hôm nay.

1. Xác định độ chính xác mục tiêu: BF16, FP8 hoặc chờ lượng tử hóa cộng đồng.
2. Đối chiếu yêu cầu VRAM, KV cache và context length với phần cứng có thể truy cập.
3. Cài đặt vLLM hoặc SGLang; chạy thử GLM-5.2 hoặc một MoE nhỏ hơn.
4. Tạo API key Z.ai và xác nhận model ID trong tài liệu Z.ai.
5. Ghi lại 20–50 phản hồi baseline từ API hosted với temperature: 0.
6. Tạo collection Apidog với hai environment hosted và local.
7. Thêm assertion về HTTP status, cấu trúc response, usage và nội dung tối thiểu.
8. Xác định context length tối đa cho từng tier triển khai.
9. Vào ngày phát hành, theo dõi huggingface.co/zai-org để tìm GLM-5.3 và GLM-5.3-FP8.
10. Đọc model card và giấy phép trước khi triển khai thương mại.
11. Tải trọng số, khởi động server và trỏ environment local vào endpoint mới.
12. Chạy lại collection và so sánh với fixture hosted.
13. Điều tra lỗi chất lượng trước khi mở rộng traffic.
14. Chỉ sau đó mới tối ưu lượng tử hóa, parallelism, prefix cache và giới hạn context.

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

Tôi có thể tải trọng số GLM-5.3 ngay bây giờ không?

Không. Tính đến ngày 14 tháng 8 năm 2026, chỉ API được lưu trữ đang hoạt động. Zhipu cho biết trọng số mở dự kiến có sẵn sau khoảng hai tuần, gần ngày 28 tháng 8, trên trang Hugging Face zai-org.

GLM-5.3 có chạy trên một GPU tiêu dùng duy nhất không?

Không, không phải với trọng số đầy đủ. Dòng mô hình này có 744 tỷ tham số, cần khoảng 744 GB ở FP8 trước KV cache. Ngay cả lượng tử hóa INT4 cũng vẫn thuộc phạm vi nhiều GPU.

Nếu chỉ có một GPU, hãy chạy mô hình mở nhỏ hơn tại chỗ và dùng GLM-5.3 qua API. Tổng hợp LLM cục bộ có thể giúp bạn chọn phương án phù hợp.

Tôi nên dùng framework phục vụ nào cho GLM-5.3?

vLLM là lựa chọn mặc định an toàn nhờ hỗ trợ GLM-5, MoE-aware parallelism và OpenAI-compatible server. SGLang phù hợp khi workload có tiền tố dài được gửi lại nhiều lần, chẳng hạn vòng lặp agent.

llama.cpp, Ollama và LM Studio cần GGUF, thường xuất hiện sau khi cộng đồng chuyển đổi trọng số safetensors.

SDK OpenAI hiện tại có hoạt động với GLM-5.3 tự lưu trữ không?

Có. Trỏ base_url của SDK tới server vLLM hoặc SGLang thay vì:

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

Giữ nguyên request shape và model name đã đăng ký. Tuy nhiên, hãy kiểm thử riêng streaming và tool calling vì đây là các điểm local stack có thể khác hosted API.

Vì sao cần API được lưu trữ nếu tôi đã định tự lưu trữ?

API hosted là triển khai tham chiếu của bạn. Nếu output cục bộ khác thường, baseline hosted giúp xác định nguyên nhân là:

• Lượng tử hóa quá mạnh.
• Serving stack cấu hình sai.
• Khác biệt vốn có của sampling.
• Hành vi mô hình thực tế.

Hãy ghi baseline ngay bây giờ theo hướng dẫn bắt đầu nhanh API GLM-5.3, để ngày phát hành trở thành bài toán so sánh thay vì phỏng đoán.

GLM-5.3 phù hợp ở đâu trong ngăn xếp của bạn?

GLM-5.3 là một thông báo mô hình mở đáng chú ý: đạt kết quả cao trên Terminal-Bench 3.0 và Agents’ Last Exam, có điểm CyberGym cao hơn hai mô hình tiên tiến, đồng thời có lịch phát hành trọng số công khai.

Nhóm nhận được giá trị sớm nhất không nhất thiết là nhóm có ngân sách GPU lớn nhất. Đó là nhóm đã chuẩn bị trước:

• Cài đặt serving stack.
• Chọn độ chính xác mục tiêu.
• Xác định giới hạn context.
• Lưu baseline hosted.
• Xây dựng bộ hồi quy.
• Chuẩn bị quy trình pass/fail.

Bắt đầu với checklist ở trên. Ghi lại baseline hosted trong tuần này và tải xuống Apidog để quản lý collection, environment và assertion. Khi thay đổi lượng tử hóa hoặc cờ serving, bạn sẽ có một báo cáo có thể chạy lại thay vì phải đánh giá lại từ đầu.