Phân tích AIDoc trong 12 phut

Mercury 3 hứa trả lời nhanh hơn. Nhiệm vụ AI của bạn có xong sớm hơn?

Mô hình ngôn ngữ khuếch tán mới của Inception nhắm đến tương tác. Tốc độ hữu ích ở đâu, so toàn nhiệm vụ thế nào và vì sao giá ra mắt cần cột riêng?

K
Ken Jo

Khách hỏi đơn hàng đổi được trước khi giao không. Trợ lý tìm đơn, đọc chính sách, kiểm trạng thái kho rồi chuẩn bị đáp. Mỗi bước có vẻ nhỏ. Cộng lại, thời gian chờ khiến trao đổi đơn giản như kết nối chậm với người rất bận.

Inception ra mắt Mercury 3 ngày 19 tháng 10, nhắm mô hình ngôn ngữ khuếch tán mới vào ứng dụng nơi khoảng dừng tích lũy. Công ty báo cáo 1.068 token đầu ra mỗi giây trên GPU NVIDIA, cùng cửa sổ ngữ cảnh 1 triệu token. Đây là thông số hãng, không bảo đảm toàn tương tác khách hàng. Thông báo Inception.

Câu hỏi thú vị là mô hình nhanh hơn cho bạn đổi gì. Gia sư gợi ý khi người học còn làm. Tác nhân hỗ trợ kiểm ngoại lệ trước đáp. Trợ lý trình duyệt làm thêm bước hữu ích trong cùng thời gian chờ. Bài viết hướng dẫn các khả năng, chi phí và cách thực tế đánh giá Mercury 3 có cải thiện đúng nhiệm vụ bạn có.

Bộ tăng tốc NVIDIA H100 PCIe trên bàn, ảnh của Geekerwan

Phần cứng NVIDIA H100, minh họa bối cảnh suy luận GPU. Ảnh: 极客湾Geekerwan, nguồn Wikimedia Commons, CC BY 3.0; đổi kích thước và chuyển JPEG, giữ watermark tác giả. Không phải hạ tầng Inception hay benchmark chúng tôi, không xác định phần cứng dùng cho kết quả Mercury 3 công bố.

Khuếch tán cho Inception đường khác đến văn bản nhanh

Inception là công ty nghiên cứu, sản phẩm AI bán mô hình ngôn ngữ qua dịch vụ lưu trữ. Dòng Mercury dùng khuếch tán, tinh chỉnh văn bản qua nhiều vị trí thay vì hoàn toàn dựa vào chuỗi trái sang phải. Bài Mercury của nhóm, gửi ngày 17 tháng 6 năm 2025, mô tả phương pháp và đánh giá dòng trước. Đây là bối cảnh cách tiếp cận, không báo cáo benchmark Mercury 3.

Ý nghĩa cho độc giả đơn giản: thứ tự mô hình tính văn bản có thể ảnh hưởng tốc độ ứng dụng nhận đáp hữu ích. Không làm mọi phản hồi tức thì hay câu khó không cần suy luận. Nó đổi một phần công tạo đáp. Phần còn lại vẫn phải lấy thông tin, quyết xử lý và trình thứ người dùng được.

Hãy coi độ trễ là ngân sách chờ. Lập trình viên có thể dùng ngân sách đó cho lời giải thích dài hơn, kiểm thêm nguồn hoặc trả câu ngắn sớm hơn. Mô hình nhanh tạo khoảng dư trong ngân sách. Khoảng dư đó có mang lợi ích cho người dùng hay không phụ thuộc vào cách ứng dụng sử dụng nó.

Điều này quan trọng nhất khi gọi lặp. Trợ lý cần một đáp ngắn ít cơ hội tiết kiệm. Tác nhân xen đọc, chọn hành động và xem kết quả có thể trả độ trễ mô hình nhiều lần. Tiết kiệm ở bước lặp đổi trải nghiệm dù từng đáp không ngoạn mục.

Token mỗi giây chỉ đo một đoạn hành trình

Nhiệm vụ đi qua truy xuất, phản hồi đầu, tạo văn bản, công cụ và xác minh

Đồ họa biên tập tự biên soạn: giai đoạn góp thời gian hoàn tất. Kích thước đoạn là sơ đồ, không có thời lượng đo.

Có nhiều đồng hồ trong tính năng AI. Thời gian đến đáp đầu mô tả giao diện chờ bao lâu trước điều hữu ích. Thông lượng đầu ra mô tả văn bản đến nhanh ra sao. Độ trễ công cụ gồm tìm, cơ sở dữ liệu, dịch vụ ngoài. Thời gian nhiệm vụ gồm bước để có kết quả đúng, kể cả thử lại, sửa.

Các đồng hồ có thể khác hướng. Hệ thống phát chữ đầu ngay nhưng lâu mới xong yêu cầu khó. Hệ thống khác chờ rồi trả gọn không cần sửa. Hệ thống thứ ba sinh nhanh nhưng phần lớn chờ hệ thống đơn. Con số quan trọng với người dùng phụ thuộc việc.

Phép đoCho người xây biết gìĐiều bỏ ngỏ
Phản hồi hữu ích đầuGiao diện ghi nhận hay tiến yêu cầu nhanh khôngKết quả cuối đúng không
Token đầu ra mỗi giâyVăn bản sinh nhanh ra saoThời gian tìm, hàng đợi, trễ công cụ
Thời gian toàn nhiệm vụMất bao lâu có kết quả đúngThành phần nào làm chậm
Thời gian gồm sửaChi phí thực tế đạt kết quả chấp nhậnNhiệm vụ khác có tương tự không

Theo chúng tôi, mô hình nhanh đáng dùng khi bớt thời gian công việc người dùng. Giai đoạn sinh ngắn có giá trị khi rút việc hay làm kiểm cần thiết đủ rẻ. Ít giá trị nếu ứng dụng dùng tiết kiệm tạo thêm văn bản chẳng ai cần.

Giữ câu hỏi benchmark cụ thể. Nhiệm vụ có nhanh hơn cùng chuẩn chấp nhận? Bước nào đổi? Như vậy dễ tách cải thiện mô hình khỏi lời nhắc ngắn, cache ấm hay dịch vụ ngoài nhanh.

Trợ lý hỗ trợ có thể dùng thời gian tiết kiệm cho đáp tốt

Xét quy trình hỗ trợ bán lẻ minh họa. Khách muốn đổi địa chỉ sau đặt. Trợ lý cần trạng thái đơn, chính sách và chi tiết sửa. Đầu ra hữu ích là bước đúng: đổi được phép qua công cụ được ủy quyền, hoặc giải thích cần người can thiệp.

Tốc độ giúp nhiều điểm. Hỏi rõ nhanh ngăn khách bỏ chat. Đọc chính sách nhanh chừa thời gian kiểm ngoại lệ đơn đang đóng. Đáp cuối gọn xác nhận đã đổi và còn chờ gì. Không cải thiện nào cần viết dài hơn.

Đánh giá nên có ma sát thường: khách sửa mã bưu điện, đơn đã gửi, tài liệu có ngoại lệ hẹp. Đo có dùng giá trị mới thay vì đầu tiên không. Giữ quyền thay đổi riêng khả năng mô tả thay đổi.

Tránh đáp nhanh tự tin gây thêm việc. Nếu khách phải liên hệ lại sửa kết quả, phản hồi đầu chỉ hiệu quả bề ngoài. Ghi theo dõi và chuyển người cùng tốc độ ban đầu. Đó là cách số mô hình hấp dẫn thành quyết định vận hành hữu ích.

Gia sư hưởng lợi khi phản hồi đến trước lúc chú ý chuyển

Trường hợp minh họa thứ hai là ứng dụng học đáp bài ngắn. Người học gửi câu ngoại ngữ hoặc bước trung gian đại số. Ứng dụng phải xác định lỗi liên quan, đưa bước tiếp hợp. Đáp nhanh giữ người học ở cùng câu hỏi.

Đáp không luôn cần đầy đủ. Gợi ý nhỏ có thể hơn lời giải hết. Đánh giá phân biệt phản hồi đúng với giúp quá mức: nhận lỗi, giữ cơ hội học và dùng ngôn ngữ đúng trình không? Giải thích nhanh sai cấp vẫn ngắt bài.

Tạo mẫu có nhiều đáp chấp nhận và đáp cố ý mơ hồ. Yêu cầu một gợi ý trước giải đầy. Thêm người học đổi đáp, kiểm ứng dụng phản hồi bản sửa. Các trường hợp cho thấy mô hình theo tương tác giáo dục hay chỉ sinh đáp án.

Với gia sư giọng nói, mô hình văn bản là một phần. Nhận dạng, xử lý lượt và tạo giọng thêm thời gian, lỗi riêng. Thử toàn trao đổi nói trước đổi thông lượng văn bản thành tuyên bố phản hồi hội thoại. Giai đoạn chữ nhanh tạo dư địa, trong khi âm thanh vẫn quyết tự nhiên.

Tác nhân trình duyệt cần đồng hồ và quy tắc dừng

Trường hợp ba là so điều khoản nhà cung cấp qua trang công khai. Nó đọc, chọn liên kết, rút điều kiện, kiểm nguồn khác. Gọi mô hình nhanh giảm chờ lặp. Cũng có thể cám dỗ duyệt tiếp vì bước nữa rẻ.

Định nghĩa hoàn thành trước đo. Ví dụ kết thúc khi có giá kèm ngày, giới hạn dịch vụ và nguồn cho mỗi ứng viên. Dừng khi đủ, hoặc báo thiếu sau tìm có giới hạn. Lời gọi thêm hữu ích khi giải điều chưa chắc đã nêu.

Nhiệm vụ trình duyệt cũng cần ranh giới. Đọc công khai khác gửi biểu mẫu, đổi tài khoản, mua. Đổi mô hình phải giữ quyền và điểm xác nhận hiện có. Nhanh hơn làm sai sớm hơn; không làm hành động phù hợp hơn.

So việc thành công, thất bại riêng. Nếu mô hình dừng sớm và mô hình kia khám phá lâu, trung bình che khác biệt. Giữ số bước, lỗi công cụ và bằng chứng thiếu cạnh thời gian. Kết quả cần giải thích kết thúc thế nào, không chỉ chạy bao lâu.

Bảng giá cần cột sau khuyến mãi

Kiểm ngày 23 tháng 10, trang mô hình ghi Mercury 3 0,20 USD mỗi triệu token vào và 0,70 USD mỗi triệu token ra, khuyến mãi ra mắt giảm còn 0,10 và 0,35 USD. Đầu vào cache có giá riêng. Trang không nêu ngày hết, nên ngân sách cần giữ trường hợp giá niêm yết.

Token API trực tiếpGiá niêm yết mỗi 1 triệuGiá ra mắt mỗi 1 triệu
Đầu vào0,20 USD0,10 USD
Đầu vào cache0,02 USD0,01 USD
Đầu ra0,70 USD0,35 USD

Với minh họa 100 triệu token vào không cache và 20 triệu ra, số học là 34 USD giá niêm yết, 17 USD giá ra mắt. Giả định đúng khối lượng đó, bỏ dịch vụ khác. Đây là cách so hai chế độ giá, không ước chi hỗ trợ thật.

So chi token, công cụ, thử lại và xem xét với nhiệm vụ hoàn tất được chấp nhận

Khung đánh giá biên tập tự biên soạn. So tổng tài nguyên với số nhiệm vụ được chấp nhận; không hiển thị chi hay tỷ lệ thành công đo thật.

Lời gọi rẻ vẫn thuộc quy trình đắt. Truy xuất, trình duyệt, giọng nói, người xem và thử lại đổi tổng. Ngược lại lời gọi đắt hơn có thể kinh tế nếu tránh thất bại. Theo dõi chi mỗi nhiệm vụ chấp nhận cùng giá token.

Cache cũng cần kỷ luật. Không mặc định mọi tài liệu lặp hưởng giá cache. Ghi nhà cung cấp thật tính gì, dùng điều kiện tài liệu cho đường đó. Cùng mô hình qua nhiều nền tảng có thể khác điều khoản, giới hạn, giá. Giữ đường phục vụ trong hồ sơ so.

Bắt đầu chạy lại mẫu nhỏ, rồi đổi một thành phần

Hướng dẫn nhanh, kiểm ngày 23 tháng 10, xác định tên mercury-3, ghi SDK và điểm cuối chat-completions tương thích. Cho ứng dụng hiện có lộ trình tích hợp thực tế. Tương thích giúp yêu cầu đầu dễ; hành vi lời nhắc và độ tin quy trình vẫn cần kiểm riêng.

  1. Chọn nhiệm vụ đảo ngược được. Bắt đầu bản đáp hay gợi ý người kiểm được. Thu mẫu nhỏ được phép, có quy tắc chấp nhận từng ca.
  2. Lưu cơ sở so. Ghi mô hình, prompt, cỡ vào, giới hạn ra và kết quả công cụ hiện tại. Giữ đầu ra chấp nhận, thời gian từng ca.
  3. Tạo tài khoản, khóa Inception. Giữ khóa trong biến môi trường hay quản lý bí mật hiện có. Kiểm thanh toán, kiểm soát dùng trước lô.
  4. Chạy yêu cầu tài liệu với mercury-3. Giữ nhiệm vụ, tiêu chí. Log thiết lập gồm mức suy luận, giới hạn ra để lặp được.
  5. Xem thất bại trước mở lưu lượng. Kiểm sai sự kiện, thiếu điều kiện, lỗi schema, gọi thừa. Lặp ca đại diện để hiểu biến thiên.
  6. Thử có đường quay lại. Giữ nhà cung cấp trước, đặt trần dùng, theo dõi thời gian và chi nhiệm vụ chấp nhận trong lưu lượng thường.

Điểm bắt đầu Python tối thiểu có thể điều chỉnh ví dụ SDK chính thức cho prompt không nhạy cảm:

Python
from inceptionai import Inception

client = Inception()  # reads INCEPTION_API_KEY
response = client.chat.completions.create(
    model="mercury-3",
    messages=[{"role": "user", "content": "Give one hint for solving 3x + 4 = 19."}],
    reasoning_effort="medium",
    temperature=0.75,
    max_completion_tokens=512,
)
print(response.choices[0].message.content)

Hiện vật tiếp hữu ích là bảng so có kết quả đúng và ca thất bại. Yêu cầu mẫu thành công xác lập kết nối. Không xác lập mọi thiết lập, schema công cụ, prompt cũ hành xử y hệt.

Chất lượng, kiểm soát dữ liệu cần cạnh tốc độ

So ra mắt Inception khích lệ cho nhóm đích, nhưng năng lực rộng khác độ hợp việc. Trang Mercury 3 của Vals AI, kiểm ngày 23 tháng 10, báo kết quả nhiều nhiệm vụ với thiết lập riêng. Điểm cần đọc trong định nghĩa benchmark, không gộp thông lượng hãng thành xếp hạng phổ quát.

Thói quen hữu ích hơn là xem điểm không đều. Mô hình có thể rất tốt đáp cấu trúc ngắn, yếu ở việc chuyên môn mà ứng dụng coi thường. Đưa ca khó vào sớm. Bộ chỉ gồm thành công cho biết ít về nơi người cần giúp.

Dữ liệu cũng tùy dịch vụ, thỏa thuận. Điều khoản mô tả tùy chọn từ chối huấn luyện trong tài khoản; trang doanh nghiệp có kiểm soát lưu, triển khai cấu hình được. Xem đường, hợp đồng trước gửi dữ liệu khách. Dùng ví dụ tổng hợp hoặc được phép đúng cho so đầu.

Người dùng cũ cần giữ ngày thực tế: trang nói khách có dùng Mercury 2 hay 2.5 trước 19 tháng 10 giữ quyền đến 15 tháng 11 năm 2026, hỗ trợ doanh nghiệp theo hợp đồng. Di chuyển cần lịch chạy lại, kế hoạch quay lại. Prompt cũ quen không thay kiểm trên mô hình mới.

Sinh nhanh nên mua bước tiếp hữu ích hơn

Mercury 3 lập luận xem tốc độ suy luận như lựa chọn thiết kế. Cơ hội là dùng thời gian lấy lại để sửa, kiểm nguồn hay phản hồi khi còn giúp. Lo là hệ thống nhanh cũng tạo thêm việc chưa xem. Bằng chứng có nghĩa tiếp theo là hiệu năng đáng tin trên toàn nhiệm vụ người yêu cầu hoàn tất.

Thử tốt kết bằng đáp cụ thể: quy trình này nhanh hơn cùng chuẩn, hoặc không. Đó là tuyên bố nhỏ hơn nhanh nhất mọi thứ. Cũng là tuyên bố nhóm dùng để ra trải nghiệm tốt hơn.


Nguồn tham khảo

Giữ so sánh sẵn để xem lại

Nếu muốn nơi riêng giữ tài liệu được phép và ghi chú đằng sau quyết định mô hình, Telli.sh là một lựa chọn. Bắt đầu ghi chú.


← Quay lai blog