前言

前面的章節中，我們從基礎的LLM推理知識 🧠、簡單的硬體知識 💻，一路學習到一些著名的推理加速技術原理 ⚡️。

礙於技術篇即使加上一堆emoji 🎨還是很學術、掩蓋不了那些論文臭味 📚，因此這章就先來一個久違的聊天篇(X)，單純是筆者想放一些在學校和工作時不一樣的東西，順便提一下接下來實作的目標在系統中的位置。 🛠️

(圖源: memes)

💭 對系統的想像

程式碼怎麼變成服務的？對於一個初學者或非IT背景的人來說，「程式碼」可能僅僅是一行行文字，可能很難想像這些文字如何變成一個可以使用的網站或服務。

[程式碼]  ->  [??? 黑盒子 ???]  ->  [LLM 服務]

為了讓主題依舊與LLM有關，這邊就以ChatGPT為例。

• 🧑‍💻 非IT人的想像：

在非IT背景的人的眼中，軟體或系統就像一個「神奇的黑盒子」 📦，他們可能覺得只要程式碼寫好了，一切就能運行。可能會認為，只要把程式碼交給「電腦」，這個應用程式就會自動上線。

筆者為了取材，問了其中一個非IT朋友對ChatGPT網站怎麼做出來的想像，他回答了「感覺會有很多數據在跑，每天都在更新，連了google資料庫，然後把很多詞語做分類，再根據用戶的回答抓詞語，把他拼起來」，問了其他人也都回答：「資料庫？？」

其實這算是古代的NLP方法，AI和LLM對一般人來說還是很大的黑盒子，如果要解釋就要從神經網路的發展開始說起，請參考yt李宏毅教授的2024生成式AI導論XD。

如果進階一點問他對系統架構的想像、像是你的電腦到他們的電腦中間的架構，對方只回答了「嗯……連網路？」。

雖然不算是錯，只能說......架構對一般人來說真的非常抽象。

[程式碼]  ->  [電腦/網路]  ->  [資料分類、更新、資料庫]  ->  [LLM 服務]

• 🎓 大學生的想像：

許多資訊科系的學生可能認為，寫完程式碼後，只需「執行」程式，系統就可以工作。然而，他們往往忽略了如何讓這些程式能夠服務全球的user 🌐。對於部分學生來說，他們的想像可能僅僅停留在「我寫好了一個網站，這就是它了，歐耶！！」，忽略了背後的伺服器和部署過程。

至於怎麼上線的話，很多學生可能會對server、API有些概念，不過實際上還有很多細節在裡面！！

伺服器並不是憑空出現的，它需要在特定的環境中搭建。這可以是在 💻 地端的機器上設置伺服器，也可以是選擇 ☁️ 雲端服務供應商（如 AWS、Google Cloud 或 Azure）來建立虛擬伺服器（VM）。
而API是伺服器與其他服務之間的橋樑 🌉，它規定了如何進行請求和回應 🔄。

不過筆者大學時沒有很認真，只知道可以部屬在Google Cloud平台上，只要把他們放上去自然就可以使用了，中間的過程從來沒去深入了解過，畢竟平台不是我們建立的(˘･_･˘)。

[寫程式]  ->  [伺服器/雲端環境]  ->  [LLM 服務]

• 💼 工作後：

在實際的工作中，程式碼必須經過一系列的步驟才能成為一個服務。首先要編譯、測試、打包，然後將其部署到伺服器上，可能涉及容器化技術（如Docker），還要配置雲端或伺服器環境、設定網路、流量分配，最後才能將應用部署為一個可以對外提供服務的系統。

在大公司，這些環境設計的工作通常由infra團隊負責，其他工程師只需使用已建立好的環境進行開發與部署。最大的挑戰之一是在工作中學習整體的系統架構，尤其是容器的概念。

在學校時，這些知識可能還不夠具體，但實際工作中才真正了解到容器在環境管理中的關鍵作用，它最主要是解決了「開發環境與生產環境不一致」的問題，即使在不同系統中，部屬上也不會遇到環境衝突的問題。

[程式碼]  ->  [編譯]  ->  [測試]  ->  [打包]  ->  [容器化]  ->  [伺服器 / VM / Kubernetes]  ->  [網路與分流]  ->  [負載均衡]  ->  [LLM 服務] ->  [LLM 服務監控]

• 🤖 LLM服務架構 - 以RAG為例

接下來的實作部分的目標是希望可以在一個應用系統當中做到跟OpenAI的API一樣的事情，也就是在伺服器上面部屬local LLM的API。

以下圖為例，RAG算是前面系統中的[LLM 服務]，在RAG架構中有非常多步驟，而最關鍵的就是服務怎麼與LLM溝通，而這通常都是做成API方便你使用。當然目前已經有很多實作框架可以做到開API這件事情，而在選擇框架和配置這些API時，用到的知識便是前面19天的所學。

因此接下來的實作文章中，讀者可能會需要對API、Docker有些簡單的概念。

(圖源: 隊友筆繪製)

🖥️ 開發環境

在學校裡，我們通常只關心「能不能跑」這件事，根本沒有環境的區分，開發的地方就是demo的地方，但在工作中，環境的區分非常重要。一般情況下，開發環境（DEV）、測試環境（TEST）、生產環境（PROD）是嚴格分開的，而每個環境有不同的用途。

• 🛠️ DEV：工程師在這裡撰寫程式與測試。

• 🧪 TEST：工程師會在這裡檢查功能是否正常。

當然每一間公司的開發環境會有不同選擇XD，筆者有朋友是先在TEST開發才去DEV測試，最後才上PROD；也有朋友的公司有多UAT：用來給客戶或最終使用者驗收測試的環境。

• 🚀 PROD：最終服務的運作環境，所有的變更都需要嚴格審查後才會部署到這裡。

在筆者剛開始工作時對這些都沒什麼概念，要了一個API不知道那是TEST的API，結果上PROD之後才發現用到的是TEST API，不小心出事，因為整個資料在API team做其他測試時變得超級怪XD

🏗️ 對服務/基礎建設的管理

當一個系統上線後，持續監控與管理是工程師每天的工作之一。在學校的專題只需要開發到可以動就好了，但在工作中，系統需要24小時穩定運行。服務的監控可能會有很多不同的工具（如Prometheus、Grafana等）來檢查系統的效能、錯誤log和使用情況，一旦出現問題，on-call的工程師必須立即做出處理，這算是一項很大的責任，並且需要熟悉系統整體的細節。

不管是基礎建設或是服務都需要了解整體的架構，關於監控的錯誤訊息和處理方式都必須要了解，通常是寫成SOP方便一線人員處理，如果他們處理不了，才會call到on-call的工程師上。

💡 其他 - 非程式能力的部分

當初在工作前對工程師的想像是一整天都在寫code，然而實際工作後才發現根本沒有這麼單純R！

每個公司的組成和風格都不一樣，且常常會有需要合作的不同team的對象，工作過程中慢慢地會發現一些重要的事情，像是與人溝通、請人幫忙的方法（包含不想合作的人，或是請假可能要找人backup時也要拜託一下XD），剛開始工作時覺得時間都花在會議裡面很浪費，但後來發現公司是否有資訊透明化其實超重要的。而這些都攸關著領導著的能力，好的工作最大的重點是好的領導者，不過很多時候都是靠運氣抽卡的(╯▽╰ )。

雖然這段跟本系列沒什麼關係，想特別紀錄分享一下看到覺得寫得不錯的這系列。
邁向Tech Leader的成長之路
即使不一定會當tech lead，但感覺在未來的幾年後可以隨時參考學習裡面的很多職涯建議XD

章節總結

以上是很菜的筆者在工作這段時間內感覺到其中與學校的一點不同之處 🏫➡️💼，並且提了一下有關API和Docker的簡單概念，這也是後續的文章會使用到的。雖然還有很多可以說的，像是 🛠️code quality、 📊unit test等等，這些學校沒有特別教的東西，不過與本系列並沒有太大的關係，主要是筆者也沒有很擅長XD，就沒有特別去寫了。

最後，明天的內容將回到推理加速框架的比較上！ 🔍⚡