BabelDOC के साथ PDFs को custom OpenAI base URL पर translate करें।
Updated 2026-07-30
BabelDOC का translator design से ही OpenAI-compatible है: तीन flags (--openai, --openai-base-url, --openai-api-key) plus --openai-model endpoint और model चुनते हैं। Base URL को https://api.apisrouter.com/v1 पर point करें और Claude, DeepSeek, GLM, या Gemini से documents को एक key के through translate करें।
Quick answer: तीन flags हर translation call को route करते हैं।
BabelDOC की command line endpoint को सीधे लेती है: --openai LLM translator को enable करता है, --openai-base-url तय करता है requests कहां जाती हैं, --openai-api-key authenticate करता है, और --openai-model model id चुनता है। README के अपने examples exactly यही flag set दिखाते हैं, और इसका translation-service note कहता है कि सिर्फ OpenAI-compatible LLMs supported हैं, जो एक multi-vendor OpenAI-compatible gateway को workaround नहीं बल्कि natural fit बना देता है। चूंकि model id एक plain string के तौर पर forward होती है, endpoint जो भी serve करता है वह काम करता है: upstream docs खुद GLM और DeepSeek families के OpenAI-compatible-friendly models recommend करते हैं, और APIsRouter के through वे same base URL के पीछे Claude और Gemini ids के बगल में बैठते हैं।
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 को model calls में कैसे बदलता है।
BabelDOC (GitHub पर funstory-ai, लगभग 9K stars, Immersive Translate के पीछे की team से) एक PDF document translator है जो layout preserve करता है: यह document structure parse करता है, formulas और figures protect करता है, paragraphs ढूंढता है, इन्हें एक LLM से translate करता है, और PDF को एक translated mono version और एक side-by-side dual version के तौर पर rebuild करता है। यह एक CLI और एक Python API के तौर पर ship होता है, और यह hosted BabelDOC service का self-hosted counterpart है। Translation phase वह जगह है जहां endpoint matter करता है। एक document कई paragraph-sized chat-completions requests बन जाता है, --qps flag (default 4 queries per second) से throttled और एक worker pool (pool-max-workers, जो default QPS value लेता है) से processed। उस shape के दो consequences हैं। पहला, translation एक volume workload है: एक लंबा PDF सैकड़ों छोटी calls है, तो per-token price तेज़ी से compound होती है। दूसरा, retrieval workloads के उलट जहां model ज़्यादातर पढ़ता है, translation लगभग उतना ही लिखता है जितना पढ़ता है, तो ids compare करते समय output-token price भी input price जितनी ही matter करती है। BabelDOC translations को cache भी करता है, तो एक document को दोबारा run करना पुराने results reuse करता है जब तक आप --ignore-cache pass ना करें। Glossary CSVs (--glossary-files) पूरी run में terminology pin करती हैं, और --max-pages-per-part बहुत बड़े documents को parts में split करता है जो automatically translate और merge होते हैं।
पूरा setup: CLI flags या TOML config file।
बार-बार इस्तेमाल के लिए, same settings एक TOML file में रहती हैं जो --config से pass होती है। [babeldoc] table वही keys kebab-case में accept करता है: openai, openai-model, openai-base-url, openai-api-key, plus throughput और output options। यह key को आपके shell history से बाहर रखता है और documents के across एक translation profile को reproducible बनाता है। नीचे वाला config एक practical volume profile है: ज़्यादातर documents के लिए एक fast id, pooled gateway से match करने के लिए बढ़ी हुई QPS, और दोनों output modes बरकरार। जिन documents में nuance throughput से ज़्यादा matter करती है, वहां openai-model को एक stronger 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"एक translation model चुनना।
Comparison workflow concrete है: same दस pages को दो ids से translate करें (per run keyed cache इन्हें अलग रखता है), duals को साथ-साथ पढ़ें, और per-key usage log में देखें हर pass की क्या लागत आई। ज़्यादातर teams एक fast default plus एक premium profile पर आते हैं उन documents के लिए जो इसके हक़दार हैं, दोनों TOML files के तौर पर।
- Volume documents (manuals, एक बार पढ़े जाने वाले papers) deepseek-v4-flash पर fit बैठते हैं: technical prose के लिए translation quality बनी रहती है और per-page cost लगभग negligible है।
- Chinese-target translation glm-5.2 और DeepSeek family के लिए home game है; upstream docs खुद GLM और DeepSeek models को well-behaved OpenAI-compatible choices के तौर पर बताते हैं।
- Nuance-critical documents (contracts, published translations) claude-sonnet-4-6 या claude-haiku-4-5-20251001 को justify करते हैं, जो लंबे documents के across terminology और register को ज़्यादा faithfully track करते हैं।
- यहां output tokens matter करते हैं। Translation लगभग उतना ही लिखता है जितना पढ़ता है, तो ids को output price column पर भी compare करें, सिर्फ input पर नहीं।
- Fast ids के साथ glossaries pair करें। एक glossary CSV उस terminology को pin करती है जिस पर fast models कभी-कभी drift करते हैं, जो technical text पर quality gap का ज़्यादातर हिस्सा close कर देती है।
जितना उपयोग उतना भुगतान · आधिकारिक मूल्य से कम
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 |
Failure modes और throughput tuning।
QPS वह knob है जो gateway से interact करता है। 4 queries per second का default conservative है; pooled upstream capacity आमतौर पर ज़्यादा sustain करती है, और --qps बढ़ाना (pool-max-workers साथ में) वह तरीका है जिससे एक 300-page document पूरी दोपहर लेना बंद कर देता है। बड़ी number पर cold जाने की बजाय 429 responses देखते हुए ramp करें, क्योंकि एक rate-limited paragraph retry करता है और पूरी run को धीमा कर देता है। Flags तभी apply होते हैं जब --openai set हो। बिना --openai के base URL pass करना translator को disabled छोड़ देता है, जो एक ऐसी run के तौर पर सामने आता है जो PDF parse करती है पर कभी translate नहीं करती। Model ids endpoint की /v1/models listing के against exact strings हैं; एक typo model-not-found के साथ पहली paragraph call fail करती है। एक 401 का मतलब है key और base URL एक साथ belong नहीं करते। Layout problems endpoint problems नहीं हैं। Overlapping text, खोए हुए formulas, या टूटी tables PDF parsing side से trace होते हैं (--enhance-compatibility, scanned documents के लिए --ocr-workaround, या rich-text toggle try करें), और models बदलना इन्हें ठीक नहीं करेगा। उल्टा भी सही है: mistranslated terminology एक model या glossary issue है, parser issue नहीं। Cache changes को mask कर सकता है। Models बदलने के बाद, अगर आप चाहते हैं कि नई id वह content retranslate करे जो पुरानी id पहले ही cover कर चुकी थी तो --ignore-cache pass करें; वरना cached paragraphs जैसे थे वैसे ही रहते हैं।
कौन BabelDOC को एक gateway के through route करता है।
- Researchers जो papers को bulk में translate करते हैं, जहां per document सैकड़ों छोटी calls volume pricing और per-key usage visibility को पूरा game बना देती हैं।
- Teams जो bilingual documentation standardize कर रही हैं, same endpoint के against एक fast default profile और एक premium profile अलग model strings से चला रही हैं।
- Users उन markets में जहां उनके language pair के लिए सबसे strong translation models अलग-अलग vendors के पास हैं: GLM, DeepSeek, Claude, और Gemini ids सब एक key के पीछे।
- Self-hosters जो confidential documents के लिए hosted service replace कर रहे हैं, parsing local रखते हुए और सिर्फ paragraph text एक auditable endpoint को भेजते हुए।
- Developers जिनके पास किसी given vendor की billing तक access नहीं है। बिना card requirement वाला top-up based access per-provider sign-up dependency हटा देता है।
Endpoint verify करें और पहले document को debug करें।
एक लंबी run शुरू करने से पहले वे models list करें जिन तक आपकी key पहुंच सकती है; --openai-model को exactly एक served id से match करना चाहिए। फिर कुछ tiny (एक one-page PDF, या बड़े वाले पर --pages 1) end to end translate करें। पहली paragraph पर एक 401 का मतलब है key base URL से match नहीं करती। Model-not-found एक id typo है। एक run जो parse तो करे पर endpoint को कभी call ना करे उसमें --openai missing है। Retry messages के साथ बार-बार stalls उस QPS की तरफ इशारा करते हैं जो endpoint sustain करने से ज़्यादा है; इसे कम करें और वापस ramp करें। एक बार documents flow करने लगें, APIsRouter console per-request model, token counts, और spend दिखाता है। Translation cost दोनों directions (input और output) में document length के साथ scale करती है, और per key usage log वह तरीका है जिससे आप हर model के लिए per page अपनी असली cost सीखते हैं, estimate करने की बजाय।
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 custom OpenAI-compatible endpoints support करता है?
हां, natively। CLI --openai-model के साथ --openai-base-url और --openai-api-key expose करता है, और TOML config same keys accept करता है। Upstream README कहता है कि OpenAI-compatible LLMs supported translator type हैं।
क्या BabelDOC Claude, GLM, या DeepSeek models से translate कर सकता है?
हां। Model id --openai-base-url के पीछे endpoint को एक plain string के तौर पर forward होती है, तो कोई भी catalog id काम करती है। Upstream docs खुद GLM और DeepSeek family models को well-behaved choices के तौर पर recommend करते हैं।
एक PDF की कितनी API calls लगती हैं?
BabelDOC paragraph-sized chunks translate करता है, तो एक document --qps से throttled सैकड़ों छोटी chat-completions calls बन जाता है। Input और output दोनों tokens document length के साथ scale करते हैं; per-key usage log exact per-document cost दिखाता है।
एक gateway के against मुझे कौन सी QPS set करनी चाहिए?
Default 4 के पास शुरू करें और 429 responses देखते हुए ramp up करें; pooled endpoints आमतौर पर ज़्यादा sustain करते हैं, और pool-max-workers QPS value follow करता है जब तक अलग से set ना किया जाए। एक stable higher QPS ही लंबे documents पर मिनटों और घंटों के बीच का फर्क है।
मैंने models बदले पर translation नहीं बदला। क्यों?
Translation cache। BabelDOC per document cached results reuse करता है; --openai-model बदलने के बाद --ignore-cache pass करें ताकि नई id पहले cover किए content को retranslate करे।
क्या endpoint की choice layout, formulas, या tables को affect करती है?
नहीं। Parsing, layout analysis, और PDF reconstruction endpoint से independent locally चलते हैं। Layout issues की अपनी flags हैं (--enhance-compatibility, --ocr-workaround); base URL सिर्फ यह तय करता है कि text कौन सा model translate करता है।