Ember-1 cắt giảm 40% khả năng suy luận của Kimi K3 — và phần chữ in nhỏ mới là câu chuyện.

Con số sẽ được trích dẫn là 40%. Fireworks Research công bố Ember-1 vào ngày 23 tháng 9 năm 2026, mô tả nó như một dẫn xuất chuyên biệt từ Kimi K3 của Moonshot AI, giữ được độ chính xác của K3 trong khi chỉ dùng ít hơn khoảng 40% token để đạt được điều đó. Đó là một tuyên bố có thật và đặc biệt cụ thể một cách bất thường, và nó đi kèm ba thứ: một bảng benchmark đầy đủ với các cột giảm token, hai bài kiểm tra A/B của khách hàng từ lưu lượng lập trình trong sản xuất, và một trạng thái phát hành không phải là khả dụng chung. Ember-1 được phát hành dưới dạng research preview, trên nền tảng serverless của chính nhà cung cấp, với cửa sổ truy cập hai tuần và quyết định về tính lâu dài phụ thuộc vào nhu cầu. Hiểu được phần nào trong số này là sản phẩm đã tung ra và phần nào là một kết quả nghiên cứu được lập luận thuyết phục chính là toàn bộ bài tập.

Cũng có một vụ trùng tên đáng để làm rõ trước tiên. Một dự án nghiên cứu mở riêng biệt tên là Ember (v0.1.5, từ Slow Lit Labs) đã dành năm 2026 để công bố các đánh giá về tính mạch lạc trong tầm xa, và nó không liên quan gì đến mô hình này. Mọi thứ bạn đọc về việc Ember không đánh bại được Qwen3-8B dưới cùng thiết lập suy luận là nói về dự án đó. Ember-1, đối tượng ở đây, là một biến thể phái sinh từ Kimi K3 của Fireworks Research.

Ember-1 thực sự là gì

Ember-1 không phải là một kiến trúc mới và cũng không phải là một mô hình nền tảng mới. Nó là Kimi K3, được huấn luyện lại để suy luận súc tích hơn. Fireworks Research đã chạy hơn 50 thí nghiệm huấn luyện và hơn 200 đánh giá trên ngăn xếp huấn luyện serverless của chính mình, trải rộng trên toán học, lập trình, tuân thủ chỉ dẫn, hội thoại, tìm kiếm, sử dụng công cụ và kỹ thuật phần mềm, với mục tiêu rõ ràng là loại bỏ những suy luận không làm thay đổi câu trả lời. Phòng thí nghiệm này cho biết độ dài suy luận có thể được cắt giảm 35–50% mà không mất độ chính xác trên bảy bộ đánh giá và hai tập lưu lượng sản xuất của khách hàng. Mọi con số trong số đó đều do nhà cung cấp báo cáo và chưa được tái tạo độc lập; tính đến thời điểm viết, chưa có bên thứ ba nào công bố một lần chạy Ember-1.

Cách đặt khung vấn đề quan trọng vì phương án thay thế hiển nhiên đã tồn tại từ trước. Kimi K3 đi kèm các cài đặt mức nỗ lực suy luận, và cách rẻ để tiêu ít token hơn là hạ mức nỗ lực xuống. Fireworks Research cho biết họ đã thử cách đó và cài đặt thấp đã hy sinh quá nhiều chất lượng — một kết quả quen thuộc với bất kỳ ai từng tinh chỉnh các mức nỗ lực trên một mô hình suy luận. Tuyên bố của Ember-1 là nút chỉnh mức nỗ lực còn thô, còn huấn luyện lại thì ổn.

Vì sao các token suy luận lại đáng để bỏ ra ngần này công sức

Hóa đơn của một mô hình suy luận không bị chi phối bởi câu trả lời của nó. Fireworks Research lưu ý rằng K3 có thể dành hơn 90% số token được tạo ra cho suy luận nội bộ trước khi nó viết ra bất cứ điều gì người dùng nhìn thấy. Trong một yêu cầu đơn lẻ, điều đó chỉ đơn thuần là tốn kém. Trong một vòng lặp tác nhân nhiều lượt, nó tích lũy, bởi vì mỗi lượt phát lại cuộc hội thoại trước đó, nên các dấu vết suy luận từ những lượt trước bị đọc lại và tính phí lại trong mỗi lần gọi tiếp theo. Fireworks Research mô tả ngữ cảnh tăng gần như theo bậc hai với số lượt. Đó mới là mục tiêu thực sự của bản phát hành này, và đó là lý do chỉ số nổi bật là số token ít hơn khoảng 40% thay vì một bước nhảy về chất lượng.

Cơ chế này cũng giải thích rủi ro. Việc nén loại bỏ phần suy luận lãng phí là không tốn kém; việc nén loại bỏ một bước mà mô hình cần thì không. Kiểu thất bại được báo cáo rộng rãi của việc giảm suy luận quá mức là một mô hình bỏ qua bước kiểm tra trung gian và nhảy thẳng tới kết luận, điều mà trong một agent xuất hiện muộn hơn nhiều dưới dạng một lệnh gọi công cụ sai thay vì một câu sai. Việc Fireworks Research liên tục nhấn mạnh vào chất lượng tương đương được đọc như một câu trả lời cho mối lo đó, và các con số A/B là thứ gần nhất với bằng chứng cho điều đó — với lưu ý thường lệ rằng các bộ kiểm thử, tiêu chí đạt và kích thước mẫu đều do bên đưa ra tuyên bố lựa chọn.

Bảng đánh giá chuẩn, kèm theo nguồn gốc xuất xứ của nó.

Đây là các số liệu của Fireworks Research, chưa được tái lập. Cột bên phải là phần đáng đọc kỹ: nó ghép mỗi điểm số với số token và số đô-la đã tiêu tốn so với K3 Max.

• Terminal Bench 2.1 (n=89) — Ember-1 82,0% so với K3 Max 80,9%, K3 High 77,6%, K3 Low 76,4%; ít hơn 51,9% token, ít hơn 23,10 USD mỗi tác vụ.

• SWE-bench Verified (n=500) — Ember-1 92,2% so với K3 Max 93,2%; giảm 15,5% token, tiết kiệm 68,10 USD mỗi tác vụ.

• SWE-Interact (n=75) — Ember-1 20,0% so với K3 Max 21,3%, K3 High 13,3%, K3 Low 6,7%; ít hơn 32,5% token.

• DeepSWE 1.1 (n=113) — Ember-1 75,2% so với K3 Max 66,4%; ít hơn 23,7% token, ít hơn $126,90 mỗi tác vụ.

• τ-2 Bench Airline (n=50) — Ember-1 66% so với K3 Max 64%, K3 High và Low đều 64%; ít hơn 5.9% token, rẻ hơn $0.30 mỗi tác vụ.

Có hai điều nổi bật. Thứ nhất, Ember-1 thắng áp đảo trên Terminal Bench 2.1 và DeepSWE 1.1 nhưng lại thua sát nút trên SWE-bench Verified và SWE-Interact — một kiểu mẫu nhất quán với việc mô hình không hẳn đã mất năng lực mà đúng hơn là đã thay đổi những tác vụ mà nó dành thời gian suy xét. Thứ hai, mức tiết kiệm token cực kỳ không đồng đều: 51,9% trên Terminal Bench so với 5,9% trên τ-2 Airline. Dù Ember-1 đã học được gì đi nữa, đó không phải là một mức cắt giảm 40% đồng đều trong suy nghĩ. Con số "khoảng 40%" trong tiêu đề là mức trung bình trên một dải trải từ khoảng 6% đến khoảng 52%, và một nhóm mà khối lượng công việc giống với τ-2 Airline thì đừng mong sẽ cảm nhận được nó.

Các thử nghiệm A/B trên thực tế là bằng chứng thuyết phục hơn, chính vì chúng không được xây dựng để làm điểm chuẩn. Trong một khối lượng công việc lập trình của một khách hàng, Ember-1 đạt 0,753 so với 0,751 của K3, mất 21,4 bước so với 23,8, và tạo ra 29,9K token đầu ra so với 49,3K — giảm 71,3% token suy luận và 39% tổng token, với chất lượng gần tương đương. Một khách hàng thứ hai chứng kiến ít hơn khoảng 35% token mỗi tác vụ ở chất lượng tương đương, và Fireworks Research cho biết đã chạy thử việc chuyển đổi trên lưu lượng lập trình và cộng tác nội bộ của chính mình trước tiên, với kết quả được báo cáo là không ai nhận ra. Hãy coi tất cả là do nhà cung cấp báo cáo, nhưng hãy coi đó là dạng mạnh nhất của báo cáo từ nhà cung cấp: dữ liệu ưu tiên A/B và hoàn thành tác vụ khó gian lận hơn so với bảng xếp hạng.

Có thêm một đánh giá nữa, trên Bedside Bench của Doximity — 500 ca lâm sàng đã được bác sĩ xác thực thuộc mười hạng mục — trong đó Fireworks Research tuyên bố Ember-1 đã thiết lập một đường biên Pareto mới về chi phí trên mỗi tác vụ, so sánh nó với các mô hình mở và đóng bao gồm GPT-5.6 Sol, GPT-6 Astra và Claude Opus 5. Đó là một tuyên bố của nhà cung cấp về vị trí Pareto, tức là một tuyên bố về sự đánh đổi hai chiều chứ không phải một điểm số duy nhất, và nó chỉ có giá trị ngang với các giả định chi phí đằng sau nó. Những giả định đó đến từ bảng giá API công khai của Kimi K3. Điều đó đưa chúng ta đến phần của câu chuyện mà người đọc thực sự có thể kiểm chứng ngay hôm nay.

Mô hình cơ sở là phần mà bạn đã có thể định tuyến

Toàn bộ lập luận về chi phí của Ember-1 đều được đo lường dựa trên mức giá công bố của Kimi K3. Kimi K3 đã hoạt động trên OrcaRouter ở mức $3.00 cho mỗi triệu token đầu vào, $0.30 cho mỗi triệu token đầu vào được lưu trong bộ nhớ đệm và $15.00 cho mỗi triệu token đầu ra, với cửa sổ ngữ cảnh 1,048,576 token. Đó cũng chính là bảng giá mà phần so sánh của Fireworks Research sử dụng, và điều đáng biết là khoản tiết kiệm trong các cột giảm token đó được tính dựa trên những con số bạn có thể tự mình kiểm chứng, chứ không phải dựa trên mô hình chi phí nội bộ của nhà cung cấp.

Bản thân Ember-1 không có trên OrcaRouter. Nó chỉ khả dụng thông qua nền tảng serverless của chính nhà cung cấp, dưới dạng bản xem trước nghiên cứu, và Fireworks Research chưa công bố giá cho nó — vì vậy những con số đô-la trong bảng benchmark được suy ra từ mức giá K3 và số lượng token, chứ không phải từ một bảng giá Ember-1 nào thực sự tồn tại. Nếu điều bạn quan tâm là phần số học, thì trình tự trung thực là: định giá khối lượng công việc theo tuyến K3 hiện tại, lấy các tỷ lệ phần trăm giảm token làm giới hạn trên của những gì một sự chuyển đổi có thể mang lại, và chờ một mức giá được công bố trước khi mô hình hóa khoản tiết kiệm thành tiền.

Điểm mà OrcaRouter thực sự hữu ích ở đây là ở chỗ phòng ngừa rủi ro. Một bản xem trước nghiên cứu với cửa sổ truy cập hai tuần đúng là kiểu mô hình mà bạn muốn thử mà không đặt cược lộ trình sản xuất vào nó, và cách để làm điều đó mà không cần thêm một hợp đồng thứ hai là đặt nó phía sau cùng một endpoint như mọi thứ khác mà bạn gọi. OrcaRouter phục vụ hơn 200 mô hình phía sau một API duy nhất với khả năng chuyển đổi dự phòng tự động, nên một mô hình xem trước mà hóa ra lại không khả dụng vào tháng sau thì chỉ là một thay đổi định tuyến chứ không phải một cuộc di trú. Không có gì ở Ember-1 đòi hỏi điều đó — nhưng cũng chẳng có gì ở cửa sổ hai tuần phản đối điều đó.

Làm gì với bản phát hành này

Nếu bạn đã chạy Kimi K3 trong một vòng lặp agent, những con số của Ember-1 mô tả hóa đơn của bạn. Vấn đề replay nhiều lượt là có thật, nó là chi phí chi phối trong các lượt chạy agent dài, và một mô hình tự rút ngắn dấu vết của chính nó mà không thay đổi câu trả lời thì đáng để bỏ thời gian đánh giá. Phép thử đúng không phải là bảng benchmark; mà là lưu lượng của chính bạn, chạy ở chế độ shadow — gửi một phần yêu cầu thật đến cả hai mô hình, so sánh đầu ra, giữ nguyên kết quả trực tiếp trong một hoặc hai tuần trước khi thay đổi bất cứ điều gì. Đó cũng là lời khuyên mà chính độc giả phê bình của bản phát hành đưa ra, và nó hợp lý.

Nếu bạn chạy một khối lượng công việc có độ suy xét thấp, hoặc một khối lượng bị chi phối bởi các lệnh gọi ngắn một lượt, thì khoản tiết kiệm phần lớn sẽ biến mất và dòng τ-2 Airline chính là kỳ vọng thực tế của bạn. Và nếu bạn cần một cam kết chuẩn production — một mức giá, một mức dịch vụ, một bảo đảm rằng endpoint sẽ tồn tại trong sáu tháng — thì Ember-1 chưa đưa ra được cam kết nào như vậy. Đây là bản xem trước nghiên cứu mà Fireworks Research nói rõ rằng sự tồn tại lâu dài của nó gắn với nhu cầu. Câu hỏi đáng quan tâm trong tháng tới là liệu cửa sổ hai tuần có trở thành một tùy chọn phục vụ thường trực hay không, và liệu một bên thứ ba có tái lập được bất kỳ con số nào hay không. Cho đến khi một trong những điều đó xảy ra, đây là một kết quả mạnh để đọc và là một kết quả yếu để xây dựng ngân sách dựa trên đó.

Không điều nào trong số đó nên bị hiểu là hạ thấp giá trị của công trình này. Loại bỏ khả năng suy luận mà không làm mất độ chính xác là một bài toán khó hơn việc bổ sung nó, và thực hiện điều đó dựa trên mô hình tiên tiến của người khác thay vì tự huấn luyện mô hình của riêng mình chính là hình thái mà rất nhiều công trình về năng lực vào năm 2026 đã mang. Ember-1 là bản phát hành đầu tiên trong chuỗi mà Fireworks Research nói sẽ là một loạt liên tục, và khuôn mẫu — lấy một mô hình vốn đã tốt, huấn luyện lại một trục hành vi của nó, bán phần chênh lệch dưới dạng token — là một khuôn mẫu đáng theo dõi bất kể bản xem trước cụ thể này có được đón nhận ra sao.