OpenAI Batch או Anthropic Batches: אותה הנחה, כשל שונה לגמרי

לעיבוד אסינכרוני גדול, הבחירה בין OpenAI Batch API לבין Anthropic Message Batches מתחילה באופן שבו תאספו הצלחות ותטפלו בכשלים. מדריך Batch של OpenAI מציג הנחה של 50% וחלון עיבוד של 24 שעות, ומתאר קובץ פלט להצלחות וקובץ שגיאות נפרד. תיעוד Message Batches של Anthropic מציג הנחה של 50% ופקיעת מנה אחרי 24 שעות, אך מסווג את תוצאתה של כל בקשה בתוך קובץ תוצאות אחד.

אם צינור העבודה כבר מייצר קובצי JSONL וזקוק לאימות שלהם לפני תחילת הריצה, המבנה של OpenAI מתאים לו. אם רוצים להגיש בקשות Messages עם הגדרות מודל שונות באותה מנה ולקבל מצב מפורש לכל בקשה, המבנה של Anthropic נוח יותר. בשני השירותים צריך לשמור את הבקשות המקוריות לפי custom_id: סדר התוצאות אינו בסיס בטוח להתאמה לקלט, ושליחת מנה שלמה מחדש עלולה לעבד שוב תשובות שכבר התקבלו.

כמה בקשות נכנסות למנה, ומה מותר לערבב?

לכל שירות יש תקרת בקשות ותקרת גודל; המגבלה שפוגשים ראשונה קובעת את החלוקה. בקשות עם קלט ארוך יכולות למלא את מכסת הבתים הרבה לפני שמגיעים למספר הבקשות המרבי. אלה ההבדלים שיש לתרגם לחלוקת העבודה:

• OpenAI: עד 50 אלף בקשות ועד 200MB בקובץ קלט JSONL. מעלים את הקובץ תחילה, ואז יוצרים אצווה שמפנה אליו. גם בקשות embeddings כפופות לתקרה של 50 אלף קלטי embedding בכל האצווה.
• Anthropic: עד 100 אלף בקשות Messages או 256MB למנה, לפי המגבלה שמגיעים אליה קודם. רשימת הבקשות נשלחת בעת יצירת המנה; כל בקשה כוללת custom_id ואובייקט params משלה.
• מודלים ונקודות קצה: ב־Anthropic המודל מוגדר בתוך params של כל בקשה, ולכן אפשר לשלב מודלים נתמכים במנה. ב־OpenAI נקודת הקצה נקבעת לכל האצווה, בעוד ששדה המודל נמצא בגוף הבקשה. התיעוד אינו קובע שקובץ נפרד לכל מודל הוא תנאי להגשה; חלוקה לפי מודל עדיין יכולה להקל על תכנון תור הטוקנים ועל חישוב העלות.

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

איפה מתגלה בקשה פגומה?

OpenAI מעבירה אצווה דרך מצב validating לפני in_progress. אם אימות קובץ הקלט נכשל, מצב האצווה משתנה ל־failed; פרטי השגיאה עשויים לכלול גם מספר שורה. זה מועיל במיוחד כשמערכת מייצרת JSONL אוטומטית: אפשר לזהות בעיית קובץ לפני שהאצווה מתחילה לרוץ. מעבר מוצלח של השלב הזה אינו מבטיח שכל בקשה תחזיר תשובה; שגיאות במהלך העיבוד נרשמות בקובץ השגיאות.

ב־Anthropic, תוצאה מסוג errored עשויה לשאת invalid_request_error עבור בקשה מסוימת, בלי שכשלונה יעצור את שאר המנה. המערכת גם דוחה פרמטרים שאינם מתאימים למסלול האצווה, ובהם stream ו־max_tokens שערכו אפס. בדיקה של בקשה מייצגת דרך Messages API יכולה לחשוף בעיית מבנה לפני הגשה גדולה, אך היא אינה בודקת שדות שמשתנים בין הרשומות. לכל בקשה באותה מנה צריך גם custom_id ייחודי; השירות מגביל את המזהה לאותיות ולספרות, למקף ולקו תחתון.

מסלול retry לפי custom_id

ב־OpenAI יש לקרוא גם את קובץ הפלט וגם את קובץ השגיאות. ב־Anthropic יש לקרוא את קובץ התוצאות ולבחון לכל custom_id את הסוג succeeded, errored, canceled או expired. בשני המקרים מחברים את התוצאה לרשומת המקור באמצעות המזהה, ולא באמצעות מספר השורה: סדר הפלט עשוי להיות שונה מסדר ההגשה.

1. לפני ההגשה שומרים לכל custom_id את תוכן הבקשה, המודל ומזהה המנה. כך אפשר לשחזר בדיוק מה נשלח גם אם התוצאה מגיעה באיחור.
2. לאחר סיום המנה קוראים את כל התוצאות ושומרים תשובות מוצלחות לפני יצירת מנה חוזרת. מזהים כאלה מסומנים כ־done ומוצאים מרשימת השליחה.
3. בקשה שפג תוקפה, בוטלה לפני עיבוד או נכשלה בשגיאת שרת נכנסת לרשימת retry. בקשה עם invalid_request_error נכנסת לרשימת fix; משנים את הקלט לפני ששולחים אותה שוב.
4. משווים בין כל המזהים שהוגשו לבין המזהים שנקלטו. אם מזהה חסר, בודקים את מצב המנה ואת קובצי התוצאות והשגיאות לפני החלטה על שליחה חוזרת. רק מזהים שנותרו ב־retry יוצרים את המנה הבאה.

פקיעת חלון העיבוד מחדדת את ההבדל בין מצב המנה לבין מצב הבקשות. ב־OpenAI תשובות שכבר הושלמו נשארות בקובץ הפלט, בקשות שלא בוצעו מופיעות בקובץ השגיאות, והחיוב חל על טוקנים שנצרכו בבקשות שהושלמו. ב־Anthropic בקשות שסומנו errored, canceled או expired אינן מחויבות. לכן החלטת retry צריכה להתבסס על תוצאת כל מזהה, גם כשהמנה כולה הסתיימה בפקיעה או בביטול.

חישוב לדוגמה: 20 אלף בקשות

נניח לצורך חישוב בלבד 20 אלף בקשות, שבכל אחת מהן 600 טוקני קלט ו־250 טוקני פלט. בסך הכול אלה 12 מיליון טוקני קלט ו־5 מיליון טוקני פלט. תעריפי Batch של OpenAI מציגים ל־gpt-6-luna בקלט קצר 0.05 דולר למיליון טוקני קלט ו־0.25 דולר למיליון טוקני פלט. תעריפי Batch של Anthropic מציגים אותם סכומים ל־Claude Haiku 5.5 כאשר הקלט של הבקשה אינו עובר 100 אלף טוקנים.

בהנחות האלה, אם כל הבקשות הושלמו והיקף הטוקנים בפועל תואם לדוגמה, החישוב לכל אחד משני המודלים הוא 12 × 0.05 ועוד 5 × 0.25: בסך הכול 1.85 דולר. השוויון כאן נובע מבחירת שני תעריפים זהים בדוגמה, ולא מעצם ההנחה הזהה. מודל אחר, פלט באורך אחר, שימוש במטמון או בקשת Haiku שחוצה את מדרגת הקלט ישנו את החשבון.

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

מתי צריך לשמור את הפלט אצלכם?

Anthropic מאפשרת להוריד תוצאות במשך 29 יום מרגע יצירת המנה. OpenAI מוחקת כברירת מחדל את קובץ הפלט 30 יום לאחר השלמת האצווה. ב־OpenAI אפשר גם להגדיר תוקף מותאם לקובצי הפלט והשגיאות; הטווח המותר הוא משעה ועד 30 יום, והוא נספר מרגע יצירת הקובץ. אלה שעונים שונים, ולכן שמירת התוצאות אצל הספק אינה תחליף לשמירת הפלט והמיפוי ל־custom_id במערכת שלכם.

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

קראו גם:

• OpenAI API או Anthropic API: מטמון חוסך עד 80% — ולעיתים גם מאט
• OpenAI API או Gemini API: החשבון משתנה לפי אורך הקלט, לא רק המודל
• Sentry או Datadog: אותה שגיאה יכולה לדרוש שני כלים, לא מנצח אחד