Breaking Down Kimi K3's Architecture (Even For the Non-Technical)

1
00:00:00,000 --> 00:00:01,942
สัปดาห์ที่แล้ว Kimi K3

2
00:00:01,942 --> 00:00:05,472
ออกมาและได้รับการตอบรับที่น่าทึ่งมากครับ

3
00:00:05,472 --> 00:00:08,915
หลายคนพูดถึงมันว่าเกือบจะเทียบเท่าโมเดล

4
00:00:08,915 --> 00:00:11,563
frontier จาก closed lab ชั้นนำ

5
00:00:11,563 --> 00:00:15,623
ยกเว้นแต่ว่ามันเป็นโมเดล open weights ที่มาจาก

6
00:00:15,623 --> 00:00:18,006
AI lab ของจีน ค่า benchmark

7
00:00:18,006 --> 00:00:19,948
นั้นน่าประทับใจพอสมควร

8
00:00:19,948 --> 00:00:23,743
แต่การใช้งานจริงนั้นน่าประทับใจยิ่งกว่าครับ

9
00:00:23,743 --> 00:00:27,538
แต่ในวิดีโอวันนี้ ผมอยากจะมองที่สถาปัตยกรรม

10
00:00:27,538 --> 00:00:28,686
เพราะ Kimi K3

11
00:00:28,686 --> 00:00:31,863
มีสถาปัตยกรรมที่ค่อนข้างไม่เหมือนใคร

12
00:00:31,863 --> 00:00:35,129
ที่ทำให้มันเร็วและมีประสิทธิภาพสูงมาก

13
00:00:35,129 --> 00:00:39,012
แม้ตอนใช้งานกับคำถามที่มี context ยาวๆ ก็ตาม

14
00:00:39,012 --> 00:00:43,249
ผมเลยอยากใช้เวลาทั้งวิดีโอมาเจาะลึกเรื่องนี้ครับ

15
00:00:43,249 --> 00:00:45,809
และสำหรับคนที่ไม่ได้สายเทคนิค

16
00:00:45,809 --> 00:00:48,457
ทั้งหมดนี้อาจจะดูน่ากลัวไปบ้าง

17
00:00:48,457 --> 00:00:50,222
แต่ไม่ต้องกลัวนะครับ

18
00:00:50,222 --> 00:00:55,341
ผมจะอธิบายทีละส่วนให้แม้คนที่ไม่ใช่สายเทคนิคเลยก็เข้าใจได้

19
00:00:55,341 --> 00:01:02,932
และหวังว่าจะทำให้ทุกคนเข้าใจภาพรวมมากขึ้นว่าเกิดอะไรขึ้นภายใต้ฝากระโปรงตอนที่คุณใช้งาน

20
00:01:02,932 --> 00:01:05,756
coding model อย่าง Kimi K3 จริงๆ

21
00:01:05,756 --> 00:01:09,728
วันนี้เราจะติดตามคำถามเดียวตั้งแต่ตอนกด enter

22
00:01:09,728 --> 00:01:11,846
ไปจนถึงตอนที่คำตอบโผล่มา

23
00:01:11,846 --> 00:01:15,024
และดูทุกเทคนิคที่โมเดลใช้ตลอดเส้นทาง

24
00:01:15,024 --> 00:01:16,877
ขณะที่เราทำ deep dive

25
00:01:16,877 --> 00:01:20,496
ลึกเข้าไปในสถาปัตยกรรมของ Kimi K3 กันครับ

26
00:01:20,496 --> 00:01:24,203
เริ่มกันเลย Kimi K3 เป็นโมเดล open weights

27
00:01:24,203 --> 00:01:27,910
ที่ใหญ่ที่สุดเท่าที่เคยปล่อยมา ที่ขนาด 2.8

28
00:01:27,910 --> 00:01:29,587
ล้านล้านพารามิเตอร์

29
00:01:29,587 --> 00:01:32,412
พารามิเตอร์พวกนี้คือค่าตั้งต่างๆ

30
00:01:32,412 --> 00:01:34,618
ที่ปรับได้ภายในสมองของมัน

31
00:01:34,618 --> 00:01:38,767
เปรียบเหมือนปุ่มหมุนที่ถูกปรับไปตลอดช่วงการเทรน

32
00:01:38,767 --> 00:01:41,326
เพื่อเรียนรู้ทุกสิ่งที่มันรู้

33
00:01:41,326 --> 00:01:43,356
แต่ถึงแม้จะใหญ่ขนาดนั้น

34
00:01:43,356 --> 00:01:47,681
มันกลับทำงานได้ถูกกว่าโมเดลที่เล็กกว่ามันหลายเท่า

35
00:01:47,681 --> 00:01:50,947
ซึ่งฟังดูไม่น่าจะเป็นไปได้ใช่มั้ยครับ

36
00:01:50,947 --> 00:01:52,536
แล้วมันทำงานยังไง?

37
00:01:52,536 --> 00:01:57,390
นี่คือกรอบคิดที่อยากให้ทุกคนถนอมไว้ตลอดทั้งวิดีโอนะครับ

38
00:01:57,390 --> 00:02:01,362
เวลาคุณถามคำถามกับโมเดล มันมีค่าใช้จ่ายอยู่ 4

39
00:02:01,362 --> 00:02:05,422
จุดด้วยกัน คือ ค่าสำหรับการอ่านสิ่งที่คุณส่งไป

40
00:02:05,422 --> 00:02:07,276
ค่าสำหรับการคิดทีละคำ

41
00:02:07,276 --> 00:02:09,571
ค่าสำหรับการเขียนคำตอบกลับ

42
00:02:09,571 --> 00:02:15,043
และแน่นอนว่าค่าสำหรับการสร้างโมเดลขึ้นมาตั้งแต่แรกก็มหาศาลครับ

43
00:02:15,043 --> 00:02:16,143
แต่ Kimi K3

44
00:02:16,143 --> 00:02:19,409
มีเทคนิคแตกต่างกันไปสำหรับแต่ละจุดเลย

45
00:02:19,409 --> 00:02:23,469
เริ่มจากข้อแรก นี่เป็นพื้นฐาน machine learning

46
00:02:23,469 --> 00:02:24,569
อย่างมากครับ

47
00:02:24,569 --> 00:02:28,629
โมเดลเหล่านี้เรียนรู้ทุกอย่างจากข้อมูลตัวอย่าง

48
00:02:28,629 --> 00:02:34,984
โดยดูตัวอย่างมหาศาลแล้วปรับปุ่มหมุนเหล่านั้นเพื่อให้เดาถูกมากขึ้นเรื่อยๆ

49
00:02:34,984 --> 00:02:39,044
ตอนเทรน คุณป้อนข้อมูลเข้าไป แล้วถ้าโมเดลเดาผิด

50
00:02:39,044 --> 00:02:42,575
ก็จะปรับปุ่มให้น้อยลงเล็กน้อยไปทางที่ถูก

51
00:02:42,575 --> 00:02:45,664
และถ้าเดาถูกก็จะปรับไปทางนั้นอีกนิด

52
00:02:45,664 --> 00:02:48,047
ทำซ้ำแบบนี้หลายพันล้านครั้ง

53
00:02:48,047 --> 00:02:49,900
และเมื่อเทรนเสร็จแล้ว

54
00:02:49,900 --> 00:02:53,872
ปุ่มเหล่านี้ก็จะค้างอยู่ที่ค่าที่ดีที่สุดครับ

55
00:02:53,872 --> 00:02:57,138
ไม่เปลี่ยนอีกแล้ว ทีนี้เวลาใช้งานจริง

56
00:02:57,138 --> 00:02:59,080
คุณก็แค่ส่งคำถามเข้าไป

57
00:02:59,080 --> 00:03:02,963
ปุ่มทั้งหมดก็ทำงานต่อเนื่องกันไปเหมือนท่อน้ำ

58
00:03:02,963 --> 00:03:05,082
จนออกมาเป็นคำตอบ แต่ 2.8

59
00:03:05,082 --> 00:03:07,377
ล้านล้านพารามิเตอร์เยอะมาก

60
00:03:07,377 --> 00:03:10,378
ถ้าต้องส่งสัญญาณผ่านทุกตัวทุกครั้ง

61
00:03:10,378 --> 00:03:12,231
ค่าใช้จ่ายจะแพงเกินไป

62
00:03:12,231 --> 00:03:16,026
และนี่คือที่มาของเทคนิคแรกครับ ซึ่งเรียกว่า

63
00:03:16,026 --> 00:03:19,998
Mixture of Experts (การผสมผู้เชี่ยวชาญหลายคน)

64
00:03:19,998 --> 00:03:24,235
ลองนึกภาพว่าคุณมีผู้เชี่ยวชาญอยู่หลายพันคนในห้อง

65
00:03:24,235 --> 00:03:26,000
แต่คุณไม่ได้ถามทุกคน

66
00:03:26,000 --> 00:03:29,619
คุณถามแค่ไม่กี่คนที่เก่งเรื่องนั้นๆ โดยมี

67
00:03:29,619 --> 00:03:31,208
router (ตัวจัดสรร)

68
00:03:31,208 --> 00:03:36,592
ทำหน้าที่ตัดสินใจว่าคำถามแต่ละส่วนควรส่งไปหาผู้เชี่ยวชาญคนไหน

69
00:03:36,592 --> 00:03:40,034
ในกรณีของ Kimi K3 มี expert อยู่ 384 คน

70
00:03:40,034 --> 00:03:43,741
และแต่ละครั้งจะเลือกมาแค่ 8 คนเท่านั้นครับ

71
00:03:43,741 --> 00:03:50,802
เทคนิคนี้ช่วยได้เยอะเพราะการประมวลผลจริงแต่ละครั้งใช้แค่เศษเสี้ยวของโมเดลทั้งหมด

72
00:03:50,802 --> 00:03:54,774
แต่ก็มีปัญหาตามมา ถ้าคุณส่งคำถามไปหา expert 8

73
00:03:54,774 --> 00:03:57,422
คนเสมอ บางคนจะรับงานเยอะเกินไป

74
00:03:57,422 --> 00:03:59,099
ขณะที่บางคนนั่งว่าง

75
00:03:59,099 --> 00:04:04,395
และการกระจายงานไม่สม่ำเสมอก็ทำให้ฮาร์ดแวร์ทำงานได้ไม่เต็มที่

76
00:04:04,395 --> 00:04:07,307
นี่คือที่มาของ quantile balancing

77
00:04:07,307 --> 00:04:11,015
(การสมดุลตามควอนไทล์) แทนที่จะเลือก expert

78
00:04:11,015 --> 00:04:13,839
แค่จากคะแนนความเหมาะสมอย่างเดียว

79
00:04:13,839 --> 00:04:16,399
ระบบจะคอยดูด้วยว่าใครยุ่งอยู่

80
00:04:16,399 --> 00:04:19,576
และพยายามกระจายงานให้สม่ำเสมอ คล้ายๆ

81
00:04:19,576 --> 00:04:26,372
กับร้านอาหารที่ไม่ได้ส่งลูกค้าไปที่โต๊ะเดิมทุกครั้งเพียงเพราะโต๊ะนั้นดีที่สุด

82
00:04:26,372 --> 00:04:29,726
แต่จะกระจายให้พนักงานทุกคนได้ทำงานครับ

83
00:04:29,726 --> 00:04:31,845
ทีนี้เรามาดูเทคนิคที่สอง

84
00:04:31,845 --> 00:04:34,934
ที่ช่วยลดค่าใช้จ่ายตอนอ่านคำถามครับ

85
00:04:34,934 --> 00:04:38,641
ขอเริ่มจากพื้นฐานก่อน เวลาโมเดลอ่านข้อความ

86
00:04:38,641 --> 00:04:42,260
มันจะแปลงแต่ละคำให้เป็น vector (เวกเตอร์)

87
00:04:42,260 --> 00:04:46,496
ซึ่งเป็นทั้งรายการตัวเลขที่แสดงความหมายของคำนั้น

88
00:04:46,496 --> 00:04:49,674
ลองนึกถึงแต่ละคำเป็นจุดบนแผนที่ยักษ์

89
00:04:49,674 --> 00:04:53,293
คำที่ใกล้เคียงกันทางความหมายจะอยู่ใกล้กัน

90
00:04:53,293 --> 00:04:57,000
แต่แค่รู้ว่าแต่ละคำหมายถึงอะไรยังไม่พอครับ

91
00:04:57,000 --> 00:05:01,236
โมเดลต้องรู้ด้วยว่าคำแต่ละคำเกี่ยวข้องกับคำอื่นๆ

92
00:05:01,236 --> 00:05:04,326
ที่อยู่รอบๆ อย่างไร เช่น คำว่า "it"

93
00:05:04,326 --> 00:05:07,856
ในประโยคหนึ่งอาจจะหมายถึงแมวหรือหมาก็ได้

94
00:05:07,856 --> 00:05:11,563
โมเดลต้องดูบริบทรอบข้างเพื่อเข้าใจว่า "it"

95
00:05:11,563 --> 00:05:13,064
กำลังชี้ไปที่อะไร

96
00:05:13,064 --> 00:05:17,212
การที่คำแต่ละคำต้องมาเช็คความสัมพันธ์กับคำอื่นๆ

97
00:05:17,212 --> 00:05:20,654
ที่มาก่อนหน้า นี่คือแนวคิดของ attention

98
00:05:20,654 --> 00:05:24,361
(การใส่ใจ) ซึ่งจะมาดูกันต่อในส่วนถัดไปครับ

99
00:05:24,361 --> 00:05:27,804
ยกตัวอย่างเช่น คำว่า "it" ถ้าคลิกที่มัน

100
00:05:27,804 --> 00:05:29,745
จะเห็นว่ามันหมายถึงแมว

101
00:05:29,745 --> 00:05:33,717
โมเดลก็จะรู้ว่าความสัมพันธ์นี้ใกล้กว่าเดิมมาก

102
00:05:33,717 --> 00:05:37,336
นี่คือแนวคิดของ attention (การใส่ใจ) ครับ

103
00:05:37,336 --> 00:05:39,984
ที่คำทุกคำต้องมาเช็คกับคำอื่นๆ

104
00:05:39,984 --> 00:05:43,868
ที่มาก่อนหน้าเพื่อดูว่าความสัมพันธ์เป็นยังไง

105
00:05:43,868 --> 00:05:47,575
และอย่างที่คุณจินตนาการได้ กับขนาด 200,000

106
00:05:47,575 --> 00:05:51,635
tokens แล้ว ตัวเลขคำนวณค่อนข้างหนักเลยครับ 100

107
00:05:51,635 --> 00:05:55,430
tokens จะมีอยู่ 10,000 การจับมือ ซึ่งก็โอเค

108
00:05:55,430 --> 00:05:58,872
1,000 tokens ก็จะเป็นหนึ่งล้านการจับมือ

109
00:05:58,872 --> 00:06:02,491
ซึ่งก็ยังโอเคอยู่ แต่พอถึง 200,000 tokens

110
00:06:02,491 --> 00:06:06,022
เราก็กำลังพูดถึง 40 พันล้านการจับมือครับ

111
00:06:06,022 --> 00:06:09,552
และนี่เป็นเพราะสิ่งที่เรียกว่า quadratic

112
00:06:09,552 --> 00:06:11,582
problem (ปัญหากำลังสอง)

113
00:06:11,582 --> 00:06:14,407
คำทางคณิตศาสตร์ฟังดูยาก แต่จริงๆ

114
00:06:14,407 --> 00:06:18,026
แล้วมันแปลว่าเมื่อความยาวเพิ่มเป็นสองเท่า

115
00:06:18,026 --> 00:06:20,232
งานก็เพิ่มเป็นสี่เท่าครับ

116
00:06:20,232 --> 00:06:23,321
และนี่คือกำแพงที่โมเดล long context

117
00:06:23,321 --> 00:06:24,822
ทุกตัวชนเข้าไปเลย

118
00:06:24,822 --> 00:06:28,352
ผมเชื่อว่าหลายคนเคยใช้โมเดลที่มี context

119
00:06:28,352 --> 00:06:31,618
window ใหญ่ๆ บางทีอาจจะถึงล้าน tokens

120
00:06:31,618 --> 00:06:35,502
เลยใช่มั้ยครับ แต่พอไปได้สักระยะ อาจจะประมาณ

121
00:06:35,502 --> 00:06:39,032
200,000 tokens ขึ้นไป มันเริ่มทำงานแย่ลง

122
00:06:39,032 --> 00:06:42,651
ซึ่งก็คือปัญหา quadratic นี่แหละครับ ยิ่ง

123
00:06:42,651 --> 00:06:46,093
context ยาวขึ้น สิ่งต่างๆ ก็ยิ่งยากขึ้น

124
00:06:46,093 --> 00:06:48,212
ไม่ได้แค่เพิ่มแบบเส้นตรง

125
00:06:48,212 --> 00:06:52,448
แต่เพิ่มเป็นสี่เท่าทุกครั้งที่ความยาวเป็นสองเท่า

126
00:06:52,448 --> 00:06:56,420
แล้ว Kimi K3 ตอบปัญหานี้ยังไง? คุณไม่ต้องอ่าน

127
00:06:56,420 --> 00:06:58,715
transcript ทั้งหมดใหม่ครับ

128
00:06:58,715 --> 00:07:01,539
คุณเก็บไว้เหมือนมีกระดานไว้คำนวณ

129
00:07:01,539 --> 00:07:05,511
ซึ่งเขาเรียกว่า Kimi Delta Attention หรือ KDA

130
00:07:05,511 --> 00:07:09,307
ถ้าย้อนไปดูที่กราฟน่ากลังๆ ของเรา คุณจะเห็น

131
00:07:09,307 --> 00:07:12,837
KDA อยู่ตรงนี้ จะเห็นอยู่ตรงนั้นด้วยครับ

132
00:07:12,837 --> 00:07:16,809
แทนที่จะเก็บคำทุกคำไว้แล้วเปรียบเทียบกับทุกคำ

133
00:07:16,809 --> 00:07:18,133
มันเก็บ summary

134
00:07:18,133 --> 00:07:21,840
ที่ทำงานต่อเนื่องอยู่ในพื้นที่ขนาดคงที่ พอ

135
00:07:21,840 --> 00:07:25,635
token ใหม่มาถึง มันก็แค่อัปเดตกระดานนี้ครับ

136
00:07:25,635 --> 00:07:27,401
คุณสมบัติสำคัญมากคือ

137
00:07:27,401 --> 00:07:31,019
กระดานนี้ไม่มีวันใหญ่ขึ้นเลย เป็น summary

138
00:07:31,019 --> 00:07:34,815
ขนาดคงที่ ไม่ว่าจะอ่านมาพัน tokens หรือล้าน

139
00:07:34,815 --> 00:07:36,668
tokens ขนาดก็เท่าเดิม

140
00:07:36,668 --> 00:07:39,404
ต้นทุนเลยไม่เพิ่มตามความยาวครับ

141
00:07:39,404 --> 00:07:43,288
แต่คุณอาจจะถามว่า มันเป็นคำถามที่ชัดเจนมากนะ

142
00:07:43,288 --> 00:07:46,024
ว่าเกิดอะไรขึ้นเมื่อกระดานเต็ม?

143
00:07:46,024 --> 00:07:52,644
คำตอบนั้นสำคัญมากครับว่าคุณจะจัดการกับโน้ตเก่าพวกนี้ยังไงตอนกระดานเริ่มเต็ม

144
00:07:52,644 --> 00:07:56,439
วิธีที่ง่ายที่สุดก็คือ แค่เขียนทับไปเรื่อยๆ

145
00:07:56,439 --> 00:08:00,058
บนสิ่งที่มีอยู่แล้ว แต่ทำแบบนั้น 50 ครั้ง

146
00:08:00,058 --> 00:08:03,677
แล้วมันจะกลายเป็นแบบนี้ครับ อ่านไม่ออกเลย

147
00:08:03,677 --> 00:08:07,031
เป็นแค่มัดรวมของคำและแนวคิดต่างๆ สุ่มๆ

148
00:08:07,031 --> 00:08:09,767
ทุกอย่างก็ยังอยู่บนกระดานนะครับ

149
00:08:09,767 --> 00:08:11,621
เพียงแต่ว่าอ่านไม่ออก

150
00:08:11,621 --> 00:08:13,827
และดังนั้นจึงใช้การไม่ได้

151
00:08:13,827 --> 00:08:16,916
วิธีที่ฉลาดกว่าก็คืออยู่อีกด้านครับ

152
00:08:16,916 --> 00:08:21,771
เมื่อข้อมูลใหม่มาถึงเกี่ยวกับหัวข้อที่เรามีโน้ตอยู่แล้ว

153
00:08:21,771 --> 00:08:25,743
ให้เช็ดรายการเก่าออกก่อน แล้วค่อยเขียนอันใหม่

154
00:08:25,743 --> 00:08:28,391
กระดานก็ยังใบเดิม ขนาดเท่าเดิม

155
00:08:28,391 --> 00:08:30,597
แต่หลังจากอัปเดต 50 ครั้ง

156
00:08:30,597 --> 00:08:34,039
ทุกอย่างก็ยังอ่านได้สมบูรณ์ครับ ขั้นตอน

157
00:08:34,039 --> 00:08:38,100
"เช็ดก่อน" นี่แหละคือคำว่า delta ใน Kimi Delta

158
00:08:38,100 --> 00:08:41,277
Attention และนี่คือเหตุผลที่ summary

159
00:08:41,277 --> 00:08:44,101
ยังคงใช้งานได้ตลอดหลายแสน tokens

160
00:08:44,101 --> 00:08:46,396
แทนที่จะกลายเป็นเละเทะครับ

161
00:08:46,396 --> 00:08:49,927
กระดานไว้คำนวณแบบนี้มันต่างออกไปนิดหน่อย

162
00:08:49,927 --> 00:08:54,164
เพราะหัวข้อแต่ละหัวข้อจะจางหายไปในอัตราของตัวเอง

163
00:08:54,164 --> 00:08:57,518
และนี่คือสิ่งที่ทำให้กระดานของ Kimi K3

164
00:08:57,518 --> 00:08:58,618
โดดเด่นครับ

165
00:08:58,618 --> 00:09:02,766
ไม่ใช่ทุกอย่างบนกระดานที่จะอยู่รอดได้นานเท่ากัน

166
00:09:02,766 --> 00:09:05,326
เช่น ในตัวอย่างของเรา เลข 900

167
00:09:05,326 --> 00:09:09,386
เป็นข้อเท็จจริงที่สำคัญมาก เป็นตัวเลขที่แน่นอน

168
00:09:09,386 --> 00:09:12,122
เราอยากเก็บมันไว้คมชัดตลอดไปเลย

169
00:09:12,122 --> 00:09:15,035
แต่ความคิดเห็นที่แว่บขึ้นมาเรื่อง

170
00:09:15,035 --> 00:09:17,682
"ไปจัดระเบียบ codebase ทีหลัง"

171
00:09:17,682 --> 00:09:21,213
แบบนี้ก็ปล่อยให้มันจางไปเร็วๆ ได้เลยครับ

172
00:09:21,213 --> 00:09:25,097
เพราะไม่ได้สำคัญขนาดนั้น โครงสร้างเก่าที่ใช้

173
00:09:25,097 --> 00:09:26,597
whiteboard แบบนี้

174
00:09:26,597 --> 00:09:30,569
จะทำให้ทั้งกระดานจางไปพร้อมกันในอัตราเดียวกัน

175
00:09:30,569 --> 00:09:31,669
แต่ Kimi K3

176
00:09:31,669 --> 00:09:36,700
ให้รายการแต่ละรายการมีปุ่มปรับอัตราการจางหายของตัวเองครับ

177
00:09:36,700 --> 00:09:40,760
แต่ขอเน้นนะครับว่า summary ก็ยังคงเป็น summary

178
00:09:40,760 --> 00:09:44,202
บางครั้งแค่สรุปคร่าวๆ ของบางสิ่งก็ไม่พอ

179
00:09:44,202 --> 00:09:47,556
กระดานอาจจะบอกคุณว่ามี session timeout

180
00:09:47,556 --> 00:09:51,616
อยู่ที่ไหนสักแห่ง แต่คุณต้องรู้ตัวเลขที่แน่นอน

181
00:09:51,616 --> 00:09:54,794
คุณต้องรู้ว่ามันคือ 900 พอดี Kimi K3

182
00:09:54,794 --> 00:09:58,854
จึงไม่ได้พึ่งกระดานนี้เพียงอย่างเดียวครับ ทุกๆ

183
00:09:58,854 --> 00:10:06,886
สถานีสองสามครั้ง จำได้มั้ยว่านี่คือชุดสถานี สายการประกอบเลเยอร์ที่เราพูดถึงก่อนหน้านี้ ทุกๆ

184
00:10:06,886 --> 00:10:10,593
สองสามสถานีในสายการประกอบนี้ คุณจะเจอสถานี

185
00:10:10,593 --> 00:10:14,212
full transcript ครับ สถานีนี้ไม่มีการสรุป

186
00:10:14,212 --> 00:10:17,389
ไม่มีทางลัด มันจะกลับไปดู transcript

187
00:10:17,389 --> 00:10:19,243
ตัวเต็มจริงๆ ตัวเล็กๆ

188
00:10:19,243 --> 00:10:23,126
สีฟ้าเหล่านี้คือ KDA layers ส่วนตัวใหญ่ๆ คือ

189
00:10:23,126 --> 00:10:27,010
Gated MLA (Multi-head Latent Attention) ครับ

190
00:10:27,010 --> 00:10:31,247
คุณคิดซะว่ามันเป็นเหมือนตาข่ายนิรภัยอยู่ด้านล่าง

191
00:10:31,247 --> 00:10:35,042
ถ้าดูในชาร์ตเล็กๆ ของเรา นี่คือ layer stack

192
00:10:35,042 --> 00:10:38,926
ที่เราพูดถึงก่อนหน้านี้ นี่คือ attention แบบ

193
00:10:38,926 --> 00:10:42,721
KDA แล้วก็ Gated MLA สาม KDA ต่อหนึ่ง Gated

194
00:10:42,721 --> 00:10:46,163
MLA ครับ และคุณสามารถดูได้จาก tech blog

195
00:10:46,163 --> 00:10:49,959
ของเขาด้วย สาม KDA layer ต่อหนึ่ง MLA layer

196
00:10:49,959 --> 00:10:53,930
นี่คือรูปแบบของมันครับ เป็น whiteboard layers

197
00:10:53,930 --> 00:10:57,726
ราคาถูกเป็นส่วนใหญ่ สลับกับ full transcript

198
00:10:57,726 --> 00:11:00,727
layers ที่กระจายอยู่ทั่วทั้ง stack

199
00:11:00,727 --> 00:11:04,345
ทำให้ได้ทั้งความเร็วเกือบทั้งหมดของทางลัด

200
00:11:04,345 --> 00:11:08,229
และความแม่นยำเกือบทั้งหมดของการทำแบบเต็มครับ

201
00:11:08,229 --> 00:11:11,053
ถ้าจะให้จำอย่างเดียวจากวิดีโอนี้

202
00:11:11,053 --> 00:11:15,114
ผมรู้ว่ามันเยอะไปหน่อยที่ผมพูดและโชว์สไลด์ตลอด

203
00:11:15,114 --> 00:11:18,997
แต่ผมอยากให้คุณจำว่า K3 ถูกสร้างมาแบบนี้ครับ

204
00:11:18,997 --> 00:11:24,999
สไตล์แบบผสมนี้คือการตัดสินใจออกแบบที่สำคัญที่สุดอย่างเดียวในโมเดลเลย

205
00:11:24,999 --> 00:11:27,824
นี่คือต้นทุนแรกที่เราลดลงได้ครับ

206
00:11:27,824 --> 00:11:31,354
คือการอ่านคำถามของคุณ เราเห็นแล้วว่าด้วย

207
00:11:31,354 --> 00:11:35,238
whiteboard และตาข่ายนิรภัยของสถาปัตยกรรม MLA

208
00:11:35,238 --> 00:11:38,680
เราสามารถประหยัดได้มาก ลด memory สำหรับ

209
00:11:38,680 --> 00:11:41,857
context ลง 75% และเขียนได้เร็วขึ้น 6

210
00:11:41,857 --> 00:11:43,446
เท่าที่ความยาวเต็ม

211
00:11:43,446 --> 00:11:47,330
แม้ว่าควรระบุว่าตัวเลขนี้เป็นของ Kimi Linear

212
00:11:47,330 --> 00:11:51,125
ซึ่งเป็นโมเดลเล็กกว่า แต่ก็มีดีไซน์คล้ายกัน

213
00:11:51,125 --> 00:11:54,479
ของ Kimi K3 เองยังไม่มีตัวเลขออกมาครับ

214
00:11:54,479 --> 00:11:58,363
ทีนี้มาดู MLA ให้ละเอียดขึ้นนะครับ Gated MLA

215
00:11:58,363 --> 00:12:00,040
อยู่ภายในหนึ่งสถานี

216
00:12:00,040 --> 00:12:03,394
แต่ละสถานีก็เหมือนบริษัทที่ปรึกษาที่มี

217
00:12:03,394 --> 00:12:06,130
specialist อยู่ 896 คนในทีมครับ

218
00:12:06,130 --> 00:12:09,837
และนี่เป็นส่วนหนึ่งของโครงสร้าง Mixture of

219
00:12:09,837 --> 00:12:13,897
Experts เหมือนเดิม โดยจะเรียกตัวมาทำงานจริงแค่

220
00:12:13,897 --> 00:12:17,604
16 คนเท่านั้นครับ ที่เหลือก็ว่างไปส่วนใหญ่

221
00:12:17,604 --> 00:12:21,311
คิดเป็นเพียง 1.8% ที่ทำงานอยู่ตลอดเวลาครับ

222
00:12:21,311 --> 00:12:24,842
และอย่างที่บอก นี่คือ Mixture of Experts

223
00:12:24,842 --> 00:12:28,549
เป็นสถาปัตยกรรมที่พบได้บ่อยใน LLM สมัยใหม่

224
00:12:28,549 --> 00:12:30,314
ลองนึกถึงบริษัทใหญ่ๆ

225
00:12:30,314 --> 00:12:33,403
ที่คุณจ่ายแค่ไม่กี่คนในห้องเท่านั้น

226
00:12:33,403 --> 00:12:36,846
และนี่คือวิธีที่คุณสามารถมีโมเดลถึง 2.8

227
00:12:36,846 --> 00:12:38,699
ล้านล้านพารามิเตรอได้

228
00:12:38,699 --> 00:12:41,347
ความรู้ทั้งหมดของทีมอยู่ที่นี่

229
00:12:41,347 --> 00:12:44,524
แต่ต้องใช้พารามิเตอร์ทำงานจริงแค่ 50

230
00:12:44,524 --> 00:12:46,201
พันล้านเท่านั้นครับ

231
00:12:46,201 --> 00:12:48,761
คุณจึงได้ความรู้ของโมเดลยักษ์

232
00:12:48,761 --> 00:12:51,321
ในราคาทุนการทำงานของโมเดลเล็ก

233
00:12:51,321 --> 00:12:53,527
และนี่คือเทคนิคที่สองครับ

234
00:12:53,527 --> 00:12:57,146
แต่เราจะรู้ได้ยังไงว่าควรส่งคำถามไปให้ 16

235
00:12:57,146 --> 00:13:00,677
คนไหน? คำถามของคุณมาถึงครับ receptionist

236
00:13:00,677 --> 00:13:04,560
(พนักงานต้อนรับ) อ่านมันแล้วเรียก specialist

237
00:13:04,560 --> 00:13:08,267
ที่เกี่ยวข้อง 16 คนเข้ามา ตัว receptionist

238
00:13:08,267 --> 00:13:11,445
นี่แหละครับที่เราเรียกว่า router แต่

239
00:13:11,445 --> 00:13:14,357
specialist ไม่ได้ติดป้ายตามหัวข้อ

240
00:13:14,357 --> 00:13:17,888
พวกเขาเรียนรู้เองว่าตัวเองเก่งเรื่องอะไร

241
00:13:17,888 --> 00:13:21,948
และตัว router นี่แหละที่เรียนรู้ว่าควรเรียกใคร

242
00:13:21,948 --> 00:13:25,214
เราเห็นได้จาก chart ตรงนี้ครับ router

243
00:13:25,214 --> 00:13:27,244
ทีนี้มาดูส่วนที่ยากครับ

244
00:13:27,244 --> 00:13:29,450
ซึ่งหลายการอธิบายจะข้ามไป

245
00:13:29,450 --> 00:13:33,511
คำถามคือเกิดอะไรขึ้นถ้าทุกคนอยากได้ specialist

246
00:13:33,511 --> 00:13:34,923
คนเดียวกัน 3 คน?

247
00:13:34,923 --> 00:13:39,248
คนเหล่านั้นจะทำงานไม่ไหว ขณะที่อีก 880 คนนั่งเฉยๆ

248
00:13:39,248 --> 00:13:41,543
ไม่ได้ทำอะไรเลยใช่มั้ยครับ

249
00:13:41,543 --> 00:13:44,014
มันไม่ใช่แค่ไม่มีประสิทธิภาพ

250
00:13:44,014 --> 00:13:45,603
ถ้าปล่อยไว้ตอนเทรน

251
00:13:45,603 --> 00:13:49,221
มันจะทำให้ทั้งระบบล่มเลยครับ เพราะ expert

252
00:13:49,221 --> 00:13:52,222
ยอดนิยมจะได้ฝึกทั้งหมด ส่วนคนอื่นๆ

253
00:13:52,222 --> 00:13:54,076
ไม่ได้เรียนรู้อะไรเลย

254
00:13:54,076 --> 00:13:57,871
โมเดลส่วนใหญ่จะแก้ด้วยการปรับค่า hard tuned

255
00:13:57,871 --> 00:13:59,637
nudge ที่ละเอียดอ่อน

256
00:13:59,637 --> 00:14:03,079
เพื่อดึงงานออกจากคนที่ยุ่ง มันได้ผลครับ

257
00:14:03,079 --> 00:14:06,433
แต่ก็ค่อนข้างเปราะบางและ drift ได้ง่าย

258
00:14:06,433 --> 00:14:10,052
ทางแก้ของ Kimi K3 คือการส่งงานตาม ranking

259
00:14:10,052 --> 00:14:13,847
แทนครับ มันดูว่า router ให้คะแนนใครไว้ยังไง

260
00:14:13,847 --> 00:14:15,965
แล้วก็กระจายตามลำดับนั้น

261
00:14:15,965 --> 00:14:19,055
ความสมดุลจึงเกิดขึ้นเองโดยอัตโนมัติ

262
00:14:19,055 --> 00:14:22,585
ไม่ต้องปรับเลขวิเศษอะไรเลยครับ และนี่คือ

263
00:14:22,585 --> 00:14:26,116
quantile balancing (การสมดุลตามควอนไทล์)

264
00:14:26,116 --> 00:14:30,529
ซึ่งเป็นสิ่งที่ทำให้พวกเขาสามารถไปได้ขนาดรุนแรงถึง

265
00:14:30,529 --> 00:14:33,883
16 จาก 896 โดยที่การเทรนไม่พังทลายครับ

266
00:14:33,883 --> 00:14:37,413
ทีนี้ลองมาดูภาพรวมทั้งหมดในแผนผังนี้ครับ

267
00:14:37,413 --> 00:14:41,209
เราได้พูดถึง Mixture of Experts แล้วครับ มี

268
00:14:41,209 --> 00:14:45,092
router มี quantile balancing มี expert ต่างๆ

269
00:14:45,092 --> 00:14:49,152
และมี SiLU ซึ่งเป็น custom activation function

270
00:14:49,152 --> 00:14:52,683
ที่ Kimi K3 ใช้ครับ เราผ่านมาแล้วสองส่วน

271
00:14:52,683 --> 00:14:56,478
คือการอ่าน การคิด และการใช้ specialist ครับ

272
00:14:56,478 --> 00:15:01,509
ทีนี้คำถามต่อไปที่เราจะดูคือเกิดอะไรขึ้นระหว่างสถานีต่างๆ

273
00:15:01,509 --> 00:15:04,245
ลองนึกภาพว่ามีวิ่งเรเลย์ทีมยาวๆ

274
00:15:04,245 --> 00:15:07,599
แต่ละคนส่งกองสิ่งของที่ใหญ่ขึ้นเรื่อยๆ

275
00:15:07,599 --> 00:15:08,835
ให้คนถัดไปครับ

276
00:15:08,835 --> 00:15:14,219
นี่คือวิธีที่ข้อมูลเคลื่อนที่ผ่านโมเดลเหล่านี้มาเป็นเวลาสิบปี

277
00:15:14,219 --> 00:15:17,485
ปัญหาที่เห็นได้ชัดก็คือการเจือจางครับ

278
00:15:17,485 --> 00:15:18,809
เมื่อถึงปลายทาง

279
00:15:18,809 --> 00:15:23,575
สิ่งที่นักวิ่งคนแรกสื่อสารไว้จะกลายเป็นรอยเลอะเทอะจางๆ

280
00:15:23,575 --> 00:15:27,106
ที่ถูกกลบด้วยทุกสิ่งที่ถูกวางทับมาข้างบน

281
00:15:27,106 --> 00:15:29,400
และจำได้มั้ยครับว่าเลข 900

282
00:15:29,400 --> 00:15:32,843
ซึ่งเป็นสิ่งที่นักวิ่งคนที่หนึ่งอ่านได้

283
00:15:32,843 --> 00:15:36,903
เป็นเลขที่สำคัญมาก มันอยู่ตรงจุดเริ่มต้นของสาย

284
00:15:36,903 --> 00:15:40,875
และสามารถหายไปได้ง่ายๆ ที่ปลายสุดเลยครับ Kimi

285
00:15:40,875 --> 00:15:43,170
K3 เปลี่ยนการส่งต่อนี้ครับ

286
00:15:43,170 --> 00:15:46,259
แทนที่จะรับแค่กองเดียวที่รวมกันแล้ว

287
00:15:46,259 --> 00:15:48,112
แต่ละสถานีจะได้ถามว่า

288
00:15:48,112 --> 00:15:51,202
"ฉันต้องการโน้ตของใครจริงๆ ที่นี่?"

289
00:15:51,202 --> 00:15:53,938
แล้วดึงเฉพาะสิ่งเหล่านั้นมาครับ

290
00:15:53,938 --> 00:15:58,616
มันเหมือนกับการหยิบรายงานที่ระบุชื่อไว้สามฉบับจากชั้น

291
00:15:58,616 --> 00:16:03,029
แทนที่จะอ่านเอกสารยักษ์ที่รวมกองกันมาเป็นก้อนเดียว

292
00:16:03,029 --> 00:16:06,471
และนี่คือ attention residuals (residual

293
00:16:06,471 --> 00:16:08,766
attention แบบตั้งฉาก) ครับ

294
00:16:08,766 --> 00:16:11,855
มันเป็นแนวคิดเดียวกับ attention เลย

295
00:16:11,855 --> 00:16:14,768
แค่หันไปทางข้างแทน ถ้าจำได้นะครับ

296
00:16:14,768 --> 00:16:18,563
ตอนต้นของการบรรยายนี้ ผมพูดถึงว่า attention

297
00:16:18,563 --> 00:16:21,917
ช่วยให้คำเลือกได้ว่าจะฟังคำอื่นๆ คำไหน

298
00:16:21,917 --> 00:16:25,713
ผมโชว์ให้ดูในสไลด์นี้ใช่มั้ยครับ คำว่า "it"

299
00:16:25,713 --> 00:16:29,331
ฟังคำว่า "cat" นี่เป็นแนวคิดที่เปลี่ยน AI

300
00:16:29,331 --> 00:16:30,567
ไปเลยในปี 2017

301
00:16:30,567 --> 00:16:33,568
และนี่คือแนวคิดเดียวกันเป๊ะเลยครับ

302
00:16:33,568 --> 00:16:35,245
แค่หันไปทางด้านข้าง

303
00:16:35,245 --> 00:16:38,864
มันช่วยให้สถานีเลือกได้ว่าจะฟังสถานีอื่นๆ

304
00:16:38,864 --> 00:16:42,483
สถานีไหน เป็นเทคนิค attention ตัวเดียวกัน

305
00:16:42,483 --> 00:16:44,071
แค่ต่างมิติกันครับ

306
00:16:44,071 --> 00:16:47,778
และนี่เป็นหนึ่งในไม่กี่ชิ้นส่วนของ Kimi K3

307
00:16:47,778 --> 00:16:50,338
ที่ดูเหมือนจะเป็นของใหม่จริงๆ

308
00:16:50,338 --> 00:16:52,368
แทนที่จะยืมมาจากที่อื่น

309
00:16:52,368 --> 00:16:56,163
คุณเห็นได้ตรงนี้เลยครับ attention residuals

310
00:16:56,163 --> 00:16:59,870
และคุณจะสังเกตเห็นว่ามันอยู่ตรงไหนใน chart

311
00:16:59,870 --> 00:17:03,666
ครับ มัน feed เข้า layer แทนที่จะอยู่ข้างใน

312
00:17:03,666 --> 00:17:07,638
และนี่คือสิ่งที่ทำให้มันต่างจาก attention และ

313
00:17:07,638 --> 00:17:10,992
expert machinery ที่เราดูมาก่อนหน้านี้

314
00:17:10,992 --> 00:17:14,434
มันเป็นเรื่องของวิธีที่ layer พูดคุยกัน

315
00:17:14,434 --> 00:17:18,406
ไม่ใช่สิ่งที่เกิดขึ้นข้างใน layer ครับ เอาล่ะ

316
00:17:18,406 --> 00:17:20,965
เราอ่านคำถามแล้ว คิดทบทวนแล้ว

317
00:17:20,965 --> 00:17:22,995
ทีนี้ต้องเขียนคำตอบครับ

318
00:17:22,995 --> 00:17:26,791
และตรงนี้คอขวดกลับกลายเป็นด้านตรงกันข้ามเลย

319
00:17:26,791 --> 00:17:29,615
การอ่านเป็นเรื่องของการคิดให้ลึก

320
00:17:29,615 --> 00:17:33,764
แต่การเขียนเป็นเรื่องของการดึงข้อมูลให้เร็วครับ

321
00:17:33,764 --> 00:17:36,676
เพราะก่อนที่จะผลิต token เดียวได้

322
00:17:36,676 --> 00:17:39,942
โมเดลต้องไปดึง weight ทุกตัวที่ token

323
00:17:39,942 --> 00:17:44,002
นั้นต้องการออกมาจริงๆ เป็นพันล้านค่าที่เก็บไว้

324
00:17:44,002 --> 00:17:46,120
แล้วลากผ่าน processor มา

325
00:17:46,120 --> 00:17:48,680
แล้วทำแบบเดียวกันสำหรับ token

326
00:17:48,680 --> 00:17:52,211
ถัดไปและถัดไปครับ อนุมานที่ผมคิดได้ก็คือ

327
00:17:52,211 --> 00:17:57,330
ลองนึกถึงเชฟที่ต้องเดินไปคลังวัตถุดิบเพื่อหยิบทุกอย่างครับ

328
00:17:57,330 --> 00:17:59,272
การทำอาหารเองไม่ได้ช้า

329
00:17:59,272 --> 00:18:02,096
แต่การเดินไปกลับต่างหากที่ช้าได้

330
00:18:02,096 --> 00:18:03,861
ถ้าอยากเขียนเร็วขึ้น

331
00:18:03,861 --> 00:18:06,156
ก็มีลิเวอร์เดียวที่ขาดครับ

332
00:18:06,156 --> 00:18:08,451
ทำให้คลังเล็กลงใช่มั้ยครับ

333
00:18:08,451 --> 00:18:11,011
และนั่นคือสิ่งที่พวกเขาทำครับ

334
00:18:11,011 --> 00:18:14,718
เก็บทุกอย่างไว้ในรูปแบบ shorthand แบบหนึ่ง

335
00:18:14,718 --> 00:18:17,189
และนี่คือ 4-bit quantization

336
00:18:17,189 --> 00:18:20,543
(การทำให้ค่าเป็นเลข 4 บิต) ผมเคยพูดถึง

337
00:18:20,543 --> 00:18:23,809
quantization มาหลายครั้งในวิดีโอก่อนๆ

338
00:18:23,809 --> 00:18:27,604
แต่โดยพื้นฐานแล้วมันคือวิธีลดขนาดของ weight

339
00:18:27,604 --> 00:18:28,704
ครับ

340
00:18:28,704 --> 00:18:35,059
ปกติแล้วค่าตั้งค่านับล้านล้านเหล่านี้จะถูกเก็บในรูปแบบที่ค่อนข้างใจกว้าง

341
00:18:35,059 --> 00:18:36,383
เขียนออกมาเต็มๆ

342
00:18:36,383 --> 00:18:49,446
Kimi K3 จะมีขนาด weight ราว 5.5 terabytes ครับ นั่นไม่ใช่โมเดลที่ deploy ได้ จะกลายเป็นปัญหาระดับ data center เลย แต่ถ้าเก็บทุกอย่างในรูป shorthand,

343
00:18:49,446 --> 00:19:18,044
4 bit ต่อค่าแทนที่จะเป็น 16 bit ขนาดจะเหลือราว 1.4 terabytes ครับ เหลือเศษหนึ่งส่วนสี่ของขนาดเดิม อย่างที่บอก นี่คือ 4-bit quantization และรูปแบบเฉพาะที่ Kimi K3 ใช้เรียกว่า MX FP4 ครับ คุณมีคลังเล็กลง ระยะเดินไปหยิบของก็สั้นลง และสังเกตว่ามันอยู่ตรงไหนในแผนผังนี้ครับ มันไม่ได้อยู่ใน pipeline ของ prefill และ decoding จริงๆ

344
00:19:18,044 --> 00:19:19,897
แต่อยู่บนพื้นด้านล่าง

345
00:19:19,897 --> 00:19:22,633
เพราะสิ่งนี้เกิดขึ้นตอนเทรนครับ

346
00:19:22,633 --> 00:19:26,693
ทุกกล่องที่ทำงานอยู่ด้านบนทำงานบน 4-bit weight

347
00:19:26,693 --> 00:19:28,723
และโครงสร้าง whiteboard

348
00:19:28,723 --> 00:19:31,724
ก็คุ้มค่าเป็นครั้งที่สองที่นี่ครับ

349
00:19:31,724 --> 00:19:34,902
ปกติแล้วยิ่งคำตอบยาวขึ้น แต่ละ token

350
00:19:34,902 --> 00:19:38,432
ใหม่จะต้องการ memory มากขึ้น แต่ summary

351
00:19:38,432 --> 00:19:41,786
ขนาดคงที่ไม่โตขึ้นครับ token ที่ 5,000

352
00:19:41,786 --> 00:19:45,140
จึงมีค่าใช้จ่ายเท่ากับ token ที่ 5 เลย

353
00:19:45,140 --> 00:19:48,583
ทีนี้เรื่องการเขียนคำตอบ ผมอธิบายเรื่อง

354
00:19:48,583 --> 00:19:51,054
shorthand storage ไปแล้วครับ

355
00:19:51,054 --> 00:19:56,615
เทคนิคสุดท้ายสองอย่างนี้เกิดขึ้นหลายเดือนก่อนที่คุณจะถามอะไรเลย

356
00:19:56,615 --> 00:19:58,292
เกิดขึ้นตอนเทรนครับ

357
00:19:58,292 --> 00:20:01,646
โมเดลส่วนใหญ่เทรนทั้งหมดในโปรแกรมเดียว

358
00:20:01,646 --> 00:20:05,441
ชุดกฎชุดเดียวว่าแต่ละส่วนเรียนรู้เร็วแค่ไหน

359
00:20:05,441 --> 00:20:08,707
Kimi K3 โค้ชผู้เล่นทุกคนแยกจากกันครับ

360
00:20:08,707 --> 00:20:11,531
แต่ละส่วนของ attention machinery

361
00:20:11,531 --> 00:20:15,591
จะได้รับการเทรนที่ปรับเฉพาะ และนี่คือ per-head

362
00:20:15,591 --> 00:20:18,945
Muon (Muon รายหัว) ครับ และอีกอย่างกับ

363
00:20:18,945 --> 00:20:23,005
attention residuals นี่เป็นอีกหนึ่งชิ้นส่วนของ

364
00:20:23,005 --> 00:20:26,712
Kimi K3 ที่ดูเหมือนจะเป็นของใหม่จริงๆ ครับ

365
00:20:26,712 --> 00:20:31,390
ทางแก้ที่สองเป็นการแก้ปัญหาที่ผมข้ามไปก่อนหน้านี้ครับ

366
00:20:31,390 --> 00:20:35,451
ผมบอกไปว่าพวกเขาเก็บโมเดลในรูป 4-bit shorthand

367
00:20:35,451 --> 00:20:38,098
แต่คุณน่าจะสงสัยเรื่องนั้นครับ

368
00:20:38,098 --> 00:20:41,364
การบีบอัดขนาดนั้นมักจะทำให้มันพังครับ

369
00:20:41,364 --> 00:20:45,248
ถ้าคุณเคยมีประสบการณ์กับ quantization มาบ้าง

370
00:20:45,248 --> 00:20:47,543
คุณอาจจะเคยเจอเรื่องแบบนี้

371
00:20:47,543 --> 00:20:51,073
มีสองวิธีที่จะได้โมเดลที่ถูกบีบอัดมาครับ

372
00:20:51,073 --> 00:20:54,868
วิธีปกติคือเทรนโมเดลโดยเขียนออกมาเต็มรูปแบบ

373
00:20:54,868 --> 00:20:57,340
แล้วค่อยย่อให้สั้นที่ปลายสุด

374
00:20:57,340 --> 00:20:59,546
นี่คือสิ่งที่เกือบทุกคนทำ

375
00:20:59,546 --> 00:21:02,283
และความหมายจะหายไประหว่างการบีบ

376
00:21:02,283 --> 00:21:05,901
เพราะโมเดลไม่เคยมีโอกาสปรับตัวเลย Kimi K3

377
00:21:05,901 --> 00:21:09,432
ใช้วิธีที่ต่างออกไปครับ มันเรียนรู้ในรูป

378
00:21:09,432 --> 00:21:11,462
shorthand ตั้งแต่แรกเลย

379
00:21:11,462 --> 00:21:18,258
ใช้เวลาเทรนทั้งหมดฝึกจนชำนาญในการทำงานให้แม่นยำภายในรูปแบบที่ถูกบีบอัดนี้ครับ

380
00:21:18,258 --> 00:21:21,524
และนี่คือเหตุผลที่ 4-bit quantization

381
00:21:21,524 --> 00:21:24,437
ไม่ทำให้มันพังครับ และอย่างที่บอก

382
00:21:24,437 --> 00:21:28,232
องค์ประกอบสองอย่างนี้ per-head Muon และ QAT

383
00:21:28,232 --> 00:21:31,498
from SFT อยู่นอก pipeline ทั้งหมดครับ

384
00:21:31,498 --> 00:21:33,704
ไม่ใช่สิ่งที่โมเดลทำจริงๆ

385
00:21:33,704 --> 00:21:40,412
เป็นวิธีที่มันถูกสร้างขึ้นมาครับ นี่คือแผนผังทั้งหมดครับ ทั้ง 4 พื้นที่ต่างๆ

386
00:21:40,412 --> 00:21:48,444
และวิธีที่สถาปัตยกรรมไม่เหมือนใครของ Kimi K3 ช่วยปรับประสิทธิภาพผ่านแต่ละจุด และเทคนิคเล็กๆ

387
00:21:48,444 --> 00:21:50,298
น้อยๆ ที่ทำระหว่างทาง

388
00:21:50,298 --> 00:21:54,181
รายงานบอกว่าการเทรนมีประสิทธิภาพดีขึ้นประมาณ

389
00:21:54,181 --> 00:21:57,535
2.5 เท่าเมื่อเทียบกับโมเดลก่อนหน้าครับ

390
00:21:57,535 --> 00:22:01,243
กลับมาที่คำถามหลักของเราครับ โมเดลตอบอะไร?

391
00:22:01,243 --> 00:22:05,920
มันหาคำตอบโดยใช้ทุกเทคนิคที่ผมพูดถึงไปก่อนหน้านี้ครับ

392
00:22:05,920 --> 00:22:09,098
retry delay สามารถคงอยู่ตลอด session

393
00:22:09,098 --> 00:22:11,305
ที่กำลังพยายาม renew อยู่

394
00:22:11,305 --> 00:22:17,660
และวิธีแก้ที่มันเสนอคือการเชื่อมไฟล์ที่อยู่ห่างกันสองไฟล์เข้าด้วยกันครับ

395
00:22:17,660 --> 00:22:21,896
มันแก้ปัญหาด้วยวิธีเดียวกับที่มันคิดถึงปัญหาครับ

396
00:22:21,896 --> 00:22:26,309
คือการเชื่อมสองสิ่งที่อยู่ห่างไกลกันมากเข้าด้วยกัน

397
00:22:26,309 --> 00:22:30,016
เทคนิคเหล่านี้ไม่มีอันไหนซ้อนทับกันเลยครับ

398
00:22:30,016 --> 00:22:32,311
แต่ละอันโจมตีต้นทุนคนละจุด

399
00:22:32,311 --> 00:22:36,018
การประหยัดจึงไม่ได้แค่บวกกัน แต่คูณกันครับ

400
00:22:36,018 --> 00:22:39,372
และนี่คือสถาปัตยกรรมทั้งหมดของ Kimi K3

401
00:22:39,372 --> 00:22:42,197
ในหนึ่งประโยคครับ เท่านี้เองครับ

402
00:22:42,197 --> 00:22:44,756
ผมรู้ว่าตอนแรกมันดูน่ากลัวมาก

403
00:22:44,756 --> 00:22:50,140
แต่ตอนนี้คุณน่าจะมีความเข้าใจภาพรวมแล้วว่าแต่ละส่วนทำงานยังไง

404
00:22:50,140 --> 00:22:51,817
การแบ่งแยกส่วนต่างๆ

405
00:22:51,817 --> 00:22:58,702
แบบนี้ช่วยให้เข้าใจง่ายขึ้นครับ แน่นอนถ้าคุณอยากเจาะลึกแต่ละส่วนให้ละเอียดสุดๆ

406
00:22:58,702 --> 00:22:59,802
ก็ทำได้ครับ

407
00:22:59,802 --> 00:23:04,303
แต่ผมแค่อยากให้คุณเห็นภาพรวมว่าสถาปัตยกรรมเป็นยังไง

408
00:23:04,303 --> 00:23:07,393
และแต่ละองค์ประกอบทำงานร่วมกันยังไง

409
00:23:07,393 --> 00:23:11,541
ขอเพิ่มข้อควรระวังสองข้อเพื่อให้ซื่อสัตย์นะครับ

410
00:23:11,541 --> 00:23:14,101
ไม่งั้นจะมีคนคอมเมนต์เยอะแน่ๆ

411
00:23:14,101 --> 00:23:19,485
ส่วนใหญ่ของสิ่งเหล่านี้ไม่ใช่ของใหม่ทั้งหมดนะครับ whiteboard,

412
00:23:19,485 --> 00:23:20,585
safety net,

413
00:23:20,585 --> 00:23:40,797
specialist เหล่านี้เป็นการปรับปรุงจากงานวิจัยที่ตีพิมพ์แล้วทั้งนั้น และส่วนใหญ่เป็นของ Moonshot เองครับ พวกเขาทำงานในทิศทางนี้มานานแล้ว และตัวเลขเองก็ยังไม่ได้รับการยืนยันครับ เราได้แผนผังสถาปัตยกรรมมา แต่ตัวเลข performance จริงๆ

414
00:23:40,797 --> 00:23:43,975
ส่วนใหญ่มาจาก Moonshot หรือจาก paper

415
00:23:43,975 --> 00:23:47,858
ก่อนหน้าที่ดีไซน์นี้อิงจาก Kimi K3 technical

416
00:23:47,858 --> 00:23:50,418
report ยังไม่ออกมาเต็มที่ครับ

417
00:23:50,418 --> 00:23:53,242
และยังไม่มีการปล่อย weight ออกมา

418
00:23:53,242 --> 00:23:55,890
น่าจะเกิดขึ้นในสัปดาห์หน้าครับ

419
00:23:55,890 --> 00:23:59,244
ผมเลยไม่ได้เชื่อตัวเลขตรงนี้ 100% ครับ

420
00:23:59,244 --> 00:24:03,216
ผมหวังว่าคุณจะสนุกกับการดูสถาปัตยกรรมของ Kimi

421
00:24:03,216 --> 00:24:06,835
K3 ไปกับผมนะครับ เราได้เห็นว่าอนาคตของ AI

422
00:24:06,835 --> 00:24:09,571
ไม่ใช่แค่โมเดลที่ใหญ่ขึ้นนะครับ

423
00:24:09,571 --> 00:24:12,925
แต่เป็นโมเดลที่รู้ว่าควรข้ามอะไรไปบ้าง

424
00:24:12,925 --> 00:24:17,779
เพื่อให้ทำงานได้มีประสิทธิภาพและมีประสิทธิผลมากขึ้นครับ

425
00:24:17,779 --> 00:24:19,809
ฝากคอมเมนต์กันได้นะครับ

426
00:24:19,809 --> 00:24:22,281
ถ้ามีคำถามหรือความคิดเห็นใดๆ

427
00:24:22,281 --> 00:24:24,134
ฝากบอกกันได้เลยนะครับ

428
00:24:24,134 --> 00:24:28,106
หลายคนในนี้ผมเชื่อว่ารู้เรื่องสถาปัตยกรรม LLM

429
00:24:28,106 --> 00:24:30,136
พวกนี้ดีกว่าผมก็ได้ครับ

430
00:24:30,136 --> 00:24:32,519
อยากฟังความเห็นจากทุกคนครับ

431
00:24:32,519 --> 00:24:37,815
และผมสัญญาว่าเราจะทำการทดลองกับสถาปัตยกรรมเหล่านี้ให้มากขึ้น

432
00:24:37,815 --> 00:24:41,081
ไม่ใช่แค่การบรรยายเพียงอย่างเดียวครับ

433
00:24:41,081 --> 00:24:44,788
แต่สำหรับวิดีโอนี้ก็ต้องจบเพียงเท่านี้ครับ

434
00:24:44,788 --> 00:24:45,120
ขอบคุณที่รับชมนะครับ