Cách chọn mô hình AI tối ưu ngay trong trình soạn thảo code

Để chọn một mô hình AI, hãy xác định nhiệm vụ, lập danh sách rút gọn các ứng viên từ dữ liệu sử dụng thực tế và dữ liệu benchmark, so sánh giá và độ trễ giữa các nhà cung cấp, sau đó kiểm tra các ứng viên cuối cùng bằng chính các prompt của bạn. Hãy đánh giá chúng dựa trên chi phí cho mỗi nhiệm vụ hoàn thành thay vì chi phí cho mỗi token, và hãy chuẩn bị tinh thần rằng câu trả lời sẽ thay đổi khi các mô hình mới được ra mắt.

Chúng tôi sẽ không nêu tên một mô hình tốt nhất duy nhất. Bất kỳ cái tên nào chúng tôi đưa ra cũng sẽ lỗi thời trong vòng một tháng, và mô hình phù hợp phụ thuộc vào những gì bạn đang xây dựng và mức phí bạn sẵn sàng chi trả để có được kết quả chính xác.

Bài viết này mô tả khung làm việc mà chúng tôi sử dụng để trả lời câu hỏi đó, và cách thực hiện nó mà không cần rời khỏi trình soạn thảo (editor) của bạn. Máy chủ MCP của chúng tôi kết nối trợ lý của bạn với các bảng xếp hạng sử dụng thực tế, các benchmark từ bên thứ ba, giá cả theo từng nhà cung cấp và một phương thức để gửi các prompt kiểm tra đến các mô hình ứng viên.

Tóm tắt (Tl;dr)

Tại sao không có mô hình AI tốt nhất duy nhất

Không có mô hình AI tốt nhất duy nhất, chỉ có mô hình tốt nhất cho một nhiệm vụ, ngân sách và thời điểm cụ thể.

Các nhiệm vụ khác nhau đòi hỏi những thế mạnh khác nhau. Việc tóm tắt và lập trình đặt ra những yêu cầu khác nhau cho một mô hình. Trích xuất dữ liệu cần định dạng JSON hợp lệ trong mọi lần gọi hơn là cần văn phong hay. Một tính năng trò chuyện phụ thuộc vào tốc độ token đầu tiên xuất hiện, điều này tách biệt với chất lượng của toàn bộ câu trả lời. Một mô hình xếp hạng nhất trong benchmark lập trình vẫn có thể hoạt động kém trên các tài liệu dài và quá đắt đỏ cho việc trích xuất dữ liệu thông thường.

Một câu hỏi hữu ích hơn cần bao gồm công việc cụ thể. Thay vì hỏi "mô hình AI nào tốt nhất", hãy hỏi "mô hình nào tốt nhất để trích xuất các dòng mục từ hóa đơn quét", hoặc "để xem xét một pull request TypeScript", hoặc "để tóm tắt bản ghi cuộc gọi dài 90 phút". Hãy viết phiên bản câu hỏi của riêng bạn, sau đó trả lời nó từ dữ liệu hiện tại thay vì từ một bảng xếp hạng cũ.

Lưu lượng truy cập của chúng tôi cho thấy câu trả lời thay đổi nhiều như thế nào tùy theo nhiệm vụ. Chúng tôi phân loại một mẫu các yêu cầu thành 29 loại nhiệm vụ và công bố thị phần. Riêng lập trình chiếm chín trong số đó, bao gồm tạo mã, gỡ lỗi, đánh giá mã, quét repo, làm việc với SQL và cấu hình DevOps. Chín loại đó không có chung một người dẫn đầu. Trong khoảng thời gian bảy ngày kết thúc vào ngày 25 tháng 7 năm 2026, một mô hình dẫn đầu tám loại và một mô hình khác dẫn đầu về đánh giá mã và bảo mật. "Mô hình tốt nhất cho lập trình" là một câu hỏi quá rộng ngay cả trong phạm vi lập trình.

Benchmark là bộ lọc, không phải là câu trả lời

Benchmark hữu ích để thu hẹp hàng trăm lựa chọn xuống còn vài ứng viên mà bạn có thể kiểm tra kỹ lưỡng. Chúng tôi hiển thị điểm số từ bên thứ ba như Artificial Analysis và Design Arena cùng với dữ liệu sử dụng của riêng chúng tôi.

Một bảng xếp hạng không thể đưa ra lựa chọn cuối cùng thay cho bạn. Điểm số thường có nhiễu, các benchmark phổ biến dễ bị tối ưu hóa (tuning), và không có cái nào trong số đó chạy các prompt của bạn. Hãy sử dụng bảng xếp hạng để lập danh sách rút gọn và dùng các bài kiểm tra của riêng bạn để quyết định.

Các nhiệm vụ khác nhau đòi hỏi những thế mạnh khác nhau. Lập trình cần chất lượng suy luận và các lệnh gọi công cụ (tool calls) đáng tin cậy. Tóm tắt cần cửa sổ ngữ cảnh lớn và giá đầu vào thấp. Trích xuất dữ liệu cần sự tuân thủ nhất quán với lược đồ (schema) hơn là sự trôi chảy. Trò chuyện cần độ trễ thấp. Thị giác (Vision) cần một mô hình chấp nhận hình ảnh, điều này thu hẹp phạm vi trước khi xét đến chất lượng.

Không có mô hình nào dẫn đầu mọi danh mục. Việc chọn một mô hình cho mọi thứ sẽ tạo ra một lựa chọn mặc định đắt đỏ, hoạt động tốt trong các bản demo nhưng lại kém hiệu quả trong công việc thực tế bạn thực hiện.

Thiết lập máy chủ OpenRouter MCP

Mọi bước dưới đây đều chạy thông qua máy chủ MCP, vì vậy hãy kết nối nó trước.

Máy chủ OpenRouter MCP được lưu trữ bởi chúng tôi, vì vậy không cần cài đặt gì cục bộ. Bất kỳ ứng dụng khách MCP nào cũng có thể kết nối. Thiết lập dưới đây bao gồm Claude Code, Cursor và Codex CLI, tài liệu cũng bao gồm OpenCode và Claude Desktop. Bạn kết nối một lần, sau đó trợ lý của bạn có thể lấy các mô hình trực tiếp, giá cả, tín dụng, bảng xếp hạng, benchmark và tài liệu, đồng thời gửi các prompt kiểm tra mà bạn không cần rời khỏi trình soạn thảo. Hãy sử dụng nó trong khi bạn đang chọn mô hình. Khi bạn triển khai, hãy gọi API như bình thường.

Claude Code:

Bạn cũng có thể xác thực từ bên trong phiên làm việc bằng cách chạy /mcp, chọn openrouter và nhấp vào Authenticate.

Cursor: thêm nội dung này vào ~/.cursor/mcp.json, sau đó xác minh bằng lệnh cursor-agent mcp list.

Codex CLI:

Xác thực là một bước trên trình duyệt và hoạt động theo cùng một cách trong cả ba trình soạn thảo. Trong Cursor, nó chạy ở yêu cầu đầu tiên của bạn thay vì từ lệnh đăng nhập. Một yêu cầu chưa xác thực sẽ trả về lỗi 401, khởi động luồng OAuth của chúng tôi, và màn hình phê duyệt sẽ nêu rõ những gì bạn đang đồng ý trước khi bạn xác nhận.

Chúng tôi tạo một khóa có nhãn OpenRouter MCP: <tên ứng dụng>, giới hạn cho ứng dụng khách đó, với thời hạn bảy ngày và giới hạn tín dụng 10 đô la mà bạn có thể thay đổi trên màn hình đó (thông báo MCP). Khóa có thời hạn ngắn và bị giới hạn theo mặc định, bạn có thể ngắt kết nối bất kỳ lúc nào và có thể thu hồi từ bảng điều khiển khóa của mình.

Luồng này chuyển hướng đến localhost, điều này là bình thường đối với một ứng dụng khách máy tính để bàn như Claude Code hoặc Cursor, nhưng điều đó có nghĩa là chúng tôi không thể xác minh ứng dụng cục bộ nào nhận được khóa. Chỉ phê duyệt nếu bạn là người tự bắt đầu kết nối cách đây ít phút.

Các công cụ bạn sẽ sử dụng

Hầu hết là các lệnh tra cứu chỉ đọc dựa trên dữ liệu trực tiếp. Các ngoại lệ là send-message, generate-image, transcribe-audio và generate-speech, vốn thực hiện các lệnh gọi suy luận có tính phí, và send-feedback, dùng để viết phản hồi về một trong các kết quả bạn tạo ra (tài liệu MCP).

Trợ lý gọi list-task-classifications cho thẻ code:general_impl và trả về các mô hình dẫn đầu cùng với thị phần sử dụng và token của chúng, sau đó tiếp tục đến phần giá cả theo nhà cung cấp. Không cần trình duyệt.

Khung sáu bước để chọn một mô hình

Hãy thực hiện các bước này theo thứ tự. Các bước từ 2 đến 5 tương ứng với một lệnh gọi cụ thể mà trợ lý của bạn có thể thực hiện dựa trên dữ liệu trực tiếp. Bước 1 và 6 là sự đánh giá của bạn: bạn xác định những gì bạn cần và sau đó quyết định những gì sẽ triển khai.

Bước 1. Xác định nhiệm vụ như cách bạn sẽ triển khai

Bắt đầu với công việc, không phải tên mô hình. Viết ra đầu vào, đầu ra bạn mong đợi, thế nào là tốt, mục tiêu độ trễ của bạn và bạn ưu tiên điều gì khi chi phí và chất lượng xung đột.

Mục cuối cùng ảnh hưởng đến mọi bước sau đó. Một bản tóm tắt hiển thị cho khách hàng biện minh cho mức giá cao hơn. Một công việc trích xuất hàng đêm trên một triệu bản ghi biện minh cho mức giá thấp hơn, ngay cả khi phải đánh đổi một chút về chất lượng, vì khối lượng công việc quyết định hóa đơn. Hãy nêu rõ bạn đang xây dựng loại nào.

Bước 2. Lập danh sách rút gọn từ dữ liệu trực tiếp

Danh sách rút gọn đến từ hai câu hỏi: mọi người đang sử dụng gì cho công việc này và cái gì đạt điểm cao trong công việc đó?

Đối với câu hỏi đầu tiên, hãy gọi list-task-classifications. Nó trả về 29 thẻ nhiệm vụ của chúng tôi trong khoảng thời gian bảy ngày gần nhất, mỗi thẻ kèm theo thị phần sử dụng và danh sách xếp hạng các mô hình phục vụ nó, được rút ra từ lưu lượng truy cập thực tế. Đối với câu hỏi thứ hai, hãy gọi list-benchmarks với task_type được đặt là coding, intelligence hoặc agentic, lệnh này trả về điểm số của Artificial Analysis và Design Arena cùng với giá cả. Ba danh mục đó cố tình được phân loại thô hơn 29 thẻ lưu lượng truy cập, và hai lệnh gọi này được thiết kế để sử dụng cùng nhau. Bộ lọc benchmark loại bỏ các mô hình có điểm số thấp trong một danh mục rộng, và thẻ lưu lượng truy cập sau đó cho thấy mô hình nào mọi người sử dụng cho phần cụ thể của bạn.

list-daily-model-rankings hữu ích cho các xu hướng. Theo mặc định, nó trả về tổng số token hàng ngày cho 50 mô hình hàng đầu, cộng với một hàng tổng hợp "khác" mỗi ngày. Bạn có thể thu hẹp nó theo danh mục trường hợp sử dụng như lập trình hoặc nhập vai, theo phương thức (modality), hoặc theo hoạt động gọi công cụ, nhưng các lát cắt danh mục đến từ một tập dữ liệu mẫu được tổng hợp hàng tuần, vì vậy hãy coi các tổng số đó là ước tính. Nó cho bạn biết cái gì đang tăng trưởng, không phải cái gì hoạt động tốt trên công việc của bạn. Chế độ xem tương tự có sẵn tại openrouter.ai/rankings.

Bước 3. So sánh chi phí, nhà cung cấp và độ trễ

Đối với mỗi ứng viên cuối cùng, hãy gọi list-model-endpoints. Bạn sẽ nhận được mọi nhà cung cấp đang phục vụ mô hình đó cùng với giá cả, độ dài ngữ cảnh, thông lượng và độ trễ trong ba mươi phút qua, thời gian hoạt động (uptime), lượng tử hóa (quantization) và các tham số được hỗ trợ. Cùng một mô hình có thể khác biệt giữa các nhà cung cấp về giá, tốc độ và độ tin cậy, và tốt hơn là nên tìm ra những khác biệt đó ở đây thay vì trong môi trường sản xuất.

Trang so sánh hiển thị cùng dữ liệu đó trong trình duyệt khi bạn cần chia sẻ nó với ai đó.