Chọn giữa astra, sol, terra và luna

Bốn model, một endpoint, một khoản ngân sách. Câu hỏi thật sự của một tài khoản mới không phải model nào mạnh nhất, mà là mỗi phần công việc nên đi qua model nào — và câu trả lời không bao giờ là một cái tên duy nhất. Đó là một quyết định định tuyến, ra một lần cho mỗi lớp request, rồi đối chiếu lại bằng chính bảng kê usage của bạn. Dưới đây là quyết định đó, theo đúng thứ tự nên ra.

Bắt đầu ở terra

Terra là mặc định chứ không phải phương án thoả hiệp. Vai trò đã công bố của nó là việc trợ lý hằng ngày — RAG, agent, tool, coding — và bấy nhiêu đã phủ gần hết những gì một sản phẩm thực sự gửi đi: chat thông thường, trích xuất theo một cấu trúc có sẵn, và phần hỗ trợ code thiên về gõ hơn là nghĩ. Ở input nó bằng một nửa sol, 0.5 so với 1 của sol, và trọng số output là 3 so với 5 của sol.

Vậy hãy khởi đầu một lớp request mới ở đó, rồi thành thật với kết quả. Nếu câu trả lời của terra đúng là thứ bạn sẽ ship, bạn đã tìm ra model đúng và trả nửa dưới của hoá đơn cho nó. Nâng lên là quyết định dựa trên bằng chứng chỉ ra được — một ca hỏng bạn đưa ra cho người khác xem — chứ không phải nâng cho chắc.

Khi nào một lớp request xứng đáng lên sol

Sol là mốc neo của cả bảng giá: một token input của sol là một credit, và mọi con số khác trên trang này đều là tỉ lệ so với nó. Vai trò đã công bố của sol là suy luận sâu, coding khó, tác vụ kiểu Codex, nghiên cứu — và đó cũng chính là phép thử để chuyển. Hãy đưa một lớp request lên sol khi chiều sâu suy luận thấy rõ là đáng: con bug khó mà terra cứ đi vòng quanh, phân tích nhiều bước mà các bước giữa phải đúng thì kết luận mới đúng, thay đổi buộc phải giữ cả một file trong đầu cùng lúc.

Bước chuyển đó tốn gấp đôi input của terra và hơn hai phần ba output: 1 và 5 so với 0.5 và 3. Với một lớp request trước đó hỏng và giờ chạy được thì đó là cái giá rẻ; với một lớp vốn đã ổn thì đó là cái giá đắt. Hãy chuyển từng lớp chứ đừng chuyển cả ứng dụng — không có gì trong bốn model này là một thiết lập toàn cục, và thứ rẻ nhất trên trang này là request bạn không nâng cấp.

astra dành cho việc gì

Astra là suy luận đầu bảng trên cửa sổ 1 triệu token, cho việc khó nhất, và nó được định giá để bạn tiêu có chủ đích: 2.5 ở input và 12.5 ở output, so với 1 và 5 của sol. Hãy đọc điều đó như một chỉ dẫn chứ không phải một lời cảnh báo. Astra dành cho lượt rà soát cuối trước khi một thứ được ship, cho bản phân tích mà ai đó sẽ hành động theo, cho tác vụ một lần mà không ai đọc lại — những việc mà một câu trả lời sai đắt hơn số token đã tiêu.

Có một thứ không nằm trong quyết định này: độ dài. Ở đây không model nào bị phụ thu cho ngữ cảnh dài. Giá ngữ cảnh dài của mỗi model đúng bằng giá ngữ cảnh ngắn của chính nó, dòng nào cũng vậy, nên một tài liệu dài không làm đổi câu trả lời nên gửi nó cho model nào. Hãy chọn theo độ khó của công việc, còn độ lớn của input thì cứ để nó như nó vốn có.

luna gánh phần chạy nền

Không phải mọi thứ một sản phẩm gửi đi đều đáng dùng model suy luận. Phân loại, gắn nhãn, tóm tắt ngắn, quyết định một mục thuộc hàng đợi nào — những lượt chạy trên từng bản ghi mà không ai đọc riêng lẻ — là phần của luna, với vai trò đã công bố là bản nháp nhanh, phân loại, tóm tắt, chat khối lượng lớn. Ở mức 0.05 cho input, nó rẻ hơn sol hai mươi lần, và trọng số output là 0.3.

Nhưng hãy giữ prompt của nó gọn, không thì bạn trả lại nguyên khoản tiết kiệm vừa có. Một job chạy nền không cần toàn bộ ngữ cảnh của bạn: system prompt dài làm nên chất lượng của trợ lý chính thường chỉ là gánh nặng chết trong một bộ phân loại, và khoản rẻ hơn hai mươi lần trên đơn giá bị xoá sạch khi bạn gửi gấp hai mươi lần số token. Hãy gửi đúng mục cần xử lý, đúng danh sách nhãn, và không gì khác.

Trộn cả bốn, rồi kiểm lại hoá đơn

Số credits trên mỗi token, theo model và theo lớp, lấy thẳng từ catalogue mà cả site này dùng để định giá mọi thứ khác — bốn dòng mà các đoạn trên chỉ là tỉ lệ của chúng:

Không có gì ở đây là thiết lập chọn một lần rồi thôi. Bốn model dùng chung một endpoint và một key, còn model chỉ là một field trong body bạn vốn đã gửi — đổi một chữ trên request cần rẻ, đổi một chữ trên request cần đúng.

POST /v1/chat/completions

{
  "model": "terra",
  "messages": [
    {"role": "user", "content": "Tóm tắt ticket này trong một dòng."}
  ]
}

Nếu code của bạn đang gọi một tên model kiểu OpenAI, nó được đọc thành đúng lớp mà tên đó thuộc về, nên cấu hình sẵn có vẫn chạy trong lúc bạn còn đang cân nhắc đổi sang gì. Chính điều đó làm việc thử trộn model rẻ đi: bạn không phải chuyển đổi thứ gì cả để cho một lớp request chạy ở chỗ khác trong một tuần.

Một agent chạy vòng lặp còn hai điều nữa phải làm đúng. Thứ nhất, giữ một tiền tố ổn định ở đầu mỗi lượt — system prompt, phần định nghĩa tool, những chỉ dẫn không đổi giữa các lượt — vì một token đọc lại từ tiền tố đã cache chỉ bị tính bằng một phần mười đơn giá input của chính model đó, còn vòng lặp dựng lại prompt mỗi lượt thì trả giá đầy đủ cho đúng những chữ ấy, lượt nào cũng vậy. Thứ hai, định tuyến các tầng có chủ đích chứ đừng theo thói quen: cái planner quyết định làm gì tiếp thường xứng đáng sol hoặc astra, các worker thi hành từng bước của nó là terra, còn lượt chạy dọn và xếp kết quả phía sau là luna. Một agent, ba model, cố ý như vậy.

Rồi hãy kiểm lại. Mọi request đều được liệt kê từng dòng trong portal của bạn theo đúng các mức trong bảng trên — model nào, lớp token nào, bao nhiêu credits — nên cái mix mà bạn nghĩ mình đang chạy là thứ kiểm chứng được chứ không phải đoán. Đó là thứ biến tất cả những gì ở trên từ một ý kiến thành một quy trình: lấy cách định tuyến từ trang này, cho một tuần traffic thật của bạn chạy qua nó, rồi đọc ngược lại bảng kê.