Isalin ang mga PDF gamit ang BabelDOC sa isang custom OpenAI base URL.

Mabilisang sagot: tatlong flag ang nagruruta sa bawat tawag sa pagsasalin.

Direktang tinatanggap ng command line ng BabelDOC ang endpoint: pinapagana ng --openai ang LLM translator, itinatakda ng --openai-base-url kung saan pupunta ang mga request, nagpapatunay ng pagkakakilanlan ang --openai-api-key, at pinipili ng --openai-model ang id ng model. Ipinapakita mismo ng mga halimbawa sa README ang eksaktong set ng flag na ito, at sinasabi ng tala nito tungkol sa translation service na mga OpenAI-compatible na LLM lamang ang sinusuportahan, na siyang dahilan kung bakit natural na tugma ang isang multi-vendor na OpenAI-compatible gateway sa halip na isang workaround. Dahil ipinapasa ang model id bilang plain string, gumagana ang kahit anong si-serve ng endpoint: inirerekomenda mismo ng upstream docs ang mga model na madaling makasama ng OpenAI-compatible mula sa mga pamilyang GLM at DeepSeek, at sa pamamagitan ng APIsRouter nakatabi ang mga ito sa mga id ng Claude at Gemini sa likod ng parehong 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"

Paano ginagawang mga tawag sa model ng BabelDOC ang isang PDF.

Ang BabelDOC (funstory-ai sa GitHub, humigit-kumulang 9K stars, mula sa team sa likod ng Immersive Translate) ay isang PDF document translator na pinapanatili ang layout: pinag-aanalisa nito ang istruktura ng dokumento, pinoprotektahan ang mga formula at figure, hinahanap ang mga talata, isinasalin ang mga ito gamit ang isang LLM, at binubuo muli ang PDF bilang isang isinaling mono na bersyon at isang side-by-side na dual na bersyon. Ipinapamahagi ito bilang isang CLI at isang Python API, at ito ang self-hosted na katapat ng hosted na serbisyo ng BabelDOC. Ang translation phase ang kung saan mahalaga ang endpoint. Ang isang dokumento ay nagiging maraming chat-completions na request na kasing-laki ng bawat talata, na kinokontrol ng --qps flag (4 na query per second bilang default) at pinoproseso ng isang worker pool (pool-max-workers, na ang default ay ang value ng QPS). Dalawang epekto ang hugis na iyon. Una, isang volume workload ang pagsasalin: daan-daang maliliit na tawag ang isang mahabang PDF, kaya mabilis na naiipon ang presyo per token. Pangalawa, hindi tulad ng mga retrieval workload kung saan halos bumabasa lang ang model, ang pagsasalin ay sumusulat nang halos katumbas ng binabasa nito, kaya kasingahalaga ng input price ang output-token price kapag ikinukumpara mo ang mga id. Nag-i-cache din ang BabelDOC ng mga pagsasalin, kaya ang muling pagpapatakbo ng isang dokumento ay gumagamit ulit ng mga naunang resulta maliban kung magpasa ka ng --ignore-cache. Ang mga glossary CSV (--glossary-files) ay nagpipin ng terminolohiya sa buong run, at hinahati ng --max-pages-per-part ang napakalaking dokumento sa mga bahagi na isinasalin at pinagsasama-sama nang awtomatiko.

Buong setup: mga CLI flag o ang TOML config file.

Para sa paulit-ulit na paggamit, nakatira ang parehong mga setting sa isang TOML file na ipinapasa gamit ang --config. Tinatanggap ng [babeldoc] table ang parehong mga key sa kebab-case: openai, openai-model, openai-base-url, openai-api-key, kasama ang mga opsyon sa throughput at output. Pinananatili nitong wala sa shell history mo ang key at ginagawang reproducible ang isang translation profile sa iba't ibang dokumento. Ang config sa ibaba ay isang praktikal na volume profile: isang mabilis na id para sa karamihan ng mga dokumento, tinaasang QPS para tumugma sa isang pooled na gateway, at parehong output mode na pinapanatili. Palitan ang openai-model sa mas malakas na id para sa mga dokumentong mas mahalaga ang nuance kaysa sa throughput.

[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"

Pagpili ng model para sa pagsasalin.

Konkreto ang workflow ng paghahambing: isalin ang parehong sampung pahina gamit ang dalawang id (pinananatiling hiwalay ng cache na keyed per run ang mga ito), basahin ang mga dual nang magkatabi, at tignan ang per-key usage log kung magkano ang naging gastos ng bawat pass. Karamihan sa mga team ay bumabagsak sa isang mabilis na default kasama ang isang premium profile para sa mga dokumentong karapat-dapat dito, parehong bilang mga TOML file.

• Ang mga volume na dokumento (manuals, papers na isang beses lang babasahin) ay bagay sa deepseek-v4-flash: nananatiling maganda ang kalidad ng pagsasalin para sa technical prose at halos wala nang bahagi ang gastos per page.
• Home game ang pagsasalin patungong Chinese para sa glm-5.2 at sa pamilya ng DeepSeek; mismong itinuturo ng upstream docs ang mga model ng GLM at DeepSeek bilang magandang kilos na mga pagpipiliang OpenAI-compatible.
• Ang mga dokumentong kritikal ang nuance (mga kontrata, mga nailathalang salin) ay nagbibigay-katwiran sa claude-sonnet-4-6 o claude-haiku-4-5-20251001, na mas tapat na sumusubaybay sa terminolohiya at rehistro sa buong haba ng mahahabang dokumento.
• Mahalaga rito ang mga output token. Sumusulat ang pagsasalin nang halos katumbas ng binabasa nito, kaya ikumpara ang mga id sa output price column din, hindi lang sa input.
• Ipares ang mga glossary sa mabilis na id. Ang isang glossary CSV ay nagpipin sa terminolohiyang paminsan-minsang lumilihis ang mabibilis na model, na nagsasara ng malaking bahagi ng gap sa kalidad sa technical text.

Pay-as-you-go · mas mababa sa opisyal na presyo

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

Mga failure mode at pag-tune ng throughput.

Ang QPS ang kontrol na nakikipag-ugnayan sa gateway. Konserbatibo ang default na 4 na query per second; karaniwang kaya ng pooled upstream capacity ang higit pa, at ang pagtaas ng --qps (kasunod ang pool-max-workers) ang paraan para tumigil sa pag-ubos ng buong hapon ng isang 300-pahinang dokumento. Taasan ito nang paunti-unti habang binabantayan ang mga 429 response sa halip na tumalon agad sa isang malaking numero, dahil ang isang naka-rate-limit na talata ay nag-re-retry at binabagal ang buong run. Umiiral lang ang mga flag kapag naka-set ang --openai. Ang pagpasa ng base URL nang walang --openai ay iniiwang naka-disable ang translator, na lumalabas bilang isang run na pinag-aanalisa ang PDF pero hindi kailanman nagsasalin. Eksaktong mga string ang mga model id laban sa /v1/models listing ng endpoint; ang isang typo ay nagpapabigo sa unang tawag ng talata gamit ang model-not-found. Ang isang 401 ay nangangahulugan na hindi magkatugma ang key at base URL. Hindi problema sa endpoint ang mga problema sa layout. Ang overlapping text, nawawalang formula, o sirang table ay nagmumula sa PDF parsing side (subukan ang --enhance-compatibility, --ocr-workaround para sa mga scanned na dokumento, o ang rich-text toggle), at hindi ito aayusin ng pagpapalit ng model. Totoo rin ang kabaligtaran: isyu sa model o glossary, hindi sa parser, ang maling isinaling terminolohiya. Maaaring itago ng cache ang mga pagbabago. Pagkatapos magpalit ng model, magpasa ng --ignore-cache kung gusto mong muling isalin ng bagong id ang naunang nasakop na content ng lumang id; kung hindi, mananatili sa dati ang mga naka-cache na talata.

Sino ang nagru-route ng BabelDOC sa pamamagitan ng isang gateway.

• Mga mananaliksik na nagsasalin ng mga papel sa dami, kung saan ginagawang buong laro ang volume pricing at per-key usage visibility ng daan-daang maliliit na tawag per dokumento.
• Mga team na nagpapareho ng bilingual na dokumentasyon, na nagpapatakbo ng mabilis na default profile at premium profile laban sa parehong endpoint na may magkaibang model string.
• Mga user sa mga market kung saan ang pinakamalakas na modelo ng pagsasalin para sa wika nila ay nasa iba't ibang vendor: mga id ng GLM, DeepSeek, Claude, at Gemini lahat sa likod ng isang key.
• Mga self-hoster na pumapalit sa hosted service para sa mga kumpidensyal na dokumento, pinapanatiling local ang parsing at ipinapadala lamang ang paragraph text sa isang auditable na endpoint.
• Mga developer na walang access sa billing ng isang partikular na vendor. Ang top-up based na access na walang kailangang card ay inaalis ang per-provider na sign-up dependency.

I-verify ang endpoint at i-debug ang unang dokumento.

Ilista ang mga model na maaabot ng key mo bago magsimula ng mahabang run; dapat eksaktong tumugma ang --openai-model sa isang si-serve na id. Pagkatapos, isalin ang isang napakaliit na bagay (isang isang-pahinang PDF, o --pages 1 sa mas malaki) mula simula hanggang katapusan. Ang isang 401 sa unang talata ay nangangahulugan na hindi tumutugma ang key sa base URL. Ang model-not-found ay isang typo sa id. Ang isang run na pinag-aanalisa ngunit hindi kailanman tumatawag sa endpoint ay kulang ang --openai. Ang madalas na pagkaantala na may mga retry message ay tumuturo sa QPS na mas mataas kaysa sa kaya ng endpoint; ibaba ito at taasan ulit nang paunti-unti. Kapag dumadaloy na ang mga dokumento, ipinapakita ng APIsRouter console ang per-request na model, token counts, at gastos. Nag-i-scale ang gastos sa pagsasalin ayon sa haba ng dokumento sa parehong direksyon (input at output), at ang usage log per key ang paraan mo para malaman ang tunay na gastos mo per page para sa bawat model sa halip na tantiyahin ito lamang.

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

Mga madalas itanong