同一件事——把一段繞著房間走的影片，變成一團浮在空間裡的 3D 點雲——以前跟現在的做法，差得不只是快一點。

以前的標準流程長這樣：先把影片拆成幾百張照片，丟給 COLMAP 這種工具，讓它兩兩比對特徵點、算出每張照片的相機在哪、再三角測量出每個點的深度。這是一個迭代優化問題，所有照片要同時在桌上攤開，反覆調整到誤差收斂為止。場景大一點，等個幾分鐘到幾小時是常態。NeRF、Gaussian Splatting 那一掛更不用說，先收料、再訓練、最後才有得看。

關鍵字是「等到完」。資料要收齊，運算才開始；運算要跑完，你才看得到第一個點。

LingBot-Map 這個 Robbyant Team 開的模型（GitHub 上五千三百多顆星），把這件事的時間軸整個調換了。你拿手機錄走廊，它邊錄邊吐點雲，第一幀進去就有東西出來，速度大概 20 FPS。差別不是「同一套算法跑快十倍」，而是它根本沒在解原本那個優化問題。

把「攤開一桌照片」換成「一幀一幀餵進去」

先看舊做法為什麼慢。COLMAP 慢在它是全域的——第 300 張照片的結果會回頭影響第 1 張的相機估計，所有東西互相牽連，所以得反覆迭代。這是它準的原因，也是它慢的原因。

LingBot-Map 走的是另一條路：一個純前饋（feed-forward）的 Transformer。沒有迭代、沒有來回優化，畫面進去，答案出來，一次到位。這裡的取捨很 ML 味——用一個夠大的網路，把「該怎麼從畫面推回幾何」這件事，在訓練階段一次學進權重裡，推理時就不必再臨場算了。

底層接的是 Meta 的 DINOv2 ViT-Large，一個預訓練好的視覺 Transformer，負責把每一幀畫面壓成一串特徵向量。上面再疊一層自己設計的 Geometric Context Transformer（GCT）。推理流程拆開來看其實很乾淨：

影片幀 → DINOv2 抽特徵 → Frame Blocks（每一幀內部先做 self-attention，搞懂這一幀自己的結構）→ Global Blocks（跨幀做 causal attention，把這一幀跟前面看過的接起來）→ 最後三個 Head 各管一件事，分別吐出相機姿態、深度圖、還有世界座標下的 3D 點雲。

注意那個 causal attention。它的意思是：第 N 幀只能看第 1 到 N 幀，看不到未來。這跟 LLM 生成文字時「只能看前文」是同一個機制。LingBot-Map 等於是把 3D 重建，重寫成了一個「自迴歸」的問題——下一幀的幾何，是條件在前面所有幀之上預測出來的。

串流推理的真正難關，是記憶體不是速度

到這裡有個會卡住所有人的問題：既然每一幀都要參考前面所有幀，那影片越錄越長，要回頭看的歷史不就越堆越多？錄個十分鐘幾萬幀，全塞進記憶體早就爆了。

這就是 LingBot-Map 最像 LLM 的地方——它直接搬了 LLM 推理那套 KV Cache。

打個比方。你在跟人講一段很長的話，不會每講一句就把前面所有句子從頭重念一遍再決定下一句；你腦袋裡留著一份「前面講到哪、重點是什麼」的摘要，講新句子時只查這份摘要。KV Cache 就是這份摘要——前面每一幀算過的 key/value 存起來，新的一幀進來不用重算歷史，只要拿自己去查那份快取。它用的是 Paged KV Cache（基於 FlashInfer），分頁式管理，跟作業系統用分頁管記憶體是同個思路，不必把整段影片一次攤在 VRAM 裡。

光有快取還不夠，串流久了還有兩個老毛病：座標系會慢慢飄、誤差會一路累積。GCT 為此補了幾個零件——Anchor Context 釘住一個座標定錨點，不讓整個世界隨時間漂走；Trajectory Memory 記住長距離的軌跡，回頭修正累積的偏差。最有意思的是它撐得住 Loop Closure，就是你繞一圈走回原點時，模型認得出「這是我來過的地方」，把頭尾接起來——這在傳統 SLAM 裡是出了名難搞的一關。

機制拆到這，它能拿來幹嘛就幾乎是自動浮出來的，不用人去硬想。

拆完原理，用途自己長出來

最直覺的用法：拿手機繞房間或建築物錄一圈，自動生點雲。專案 demo 裡有法院、大學校園那種場景，手機影片就出片，不必扛專業 LiDAR。對房地產虛擬導覽、建築建模，這個成本差距是有感的。

但真正只有串流架構吃得下的，是那些「資料根本不會錄完」的場景。自動駕駛、機器人——相機影像是源源不絕進來的，你不可能說「等它跑完這趟我再來重建」。邊走邊建模，本來就是這類 SLAM-like 應用的硬需求，而 LingBot-Map 的因果式逐幀推理天生長這個樣子。它也能啃十三分鐘、約兩萬五千幀的室內走訪影片，靠的是 windowed mode 加 keyframe 策略，把記憶體壓在可用範圍——一般重建方法碰到這種長度，多半在開始算之前就先 OOM 了。

當然，講完漂亮的別忘了門票。這模型胃口不小：GPU 至少要 16 GB VRAM（RTX 4080 等級），24 GB 以上才舒服，8 GB 的筆電卡（像 RTX 4060 Laptop）確認跑不動，連 RTX 5090 目前配 FlashInfer 都還會 crash。還有個容易被名字騙到的點——它叫「串流」，但官方的 demo.py 其實會一次把整段影片的幀全載進記憶體，所以真‧即時串流要自己接資料流，現成腳本給的是「架構支援串流」不是「開箱即用的即時管線」。弱紋理場景（光禿禿的牆、天花板）效果也不好，只吃單相機，Mac 的 MPS／MLX 推理 PR 還沒合併。挑工具的時候，這些邊界比那個 20 FPS 重要得多。

回到最前面那個對照。從 COLMAP 到 LingBot-Map，表面上是「離線變即時、慢變快」，但底下換掉的是一個更根本的東西：把一個「所有資料必須同時在場、反覆優化到收斂」的全域問題，重寫成一個「資料一筆一筆來、看一眼就給一個答案、靠快取記住過去」的串流問題。這個轉寫一旦成立，後面所有好處——即時、吃得下超長序列、適合機器人——都是順帶長出來的，不是另外加的功能。

而這套「把離線批次問題重寫成串流自迴歸問題」的招式，眼熟嗎？語音合成正在這樣搬，影片生成也在這樣搬。下次再看到某個領域還在「等資料收完才能算」，可以先問一句：這題有沒有辦法改成一幀一幀地問？答得出來的，往往就是下一個被重寫的對象。

專案連結：Robbyant/lingbot-map（Apache 2.0）　模型：robbyant/lingbot-map　論文：Geometric Context Transformer for Streaming 3D Reconstruction（arXiv:2604.14141, 2026）