[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-cuda-binaries-turn-ptx-into-elf-you-can-inspect-zh":3,"article-related-cuda-binaries-turn-ptx-into-elf-you-can-inspect-zh":29,"series-research-15c28503-3a01-434b-9e62-9038676f5dff":74},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":22,"views":26,"created_at":27,"published_at":28,"topic_cluster_id":11},"15c28503-3a01-434b-9e62-9038676f5dff","cuda-binaries-turn-ptx-into-elf-you-can-inspect-zh","CUDA 二進位拆成可檢查 ELF","\u003Cp data-speakable=\"summary\">以前我只看 \u003Ca href=\"\u002Fnews\u002Fcuda-moat-tested-by-ai-coding-agents-zh\">CUDA\u003C\u002Fa> source；現在我直接拆 cubin bytes 和 fatbin 包裝。\u003C\u002Fp>\u003Cp>我最近一直在看 \u003Ca href=\"\u002Fnews\u002Fcuda-warps-memory-divergence-explained-zh\">CUDA\u003C\u002Fa> binaries，老實說，一開始真的很煩。能編、能 disassemble、能把 \u003Ca href=\"\u002Ftag\u002Fgpu\">GPU\u003C\u002Fa> code 打包進 wheel，流程都跑得動，可我一問「這檔案裡到底裝了什麼」，答案就開始飄。文件一會兒指向 ELF，一會兒又補個 etc.，像是在叫我自己猜。你如果也遇過那種 build 只在某個 target 爆掉、或是 source 明明只改一點點，cubin 卻整個變樣的情況，就知道問題不在「能不能 compile」，而在「你根本沒看懂 artifact 在講什麼」。\u003C\u002Fp>\u003Cp>真正讓我把這件事看清楚的，是 \u003Ca href=\"https:\u002F\u002Fwww.thesoftwarefrontier.com\u002Fp\u002Fhow-cuda-binaries-actually-work\">Lorenzo Bradanini 和 Lorenzo Tettamanti 在 The Software Frontier 的拆解\u003C\u002Fa>。他們用 \u003Ca href=\"\u002Ftag\u002Fcuda\">CUDA\u003C\u002Fa> 13.3.73 工具鏈，連 GPU 都不用，直接從 byte level 看 cubin 和 fatbin，不再用那種「反正就是 ELF 啦」的敷衍講法。我下面要拆的就是這種做法：不是背名詞，是直接看 bytes，然後把它變成你能在自己專案裡照做的流程。\u003C\u002Fp>\u003Ch2>CUDA 不是一個 compiler，是一串接力\u003C\u002Fh2>\u003Cblockquote>nvcc 不是單一 compiler，它只是把一串工具串起來的 driver。\u003C\u002Fblockquote>\u003Cp>這句話我第一次看到時，心裡只有一個感想：對，終於有人把話講白了。大家平常說「我在編 CUDA」，聽起來像一個動作；實際上是 preprocessing、切 host\u002Fdevice、前端處理、吐 PTX、再交給 ptxas 轉成 SASS，最後包進 fatbin，再回到 host compile。每一段都會留下可檢查的中間產物。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1786068196777-denz.png\" alt=\"CUDA 二進位拆成可檢查 ELF\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>白話翻譯就是：你看到的 final object file，只是多個階段談判完的結果。source 變了，不代表最後 binary 的變化一定在你以為的地方。宏展開、device split、PTX emission、assembler 的選項、包裝器的內容，都可能讓輸出長得不一樣。我以前就踩過這種坑：source 看起來只動了一個 macro，結果 binary 差很多。後來把中間檔都留住，才發現問題根本出在中途，不是在最後那個 .o。\u003C\u002Fp>\u003Cp>實操寫法很簡單：先別急著看結果，先把流程攤開。你要 debug build，就先跑 \u003Ccode>nvcc --dryrun\u003C\u002Fcode> 看它到底叫了哪些工具；接著用 \u003Ccode>--keep\u003C\u002Fcode> 留下中間檔；最後把 PTX、cubin、fatbin 分開看，不要把它們當成同一件事。你如果只看最終輸出，很多問題會一直像鬼一樣飄來飄去。\u003C\u002Fp>\u003Cul>\u003Cli>先用 \u003Ccode>nvcc --dryrun\u003C\u002Fcode> 看整條 pipeline。\u003C\u002Fli>\u003Cli>再用 \u003Ccode>--keep\u003C\u002Fcode> 保留中間檔。\u003C\u002Fli>\u003Cli>PTX、cubin、fatbin 分開檢查。\u003C\u002Fli>\u003Cli>把每個 stage 當成獨立契約，而不是一個黑箱。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>cubin 是 ELF，但 CUDA 指紋全寫在裡面\u003C\u002Fh2>\u003Cp>這篇最有用的地方之一，就是直接證明 standalone cubin 真的是 ELF64 executable，不是比喻。你拿 \u003Ca href=\"https:\u002F\u002Fman7.org\u002Flinux\u002Fman-pages\u002Fman1\u002Ffile.1.html\">file\u003C\u002Fa> 和 \u003Ca href=\"https:\u002F\u002Fman7.org\u002Flinux\u002Fman-pages\u002Fman1\u002Freadelf.1.html\">readelf\u003C\u002Fa> 去看，它就是 ELF；但 header 裡面塞了 CUDA 特有的值，像 machine type、OS ABI byte、flags word，全部都有 CUDA 的味道。\u003C\u002Fp>\u003Cp>也就是說，\u003Ca href=\"\u002Ftag\u002Fnvidia\">NVIDIA\u003C\u002Fa> 不是發明一個全新 container，而是在 ELF 上加自己的語意。這做法有好有壞。好處是 generic tooling 還能勉強讀；壞處是你以為自己在看標準 ELF，其實真正有用的資訊散在 header、note section、還有 NVIDIA 私有 section 裡。格式本身看起來很乖，內容卻一直把關鍵資訊藏在側邊。\u003C\u002Fp>\u003Cp>我自己最有感的是 generic tools 只能幫你看一半。你會看到 section table，卻看不懂那些 0x70000000 範圍的 section type 在講什麼，因為它們對一般 ELF 工具來說就是 unknown。這不是工具壞掉，是格式本來就故意把重要資訊塞進 NVIDIA 自己的 namespace 裡。你如果在寫 parser，看到這裡就該醒了。\u003C\u002Fp>\u003Cp>實操寫法：每次拿到 cubin，先做三件事。第一，跑 \u003Ccode>file\u003C\u002Fcode>。第二，跑 \u003Ccode>readelf -h\u003C\u002Fcode> 看 machine type、OS ABI、flags。第三，別以為看到 ELF 就代表普通工具夠用，接著要去看 NVIDIA note section。你要的是「能解釋 binary」，不是「證明它長得像 ELF」。\u003C\u002Fp>\u003Cul>\u003Cli>對每個 cubin 都先看 \u003Ccode>file\u003C\u002Fcode> 和 \u003Ccode>readelf -h\u003C\u002Fcode>。\u003C\u002Fli>\u003Cli>把 ELF machine type、OS ABI、flags 記下來。\u003C\u002Fli>\u003Cli>不要把 ELF 當成可移植保證。\u003C\u002Fli>\u003Cli>真正的 CUDA metadata 常在 NVIDIA 私有 section。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>有用的資訊大多在 note，不在 code\u003C\u002Fh2>\u003Cp>這也是我最想罵醒大家的一段。文章裡一個很小的 kernel，cubin 總大小 3,968 bytes，真正 machine code 只有 512 bytes。其餘大部分都是 metadata、symbols、notes、relocations、CUDA-specific sections。這個比例很重要：code 很小，圍著 code 的契約很大。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1786068200965-gu0i.png\" alt=\"CUDA 二進位拆成可檢查 ELF\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>原文把幾個關鍵 section 點得很清楚，像 \u003Ccode>.note.nv.tkinfo\u003C\u002Fcode>、\u003Ccode>.note.nv.cuinfo\u003C\u002Fcode>、\u003Ccode>.nv.info\u003C\u002Fcode>、\u003Ccode>.nv.compat\u003C\u002Fcode>、\u003Ccode>.nv.callgraph\u003C\u002Fcode>，還有 kernel 專屬的 \u003Ccode>.nv.info.<mangled-symbol>\u003C\u002Fcode>。其中 \u003Ccode>.note.nv.tkinfo\u003C\u002Fcode> 會記錄 compiler build 和 command line。這超實用，因為它等於把 provenance 直接寫進 artifact。你如果哪天在查 wheel 是誰、用哪個 toolkit 產的，這種 note 就是救命繩。\u003C\u002Fp>\u003Cp>白話翻譯就是：binary 比你想的更會講故事。build flags 不只在 CI log 或 shell script 裡，也可能直接躺在檔案本身。這對 reproducibility、audit、supply chain tracing 都很重要。以前我也遇過團隊說「我們知道這包是誰 build 的」，結果六週後沒人記得到底是哪個 CUDA 版本。這種時候，你最好先看 note section，而不是先翻 Slack。\u003C\u002Fp>\u003Cp>實操寫法：先把 note section 當成第一級資訊來源。用 \u003Ccode>cuobjdump -elf\u003C\u002Fcode> 讀 \u003Ccode>.note.nv.tkinfo\u003C\u002Fcode> 和 \u003Ccode>.note.nv.cuinfo\u003C\u002Fcode>，把輸出存進 CI artifact。之後如果 binary 有變，就先 diff 這些 note，再去看 code。很多時候你會發現，變的不是 kernel 本身，是 build contract。\u003C\u002Fp>\u003Cul>\u003Cli>先查 \u003Ccode>.note.nv.tkinfo\u003C\u002Fcode> 看 provenance。\u003C\u002Fli>\u003Cli>再查 \u003Ccode>.note.nv.cuinfo\u003C\u002Fcode> 看 CUDA metadata。\u003C\u002Fli>\u003Cli>把 note dump 存進 CI artifact。\u003C\u002Fli>\u003Cli>先 diff metadata，再看 machine code。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>你以為的 target，不一定是檔案裡記的 target\u003C\u002Fh2>\u003Cp>這段很容易讓人不爽，但它是真的。文章提到，老工具曾經把 PTX architecture 放在 ELF flags 裡；現在 CUDA tooling 把這資訊搬到 note section，\u003Ccode>cuobjdump\u003C\u002Fcode> 會把它報成 CUDA Virtual SM。flags word 還是有架構相關資料，但它已經不是全部答案。\u003C\u002Fp>\u003Cp>也就是說，如果你以前寫過 parser，假設 \u003Ccode>e_flags\u003C\u002Fcode> 就是 virtual architecture 的唯一來源，那你很可能早就偏掉了。原文還示範了同一個 kernel，在不同 PTX architecture、相同 real target 下，flags 可能還是一樣。架構意圖被記到別的地方去了。這就是那種看起來沒出事、其實已經悄悄 drift 的格式變動，最會害工具壞掉。\u003C\u002Fp>\u003Cp>我對這種變動很有意見，因為它\u003Ca href=\"\u002Fnews\u002Fai-agents-will-expose-web3-weakest-systems-zh\">不會\u003C\u002Fa>大張旗鼓告訴你。文件零碎、release note 零碎、disassembler output 也零碎，整個生態就是要你自己拼。實務上你要同時看三件事：real target、virtual target、還有像 \u003Ccode>sm_100f\u003C\u002Fcode> 這種 feature suffix。這些東西不一定都會影響最後 binary，但你不看就會誤判。\u003C\u002Fp>\u003Cp>實操寫法：別只讀 \u003Ccode>e_flags\u003C\u002Fcode>，把 note section 和 disassembler output 一起看。測 parser 的時候，至少拿不同 CUDA 版本交叉驗證。你要假設 architecture metadata 會移位，而且不會先通知你。\u003C\u002Fp>\u003Cul>\u003Cli>不要只信 \u003Ccode>e_flags\u003C\u002Fcode>。\u003C\u002Fli>\u003Cli>note section 和 disassembler 要一起看。\u003C\u002Fli>\u003Cli>parser 要跨 CUDA 版本測。\u003C\u002Fli>\u003Cli>架構資訊會搬家，這很正常，也很煩。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>支援 target 變少，build matrix 就不能裝死\u003C\u002Fh2>\u003Cp>文章還點出一個很實際的坑：CUDA 13 的支援 target list 其實很短。Turing 是底線，Maxwell、Pascal、Volta 這些舊架構在 CUDA 13.0 的 offline compilation support 已經沒了。這不是小修小補，這會直接影響你的 build matrix。如果你還在維護要給舊 GPU 用的套件，toolkit 版本就不是可有可無。\u003C\u002Fp>\u003Cp>白話翻譯就是：CUDA 版本不只是多幾個 feature，它也在決定你還能對哪些硬體說話。文章也提到 Jetson AGX Thor 的 \u003Ccode>sm_101\u003C\u002Fcode> 改名成 \u003Ccode>sm_110\u003C\u002Fcode>，這種事最討厭，因為你的 script 看起來完全沒問題，實際上 target name 已經換了。這種 silent compatibility trap 我最不愛，因為它不會當場炸，只會在你最不想 debug 的時候炸。\u003C\u002Fp>\u003Cp>實操寫法很直接：CI 裡要 pin CUDA toolkit 版本，target list 不要手寫死，最好從安裝好的 toolkit 生成。你還要檢查腳本裡有沒有硬編 architecture 名稱。只要你還要支援舊 GPU，就別把舊 toolchain 丟掉，留著才有退路。\u003C\u002Fp>\u003Cul>\u003Cli>CI 先 pin CUDA toolkit version。\u003C\u002Fli>\u003Cli>target list 從 toolkit 產生，不要手打。\u003C\u002Fli>\u003Cli>檢查腳本裡的硬編架構名稱。\u003C\u002Fli>\u003Cli>還要支援舊 GPU，就保留舊 toolchain。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>fatbin 是包裝器，不是 payload\u003C\u002Fh2>\u003Cp>很多人講到 fatbin 就停了，像是講完一個名詞就算理解。我覺得這很危險。fatbin 是包裝層，裡面可以放一個或多個 images，也會帶 command-line metadata，讓 runtime 決定要載哪個 payload。它不是 kernel 本體，它比較像 dispatch table。\u003C\u002Fp>\u003Cp>也就是說，如果你 ship 多個 architecture，fatbin 會幫 runtime 在不同 image 間做選擇；就算你只放一個 architecture，它還是會帶 build metadata。這讓它很適合做相容性包裝，但也很容易讓你誤以為自己送出去的東西比實際更單純。我以前看過 build system 外表很乾淨，結果 fatbin 裡面塞了多個 image，還附帶一堆 command-line 歷史。這些東西不是不能有，是你得知道它們在。\u003C\u002Fp>\u003Cp>實操寫法：用 \u003Ca href=\"https:\u002F\u002Fdocs.nvidia.com\u002Fcuda\u002Fcuda-binary-utilities\u002Findex.html\">cuobjdump\u003C\u002Fa> 或 \u003Ca href=\"https:\u002F\u002Fdocs.nvidia.com\u002Fcuda\u002Fnvdisasm\u002Findex.html\">nvdisasm\u003C\u002Fa> 直接看 fatbin contents，確認 bundled 了哪些 images、runtime 會挑哪個、wrapper 裡還藏了什麼 metadata。如果你在發佈 CUDA code，至少要能回答三件事：裡面有哪些 image、會選哪個、wrapper 有沒有把你不想暴露的東西也一起帶出去。\u003C\u002Fp>\u003Cul>\u003Cli>用 \u003Ccode>cuobjdump\u003C\u002Fcode> 或 \u003Ccode>nvdisasm\u003C\u002Fcode> 看 fatbin。\u003C\u002Fli>\u003Cli>確認每個 target bundle 了哪些 images。\u003C\u002Fli>\u003Cli>多架構發佈時，明確設計 fatbin。\u003C\u002Fli>\u003Cli>不要把 wrapper 當 payload。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>最省事的流程就是 inspect、diff、repeat\u003C\u002Fh2>\u003Cp>如果要我把這篇文章濃縮成一個習慣，我會說：別再只信 source，開始 diff artifact。原文作者很明確地說，所有數字和 hex dump 都是他們在自己機器上產出的檔案。這才是對的做法。格式如果文件不完整，你最可靠的 source of truth 就是你自己能重現的 bytes。\u003C\u002Fp>\u003Cp>白話翻譯就是：CUDA binary work 本質上比較像系統考古。你先產出一個 cubin，再把 header、section table、disassembly 全部 dump 出來，接著跨 toolkit 版本、跨 target、跨 feature suffix 去比。格式真正會說話的地方，不在長篇說明，而在差異本身。\u003C\u002Fp>\u003Cp>我自己在解釋兩個 build 為什麼 source 看起來一樣、output 卻不一樣時，最常用的也是這招。driver 載的是 output，不是 source。效能、相容性、reproducibility，最後都落在 artifact 上。只要你能 diff，通常就能把事情講清楚。\u003C\u002Fp>\u003Cp>實操寫法：留一個很小的 kernel 當 binary-format test case，固定在不同 toolkit 和 target 下 build，然後把 ELF header、section table、disassembly output 全部存起來。先 diff 這些，再去怪 compiler。這樣你比較不會把直覺當真相。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># CUDA binary inspection checklist\n\n## Inputs\n- CUDA toolkit version:\n- Target architecture:\n- Source file:\n- Build flags:\n\n## Commands\nnvcc -arch=${ARCH} -cubin -o kernel.cubin kernel.cu\nfile kernel.cubin\nreadelf -h -S kernel.cubin\ncuobjdump -elf kernel.cubin\nnvdisasm kernel.cubin\n\n## What to record\n- ELF machine type\n- OS ABI byte\n- ABI version\n- e_flags value\n- CUDA virtual SM from notes\n- Toolkit provenance note\n- Section table entries\n- .text section size\n- .nv.info and .nv.compat contents\n- Fatbin images, if present\n\n## What to compare\n- Same source, different toolkit versions\n- Same source, different -arch values\n- Same source, with and without feature suffixes\n- Same source, with and without debug info\n\n## Questions to answer\n- Which stage changed the output?\n- Is the change in code or metadata?\n- Did the virtual architecture move?\n- Did the wrapper change even if the kernel did not?\n- Can I reproduce the same bytes on another machine?\n\n## CI artifact suggestion\nSave:\n- build log\n- readelf output\n- cuobjdump output\n- nvdisasm output\n- section-table diff\n- toolkit version string\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>這段我真的會直接拿去用。它不花俏，但它能最快把 CUDA binaries 從「像傳說」變成「像系統」。你先從一個小 kernel 開始，把所有輸出都留下來，最好進版控。當你這樣做一輪，很多原本看起來玄學的問題，會突然變得很平。\u003C\u002Fp>\u003Cp>我最後的結論很簡單：CUDA binaries 之所以難懂，不是因為它們神秘，而是因為重要資訊被拆散在 ELF header、NVIDIA notes、section table、wrapper format 裡面，而大多數人只看最後那一層。你把整條鏈看完，bytes 其實會講得很清楚。\u003C\u002Fp>\u003Cp>來源致謝：原始技術拆解來自 Lorenzo Bradanini 和 Lorenzo Tettamanti 的文章 \u003Ca href=\"https:\u002F\u002Fwww.thesoftwarefrontier.com\u002Fp\u002Fhow-cuda-binaries-actually-work\">https:\u002F\u002Fwww.thesoftwarefrontier.com\u002Fp\u002Fhow-cuda-binaries-actually-work\u003C\u002Fa>。上面內容是我根據這篇文章整理出的實作版理解，最後的模板則是我改寫成可直接套用的版本。\u003C\u002Fp>","我把 CUDA binary 的 cubin、fatbin、ELF note 一層層拆開，整理成可直接照抄的檢查模板。","www.thesoftwarefrontier.com","https:\u002F\u002Fwww.thesoftwarefrontier.com\u002Fp\u002Fhow-cuda-binaries-actually-work",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1786068196777-denz.png","research","zh","fa5321dc-f874-4ab7-9a8c-427e02701561",[17,18,19,20,21],"CUDA","cubin","fatbin","ELF","cuobjdump",[23,24,25],"CUDA binary 其實是多階段 pipeline 的結果，不是單一 compiler 黑箱。","cubin 和 fatbin 裡最有價值的資訊常在 note、section、wrapper metadata。","最佳實務是先 dump、再 diff，最後才怪 compiler。",1,"2026-08-07T02:02:53.326675+00:00","2026-08-07T02:02:53.296+00:00",{"tags":30,"relatedLang":33,"relatedPosts":37},[31],{"name":17,"slug":32},"cuda",{"id":15,"slug":34,"title":35,"language":36},"cuda-binaries-turn-ptx-into-elf-you-can-inspect-en","CUDA binaries turn PTX into ELF you can inspect","en",[38,44,50,56,62,68],{"id":39,"slug":40,"title":41,"cover_image":42,"image_url":42,"created_at":43,"category":13},"a2ae5975-7c35-4094-9d13-922f15cb1034","octolong-cross-repository-code-contexts-zh","OctoLong 用跨倉庫程式脈絡訓練長上下文模型","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1785999778532-gdas.png","2026-08-06T07:02:26.875328+00:00",{"id":45,"slug":46,"title":47,"cover_image":48,"image_url":48,"created_at":49,"category":13},"9ffcddf6-f52b-4ca8-99f5-a927ec5261b4","argus-self-evolving-runtime-long-tasks-zh","Argus：會自我演化的長任務 runtime","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1785997980205-qk1s.png","2026-08-06T06:32:34.986144+00:00",{"id":51,"slug":52,"title":53,"cover_image":54,"image_url":54,"created_at":55,"category":13},"975385e8-e9e9-4c95-a671-8698277cd71c","reasoning-core-procedural-reasoning-data-zh","Reasoning Core 讓程序推理資料更好用","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1785996216956-aq0n.png","2026-08-06T06:03:09.482977+00:00",{"id":57,"slug":58,"title":59,"cover_image":60,"image_url":60,"created_at":61,"category":13},"499d414d-4573-44b3-a643-dbfb8c269d8e","anthropic-shikong-ceshi-ai-anquan-weiguo-zh","Anthropic的失控测试：AI安全还没过关","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1785931378812-l2ud.png","2026-08-05T12:02:33.709216+00:00",{"id":63,"slug":64,"title":65,"cover_image":66,"image_url":66,"created_at":67,"category":13},"ea21ed90-eaf8-4d46-97c9-4e495ed14c83","worldcup-arena-live-llm-forecasting-zh","WorldCup Arena：LLM 直播預測實測","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1785913378717-go7u.png","2026-08-05T07:02:29.072783+00:00",{"id":69,"slug":70,"title":71,"cover_image":72,"image_url":72,"created_at":73,"category":13},"fa03dc7f-4db2-4122-ab50-729e2f795964","societybench-social-event-forecasting-benchmark-zh","SocietyBench：測 LLM 社會事件預測","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1785911578272-io30.png","2026-08-05T06:32:28.944853+00:00",[75,80,85,90,95,100,105,110,115,120],{"id":76,"slug":77,"title":78,"created_at":79},"f18dbadb-8c59-4723-84a4-6ad22746c77a","deepmind-bets-on-continuous-learning-ai-2026-zh","DeepMind 押注 2026 連續學習 AI","2026-03-26T08:16:02.367355+00:00",{"id":81,"slug":82,"title":83,"created_at":84},"f4a106cb-02a6-4508-8f39-9720a0a93cee","ml-papers-of-the-week-github-research-desk-zh","每週 ML 論文清單，為何紅到 GitHub","2026-03-27T01:11:39.284175+00:00",{"id":86,"slug":87,"title":88,"created_at":89},"c4f807ca-4e5f-47f1-a48c-961cf3fc44dc","ai-ml-conferences-to-watch-in-2026-zh","2026 AI 研討會投稿時程整理","2026-03-27T01:51:53.874432+00:00",{"id":91,"slug":92,"title":93,"created_at":94},"cf046742-efb2-4753-aef9-caed5da5e32e","adaptive-block-scaled-data-types-zh","IF4：神經網路量化的聰明選擇","2026-03-31T06:00:36.990273+00:00",{"id":96,"slug":97,"title":98,"created_at":99},"53a0dc54-0371-4e40-8d5e-74e94a73840c","geometry-aware-similarity-metrics-for-neural-representations-zh","超越距離測量：用微分幾何重新理解神經網路","2026-03-31T06:01:01.241968+00:00",{"id":101,"slug":102,"title":103,"created_at":104},"fee7d472-a775-4b1d-bbc2-1e8bca1bbf8b","on-the-fly-repulsion-in-the-contextual-space-for-rich-divers-zh","讓AI繪圖更有創意：用排斥力提升生成多樣性","2026-03-31T06:01:25.439673+00:00",{"id":106,"slug":107,"title":108,"created_at":109},"a9901203-d69b-447b-8854-15d14eab32b4","vision-aided-beam-prediction-cnn-eca-zh","影像輔助波束預測升級 CNN","2026-04-01T10:00:25.8073+00:00",{"id":111,"slug":112,"title":113,"created_at":114},"b55e7dd4-0a24-4b3d-804d-b0309a03f498","triple-band-fss-mimo-antenna-sub-6-ghz-zh","三頻 FSS MIMO 天線瞄準 sub-6 GHz","2026-04-01T13:18:36.857305+00:00",{"id":116,"slug":117,"title":118,"created_at":119},"f68290bd-e7f3-4b30-ba22-dcd4e0130a66","openclaw-1299-repos-eight-weeks-analysis-zh","OpenClaw 1299 個 Repo 的資料解讀","2026-04-02T05:03:45.208411+00:00",{"id":121,"slug":122,"title":123,"created_at":124},"ed9f80eb-eb02-4d35-8ad4-0ddf428751dd","beam-coherence-aware-combining-mmwave-mimo-zh","毫米波 MIMO 的雙階合併法","2026-04-02T05:27:26.897188+00:00"]