תרגמו קבצי PDF עם BabelDOC על base URL מותאם אישית של OpenAI.

Updated 2026-07-30

המתרגם של BabelDOC תואם OpenAI מעצם התכנון: שלושה דגלים (--openai, --openai-base-url, --openai-api-key) בתוספת --openai-model בוחרים את ה-endpoint ואת המודל. הפנו את ה-base URL אל https://api.apisrouter.com/v1 ותרגמו מסמכים עם Claude, DeepSeek, GLM, או Gemini דרך מפתח אחד.

תשובה מהירה: שלושה דגלים מנתבים כל קריאת תרגום.

שורת הפקודה של BabelDOC לוקחת את ה-endpoint ישירות: --openai מפעיל את מתרגם ה-LLM, --openai-base-url קובע לאן הבקשות הולכות, --openai-api-key מאמת, ו---openai-model בוחר את ה-id של המודל. הדוגמאות של ה-README עצמו מראות בדיוק את קבוצת הדגלים הזו, וההערה על שירות התרגום שלו קובעת שרק LLMs תואמי OpenAI נתמכים, מה שהופך gateway תואם OpenAI מרובה-ספקים להתאמה טבעית ולא לפתרון עוקף. מכיוון שה-id של המודל מועבר כמחרוזת פשוטה, כל מה שה-endpoint משרת עובד: התיעוד ה-upstream עצמו ממליץ על מודלים ידידותיים ל-OpenAI-compatible ממשפחות GLM ו-DeepSeek, ודרך APIsRouter אלה יושבים לצד ids של Claude ו-Gemini מאחורי אותו base URL.

babeldoc --files paper.pdf \
  --lang-in en --lang-out zh \
  --openai \
  --openai-model "deepseek-v4-flash" \
  --openai-base-url "https://api.apisrouter.com/v1" \
  --openai-api-key "$APISROUTER_API_KEY"

איך BabelDOC הופך PDF לקריאות מודל.

BabelDOC (funstory-ai ב-GitHub, כ-9K כוכבים, מהצוות שמאחורי Immersive Translate) הוא מתרגם מסמכי PDF ששומר על הפריסה: הוא מנתח את מבנה המסמך, מגן על נוסחאות ואיורים, מוצא פסקאות, מתרגם אותן עם LLM, ובונה מחדש את ה-PDF כגרסה מתורגמת יחידה וכגרסה כפולה זו-לצד-זו. הוא מגיע כ-CLI וכ-Python API, וזהו העמית ה-self-hosted לשירות ה-BabelDOC המתארח. שלב התרגום הוא המקום שבו ה-endpoint משנה. מסמך הופך להרבה בקשות chat-completions בגודל פסקה, מוגבלות על ידי הדגל --qps (ברירת מחדל 4 שאילתות לשנייה) ומעובדות על ידי מאגר עובדים (pool-max-workers, כברירת מחדל שווה לערך ה-QPS). לצורה הזו יש שתי השלכות. ראשית, תרגום הוא עומס עבודה נפחי: PDF ארוך הוא מאות קריאות קטנות, כך שהמחיר-לטוקן מצטבר מהר. שנית, בניגוד לעומסי אחזור שבהם המודל בעיקר קורא, תרגום כותב בערך כמה שהוא קורא, כך שמחיר טוקני הפלט חשוב כמו מחיר הקלט כשאתם משווים ids. BabelDOC גם שומר תרגומים במטמון (cache), כך שהרצה חוזרת על מסמך משתמשת מחדש בתוצאות קודמות אלא אם תעבירו --ignore-cache. קבצי CSV למילון מונחים (--glossary-files) נועצים טרמינולוגיה על פני ההרצה, ו---max-pages-per-part מפצל מסמכים גדולים מאוד לחלקים שמתורגמים ומתמזגים אוטומטית.

הגדרה מלאה: דגלי CLI או קובץ הגדרת TOML.

לשימוש חוזר, אותן ההגדרות חיות בקובץ TOML שמועבר עם --config. הטבלה [babeldoc] מקבלת את אותם המפתחות ב-kebab-case: openai, openai-model, openai-base-url, openai-api-key, בתוספת אפשרויות התפוקה והפלט. זה שומר את המפתח מחוץ להיסטוריית ה-shell שלכם והופך פרופיל תרגום לבר-שחזור על פני מסמכים. ההגדרה למטה היא פרופיל נפח מעשי: id מהיר לרוב המסמכים, QPS מוגבר כדי להתאים ל-gateway עם pool, ושני מצבי הפלט נשמרים. החליפו את openai-model ל-id חזק יותר עבור מסמכים שבהם ניואנס חשוב יותר מתפוקה.

[babeldoc]
lang-in = "en-US"
lang-out = "zh-CN"
qps = 10
pool-max-workers = 10

# Translation service
openai = true
openai-model = "deepseek-v4-flash"
openai-base-url = "https://api.apisrouter.com/v1"
openai-api-key = "sk-YOUR-APISROUTER-KEY"

# Output control
no-dual = false
no-mono = false
watermark-output-mode = "no_watermark"

בחירת מודל תרגום.

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

  • מסמכי נפח (מדריכים, מאמרים שנקראים פעם אחת) מתאימים ל-deepseek-v4-flash: איכות התרגום נשמרת עבור פרוזה טכנית והעלות לעמוד כמעט זניחה.
  • תרגום ליעד סינית הוא משחק בית עבור glm-5.2 ומשפחת DeepSeek; התיעוד ה-upstream עצמו מצביע על מודלי GLM ו-DeepSeek כבחירות תואמות-OpenAI מתנהגות היטב.
  • מסמכים קריטיים-ניואנס (חוזים, תרגומים מפורסמים) מצדיקים את claude-sonnet-4-6 או claude-haiku-4-5-20251001, שעוקבים אחר טרמינולוגיה ורגיסטר בנאמנות רבה יותר על פני מסמכים ארוכים.
  • טוקני פלט חשובים כאן. תרגום כותב בערך כמה שהוא קורא, אז השוו ids גם על עמודת מחיר הפלט, לא רק הקלט.
  • זווגו מילוני מונחים עם ids מהירים. CSV של מילון מונחים נועץ את הטרמינולוגיה שמודלים מהירים לפעמים סוטים ממנה, מה שסוגר חלק ניכר מפער האיכות בטקסט טכני.

תשלום לפי שימוש · מתחת למחיר הרשמי

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

מודלמחיר רשמיהמחיר שלנו
DeepSeek V4 Flash$0.14 / $0.28 per M$0.10 / $0.30 per M
GLM-5.2$1.14 / $4.00 per M$1.10 / $4.00 per M
Gemini 3.5 Flash$1.50 / $9.00 per M$1.20 / $7.20 per M
Claude Haiku 4.5 20251001$1.00 / $5.00 per M$0.80 / $4.00 per M
Claude Sonnet 4.6$3.00 / $15.00 per M$2.40 / $12.00 per M

מצבי כשל וכיוונון תפוקה.

QPS הוא הכפתור שמתקשר עם ה-gateway. ברירת המחדל של 4 שאילתות לשנייה שמרנית; קיבולת upstream עם pool בדרך כלל מחזיקה יותר, והעלאת --qps (עם pool-max-workers שעוקב אחריו) היא איך מסמך בן 300 עמודים מפסיק לקחת אחר-צהריים שלם. העלו את זה בהדרגה תוך צפייה בתגובות 429 במקום לקפוץ למספר גדול קר, מכיוון שפסקה שהוגבלה בקצב מנסה שוב ומאיטה את כל ההרצה. הדגלים חלים רק כש---openai מוגדר. העברת base URL בלי --openai משאירה את המתרגם מושבת, מה שמתבטא כהרצה שמנתחת את ה-PDF אבל אף פעם לא מתרגמת. ids של מודלים הם מחרוזות מדויקות מול רשימת ה-/v1/models של ה-endpoint; טעות הקלדה מכשילה את קריאת הפסקה הראשונה עם model-not-found. 401 אומר שהמפתח וה-base URL לא שייכים יחד. בעיות פריסה אינן בעיות endpoint. טקסט חופף, נוסחאות אבודות, או טבלאות שבורות מתחקות לצד ניתוח ה-PDF (נסו --enhance-compatibility, --ocr-workaround למסמכים סרוקים, או את מתג rich-text), והחלפת מודלים לא תתקן אותן. גם ההפך נכון: טרמינולוגיה מתורגמת שגוי היא בעיית מודל או מילון מונחים, לא בעיית parser. המטמון יכול להסתיר שינויים. לאחר החלפת מודלים, העבירו --ignore-cache אם אתם רוצים שה-id החדש יתרגם מחדש תוכן שה-id הישן כבר כיסה; אחרת פסקאות במטמון נשארות כפי שהיו.

מי מנתב את BabelDOC דרך gateway.

  • חוקרים שמתרגמים מאמרים בכמות גדולה, שם מאות קריאות קטנות למסמך הופכות תמחור נפח ונראות שימוש-לפי-מפתח למשחק כולו.
  • צוותים שמתקננים תיעוד דו-לשוני, מריצים פרופיל ברירת מחדל מהיר ופרופיל פרימיום מול אותו endpoint עם מחרוזות מודל שונות.
  • משתמשים בשווקים שבהם מודלי התרגום החזקים ביותר לזוג השפות שלהם נמצאים אצל ספקים שונים: ids של GLM, DeepSeek, Claude, ו-Gemini כולם מאחורי מפתח אחד.
  • self-hosters שמחליפים את השירות המתארח עבור מסמכים סודיים, שומרים את הניתוח מקומי ושולחים רק טקסט פסקה אל endpoint אחד שניתן לביקורת.
  • מפתחים ללא גישה לחיוב של ספק נתון. גישה מבוססת-הטענה בלי דרישת כרטיס מסירה את התלות בהרשמה לכל ספק.

אמתו את ה-endpoint ובצעו דיבוג למסמך הראשון.

רשמו את המודלים שהמפתח שלכם יכול לכתוב אליהם לפני שאתם מתחילים הרצה ארוכה; --openai-model חייב להתאים בדיוק ל-id מוגש. לאחר מכן תרגמו משהו זעיר (PDF בן עמוד אחד, או --pages 1 על אחד גדול יותר) מקצה לקצה. 401 בפסקה הראשונה אומר שהמפתח לא תואם ל-base URL. model-not-found היא טעות הקלדה ב-id. הרצה שמנתחת אבל אף פעם לא קוראת ל-endpoint חסרה --openai. תקיעות תכופות עם הודעות retry מצביעות על QPS שהוגדר גבוה יותר ממה שה-endpoint מחזיק; הורידו אותו והעלו בהדרגה בחזרה. ברגע שמסמכים זורמים, קונסולת APIsRouter מציגה מודל לכל בקשה, ספירות טוקן, והוצאה. עלות התרגום נמדדת לפי אורך המסמך בשני הכיוונים (קלט ופלט), ולוג השימוש לפי מפתח הוא הדרך ללמוד את העלות האמיתית שלכם לעמוד לכל מודל במקום להעריך אותה.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

# then a one-page smoke test
babeldoc --config babeldoc.toml --files sample.pdf --pages 1

שאלות נפוצות

האם BabelDOC תומך ב-endpoints תואמי OpenAI מותאמים אישית?

כן, באופן נטיבי. ה-CLI חושף את --openai-base-url ו---openai-api-key לצד --openai-model, וקובץ ה-TOML מקבל את אותם המפתחות. ה-README ה-upstream קובע ש-LLMs תואמי OpenAI הם סוג המתרגם הנתמך.

האם BabelDOC יכול לתרגם עם מודלי Claude, GLM, או DeepSeek?

כן. ה-id של המודל מועבר כמחרוזת פשוטה אל ה-endpoint מאחורי --openai-base-url, כך שכל id מהקטלוג עובד. התיעוד ה-upstream עצמו ממליץ על מודלי משפחות GLM ו-DeepSeek כבחירות מתנהגות היטב.

כמה קריאות API עולה PDF אחד?

BabelDOC מתרגם נתחים בגודל פסקה, כך שמסמך הופך למאות קריאות chat-completions קטנות המוגבלות על ידי --qps. גם טוקני קלט וגם פלט נמדדים לפי אורך המסמך; לוג השימוש לפי מפתח מציג את העלות המדויקת לכל מסמך.

איזה QPS כדאי להגדיר מול gateway?

התחילו קרוב לברירת המחדל של 4 והעלו בהדרגה תוך צפייה בתגובות 429; endpoints עם pool בדרך כלל מחזיקים יותר, ו-pool-max-workers עוקב אחר ערך ה-QPS אלא אם מוגדר בנפרד. QPS גבוה יותר ויציב הוא ההבדל בין דקות לשעות על מסמכים ארוכים.

החלפתי מודלים אבל התרגום לא השתנה. למה?

מטמון התרגום. BabelDOC משתמש מחדש בתוצאות במטמון לכל מסמך; העבירו --ignore-cache אחרי שינוי --openai-model כך שה-id החדש יתרגם מחדש תוכן שכוסה קודם.

האם בחירת ה-endpoint משפיעה על פריסה, נוסחאות, או טבלאות?

לא. ניתוח, ניתוח פריסה, ובנייה מחדש של PDF רצים מקומית ללא קשר ל-endpoint. לבעיות פריסה יש דגלים משלהן (--enhance-compatibility, --ocr-workaround); ה-base URL רק קובע איזה מודל מתרגם את הטקסט.