🧭 這到底是什麼（白話版）
這篇文章在講一件事：有位工程師（ryanzhou）把一顆304B（3040億參數）的大型語言模型DeepSeek V4 Flash，直接塞進一張AMD的MI300X顯卡裡跑正式服務，而且沒有做任何量化把模型參數從精細的數字壓縮成粗略一點的數字，檔案變小、速度變快，但可能損失一點準確度，也沒有把權重搬到別的地方，模型是「原封不動」整包塞進顯卡的HBM顯示卡上直接焊在GPU旁邊的高速記憶體，用來放模型權重和運算過程用的暫存資料裡。
這件事值得拿出來講的原因是：官方原廠的部署教學（vLLM）主要是為NVIDIA顯卡寫的，比較新的AMD顯卡才有官方配方，MI300X這張卡加上這顆模型的組合，官方完全沒有現成教學，作者得自己動手修補好幾個底層問題，才能穩定上線。
這顆模型是MoE（混合專家）把模型內部拆成很多小塊「專家」，每次回答問題只喚醒其中幾個專家做事，不用整顆模型全部動起來架構，理論上算力需求比同樣參數量的傳統模型低。但不管架構多聰明，3040億個參數的「重量」都得先塞進記憶體裡，這就是為什麼「這張卡的記憶體到底有多大」變成整篇文章的核心。
作者處理的修補內容包括：FP8一種只用8個位元存一個數字的精簡格式，犧牲一點精確度、換取更省記憶體、算得更快格式不相容、多專家路由在高併發同一時間有好幾個人同時在使用同一個服務、共享同一份運算資源下出錯、生成內容的驗證機制、還有記憶體同步問題，最後把整套修好的版本用Docker Compose一種用一份設定檔就能把整套軟體環境（作業系統、函式庫、版本）打包起來、讓別人一鍵重現的工具和版本雜湊值釘死，讓別人也能重現同一套環境。
🧠 工程思維透鏡（資深工程師看到的是什麼）
🔭 作者為什麼堅持『先修正FP8和MoE路由的正確性問題，才開始調效能』，而不是先求跑得快？
因為推測解碼、MoE路由這些機制本質上是「機率性的正確性系統」——猜錯了會重算、路由錯了會答錯，如果底層數值本來就因為FP8格式誤判而錯了，後面調得再快也只是更快地產出錯誤答案。這是資深工程師常見的紀律：效能是加分項，正確性是及格線，兩者不能倒過來做。
🔭 作者為什麼要用SHA-256把每個修補檔案的版本都釘死，包進Docker Compose，而不是寫『裝好某版vLLM就能跑』這種說明？
ROCm（AMD的運算框架）還在快速迭代的nightly階段，今天能跑的組合，明天可能因為上游更新就悄悄壞掉、或效能悄悄變差，而且不會有明顯錯誤訊息提醒你。用版本雜湊值釘死、包進可重現的容器設定，是用『環境凍結』換取『別人真的能重現同一套結果』，這是基礎建設思維，不是應用程式思維。
🔭 文章特別提到把『長prefill（長文章輸入）上限設定在1,024 token』，這樣不是讓長文章的使用者要等更久嗎？為什麼要這樣設計？
這是排程層的取捨：如果放任一個很長的請求把整張卡的運算資源獨佔太久，其他所有短請求的人都要跟著等，對『多人共享同一份運算資源』的服務來說，犧牲少數長請求使用者的一點速度，換取大多數人的服務品質穩定，是公平排程系統的常見設計邏輯。
🔭 192GB和80GB的記憶體差距，為什麼能讓『到底要不要上多卡』這整個問題直接消失？
一旦記憶體大到能整包裝下模型權重，不需要搬移權重（offload）、不需要多卡協調通訊，整個部署複雜度是斷崖式下降，而不是漸進式改善——這說明資源規劃時，跨過某個關鍵門檻，常常能直接消滅一整類的工程複雜度，而不只是讓某個指標變好一點點。
📝 隨堂考（點選答案，立即回饋）
Q1. 文章提到，同一份模型權重「原封不動」放進AMD顯卡卻可能算出錯誤答案，最主要的原因是什麼？
✅ MI300X用的是AMD/Graphcore的fnuz版E4M3格式，跟比較新的AMD顯卡採用的OCP標準格式不同，如果程式碼假設是OCP格式去解讀數字，換算出來的縮放係數會差到兩倍，這種錯誤不會讓程式當掉，卻會讓答案悄悄變錯，非常危險。
Q2. 如果顯卡記憶體不夠大，裝不下一個大模型的全部權重，業界常見的兩種因應做法是什麼？
✅ 文章特別強調這次是「沒有額外做量化、也沒有把權重搬出去（offload）」，直接整包塞進去，這剛好凸顯出：通常記憶體不夠時，工程師才需要用量化或offload來讓模型『瘦身』或『搬家』，而這次是因為卡的記憶體夠大，才省掉了這一步。
Q3. 文章中64人同時衝進來的壓力測試，結果是「沒有OOM（記憶體爆掉）、沒有引擎錯誤」，這個結果代表的工程意義最接近下列何者？
✅ 這個結果不是運氣，而是前面設定的『2,048 token排程預算』『1,024 token長prefill上限』『20GB KV pool＋96GB CPU層快取分級』等設計，正是為了在爆量時還能守住系統不崩潰，這是壓力測試在驗證『設計有沒有真的生效』。
Q4. 文章一直強調「先確保正確性，再調效能」的順序，這個原則最主要是為了避免什麼情況？
✅ 效能調校讓系統『跑得快』，但如果FP8精度、MoE路由這些底層邏輯本來就算錯了，調得再快也只是『更快地算出錯誤答案』，而且這種錯誤通常不會讓程式崩潰，使用者很難察覺，所以正確性必須排在效能前面。
Q5. 從這篇文章的案例，在幫公司評估要採購哪張AI顯卡時，可以多問自己哪一個關鍵問題？
✅ 文章的核心案例就是：MI300X的192GB記憶體讓一整顆3040億參數的模型可以單卡塞下，不用搞多卡或offload的複雜工程，這說明採購時『記憶體容量夠不夠裝下模型』常常是比算力數字更早決定成敗的關鍵問題。