Một buổi nghiệm thu formal Hy4: bảng xanh/đỏ trước khi merge canary

Formal Hy4 lên lịch công bố khoảng 2026-11-04. Preview (hy4-preview) mình từng chạm từ cuối tháng 8/2026. Bài này không phải nhật ký “mở model → chấm điểm → đề tiếp”. Mình gắn formal Hy4 vào một ticket nghiệm thu trên board: có bảng acceptance, có dòng xanh/đỏ, có quyết merge canary hay không. Mục tiêu của buổi là trả lời đúng một câu — ticket này có đủ bằng chứng để cho hy4 vào lane canary không?

Ngày viết và đo: 2026-11-05. Gateway mình dùng: https://api.crazyrouter.com/v1, model id hy4. Trên gateway này không có hy4-preview, nên không có A/B cùng đường. Mọi số liệu bên dưới chỉ nói về formal hy4 hôm đó.

Hy4 trên ticket: đóng khung trước khi đụng model string

Trước khi sửa model, mình dán bốn dòng lên ticket (comment cũng được):

1. Việc cần nghiệm thu là gì? Lane có ảnh cần đọc (biểu đồ / UI crop), không phải “đổi tên cho mới”.
2. Tiêu chí xanh tối thiểu? (a) đọc đúng một mẫu ảnh đại diện, (b) không nuốt content rỗng mà vẫn báo success, (c) smoke ngắn còn trả lời được.
3. Cái gì không nằm trong buổi này? Computer use (CLI/GUI) và claim agent dài hạn — mình chưa đo, nên không ghi “pass” trên ticket.
4. Điều kiện merge canary? Chỉ khi bảng acceptance không còn dòng đỏ bắt buộc; curl để sau cùng.

Đóng khung kiểu này để tránh buổi nghiệm thu trôi thành buổi demo marketing. Formal Hy4 có nhiều lời giới thiệu; ticket của mình chỉ mua đúng phần mình chứng minh được trong một buổi.

ID cần nhớ: preview hy4-preview, formal hy4 (OpenRouter hay gặp tencent/hy4). Preview từng mở weight Apache 2.0; formal weight chưa công bố lúc viết bài — ghi chú này nằm ngoài cột xanh/đỏ kỹ thuật, nhưng hữu khi ai đó hỏi “self-host được chưa”.

Hy4: bảng nghiệm thu xanh/đỏ mình dùng trong buổi

Mình không kể từng lần bấm. Chỉ để lại bảng gắn ticket:

Bảng này khác checklist “thử hết mọi tính năng”. Dòng ngoài phạm vi không được tô xanh cho đẹp ticket. Nếu PM muốn thêm computer use vào Definition of Done, phải mở buổi nghiệm thu khác với kịch bản CLI/GUI thật — không vay bảng trên.

Coding chỉ là phụ: một brief rows.sort side-effect + list rỗng + date key, max_tokens đủ lớn thì model chỉ ra lỗi và viết lại; để thấp (2048/8192 tùy case) có lúc lại empty. Mình không biến coding thành hàng tiêu đề của buổi Hy4 này.

Hy4 — hàng vision trên bảng nghiệm thu

Hàng vision là lý do ticket tồn tại. Preview không có vision theo mô tả cập nhật; formal Hy4 được nêu là lần đầu có hiểu ảnh. Mình chỉ cần một mẫu đủ cứng để không tự dối:

• PNG synthetic bốn cột N/E/S/W.
• Câu hỏi một dòng: vùng cao nhất + giá trị.
• Kỳ vọng: S và 200 (thứ tự ghi có thể hơi khác, nghĩa phải đúng).

Lần đo ~8.9s, finish=stop. Vậy là đủ để tô xanh hàng vision trên ticket canary ảnh. Không đủ để tuyên bố OCR hóa đơn, UI phức tạp, hay pipeline ảnh→video. Nếu team đang soi catalog sinh ảnh/video gần đó — ví dụ Kling AI models — đó là ticket khác, model khác; đừng nhét vào buổi nghiệm thu Hy4.

Thực dụng: lane text giữ nguyên; chỉ nhánh có image_url mới trỏ hy4. Canary hẹp hơn fleet-swap.

Hy4 — hàng empty-guard: đỏ giả thành xanh mới nguy hiểm

Hàng mình cay nhất không phải vision sai, mà HTTP 200 + content rỗng. Với max_tokens 128, 256, 512, 1024, formal Hy4 vẫn 200, finish_reason=length, content rỗng — token đi hết về phía reasoning. Lên 2048 thì chữ bắt đầu ra, đôi khi vẫn bị length cắt.

Nếu client cũ chỉ check status code, hàng này sẽ tô xanh giả. Trên bảng nghiệm thu mình ghi rõ:

• Xanh empty-guard = đã bắt được case rỗng và có retry/max_tokens floor.
• Đỏ = còn đường nào nuốt rỗng thành “OK”.

Ping 256 token × 12 lần trả「收到」ổn định 2.6–4.0s chứng minh route sống; nó không thay được empty-guard. Hai hàng tách nhau trên ticket.

Hy4: giới hạn trung thực của buổi nghiệm thu

Ba điều mình viết thẳng vào comment ticket, để sau này không ai “suy ra” quá đà:

1. Không A/B preview trên cùng gateway Crazyrouter. Không bịa latency/score đối đầu.
2. Không claim computer use / agent. Chưa đo = chưa có cột xanh.
3. Giá list không phải lý do merge. TokenHub công bố khoảng CNY 6 / 18 / 0.3 mỗi 1M in/out/cache; formal giữ band này theo mô tả cập nhật. Mình không gắn khuyến mại hay “nửa giá” vào ticket. So band với model khác thì mở trang giá riêng (ví dụ Gemini 2.5 Flash-Lite pricing) — đó là việc kế toán, không phải acceptance kỹ thuật của buổi Hy4.

Nhạc / BGM cũng ngoài scope: có thể xem AI music generation models khi team làm audio, nhưng không có hàng nào trên bảng Hy4 hôm nay liên quan.

Hy4: curl để muộn — sau khi bảng đã nói được chuyện

Chỉ khi vision xanh, empty-guard xanh, smoke xanh, mình mới dán curl vào runbook. Thứ tự cố ý: acceptance trước, dây nối sau.

curl https://api.crazyrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "hy4",
    "messages": [{"role": "user", "content": "用一句话介绍你自己"}],
    "max_tokens": 512
  }'

Thông thì tách ba lớp: HTTP, message.content, usage (prompt / completion / reasoning nếu có). Một lần smoke ~9.5s không phải benchmark; nó chỉ chứng minh route formal Hy4 hôm đó đi được. Ảnh thì thêm part image_url — đừng lấy curl chữ thuần làm bằng chứng vision.

Hy4: merge canary hay chưa — quyết trên ticket

Cuối buổi mình chỉ ghi một trong hai:

• Merge canary hẹp: nhánh có ảnh + empty-guard đã bật; text lane chưa đụng; release note không viết computer use.
• Chưa merge: thiếu mẫu ảnh đại diện của team, hoặc client còn nuốt content rỗng, hoặc ai đó muốn “bật hết claim formal” trong cùng PR.

Formal Hy4 với mình là linh kiện có điều kiện, không phải skin đổi tên. Buổi nghiệm thu xong khi bảng nói được chuyện — không phải khi đã thử đủ mọi bullet trên landing. Mai có kịch bản GUI thật thì mở ticket mới; hôm nay không vay xanh.

Đó là toàn bộ buổi nghiệm thu formal Hy4 của mình ngày 2026-11-05: đóng khung → bảng → vision → empty → trung thực → curl muộn → merge hoặc không.