本期 Tempest Python Daily 收錄三則來源動態，主題集中於「Python 作為科學計算與 AI 工程基礎建設」這條主軸：(1) 一份來自 arXiv 的全新 Python 套件 MLM（Multi-Layer Moire），用以產生扭轉多層二維材料的可通約超晶格，是凝態物理與量子材料模擬端的最新工具；(2) libwignernj——一個以 BSD 授權釋出、可同時供 C／C++／Fortran／Python 呼叫的 Wigner 3j、6j、9j 與 Clebsch–Gordan 等角動量耦合係數函式庫；(3) 一篇生產級多模態推論工程文章，作者透過剖析 SGLang 排程器並以一個 Python dict 取代昂貴的 GPU 共享記憶體 book-keeping，使得吞吐量與延遲同時改善逾 10%。三則文章橫跨「科學計算套件、跨語言函式庫、生產推論優化」三個層次，本日報展開 10 則延伸觀察，協助台灣的科研工程師、AI 系統工程師與資料科學家在 5 分鐘內掌握當日重點。所有原文連結均保留 ift.tt 原始短網址，建議讀者在引用任何細節前直接閱讀原文，避免基於二手摘要做技術判斷。
1. arXiv 新套件 MLM：扭轉多層二維材料的 Python 模擬工具
第一則來源是 arXiv 編號 2605.05393v1 的論文，題為「MLM: Multi-Layer Moire — A Python Package for Generating Commensurate Supercells of Twisted Multilayer Two-Dimensional Materials」。原文摘要指出，由原子級薄的二維材料以特定相對扭轉角堆疊而成的 Moire 超晶格，已成為調控量子電子、光學、鐵性質的多功能平台；MLM 套件鎖定的問題是：當研究者要在電腦中建模這類扭轉多層結構時，如何產生可通約（commensurate）的超晶格。對台灣的凝態物理與材料計算社群，這代表又一個直接以 Python 落地、可整合進 ASE／Atomic Simulation Environment 等主流工作流的工具。本日報不擅自轉述原文未明示的實作細節（例如所支援的層數上限、可接受的扭轉角範圍、對稱群處理方式），請讀者以原文為準。原文連結：[https://ift.tt/Zf82V7C]。
2. 為什麼「Moire 超晶格」值得 Python 工程師也關注
Moire 超晶格近年的關注度，源於扭轉雙層石墨烯（twisted bilayer graphene）等材料能在特定「魔角」展現超導等強關聯現象。原文指出，這類超晶格被視為「engineering quantum electronic, optical, and ferroic properties」的多功能平台——換言之，它已不只是物理研究主題，也是後續量子元件與光電材料的設計起點。而從工程觀點看，MLM 把「產生可通約超晶格」這件具體計算任務以 Python 套件包裝，意味著研究端的環境（Jupyter、numpy、ASE、pymatgen）都能直接接上。對台灣半導體、光電與量子材料相關的研發團隊而言，能否快速將此類學術級套件納入內部模擬流水線，是衡量計算工具鏈成熟度的指標之一。本則為延伸觀察，原文具體 API、輸入輸出格式請以原文為準。原文連結：[https://ift.tt/Zf82V7C]。
3. 從 MLM 看「研究級 Python 套件」的工程化趨勢
從另一個角度觀察，MLM 反映出近年凝態物理與材料計算社群的一個明顯趨勢：研究者愈來愈傾向把核心演算法以 Python 套件形式發表並開源，而不只是公開資料或 Fortran／Matlab 程式碼。這背後的工程含義對 Python 社群是好消息：(a) 套件化降低了再現性研究（reproducibility）門檻，後續論文可直接 pip install 並 import；(b) 與既有 Python 科學生態（numpy、scipy、ASE、pymatgen）對接的成本明顯低於封閉工具；(c) 同時也意味著科學軟體工程實踐（CI、文件、語意化版號、測試覆蓋）在這些研究套件中將逐步成為常態。對於從事科學計算或在學界、產學合作中參與工具開發的台灣 Python 工程師而言，是值得參照的釋出範式。本則為延伸觀察，具體開發流程請以原文與套件原始碼為準。原文連結：[https://ift.tt/Zf82V7C]。
4. libwignernj：BSD 授權的角動量耦合係數函式庫
第二則來源是 arXiv 2605.06634v1，介紹 libwignernj——一個 BSD 授權、可重複使用的 C／C++／Fortran／Python 函式庫，用以計算 Wigner 3j、6j、9j 符號，以及 Clebsch–Gordan 係數、Racah W 係數、Fano X 係數，並支援以複數與實數球諧函數標準計算的 Gaunt 係數。原文摘要指出，該函式庫提供「精確（exact）」的 Wigner 符號計算，並對複數及實數球諧函數兩套標準皆有支援。對涉及量子力學角動量耦合（如核物理、原子分子物理、量子化學、磁學）相關計算的工程師與研究員，這是一個值得納入候選工具集的選項。本日報不轉述原文未明示的精度上限、性能基準或記憶體需求等細節，請以原文為準。原文連結：[https://ift.tt/8pkyJQZ]。
5. 為什麼「同時可從 C／C++／Fortran／Python 呼叫」很重要
libwignernj 對 Python 社群最直接的價值不只是「有 Python 綁定」，而是它同時支援 C／C++／Fortran 與 Python——這幾乎完整對應到當代計算物理／化學／天文軟體的語言光譜：(a) Fortran 仍是大型核物理、量子化學程式（如 NWChem、DIRAC、許多核反應網絡程式碼）的主力；(b) C／C++ 是中介層與性能關鍵函式庫（如 Eigen、Boost、GSL）的常見語言；(c) Python 則是當代腳本層、資料處理層、Jupyter Notebook 互動分析的入口。當同一個底層數值核被多語言共享，研究團隊可在不重寫核心邏輯的前提下，把繁重計算交給 Fortran／C++ 主程式、把資料前處理與視覺化交給 Python，而不必擔心數值結果在跨語言時出現微小不一致。本則為延伸觀察，具體綁定機制與安裝步驟請以原文為準。原文連結：[https://ift.tt/8pkyJQZ]。
6. 對台灣科學計算社群的啟示：少做「精度競賽」、多做「正確的工具選型」
對台灣的物理、化學與天文計算實驗室而言，libwignernj 帶來的一個值得記下的訊息是：許多看似基礎的數學工具（Wigner 符號、Clebsch–Gordan 係數），其實長年缺乏一份兼具「精確、可信、跨語言、開源、BSD 授權」屬性的標準函式庫；過去多由各研究組自行實作或從上游程式碼複製貼上，潛在帶來精度誤差與維運成本。一旦此類函式庫到位，後續工作的價值在於「把對的人才從重新發明輪子釋放出來」，而非把資源投入再造一份相似實作。對 Python 工程師而言，類似觀察也適用於 LLM 工程：愈早把推理引擎、向量索引、評估框架等基礎設施交給社群成熟工具，研發資源愈能聚焦在資料、提示與產品本身。本則為延伸觀察，原文未討論 LLM 應用，僅作類比。原文連結：[https://ift.tt/8pkyJQZ]。
7. 用一個 Python dict 把多模態推論吞吐量拉高 10% 以上
第三則來源是一篇工程實務文章，標題為「Boosting multimodal inference performance by >10% with a single Python dict」。原文 tl;dr 開門見山：多模態模型雖具前景，但推論引擎尚未針對它們充分優化；作者剖析（profile）了 SGLang 的排程器在多模態工作負載下的行為，發現一個機會——把圍繞 GPU 共享記憶體的昂貴 book-keeping，替換為單純的快取查找（cache lookup），最後吞吐量與延遲同時獲得改善。原文以「single Python dict」凝聚這個改動的本質：不是換模型、不是換硬體，而是把錯放在熱路徑上的資料結構換掉。對 LLM／多模態系統工程師而言，這是高度可遷移的觀察方法。原文連結：[https://ift.tt/I85RGQL]。
8. 為什麼「book-keeping 開銷」常被低估
當 LLM 推理服務進入生產階段，許多團隊把優化注意力放在 GPU kernel、量化、KV cache 命中率等顯而易見的方向，卻容易忽略排程器內部用於追蹤資源（GPU 記憶體區段、prefix tree 節點、批次中各請求狀態）的 book-keeping 結構本身的成本。原文之所以能以「替換為一個 dict」的形式拉高 10% 以上吞吐量，背後的工程心法是：(a) 先 profile，找到熱路徑上真正花時間的呼叫；(b) 確認該邏輯是否「在語意上等同於一次鍵值查找」，若是則目前資料結構就被選錯了；(c) 用最簡單的容器替換並驗證正確性與性能。對台灣的 LLM 推論工程團隊而言，這個案例值得作為「在引入更複雜架構前，先用 profile 驗證熱路徑」的示範。本則為延伸觀察，具體改動位置、benchmark 配置請以原文與 SGLang 的實際 commit 為準。原文連結：[https://ift.tt/I85RGQL]。
9. SGLang 與多模態推論：為何優化空間集中在「排程器」這層
原文選擇剖析的對象是 SGLang 的排程器（scheduler），而非模型前向計算或注意力 kernel。這個選擇本身傳遞了一個訊號：在多模態推論（同時處理文字、影像、音訊等不同模態）的場景下，請求生命週期遠比純文字 LLM 複雜——影像 token 化、視覺編碼器與語言模型之間的串接、跨模態快取的命中與失效，都會放大排程器在中介層的工作量。當每個請求要被排程器處理的 metadata 變多，原本針對純文字工作負載設計的 book-keeping 結構就會在熱路徑上暴露出來。換句話說，多模態推論的下一波性能爭奪，可能不在 GPU kernel，而在排程器與資料結構選型。對台灣以 LLM 為核心的 AI 服務團隊，建議：(a) 在切到多模態之前，先在 profile 上預留多模態工作負載；(b) 對使用 SGLang／vLLM／TGI 等推論引擎的團隊，定期追蹤上游 issue 與 release notes，避免重新發明已被社群解決的問題。本則為延伸觀察，具體影響量級請以原文為準。原文連結：[https://ift.tt/I85RGQL]。
10. 當日行動建議：科研、跨語言、推論三條主線一次盤點
整合本期三則來源，給台灣 Python 社群與技術主管的當日行動建議：(a) 科研／材料計算端—關注 MLM 套件並追蹤 arXiv 2605.05393v1 的後續更新，若團隊正在處理扭轉多層二維材料模擬，可評估在內部工作流中試跑此套件以替換自製腳本；(b) 跨語言科學軟體端—把 libwignernj（arXiv 2605.06634v1）納入候選函式庫清單，特別是同時維運 Fortran 主程式與 Python 分析腳本的研究組，可重新評估是否還需自製 Wigner 符號計算；(c) LLM／多模態推論端—把那篇「single Python dict」文章作為內部讀書會材料，要求工程師在下一次性能會議中報告自家系統的排程器熱路徑 profile，找出是否存在類似的 book-keeping 過度設計；(d) 整體編採層面—本期收錄量為 3 則，數量偏少但每一則都涉及具體可採用的工具或方法，建議以「科研、跨語言、推論」三軸組合閱讀，不需追求廣度。所有外部連結均保留原始 ift.tt 短網址。