AI 趨勢日報：2026-07-24

鵜鶘測試無罪，但 AI 帳本藏了 1.65 兆美元等待浮現

什麼是 Pelicanmaxxing？AI 實驗室的規模幻術

Simon Willison 多年來習慣以「鵜鶘騎自行車 SVG」作為固定測試 prompt，因為這類輸出長期佔據 Hacker News 熱門回應，逐漸形成非正式的社群基準。

2025 年起，外界開始懷疑 AI 實驗室是否針對這題刻意調教模型——這個現象被稱為「Pelicanmaxxing」。

研究者 Dylan Castillo 以系統化方式回應這個質疑：他對七個前沿模型進行 1,008 張 SVG 圖測試，涵蓋 48 種動物與交通工具的配對組合，使用固定效應迴歸加上 LLM 評審打分。

結論清晰：鵜鶘在 8 種動物中排名第 6，自行車在載具中排名第 7，鵜鶘加自行車組合在 48 種配對中排名第 42——並無統計顯著的「鵜鶘加成」。

Castillo 本人坦言：「我找不到任何跡象顯示鵜鶘自行車圖片明顯優於其他組合。」更可能的解釋是「SVGmaxxing」——各實驗室在整體向量圖形能力上的全面提升，而非單點作弊。

名詞解釋
固定效應迴歸 (Fixed Effects Regression) ：一種排除個體差異干擾的統計方法，用於消除不同動物或交通工具本身難度的影響，讓跨組比較更公平。

帳面之下：AI 公司如何隱藏巨額債務

就在 Pelicanmaxxing 爭議平息之際，Nikkei Asia 一份 2026 年 7 月的研究揭示了更嚴峻的財務真相。

Alphabet、Microsoft、Amazon、Meta 與 Oracle 五大科技巨頭，表外負債合計高達約 1.65 兆美元，超過其帳面正式揭露的 1.35 兆美元，比例達帳面債務的 122%。

Meta 一家的表外曝險便高達約 4,200 億美元，接近其透明債務的三倍；Oracle 的隱性負債四年來成長逾 30 倍，達 2,733 億美元，主要來源是與 Stargate 專案相關的資料中心承諾。

這些表外義務自 2022 年以來已成長約 8 倍，融資工具涵蓋資料中心租約、GPU 供應合約及特殊目的載具 (SPV) 。

名詞解釋
特殊目的載具（SPV，Special Purpose Vehicle）：企業設立的獨立法律實體，用於隔離特定資產或負債，使其不直接出現在母公司的資產負債表上。

技術會計顧問 Tom Selling 直言：「如果其中一家公司是紙牌屋，靠這種會計處理撐著，那會怎樣？」他將現行財務結構比擬為 2001 年 Enron 崩潰前夕。

社群激辯：必要投資還是即將破裂的泡沫？

HN 社群在 AI 債務議題上呈現鮮明分歧。

支持者認為，這不過是 GAAP 合規框架下的「CFO 101 基本操作」——科技公司開始像傳統資本密集產業一樣使用槓桿，而其千億美元級別的獲利本就足以支撐現有規模。

批評者則指向更根本的結構性問題：科技巨頭互相投資、互相付費，形成封閉的資金循環，讓真實的外部需求幾乎無從分辨。AI 板塊已佔 S&P 500 約 40%，若多家高槓桿公司同步出現流動性問題，波及範圍將遠超科技業本身。

一位 HN 評論者指出，私人信用已滲入部分壽險公司，「這終將成為所有人的問題」——反映出風險傳染路徑已悄然延伸至退休金與保險資產。

可持續性展望：AI 產業的下一步

兩條脈絡在此收斂：Pelicanmaxxing 的無罪證明讓社群暫時鬆了一口氣，但隨即意識到更根本的問題——當連「鵜鶘是否被特訓」這種問題都需要嚴謹統計研究才能釐清，投資人與用戶又如何驗證 AI 能力的真實進步？

表外債務 4 年成長 8 倍、AI 耗電量持續攀升（2025 年已佔全球用電 0.5%），讓整個 AI 投資週期的可持續性疑慮不斷加深。

科技巨頭目前仍享有足夠的信用評等與現金流緩衝，但資料中心租約的「一次性滾入資產負債表」機制，意味著龐大義務只是尚未浮現，而非已被消化。

AI 基礎建設的真正壓力測試，仍在前方等待。

對開發者的影響

Pelicanmaxxing 研究提醒：非正式社群基準的觀察偏差可能遠超想像。單一 prompt 的亮眼表現，更可能反映訓練資料的分布特性（如攝影慣例讓自行車圖片普遍朝右），而非刻意的針對性調教。

評估 AI 模型時，應優先參考有完整方法論披露的系統性測試，而非依賴社群的驚嘆號式分享。

對團隊／組織的影響

AI 供應商的財務穩定性，正成為採購決策的新風險維度。表外負債結構意味著即使帳面健康，特定流動性情境下仍可能出現服務中斷或合約重談。

企業 AI 策略應納入供應商集中度管控，避免核心業務單點依賴於槓桿程度極高的 AI 基礎建設提供者。

短期行動建議

• 要求 AI 工具供應商提供獨立第三方能力評測報告，而非僅依賴官方基準數字
• 追蹤主要 AI 供應商的信用評等變化與年報中的表外義務揭露趨勢
• 規劃雙軌 AI 供應策略，降低對單一平台的過度依賴

產業結構變化

AI 基礎建設投資的槓桿化，正在重寫 AI 產業的風險分布。過去科技公司以「輕資產、高毛利」著稱，如今 Oracle 的隱性負債規模已超越許多傳統重工業企業。

這種轉變尚未反映在多數投資人的估值框架中，科技股的「債務輕型」溢價面臨重新定價的壓力。

倫理邊界

Pelicanmaxxing 爭議與表外負債問題，揭示了 AI 產業的雙重透明度危機：基準測試可能被「優化」，財務報表可能被「架構」。

兩種形式都指向相同的資訊不對稱困境——外部評估極為困難，「市場自我糾正」的前提愈發脆弱。

長期趨勢預測

若 AI 基礎建設繼續以當前速度擴張槓桿，監管機構介入財務披露標準的機率將大幅提升。歐盟已有相關動作，美國 SEC 也可能針對科技公司表外義務設立新的揭露要求。

與此同時，AI 能力評估的標準化壓力持續增加，推動更嚴謹的第三方基準測試機制——讓 Pelicanmaxxing 式的社群質疑能以更低成本得到解答。

pip install gigatoken，一行指令讓分詞速度暴增千倍

SIMD 加速原理：從逐字元到向量化批次處理

傳統 BPE 分詞器的預分詞 (pretokenization) 階段通常委由 Regex 引擎處理，單執行緒吞吐量僅約 47 MiB/s，在超長 prompt 或大規模語料場景下形成隱形瓶頸。

GigaToken 捨棄 Regex，改用手寫的 SWAR(SIMD Within A Register) 實作：將多個字元打包進 64-bit 暫存器同步比對，搭配雙指標指令級平行化，消除大量分支跳躍，使預分詞吞吐量提升至 1,049 MiB/s。

名詞解釋
SWAR(SIMD Within A Register) ：在普通整數暫存器中模擬向量運算的技巧，無需專用向量指令集，即可一次平行處理多個字元資料。

第二個關鍵機制是預分詞快取 (Pretoken Caching)：高頻詞彙在語料中重複出現，GigaToken 建立 pretoken-to-token 映射快取，讓重複詞彙的分詞結果變成近乎 O(1) 的查表操作，是整體達千倍加速的核心跳躍。

千倍提速的基準測試與實際驗證

在 144 核 AMD EPYC 9565 伺服器上，GigaToken 處理 GPT-2 詞彙表達到 24.53 GB/s，比 HuggingFace tokenizers 快 989 倍、比 OpenAI tiktoken 快 681 倍。

Apple M4 Max（16 核）達到 8.79 GB/s，是 HuggingFace 的 1,268 倍；AMD Ryzen 7 9800X3D（16 核）達到 6.27 GB/s，加速 106 倍。理論上單台機器可在不到 7 小時內完成 Common Crawl 全量資料集分詞。

啟用精確相容模式 (exact output parity) 時，輸出與 HuggingFace 位元組完全一致，此模式仍維持約 200–300 倍加速。

HN 用戶 janwas 指出程式碼中的 42-bit 單乘法 hash 函數在超大規模資料集上存在碰撞風險，作者目前尚未提供完整大規模驗證資料，這是生產部署前最關鍵的待確認項目。

新應用場景：RAG、即時推論與大規模資料前處理

分詞速度提升千倍後，RAG 管線是最直接的受益場景：文件在進入 embedding 模型前必須先分詞，過去此步驟在大規模文件庫下構成前處理瓶頸，GigaToken 可將其消除，催生更多即時知識庫問答應用。

在推論服務端，分詞器可在請求進入 GPU 之前即時計算 token 數，用於路由決策與速率限制。長 prompt 場景實測顯示：8,192 token 輸入時首 token 延遲 (TTFT) 減少 8.4%；32,768 token 輸入時減少 7.8%。

名詞解釋
TTFT(Time to First Token) ：從使用者送出請求到收到第一個 token 輸出的時間，是衡量推論服務響應速度的核心指標。

對預訓練資料工程師而言，以往需要大型分散式叢集的 Common Crawl 級別分詞任務，現在單機即可承擔，基礎設施成本大幅下降。

社群技術討論：精確度權衡與整合挑戰

HN 討論串中，精確度問題是最受關注的技術爭議。janwas 的 42-bit hash 碰撞質疑至今未獲完整回應，社群正等待作者在 Common Crawl 規模進行端到端驗證。

在整合面，scottcha 提到其團隊長期使用 vLLM，vLLM 有自己的 tokenizer 管理層，GigaToken 能否無縫嵌入仍需社群進一步驗證。此外，SentencePiece 詞彙表僅達 7–22 倍加速，WordPiece 架構（BERT 系模型）目前完全不支援，對 BERT 系嵌入模型用戶而言尚無效益。

在現代 LLM 推論管線中，分詞看似微不足道，卻是每個請求的必經步驟。當服務處理大量並發請求或超長 prompt 時，分詞吞吐量就從隱形成本演變為真實瓶頸。

環境需求

Python 3.8+，pip install gigatoken 即可安裝，無需額外依賴。核心為 Rust 編譯的 Python 擴充套件，支援 macOS（Apple Silicon 與 x86）、Linux、Windows。

最小 PoC

from gigatoken import Tokenizer

tok = Tokenizer.from_pretrained("gpt2")
tokens = tok.encode("Hello, world!")

# 批次編碼（適合大規模前處理）
batch = tok.encode_batch(["First document", "Second document"])

驗測規劃

導入後先執行精確性對比測試：以相同語料分別用 GigaToken 與 HuggingFace tokenizers 輸出 token 序列，逐行比較。

建議在啟用 exact output parity 模式的狀態下，以至少 100 MB 真實生產語料進行端到端驗證，確認輸出無差異後再正式上線。

常見陷阱

• 未啟用精確相容模式直接上線：預設模式可能與 HuggingFace 輸出有微小差異
• 超大規模資料集未驗證碰撞：42-bit hash 在億級 token 場景應先執行碰撞率抽樣測試
• 對 BERT 系模型使用：WordPiece 目前不支援，需確認模型架構再導入

上線檢核清單

• 觀測：分詞吞吐量 (GB/s) 、TTFT 變化量、碰撞率抽樣結果
• 成本：CPU 時間節省比例、叢集機器數縮減幅度
• 風險：hash 碰撞驗證通過、精確模式測試通過、vLLM 整合相容性確認

競爭版圖

• 直接競品：HuggingFace tokenizers（生態最完整、應用最廣）、OpenAI tiktoken（OpenAI API 套件標配）
• 間接競品：SentencePiece（Google 系模型使用）、各推論框架內建分詞器（vLLM、TGI）

護城河類型

• 工程護城河：SWAR 手寫最佳化需要深厚底層工程能力，66.2% 為 Rust 程式碼，複製成本高
• 生態護城河：支援 23 種分詞器家族，相容性廣，降低遷移阻力

定價策略

MIT 授權完全免費，無商業版或企業版。作者為 Stanford 博士生，目前無商業化跡象，但廣泛採用後可能成為推論基礎設施廠商的整合目標。

企業導入阻力

• 42-bit hash 碰撞風險尚未通過大規模生產驗證，保守型企業需要完整驗證報告
• vLLM、TGI 等主流推論框架尚未原生整合，需自行維護 patch
• WordPiece 不支援，BERT 系嵌入模型用戶無法直接受益

第二序影響

• RAG 前處理成本下降，可能加速即時 RAG 應用商業化落地
• 單機即可完成大規模語料分詞，降低預訓練入門門檻，催生更多小型 AI 實驗室

判決值得關注（Stanford 背書、千倍效能，生態整合仍需成熟）

技術突破真實且可重現，MIT 授權讓採用門檻極低。但 42-bit hash 碰撞疑慮和 vLLM 原生整合缺失，讓保守型企業仍需觀察。資料工程師可立即試用，推論服務整合建議等待社群驗證後再跟進。

多平台基準測試（GPT-2 詞彙表）

在 144 核 AMD EPYC 9565 伺服器上，GigaToken 達到 24.53 GB/s，相較 HuggingFace tokenizers 快 989 倍、相較 OpenAI tiktoken 快 681 倍。Apple M4 Max（16 核）：8.79 GB/s，是 HuggingFace 的 1,268 倍。AMD Ryzen 7 9800X3D（16 核）：6.27 GB/s，達 106 倍加速。

精確相容模式效能

啟用 exact output parity 模式後，輸出與 HuggingFace tokenizers 位元組完全一致，此模式下仍維持 200–300 倍加速，適合需要精確比對的生產環境。

架構限制

SentencePiece 詞彙表加速比僅為 7–22 倍；WordPiece 架構（BERT、RoBERTa 等）目前完全不支援。

三億人的健康顧問正式開業，但付費牆把醫療建議品質切成了兩個世界

功能全貌：醫療記錄串接與 Apple Health 整合

OpenAI 於 2026 年 7 月 23 日正式向美國全體成年用戶推出「Health in ChatGPT」，這是繼 2026 年 1 月試點後的全面重啟版本。根據官方說明，此次整合覆蓋 Apple Health(iPhone) 、醫院系統（Epic、Oracle Health）、One Medical、Function Health，以及 MyFitnessPal 等健康平台，所有資料連接均需用戶主動授權。

名詞解釋
Epic：美國最大的電子健康記錄 (EHR) 系統供應商，覆蓋全美超過 70% 的住院患者資料，是醫療資料整合的關鍵樞紐。

功能設計的核心在於「健康背景資訊融入所有對話」——根據 OpenAI 官方說明，ChatGPT 在幫你選餐廳時會考量飲食限制，在規劃週末活動時會注意你最近的運動傷害。這意味著健康資訊不只是醫療問答的輸入，而是成為整個對話體驗的隱形背景層，而非僅限於獨立的健康模組。

付費牆爭議：免費版用戶的健康建議真的比較差？

OpenAI 為不同訂閱方案部署了不同模型：免費用戶的健康建議由 GPT-5.5 Instant 提供，付費訂閱者則使用旗艦模型 GPT-5.6 Sol。The Decoder 的分析直接點出核心問題：在 OpenAI 自家 HealthBench Professional 基準測試上，兩者差距相當顯著。

付費版的完整性 (Completeness) 達 88.0%，免費版僅 53.2%；健康決策有用性 (Health Decision Helpfulness) 付費版 83.0%，免費版 50.8%——即免費版的醫療建議品質接近付費版的六成。

OpenAI 以「兩種模型均優於醫師書面回答」為雙層制辯護，但獨立研究指出 AI 聊天機器人存在危險的過度自信問題：會在不承認不確定性的情況下提供錯誤醫療結論，而這恰恰是人類醫師通常做得更好的地方。

名詞解釋
HealthBench Professional：OpenAI 自行設計的醫療問答基準測試，以醫師書面回答作為對照基線，評估健康建議的完整性與決策有用性。

三億用戶的健康數據：隱私與倫理挑戰

全球每週已有超過 3 億 ChatGPT 用戶詢問健康相關問題，Health in ChatGPT 的推出意味著這個早已存在的使用場景正式建立了資料整合管道。OpenAI 承諾所有對話均以靜態與傳輸加密儲存，連接的健康資料額外享有強化加密，且不會用於基礎模型訓練或廣告定向。

然而，一個關鍵隱憂在於健康資訊成為「所有對話」背景脈絡的這一設計決策本身。使用者可能在無意識的情況下，讓私人健康資料影響餐廳推薦、旅行建議等日常決策——個資的流動邊界從單次醫療問答擴散為持續性背景注入。

功能全面上線的同一週，OpenAI 面對兩起重大訴訟：一名 19 歲青年依照 ChatGPT 建議混用 Xanax 與 Kratom 後身亡；一名佛羅里達州牧師因 ChatGPT 建議延誤肺栓塞治療。兩起訴訟均要求暫停 Health 功能，顯示法律風險正在快速積累。

AI 醫療應用的監管前景與產業影響

Health in ChatGPT 目前在歐洲、歐洲經濟區 (EEA) 、瑞士與英國均無法使用。歐盟更嚴格的資料隱私規定，以及該功能可能被 EU AI Act 列為高風險 AI 系統，是主要阻礙；美國市場本身也因訴訟而面臨監管壓力，未來是否需要 FDA 等機構介入審查仍是未定之數。

名詞解釋
EU AI Act：歐盟《人工智慧法》，將 AI 系統按風險分級管理，「高風險」類別（包含醫療診斷輔助）須通過嚴格合規審查方可上市。

從產業格局看，Epic 等傳統 EHR 系統在此次整合中佔據關鍵地位，但 HN 社群的實際使用反饋顯示，既有玩家有強烈誘因讓整合過程盡可能麻煩，以保護自身的中介地位。ChatGPT Health 若要實現真正的個人化醫療助理願景，必須跨越技術整合與監管合規的雙重高牆。

Health in ChatGPT 的技術架構並非單純的「AI 問答 + 健康資料」疊加，而是一個多層整合系統，核心挑戰在於如何在隱私保護與個人化之間取得平衡。

環境需求

目前 Health in ChatGPT 以 SaaS 整合方式提供，開發者無法直接取用用戶健康資料的 API——整合層封裝在 ChatGPT 前端。若要在自有應用中實現類似功能，需自行與 Apple HealthKit、Epic FHIR API 或 SMART on FHIR 標準對接，並完成 HIPAA BAA 簽署。

遷移／整合步驟

若企業評估是否自建健康資料 LLM 整合，建議路徑如下：

1. 確認資料來源是否支援 FHIR R4 標準（Epic、Cerner 等主流 EHR 均已支援）
2. 申請 Epic App Orchard 或對應平台的開發者認證，完成 HIPAA BAA 簽署
3. 使用 SMART on FHIR OAuth 2.0 流程取得用戶授權
4. 將健康摘要以結構化格式注入 LLM 系統提示，避免原始 FHIR JSON 直接傳入

驗測規劃

醫療 AI 整合的驗測需同時覆蓋功能正確性與安全邊界：確認模型是否在不確定時明確提示「請諮詢醫師」，以及是否在敏感藥物交互問題上拒絕給出劑量建議。

常見陷阱

• Epic 等 EHR 系統在 OAuth 授權流程上可能設置額外障礙，實際整合體驗遠比規格文件描述複雜
• 健康資料作為系統提示背景層會大幅增加每次對話的 token 消耗，需評估成本影響
• HIPAA 合規要求所有健康資料傳輸和儲存均需加密，且 LLM 供應商需簽署 BAA 才能處理 PHI

上線檢核清單

• 觀測：監控含健康背景的對話是否觸發更高的拒絕率或免責聲明頻率
• 成本：健康摘要 token 注入造成的 API 費用增幅估算（每次對話可能增加 500-2000 tokens）
• 風險：確認 LLM 供應商的 BAA 條款是否涵蓋此用途，確認資料不用於模型訓練

競爭版圖

• 直接競品：Google Health AI（整合 Fitbit + Gemini）、Amazon Alexa Health、Apple Health 原生智慧建議
• 間接競品：傳統遠距醫療平台（Teladoc、MDLive）、電子健康記錄廠商（Epic、Cerner）的患者入口網站

護城河類型

• 數據護城河：3 億週活用戶的健康詢問行為資料，即使不用於訓練，也構成龐大的使用場景理解基礎
• 整合護城河：與 Epic、Apple Health 的官方整合認證具有相當的准入門檻，競品難以快速複製

定價策略

OpenAI 將健康功能作為全訂閱方案的標配，但透過模型差異化實質創造了「健康 Pro」的付費理由。在醫療建議品質存在 35 個百分點差距的情況下，Plus／Pro 訂閱對有健康管理需求的用戶具有強烈升級誘因。

企業導入阻力

• HIPAA 合規要求與 BAA 簽署流程繁瑣，醫療機構採購週期長
• 兩起死亡相關訴訟增加法務部門的採購顧慮，企業風險評估門檻提高
• Epic 等既有 EHR 廠商有強烈動機阻礙整合流暢度，以保護自身市場中介地位

第二序影響

• 若 ChatGPT Health 規模化成功，將對遠距醫療平台造成結構性衝擊——用戶有誘因先在 ChatGPT 完成症狀初篩，再決定是否就診
• 醫療資料整合成功也可能加速 OpenAI 進入醫療保險定價、健康管理合約等上游市場

判決：先觀望（訴訟與監管風險未釐清前，企業部署風險過高）

消費者端可試用功能評估個人化品質，但企業端在 FDA 監管立場明確、HIPAA BAA 條款更新及兩起死亡訴訟判決出爐前，建議暫緩大規模部署。

HealthBench Professional 基準測試結果

OpenAI 使用自家設計的 HealthBench Professional 測試兩個模型，以醫師書面回答作為對照基線。

兩個模型在 HealthBench Professional 均宣稱優於醫師書面回答，但獨立研究對此持保留態度。AI 聊天機器人在不確定時往往仍以自信口吻回答，而人類醫師在同等不確定性下通常會明確表示「需要進一步檢查」——這個維度並未納入基準測試。