分類: 技術

AI 搶飯碗!

本來今天打算整理一篇以前的讀書心得, 不過 AI 搶軟體工程師飯碗這件事對我還滿有衝擊的, 所以特別紀錄一下.

今天是十天連假的收假日, 不小心打開很久沒玩的數獨 (Sudoku), 發現竟然有對戰模式, 可以跟外國真人對戰! 這個比寶可夢的對戰刺激多了, 所以我馬上跟配對的老印、老法、老德殺起來! 前幾戰的對手超弱, 但後面的對手滿強的, 幾乎是分秒必爭. 稍微分心一點點就輸了. 畢竟我好久沒玩了, 反應慢很多, 只得到 16 勝 8 敗就想趕快休息. 不然萬一心臟負荷不了猝死就划不來了. 這樣以後人家問起老爸的死因, 女兒只能說死於某一波寒流這樣塘塞過去.

(對了, 此遊戲選台灣會變成中國的一部分, 所以我推薦女兒玩, 結果她選冰島籍).

接著我發現電腦的 ChatGPT 窗口還沒關, 順便就問它, “can you resolve a sudoku?", 然後奇妙的事情發生了. 我知道 ChatGPT 會寫程式, 但我只是隨 “口" 問問, 它就把程式寫好了. 看來不只是可以幫我們交訓練課程的心得報告而已. 連我們以後上機考試要更嚴格防弊了….哈!

Yes, a sudoku can be resolved using algorithms such as backtracking, constraint propagation, and search. Here’s an example of a simple backtracking solution in Python:

哇! 架構都出來了! 稍微把那多餘的 return 拿掉, 加個 class 的殼, 程式就能用了. 不求任何優化, 只要把題目的 array 輸進去, 答案立馬出來.

這有什麼啟示呢? 我想大理工時代將要隨著 AI 的興起而沒落了. 基本上, 現在電資的學生不分良窳, 幾乎都比文組有職場競爭力. 不過 AI 的程式都寫得比人類又好又快了, 那自然也就不需要這麼多就業人口了. 雖然文組可能會丟掉飯碗 – AI 當小編, AI 寫文案, AI 寫專欄, ….. 不過近年風光無限的理工同學, 真的要當心 AI 寫程式、畫 layout 這些變化. 基本上這都還算是初階. 等到它會分析 bug, 連資深同仁的工作可能都不保了. 至於 PM, …可能可以再撐一陣子, 但是前途也是堪慮. 所以…人脈很重要, 這個 AI 取代不了~~~哈!

自製 mini ChatGPT

根據 [1], 決定自製一個 mini ChatGPT. Afiz 的流程如下:

首先在 Anaconda 中 pip install openai 就失敗, 原來要用 conda install -c conda-forge openai [2].

pip install gradio 沒問題

from config open_api_key 一看就不合用! 看 [2] 裡面的說明, 要先參加 OpenAI會員. 這個我已經註冊過了. 登入後, 可以在 https://beta.openai.com/account/api-keys 產生 key. 然後把 key 設為環境變數 %OPENAI_API_KEY%.

後面照抄 [4], 可是出現 check internet connection. 暫時卡住.

這要怎麼 debug 呢? 因為是抄的, 所以有點不明就裡. 乾脆來問 ChatGPT 本人要怎麼呼叫它? 然後它就大方地給我一個 sample code. 這感覺就是 “玄 “!

import os
import openai

openai.api_key = os.getenv("OPENAI_API_KEY")
response = openai.Completion.create(
    model="text-davinci-003",
    prompt="The following is a conversation with an AI assistant. The assistant is helpful, creative, clever, and very friendly.\n\nHuman: Hello, who are you?\nAI: I am an AI created by OpenAI. How can I help you today?\nHuman: I'd like to cancel my subscription.\nAI:",

    temperature=0.9,
    max_tokens=150,
    top_p=1,
    frequency_penalty=0.0,
    presence_penalty=0.6,
    stop=[" Human:", " AI:"]
)

不過, 這段程式還是有個相容性問題. 它說 Anacoda 裡面有段 source code 開檔預設是 latin-1, 不是 UTF-8. 這…這我 debug 不了啊? 查一下午資料, 都說要改 mysql database 那邊的設定.

UnicodeEncodeError: 'latin-1' codec can't encode character '\u201c' in position 7: ordinal not in range(256)

好在我到處 Google 找到了另外一篇中文教學 [5], 它的範例不會打到上面那個 bug. 所以狗哥不用怕, 裁員一次就好, ChatGPT 暫時還不能把你幹掉. 仔細比較兩個程式, 目前認為還是 export private key 沒有成功, 所以暫時用明碼才能夠連線的關係. 這樣總算在過年假期當中, 把 OpenAI 的探索前進了一小步! 現在它可以講笑話了, 雖然要等 2~3 秒.

[REF]

  1. https://twitter.com/itsafiz/status/1610245691812741120
  2. https://anaconda.org/conda-forge/openai
  3. https://help.openai.com/en/articles/5112595-best-practices-for-api-key-safety
  4. https://github.com/afizs/chatgpt-clone/blob/main/mini_ChatGPT.ipynb
  5. https://steam.oxxostudio.tw/category/python/example/openai.html

LeetCode 小體驗

話說我摸了一陣子 Python, 那要算會? 還是不會呢? 稍微 Google了一下相關資料, 臉書的廣告就變成各種 Python 補習班了. 當然, 要我花錢去補習或是考照那是絕不可能的! 好歹我還曾經贓到過 Sun 認證的第一代 Java 講師稱號呢, 怎麼可以從講師變學徒呢? 至少要自修吧! 哈! 但是誰可以幫我鑑定一下我的水準呢? 我靈機一動就想到了 LeetCode.

如果我用 Python 來解 LeetCode 的題目 [1], 不就知道自己的水準好不好了嗎? 於是乎我找出註冊 N 年還沒開工過的 LeetCode 帳號, 選用 Python3 來作答. …..嗯, 果然程度不太好. 雖然看過一些 code, 也把教學 [2] 讀完了. 不過還是不能得心應手.

尤其第一次做, 我還不知道題目下面就有 test case, 也不知道不用自己寫輸出入 UI, 只要 function 吃到參數就好. 所以花了很多時間設計怎麼輸入 list 最 user friendly, 結果不但做白工, 還判失敗~~ 結果拔一拔反而 pass 了. 完全在搞笑!

所以提醒初學者, 先選選擇難度. 然後挑個自己想解的題目.

點進去之後. 可以選各種語言. 下面有 test case. 右下角選 run, 然後看 Result 對不對? 對的話就可以按綠色的 Submit. 如果選 auto, 電腦可以自動幫忙完成, 當然那也要花錢錢. 點選題目也可以看別人的解答, Stackoverflow 也一堆解答. 不過我第一個程式當然要自己摸索~~ (當然也就搞笑了).

Accept 之後, 系統還會說明執行速度和使用 memory 兩方面贏過多少人? 這個要拚的話當然是可以再努力. 不要 init class 也可以變快一點 (^^). 另外, 我傻傻地用初學時的 Jupyter Notebook 打草稿, 這樣連 list 都要 import 才編得過. 但是在 LeetCode 卻都可以忽略. 果然是有差!

Anyway, 我第一次 run LeetCode, 而且是用 Python. 這還滿值得我記錄的, 算是 2023 年的新年新把戲!

[REF]

  1. https://leetcode.com/problemset/all/
  2. https://docs.python.org/zh-tw/3/tutorial/index.html

UCIE 小整理

新 IC 非常順利, 好像不需要額外的關注. 於是來看一下 UCIE 說什麼? 上次研讀了 chiplet, 這次的 UCIE (universal Chiplet Interconnection Express) 就是用來規範 chiplet 如何連接. 特別有趣的是, 有別於上次舉的都是 AMD 的例子, UCIE 則是 Intel 所主導的. Contribution member [1] 包括咱們的同業: Broadcom, MTK, Marvell; IP 公司 Synopsys, Cadence 等等. 沒有 AMD!

按照 [2] 的說法, 大公司將比照 Apple, 跳過 IC 設計公司, 自己做產品. 在分工上, 依然維持 fabless, 例如 Apple, AMD 都是. 但是產品由自己定義, 甚至也不用讓 ODM 賺一手. 只要把 HW IP 兜起來, 然後找 TSMC 做 IC 和封測, 自己出 HWSD 設計系統, 發包給 OEM 生產即可. 這樣技術都在自己家裡.

當然, 如果這個趨勢成真, 那 fabless IC design house 大概就沒飯吃了, 只能吃雜糧配菜. 舉例來說, Meta 要建立元宇宙用的資料中心, AMD 出 chiplet 來搶單, 第二代 EPYC 把 CPU/DDR 都用封好了, 外面有自家 interface 可以接網路 PHY, GPU, NPU 這些, layout 都固定了, 系統廠根本賺不到設計費. 更不干 design house 什麼事. 如果 IC design house 沒有符合 chiplet 互通標準的 die 可以賣給 AMD (舉此處資料中心的例子), AMD 絕不可能直接跟螃蟹公司買 Gigabit IC, 因為它不要封裝好的, 只要 known good die.

根據 UCIE 白皮書, 製程愈先進, 軟體愈貴 – 占用整個 design cost 的比重愈高, 驗證則居其次. 這個問題如何解決呢? 幫 SWSD 加薪嗎? 嗯, 但願如此. 白皮書的看法是簡化連接方式, 把它做到極簡, 就不容易出錯.

白皮書裡面有一張類似的圖, 但下圖這張 (取材自 [4]) 比較簡單. 在 UCIE 1.0 裡面, 最上層可以看到 PICE, CXL (Computer Express Link) 等知名 protocol. 其中 streaming protocol 是用來 mapping 到其他規格用的. 多種規格都以 256 byte Flow control Unit (FLIT) 為單位傳到 Die-to-Die Adapter. 其中 FDI 是 FlIT awared D2D interface. D2D adapter 負責處理繁瑣的資料處理, 然後透過 RDI (Raw D2D interface) 跟真正的 PHY 溝通.

資料傳到 PHY 這邊並不是終結, 而是 UCIE interconnect 到另外一個 die.把這些 die 都封裝起來, 是一個 2D/2.5D/3D 的 SOC. UCIE 在此提供 on package 的整合規範.

舉例來說, 下圖是一個伺服器的機架, 我們在電影裡也會看到. 主角想拔出一個抽屜 (drawer), 阻止 AI 電腦的運作. 在 UCIE 的架構下, 可能一個槽全是 (non-volatile) memory/storage, 另一槽全是 CPU/NPU 之類的. 彼此之間透過 UCIE off package 的方式溝通. 所以時間有限的話, 要拔對抽屜才能拯救世界!

最後, 這整件事對 fabless IC design house 有什麼意義呢? 那就是在大廠自己開 IC 的情況下, 設法做一些 chiplet 賣給他們, 多少能賺一點. 需要改變的是: 把手上的 IP 做成 chiplet die, 支援任何一種 chiplet interconnection protocol, e.g. UCIE, 並推銷出去. 我猜 CP 的驗證也要做得好, 但不用管 FT 了吧 (?).

[REF]

  1. https://www.uciexpress.org/copy-of-membership
  2. https://www.inside.com.tw/article/29275-behind-intel-ucle
  3. https://www.uciexpress.org/_files/ugd/0c1418_c5970a68ab214ffc97fab16d11581449.pdf
  4. https://www.edntaiwan.com/20221021nt61-ucie-spec-for-developing-a-chiplet-design/

Chiplet 小整理

今天跟前同事吃晚餐, 討論到 chiplet 這個東西, 感覺滿有趣的, 最近想花一點時間來整理. 不過更深入的研究要等我們新 IC Danvers bring up 以後才可以. 剛剛在辦公室玩了一下 Android 12 還跑得滿順的, 把進度寫到月報寄出, 就來 Google chiplet, 順便做個紀錄. 接下來有空再看進階的 UCIE.

Chiplet 的誕生主要考量到單一顆大晶片的良率會降低, 於是把 “traditional monolithic" 這樣的 IC 拆成 4 顆來實作. EPYC 是 AMD 的 server 級 processor. 拆成 4 顆之後. 面積由 777 mm2 長到 852 mm2. 算起來胖了 10%. 下圖取材自 [1].

但 IC 變胖不是天險, 在每顆小 IC 裡面, 我們可以看到 IO, 類比的東西其實是可以抽出來的. 於是乎 4 小 IC 不用長得很像, 而是像拼圖一樣取最大綜效. 下圖同樣取材自 [1], 但是為了避免抄襲太嚴重, 我講一些原來沒有的.

圖片中橘色的部分叫做 CCX (Zen CPU Complex) [2], 多 complex (複雜)呢? 每個 CCX 都有 Core 和 private L2 cache 和 shared L3 cache, 所以 Core+Cache 這樣 CC 地複雜, 就叫做 CCX. 然後也看到一個藍框裡面有白色無限大符號, 那個叫做 Infinity Fabric [3], 這是個 AMD 傳送資料 (Scalable Data Facric) 和控制訊號 (Scalable Control Fabric) 的架構, 可以讓 CPU, GPU, 和其他 IP 互傳. 以上都是 AMD 獨有的術語, 但是概念可以推廣. DDR 就是記憶體的那個 DDR.

然後, 我們又知道 DDR 的特性沒辦法走到最新進的製程 (電容小速度快, 但是電容小充不多), 所以把 DDR 挪到中間去, 用比較舊的製程 (14 nm), CCX 用比較新的製程 (7 nm). 這樣成本據說還可以變成一半. 當然封裝的難度就增加了. 但 chiplet bonding (3D 封裝) 也是最近當紅的技術 [4].

[REF]

  1. https://www.eettaiwan.com/20210305nt01-amd-shows-its-chiplet-playbooks-at-isscc/
  2. https://fuse.wikichip.org/news/1177/amds-zen-cpu-complex-cache-and-smu/
  3. https://en.wikichip.org/wiki/amd/infinity_fabric
  4. https://www.cadence.com/content/dam/cadence-www/global/en_US/documents/tools/ic-package-design-analysis/chiplets-and-heterogeneous-packaging-are-changing-system-design-and-analysis.pdf