調研視窗：過去 24 小時（2026-09-16 19:23 ~ 2026-09-17 19:23，北京時間；本任務為每日 07:00 定時的首次試執行，判定改在當日傍晚執行，視窗仍按 24 小時取） 信源：GitHub（tile-ai 組織 28 個倉庫 pushed_at 全量核查，視窗內 9 個倉庫有推送；tilelang、tilelang-ascend、tilelang-metax、tilelang-hygon、TileOPs 等倉庫視窗內提交逐條複核，關鍵 PR 說明與基準資料核對；分支與標籤後設資料交叉驗證）、第三方適配與採用方倉庫（tilelang-mlir-ascend、tilelang-musa、TileFoundry、TileRT、deepseek-ai/TileKernels、QwenLM/FlashQLA）、Google News RSS 中英文多組查詢（走代理）、Hacker News、arXiv、華為全聯接大會 2026 現場報道（詳見附錄信源清單）

本期索引

  • 今日重點：T.gemm_blockscaled 進入主倉——分塊量化 GEMM 有了統一入口（09-17）
  • 一、核心專案進展
    • 1.1 主倉新增 T.gemm_blockscaled 與後端選擇器，分塊量化不再靜默降級（09-17）
    • 1.2 原子向量寬度改由目的地址規劃，嵌入反向等核心提速 1.4 至 2.5 倍（09-17）
    • 1.3 原子加在非連續目的地址上保持標量，修掉一類靜默寫錯與地址未對齊崩潰（09-17）
    • 1.4 JIT 補 uint64 引數型別對映，Cython 與 NVRTC 宿主包裝器對齊（09-17）
    • 1.5 TileOPs：MoE 索引小路由專家路徑，H200 上對標 vLLM 全面領先（09-17）
    • 1.6 TileOPs：核心選擇與構建分派重構，四處運算元引數遷入建構函式（09-16/09-17）
  • 二、多後端適配（昇騰 / 沐曦 / 海光 / 摩爾執行緒）
    • 2.1 昇騰：NSA 前向與其變長版本同日入庫，910B3 上進入 20 微秒量級（09-17）
    • 2.2 昇騰：動態量化、RMSNorm 融合與 RoPE 示例補齊運算元面（09-16/09-17）
    • 2.3 沐曦：MACA 非同步複製 GEMM 支援入庫（09-17）
    • 2.4 海光：HCU 後端 rebase 多級儲存與緩衝儲存，流水改走 prefer_async（09-17）
    • 2.5 摩爾執行緒：MUSA 5.3.0 文件補入回移植分支（09-17）
    • 2.6 產業側：華為全聯接大會 2026 公佈昇騰 960 與 Atlas 960 超節點進展（09-17）
  • 三、生態與採用方
    • 3.1 tilelang-mlir-ascend：TileOPs 多頭注意力運算元與自適應 LayerNorm 合入（09-16）
    • 3.2 採用方倉庫視窗內安靜：TileKernels、FlashQLA、TileRT 均無推送
    • 3.3 第三方：TileSight 效能分析技術路線文件公開（09-17）
  • 四、社群、教程與活動
    • 4.1 文件站隨主倉持續同步（09-17）
    • 4.2 學術與教程線：ICLR 2026 論文與 Hugging Face 核心教程（背景，視窗外）
  • 五、趨勢觀察
    • 5.1 國產四家後端同日並行演進，適配從單向跟隨轉為同步推進
    • 5.2 主倉兩條線並行：新硬體分塊量化能力與既有核心效能回補
    • 5.3 TileOPs 的定位正從運算元庫轉向可與推理引擎對錶的生產級運算元層
    • 5.4 本視窗的空白與風險點

今日重點：T.gemm_blockscaled 進入主倉——分塊量化 GEMM 有了統一入口

日期：2026-09-17　來源：tilelang #3237 分塊量化 GEMM 語義與後端分派

本視窗主倉最重的一筆改動是把「分塊量化 GEMM」（block-scaled GEMM，即 MXFP8/MXFP4 一類按塊共享縮放因子的低位寬矩陣乘）從散落在各後端的特例，提升為語言層的一個正式運算元。改動引入 GemmBlockScaledNode（實現於 src/op/gemm_blockscaled.{h,cc}）與語言側的 T.gemm_blockscaled，語義寫作 C (+)= (A * SFA) @ (B * SFB)，即縮放因子作為運算元的一等輸入，而不是讓呼叫方在外部手工折算。

它同時修掉兩個此前會靜默出錯的路徑：其一，SM100 上的單 CTA 分塊量化 GEMM 有可能命中只該 SM120 走的指令選擇分支；其二，不具備分塊量化能力的後端會把它當作稠密 GEMM 降級執行，縮放因子被直接丟棄——結果能跑通、精度是錯的。現在分派改走專用的後端選擇器，落在 cuda.tcgen05.blockscaled（SM100 線）與 cuda.mma.blockscaled（SM120 線）兩條實現上，並保留 mbar、use_2cta、sf_layout 等引數入口。作者在 SM100 級裝置（sm_103）上本地驗證，覆蓋 1D1D 佈局的 MXFP8 分塊量化示例與 tcgen05 INT8 GEMM 斷言，並明確標註 SM120 側的執行路徑未在本地驗證。

與它同日合入的 #3238 是另一條線上的對偶動作：不新增能力，而是把此前一次改動引入的效能回退收回來——詳見 1.2。兩條並讀，主倉當前的節奏是「加新硬體路徑」與「補既有核心效能」同時推進。

一、核心專案進展

視窗總覽：tile-ai 組織 28 個倉庫中，視窗內有推送的為 9 個：核心倉 tilelang，國產後端 tilelang-ascend、tilelang-metax、tilelang-hygon、tilelang-musa，運算元庫 TileOPs 與其站點 TileOPs.github.io、TileOPs-nightly，以及文件站 tilelang.github.io。按視窗內提交條數計，tilelang-ascend 6 條最多，tilelang 4 條、TileOPs 3 條、tilelang-metax 2 條、tilelang-hygon 1 條；tilelang-musa 的推送落在回移植分支而非預設分支，故預設分支上無視窗內提交。

1.1 主倉新增 T.gemm_blockscaled 與後端選擇器，分塊量化不再靜默降級（09-17）

日期：2026-09-17　來源：tilelang #3237

詳見「今日重點」。補兩點實現側細節：一是分塊量化 GEMM 已從 GemmImpl 拆出、按後端單獨註冊，稠密 GEMM 與分塊量化 GEMM 各走各的實現槽位，避免再次出現「某後端把它當稠密運算元處理」的路徑混淆；二是 tl.gemm.infer_layout 與 tl.gemm.lower 兩個共享入口被要求嚴格接收 13 個位置引數，使新增運算元必須顯式宣告完整介面，而不是靠預設值矇混過關。該 PR 標題帶「Do not review」字首、由核心維護者自合，合入時攜帶 19 個提交。

1.2 原子向量寬度改由目的地址規劃，嵌入反向等核心提速 1.4 至 2.5 倍（09-17）

日期：2026-09-16 至 2026-09-17　來源：tilelang #3238

動態形狀會在車道索引外引入 int64 轉換，此前的向量化判定只認未化簡的 Ramp 形式，遇到「廣播基址加 int64 車道偏移」這類等價寫法就把整個迴圈標量化——明明訪問的是四個對齊連續元素，卻退化成逐元素執行。修復把判定改為依據目的地址（elem_offset、IndicesCanVectorize、AtomicTargetIsContiguous 三處協同），並以 c6ece48 為基線給出同卡三次測量的中位對比：嵌入反向 N=8192/H=4096/V=129280 從 97.90 微秒降到 56.01 微秒，N=196608/H=256/V=3000000 從 146.87 微秒降到 82.70 微秒，另一檔從 86.62 微秒降到 49.87 微秒，序列輔助計數與求和從 18.40 微秒降到 12.17 微秒；迴歸基準裡 example_gqa_bwd_tma_reduce_varlen 拿到約 27% 的相對提升，其餘用例波動在 0.5% 至 1.5% 之間。這是一次典型的「編譯器改寫規則影響真實推理效能」——受影響的嵌入反向與變長注意力反向都是大詞表推理的常駐核心。

1.3 原子加在非連續目的地址上保持標量，修掉一類靜默寫錯與地址未對齊崩潰（09-17）

日期：2026-09-16　來源：tilelang #3219

與 1.2 同源的另一處向量化缺陷：T.atomic_add 的目的地址若是向量邊界內不變的表示式（如按 i 除以 2 索引、或常量下標），舊邏輯只看資料型別選寬度，把一個「所有車道寫同一格」的語義編譯成一條寬原子加，結果是相鄰元素被靜默寫壞；基址為奇數時直接觸發地址未對齊崩潰。修復新增 CanVectorizeAtomicTarget 前置判定，覆蓋 address_of、tl.access_ptr、tvm_access_ptr 三種目的地址形態，非連續或未對齊一律退回標量。這個缺陷影響面不小——T.Parallel 配 T.atomic_add 是 GEMM split-K、注意力反向、層歸一化的常用寫法，且既有測試用 N 等於執行緒數的配置剛好繞過了它。

1.4 JIT 補 uint64 引數型別對映，Cython 與 NVRTC 宿主包裝器對齊（09-17）

日期：2026-09-17　來源：tilelang #3229

宿主側包裝器此前缺 uint64 的型別對映，遇到該型別引數直接報「不支援的 dtype」。修補後 Cython 與 NVRTC 兩條宿主路徑都能處理 uint64 實參，與裝置側的 uint64_t 宣告對齊。屬於小口子、但不補會在大整數索引與位運算類核心上直接撞牆。

1.5 TileOPs：MoE 索引小路由專家路徑，H200 上對標 vLLM 全面領先（09-17）

日期：2026-09-17　來源：TileOPs #2141

運算元庫側本視窗最有分量的一條。改動為共享融合 MoE 增加了索引式小路由專家路徑：當路由分組稀疏、單專家實際收到的 token 很少時，改用按索引聚合的執行方式，避開大分組下的低效路徑。公開介面不變，不支援的裝置與形狀、大路由分組、以及未驗證的啟用與佈局組合一律保持既有回退。作者在 H200 上用 BF16、top-8 sigmoid 路由加修正偏置、CUPTI 裝置佔用計時並做 L2 沖刷，與 vLLM 對比三套模型：GLM-4.5 在 4096 token 檔領先 25.85%，DeepSeek-V3 同檔領先 16.03%，Kimi K2 領先 8.65%，小 token 檔也普遍佔先。基準自身也被重建（此前基線不可信），並給出 FusedTopK 至少 49.3%、PermuteAlign 至少 59.6% 的整組提升；對照資料說明路由為固定種子的合成路由而非真實 checkpoint 軌跡，屬如實披露。

1.6 TileOPs：核心選擇與構建分派重構，四處運算元引數遷入建構函式（09-16/09-17）

日期：2026-09-16 至 2026-09-17　來源：TileOPs #2146、TileOPs #2145

結構與 1.5 的效能改動同日發生，屬同一輪內部整理。一是分派模型改為「先選出核心、再問它怎麼構建」（Op.kernel_for / Op.entry_for），GEMM 家族全部改走選中的類分派，不再由呼叫點判斷；二是四處原本按呼叫傳參的運算元把引數移到構造階段，其中 MHP 前向若有外部目標首次呼叫會直接拋屬性錯誤、分頁預填充運算元持有一個構造時從未賦值的序列長度欄位，均屬真實缺陷；另把六個運算元的輸出型別引數統一改名為 out_dtype，FP8 GEMM 與其批次版本改收 torch 資料型別而非字串。作者明確本次未改核心主體與生成程式碼，因此不作效能主張，價值在於消除「選擇時讀一個裝置的架構、構建時讀另一個裝置」這類漂移。

二、多後端適配（昇騰 / 沐曦 / 海光 / 摩爾執行緒）

本視窗的形態是四家國產後端同日在場：昇騰 6 條提交、沐曦 2 條、海光 1 條、摩爾執行緒 1 條（回移植分支文件）。這是本日報自採集中少見的密度——四家在同一天都有實質動作，而非各自錯峰。

2.1 昇騰：NSA 前向與其變長版本同日入庫，910B3 上進入 20 微秒量級（09-17）

日期：2026-09-17　來源：tilelang-ascend #1699、tilelang-ascend #1700

兩條都落在昇騰專倉的 ascendc_pto 分支上，四分鐘內先後合入（北京時間 11:44 與 11:49）。#1699 是原生稀疏注意力（NSA）前向運算元：以開發者模式的混合寫法實現，編譯器自動切分 Cube 與 Vector 作用域、自動插入跨核同步標誌，無需手寫全域性屏障、作用域宣告或手工標誌位；黃金配置下任務耗時 19.62 微秒，精度分層測試 27 例全過，最高絕對誤差 1.95e-03。#1700 加上變長序列支援，單核心前向、持久化網格、四段流水，910B3 上測試配置耗時 20.34 微秒，21 例分層測試全過，按容差雙閘門標準口徑給出匹配比例 1.0000。兩條一併看，昇騰側對 DeepSeek 系稀疏注意力結構的覆蓋從「有實現」走到「帶變長與測試分層」。

2.2 昇騰：動態量化、RMSNorm 融合與 RoPE 示例補齊運算元面（09-16/09-17）

日期：2026-09-16 至 2026-09-17　來源：tilelang-ascend #1688、tilelang-ascend #1673、tilelang-ascend #1580

三條示例層改動同時說明昇騰在補「推理鏈路上的常規運算元」：動態量化運算元（#1688）經 CANN 基準與線上評測，20 例精度全過、平均加速比 0.78 倍——即精度可用而效能仍落後廠商基線，屬如實記錄而非勝績；疊加 RMSNorm 的動態量化融合運算元（#1673）與旋轉位置編碼運算元（#1580，覆蓋半旋轉與交錯兩種佈局，附基準指令碼與對標 torch_npu 的精度測試）補上了大模型推理前處理與位置編碼兩個環節。此外 #1603 為 T.tile.merge_sort 補了介面文件與測試用例。

2.3 沐曦：MACA 非同步複製 GEMM 支援入庫（09-17）

日期：2026-09-17　來源：tilelang-metax #156

沐曦側為 MACA 平臺補上非同步複製 GEMM 路徑，涉及非同步記憶體複製原語、屏障指令與非同步複製完成計數三個入口，使矩陣乘的資料搬運可以走非同步流水；同日另有一條測試用例缺陷修復（#157）。對沐曦而言這是「從能跑到跑得快」的一步，因為非同步複製正是 GEMM 流水重疊的前提。

2.4 海光：HCU 後端 rebase 多級儲存與緩衝儲存，流水改走 prefer_async（09-17）

日期：2026-09-17　來源：tilelang-hygon 提交 36db42e1

海光側一條提交觸及 19 個檔案，動作是 rebase 多級儲存（MLS）與緩衝儲存的寫入路徑，並把流水線的複製排程改走 prefer_async。新增的緩衝偏移依賴檢查器按「按塊索引相關」與「按執行緒索引相關」兩類分別判定，再以語法導向的方式把塊基址與殘餘偏移拆開——註釋裡寫明瞭這裡的邊界：緩衝註解就是呼叫方的安全契約，編譯器不去做範圍證明。這條與沐曦那條方向一致：兩家都在把同步搬運換成非同步流水。

2.5 摩爾執行緒：MUSA 5.3.0 文件補入回移植分支（09-17）

日期：2026-09-17　來源：tilelang-musa 分支列表

摩爾執行緒倉的視窗內推送落在 v0.1.12+musa.1 這條回移植分支上，內容是把 MUSA 5.3.0 的文件補進舊版本線，預設分支無視窗內提交。這條訊號偏弱：主線的上一次實質提交是 09-11 的準備公開發布與 09-10 的一批執行時能力（對稱 IPC 分配、IPC 與可選虛擬記憶體管理執行時、DLPack 裝置相容、系統級柵欄），MUSA 側本期屬維護性動作而非新能力。

2.6 產業側：華為全聯接大會 2026 公佈昇騰 960 與 Atlas 960 超節點進展（09-17）

日期：2026-09-17　來源：華為全聯接大會 2026 現場報道（每經，星島環球網轉載）、昇騰 960 定檔 2027 年一季度（網易轉載）

昇騰是 TileLang 國產後端裡最活躍的一支，其硬體路線圖對運算元與核心的適配節奏有直接影響，故列一條產業側動態。9 月 17 日在上海舉行的華為全聯接大會 2026 上，華為副董事長、輪值董事長汪濤宣佈昇騰 960DT 提前至 2027 年第一季度釋出、昇騰 960PR 提前至 2027 年第三季度；Atlas 960 超節點單個可實現 4096 顆 NPU 高速互聯，依託靈衢架構與 Hi-ONE 光引擎，往返時延最低 2 微秒，並首次應用近封裝光學（NPO）光引擎，液冷版計劃 2027 年第三季度推出。會上另稱超節點累計部署超一千套、服務 370 家以上客戶。

作為背景（不在本視窗內）：9 月 8 日 PyTorch Conference China 2026 上，昇騰方面稱其已成為 PyTorch 官方支援的第一個中國硬體，並計劃與 PyTorch 共建面向超節點的原生軟體棧。兩條合看，昇騰的軟體生態位在抬升，對運算元 DSL 層（含 TileLang 昇騰後端）是順風。

三、生態與採用方

3.1 tilelang-mlir-ascend：TileOPs 多頭注意力運算元與自適應 LayerNorm 合入（09-16）

日期：2026-09-16　來源：tilelang-mlir-ascend 提交列表

該倉在 09-16 傍晚（貼近本視窗前邊界）合入一條「把 TileOPs 的多頭注意力運算元接進來」的改動，並修復其基準指令碼的缺陷；此前一天已補自適應 LayerNorm 核心。該倉同時把 CI 切到昇騰 A3 裝置的 runner 標籤上——說明昇騰側不光在寫運算元，也在把驗證搬進真實裝置流水線。

3.2 採用方倉庫視窗內安靜：TileKernels、FlashQLA、TileRT 均無推送

日期：2026-09-17（核查）　來源：deepseek-ai/TileKernels、QwenLM/FlashQLA、tile-ai/TileRT

按本日報的核查清單，採用方與推理側三個倉庫視窗內均無推送：TileKernels 最近一次推送為 2026-04-23，FlashQLA 為 2026-08-26，TileRT 為 2026-08-13。TileRT 已連續五週無更新，是當前清單裡安靜時間最長的一個。這不構成負面結論，但值得繼續跟蹤——TileRT 面向的是低延遲推理執行時，長期停更會讓「TileLang 生態已進入生產部署」的敘事缺少工程側的新證據。

3.3 第三方：TileSight 效能分析技術路線文件公開（09-17）

日期：2026-09-17　來源：tilelang4tilesight-doc 倉庫

第三方開發者公開了一套把 TileLang 程式與 TileSight 效能分析工具對接的技術文件，內容包括從 Python 與高層中間表示中提取語義、工作量與依賴，接入快取與流水分析，並以執行時觀測生成獨立報告與聯合預測；文件把效能問題分為流水瓶頸、跨層級搬運異常、快取利用異常、計算與訪存重疊失敗、負載不均、模型預測偏差六類，並明確區分模型預測、執行時觀測與證據不足三種結論強度，主要討論平臺為 H200。價值在於 TileLang 側的觀測與調優工具鏈正在被外部補齊。

四、社群、教程與活動

4.1 文件站隨主倉持續同步（09-17）

日期：2026-09-17　來源：tilelang.github.io 提交列表

文件站在視窗內有一條自動同步提交（09-17 18:37 北京時間），此前 09-16、09-15、09-12 也各有一次，節奏與主倉合入基本對齊。站點當前版本為 0.1.14，工具區已含編譯工具、效能分析器、佈局視覺化、自動增量除錯、中間表示下降追溯與運算元剖析等條目。文件站同步屬機器人提交，本報告只作節奏記錄。

4.2 學術與教程線：ICLR 2026 論文與 Hugging Face 核心教程（背景，視窗外）

日期：2026-04-23 至 2026-05-31（視窗外背景）　來源：ICLR 2026 海報頁、TileLang 論文（arXiv:2504.17577）、Hugging Face 教程《Writing High-Performance Kernels in TileLang》

本視窗內 arXiv、Hacker News 與中英文新聞檢索均未出現 TileLang 相關新內容，故此處只列視窗外已存在的學術與教程資產，供讀者對照：論文聲稱在 H100 上最高相對 Triton 提速 5 倍、融合注意力核心程式碼量最多縮減 90%；Hugging Face 上的教程給出了從 GEMM 到多頭潛在注意力的完整寫法，並記錄了一處真實收益——某個此前沒有快速路徑的模型配置，換成 TileLang 寫的即插即用核心後從「直接報錯」變為「可上線」。

五、趨勢觀察

5.1 國產四家後端同日並行演進，適配從單向跟隨轉為同步推進

昇騰、沐曦、海光、摩爾執行緒在同一個 24 小時視窗裡都有落地動作，且方向高度趨同：都在補非同步搬運與流水（沐曦的非同步複製 GEMM、海光的 prefer_async、昇騰多段流水），都在補推理鏈路常規運算元（動態量化、RMSNorm 融合、位置編碼）。這說明國產後端的適配已經不是「等上游出特性再跟進」，而是在同一輪裡各自補齊同一組能力。

5.2 主倉兩條線並行：新硬體分塊量化能力與既有核心效能回補

主倉本視窗的兩筆大改動性質相反卻同日合入：一邊給 Blackwell 世代的分塊量化 GEMM 建統一入口與專用分派（避免降級與路徑混淆），一邊把此前一次改寫造成的向量化回退修回來（嵌入反向提速近一倍）。分塊量化對應的是 MXFP8/MXFP4 這類低位寬格式在推理側的普及，效能回補對應的則是大詞表推理的常駐核心——兩者都不屬於「新增運算元」型擴張，而是編譯器層的穩定性與效率工作，通常比分點運算元更能說明專案進入工程成熟期。

5.3 TileOPs 的定位正從運算元庫轉向可與推理引擎對錶的生產級運算元層

本視窗 TileOPs 同時做了兩件事：一是給出對標 vLLM 的整表效能資料（GLM-4.5 4096 token 檔領先 25.85%、DeepSeek-V3 同檔 16.03%），二是把核心選擇與構建分派重構乾淨、並把不一致的介面引數一次性收口。願意公開與 vLLM 的逐檔對比、並同時承認基準此前不可信，表明它的驗收口徑正在向生產可用靠攏；昇騰側的 mlir 倉開始直接接入 TileOPs 運算元，則是這套口徑開始跨後端複用的訊號。

5.4 本視窗的空白與風險點

需要如實指出四點空白：其一，新聞側 24 小時內在中英文渠道均無 TileLang 本體命中，檢索到的同名噪音（資料庫產品更名為 Tile.ai、無關的 2048 強化學習倉庫）不算動態；其二，採用方倉庫（TileKernels、FlashQLA）與推理執行時 TileRT 全部安靜，其中 TileRT 已停更五週；其三，學術側視窗內無新論文；其四，昇騰分塊量化之外的國產後端仍以「補齊常規能力」為主，尚無對標廠商基線並取勝的效能資料，昇騰動態量化運算元 0.78 倍的加速比就是一例——精度透過而效能落後，需要後續視窗繼續跟蹤是否收斂。

附錄：素材與核查說明

核對方式：所有條目均以倉庫提交時間（committer 時間）為準，倉庫推送時間與提交時間分別核對；本視窗內新增的提交逐條讀過標題與 PR 說明，關鍵改動另讀正文中的驗證口徑與基準資料；對分支推送倉庫（摩爾執行緒）追認到具體分支，確認預設分支無視窗內提交；對無法取得正文的第三方連結（含部分媒體頁）只作存在性引用並在正文中註明其性質。

侷限性說明：其一，GitHub 介面在本機採集過程中觸發過未認證限流（每小時 60 次），視窗末期對文件站、mlir 倉、TileFoundry、TileRT 的核查改由倉庫提交流完成，覆蓋倉庫數略有取捨，已在正文標註每一步的核查方式；其二，昇騰與沐曦的實測資料來自提交說明與 PR 正文的自述，本機無對應硬體，未做獨立復現；其三，產業側動態來自公開報道，未取得廠商一手公告原文。

信源核查表

信源 核查結果
tile-ai 組織（28 倉庫） 視窗內 9 個倉庫有推送
提交明細複核 tilelang 4 條、tilelang-ascend 6 條、TileOPs 3 條、tilelang-metax 2 條、tilelang-hygon 1 條
tilelang-musa 預設分支無視窗內提交，推送落在回移植分支 v0.1.12+musa.1
tilelang-mlir-ascend 視窗內無推送，最近一次為 09-16 傍晚（視窗前邊界外一小時）
TileFoundry / DeepStack / tilescale 視窗內無推送，最近一次分別為 09-15 / 09-15 / 08-25
TileRT 視窗內無推送，最近一次 2026-08-13，連續五週無更新
採用方倉庫 TileKernels / FlashQLA 視窗內無推送，最近一次分別為 2026-04-23 / 2026-08-26
Google News RSS（中英文多組查詢） 主題詞與元件名視窗內零命中；命中的 TileDB 更名與 2048 強化學習倉庫屬同名噪音，已剔除
產業新聞渠道 華為全聯接大會 2026 現場報道兩條可用，已收錄 1 條
Hacker News 視窗內無 TileLang 相關討論
arXiv 視窗內無新論文，主論文為既有版本 v2

完整信源清單

wenLM/FlashQLA>