Ripple-65B Preview: נקודת קצה ב-$0.20, מיזוג vLLM נייטיבי, ושלושה מספרי הקשר

המשקלים נחתו ב-02:41 UTC ב-4 בנובמבר. תשע-עשרה שעות לאחר מכן מישהו פתח בקשת משיכה כדי להכניס אותם לענף הראשי של vLLM, וב-17:36 UTC ב-5 בנובמבר היא מוזגה — 1,153 שורות נוספות ב-27 קבצים. זה מהיר אפילו לפי הסטנדרטים של שחרור מודל שמושך אליו תשומת לב רבה, וזה משנה משהו ספציפי: עד אותו מיזוג, Ripple-65B Preview — נקודת הבדיקה הצפופה (dense) בגודל 65B ברישיון Apache 2.0 של Ricursive Intelligence — היה לה בדיוק מסלול הגשה מתועד אחד, תוסף שהמחברים הוציאו מחוץ למנוע. השאלה לכל מי שמעריך אותו היא כבר לא אם אפשר להגיש אותו. היא איזו מהדרכים הרשמיות כעת להגיש אותו מתאימה לחומרה שלך, ומה כל אחת מהן גובה ממך בשקט.

שתי עובדות עומדות מאחורי השאלה הזו והן מושכות לכיוונים מנוגדים. תמיכה מקורית ב-vLLM הופכת אירוח עצמי לאפשרי עבור צוותים שמעולם לא הצליחו להפעיל את סקריפט SGLang שמחוץ לעץ. הרשומות המאוחסנות, לעומת זאת, עדיין חולקות על כרטיס המודל בשאלה כמה הקשר באמת מקבלים — עמוד שירות אחד מציג בכותרת 128K בסרגל המפרט שלו, בעוד שקטע כרטיס המודל באותו עמוד אומר עד 1,048,576 טוקנים, ונקודת הקצה המסחרית הראשונה שנשאה את המודל הגישה 16,384. אף אחת מהעובדות לא פותרת את השאלה מה אמור לעשות מודל 65B שמפרסם הקשר של מיליון טוקנים כאשר נקודת הקצה שמולו מציינת 128K.

מה בעצם היה חסר לפני המיזוג

הרמז נמצא בתיאור של ה-pull request עצמו, שבו נאמר שלפניו, "נתיב השירות היחיד היה הפלאגין out-of-tree של SGLang מטעם המחברים." הפלאגין הזה נשלח עם כרטיס המודל כהתקנת SGLang 0.5.19, כלומר כל מי שרצה לשרת את Ripple-65B Preview היה צריך או לאמץ גרסת מנוע ספציפית עם סקריפט חיצוני, או לכתוב הגדרת מודל משלו מול checkpoint שמצהיר על ארכיטקטורה מותאמת אישית.

הנקודה השנייה היא זו שהורגת בשקט את האימוץ. מאגר ה-BF16 נושא את התגית custom_code, וה-config מגדיר את הארכיטקטורה כ-RicursiveForCausalLM — שם שאף מנוע לא שמע עליו לפני שבוע. טעינתו חייבה --trust-remote-code, שבברוב סביבות הייצור היא שיחה עם סוקר אבטחה לפני שהיא החלטה טכנית.

המיזוג מסיר את השלב הזה במקום לעקוף אותו. ה-PR מוסיף RicursiveConfig מובנה, כך שה-checkpoint נטען ללא --trust-remote-code, והוא רושם את הארכיטקטורה ב-model registry לצד כל משפחה ראשית אחרת. מאמץ מקביל לעשות את אותו הדבר עבור SGLang עדיין פתוח ולא מוזג, כך ש-vLLM הוא כרגע המנוע המיינסטרימי היחיד שבו המודל הזה הוא אזרח נתמך ולא סקריפט.

החלקים של המיזוג החשובים יותר מקובץ המודל

מימוש מודל בן 413 שורות הוא החצי הלא־זוהר. התוספות המעניינות הן אלה שגורמות למודל להתנהג כמו הדבר שמספרי הבנצ׳מרק שלו מתארים.

• נימוק וקריאות לכלים — המיזוג מוסיף את ‎--reasoning-parser ripple ואת ‎--tool-call-parser ripple, שמטפלים בבלוק think אופציונלי ובקריאות כלים בסגנון Hermes בפורמט JSON, עם פלט בזרימה שתואם לצורה שאינה בזרימה. בלעדיהם, מודל סוכני מחזיר טקסט שאתם צריכים לפרסר בעצמכם, והפרסור הוא המקום שבו סוכנים שנפרסו נכשלים.

• מתכון מאומת — recipes/models/ricursiveAI/Ripple-65B-Preview.yaml,‏ 97 שורות, כברירת מחדל משתמש בנקודת הבדיקה NVFP4 על B300 בודד, עם גרסת BF16 והמנתחים מחוברים. הוא עובר את validate-source.mjs של מאגר המתכונים עצמו. זה הדבר הקרוב ביותר ל"הרצה כך" רשמי שקיים עבור המודל.

• פענוח ספקולטיבי באמצעות נקודת הבדיקה של הטיוטה — המאגר כולל דראפטר בגודל 4.04B, והמיזוג מלמד את vLLM לקרוא את פריסת שכבות ה-NoPE שלו דרך no_rope_layers. ב-GSM8K ה-PR מדווח על אורך קבלה ממוצע שעולה מ-4.98 ל-7.34 טוקנים לכל שלב אימות.

• 158 שורות של בדיקות מנתח, בתוספת בונה עקבות, שזה החלק הכי פחות גלוי והכי מרגיע: התנהגות מנתח ההיסק מוצמדת בבדיקות ולא בהערה.

מדוע אורך הקבלה הוא הנתון שכדאי לשים לב אליו, ולא טוקנים לשנייה

נתון היעילות של Ricursive עצמו הוא 250 טוקנים לשנייה על שני B200s בגודל אצווה 8, לפני קוונטיזציה או קרנלים מותאמים אישית. המספר הזה נמדד עם גרסת ה-SGLang של המחברים עצמם, על מהדורת ה-checkpoint שהם בדקו. זה תקרה נאה ותשומה גרועה לתכנון, כי הדבר שקובע אם לולאת סוכן מרגישה מהירה הוא כמה טוקנים שורדים אימות בכל סבב טיוטה.

המנסח עוזר שם ורק שם. הוא מציע בלוקים של 16 טוקנים עם 32 מועמדים לכל עמדה וקורא מצבים חבויים ביניים מהמודל היעד בשכבות 1, 20, 39, 58 ו-77 — מודל של 4.04B שכל תפקידו לנחש מה מודל ה-64.8B יאמר לאחר מכן. הכרטיס של עצמו מקפיד לגבי התנאים: האימות רץ על שמונה H100 תחת ripple-sglang מול נקודת הביקורת RL-step-500, והכרטיס מציין בפשטות שזה "אינו מבסס תאימות או ביצועים עבור גרסאות יעד או גרסאות זמן ריצה אחרות."

קרא את המשפט הזה פעמיים לפני שאתה בונה תקציב השהיה על 7.34. זו מדידה של אותה גרסה ואותו זמן ריצה. המיזוג של vLLM משנה את זמן הריצה. אף אחד עוד לא פרסם נתון אורך קבלה עבור המסלול הממוזג, וזה הדבר הראשון שהייתי מודד על התעבורה שלי במקום להסתמך על נתון שאול.

מה ההורדה עולה לך, ועל איזה חומרה היא מתאימה

מאגר ה-instruct מסוג BF16 הוא 129.6 GB ב-16 שברים (shards), וסך המטא-דאטה של safetensors עומד על 64,782,689,360 פרמטרים — צפוף, כולם פעילים בכל טוקן. אין ניתוב מומחים (expert routing) לנצל, ואין דרך להחליף פרמטרים פעילים תמורת איכות. אם רוצים את המודל ברמת דיוק מלאה, זה המספר שעבורו מקצים משאבים, בתוספת מטמון KV.

• מסלול מכומת — מאגר NVFP4 מאחסן 39,616,865,360 פרמטרים, כ-61% ממספר ה-BF16, ומתכון המיזוג משתמש בו כברירת מחדל על B300 בודד.

• נתיב ה-Draft — הוספת 4.04B פרמטרים ונתיב KV שני אם תפעילו את DFlash2; המתכון משאיר אותו כאופציה ולא כברירת מחדל.

• טענות לתחנת עבודה בודדת — Ricursive אומרת שהמודל נכנס ל-NVIDIA DGX Spark, ודיווח קהילתי מציג אותו פועל על שלושה כרטיסי Radeon AI PRO R9700 תחת ROCm 7.2.1. שניהם אמינים עבור הצ'קפוינט המכוונט, ואף אחד מהם אינו כולל נתון תפוקה שהייתי מצטט כרמת שירות.

• מקביליות — המיזוג טוען במפורש ל־tensor parallel, pipeline parallel, torch.compile ו־CUDA graphs, וזה מה שהופך הגשת מודל dense בגודל 65B על פני כמה GPUs למעשית ולא לשאיפה בלבד. מודלים dense מתפצלים בצורה נקייה, ו־65B על פני ארבעה כרטיסי 80GB הוא פריסת tensor-parallel-4 נוחה ב־BF16.

חלון ההקשר הוא עדיין שלושה מספרים שונים

זהו הפריט הלא פתור, והוא שרד את המיזוג ללא שינוי משום שמדובר בשאלת תצורת הגשה ולא בשאלת מנוע.

כרטיס הדגם מפרסם "אורך הקשר של עד 1M", והתצורה תומכת במיקומים הרבה מעבר לכך — שלבי אימון להקשר ארוך השתמשו ברצפים של 2M טוקנים. המודעה המסחרית שפורסמה השבוע מציגה בכותרת חלון הקשר של 128K וחוזרת על 128K בסרגל המפרטים שלה, בעוד שקטע כרטיס הדגם באותו עמוד אומר "אורך הקשר של עד 1,048,576 טוקנים." בהשקה, נקודת הקצה המתארחת הראשונה שנשאה את הדגם סיפקה 16,384.

שלושה מספרים, צ'קפוינט אחד. ההסבר הסביר ביותר אינו מפתיע: נתון ה-1M מתאר מה שהארכיטקטורה והמשקלים מסוגלים לעשות, והנתונים הקטנים יותר מתארים עבור מה פריסת שירות נתונה הוגדרה ואומתה. זהו פער רגיל. זה גם הפער שקובע אם המודל שמיש לעבודת סוכן בקנה מידה של מאגר קוד, מפני שחלון של 16K אינו יכול להכיל דיף גדול יחד עם פלט הבדיקות שלו, וחלון של 128K יכול להכיל בערך אחד.

אם אתה מעריך את Ripple-65B Preview לקידוד סוכני, התייחס למספר ההקשר כאל תכונה של נקודת הקצה, לא של המודל, ובדוק את נקודת הקצה. מתכון ה-vLLM הוא המקום שבו תוכל להגדיר משלך.

מה זה אומר לגבי החלטת הניתוב

שום דבר מזה לא משנה את צורת הבחירה, רק את מספר הנתיבים הישימים אליה. כעת תוכלו להריץ את המודל בעצמכם על vLLM עם מתכון רשמי, או לפנות לנקודת קצה מתארחת בכ-$0.20 למיליון טוקני קלט ו-$0.60 למיליון טוקני פלט, כאשר קלט השמור במטמון מחויב בשבריר מזה. אלה מוצרים שונים עם אותם משקלים: האחד נותן לכם שליטה על חלון ההקשר ועל החשבון, והאחר נותן לכם כרטיס אשראי והתור של מישהו אחר.

ב-OrcaRouter אין את Ripple-65B Preview — הקטלוג כולל יותר מ-200 מודלים וזה לא אחד מהם, מה שראוי לומר בפשטות ולא לרמוז אחרת. מה זה אומר בפועל: אם הסיבה שאתה בוחן את המודל הזה היא שהוא זול ופתוח, ההשוואה שאתה באמת צריך היא מול משהו שאתה יכול להגיע אליו באותו מפתח. DeepSeek V4 Proעומד על 0.66$ ו-1.98$ למיליון עם חלון הקשר של 1M ופלט מקסימלי של 384K; Kimi K3.1 Proעומד על 2.00$ ו-10.00$ עם חלון הקשר של 1M ותקרת פלט של 943K. הרצת השניים האלה דרך נקודת קצה אחת עם מעבר אוטומטי לגיבוי היא החלק במערך שאנחנו יכולים להוריד ממך. חלק ה-Ripple הוא שלך לאירוח או לרכישה.

מה שעדיין מדווח על ידי הספק, ומה שגילה גורם חיצוני

כל מספר יכולת המיוחס למודל הזה מגיע מ-Ricursive. Terminal-Bench 2.1 עם 80.52 הוא נתון הכותרת, והכרטיס כולל גם 80.5 ב-Terminus 2, 76.5 ב-SWE-bench Verified, 61.42 ב-SWE-bench Pro v1.0, 79.1 ב-SWE-bench Pro v2.0 Hard, 44.3 ב-DeepSWE 1.1, 39.4 ב-SciCode ו-71.67 ב-MCP Atlas. אף אחד מהם לא שוחזר על ידי מעבדה עצמאית, ול-Artificial Analysis אין רשומה עבור המודל — ספריית המודלים שלה מחזירה 404 עבור כל מזהה Ripple שניסיתי, וזה איך ש"לא מדורג" נראה מבחוץ.

האות העצמאי היחיד שקיים מצביע דווקא לכיוון ההפוך וראוי להיאמר במדויק. מערך בדיקות בן 157 בדיקות בשם Cold Iron העניק למודל ציון 93 מתוך 157 והציב אותו במקום ה-28 מתוך 28, חמש נקודות אחרי הרשומה הנמוכה הבאה. הפירוט של המחבר עצמו מעניין יותר מהדירוג: מתוך 64 כשלים, 12 היו פסקי זמן של הספק שהחזירו אפס טוקנים ו-49 היו finish=length — המודל מיצה את תקציב הפלט של 4,096 טוקנים לפני שהפיק תשובה שאפשר לתת לה ציון. רק שלושה היו החמצות תוכן. זיכוי פסקי הזמן היה מעלה אותו ל-105, עדיין בערך במקום ה-26.

זו תוצאה הנוגעת לתצורת ההגשה לא פחות מאשר ליכולת, והיא בדיוק סוג הכשל שתמיכת מנוע מקורית עם מתכון מאומת אמורה לצמצם. מודל שממצה תקרת פלט של 4K במשימות קידוד הוא מודל שמופעל באופן שגוי, לא בהכרח מודל שאינו יודע לכתוב קוד.

מה לצפות בהמשך

שלושה דברים יכריעו את הסוגיה הזו לגבי המודל מהר יותר מכל סיקור נוסף. ציון בלתי־תלוי — ברגע ש-Artificial Analysis או LMArena יאמצו אותו, טבלת הספקים תהפוך לניתנת לבדיקה ולא רק לציטוט. מיזוג בצד של SGLang, שיסיים את מצב המנוע הבודד. וצ'קפוינט בלי "Preview" בשמו, מאחר ש-Ricursive תיארה את המהדורה הזו ככזו שעברה אימון־המשך קל בכוונה, כשהמוצר הפנימי האמיתי הוא וריאנט לתכנון שבבים.

עד אז, הסיכום הכנה של השבוע הזה הוא צר ושימושי: סיפור ההגשה השתפר באופן מהותי בתוך 36 שעות, סיפור היכולות לא השתנה כלל, ושאלת חלון ההקשר עברה מכרטיס הדגם לקובץ התצורה שלך.