GLM-5.3-Flash làm được gì? Từ đọc bảng trong ảnh đến gọi API bằng Node.js

GLM-5.3-Flash là mô hình thuộc dòng GLM của Zhipu. Trong tài liệu chính thức của Z.ai, Flash và FlashX được giới thiệu với khả năng đa phương thức, hướng tới lập trình dựa trên hình ảnh, xử lý tài liệu và công việc văn phòng. Với người muốn đưa AI vào một công việc nhỏ, điểm đáng tìm hiểu là mô hình nhận được dữ liệu gì và trả lại thứ gì có thể dùng tiếp.

Ngày 30/10/2026, tôi thử glm-5.3-flash qua Crazyrouter với ba việc: đọc một bảng đăng ký từ ảnh, giải bài toán xác suất có điều kiện và tạo trang chia tiền chạy ngoại tuyến. Bảng và bài toán cho kết quả đúng trong các lần gọi tương ứng. Trang web cần gọi lại mới có mã hoàn chỉnh. Những kết quả này giúp hình dung một cách dùng khá cụ thể: giao cho mô hình phần đọc hiểu, nhưng giữ lại quy tắc và dữ liệu gốc để đối chiếu.

Hiểu đúng đầu vào và đầu ra của GLM-5.3-Flash

Đa phương thức nghĩa là mô hình có thể tiếp nhận nhiều loại dữ liệu, chứ không chỉ một đoạn văn bản. Tuy nhiên, ứng dụng hoặc API đang dùng vẫn phải hỗ trợ cách gửi loại dữ liệu đó. Trong thử nghiệm này, tôi gửi văn bản và một ảnh PNG; không thử video hay các định dạng tài liệu khác.

Ảnh cắt từ ảnh chụp trang BigModel chính thức, giữ nguyên chữ tiếng Trung. Đoạn này giới thiệu khả năng làm việc với tài liệu và công cụ. Đây là mô tả của nhà cung cấp, không phải ảnh kết quả của ba thử nghiệm dưới đây.

Đầu ra được tài liệu mô tả là văn bản. Văn bản ấy có thể chứa một bảng, lời giải hoặc mã HTML. Muốn có một tệp chạy được, vẫn cần lưu và chạy mã; muốn mô hình thao tác trình duyệt, phải có môi trường cung cấp công cụ tương ứng. Tôi không cấu hình công cụ ngoài cho mô hình trong các lần gọi này.

Cũng cần phân biệt tên: glm-5.3-flash là model ID đã dùng. FlashX là mô hình khác, chưa được thử ở đây. GLM-5.3 có tài liệu riêng mô tả đầu vào và đầu ra văn bản. Không nên rút gọn tất cả thành “GLM” rồi áp thông số hay kết quả của phiên bản này cho phiên bản kia.

Đọc bảng từ ảnh: quy tắc quan trọng không kém nhận dạng chữ

Giả sử bạn cần tổng hợp đăng ký một buổi sinh hoạt. Có người cập nhật thông tin, có người huỷ, có người mới thanh toán một phần. Bài toán không còn là đếm số dòng: phải biết bản ghi nào còn hiệu lực và khoản nào được đưa vào tổng.

Tôi tạo bảng giả lập gồm 12 bản ghi, trong đó một số mã đăng ký xuất hiện nhiều lần. Yêu cầu gửi kèm ảnh là giữ bản cập nhật mới nhất của từng mã, loại đăng ký đã huỷ khỏi nhóm còn hiệu lực, đồng thời tách số đã thanh toán và đã hoàn lại. Đáp án tham chiếu không được gửi cho mô hình.

Đây là ảnh đầu vào gốc bằng tiếng Trung giản thể. Các cột lần lượt là mã đăng ký, loại, số phải nộp, đã nộp, đã hoàn, trạng thái và thời điểm cập nhật. Mọi bản ghi đều giả lập; số tiền giữ nguyên đơn vị nhân dân tệ của đề gốc, không quy đổi sang đồng Việt Nam.

Ảnh được gửi dưới dạng Base64 Data URL trong khối image_url. Mô hình trả về 9 bản ghi mới nhất; các trường khớp với ảnh nguồn và cả 10 chỉ tiêu tổng hợp khớp đáp án độc lập. Trong đó có 7 đăng ký còn hiệu lực, tổng phải nộp 720, thực thu ròng 580 và còn thiếu 140. Nhóm đã huỷ có tổng đã nộp 200, đã hoàn 80.

Mô hình còn chỉ ra hai trường hợp cần xem lại: A004 đã huỷ nhưng không có khoản hoàn được ghi nhận; A006 chưa nộp đủ. Nó không tự kết luận A004 chắc chắn phải được hoàn, vì ảnh không chứa chính sách hoàn tiền hay lý do huỷ.

Đây là chỗ mô hình có thể giúp người xử lý dữ liệu: tìm ra dòng cần chú ý và giải thích căn cứ. Quyết định nghiệp vụ vẫn cần thông tin thật. Nếu đầu ra chỉ có một tổng cuối cùng, rất khó biết lỗi đến từ việc đọc nhầm số, chọn nhầm bản cập nhật hay áp sai quy tắc.

Với công việc tương tự, tôi sẽ yêu cầu cả danh sách được giữ lại lẫn các tổng. Sau đó kiểm tra ba việc: mã có bị trùng không, bản cập nhật có đúng là mới nhất không, và trạng thái đã huỷ có bị tính vào nhóm đang hoạt động không. Đây là cách tổ chức quy trình từ kết quả thử nghiệm; chưa phải một hệ thống nhập liệu tự động đã triển khai.

Một ảnh rõ và có chủ đích vẫn là phạm vi hẹp. Kết quả này chưa cho biết mô hình xử lý ảnh chụp nghiêng, chữ mờ, ô gộp hay tài liệu nhiều trang tốt đến đâu.

Dùng bài toán có đáp án độc lập để hiểu cách mô hình suy luận

Bài toán thứ hai có hai hộp: A gồm 4 bi đỏ và 2 bi xanh; B gồm 2 bi đỏ và 4 bi xanh. Xác suất chọn A là 1/3, chọn B là 2/3. Chọn một hộp rồi lấy liên tiếp 3 bi không hoàn lại. Biết ít nhất một trong hai lần đầu lấy được bi đỏ, cần tìm xác suất lần thứ ba đỏ và xác suất đã chọn hộp A.

Mô hình trả về lần lượt 13/32 và 7/16, với các bước suy luận khớp lời giải tham chiếu. Trước khi gọi API, tôi đã chuẩn bị phép liệt kê độc lập: coi từng viên bi là một vật riêng, mỗi hộp có 6 × 5 × 4 = 120 thứ tự lấy ba viên.

Tôi cũng chạy chương trình JavaScript mà mô hình đưa ra. Chương trình dùng BigInt để tính phân số chính xác và cho cùng hai đáp án. Như vậy, ở bài này có thể đối chiếu lời giải, mã do mô hình sinh và phép liệt kê chuẩn bị riêng.

Nếu đang học xác suất, lợi ích không chỉ là nhận một con số. Bạn có thể nhìn xem lời giải đã cập nhật xác suất chọn hộp sau điều kiện quan sát hay chưa, và có nhầm việc rút không hoàn lại thành các lần rút độc lập hay không. Một bài đúng chưa đủ để kết luận mô hình luôn giỏi toán; nó cho thấy cách đặt một câu hỏi mà kết quả có đường kiểm tra rõ ràng.

Khi yêu cầu một trang web, cần dành chỗ cho cả phần mã cuối cùng

Tôi yêu cầu một tệp HTML ngoại tuyến để chia chi phí: thêm, đổi tên, xoá người; chọn người tham gia từng khoản; sửa, xoá khoản chi và đặt lại trang. Số tiền phải được tính bằng số nguyên ở đơn vị nhỏ nhất, phần dư chia theo thứ tự hiển thị.

Chẳng hạn, 100,00 chia ba phải thành 33,34; 33,33; 33,33. Với 0,01 chia ba, kết quả là 0,01; 0; 0. Quy tắc này giúp tránh tạo thêm hoặc làm mất tiền khi làm tròn.

Lần đầu, API trả HTTP 200 nhưng finish_reason là length: mã dừng giữa chừng. Giới hạn đầu ra là 32.000 token, và trường usage ghi nhận 25.707 token suy luận nằm trong tổng đó. Vì thế, 32.000 không phải toàn bộ số token dành cho HTML hiển thị.

Tôi giữ nguyên đề và system message, chỉ tăng max_tokens lên 48.000 rồi gọi lại. Lần thứ hai kết thúc bằng stop và có HTML hoàn chỉnh. Tôi không tự nối phần còn thiếu hay sửa mã của mô hình trước khi kiểm tra.

Script hoàn chỉnh qua kiểm tra cú pháp. Các hàm tính toán và kiểm tra dữ liệu, được chạy nguyên trạng trong Node.js, vượt qua 40 kiểm tra; một kiểm tra trong số đó bao phủ 132 tổ hợp số tiền và số người. Các trường hợp gồm giữ nguyên tổng tiền, chia phần dư đúng thứ tự, chỉ chia cho người được chọn, từ chối số tiền không hợp lệ và ngăn xoá người duy nhất của một khoản chi.

Giao diện chưa được thao tác trong trình duyệt thật. Chưa có kết quả kiểm tra bố cục, nút bấm, sửa dữ liệu hay đặt lại trang. Lần gọi thứ hai cũng là một lần sinh mới, nên không thể coi tăng giới hạn token là cách chắc chắn sửa mọi trường hợp bị cắt.

Gọi GLM-5.3-Flash bằng Node.js, lấy Crazyrouter làm ví dụ

Bạn có thể dùng API chính thức của BigModel hoặc Z.ai. Ví dụ dưới đây dùng Crazyrouter vì đây là nơi tôi thực hiện các lần gọi đã nêu. Key, địa chỉ dịch vụ và tham số phải thuộc cùng một nhà cung cấp; không dùng key của dịch vụ này với endpoint của dịch vụ khác.

Khi muốn xem thêm các lựa chọn phục vụ lập trình, có thể tham khảo danh mục mô hình lập trình của Crazyrouter. Đây là trang danh mục chung, không phải trang thông số riêng của Flash. Model ID trong ví dụ vẫn là glm-5.3-flash.

Chuẩn bị tệp và key

Cài Node.js 22 trở lên, chạy node --version để kiểm tra. Trong mục quản lý API token của Crazyrouter, tạo key; nếu giới hạn mô hình được phép dùng, cần có glm-5.3-flash. Tạo một thư mục và lưu riêng key vào api-key.txt. Không đưa tệp này lên kho mã nguồn hoặc vào ảnh chụp.

Lưu mã sau thành glm-flash-vi.cjs trong cùng thư mục. Đề trong mã là ví dụ tiếng Việt tương đương về mặt toán học. Ba thử nghiệm phía trên dùng tiếng Trung giản thể; tôi chưa gọi mô hình trực tiếp với đề tiếng Việt này. Script được kiểm tra cục bộ về cấu trúc yêu cầu và xử lý phản hồi, không phải một phép đo năng lực tiếng Việt.

'use strict';
const fs = require('node:fs');
const path = require('node:path');

async function main() {
  const key = fs.readFileSync(path.join(__dirname, 'api-key.txt'), 'utf8').trim();
  if (!key || /\s/.test(key)) throw new Error('Invalid key file');
  const request = {
    model: 'glm-5.3-flash',
    messages: [
      {
        role: 'system',
        content: "Trả lời dựa trên dữ kiện của đề; phân biệt phép tính, giả định và thông tin chưa biết. Không khẳng định đã chạy mã nếu chưa chạy."
      },
      {
        role: 'user',
        content: "Hộp A có 4 bi đỏ và 2 bi xanh; hộp B có 2 bi đỏ và 4 bi xanh. Chọn A với xác suất 1/3, B với xác suất 2/3, rồi rút liên tiếp 3 bi không hoàn lại từ cùng hộp đã chọn. Biết ít nhất một trong hai lần rút đầu tiên được bi đỏ, hãy tính xác suất lần thứ ba được bi đỏ và xác suất hậu nghiệm đã chọn hộp A. Trả lời bằng phân số chính xác, trình bày từng bước và giải thích lỗi thường gặp. Cung cấp mã Node.js để kiểm tra bằng cách liệt kê chính xác các thứ tự rút, coi từng viên bi là một vật riêng biệt. Không thay phép liệt kê bằng mô phỏng ngẫu nhiên và không khẳng định đã chạy mã."
      }
    ],
    max_tokens: 24000,
    stream: false
  };
  const response = await fetch('https://api.crazyrouter.com/v1/chat/completions', {
    method: 'POST',
    redirect: 'error',
    signal: AbortSignal.timeout(720000),
    headers: { Authorization: 'Bearer ' + key, 'Content-Type': 'application/json' },
    body: JSON.stringify(request)
  });
  if (!response.ok) {
    console.error('Yêu cầu thất bại. Mã HTTP: ' + response.status);
    process.exitCode = 1;
    return;
  }
  const data = await response.json();
  const choice = data.choices?.[0];
  const redact = value => String(value).split(key).join('[redacted]');
  console.log('Lý do kết thúc: ' + redact(choice?.finish_reason || 'không được cung cấp'));
  const answer = choice?.message?.content;
  if (typeof answer !== 'string' || !answer.trim()) {
    console.error('Không nhận được nội dung trả lời. Kiểm tra giới hạn đầu ra và tham số.');
    process.exitCode = 1;
    return;
  }
  console.log(redact(answer));
}
main().catch(() => {
  console.error('Chưa hoàn tất yêu cầu. Kiểm tra tệp cục bộ, kết nối và cấu hình. Chi tiết lỗi nhạy cảm không được hiển thị.');
  process.exitCode = 1;
});

Chạy và đọc phản hồi

Mở terminal tại thư mục vừa tạo rồi chạy:

node glm-flash-vi.cjs

Trên Windows, có thể nhập powershell vào thanh địa chỉ của thư mục trong File Explorer rồi nhấn Enter. Kiểm tra tên tệp không bị thêm đuôi .txt. Không cần cài thêm thư viện cho ví dụ này.

Lệnh gửi một yêu cầu API thật, chờ phản hồi đầy đủ rồi in lý do kết thúc và câu trả lời. Nó không chạy mã mà mô hình trả về. Đáp án toán học để tự đối chiếu là 13/32 và 7/16; phản hồi mới vẫn cần được đọc và kiểm tra.

Nếu gặp HTTP 401, kiểm tra key có hợp lệ và đúng dịch vụ hay không. Nếu thấy length, kiểm tra phần cuối câu trả lời trước khi dùng. Nếu không đọc được tệp key, kiểm tra lại vị trí và tên tệp. Với phản hồi rỗng, đừng vội coi HTTP 200 là thành công hoặc gửi lại liên tục mà chưa tìm nguyên nhân.

Một ứng dụng yêu cầu Base URL tương thích OpenAI sẽ dùng https://api.crazyrouter.com/v1; script gọi địa chỉ đầy đủ kết thúc bằng /chat/completions. Có thể tra chỉ mục tài liệu API khi cần định dạng khác. Ví dụ này chỉ gửi văn bản; gửi ảnh cần khối nội dung image_url như trong phần thử bảng.

Nên bắt đầu bằng công việc nào?

Với kết quả hiện có, tôi sẽ bắt đầu từ một bảng hoặc bài toán mà mình đã hiểu quy tắc, thay vì giao ngay cả một ứng dụng. Một lần gọi có thể giúp đọc, sắp xếp và giải thích dữ liệu; phần còn lại là đối chiếu với nguồn rồi quyết định dùng kết quả thế nào. Khi chuyển sang tạo công cụ, cần thêm bước chạy và thao tác thực tế.

Phạm vi của bài này là 3 tác vụ độc lập, tổng cộng 4 yêu cầu API ngày 30/10/2026, dùng glm-5.3-flash tại https://api.crazyrouter.com/v1/chat/completions. Giới hạn đầu ra lần lượt là 16.000 token cho ảnh, 24.000 cho xác suất, 32.000 và 48.000 cho hai lần tạo trang. Tất cả dùng stream: false; tôi không đặt riêng temperature, top_p hay reasoning_effort. Việc chạy mã để đối chiếu được thực hiện sau khi nhận phản hồi, không phải công cụ do mô hình tự gọi.

Đó là đủ để chọn một việc nhỏ có thể thử tiếp, nhưng chưa đủ để xếp hạng tốc độ, độ ổn định hay kết luận về khả năng tiếng Việt. Điểm bắt đầu tốt là câu hỏi bạn có thể kiểm tra được, rồi mở rộng khi đã hiểu mô hình thường giúp ở bước nào.