軌道運算需要一把衡量「按時交付工作」的尺

2026年10月30日，Google公布Suncatcher在軌原型首次傳回AI回應。衛星於10月1日發射；回應發生在公告當週，未披露具體日期。Google公告

跟著一項任務，直到結果回來

Open Market Notes分析。 軌道運算接下來值得討論的問題，是如何定義一項工作已經完成。以下提出評估框架，不是對Google實際系統的描述，也不代表其商業效能已經得到證明。

使用者經歷的是一條完整鏈路：提交輸入、等待接收、執行運算、傳回輸出，再判斷輸出是否合格。只替處理器計時，會把這條鏈路的相當一部分排除在測量之外。技術上正確的結果，也可能在相關決策結束之後才到達。反過來，一項明天才需要完成的歸檔任務，可能完全能夠接受較長等待。什麼算有用容量，取決於服務承諾了什麼。

因此，較實用的比較單位，是在明確截止時間內交付、並達到約定品質門檻的合格結果。分母應包含所有已經接收的獨立任務，包括過期、失敗或需要重試的任務；執行嘗試次數另行統計。否則，只展示成功傳回的案例，就能讓表面成功率變得好看。被拒絕的請求也應單獨披露：控制接入量可以保護可靠性，卻同時減少真正得到服務的需求。

這樣的定義並非要求研究實驗立即達到正式營運的服務標準，而是讓前後實驗能夠比較。一條成功路徑回答一個較窄的問題；重複執行、並公開等待時間的任務，可以回答更寬的問題。兩種觀察都不應被悄悄升級為持續可用的證據。

把等待寫進任務設計

NASA對延遲容忍網路的解釋是：鏈路中斷時先儲存資料，待具備條件後再轉送。這是一般通訊背景，並不能證明Suncatcher選用了該協定。NASA說明

我們的推論是，應用的截止時間應與運算任務一起設計。設想兩類客戶：一類希望在夜間完成一批固定資料的分類；另一類必須在立即採取行動之前獲得答案。即使模型執行時間相同，兩者得到的服務也不等價。前者可能接受排隊和約定時間取回結果，後者則可能需要在軌道結果傳回之前啟用地面備援方案。這個假設例子不包含任何效能或延遲預測。

資料來自哪裡、有多大，也會改變比較方式。如果輸入首先需要上傳，傳輸就是使用者購買的服務的一部分。如果資料已經位於處理器附近，問題就可能變成：傳回篩選後的發現，還是把底層資料傳回地面處理。這裡討論的是有條件的設計選擇，並未斷言哪條路徑更便宜，也不聲稱某個任務已經採用它。

減少傳輸位元組還可能帶來驗證負擔。簡短答案只有在接收者能夠判斷其是否適合任務時才有價值。因此，試驗可以保留輸入樣本，記錄模型及軟體版本，並將部分輸出與事先約定的參照結果比較。這些是我們建議的控制措施，不應被寫成該專案已經展示的功能。

恢復過程需要記帳，同一任務不要算兩遍

重試應有單獨的紀錄。輸出遲遲未到，客戶可能再次提交，也可能把工作轉移到其他地方。兩次執行都消耗資源，但客戶仍然只是在解決同一個問題。有用的報告應區分獨立的合格結果與執行嘗試次數，並說明何時丟棄了遲到的重複結果。

備援路徑也有兩面性。它能改善客戶體驗，同時可能遮住軌道路徑本身的限制。這並不意味著不該使用備援方案，而是應分別報告組合服務表現和軌道部分的貢獻。否則，地面系統可能承擔了可靠性承諾，太空系統卻獲得了全部效能功勞。

公平的地面對照，應使用相同輸入、品質要求、截止時間和統計邊界，兩側都計入等待與恢復。把軌道加速器的執行時段與完整的地面流程比較，或反過來選擇邊界，都會製造醒目卻難以使用的數字。成本及能源比較還需要公開系統邊界；本文不進行這兩項計算。

下一份結果怎樣才更有資訊量

一個規模不大、說明清楚的工作負載，可能比規模更大卻不公開分母的展示更能幫助判斷。報告接收了多少任務、多少按時到達、最老的未完成任務等待了多久，以及中斷以後怎樣處理；同時披露完成時間的分布，而不是只給出有利的平均值。讀者才有機會判斷，這種等待對於某個具體應用是否足夠可預測。

不同解釋都需要保留空間。有些任務可能容忍很長等待；另一些任務需要的連續性，可能無法由這種架構經濟地提供。早期實驗無法一次解決這些差異。沒有公開服務等級紀錄，也不能反過來被當作失敗證據。更有建設性的標準是：每次新測試，都讓人更容易辨認哪些工作能可靠地交付有用結果，並把剩餘的不確定性擺在明處。