交易公司如何當天就上線新 AI 模型——專訪 Optiver 的 Noyan Tokgozoglu

Optiver 是造市商，其 AI 工程主管 Noyan Tokgozoglu 主張，交易公司每天結算損益（P&L）的做法，迫使它採取與消費科技公司截然不同的 AI 策略：模型必須在數小時內完成評測、部署與成本控管，而不是以季為單位。本集內容涵蓋 Optiver 的地端 AI 平臺、當日完成模型上線的流程，以及 2026 年夏季前沿模型發布後，Token 支出如何被重新壓回可控範圍的詳細過程。標題所稱的「當日上線」確實不假，但只佔了幾分鐘；本集大部分時間談的是平臺架構、評測與成本最佳化。

Tokgozoglu 的視角來自一家以自有資金交易、沒有客戶、每天處理數 PB 資料、為超過一百萬種金融商品報價的公司。他先前任職於 Apple，並以那段經歷作為回饋迴圈緩慢的對照案例。讀者讀完應該能具體掌握：在受監管、地端部署、對損益高度敏感的環境裡跑前沿模型需要哪些條件，以及 Optiver 用了哪些具體手段削減 Token 浪費、同時不減少使用量。

每日損益結算，讓回饋迴圈縮短到數小時而非數季

在消費科技公司，改動推給使用者後，互動指標要花數天到數週才累積出來，營收或顧客終身價值則要數月到數季才顯現。在 Optiver，每天一開始資產負債表就歸零，收盤時讀當日損益。交易員和量化研究員「幾乎是幾小時內」就能看到平臺改動的影響。

這樣的速度是兩面刃。錯過機會的代價很高——Tokgozoglu 舉的例子是假設市場發生重大事件（他說「像 SpaceX AI 掛牌之類的」），而公司沒能交易到。這造就一種要求快速決策、有效衡量與「行動優先」的文化。他也從經濟結構上做了區分：像 Spotify 這種以注意力為基礎的生意，爭奪的是有限的顧客注意力；造市商則是交易越多、賺得越多。

「每天一開始，我們基本上把資產負債表歸零，然後到收盤時看我們賺了多少錢。」

他給出的規模數字：每天超過一千萬筆交易、為超過一百萬種商品報價、每天處理數 PB 資料、全球超過十個據點。

平臺分層建構，不讓任何單一供應商決定節奏

Optiver 的技術堆疊完全地端部署——自有 GPU 與基礎設施——因為這是高度監管的產業，且公司非常重視自家 IP。唯一離開自家伺服器的流量是第三方模型推論，且受零資料保留協議約束。Tokgozoglu 說公司上下都在用 AI，只是每個人用法略有不同。

他由下而上描述的架構如下：

flowchart TD
    A["第三方模型供應商"] --> D["推論閘道"]
    B["自架與開源模型"] --> D
    D --> E["代理平臺：技能、外掛、工具、記憶"]
    E --> F["代理閘道：單一帳本、身分、編排"]
    F --> G["使用介面：網頁入口、代理工作臺、個人助理、Slack"]
    D --> H["日誌與評測系統"]

推論閘道負責在供應商之間路由、追蹤各模型的支出、分配預算，並提供容錯——若某家供應商掛掉，流量就切到另一家，因為停機就等於不能交易、沒有營收。代理平臺註冊各項能力，以及各團隊的知識與記憶。代理閘道是全公司每一個代理的單一帳本，負責通訊、人與代理的編排，以及共用身分管理——這是群體式多代理協作的基礎。最上層是使用者介面：供工作階段使用的網頁介面、可讓團隊共用的人設管理「代理工作臺」，以及人人可用的個人助理。

新前沿模型以內部黃金測試集評測，當天就能進生產環境

他們的原則是：新的前沿模型一旦公開發布，Optiver 就要它當天就能用在生產流程中——但前提是它真的有用。這需要成熟的評測框架與內部基準，因為外部基準的資料分佈與 Optiver 自身不同。公司與關鍵交易團隊合作，蒐集他們的基準並納入平臺，任何新模型一齣來就立刻對這些測試集跑一輪，並在內部傳閱指標結果。

模型上線不只是呼叫一次 API。模型必須以正確的介面加入閘道、做好成本管理，而測試框架（harness）往往也需要更新。這些更新與交付也由 Optiver 自己處理。由於公司據點遍佈全球，AI 工程團隊分割槽輪班提供全天候支援，以維持高可用性。溝通也是流程的一部分：團隊會告訴全公司他們測了什麼、效果如何、怎麼用，以及他們的建議。

模型與測試框架的中立性是設計上的硬性要求，背後原因包括區域與雲端供應商的可用性、有些工作負載必須跑在完全隔離的地端 DMZ 區，以及成本考量。每一次模型互動都會被記錄，並自動送進評測系統。Optiver 支援多種測試框架，並在其上跑一層「meta harness」，讓團隊能設定自己的使用體驗，並在不同框架之間移植。這些設定會接上團隊知識庫，而知識庫會隨著時間從追蹤紀錄中自動蒐集。

Token 支出隨 2026 年夏季模型發布暴增，再靠單次工作階段層級的修正壓回

Tokgozoglu 展示了一張示意圖（未標示單位）說明 AI 支出。支出在十二月他所稱的「Claude Code 時刻」上升——那正是他加入公司的時間點，他開玩笑說兩者未必有關——接著在 2026 年夏季幾款大型前沿模型發布時急速飆高。之後透過各種最佳化，支出被重新壓回可控範圍。

根本問題在於自助式使用卻沒有好的預設值：新工作階段一開就是 20 萬 Token 以上的上下文，有時甚至以此為下限，因為大家把所有東西都往裡塞。修正手段如下：

他強調，這些節省會隨 Token 單價放大——Token 越貴，最佳化省下的越多。他也提到，自己還沒細談模型路由或子代理最佳化；上述全都只是單次工作階段層級的調整。可視性那一點讓他很意外：當團隊能看到自己的支出、自行設定警示與上限時，很多人自己就設了合理的上限。

「幾乎總是有價值留在桌上沒拿。我們正毫不留情地朝那個方向最佳化。」

這個框架並不是要緊縮：Optiver 仍在投資大量使用 Token，目標是讓同樣的 Token 產出更高的投資報酬。

高自主性的使用者會自己造工具，所以 Optiver 直接做更好的版本

在這場演講前幾個月，員工各自搞自己的做法——用 tmux 連進開發機、拼湊克難的網頁介面、用各式各樣的測試框架。Optiver 沒有禁止，而是把大家已經在做的事做成精緻版本，開放給全公司：工作階段管理、聊天視窗、產出物（artifacts）。Tokgozoglu 承認測試框架廠商也有類似產品，但自家版本更貼合 Optiver 的基礎設施，迭代速度也符合公司想要的水準。

這個內部工具後來變成協作成果。交易員現在會貢獻程式碼——他們發現某個對自己工作流程有用的東西就送 pull request，團隊再合併進去。協作式檔案編輯這類功能就是這樣來的。下一步是「代理多人模式」：在同一個空間裡放入你的代理、同事的代理，以及已部署的代理，另外還有一個可隨身使用的 Slack 使用者端。

「我們的使用者自主性非常高。如果我們不幫他們做，他們就自己去做，所以我們乾脆做一個更好的版本。」

更宏觀的運作模式有三部分：模組化平臺、用來收束自助式混亂的良好預設值，以及前線部署——AI 工程師與交易員坐在一起，瞭解他們怎麼交易，教他們 AI 能在哪裡創造價值，再把心得帶回平臺。

自建勝過採購，因為供應商會拖慢路線圖

被問到為何 Optiver 要自建測試框架而不用 Codex，Tokgozoglu 給了三個理由。第一，多數商用工具在 Optiver 自家基礎設施裡都跑不好；Codex 直到最近才開始提供部署在客戶基礎設施上的託管代理，而 Optiver 一直與該廠商合作推進這件事。第二，供應商會試圖把客戶綁在他們的模型或整套技術堆疊上，過度押注單一供應商就等於只能跟著對方的速度走。他具體提到與前一家推論閘道供應商的經驗：Optiver 需要一項新功能，對方要他們去跟 GTM 團隊談、排進路線圖，他們得出的結論是自己必須走得比那更快。第三，他聲稱 Optiver 一直走在前面——是前沿實驗室來問 Optiver 怎麼做出託管代理能力，而不是反過來。

他謹慎表示這套做法不適用於所有人，並歸功於「一連串獨特條件的組合」。

評測才是難題，因為工具呼叫依賴的世界狀態未必能重現

每一次工具呼叫、輸入與輸出都會透過 OTEL 記錄下來，送進評測系統。未解的問題是：當代理的工具依賴原始執行當下的世界狀態時，要如何用不同模型重跑。Optiver 的 Slack 客服機器人代理就是例子：要重跑它，就得知道當時的 Slack 長什麼樣子。

他們的做法是為每一次工具呼叫能多精確地對應到某個時間點，給一個信心值。交易回測資料庫很容易——逐時點重現（point-in-time replay）在那是標準做法。其他系統就不是了，Optiver 在 MCP 外面包一層代理來提供快照，Tokgozoglu 說這並不完美。除了把一切都錄下來，他看不到完美的解法。

代理範圍蔓延要靠編排解決，而不是把單一代理養肥

當兩個團隊想讓各自的代理協作，最直覺的解法——做一個涵蓋兩團隊所有功能的代理——會累積技術債、效能也差，尤其當它要用不同驗證方式 checkout 多個 repo 時更是如此。代理是有版本控管的，所以小幅增量可以作為帶新功能的新版本發布。但更受偏好的模式是代理閘道：把每個代理的範圍限定在它做得好、且能被衡量的任務上，管理它的生命週期，讓它透過單一帳本與其他代理溝通，需要時互相啟動。這就把問題轉變成多代理編排。讓代理保持可衡量很重要，因為一個臃腫的代理可能某些功能變好、另一些功能退步，卻沒辦法分開調校。

值得持續關注的收尾矛盾是知識與記憶管理。Tokgozoglu 說市面上沒有任何方案讓他滿意。他指出，有些前沿實驗室建議用龐大的階層式 markdown 檔案，向量搜尋也有自身的取捨，而 Optiver 採混合做法來探索各種選項。他想花更多時間研究圖資料庫，並說他每天在 Twitter 上都看到新的記憶技術。同樣的不滿也適用於評測：非資料庫系統的逐時點重現仍未解，Optiver 的答案是給一個信心分數，而不是真正修好。這兩類問題都會隨著越來越多代理接觸越來越多有狀態系統而變得更難，而不是更簡單。