Awesome-LLM 把研究變地圖

以前 LLM 資料散成一地連結，現在可以照著一張地圖去找論文、工具、評估和模型。

我最近一直在整理 LLM 相關連結，整理到有點火大。瀏覽器分頁一開就是一串，GitHub stars 存了一堆，Notion 也有，但每次真的要找東西，我還是得重搜一次。更煩的是，同一個主題會在不同地方重複出現，論文、框架、評測、模型混在一起，看起來很多，實際上很難用。我不是缺資料，我是缺一個能讓我少繞路的結構。

後來我看了 Hannibal046 的 Awesome-LLM，才發現這種整理法其實很務實。它不是在炫技，也不是在裝全面。它就是把 LLM 研究、工具、資料、評估、訓練、推理、應用，硬生生收進一張可走的地圖裡。這種東西對開發者最有用，因為我們要的不是收藏，是定位。

它真正做的事，是幫你少走冤枉路

Here is a curated list of papers about large language models, especially relating to ChatGPT. It also contains frameworks for LLM training, tools to deploy LLM, courses and tutorials about LLM and all publicly available LLM checkpoints and APIs.

翻譯一下就是：這份 repo 不是單純把連結丟給你，而是先幫你切好領域。你要看歷史，有歷史；你要找訓練框架，有訓練框架；你要找部署工具，也有部署工具。這種分類看起來很普通，但我真的覺得很多人低估了它的價值。因為做 LLM 最浪費時間的地方，常常不是寫 code，而是決定下一步該看什麼。

我自己以前也很愛蒐集「有用資源」，結果最後變成一個四不像資料庫。要找 benchmark，跑去翻論文；要找推理工具，混進教學文；要找模型列表，又被一堆 blog 帶偏。Awesome-LLM 的手法比較像老編輯在幫你排版：先決定主路線，再把旁枝放到對的位置。

實操上，我會把這種結構想成四層：先是「理解這個領域」，再來是「知道現在有哪些東西」，接著是「知道怎麼測」，最後才是「知道怎麼上線」。如果你的內部文件沒有這種順序，團隊成員通常只會在裡面亂逛，然後回到 Google 重搜。

• 先用分類幫人定位，再用連結幫人深入。
• 每個區塊都要回答一個問題，不要只堆資源。
• 讓人一眼看出這頁是拿來找方向，不是拿來炫收藏。

Milestone papers 不是獎盃牆，是時間線

Awesome-LLM 的 Milestone Papers 很有意思。它從 Attention Is All You Need 開始，接著排 GPT、BERT、GPT-2、T5、ZeRO、GPT-3、Switch Transformers、Codex、FLAN、WebGPT、Chain-of-Thought，一路排到後面那些你現在每天都會聽到的名字。這不是在列名單，這是在講路徑。

白話講，這種排序的價值在於它讓你看見「為什麼今天的 LLM 長這樣」。你會慢慢看懂，架構怎麼演化、規模怎麼上去、指令微調怎麼改變互動、檢索怎麼補模型短板、推理怎麼被重新定義。沒有這條時間線，你看到的只會是一堆名詞；有了它，你才知道每個名詞是被什麼壓力推上來的。

我以前帶人看模型時，最常遇到的誤會就是只看最新一代，然後對前面幾代完全沒感覺。結果一問為什麼要做 retrieval，為什麼要做 sparse experts，為什麼 instruction tuning 這麼重要，大家就開始含糊。這份 repo 的時間線很像在幫你補這塊骨架，讓你不是背答案，而是知道答案怎麼長出來的。

實操上，我會把 milestone papers 拆成三段來讀：

• 先看架構與訓練方法，搞懂模型怎麼生出來。
• 再看 scaling、instruction tuning、alignment，搞懂為什麼互動方式變了。
• 最後看 retrieval、reasoning、tool use，搞懂模型怎麼接到產品。

這樣讀，才不會把每篇 paper 都讀成孤島。

資料與評估區塊，才是我最信的部分

很多人整理 LLM 資源，最愛放模型，最不愛放資料和評估。我懂，因為模型名字最吸睛，demo 也最好看。但真正在做事情的人都知道，資料來源和評估方式才是地基。沒有這兩塊，你看到的很可能只是漂亮輸出，不是可靠系統。

Awesome-LLM 把 LLM Data 跟 LLM Evaluation 拉成正式分類，我覺得這點很對。也就是說，它直接提醒你：先別急著談模型多強，先弄清楚它吃什麼資料、怎麼測、測到什麼、沒測到什麼。這種問題如果不先問，後面很容易變成自我感覺良好。

我自己有一次在比兩個模型，一個 demo 很順，一個 demo 普通，但後者的 benchmark 和測試範圍比較完整。最後真要對內部說明，前者反而很難講清楚。那次之後我就更相信，資料與評估不是附錄，是主文。這份 repo 把它們放在前面，等於在逼你做正事。

實操寫法我會建議這樣做：

• 每個資料集都補一句：它擅長什麼、缺什麼。
• 每個 benchmark 都補一句：它最容易誤導人的地方在哪。
• 每個模型頁面都補一句：這個結果到底是靠資料、訓練，還是評估定義撐起來的。

如果你要做團隊內部的 LLM 資源頁，這一段比模型清單還重要。因為模型會換，資料和評估的思路才是真正會留下來的東西。

訓練與推理，把研究跟上線硬接起來

我最喜歡 Awesome-LLM 的另一個地方，是它沒有把研究和工程切成兩個世界。LLM Training Framework 和 LLM Inference 這兩欄，直接把現實拉進來：訓練時你要管顯存、平行化、吞吐量、分散式；推理時你要管 latency、batching、quantization、部署成本。這些東西一點都不浪漫，但都很真。

翻成白話，就是這份 repo 沒有假裝「讀完 paper 就會做產品」。很多人很愛講模型品質，講到像在選手機規格；真的上線之後，才發現卡住的是 serving、成本、debug、版本管理。Awesome-LLM 把訓練和推理放在同一張圖上，等於在提醒你：研究和生產不是兩條平行線，它們一直互相拉扯。

我以前最常遇到的狀況，是團隊很會挑模型，但沒人真的知道怎麼把它穩定跑起來。結果每次一出事，就開始怪模型、怪框架、怪 GPU，最後沒人怪自己沒先把路線圖畫好。這種時候，一份像 Awesome-LLM 這樣的整理，至少能讓大家先對齊工具鏈，再談性能。

實操上，我會建議你做一張簡單的內部表：

• 訓練框架：誰用、支援什麼硬體、學習成本多高。
• 推理框架：延遲、吞吐、部署難度、維護成本。
• 運行限制：單機、叢集、量化、快取、監控。

這張表比「這個框架很紅」有用太多了。

應用、教學、書籍，才是讓人真的上手的入口

我以前很看不起應用區，覺得那只是給初學者看的。後來我發現我錯了，至少錯一半。因為很多人不是從研究走進 LLM，而是從應用、從 prompt、從一個小工具開始。你如果只給他論文，他根本進不來；你如果只給他 demo，他又學不到為什麼。

Awesome-LLM 把 LLM Applications、Tutorials and Courses、Books 放在一起，我覺得這很老實。它承認學習路徑本來就不是單線條。有人要的是快速上手，有人要的是系統理解，有人要的是可落地的工作流。你不能拿同一種內容硬塞給所有人。

我之前幫團隊做內部分享，最常失敗的地方，就是把太多高密度內容塞在前面。結果大家聽完只記得名詞，沒記住路徑。後來我改成先放一個可以照做的應用案例，再接一個教程，最後才補書和 paper，效果差很多。Awesome-LLM 的結構其實就是這個邏輯。

實操上，你可以這樣設計自己的入口頁：

• 先放一個最容易成功的應用案例。
• 再放一個教學或課程，讓人知道怎麼走下去。
• 最後放書和深度資料，給想鑽的人。

這樣排，比把所有資源平均灑上去有效太多。

最值得抄的，其實是它的編輯手感

Awesome-LLM 最強的地方，不在於它列了多少東西，而在於它知道什麼該放主路，什麼該放支線。這就是編輯手感。你在做知識庫、團隊維基、研究索引時，真正需要學的不是「收集更多」，而是「幫別人少選幾次」。

白話講，這份 repo 教你的不是 LLM，而是怎麼做一份會被真的打開的資源頁。它把領域切成幾個高信號區塊，讓人能快速找到方向，再往下鑽。這種做法比「我把所有東西都放進來了」成熟太多了，因為後者通常只是收藏癖，不是整理。

如果我要把這套方法用在公司內部，我會固定三件事：一，分類要少而準；二，每個分類要有一句用途說明；三，每個連結旁邊都要有一句為什麼值得看。這樣做不漂亮，但真的能用。

我很喜歡這種不裝的整理法。它承認領域很亂，但還是硬把路畫出來。對開發者來說，這種東西比任何空話都有用。

可抄的模板

# LLM Resource Map for Our Team

## 這頁的用途
這是一份給開發者用的 LLM 地圖。目標不是收集最多連結，而是讓人能快速找到下一步該看什麼、做什麼、測什麼。

## 1) 里程碑論文
- [Attention Is All You Need](https://arxiv.org/abs/1706.03762) — 看架構起點
- [BERT](https://aclanthology.org/N19-1423.pdf) — 看預訓練與表示學習
- [Language Models are Few-Shot Learners](https://papers.nips.cc/paper/2020/file/1457c0d6bfcb4967418bfb8ac142f64a-Paper.pdf) — 看 scaling 與 few-shot
- [Chain-of-Thought Prompting](https://arxiv.org/abs/2201.11903) — 看推理提示法

## 2) 現在值得追的模型
- [DeepSeek-R1](https://github.com/deepseek-ai/DeepSeek-R1)
- [DeepSeek-V3](https://github.com/deepseek-ai/DeepSeek-V3)
- [open-r1](https://github.com/huggingface/open-r1)
- [TinyZero](https://github.com/Jiayi-Pan/TinyZero)
- [Kimi-K2](https://github.com/MoonshotAI/Kimi-K2)

## 3) 資料
### 我們關心的資料集
- 名稱：
- 來源：
- 適合什麼任務：
- 容易踩的坑：

## 4) 評估
### 我們信的 benchmark
- 名稱：
- 測什麼：
- 沒測到什麼：
- 什麼情況會誤導人：

## 5) 訓練
### 訓練框架
- [DeepSpeed](https://github.com/deepspeedai/DeepSpeed)
- [PyTorch](https://github.com/pytorch/pytorch)
- [Hugging Face Transformers](https://github.com/huggingface/transformers)

### 記錄欄位
- 顯存需求
- 分散式支援
- 訓練速度
- 除錯難度

## 6) 推理與部署
### 推理框架
- [vLLM](https://github.com/vllm-project/vllm)
- [Text Generation Inference](https://github.com/huggingface/text-generation-inference)
- [llama.cpp](https://github.com/ggerganov/llama.cpp)

### 記錄欄位
- 延遲
- 吞吐
- 量化支援
- 維護成本

## 7) 應用
- 內部 copilot
- 文件搜尋
- 程式碼助手
- 工作流自動化
- Agent 工具

## 8) 教學與書
- 一個入門教學
- 一個實作課程
- 一本深度書

## 9) 維護規則
- 每月檢查一次死連結
- 每個新連結都要補一句理由
- 只保留真的會被打開的內容
- 不要把收藏清單偽裝成知識地圖

## 10) 使用原則
如果一個連結不能幫人決定下一步要讀、要做、要測什麼，就先不要放進來。

這段我自己會直接拿去改。你可以把它當成團隊 wiki、研究索引，或是個人 LLM 筆記的骨架。重點不是抄連結，而是抄這種編輯邏輯。

原始來源是 https://github.com/hannibal046/awesome-llm，我這篇是根據它的 README 結構和分類方式做的拆解，內容觀點是我自己的整理，不是逐句翻譯。順手也參考了 Attention Is All You Need、Hugging Face Transformers、vLLM 和 DeepSpeed 這幾個權威連結來補完整個脈絡。