Ripple-65B Preview: Một endpoint $0.20, một bản hợp nhất vLLM gốc và ba con số ngữ cảnh

Các trọng số đã được đưa lên lúc 02:41 UTC ngày 4 tháng 11. Mười chín giờ sau, ai đó đã mở một pull request để đưa chúng vào nhánh chính của vLLM, và lúc 17:36 UTC ngày 5 tháng 11, nó đã được hợp nhất — 1.153 dòng được thêm trên 27 tệp. Đó là tốc độ nhanh ngay cả theo tiêu chuẩn của một bản phát hành mô hình được chú ý nhiều, và nó thay đổi một điều cụ thể: cho đến lần hợp nhất đó, Ripple-65B Preview — checkpoint dense 65B theo Apache 2.0 từ Ricursive Intelligence — chỉ có đúng một đường phục vụ được ghi nhận, một plugin do các tác giả phát hành bên ngoài engine. Câu hỏi dành cho bất kỳ ai đánh giá nó không còn là liệu nó có thể được phục vụ hay không. Mà là cách nào trong số các cách phục vụ chính thức hiện nay phù hợp với phần cứng của bạn, và mỗi cách âm thầm khiến bạn tốn kém những gì.

Hai sự thật nằm sau câu hỏi đó và chúng kéo theo hai hướng ngược nhau. Hỗ trợ gốc của vLLM khiến việc tự lưu trữ trở nên khả thi với những nhóm chưa từng chạy được script SGLang ngoài cây. Trong khi đó, các danh sách dịch vụ lưu trữ vẫn mâu thuẫn với thẻ mô hình về lượng ngữ cảnh bạn thực sự nhận được — một trang dịch vụ ghi nổi bật 128K trong thanh thông số kỹ thuật, trong khi phần thẻ mô hình trên cùng trang đó nói lên tới 1.048.576 token, và endpoint thương mại đầu tiên mang mô hình này phục vụ 16.384. Không sự thật nào giải quyết được việc một mô hình 65B quảng cáo ngữ cảnh một triệu token phải làm gì khi endpoint đứng trước nó nói 128K.

Điều gì thực sự còn thiếu trước khi hợp nhất

Manh mối nằm ngay trong phần mô tả của chính pull request, trong đó nêu rằng trước đó, "cách phục vụ duy nhất là plugin SGLang ngoài cây mã nguồn của các tác giả." Plugin đó được phát hành kèm model card dưới dạng thiết lập SGLang 0.5.19, nghĩa là bất kỳ ai muốn phục vụ Ripple-65B Preview đều phải hoặc dùng một phiên bản engine cụ thể với script bên ngoài, hoặc tự viết định nghĩa model của riêng mình dựa trên một checkpoint khai báo kiến trúc tùy chỉnh.

Điểm thứ hai chính là điểm âm thầm giết chết việc áp dụng. Kho BF16 mang thẻ custom_code, và tệp cấu hình xác định kiến trúc là RicursiveForCausalLM — một cái tên mà không engine nào từng nghe cách đây một tuần. Tải nó đồng nghĩa với --trust-remote-code, mà trong hầu hết môi trường production, đó là một cuộc trao đổi với người đánh giá bảo mật trước khi trở thành một quyết định kỹ thuật.

Việc hợp nhất loại bỏ bước đó thay vì tìm cách lách qua nó. PR bổ sung RicursiveConfig tích hợp sẵn, nên checkpoint tải được mà không cần --trust-remote-code, và nó đăng ký kiến trúc trong sổ đăng ký mô hình cùng với mọi họ mô hình hạng nhất khác. Một nỗ lực song song nhằm làm điều tương tự cho SGLang vẫn đang mở và chưa được hợp nhất, nên hiện tại vLLM là engine phổ biến duy nhất mà mô hình này là một công dân được hỗ trợ thay vì chỉ là một script.

Những phần của quá trình hợp nhất quan trọng hơn tệp mô hình

Việc triển khai mô hình 413 dòng là nửa kém hào nhoáng. Những bổ sung thú vị là những thứ khiến mô hình hành xử giống như thứ mà các con số benchmark của nó mô tả.

• Suy luận và gọi công cụ — bản hợp nhất bổ sung --reasoning-parser ripple và --tool-call-parser ripple, xử lý khối think tùy chọn và các lệnh gọi công cụ JSON kiểu Hermes, với đầu ra dạng streaming khớp với dạng không streaming. Nếu không có những thứ này, một mô hình agentic sẽ trả về văn bản mà bạn phải tự phân tích, và chính bước phân tích là nơi các agent đã triển khai thất bại.

• Một công thức đã được kiểm chứng — recipes/models/ricursiveAI/Ripple-65B-Preview.yaml, 97 dòng, mặc định dùng checkpoint NVFP4 trên một B300 duy nhất, với một biến thể BF16 và các bộ phân tích cú pháp được nối sẵn. Nó vượt qua chính validate-source.mjs của kho recipes. Đây là thứ gần nhất với một hướng dẫn "chạy như thế này" chính thức dành cho mô hình.

• Giải mã suy đoán thông qua checkpoint nháp — kho lưu trữ cung cấp một drafter 4,04B, và bản hợp nhất dạy vLLM đọc bố cục lớp NoPE của nó thông qua no_rope_layers. Trên GSM8K, PR báo cáo độ dài chấp nhận trung bình tăng từ 4,98 lên 7,34 token mỗi bước xác minh.

• 158 dòng kiểm thử parser, cùng với một trình dựng trace, đây là phần ít thấy nhất và đáng yên tâm nhất: hành vi của reasoning-parser được ghim bằng kiểm thử chứ không phải bằng một chú thích.

Vì sao độ dài chấp nhận là con số cần theo dõi, chứ không phải token mỗi giây

Con số hiệu suất của chính Ricursive là 250 token mỗi giây trên hai B200 ở kích thước lô 8, trước khi lượng tử hóa hoặc dùng kernel tùy chỉnh. Con số đó được đo bằng bản dựng SGLang của chính các tác giả, trên bản sửa đổi checkpoint mà họ đã thử nghiệm. Đó là một mức trần đẹp nhưng là đầu vào lập kế hoạch tồi, vì thứ quyết định một vòng lặp agent có cảm giác nhanh hay không là có bao nhiêu token sống sót qua xác minh trong mỗi lượt nháp.

Bộ soạn thảo hỗ trợ ở đó và chỉ ở đó. Nó đề xuất các khối 16 token với 32 ứng viên cho mỗi vị trí và đọc các trạng thái ẩn trung gian từ mô hình đích tại các lớp 1, 20, 39, 58 và 77 — một mô hình 4,04B mà toàn bộ nhiệm vụ là đoán xem mô hình 64,8B sẽ nói gì tiếp theo. Thẻ mô tả của chính nó cẩn trọng về các điều kiện: quá trình kiểm định chạy trên tám H100 dưới ripple-sglang với checkpoint RL-step-500, và thẻ nêu rõ rằng điều này "không thiết lập được tính tương thích hay hiệu năng cho các bản sửa đổi mô hình đích hoặc phiên bản runtime khác."

Hãy đọc câu đó hai lần trước khi bạn xây dựng ngân sách độ trễ dựa trên 7.34. Đây là phép đo cùng phiên bản, cùng môi trường chạy. Việc hợp nhất vLLM thay đổi môi trường chạy. Chưa ai công bố con số độ dài chấp nhận cho đường đã hợp nhất, và đó là thứ đầu tiên tôi sẽ đo trên lưu lượng của chính mình thay vì đi mượn.

Việc tải xuống khiến bạn tốn những gì và nó phù hợp với phần cứng nào

Repo hướng dẫn BF16 có dung lượng 129,6 GB trải trên 16 shard, và siêu dữ liệu safetensors tổng cộng 64.782.689.360 tham số — dạng dense, tất cả đều hoạt động trên mỗi token. Không có định tuyến chuyên gia nào để khai thác và không có cách nào đánh đổi tham số hoạt động để lấy chất lượng. Nếu bạn muốn mô hình độ chính xác đầy đủ, đó chính là con số bạn cần cấp phát, cộng thêm KV cache.

• Nhánh lượng tử hóa — repo NVFP4 lưu trữ 39,616,865,360 tham số, khoảng 61% số lượng của BF16, và công thức hợp nhất mặc định sử dụng nó trên một B300 duy nhất.

• Đường nháp — thêm 4,04B tham số và một đường KV thứ hai nếu bạn bật DFlash2; công thức để nó ở dạng tùy chọn bật chứ không mặc định.

• Các tuyên bố về máy trạm đơn — Ricursive nói mô hình vừa trên một NVIDIA DGX Spark, và một báo cáo cộng đồng cho thấy nó chạy trên ba card Radeon AI PRO R9700 dưới ROCm 7.2.1. Cả hai đều đáng tin đối với checkpoint đã lượng tử hóa và không cái nào kèm theo con số thông lượng mà tôi sẽ trích dẫn như một mức dịch vụ.

• Tính song song — bản hợp nhất tuyên bố rõ ràng về tensor parallel, pipeline parallel, torch.compile và CUDA graphs, và chính điều này khiến việc phục vụ đa GPU cho một mô hình dense 65B trở nên khả thi trong thực tế chứ không chỉ là kỳ vọng. Các mô hình dense chia tách gọn gàng, và 65B trên bốn card 80GB là một bố cục tensor-parallel-4 thoải mái trong BF16.

Cửa sổ ngữ cảnh vẫn là ba con số khác nhau

Đây là mục chưa được giải quyết, và nó vẫn nguyên vẹn sau khi hợp nhất vì đây là câu hỏi về cấu hình phục vụ chứ không phải câu hỏi về engine.

Thẻ mô hình quảng cáo "độ dài ngữ cảnh lên tới 1M", và cấu hình hỗ trợ các vị trí vượt xa mức đó — các giai đoạn huấn luyện ngữ cảnh dài đã dùng chuỗi 2 triệu token. Danh mục thương mại được công bố tuần này giật tít cửa sổ ngữ cảnh 128K và lặp lại 128K trong thanh bên thông số kỹ thuật, trong khi mục thẻ mô hình của cùng trang đó nói "độ dài ngữ cảnh lên tới 1.048.576 token". Khi ra mắt, endpoint được host đầu tiên mang mô hình này phục vụ 16.384.

Ba con số, một checkpoint. Cách lý giải khả dĩ nhất chẳng có gì đáng chú ý: con số 1M mô tả những gì kiến trúc và trọng số có thể làm được, còn những con số nhỏ hơn mô tả những gì một triển khai phục vụ cụ thể đã được cấu hình và kiểm chứng để làm. Đó là một khoảng cách bình thường. Đó cũng chính là khoảng cách quyết định liệu mô hình có dùng được cho công việc agent ở quy mô kho mã hay không, bởi cửa sổ 16K không thể chứa một diff lớn cùng đầu ra kiểm thử của nó, còn cửa sổ 128K có thể chứa khoảng một trường hợp như vậy.

Nếu bạn đang đánh giá Ripple-65B Preview cho lập trình agentic, hãy coi số ngữ cảnh là thuộc tính của endpoint, không phải của mô hình, và hãy kiểm thử endpoint. Recipe vLLM là nơi bạn có thể tự đặt giá trị của riêng mình.

Điều này đặt quyết định định tuyến ở đâu

Không điều nào trong số này thay đổi bản chất của lựa chọn, chỉ thay đổi số con đường khả thi để đạt tới nó. Giờ bạn có thể tự chạy mô hình trên vLLM bằng một công thức chính thức, hoặc gọi một endpoint được host với giá khoảng 0,20 USD cho mỗi triệu token đầu vào và 0,60 USD cho mỗi triệu token đầu ra, trong đó phần đầu vào được lưu đệm chỉ bị tính một phần nhỏ của mức đó. Đó là những sản phẩm khác nhau với cùng một bộ trọng số: một bên cho bạn quyền kiểm soát cửa sổ ngữ cảnh và hóa đơn, bên kia cho bạn một chiếc thẻ tín dụng và hàng đợi của người khác.

OrcaRouter không cung cấp Ripple-65B Preview — danh mục có hơn 200 mô hình và mô hình này không nằm trong số đó, điều này nên được nói thẳng thay vì ngụ ý ngược lại. Điều đó có nghĩa trên thực tế: nếu lý do bạn đang xem mô hình này là vì nó rẻ và mở, thì phép so sánh bạn thực sự cần là với thứ bạn có thể truy cập bằng cùng một khóa. DeepSeek V4 Proở mức $0.66 và $1.98 mỗi triệu token với ngữ cảnh 1M và đầu ra tối đa 384K; Kimi K3.1 Proở mức $2.00 và $10.00 với ngữ cảnh 1M và trần đầu ra 943K. Chạy hai mô hình đó qua một endpoint với chuyển đổi dự phòng tự động là phần của stack mà chúng tôi có thể đảm nhận thay bạn. Phần Ripple là của bạn để tự host hoặc mua.

Điều gì vẫn do nhà cung cấp tự báo cáo, và điều gì một người bên ngoài phát hiện ra

Mọi con số năng lực gắn với mô hình này đều đến từ Ricursive. Terminal-Bench 2.1 với 80.52 là điểm nhấn, và thẻ mô hình còn ghi 80.5 trên Terminus 2, 76.5 trên SWE-bench Verified, 61.42 trên SWE-bench Pro v1.0, 79.1 trên SWE-bench Pro v2.0 Hard, 44.3 trên DeepSWE 1.1, 39.4 trên SciCode và 71.67 trên MCP Atlas. Chưa có phần nào trong số đó được một phòng thí nghiệm độc lập tái lập, và Artificial Analysis không có mục nào cho mô hình — thư mục mô hình của nó trả về 404 với mọi slug Ripple tôi đã thử, đó là hình thức của "chưa được chấm điểm" khi nhìn từ bên ngoài.

Tín hiệu độc lập duy nhất hiện có lại chỉ theo hướng ngược lại và cần được nêu chính xác. Một bộ kiểm thử gồm 157 bài có tên Cold Iron đã cho mô hình 93 trên 157 điểm và xếp nó thứ 28/28, kém mục thấp nhất kế tiếp năm điểm. Phân tích chi tiết của chính tác giả thú vị hơn thứ hạng: trong 64 lần thất bại, 12 là do nhà cung cấp hết thời gian chờ và trả về không token nào, còn 49 là finish=length — mô hình đã dùng hết ngân sách đầu ra 4.096 token trước khi tạo ra được câu trả lời có thể chấm điểm. Chỉ có ba là lỗi nội dung. Nếu tính cả các lần hết thời gian chờ, điểm sẽ lên 105, vẫn khoảng thứ 26.

Đó là một kết quả liên quan đến cấu hình phục vụ nhiều không kém gì năng lực, và nó đúng là nhóm lỗi mà hỗ trợ engine gốc với một công thức đã được kiểm chứng được kỳ vọng sẽ giảm thiểu. Một mô hình dùng hết giới hạn đầu ra 4K trong các tác vụ lập trình là một mô hình đang bị chạy sai, không nhất thiết là một mô hình không thể lập trình.

Xem gì tiếp theo

Ba điều sẽ giúp chốt mô hình này nhanh hơn bất kỳ bài đưa tin nào nữa. Một điểm số độc lập — ngay khi Artificial Analysis hoặc LMArena tiếp nhận nó, bảng của nhà cung cấp sẽ trở nên có thể kiểm chứng thay vì chỉ để trích dẫn. Một bản hợp nhất ở phía SGLang, điều sẽ chấm dứt tình trạng chỉ có một engine. Và một checkpoint không có chữ "Preview" trong tên, vì Ricursive đã mô tả bản phát hành này là được cố ý hậu huấn luyện nhẹ, với sản phẩm nội bộ thực sự là một biến thể thiết kế chip.

Cho đến lúc đó, bản tóm tắt trung thực của tuần này thật hẹp và hữu ích: câu chuyện phục vụ đã cải thiện đáng kể trong 36 giờ, câu chuyện năng lực không thay đổi chút nào, và câu hỏi về cửa sổ ngữ cảnh đã chuyển từ thẻ mô hình sang tệp cấu hình của chính bạn.