Tensor Processing Unit (TPU) ตัวแรกของ Google: สถาปัตยกรรม

 (thechipletter.substack.com)
1 คะแนน โดย GN⁺ 2024-03-26 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Google TPU v1 เป็น ASIC ที่พัฒนาขึ้นภายใน 15 เดือนตั้งแต่ปลายปี 2013 เพื่อรองรับ ต้นทุนและขนาดของงาน inference สำหรับบริการดีปเลิร์นนิง โดยตั้งเป้าความคุ้มค่าต่อราคาสูงกว่า GPU 10 เท่า
  • แกนหลักคือการนำ systolic array จากงานปี 1978 ของ H.T. Kung และ Charles E. Leiserson มาสร้างเป็นโครงสร้าง MAC แบบ 256×256 เพื่อลดการไปกลับของผลลัพธ์ระหว่างทางระหว่างหน่วยความจำขณะทำเมทริกซ์คูณ
  • TPU v1 สื่อสารกับโฮสต์ผ่าน PCIe เก็บค่าน้ำหนักไว้ใน DDR3-2133 และจัดลำดับการทำงานของ inference ด้วยคำสั่งจำนวนน้อย เช่น Read_Host_Memory, Read_Weights, Matrix_Multiply / Convolve, Activate, Write_Host_Memory
  • ใช้การคูณจำนวนเต็มแบบ 8-bit×8-bit และ quantization เพื่อหลีกเลี่ยงภาระด้านพื้นที่ไดของการคำนวณแบบ floating point พร้อมให้ User Space Driver และ Kernel Driver ที่ทำงานร่วมกับ TensorFlow ควบคุมการรัน
  • Intel Haswell CPU และ Nvidia K80 GPU เป็นคู่เทียบในเวลานั้น โดย TPU v1 เร็วกว่าในการทำ inference ราว 15~30 เท่า และมีสมรรถนะเพิ่มขึ้นต่อวัตต์เมื่อเทียบกับ GPU สูงกว่า 25~29 เท่า แต่ไม่ได้เป็นอุปกรณ์สำหรับเทรนโมเดล

จุดเริ่มต้นของ TPU v1 เพื่อลดต้นทุน inference

  • เป้าหมายของโครงการ TPU v1 คือการสร้าง ASIC สำหรับ inference อย่างรวดเร็ว เพื่อลดต้นทุนฮาร์ดแวร์ขนาดใหญ่ที่บริการซึ่งใช้ดีปเลิร์นนิงต้องการ
    • เป้าหมายเชิงตัวเลขคือมี ความคุ้มค่าต่อราคา ในงาน inference สูงกว่า GPU 10 เท่า
    • ต้องตอบโจทย์ทั้งการพัฒนาอย่างรวดเร็ว ประสิทธิภาพสูง การใช้งานในวงกว้าง การรองรับเวิร์กโหลดใหม่ได้ทันที และความคุ้มค่าด้านต้นทุน
  • ชื่อ TPU มาจากการเป็นอุปกรณ์ที่เร่งการคำนวณแบบ tensor
    • การคำนวณหลักที่ฮาร์ดแวร์ TPU v1 จัดการจริงส่วนใหญ่คือ การคำนวณเวกเตอร์และเมทริกซ์
    • ชั้นซ่อนและชั้นเอาต์พุตของโครงข่ายประสาทสามารถเขียนให้อยู่ในรูปผลลัพธ์ของการนำฟังก์ชันกระตุ้นไปใช้กับผลคูณระหว่างเวกเตอร์อินพุตกับเมทริกซ์ค่าน้ำหนัก
    • เมื่อมีข้อมูลอินพุตหลายชุด ก็จะอยู่ในรูปของการนำฟังก์ชันกระตุ้นไปใช้กับแต่ละค่าของผลลัพธ์จากการคูณเมทริกซ์

ประมวลผลเมทริกซ์คูณด้วย systolic array

  • TPU v1 ใช้แนวคิด systolic system จากบทความปี 1978 Systolic Arrays (for VLSI) ของ H.T. Kung และ Charles E. Leiserson
    • เป็นโครงสร้างที่โปรเซสเซอร์หลายตัวคำนวณและส่งต่อข้อมูลตามจังหวะที่สม่ำเสมอ
    • โปรเซสเซอร์แต่ละตัวทำการคำนวณสั้น ๆ พร้อมกับเคลื่อนย้ายข้อมูลเข้าออกอย่างต่อเนื่อง
  • ในตัวอย่างการคูณเมทริกซ์ 2×2 แบบง่าย หากป้อนข้อมูลจากด้านบนและด้านซ้ายตามลำดับที่ถูกต้อง ผลลัพธ์จะออกมาจากอาร์เรย์ MAC 2×2 ได้อย่างเป็นธรรมชาติ
    • แต่ละ MAC ทำหน้าที่คูณและสะสมค่า
    • ผลรวมย่อยจะถูกเก็บไว้ภายในอาร์เรย์ และผลลัพธ์สุดท้ายจะปรากฏในลักษณะเส้นทแยงที่เคลื่อนที่ไป
    • ตัวอย่าง 2×2 ต้องใช้ 4 ขั้นตอน แต่ในทางปฏิบัติ เมื่อ MAC มุมซ้ายบนว่าง ก็สามารถเริ่มการคูณเมทริกซ์ชุดถัดไปได้ทันที ทำให้เริ่มงานคูณเมทริกซ์ใหม่ได้ทุก 2 ไซเคิล
  • แกนสำคัญคือ เมื่อป้อนข้อมูลเข้าสู่ systolic array ตามลำดับที่ถูกต้อง การไหลของค่าและผลลัพธ์เองจะสร้างลำดับการคำนวณที่ต้องการ
    • ไม่จำเป็นต้องบันทึกผลลัพธ์ระหว่างทางลง main memory แล้วดึงกลับมาอีกครั้ง
    • ด้วยโครงสร้างของหน่วยคูณเมทริกซ์และลำดับอินพุต ผลลัพธ์ระหว่างทางจะพร้อมใช้งานโดยอัตโนมัติในเวลาที่ต้องใช้

โครงสร้างระบบของ TPU v1

  • TPU v1 สื่อสารกับคอมพิวเตอร์โฮสต์ผ่านบัสอนุกรมความเร็วสูง PCIe และเข้าถึง DDR3 DRAM ของตัวเองได้โดยตรง
  • องค์ประกอบหลักมีดังนี้
    • DDR3 DRAM / Weight FIFO
      • ค่าน้ำหนักถูกเก็บไว้ในชิป DDR3 RAM ที่เชื่อมต่อผ่านอินเทอร์เฟซ DDR3-2133
      • หลังจากโหลดล่วงหน้าจากหน่วยความจำของโฮสต์ผ่าน PCIe แล้ว จะถูกย้ายไปยัง Weight FIFO เพื่อให้ Matrix Multiply Unit ใช้งาน
    • Matrix Multiply Unit
      • เป็น systolic array ที่ประกอบด้วย MAC 256×256
      • รับค่าน้ำหนัก 256 ค่าเข้าจากด้านบน และรับข้อมูลอินพุต 256 ค่าเข้าจากด้านซ้าย
    • Accumulators
      • เก็บผลลัพธ์ที่ออกมาจากหน่วยเมทริกซ์แบบ systolic ด้านล่าง
    • Activation
      • เป็นขั้นตอนที่ใช้ฟังก์ชันกระตุ้นของโครงข่ายประสาท
    • Unified Buffer / Systolic Data Setup
      • เก็บผลลัพธ์หลังผ่านฟังก์ชันกระตุ้น และเตรียมป้อนกลับเป็นอินพุตของ Matrix Multiply Unit สำหรับการคำนวณชั้นถัดไป

รูปแบบการคำนวณและชุดคำสั่ง

  • Matrix Multiply Unit ของ TPU v1 ทำ การคูณจำนวนเต็มแบบ 8-bit×8-bit
    • ใช้ quantization เพื่อหลีกเลี่ยงการคำนวณแบบ floating point ที่ต้องใช้พื้นที่ไดมากกว่า
  • ชุดคำสั่งเป็นการออกแบบแบบ CISC ที่มีคำสั่งราว 20 คำสั่ง
    • คำสั่งไม่ได้ถูกดึงจากหน่วยความจำ แต่โฮสต์คอมพิวเตอร์จะส่งมาผ่าน PCIe
  • โฟลว์ของ inference ส่วนใหญ่ประกอบด้วย 5 คำสั่งหลัก
    • Read_Host_Memory
      • อ่านอินพุตจากหน่วยความจำของโฮสต์ผ่าน PCIe เข้าสู่ Unified Buffer
    • Read_Weights
      • อ่านค่าน้ำหนักจากหน่วยความจำค่าน้ำหนักเข้าสู่ Weight FIFO
    • Matrix_Multiply / Convolve
      • ส่งอินพุตจาก Unified Buffer ไปยัง Accumulators พร้อมทำการคูณเมทริกซ์หรือคอนโวลูชัน
      • คูณอินพุตขนาด B×256 กับค่าน้ำหนักคงที่ขนาด 256×256 เพื่อสร้างเอาต์พุตขนาด B×256 และใช้เวลา B pipeline cycles
    • Activate
      • ใช้ฟังก์ชันไม่เชิงเส้นของ artificial neuron เช่น ReLU, Sigmoid กับอินพุตของ Accumulators แล้วส่งผลลัพธ์ไปยัง Unified Buffer
    • Write_Host_Memory
      • เขียนผลลัพธ์จาก Unified Buffer กลับไปยังหน่วยความจำของโฮสต์ผ่าน PCIe
  • โฟลว์นี้สามารถมองได้โดยคร่าว ๆ ในรูปแบบต่อไปนี้
Read_Host_Memory
Read_Weights
Loop_Start
    Matrix_Multiply
    Activate
Loop_End
Write_Host_Memory
  • หน่วยเมทริกซ์ใช้ การทำงานแบบ systolic เพื่อลดการอ่านเขียน Unified Buffer และประหยัดพลังงาน
    • ข้อมูลจะไหลเข้าจากด้านซ้าย และค่าน้ำหนักจะถูกโหลดจากด้านบน
    • การทำงาน MAC ของสมาชิก 256 ตัวจะเคลื่อนผ่านเมทริกซ์ราวกับคลื่นหน้าทแยง

TensorFlow และสแตกไดรเวอร์

  • เพื่อให้ฮาร์ดแวร์ TPU v1 ถูกใช้งานจริงในบริการ จำเป็นต้องมี ซอฟต์แวร์สแตก ที่รองรับ
    • เนื่องจาก Google พัฒนาและใช้ TensorFlow อยู่แล้ว งานสำคัญจึงเป็นการสร้างไดรเวอร์ให้ TensorFlow ทำงานกับ TPU v1 ได้
  • ซอฟต์แวร์สแตกของ TPU ต้องเข้ากันได้กับสแตกสำหรับ CPU และ GPU
    • แอปพลิเคชันต้องสามารถย้ายมาใช้ TPU ได้อย่างรวดเร็ว
    • ส่วนของแอปพลิเคชันที่รันบน TPU มักเขียนด้วย TensorFlow และคอมไพล์เป็น API ที่รันได้บน GPU หรือ TPU
  • เช่นเดียวกับ GPU สแตกของ TPU ก็แยกเป็น User Space Driver และ Kernel Driver
    • Kernel Driver ถูกทำให้เบา โดยจัดการเพียงหน่วยความจำและ interrupt และมุ่งเน้นเสถียรภาพระยะยาว
    • User Space Driver เปลี่ยนแปลงบ่อยกว่า และรับผิดชอบการตั้งค่าและควบคุมการรันของ TPU การจัดรูปข้อมูลใหม่ให้ตรงกับลำดับของ TPU การแปลง API calls เป็นคำสั่งของ TPU และการสร้าง application binary

กระบวนการผลิต 28nm และการจัดวางบนได

  • TPU v1 ผลิตด้วย กระบวนการ 28nm ที่ค่อนข้างสุกงอมของ TSMC
    • ในเวลานั้น ชิป Intel Haswell CPU และ Nvidia K80 GPU ที่ใช้ในดาต้าเซ็นเตอร์ของ Google ผลิตด้วยกระบวนการที่ล้ำหน้ากว่า
    • ตามข้อมูลของ Google พื้นที่ไดของ TPU v1 มีขนาดไม่ถึงครึ่งของพื้นที่ไดของชิปเหล่านั้น
  • ISA ที่เรียบง่ายช่วยลดโอเวอร์เฮดบนไดที่ต้องใช้กับการดีโค้ดและงานที่เกี่ยวข้อง
    • พื้นที่ control ใช้เพียง 2% ของพื้นที่ได
    • Matrix Multiply Unit ใช้ 24% และ Unified Buffer ใช้ 29%

การเปรียบเทียบประสิทธิภาพและข้อจำกัดที่ชัดเจน

  • TPU v1 เป็นอุปกรณ์สำหรับ inference ที่ออกแบบมาเพื่อใช้โมเดลที่เทรนแล้วให้มีประสิทธิภาพมากขึ้นในบริการจริงระดับ Google
    • ไม่ใช่อุปกรณ์ที่ออกแบบมาเพื่อปรับปรุงความเร็วหรือประสิทธิภาพของการเทรน
    • inference กับการเทรนสร้างโจทย์คนละแบบในการพัฒนาฮาร์ดแวร์เฉพาะทาง
  • ณ ปี 2013 คู่เทียบหลักคือ Intel Haswell CPU และ Nvidia K80 GPU
    • TPU v1 มีจำนวน MAC มากกว่า K80 GPU 25 เท่า
    • TPU v1 มีหน่วยความจำบนชิปมากกว่า K80 GPU 3.5 เท่า
    • TPU v1 เร็วกว่า K80 GPU และ Haswell CPU ในงาน inference ราว 15~30 เท่า
    • สมรรถนะเพิ่มขึ้นต่อวัตต์เมื่อเทียบกับ GPU อยู่ที่ 25~29 เท่า
  • ด้วยสถาปัตยกรรมที่ออกแบบเฉพาะ TPU v1 จึงให้ประสิทธิภาพ inference สูงกว่าและใช้พลังงานต่ำกว่า CPU และ GPU ในเวลานั้น
  • อย่างไรก็ตาม เพราะเป็นการออกแบบรุ่นแรกที่โฟกัสเพียงเป้าหมายเดียวคือ inference ที่รวดเร็วและประหยัดพลังงาน จึงยังมีข้อจำกัดว่าไม่ได้ถูกออกแบบมาสำหรับการเทรน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-03-26
ความคิดเห็นบน Hacker News

  • Jonathan Ross ซีอีโอของ Groq เล่าในการสัมภาษณ์พอดแคสต์เมื่อไม่นานนี้ถึงตอนที่สร้าง TPU รุ่นแรก ๆ ที่ Google ว่า เดิมทีเป็น FPGA ที่เขาทำในเวลา 20% เพราะนั่งอยู่ใกล้ทีมที่กำลังเจอปัญหาเรื่องความเร็วในการอนุมาน
    หลังจากทำให้มันใช้งานได้แล้ว Jeff Dean ลองคำนวณดู และตัดสินใจไปทาง ASIC
    ถ้าเป็นตอนนี้ ผมคิดว่า Google ควรแยกทีม TPU ออกไปเป็นบริษัทต่างหาก เป็นคู่แข่งที่น่าเชื่อถือเพียงรายเดียวที่จะสู้กับ Nvidia ได้ และการรองรับซอฟต์แวร์ก็อยู่ในระดับรองจาก Nvidia เท่านั้น
    https://open.spotify.com/episode/0V9kRgNS7Ds6zh3GjdXUAQ?si=q...

    • ผมมองว่าจุดแข็งของ Nvidia เรียงตามความสำคัญคือ กำลังการผลิตจาก foundry ที่จองไว้, ซอฟต์แวร์ที่ผสานรวมกันอย่างมาก, โครงสร้างฮาร์ดแวร์ที่มีอยู่แล้ว และความสัมพันธ์กับลูกค้า
      แต่แต่ละข้อก็มีจุดอ่อน ปริมาณการผลิตจาก foundry นั้นตึงมากก็จริง แต่ Nvidia สามารถสละตลาด GPU สำหรับผู้บริโภคได้ถ้าขายชิป AI ที่แพงกว่าได้ หากคู่แข่งวางเดิมพันครั้งใหญ่ไว้ตั้งแต่หลายปีก่อน หรือบริษัทที่มีกำลังการผลิตมากอย่าง Intel เปลี่ยนลำดับความสำคัญ ข้อได้เปรียบนี้ก็จะหายไป
      การมีซอฟต์แวร์ปิดที่เป็นมาตรฐานอุตสาหกรรมย่อมสะดวก แต่ความสำคัญจริง ๆ ขึ้นอยู่กับกรณีใช้งานอย่างมาก การออกแบบฮาร์ดแวร์สำหรับ TPU ดูโดยเนื้อแท้แล้วเรียบง่ายกว่า GPU มาก ไม่ต้องมี ray tracing, texture sampler หรือ rasterization และส่วนใหญ่ต้องการแค่การคูณเมทริกซ์กับหน่วยความจำจำนวนมาก
      ความสัมพันธ์กับลูกค้ามีประโยชน์ในการคอยมีส่วนร่วมในบทสนทนา แต่ในตลาดที่มองหาข้อได้เปรียบแม้เพียงเล็กน้อย ผู้จัดหาฮาร์ดแวร์ที่ให้ FLOPS ต่อดอลลาร์สูงที่สุดก็น่าจะหาลูกค้าได้มากพอที่จะเติมกำลังการผลิตของตัวเอง ดังนั้นในอีกไม่กี่ปี การแข่งขันน่าจะกลายเป็นจริงได้ค่อนข้างเร็ว
    • เรื่องที่ว่า Google ควรแยกทีม TPU ออกมาเป็นบริษัทต่างหากนั้น เมื่อดูจากขนาดตลาดและสถานการณ์ที่แทบจะผูกขาด ผมคิดว่ามันมีโอกาสแซง ธุรกิจฮาร์ดแวร์ Pixel ได้แทบจะทันที
      อย่างไรก็ตาม TPU เป็นทรัพยากรประมวลผลที่ค่อนข้างขาดแคลนแม้แต่ภายใน Google เอง และมีความเป็นไปได้สูงว่าแค่ตอบสนองความต้องการภายในก็ยังยากแล้ว
    • Amazon ซื้อ Annapurna Labs ซึ่งทำเรื่องคล้ายกัน จนมีซิลิคอน Trainium/Inferentia ของตัวเอง และในด้านการสนับสนุนนั้นมีมากกว่า Google อย่างชัดเจน
    • การบอกว่า TPU เป็นคู่แข่งที่น่าเชื่อถือเพียงรายเดียวของ Nvidia นั้นไม่ถูกต้อง AMD และ Intel ก็มี GPU ระดับประสิทธิภาพ H100 ผ่าน Habana เช่นกัน
    • Groq นั้นยอดเยี่ยมจริง ๆ สตาร์ทอัพจำนวนมากออกมาพร้อมคำคุยโวและคำสัญญาเท่านั้น แต่ Groq ปรากฏตัวพร้อมผลิตภัณฑ์ที่ยอดเยี่ยมและใช้งานได้จริงแล้ว แค่นั้นก็เป็นเหตุผลเพียงพอที่จะชอบแล้ว
      ผมแทบไม่เคยพูดว่าผมนับถือบริษัทหนึ่งถึงขนาดนี้ แต่ Groq นั้นผมนับถือจริง ๆ

  • Google เป็นผู้ประดิษฐ์ TPU และ Google Research ก็ยังออก论文 LLM ด้วย แต่ไม่เข้าใจว่าทำไม NVDA กับสตาร์ทอัพ AI ถึงได้เอามูลค่าไปเกือบ 100%

    • มีมุกเก่าเกี่ยวกับ Xerox กับ PARC ที่อธิบายว่า “การขาย สำนักงานไร้กระดาษ ให้บริษัทเครื่องถ่ายเอกสารเป็นเรื่องยาก”
      ในกรณีของ Google อาจเทียบได้ว่า หากเสนอให้เผยแพร่สิ่งอย่าง ChatGPT ในวงกว้าง ก็อาจกัดกินรายได้จากการแสดงผลแบบจ่ายเงินในเสิร์ชเอนจิน และรายได้โฆษณาของเว็บไซต์ที่ผู้คนไม่จำเป็นต้องเข้าไปเยี่ยมชมอีก ดังนั้นพวกเขาอาจตัดสินใจค่อย ๆ นำมาใช้ด้วยวิธีที่ลดแรงกระแทก เฉพาะเมื่อจำเป็นด้านการแข่งขันเท่านั้น
      ความจริงคงไม่ได้เรียบง่ายขนาดนั้น แต่ถ้านั่นเป็นเหตุผลจริงก็น่าขำไม่น้อย
    • Google ไม่สามารถโฟกัสกับผลิตภัณฑ์ที่ไม่สร้าง กำไร ระดับหลายพันล้านดอลลาร์ได้นานเกิน 18 เดือน พวกเขาเมาโฆษณาอยู่
    • ยังเร็วเกินไปที่จะบอกว่า Google จะเก็บมูลค่าจาก AI ไม่ได้ พวกเขามีโอกาสมากพอที่จะผสาน AI เข้ากับผลิตภัณฑ์ของตัวเอง
    • ตัวอย่างในประวัติศาสตร์ก็ดู Xerox PARC ได้เลย
    • OpenAI ดึงคนเก่งจาก Google ไปด้วยค่าตอบแทนที่สูงกว่ามาก
      https://www.linkedin.com/posts/eolver_googles-defense-agains...

  • ผมเป็นพนักงาน Google ถ้าไม่ได้ดู TPU มาสักพัก แนะนำให้ลองดู v5 ตอนนี้รองรับ PyTorch/JAX แล้ว ทำให้ใช้ง่ายกว่าสมัยที่ใช้ได้เฉพาะ TensorFlow มาก

    • จะซื้อ TPU v5 มาเสียบในเซิร์ฟเวอร์ของผมได้ที่ไหน? ถ้าคำตอบคือ “คลาวด์” นั่นแหละคือเหตุผลที่ Nvidia เหนือกว่าอย่างท่วมท้น

  • บทความนี้เชื่อมโยงชิ้นส่วนหลายอย่างที่เคยกระจัดกระจายแบบนามธรรมให้เห็นได้ดีว่าในความเป็นจริงมัน ไหลอยู่ภายในซิลิคอนอย่างไร
    โดยเฉพาะการได้เห็นว่าคำสั่ง CISC แบบเรียบง่ายสอดคล้องกับขั้นตอนการอนุมาน LLM แทบจะตรง ๆ นั้นดีมาก

  • อาจเป็นคำถามโง่ ๆ ที่เผยว่าผมไม่รู้อะไรเลยก็ได้ แต่ฝั่งผู้บริโภค ผมได้ยินอยู่เรื่อย ๆ ว่า ชิป M1~M4 ดีสำหรับงาน AI บางอย่าง
    ทุกวันนี้สิ่งที่สำคัญที่สุดสำหรับผมคือเครื่องมืออย่าง Photoshop, Resolve และผมเห็นว่ามันทำงานบนชิปแบบของ Apple รุ่นใหม่ได้เร็วกว่ามากเมื่อเทียบกับเครื่องเก่าของผม
    เรื่องนี้อาจไม่เชื่อมโยงกับสิ่งที่ชิปเหล่านี้หรือ H100 ทำได้มากนัก แต่ผมสงสัยว่ามันเชื่อมโยงกันบ้างไหม แน่นอนว่า Apple ไม่ได้ขายชิปของตัวเองแยกต่างหาก ดังนั้นถ้าจะทำให้ใช้งานได้จริง ก็คงต้องออกผลิตภัณฑ์ลักษณะเซิร์ฟเวอร์ภายนอกที่อัด GPU กับชิป AI เข้าไปจำนวนมาก

    • ผมคงเรียกตัวเองว่าผู้เชี่ยวชาญไม่ได้ แต่เคย benchmark M1 กับ GPU หลายรุ่น
      ชิป M* ใช้หน่วยความจำแบบ unified memory และโดยเฉพาะรุ่น Pro/Max/Ultra มีแบนด์วิดท์หน่วยความจำสูงมาก แม้เทียบกับ GPU อย่าง 1080 แบนด์วิดท์หน่วยความจำของ M1 Ultra อยู่ประมาณระหว่าง 2080 กับ 3090
      สำหรับ batch size เล็ก โดยเฉพาะ batch 1 อย่างงาน local ส่วนใหญ่ การอนุมานจะติดคอขวดที่แบนด์วิดท์หน่วยความจำมากกว่าพลังประมวลผล นี่คือเหตุผลที่มีคนบอกว่าชิป M* ดีสำหรับ machine learning
      แต่ H100 ส่วนใหญ่ใช้สำหรับการฝึกที่มี batch size มหาศาล และการฝึกโมเดลขนาดใหญ่ต้องใช้อินเตอร์คอนเนกต์จำนวนมาก ในระดับนั้น arithmetic intensity สูงมาก ดังนั้นแม้จะเชื่อมชิป M* เข้าด้วยกันผ่านเครือข่ายได้ ก็ยังไม่ค่อยมีความสามารถในการแข่งขันนัก พูดได้ว่าเลือกอยู่คนละจุดบนเส้น Pareto ด้านพลังงาน/ประสิทธิภาพเมื่อเทียบกับชิปที่กินไฟมากอย่าง H100

  • สิ่งที่ Google ควรทำจริง ๆ คือเข้าไปสู่ขอบเขตของ 2nm EUV และลงไปต่ำกว่า 2nm
    ถ้ามีของแบบนั้น ไม่ว่าจะเป็น electron lithography หรือเทคโนโลยีที่ ASML ใช้พิมพ์ลวดลายลงบนชิป ก็จะกลายเป็นผู้เล่นที่น่ากลัวจริง ๆ น่าจะต้องมีโปรเจกต์ moonshot แบบฮาร์ดคอร์สไตล์ Google X
    หรือไม่ก็อาจมีเงินราว 500 ล้านดอลลาร์พอจะซื้อเครื่องสักเครื่องอยู่แล้วก็ได้ ถ้า TPU ดีขนาดนั้นจริง ๆ การบูรณาการแนวดิ่งไปจนถึงเทคโนโลยีของตัวเองและ fab ของตัวเองก็น่าจะเป็นธุรกิจที่ดีได้

    • พูดตรง ๆ คือแทบเป็นไปไม่ได้ ลองคิดถึง ความลับทางการค้า ที่สะสมมาหลายสิบปีซึ่งต้องค้นให้เจอก่อน, เงินทุนหลายหมื่นล้านหรือหลายแสนล้านดอลลาร์ที่ต้องใช้สร้าง fab ขั้นสูงแห่งแรก, เวลา 10–20 ปีจนกว่าจะเติบโตเป็นธุรกิจที่ทำงานได้จริง และประเด็นที่ว่าปริมาณที่พวกเขาจะผลิตนั้นน้อยเกินไปมาก สุดท้ายมีแนวโน้มสูงว่าจะเป็นการเผาเงิน 500,000 ล้านดอลลาร์ เพื่อไปถึงจุดที่ตามหลังกระบวนการผลิตขั้นสูงในปัจจุบันอยู่หลายปี ในอีกราว 10 ปีข้างหน้า
      เหตุผลที่ fab ขั้นสูงในปัจจุบันทำกำไรได้ คือการผลิตอุปกรณ์คอมพิวติ้งอเนกประสงค์ให้กับลูกค้าและการใช้งานที่หลากหลาย พร้อมด้วยบุคลากรและวิศวกรรมที่สั่งสมมาหลายสิบปี ยิ่งกว่านั้น ลูกค้ายังช่วยผลักดันนวัตกรรมอย่างอิสระในส่วนสำคัญ ๆ เช่น การปรับปรุง yield ของ chip-on-chip HDI ของ Micron, fabric สำหรับการสื่อสารระหว่าง die และการออกแบบ substrate แบบ multi-chip ของ Xilinx
      TPU ไม่มีทางสร้างปริมาณที่จำเป็นได้ และก็ไม่อาจดึงลูกค้าที่จะทำให้เกิด economies of scale ที่มีกำไรได้ด้วย Google ยังต้องเสนอราคาที่น่าสนใจเมื่อเทียบกับคู่แข่งด้วย
      หากมีเหตุผลทางธุรกิจที่น่าเชื่อถือมากพอ fab ที่มีอยู่ก็คงยินดีจัดสรรกำลังการผลิตให้เอง TPU ยังไม่น่าเชื่อถือถึงระดับนั้นเลย

  • เคยฟังพรีเซนต์ของ Jim Keller จาก TensTorrent ที่อธิบายแนวทางอีกแบบในการสร้าง AI core วิธีคือมี RISC-V core 5 ตัว โดยตัวหนึ่งใช้โหลดข้อมูล ตัวหนึ่งใช้อัปโหลดข้อมูล และที่เหลือใช้เฉพาะงานคำนวณเมทริกซ์
    เขาพูดถึง Google TPU ด้วย โดยบอกว่าการเขียนโปรแกรมให้มันเหมือนกับการจัดการ VLIW และมีคนราว 500 คนทำงานกับคอมไพเลอร์

  • ในต้นฉบับเขียนว่า “TPU v1 เป็นการออกแบบแบบ CISC ที่มีคำสั่งราว 20 คำสั่ง” ซึ่งทำให้ขำ เพราะดูเหมือนว่า CISC/RISC จะเดินทางจากข้อสังเกตที่เฉียบคม ไปเป็นโครงการวิจัย เทคโนโลยีปฏิวัติวงการ คำฮิตทางการตลาด และสุดท้ายกลายเป็นคำที่แทบไม่มีความหมายโดยสิ้นเชิงแล้ว
    คงต้องเรียกว่าวงจรชีวิตของคำศัพท์

    • ไม่แน่ใจนัก แต่เท่าที่เรียนมาจากวิชาสถาปัตยกรรมคอมพิวเตอร์ ความต่างระหว่าง CISC กับ RISC เกี่ยวข้องกับความซับซ้อนของคำสั่งมากกว่าจำนวนคำสั่งเอง
      ดังนั้นแม้ TPU จะมีจำนวนคำสั่งน้อย แต่ถ้าแต่ละคำสั่งค่อนข้างซับซ้อน ก็อาจเป็น CISC ได้ เพียงแต่ครั้งสุดท้ายที่เรียนสถาปัตยกรรมคอมพิวเตอร์คือวิชาระดับบัณฑิตเมื่อ 15 ปีก่อน ความจำเลยเลือน ๆ อยู่บ้าง แถมเทอมนั้นส่วนใหญ่ก็หมดไปกับงานเกี่ยวกับ Itanium ซึ่งตอนนี้ไม่ค่อยมีประโยชน์แล้ว
    • ดูเหมือนกำลังสื่อว่าจำนวนคำสั่งที่มีให้ใช้เป็นตัวแยก CISC แต่เดิมทีไม่ได้ใช้เกณฑ์แบบนั้น

  • ความต้องการกำลังการผลิตของ foundry ดูมหาศาล เลยสงสัยว่าเวลา Microsoft หรือ Google ทำชิปของตัวเองแล้วต้องการผลิต เขาไปอยู่หน้าสุดของคิวได้อย่างไร
    มันเรียบง่ายพอที่จะผลิตใน fab “เก่าและมีความต้องการน้อยกว่า” ได้หรือเปล่า? เท่าที่รู้ Apple กับ Nvidia จองกำลังการผลิต foundry ไว้มากอยู่แล้ว

    • โดยคร่าว ๆ มันทำงานบน fab รุ่นเก่าที่ ตามหลังเทคโนโลยีล้ำสุดอยู่หนึ่งเจเนอเรชัน
      https://en.wikipedia.org/wiki/Tensor_Processing_Unit#Product...
      พวกเขายังมีบทบาทและการใช้จ่ายไม่น้อยในด้านอย่าง HBM ด้วย และ SemiAnalysis ก็มีบทความดี ๆ เกี่ยวกับเรื่องนี้

  • สงสัยว่าถ้า LLM ได้ใช้ quantization แบบ -1, 0, 1 กันอย่างแพร่หลายจริง ๆ ฮาร์ดแวร์จะเปลี่ยนไปอย่างไร