[Dev Note] Gemini 3 附帶的 PDF 黑魔法：從 Token 爆炸到無痛吃到飽

Dec 5, 2025 min read
[Dev Note] Gemini 3 附帶的 PDF 黑魔法：從 Token 爆炸到無痛吃到飽

前言：Gemini 3 世代下的 PDF 黑魔法

做為一個熱愛在 Side Project 裡串接 AI 的開發者，過去這半年，我跟 Google Gemini 的關係大概就像坐雲霄飛車一樣：從熱戀、到失望分手（轉向手刻輪子），再到今天——我又重新愛上它了。

今天想跟大家聊聊 Gemini 3 在 PDF 文件處理 (Document Processing) 上的一個「無聲但巨大」的改動。如果你跟我一樣，過去曾經因為 GEMINI 的 file api ，總是把 PDF 轉圖片導致 Token 爆炸而去尋找其他解決方案（to markdown、OCR、vision model），那我得說，“大家可以回家啦！”。

背景：曾經的百萬豪邁與 10/26 的惡夢

把時間撥回幾個月前。那時候 Gemini 2.5 Pro 剛出來，最讓我（以及所有開發者）驚豔的，就是那個大方到不行的 100 萬 Token Context Window，以及對免費用戶極其慷慨的 Rate Limit。

那時我的 Side Project 邏輯超級簡單暴力：

  1. 下載一份幾十頁的財報或報紙 PDF。
  2. 直接整份丟進 Gemini API。
  3. Prompt: “幫我摘要這份文件。”
  4. 搞定。

因為 Context 夠大，我根本不需要做什麼 to markdown、ETL、chunking，反正全部丟進去它都吃得下。那是一段「暴力美學」的美好時光。

但好景不常，這段蜜月期我依稀記得在 2025-10-26 戛然而止。

Google 調整了免費層級 (Free Tier) 的限制，將 TPM (Tokens Per Minute) 的上限做了毀滅性的調降：

  • Gemini-2.5-Pro：從 100 萬驟降至 12.5 萬。
  • Gemini-2.5-Flash：從 100 萬驟降至 25 萬。

這對我的 PDF 處理流程來說是災難性的。為什麼？

因為在當時，Gemini 2.5 處理 PDF 的邏輯是將每一頁 PDF 視為一張「高解析度圖片 (Image)」。你可能覺得一份純文字的 PDF 沒多少字，但在 LLM 眼裡，那是 50 張高畫質截圖。

隨便一份華爾街日報或財報，轉成圖片後的 Token 數輕鬆突破 11 萬至 20 萬+。這意味著，我只要傳送一個 Request，立刻就會撞到 12.5 萬或 25 萬的 TPM 牆，API 直接報錯 429 Too Many Requests。

困境：被迫勤勞的手刻 Markdown 轉換器

為了讓專案繼續跑下去，我不得不放棄「直接上傳 PDF」的懶人做法。

我開始研究 Python 的 pdfminer、PyMuPDF，甚至是其他一些 OCR 工具，把 PDF 轉成 Markdown 格式。

可以參考之前的過程細節 [教學] Cloudflare Auto Rag 一起動手玩。

雖然這樣把 Token 壓回了 2~3 萬的水準，成功繞過了 TPM 限制，但心裡還是很阿雜：

  1. 圖表看不到了：財報裡的趨勢圖、K 線圖直接被 script 過濾掉，AI 分析少了一隻眼睛。
  2. 維護成本變高：我還要自己維護 PDF 解析的程式碼，尤其是 to markdown 以後的資料清洗。

轉機：Gemini 3 世代，帶來的驚喜

直到今天，我在 google ai studio 上測試最新的 Gemini 3 模型時，抱著「試試看能不能操爆它」的心態，把一份完整的、包含大量圖表的 PDF 報紙直接 generate content。

結果？ Token 用量顯示：39,000。

真的是 3 萬多，不是 13 萬。而且內容也精準地包含圖表資訊。

技術細節：到底發生了什麼事？

我去翻了最新的 Google AI Studio 文件，才發現 Google 在底層邏輯上做了一個超棒的優化。

簡單來說，Gemini 3 出世以後，處理 PDF 的方式也改變了：

  1. 以前 (Vision-only)： 不管 PDF 是掃描的還是數位的，模型通通把它當成「一連串的圖片」來看，並且強制轉換為一張又一張高解析度圖片。一張圖片 = 1000-1500 Token (甚至更多)。假設 1500 Token 一張圖片，50 頁就是 75,000 Token 起跳。

  2. 現在 (Native Text + Vision)： File API 變聰明了。它會優先讀取 PDF 內部的原生文字編碼 (Native Text)。

    • 重點來了：Google 的文件暗示，從 PDF 提取的原生文字 Token，是不計費（或是權重極低）的！
    • 模型只會對那些「真的需要視覺理解」的部分（比如圖表、照片）計算視覺 Token，而且預設使用了更聰明的壓縮技術。

這就是為什麼同樣一份檔案，在過去傳一份 PDF 是 11 萬 Token（因為全是圖），今天傳一份 PDF 是 3 萬 Token（因為是文字 + 少許圖）。

(個人過去實測案例: wsj-daily.pdf，平均一份會是佔用 11 萬至 20 萬 token，幅度這麼大的原因是假日版本廣告內容會更多一些)

(技術細節 Google 沒完全公開，以上是根據官方文件與實測推斷)

結論：懶人開發者的勝利

這項改動對我來說意義重大：

  1. 成本大幅下降：不管是免費版的 TPM 限制，還是付費版的帳單，壓力都瞬間釋放。
  2. 流程回歸簡潔：我可以把那些自己寫的 pdf to Markdown 腳本丟進垃圾桶了。直接 upload_file，剩下的交給 Google。（當然，如果你有打算玩 RAG，這 to markdown 的工作還是省不了）
  3. 圖文並茂：因為不用自己暴力轉文字，現在模型又能重新「看見」那些重要的趨勢圖和版面配置了。

如果你跟我一樣，之前因為 10 月底的那波 TPM 限縮而對 Gemini 感到灰心，強烈建議你回來試試。那個「直接把文件甩給 AI 就能用」的爽快感，真的回來了！

文件沒說明，僅僅一行字，但實際上等於是向下支援過去 Gemini 2.5 版本，畢竟核心改變的是 file api 的處理邏輯，而不是 model 的能力。

(出自官方文件)

(P.S. 當然，如果你的 PDF 是那種純圖片掃描檔、裡面沒有文字層的，那 Token 還是會算圖片的喔！但對大多數現代文件來說，這絕對是個 Game Changer。)