Qwen3.8-27B của Alibaba ra mắt ngày 14/8 với những con số thực sự ấn tượng — Terminal-Bench 2.1 tăng từ 63,4 lên 73,0 so với phiên bản trước, DeepSWE 1.1 nhảy từ 13,3 lên 42,2, vượt qua Muse Glimmer của Meta ở cả tám benchmark đối đầu trực tiếp mà team Qwen công bố. Đây là model multimodal dense 27,8B, giấy phép Apache 2.0, context gốc 262K có thể mở rộng lên 1M qua YaRN, và chạy được trên một GPU 24GB duy nhất. Trên giấy tờ, đây là một trong những model open-weight mạnh nhất bạn có thể tự host hôm nay.

Rồi Simon Willison yêu cầu nó vẽ một hình tròn SVG, và nó mất 21 phút.

Cái default âm thầm ngốn hết ngân sách latency của bạn

Nguyên nhân gốc rễ nằm ở một quyết định cấu hình duy nhất: Qwen3.8-27B mặc định reasoning effort ở mức xhigh. Với prompt “vẽ một hình tròn”, điều đó nghĩa là 22.276 reasoning token trước khi nó tạo ra bất kỳ output nào — 21 phút từ đầu đến cuối. Tắt hẳn reasoning và cùng một prompt đó hoàn thành trong 137 giây. Đây không phải chênh lệch 2x hay 3x, mà khoảng 9x, trên một tác vụ lẽ ra không cần tới bất kỳ reasoning token nào.

Tôi từng gặp dạng lỗi này trước đây, chỉ chưa bao giờ nghiêm trọng đến vậy. Setting reasoning effort là một nút chỉnh còn khá mới trên toàn cảnh model — Claude, GPT, và giờ là các bản release open-weight đều có phiên bản của nút này — và các vendor vẫn đang trong quá trình hiệu chỉnh xem default nên là gì cho một bản release general-purpose. Team Qwen rõ ràng đã tối ưu default cho hiệu năng benchmark (xhigh gần như chắc chắn làm đẹp các con số Terminal-Bench và DeepSWE) thay vì cho request trung vị trong thực tế, thứ mà với đa số pipeline agent không hề giống một bài toán thi đấu.

Điều này thực sự tốn bao nhiêu trong production

Nếu bạn đang chạy Qwen3.8-27B làm backend cho coding agent — và Willison xác nhận nó làm tốt vai trò này sau khi được tune, test qua Pi agent — thì default xhigh không chỉ là một phiền toái về latency, nó là một hệ số nhân chi phí token ẩn trong từng lệnh gọi. Hình dung một CI pipeline chạy agent trên mỗi PR: ở default xhigh, bạn đang trả tiền cho hàng chục nghìn reasoning token bỏ đi trên những request mà setting low hoặc tắt hẳn reasoning sẽ trả lời giống hệt, chỉ nhanh hơn và rẻ hơn.

Cách sửa chỉ là một tham số, nhưng bạn phải biết để chỉnh nó:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:1234/v1", api_key="lm-studio")

response = client.chat.completions.create(
    model="qwen3.8-27b",
    messages=[{"role": "user", "content": "Draw an SVG circle, 100x100, red fill."}],
    extra_body={
        "reasoning_effort": "low"  # hoặc "none" — xhigh là default khi ship
    },
)

Nếu bạn chạy qua LM Studio hoặc Ollama thay vì một endpoint OpenAI-compatible thuần, tương đương sẽ là một flag khi load model hoặc một override per-request trong config server — kiểm tra kỹ tài liệu runtime của bạn về reasoning_effort hoặc thinking_budget trước khi ship bất cứ thứ gì dùng model này. Đừng giả định default khi ship là phù hợp cho production chỉ vì nó là default — chính giả định đó đã khiến Willison mất 21 phút.

Nửa còn lại của câu chuyện: nó thực sự tốt một khi được tune đúng

Đây không phải bài viết kiểu “bỏ qua model này”. Một khi reasoning effort được chỉnh xuống, Willison nhận thấy khả năng vision và bounding-box detection thực sự mạnh, và xác nhận nó hoạt động tốt như backend cho coding agent. Còn có một lợi ích throughput cụ thể đáng biết: Multi-Token Prediction trong LM Studio cho mức tăng throughput khoảng 72% riêng trên model này — MTP dự đoán nhiều token mỗi lượt forward pass thay vì một, và kiến trúc của Qwen3.8-27B dường như tận dụng tốt điều đó. Nếu bạn đang tự host, đây là đòn bẩy lớn hơn phần lớn các thủ thuật quantization mà bạn thường dùng.

Điều tôi thực sự sẽ làm trước khi deploy model này

Ba việc, theo thứ tự, trước khi model này chạm vào một pipeline agent production:

1. Benchmark chính workload của bạn ở từng tier reasoning-effort, không phải benchmark suite của vendor. Một prompt vẽ hình tròn và một refactor đa file có nhu cầu reasoning hoàn toàn khác nhau — low có thể đủ cho 80% traffic của agent bạn nhưng thực sự thiếu cho 20% còn lại. Đo lường, đừng đoán.
2. Chỉnh reasoning effort tường minh trong mọi request, không bao giờ dựa vào default khi ship của model. Điều này đúng với mọi model có khả năng reasoning bạn deploy, không chỉ model này — default tối ưu cho câu chuyện benchmark của vendor, không phải SLA latency của bạn.
3. Bật Multi-Token Prediction nếu bạn dùng LM Studio. Mức tăng throughput 72% đủ lớn để trở thành một phần trong config baseline, không phải một tweak opt-in bạn phát hiện ra ba tuần sau khi đã chạy production.

Bài học lớn hơn cho ai đang đánh giá open model lúc này

Các bảng xếp hạng benchmark ngày càng thưởng cho những default reasoning-effort mạnh tay, vì càng nhiều reasoning token thường đồng nghĩa điểm số cao hơn trên các bộ eval khó. Điều đó tạo ra một động lực mang tính cấu trúc để các bản release model ship “thông minh nhưng chậm và tốn kém” ngay từ đầu, rồi trông chờ người dùng tự khám phá ra nút chỉnh — đúng như những gì đã xảy ra ở đây. Khi bạn đánh giá một bản release open-weight mới, đừng chỉ đọc bảng benchmark. Hãy đọc (hoặc chạy thử) một bài test latency với tác vụ tầm thường trước. Nếu một prompt “vẽ hình tròn” mất hơn vài giây, bạn đã tìm ra đúng cái bẫy default mà Willison gặp phải, và đáng để biết trước khi bạn gắn model này vào bất cứ thứ gì chạy ở quy mô lớn.

Nguồn: Simon Willison — Qwen3.8-27B, Qwen3.8-27B specs and benchmarks