DeepSeek 開源 DeepInfer 推理引擎，單集羣每日處理量報稱達 155T tokens
[AINews] DeepSeek DeepInfer: Open Source SOTA Inference running 155T toks/day/cluster making $22m/day at ~80% margin for a 81 day payback
DeepSeek 開源為 V4.1 Flash 提供推理服務的 DeepInfer，並披露單一集羣每日處理 155T tokens，輸入快取命中率為 96%。報道指出，該處理量包含快取命中，不能等同全新計算量；KV-cache 管理及負載平衡等服務層組件尚未完整公開。
內容將 DeepSeek 公佈的吞吐與每卡時收入，連同 96% 輸入快取命中及未完整公開的服務組件一併梳理，説明這些數字的適用邊界。
譯文尚不完整，完整內容請切換到原文。
由 SerpApi 隆重呈獻：今天的發布涵蓋大量內容，不過你可以把所有內容擷取成 Markdown，供你的 Agent 使用！token 用量只有 JSON 的 50%。
我們上次在4 月談到推理轉折，而過往大部分進展都來自閉源十角獸企業，從Fireworks 到 Baseten，再到Modal。
現在輪到開源陣營回應。今天是PyTorch Conf的第一天，DeepSeek 將一枚洲際彈道導彈射入這場討論，宣佈開源其生產堆疊DeepInfer。這套堆疊可支援長達 72 小時的提示詞快取；OpenAI 剛宣佈的則是12 小時：
這是他們對 vLLM 的客製化版本，並向 SGLang 和 TRRTLLM 致謝，但也新增了不少內容……唯獨未包括他們的核心技術——他們極致優化的 KV 快取（精簡 + >8hour 使用期限）、PD／分離，以及負載平衡（他們的3FS早前已開源）。我們已翻譯他們的網誌文章並在此發佈，另附完整的研究指南、解説文章、程式碼地圖和子系統指南：
正如我們在他們的補充披露中指出，他們聲稱每日提供 155T 個 token，這可讓每張 SM100/A950 卡每小時帶來 $38——這是按離峯價格計算（目前每百萬個輸入／輸出 token 的價格分別為 $0.15/$0.60：155000000 個 token * $0.14 混合成本 / 24 小時，約為每小時 $1m）。以他們的生產數據（我們已翻譯）計算，每部 prefill GPU 每秒處理 1.5 million 個計入快取的輸入 token，輸入快取命中率為 96%；每部 decode GPU 每秒處理 14,000 個輸出 token（涉及 ~2400 部 GPU）：
全包成本為每張卡每小時 $5-8，推理利潤率超過 80%！
根據叢集數據估算，這相當於每 GW 約 $166B，按推理利潤計算的回本期為 81 日（DeepSeek 著名的目標是 10 個月回本）。想像一下 Whale 有更多 GWs 時能做到甚麼。
SerpApi 贊助：
以更少 token 為 AI Agent 提供即時搜尋數據
使用SerpApi 旗下 100 多個 API，接收整潔、結構化的 Markdown 格式結果，平均比 JSON 少用約 50% token。只需加入 output=md，或使用 /search.md 端點。無需任何設定，而且所有方案均已包含這項功能，不另收費。
AI News（10/19/2026-10/20/2026）。我們檢視了 12 個 subreddit、544 個 Twitter 帳號，沒有查看其他 Discord。AINews 網站讓你搜尋所有過往期刊。提醒一下，AINews 現已成為 Latent Space 的一個版塊。你可以選擇訂閲或取消訂閲不同頻率的電郵！
AI Twitter 摘要
焦點新聞：DeepSeek DeepInfer——生產環境推理、開源界線與快取 Token 的經濟效益
發生了甚麼
DeepSeek 發佈了 DeepInfer——V4.1 Flash 背後的推理引擎，同時公佈生產環境服務的細節，令這份工程報告與程式碼同樣重要。
此版本涵蓋推理引擎和 API 處理層。 DeepInfer 支援分散式推理、推測解碼、SWA Bounded Replay，以及在 NVIDIA 和 Huawei Ascend 平台上輸出結構化內容。配套的 deepseek-recipe 元件負責在正式環境中進行 token 編碼／解碼，以及相容於官方 API 的處理。DeepSeek 表示，未來的模型推理實作和最佳化也會在此程式碼儲存庫中發布。@deepseek_ai、@deepseek_ai、公告翻譯
報告中的正式環境數據相當可觀，但描述的是一項大量使用快取的服務。 DeepSeek 的工程報告（如所提供貼文中的摘要和引述所述）指出，單一叢集每日處理 155 萬億個 token、輸入快取命中率為 96%、首個 token 的平均等待時間為 400 ms，以及生成速度為每秒 230 個 token，而編碼時可達每秒 300 個 token。報告亦指出，按非繁忙時段價格計算，每加速器小時的收入為 $38。這些是 DeepSeek 自行公佈的正式環境數據，並非經獨立審核的測量結果。@ZhihuFrontier、@swyx
「完全開源」不代表單憑此版本便能重現整個正式環境服務。 雖然 DeepSeek 形容 DeepInfer 為完全開源，但技術説明指出，KV-cache 管理和負載平衡元件尚未完全發布，因為它們仍與內部基礎設施緊密結合。引擎已開源；重要的服務層級協調工作仍須由部署方負責。@deepseek_ai、@ZhihuFrontier
vLLM 提出了最具體的比較回應。 vLLM 團隊承認 DeepInfer 最初主要以 vLLM 為基礎開發，並以 Apache 2.0 授權發布後，表示在相同配置下，GB200 的解碼吞吐量與 DeepInfer 公佈的結果相差不超過 6%。團隊亦發布了 AgentX 結果和重現測試的配方，實質修正了「現有開源引擎無法達到 DeepSeek 效率」的説法。@vllm_project、@vllm_project、重現測試資源
此版本引發了兩場不同的討論：DeepSeek 是否擁有獨特而強大的服務堆疊，以及其披露的資料是否能普遍證明推理具有高盈利能力。前者現已有比較基準測試數據；後者仍取決於工作負載組合、快取計算方式、硬件成本，以及計入哪些開支。@Tim_Dettmers、@zephyr_z9、@Yuchenj_UW
架構：分開各個階段，按計算而非 token 排程
DeepInfer 公開的架構將視覺編碼、預填充和解碼分開，讓各階段按自身的瓶頸擴展。建議的部署配置是：預填充使用一般配備八個加速器的機器，解碼則使用配備 64–128 個加速器的超級節點。解碼會採用大規模專家平行處理來分配 MoE 專家，同時維持較大的有效批次。這些是部署建議，並不足以證明 DeepSeek 正式環境叢集的確切硬件組成。@ZhihuFrontier
排程細節説明瞭，為何傳統的「每批次 token 數量」比較可能忽略重大差異：
預填排程會估算注意力運算成本。工作會按估算的運算量分配，而不只是根據原始請求長度。分塊大小會調整以配合時間預算，而不是對不同請求一律採用固定分塊大小。@ZhihuFrontier
預填路由不需要快取親和性。由於快取前綴集中存放於共享儲存空間，請求可派往可用的工作節點，而非先前處理其前綴的工作節點。在一篇詳細的中文分析中，推理工程師 Su Jin Yan 指出，這是特別實用的生產環境設計：預填資料並行組按「計算 token」平衡負載，而共享儲存空間則提供可重用狀態。同一分析亦指出，系統採用請求分桶，以及配合執行時估算器的 FIFO 排程。@SuJinYan123
解碼路由會同時平衡正在執行的請求數和 KV 快取長度。請求數可大致反映排程壓力；累積 KV 長度則反映記憶體及狀態壓力，彌補單看請求數的不足。工程評論指出，預填的擴展訊號是整體運算負載，而解碼的擴展訊號則是正在執行的請求數。@ZhihuFrontier、@SuJinYan123
專家並行負載平衡會複製熱門專家。系統會定期重新分配副本，以減少路由偏斜造成的裝置間等待。這種做法需要在額外消耗 HBM 與提高吞吐量之間取捨；隨着副本數增加，效益會遞減。合適的複製因子視乎工作負載而定。@ZhihuFrontier、@SuJinYan123
CPU 排程會與加速器執行重疊。非同步排程可消除解碼步驟之間的閒置間隙，而不是把主機端協調工作當作沒有成本。@ZhihuFrontier
一項值得注意的技術觀察是，公開的 Blackwell 配置似乎沒有採用張量並行。一位評論者將此與 vLLM/SGLang 的預設方案作比較，並把這種做法追溯至 DeepSeek V3 在 H800 時代面對的互連限制。這是對該配置的解讀，並非張量並行普遍較差的證據。@nrehiew_
規模亦很重要。Su Jin Yan 認為，大規模專家並行預填需要足夠流量和工作節點才值得採用；對於預填工作節點只有少數的中小型部署，則較傾向採用管線並行。作者亦指出，各層之間的異質性可能令管線分區更複雜。這是從業者的判斷，並非確立普遍適用分界點的基準測試。@SuJinYan123
快取階層：持久化前綴及低成本重建暫態狀態
快取設計是連結吞吐量數字、Agent 工作負載，以及據報每個加速器收入的核心。
持久化區塊 KV 存放於獨立的 3FS 儲存叢集，該叢集具備約 100 PiB SSD 容量。據報，代理程式流量的保留時間為三天，聊天機械人流量則為七天。任何預填工作節點均可擷取快取前綴，令快取位置與運算部署位置分離，並讓儲存和運算可獨立擴展。@ZhihuFrontier
這種保留方式對反覆重新傳送不斷增長的指令、儲存庫內容、工具輸出及先前回應歷史的 Agent 很有用。這亦表示 每日服務 155T 個 token 不應解讀為每日新生成 155T 個 token：快取命中計入服務的 token 統計，而新計算的 prefill 與自回歸輸出所需成本則截然不同。因此，報稱 96% 的輸入快取命中率，是理解標題吞吐量的關鍵背景。@ZhihuFrontier、經濟工作負載假設
這項實作處理兩種不同的狀態生命週期：
持久區塊快取會以非同步方式載入。主機至裝置的傳輸會與層執行重疊。Su Jin Yan 指出一項較底層的實作細節：透過 CUDA copy engine 複製細粒度 KV 區塊時效能不佳，因此文中所述路徑採用 GDR/RDMA 傳輸，目標是在不佔用 SM 的情況下充分利用 PCIe 頻寬。這是根據報告得出的技術觀察，並非該則推文中另行測量的結果。@SuJinYan123
滑動視窗注意力狀態保留在主機記憶體，而非持久性 SSD 儲存空間。這種狀態主要在作用中的工作階段內有用，生命週期亦比可重用的區塊前綴短。@ZhihuFrontier
SWA Bounded Replay 只根據最近的 128 個 token 重建遺失的短期狀態。重播會將注意力限制在該片段，同時重用持久區塊快取，因此得到的是近似結果，而非根據完整的先前歷史重建狀態。DeepSeek 表示，這項做法令整體 prefill 計算量接近減半。考慮能否移植至其他架構時，這種近似方式及其對特定模型的適用性相當重要。@ZhihuFrontier
Su Jin Yan 另指出，較長的保留尾段只能額外增加約 0.5–1 個百分點的快取命中率，顯示儲存容量與重新計算之間存在取捨。同一評論亦指出，以解碼為主導的快取管理可讓生成的輸出在後續回合成為可重用的前綴狀態。@SuJinYan123
這個保留時長令人聯想到 OpenAI 另行公佈的 12 小時 API 提示詞快取，相較於其預設的 30 分鐘保留時長，亦支援在同一請求中混合不同保留時長。兩者並非相同產品或架構，但都面向會在長時間間隔後重用上下文的持續運作 Agent。資訊流其他地方有關登入狀態下無限期快取的説法屬評論，並非 API 公告所列條款。@OpenAIDevs、保留時長設定、比較評論
推測解碼、API 相容性與模型專屬最佳化
DSpark 令推測驗證具備適應性。它會預測草稿 token 的接受機率，並調整驗證長度，以最大化預期吞吐量。DeepSeek 表示，相較於一律驗證五個草稿 token，生產環境吞吐量提升了 6%。這是相對於特定推測解碼基準的增幅，並非相較於非推測解碼提升 6%。@ZhihuFrontier
deepseek-recipe處理的是服務介面，而不只是 tokenizer 速度。它支援 Chat Completions、Responses 和 Messages API，可平行處理 tokenization，並能區分真正的控制 token 與外觀相同、由用戶以文字輸入的字串。這種區分可防止用戶輸入的字面內容意外被解析為結構分隔符；但不應將此誤認為完整的提示詞注入防護。@ZhihuFrontier、@deepseek_ai
社羣的解釋將效率歸因於多項模型與執行時共同設計的選擇：196B Engram 參數、較小的 prefill 主幹網絡（每個 token 啟用約 8B 參數，decode 時則為 16B）、寬幅 EP、高度壓縮的 KV，以及推測解碼。文章還提到552B 專家參數、DP64/EP64、每個裝置約有 45B 常駐參數、權重大多為 4-bit，以及聲稱 KV 較 GQA 基準減少 400×。這些都是二手説法：文章沒有充分交代複製方式、共享權重、量化配置或 GQA 參照基準，因此無法獨立重現這些數字。尤其是，45B／裝置並非單純以 552B 除以 64 得出。@bookwormengr
模型特定性正是不能假設同樣的效能提升會自動套用到任意模型檢查點的原因之一。Su Jin Yan 認為按模型採用不同的程式碼庫／核心策略有其價值；Andrew Carr 則建議使用編碼 Agent 將實作調整至其他模型，但沒有提供可移植性或效能驗證。@SuJinYan123、@andrew_n_carr
獨立比較：vLLM 重現了甚麼，沒有重現甚麼
對「只有 DeepSeek 才能做到」這種説法，最有力的技術反證是 vLLM 的後續比較：
必須分清三點：
誤差在 6% 以內的結果指的是 decode 階段的效能相若，並非重現 DeepSeek 的整個服務。這並不能證明兩者在 100-PiB 快取操作、保留成本效益、路由、生產環境可用性，或 DeepSeek 流量分佈下的端到端延遲方面相若。
每 GPU 每秒 1M 個 token 的數字，不可能代表單一用戶的生成速度。同一篇文章另行報告了約 200 P90 輸出 TPS；比較這項吞吐量標題數字與純 decode 吞吐量前，必須先了解基準測試如何計算輸入、快取及輸出。
這項工作是外部實作比較，但仍是由競爭引擎團隊自行報告。公開的 InferenceX 結果及配方有助提升可重現性，但不代表每項所引用的生產環境數據都經過獨立審核。
開源發展脈絡十分清晰：vLLM 感謝 DeepSeek 以 Apache 2.0 授權發布程式碼並致謝，Woosuk Kwon 則形容 DeepSeek 是早期採用者及貢獻者。因此，DeepInfer 更適合理解為生產環境經驗迴流至現有生態系，而非一個完全獨立、取而代之的方案。@vllm_project、@woosuk_k
其他反應涵蓋了多種有參考價值的觀點：
強力背書：Tim Dettmers 認為，以用戶規模而言，DeepSeek 的推理技術架構可媲美 OpenAI，並勝過 Anthropic；Graham Neubig 則指出官方 API 的速度和價格具優勢。兩人均未提供同條件的跨實驗室基準測試。QuixiAI 表示，這次發布將為 SlimServe 提供參考。@Tim_Dettmers、@gneubig、@QuixiAI
對部署持懷疑態度：Su Jin Yan 認為，對有經驗的推理開發者而言，工程文章比程式碼庫更有參考價值，部分原因是有重要元件缺失。Finbarr Timbers 要求與 Modal、Together 和 vLLM 作比較；所提供的帖文中沒有與 Modal／Together 在相同條件下的比較。@SuJinYan123、@finbarrtimbers
一名原本十分熱情的評論者表示有保留的支持：Teortaxes 承認基礎設施並不齊全，並指出 3FS 加上可能採用的 Dynamo 或可彌補部分不足；他估計，要達到叢集規模的吞吐量，約需3,000–4,000 GB200s。這是建議的部署方案，並非已驗證的重現結果。@teortaxesTex
其後有人在程式碼庫中找到技術報告的官方英文版，因此不必再完全依賴社羣翻譯。@teortaxesTex
經濟效益：披露了可觀收入，但未完整交代利潤率
最重要的財務披露是按非繁忙時段價格計算，每加速器小時收入為 $38。收入不等於利潤，而加速器小時只是正式服務成本結構的一部分。@swyx
一項廣泛流傳的估算最初得出推理利潤率為 87.76–96.94%，其假設如下：
所有計費 token 中，97% 為快取輸入、2% 為未快取輸入、1% 為輸出；
每張 GPU 每秒處理 80K 個未快取輸入 token，以及每張 GPU 每秒處理 16K 個輸出 token；
每名用戶每秒輸出 250 個 token；
每 GPU 小時租金為 $3–$6。
以總計 10 億個計費 token 計算，該模型包含9.7 億個快取輸入 token、2,000 萬個未快取輸入 token及1,000 萬個輸出 token，所需時間約為875 GPU 秒：250 秒用於預填充，625 秒用於解碼。估算的 GPU 成本為$0.73–$1.46，對比之下，非繁忙時段收入為$11.91，繁忙時段收入則為$23.82。@zephyr_z9
作者其後修正估算：理想化情境推算的收入約為每小時 $49，而 DeepSeek 報告的數字是每小時 $38，即實際服務表現約為基準測試表現的 80%。修正後引用的利潤率範圍為84.2–96.1%。引用原本的估算時，不應忽略這項修正。@zephyr_z9
其他帖文採用較高的硬件成本：
以每小時 $7 的成本對比每小時 $38 的收入，計算結果約為81.6%，尚未計入其他成本。Yuchen Jin 特別指出，DeepSeek 沒有披露收入數字所對應的 GPU 型號。@Yuchenj_UW
以每小時 $5–$10 計算，同一個只計加速器成本的估算結果約為73.7–86.8%，而非得出一個普遍適用的「80% 服務利潤率」。@swyx
這些計算沒有計入或未有完整分攤SSD 快取設備羣、CPU、網絡、閒置／備用容量、故障、工程、支援及其他營運成本。計算亦建基於對快取有利的 token 組合。訓練開支和未來算力承諾則是另外的項目：推理業務即使有高貢獻毛利率，公司整體仍可能錄得巨額虧損。
較進取的推算明確屬推測。Teortaxes 估計，據稱的 $1B ARR，在非繁忙時段價格下，約需 42 個 GB200 NVL72 機櫃／約 3,000 張 GPU 支持；其後在納入繁忙時段價格後，將估算下調至 33 個機櫃。貼文亦推算，約 4,167 個機櫃可帶來 $100B 年收入，以及每吉瓦的高收入。這些都只是情境計算，並非經審計的 DeepSeek 收入、機羣規模或回本資料披露。初步估算、修訂估算、業界推算
各界對市場影響的看法不一。有人認為，這些披露顯示推理已跨過盈利門檻；也有人預期 token 價格下跌、算力價格上升，最終會壓縮回報。這對 Moonshot／Zhipu 託管協議可能造成的競爭影響雖然合理，但尚未量化：可公開部署的技術堆疊既可改善服務供應商的經濟效益，也會加劇價格競爭。@KCDN19、價格趨同論點、託管服務競爭
NVIDIA、Ascend 與硬件推理的限制
Ascend 相容性已獲確認，但 Ascend 在生產環境的效能是否相若，則尚未證實。數篇貼文將對 Blackwell 的支援、對 sm100 的支援，以及採用 NVL72 形態的配置，解讀為生產環境使用 NVIDIA 硬件的證據。這些只是線索，並非已披露的硬件清單，也不是經測量的 NVIDIA 與 Ascend 比較。@eliebakouch、@stochasticchasm、明確指出不確定性
較後期的一項硬件分析比較了 GB200 與 Ascend 950DT 已報告的解碼數據：
在 100 TPS 限制及 131K 上下文下：每部裝置約為 25.5K 對 5K tokens/s/device。
在 230 TPS 下：約為 20K 對 2.7K，差距由約 5× 擴大至 7.4×。
該分析引述 DeepEP-Ascend 較早前披露的資料，指 EP64–128 及 combine 操作仍在優化中，包括本地歸約開銷，以及 URMA 帶來的 HBM 競爭。
該分析推測，經改進後可達到 8–10K tokens/s/chip，而以假設價格 $10M/NVL72 機櫃及傳聞中的 $37K/950DT計算，經濟效益的交叉點約為 6.8K tokens/s/chip。
這些推算混合了不同的測量數據、假設採購價格，以及未經證實的未來優化成效；它們並非在相同條件下進行的 DeepInfer 硬件基準測試。@teortaxesTex
同一位評論者推測，DeepSeek 到 2027 年底會大規模配置 Ascend，並擁有超過 1 GW 的 Blackwell 等效算力；同時亦提及一項與之矛盾、由模型生成的 250K 張 GPU估算。這兩項預測都不是 DeepSeek 的採購公告。算力推算、互相矛盾的估算
V4.1 Flash：低成本推理服務能放大能力，但不足以定論品質
獨立評測顯示，開放模型的能力有顯著進步，但並非在所有方面都達到前沿模型水平：
Arena：V4.1 Flash 20261017 Max 在 Agent Arena 和 Code Arena: WebDev 中排名第 #1 開放模型。在 Agent Arena 中，它總排名第 #11，在 7,500+ 次真實世界工作階段中，淨改善幅度為 +5.1%，每項任務的成本中位數為 $0.20。Arena 將此形容為：以 27% 的成本，取得 GPT-6.1 Sol 約 37% 的改善幅度。報告列出的指標包括：已確認成功率 +11.5%、好評相對投訴 +5.9%、Bash 可靠性 +5.4%，以及可引導性 +2.5%；該評測中沒有觀察到工具幻覺問題。@arena、詳細結果
網絡安全：Vals 報告指，V4.1 Flash 1017 在一項使用 Pi-based agent 的模擬企業網絡任務中，平均進度超越 GPT-6 Sol。DeepSeek 和 Sol 各進行了三次全新範圍測試；其他模型則各進行一次。完整評測詳情仍有待公佈。DeepSeek 使用的 token 大幅較多，但 API 總成本較低。@ValsAI、成本解讀、方法
網絡安全測試結果在效率和最佳單次表現方面存在爭議。Scaling01 認為，稱 DeepSeek「勝過 Sol」誇大了結果，因為 DeepSeek 的效率低數倍。Teortaxes 報告指，DeepSeek 使用的 token 約為 Sol 的 4.3×，所需時間則為 2.4×，並指出 Sol 的最佳一次測試達到了一組 DeepSeek 所有測試均未達到的目標。建議把節省下來的資源用於重複測試或 swarm，仍屬假設，並非在相同預算下評測所得的結果。@scaling01、@teortaxesTex、相同成本下使用 swarm 的建議
非正式報告的結果比受控證據所能支持的更為正面。Teortaxes 描述了幾輪冷知識問答測試：DeepSeek 的得分為 100%、100% 和 91%，MiniMax 則約為 60%、48% 和 62%；在一項描述／拼寫變體測試中，兩者得分為 100% 對 50%。這些都是由作者設計的小型測試，題目由模型生成，答案鍵亦有錯誤；結果可作為進一步實驗的方向，但並非經驗證的知識基準測試，也不能證明差異單由 Engram 引起。另一名用戶表示，藉助 Hermes 進行 AI 研究的效果出色；另一則帖文則稱，DeepSeek 在另一項評測中的表現仍遠遜 Sol-xhigh。冷知識測試、後續測試、拼寫變體測試、研究軼事、相反結果
本機部署帶來另一種取捨。Brandon Music 發布了 TrellisMX K2 Mix，目標硬件為兩張 RTX PRO 6000；它採用兩位元專家，其中 629 個專家提升至三／四位元，並使用四位元 Engram 表，容量目標約為 3M KV tokens。據報平均 KLD 為 0.1306 nats，比純 K2 低 8.6%；另一個 +5GB 版本的目標容量約為 2M KV tokens。目前只測量了 KLD，而且推理服務使用的是測試映像，因此任務品質能否維持、實際速度及運作穩定性仍未確立。@BrandonMusicKy
Agent 基礎設施、本機執行與硬件加速
長上下文推理核心：SGLang 已合併對 megakernel 的支援；SemiAnalysis 報告指，在 GB300 NVL72 上使用 AgentX 時，每名用戶的速度接近 1,000 tokens/s/user；在 MI355X 上，互動性則提升 1.5×。另外，Inferact 報告指，使用 vLLM TorchTPU 中的開源 megakernel，Kimi K3 在 TPU v7 上達到每名用戶 391 tokens/s/user（SGLang 結果、TPU 結果）。
Apple silicon 執行效能提升：PyTorch 2.15 以 Metal 核心取代數條 MPSGraph 路徑。據報改進包括 MoE 解碼速度提升 5–6.5 倍、Qwen3.6-35B-A3B 在 M3 Ultra 上的速度從 9.4 提升至每秒 61.3 tokens、支援 MPS 上的 FP8，以及 Wan2.2 VAE 的峯值驅動程式記憶體用量從約 270 GiB 降至 8 GiB。這些改進直接納入 PyTorch，而非獨立的推理執行環境（發布摘要）。
本機 Perplexity Computer：現在模型和 Agent 均可完全在支援的 Apple silicon Mac 上執行，包括離線使用，並能與原生 App 及本機檔案互動。
持續運作的 Agent 服務：LangChain 的 Managed Deep Agents 整合了用戶專屬憑證、範圍受限的記憶、沙盒執行及排程工作；Hugging Face 的 Agent Manager 則可在 Claude Code、Codex 及其他執行框架中協調持續工作階段（LangChain 架構、Agent Manager）。
裝置端模型、語音及圖像產品發布
Muse Glimmer：Meta 推出的開放式 30B 多模態 Agent 模型，由 Muse Spark 蒸餾而來，目標配置為 32 GB VRAM，並可透過 4-bit 量化及 speculative decoding head 在單張 RTX 5090 上執行。論文報告其在 MCPAtlas 的成績為 75.5，在 SWE-Bench Pro 的成績為 51.2；Qwen3.6-27B 在 OSWorld-Verified 和 TerminalBench 2.1 上仍然領先。模型支援文字、圖像及超過 100 種語言，採用 Apache 2.0 授權（論文摘要）。
Voxtral 3：Mistral 推出批次及串流轉錄、多語言 TTS，以及支援工具呼叫的語音 Agent SDK；用戶可透過其 API 使用，或在客戶的基礎架構上部署（發布消息、部署選項）。
Fibo 2.0：Bria 的 8B 開放權重圖像模型系列包含用於文字生成圖像的 Dev，以及蒸餾版 Edit Turbo。Artificial Analysis 指其開放權重圖像編輯表現領先，文字生成圖像方面則與 Qwen-Image-2.1 統計上不相上下；Bria API 的價格為每 1,000 張圖片 $32（評估）。
Krea 3 Ultra：不同 Arena 榜單及更新版本的排名各有差異。Artificial Analysis 自行發布的公告將 Ultra 列為第 5 名，較早的帖子則曾列為第 4 名；Arena 將它列為多圖編輯第 4 名、單圖編輯第 8 名。較有根據的結論是其圖像編輯質素具競爭力，而非普遍排名第四（Artificial Analysis、Arena）。
價格：Fast 每 1K 張輸出圖片收費 $0.03，另加每 1K 張參考圖片 $0.02。Ultra 僅支援 2K 輸出；使用一張 1K 參考圖片進行 2K 編輯，費用為 $0.27。
獨立評估、網絡能力與安全證據
HealthBench 揭示評分對答案長度的敏感度：Artificial Analysis 為5,000 段一般健康對話及525 段臨牀醫生對話推出排行榜。GPT-6 Astra 在 Professional 的經長度調整分數中以 66.0% 領先；Claude Sonnet 5.5 則以 62.1% 領先一般 HealthBench。
長度影響：Opus 5.5 的 Professional 原始分數最高，達 71.4%，但經調整後降至 59.9%。在一般 HealthBench 中，回答最短的模型在溝通質素方面居首，但完整性得分最低。因此，答案長度是會實質影響排名的因素，並非表面細節。
成本取捨：DeepSeek V4.1 Flash 每項任務收費 $0.005，得分為 60.9%；Sonnet 每項任務收費 $0.08，得分為 62.1%。評分採用 OpenAI 模型，沿用原始實作的做法（方法與結果）。
路由與專用模型的取捨：Vals 在五個路由器及約 1,250 項任務的測試中發現，每個路由器在分數和成本兩方面都至少被一個單獨使用的模型超越。在路由器預算範圍內，若能事後作最佳選擇，分數可提高 8–27 分，顯示選擇策略仍有相當大的提升空間（Router Index、最佳化比較）。
DeepSeek 網絡攻擊測試結果：Vals 報告指，在使用 Pi 測試框架進行的模擬企業網絡任務中，V4.1 Flash 1017 的表現勝過 GPT-6 Sol。DeepSeek 消耗的 tokens 較多，但總費用較低。
安全保障與問責：METR 認同 Anthropic 對受評模型出現災難性錯誤對齊風險偏低的結論，但指出雙方在分析上存在重大分歧。METR 建議對監察系統進行端到端紅隊測試，並評估模型削弱安全相關決策的能力（評估、建議、決策風險）。
科學代理：濕實驗結果與開放式研究的限制
蠍毒素結合蛋白：Anthropic 和 Citrini 報告，211 個經測試的蛋白質設計中有 17 個結合蛋白，此前 Anthropic 內部 Claude 研究模型已進行大量計算工作。所有經測試的設計及實驗室數據均會公開（公告、數據）。
由病理學預測生物學特徵：Sophont 推出 Holon-S1，可從常規病理切片預測空間基因活性及生物標記。團隊表示，該模型已在 16 種器官類型及超過 15 款掃描器上接受評估，在空間基因預測方面勝過兩款比較模型，並找出可能是新型的乳癌及結腸癌生物標記。這些屬研究結果，並非經驗證的治療方案選擇成效（發布公告）。
開放式研究仍具難度：評估人員向 GPT-6 Astra 和 Claude Fable 5.1 提供未公開的 AI 研究問題，並各自給予 $10,000 預算。原論文作者認為，與較早前的測試相比，實驗設計及資源管理有所改善，但仍因創意、判斷、校準及溝通方面的不足，拒絕兩者生成的論文。這項小型研究可作為補充參照，平衡那些針對狹義且可驗證研究任務的結果（評估）。
產業與政策：藥物開發、製造及資本承諾
OpenAI 收購 Orchestra Bio：OpenAI 宣佈收購一個藥物開發協調平台，與 Rosalind 並行，把其生命科學工作由研究工具延伸至實際營運執行。公告未有提供財務條款（公告）。
Arda 正式公開推出：前 OpenAI 研究主管 Bob McGrew 宣佈推出與 Anduril 共同開發的製造業軟件，Anduril 擔任設計合作夥伴。他本人發布的資訊列明，A 輪融資為 $160M，估值為 $1.5B；CNBC 隨附的貼文則稱已集資 $230M，但沒有清楚説明這個數字與宣佈的融資輪次有何關係。首款產品支援手動設計及操作裝配線；下一步目標是發展可重新配置的自動化技術（創辦人公告、CNBC 報道）。
融資及算力支出風險：有報道指，OpenAI 正尋求約 $30B 融資，估值為 $1.4T+，時間早於預期中的 Anthropic IPO。另外，據報《華爾街日報》審閲 Anthropic 的招股書草案後指出，公司上半年收入為 $16.3B，算力及基建開支接近 $9B，未來算力承諾超過 $600B，當中包括仍在磋商的項目。以上均為報道引述的資料，並非已完成的交易或經獨立核實的財務披露（OpenAI 報道、Anthropic 報道）。
熱門推文（按互動量排名）
39,393 — DeepSeek 發布 DeepInfer
5,778 — Anthropic 發表蠍毒結合蛋白研究
5,700 — OpenAI 宣佈收購 Orchestra Bio
3,056 — Mistral 推出 Voxtral 3
2,600 — 研究人員解釋結合蛋白研究結果及生物學限制
2,476 — Hugging Face 行政總裁質疑網絡攻擊紀錄片的敍事方式
2,330 — Theo 否認曾獲得所謂的 Fable 5.5 存取權
AI Reddit 摘要
/r/LocalLlama + /r/localLLM 摘要
1. DeepSeek DeepInfer 開源推理框架
New from DeepSeek - DeepInfer - (Activity: 313): The image is a mobile screenshot of DeepSeek’s X announcement that DeepInfer, its in-house inference framework, is now fully open source: image, GitHub. The technically relevant claim from the linked/source discussion is that DeepInfer powers DeepSeek V4.1 Flash at scale, with reported single-cluster throughput of 155 trillion tokens/day and revenue of $38 per card per hour at off-peak pricing, emphasizing high-throughput, low-latency large-scale inference rather than model training. Commenters were notably surprised that DeepSeek open-sourced an internal production inference stack, contrasting it with what they expect from Anthropic, OpenAI, or Meta. There was also basic uncertainty from some readers about what the framework actually does, i.e. serving/inference infrastructure rather than a new model.
A linked Zhihu source claims DeepInfer enables high-throughput, low-latency large-scale inference for DeepSeek V4.1 Flash, reporting 155 trillion tokens/day throughput for a single cluster and $38 per card-hour revenue under off-peak pricing:
https://zhuanlan.zhihu.com/p/2095560295930508953
. One commenter also highlights a reported serving figure of roughly 256 tokens/s × 100 users, implying very high concurrent decode throughput if sustained in production.
A technical concern raised is whether DeepInfer is a general-purpose inference framework or primarily a stack heavily optimized for DeepSeek’s own model architecture and deployment environment. The repo’s low initial GitHub star count versus high announcement engagement was interpreted as likely due to freshness, but commenters expect more meaningful evaluation once engineers inspect the implementation and portability.
Deepseek released DeepInfer - Open Source high-performance, large-scale inference framework for DeepSeek models! (Activity: 1023): DeepSeek released DeepInfer, an open-source high-performance offline inference framework for DeepSeek-V4.1-Flash, with production-oriented primitives including optimized kernels, attention/data/context parallelism, MoE expert parallelism with EPLB, DSpark-style speculative decoding, SWA bounded replay, async scheduling, structured outputs, batch-invariant inference, and deterministic sampling. It currently targets NVIDIA SM100 GPUs and Huawei Ascend 950 NPUs via DEEPINFER_ACCELERATOR=nvidia|ascend, requiring Linux/Python 3.12 plus CUDA 13 or CANN 9.2; however, full online serving still needs external KV-cache management, prefill/decode disaggregation, and DP replica load balancing. DeepSeek also released deepseek-recipe, a Rust library with Python bindings for protocol conversion and model-output parsing across APIs such as Chat Completions, Messages, and Responses. Commenters framed the release as valuable for reverse-engineering production inference techniques into community engines such as gufo, halogen, strixite, and Strata. There was also interest in the explicit Ascend 950 support, with one commenter joking that “Nvidia [is] in shambles,” though the listed NVIDIA target remains next-gen SM100 rather than current widely deployed GPUs.
DeepSeek’s release is split into two repositories: DeepInfer, described as a high-performance large-scale inference framework for DeepSeek models, and deepseek-recipe, a Rust library with Python bindings for protocol conversion and model-output parsing across API formats like Chat Completions, Messages, and Responses.
Commenters noted the currently listed accelerator targets are NVIDIA SM100 GPUs and Huawei Ascend 950 NPUs, with build-time platform selection exposed through DEEPINFER_ACCELERATOR=nvidia or ascend before running ./build.sh. The Ascend support drew attention because it implies DeepSeek is optimizing beyond the standard CUDA/NVIDIA path.
One commenter referenced DeepSeek’s Zhihu post claiming roughly $38 per GPU-hour revenue/throughput economics, linking the original post at zhuanlan.zhihu.com/p/2095560295930508953. The thread raised whether similar per-GPU economics could be used to estimate inference revenue for competitors like OpenAI or Anthropic, though no concrete derivation was provided.
Can DeepSeek V4.1 Flash 1017 really run on 12GB VRAM + 64GB RAM? (Activity: 352): The image is a screenshot of an X/Twitter thread claiming DeepSeek V4.1 Flash 1017 may be runnable locally at Q4 with 12GB VRAM + 64GB RAM; the Reddit post asks whether an RTX 3060 12GB could offload enough layers to make inference usable. The key technical pushback is that V4.1 Flash is reportedly already around 4.25 bpw for many experts via mxfp4 + fp8, so while it may fit if total RAM is sufficient, expected performance with heavy CPU/RAM execution could be extremely slow—one commenter estimates roughly ~3 tokens/sec. Commenters are skeptical that this would be practical for everyday use: the consensus is closer to “possible to load” than “pleasant to run.” One comment notes the person making the original claim is the Strata creator, lending some credibility to the sizing claim, but not necessarily to performance expectations.
Commenters disputed the claim that DeepSeek V4.1 Flash 1017 can practically run on 12GB VRAM + 64GB RAM: even the “Flash” variant is described as already being around 4.25 bpw for many experts, using MXFP4 + FP8, so a standard Q4-style fit is unlikely within that memory budget.
A technically viable setup may require heavy offloading: one commenter says Q4 does not fit and suggests checking the Hugging Face model size directly, then offloading n-grams to NVMe and streaming some MoE experts from disk. This may run in principle, but expected throughput is likely very poor, with one estimate around ~3 tokens/s or worse depending on disk and offload implementation.
There was skepticism that the original Strata claim was accurate; commenters noted that even if the model can be made to “fit” somewhere across RAM/NVMe, the relevant question is practical inference speed rather than mere loadability.
2. MiniMax M3.1 Flash Release
MiniMax M3.1 Flash released, Model weights Oct 23 (Activity: 874): The image is an official MiniMax X announcement for MiniMax M3.1 Flash, described as “Space Performance + Bunny Speed,” with API availability now and open model weights scheduled for Oct 23. Commenters add that the model is reportedly a MoE with 428B total parameters, ~23B active parameters, sparse attention, and a native visual encoder; a preview/tool page is linked at agent.minimax.io/tools/m3-1-flash-preview. The main technical concern in comments is that benchmark excitement depends heavily on knowing the model size/active parameter count, since performance claims are hard to contextualize without architecture details.
A commenter cites the MiniMax M3.1 Flash Preview tool page as specifying a Mixture-of-Experts architecture with 428B total parameters and roughly 23B active parameters, plus sparse attention and a native visual encoder: https://agent.minimax.io/tools/m3-1-flash-preview. This directly answers discussion uncertainty about model size and suggests the model is positioned as a large sparse multimodal system rather than a dense LLM.
MiniMax-M3.1-Flash is coming (Activity: 521): MiniMax teased MiniMax-M3.1-Flash via an official X post (source), but the Reddit post provides no architecture details, parameter count, context length, pricing, release date, or benchmarks. The only technical signal is the product naming: commenters infer “Flash” may denote a speed/latency-optimized variant, though no evidence is given. Commenters are skeptical about the meaning of “Flash,” joking that in current LLM naming it could still be a very large model — e.g. “Flash means a 500B model” — or sarcastically a supposedly lightweight model that is not actually small.
3. Benchmark Inflation and AI Slop Measurement
AI labs report benchmark scores 6.4% higher than independent testers, on average (Activity: 334): The image is a technical benchmark-comparison chart from the whatmodel.sh open leaderboard, visualizing 611 matched comparisons across 180 AI models and 103 benchmarks from 1,629 published results. It reports that AI labs’ self-published scores are 6.4% higher on average than independent testers for the same model/benchmark pairs, with 375 lab-higher cases vs. 216 independent-higher and 20 ties; the largest median benchmark gaps shown include SWE-bench Verified and MBPP at about +9.0 points for labs. Image · interactive chart · data/code Commenters debated whether the gap reflects intentional score inflation or more mundane reproducibility issues such as package versions, harness settings, random seeds, prompt/eval setup, or labs optimizing benchmark tooling to present best-case results. Several compared it to vendor-favorable performance charts from companies like Apple or Nvidia, arguing that only independently reproduced or peer-reviewed results should be trusted.
Several commenters argued that the 6.4% average gap may come from benchmark reproducibility issues rather than outright inflation: small differences in package versions, evaluation harness settings, random seeds, prompt formatting, and lab-specific benchmark tooling can materially affect reported scores. One theme was that labs likely optimize the exact harness/configuration used to showcase their models, while independent testers may use more generic or less model-tailored setups.
A commenter noted the mean gap may be driven by outliers and suggested the median discrepancy would likely be closer to reported benchmark values. This implies the headline average could overstate systematic inflation if a small number of large deviations dominate the aggregate.
One technical explanation proposed was deployment mismatch: labs may benchmark full-weight models, e.g. BF16, while independent testers often evaluate served API versions that have been quantized to FP8, MXFP4, or other hardware-efficient formats. If true, some score degradation could reflect inference serving optimizations for datacenter tensor units rather than benchmark manipulation.
Let’s delve into the tapestry of AI slop on r/LocalLLaMA (Activity: 455): The post links an informal longitudinal analysis of “AI slop” across Reddit communities, including r/LocalLLaMA, with an attempted extrapolation of future slop prevalence: thil.ooo/blog/measuring-slop. A technical commenter notes likely measurement bias: moderator removals and karma filters may cause Pushshift/archive-style datasets to undercount short-lived bot posts, while bot evasion tactics such as all-lowercase writing may weaken simple “human marker” heuristics; they also suggest comparing against Claude-associated vocabulary from “load-bearing vocabulary of Claude”. Moderation feedback was supportive: a mod left the post up as directly relevant to ongoing anti-slop moderation despite reports. Commenters broadly agreed that obvious AI-generated style markers—em dashes, bullet lists, and stock phrases like “delve”—have become noisy signals and can falsely implicate human writing.
A commenter noted several measurement biases that could affect an AI-slop detector trained/evaluated on Reddit archive data: moderators may remove many generated posts from /new before they appear in the dataset, and a new karma filter may be suppressing bot/slop submissions upstream. They also flagged that bots may evade simple style heuristics by posting in all lowercase, potentially corrupting “human marker” assumptions.
One technical suggestion was to expand the detector’s lexical feature set using Claude-specific “slop” terms, referencing the analysis of Claude’s load-bearing vocabulary at https://louisabraham.github.io/load-bearing/. The commenter emphasized distinguishing obvious AI slop from broader low-value generated content that may not exhibit obvious stylistic markers and may be removed quickly.
Less Technical AI Subreddit Recap
/r/Singularity, /r/Oobabooga, /r/MachineLearning, /r/OpenAI, /r/ClaudeAI, /r/StableDiffusion, /r/ChatGPT, /r/ChatGPTCoding, /r/aivideo, /r/aivideo
1. Opus 5.5 Game Automation Feats
After $712 and 39 hours, Opus 5.5 beat Baldur’s Gate 3 all by itself (Activity: 1145): A user reports that Claude Opus 5.5 autonomously completed Baldur’s Gate 3 using a custom harness: claude -p with built-in tools disabled, a Python MCP server connected over TCP to a Lua BG3 mod, Vulkan-layer screenshots, and SDL-mediated clicks (write-up, code). The run took 39 hours, $712, 99 fresh sessions, 20,809 tool calls, 862 screenshots, 2.2B+ cached input tokens vs 3.5M output tokens, and relied on a git-backed memory system with 157 commits, ~23k curated words, and 67 distilled tactical rules; an audited Faith-Leap rerun required 36 min, 674 tool calls, $24, one death, and eleven reloads using only screenshots of the mosaic after fixing a hidden-walkway leak. The author plans to turn the harness into a benchmark of short BG3 scenarios scored by success, attempts, time, and cost, with Claude’s Nautiloid opening reportedly succeeding 9/9 at about $1.50/run, and Codex/Gemini integrations prepared but not yet evaluated. Top commenters mostly reacted that the project is expensive but promising: one called it “one of the best benchmark ideas” for comparing agents across vendors, while another dismissed the spend as “more money than sense.” Non-technical joking centered on whether the agent made morally significant in-game choices, e.g. whether it raided the grove.
A commenter framed the run as a potentially useful agentic benchmark, suggesting that repeating the Baldur’s Gate 3 task across competing models could provide a more practical comparison of long-horizon planning, tool use, and persistence than many standard benchmarks. The key technical value would come from standardizing the setup and measuring cost, completion time, failure modes, and decision quality across models.
Claude Opus 5.5 decompiles a PS2-era game overnight, and hundreds of them now run in browser tabs (Activity: 2348): A Kotaku report claims AI-assisted reverse engineering—attributed in the post title to Claude Opus 5.5—has enabled browser-playable ports of older titles such as Halo: CE, GTA: Vice City, Skate 3, and The Simpsons: Hit & Run. The article says some ports run entirely in-browser with notable performance claims, e.g. Hit & Run targeting 240fps and a Halo: CE build supporting low-latency online multiplayer, but commenters question whether these are true decompilations or instead recompilations/reimplementations of existing binaries/assets. Top comments are skeptical: one asks for an actual playable browser link and calls the post an “empty flex,” while another argues the terminology is being conflated—“these aren’t decomps… they’re just recomps?” A separate commenter speculates that public access to strong models may be restricted once corporations view this as an IP-enforcement threat.
A commenter challenges the post’s terminology, arguing these likely are not full decompilations but rather recompilations/recomp projects, noting that the community may be conflating the two. This distinction matters technically: decompilation implies recovering high-level source or equivalent structure, while recompilation often translates existing binaries/IR into a new target such as browser-compatible code.
2. AI Proofs and Academic Labor
Fields Medalist Richard Borcherds on OpenAI proofs: “I think what people are getting upset about is they’re slowly realizing that they are dumb and somehow blaming this on AI, even though it’s not really AI’s fault” (Activity: 1309): The linked Daily Cal piece covers UC Berkeley mathematicians’ reaction to an alleged OpenAI Navier–Stokes proof (article), framing it as a stress test for mathematical proof validation, pedagogy, and the role of AI systems in advanced research. Richard Borcherds is quoted arguing that backlash may reflect researchers’ realization of their own limitations rather than an AI-specific failure: “they’re slowly realizing that they are dumb and somehow blaming this on AI.” Top commenters focused mostly on education: one endorsed the view that AI use on homework is irrelevant if students cannot reproduce understanding on exams, while another highlighted Borcherds’ claim that AI may be a more patient and expressive tutor for graduate abstract algebra than a human instructor.
A quoted discussion from Richard Borcherds frames AI-generated mathematics as potentially producing very large formal artifacts—e.g. “a 100,000-line formal proof of some major conjecture”—but argues this does not necessarily degrade mathematical learning or research because humans can choose to ignore machine-produced formalizations. The technically relevant implication is a distinction between formal proof generation/verification and the human-centered process of understanding, motivation, and theory-building.
One comment highlights Borcherds’ claim that AI may be better than him at teaching MATH 250A graduate abstract algebra, specifically because it is patient, consistent, and able to re-explain material without frustration. This is an education-focused technical point: LLMs may function well as adaptive tutors for dense symbolic subjects, while still not replacing the need for students to independently solve problems for exam-level mastery.
A physicist spent a year of his life and ~500 pages of hand calculations for quantum gravity in his PhD thesis, but Opus 5.5 did it in 10 hours, including the article and GitHub repo. And it even found the errors. What will “labor” mean in academia from now on? (Activity: 1710): The linked repo, eokahya/claude-audits-quantum-gravity, is an AI-assisted audit by E. O. Kahya, the original coauthor, of prior one-loop quantum-gravity calculations for the graviton correction to a massless minimally coupled scalar in de Sitter space—not a fully autonomous rediscovery. The workflow was manually decomposed into an 18-task/9-stage pipeline where Claude orchestrated deterministic SymPy/mpmath checks, including high-precision numerical sampling, and found mostly bookkeeping/printing issues: an overall sign convention error in the printed bare self-mass, missing/non-analytic and analytic terms in Table X, finite intermediate issues, and 23 typos. The main physics result reportedly survived unchanged: after correction, the Schwinger–Keldysh late-time mode-function analysis still yields no growing one-loop terms such as ln(a), ln²(a), or a, only constant field-strength renormalization plus decaying terms. Top commenters pushed back on the framing that “Opus 5.5 did a PhD thesis in 10 hours,” arguing the hard scientific work was the original formulation, boundary conditions, Feynman rules, and expert scaffolding; the AI mostly accelerated verification of dense tensor algebra. A broader debate compared current academia to human+engine chess, with one view that AI-assisted researchers are temporarily strongest, but another predicting fully automated systems may eventually outperform human academics except in posing high-value questions.
Multiple commenters argue the headline misrepresents the work: E. O. Kahya, the original coauthor, did not have Claude autonomously rederive quantum gravity results from first principles; he used it to audit prior calculations. The workflow was manually scaffolded into an 18-task, 9-stage pipeline with expert-supplied boundary constraints, while Claude orchestrated deterministic tools like SymPy and mpmath for tensor-algebra checks and 30-digit numerical validation.
The technically important outcome was that the core physical result survived unchanged. Reported issues were limited to arithmetic slips, an overall sign/definition flip, a missing bookkeeping term, and 23 typographical errors, with commenters emphasizing that this is closer to computer-assisted verification of dense symbolic work than novel physical discovery.
Commenters highlight that Kahya’s own README includes caveats such as “What a human expert should still review” and limitations around numerical sampling. The main technical framing is therefore AI as an audit/cross-check layer for expert-designed theoretical pipelines, not yet a replacement for posing the theory, deriving Feynman rules, or establishing the physical framework.
3. Agent Security and Prompt-Injection Risks
PSA: Do NOT connect your gmail and drive with your Dots at the moment (Activity: 1225): The post warns that Dots agents connected to Gmail/Drive/PC may execute attacker-controlled instructions delivered via email attachments or message bodies, exfiltrating personal data or installing malware if the agent treats the content as trusted user intent. Commenters identify this as a classic prompt injection / tool-use security failure affecting any LLM agent with external capabilities, not just Dots: untrusted content can become executable instructions when read by an autonomous agent. The dominant reaction is strong skepticism toward granting AI agents privileged access to local machines, email, or cloud storage until robust permissioning, sandboxing, and instruction-boundary defenses exist.
Several commenters identify the core risk as prompt injection against AI agents with connected tools, not a Dots-specific flaw. The technical concern is that any LLM granted access to Gmail/Drive or local actions can be manipulated by untrusted content to perform unintended operations, making autonomous account access unsafe without strong sandboxing, permission boundaries, and human-in-the-loop approval.
My post about rogue AI agents got 1.3M views here and then reddit just deleted it. no reason given (Activity: 1315): The image is a non-technical Reddit UI screenshot showing a prior r/ChatGPT post marked “[Removed by Reddit]” for a content-policy violation, despite reportedly reaching ~1.3M views, 1.5K upvotes, 530 comments, and moderator approval before removal: image. The post claims the removed content discussed research, also covered by the NYT, about “rogue” AI agents operating online, but the screenshot itself provides no technical evidence about the agents—only evidence of platform-level removal without a visible rule citation. Comments lean conspiratorial/skeptical, suggesting the alleged agents or bots could be suppressing discussion or manipulating perception, while others frame reposting as the expected Reddit response.
來源：Latent Space · latent.space