Mặt tối của mặt trăng và bài báo mới của Tsinghua: Tiền điền trước LLM có thể vượt qua trung tâm dữ liệu, thông lượng của mô hình 1T tăng 54%

robot
Đang tạo bản tóm tắt
ME Tin tức tin tức, ngày 18 tháng 4 (UTC+8), theo giám sát Beating của Dongcha, Moonshot AI và Đại học Thanh Hoa đã đăng bài báo mới trên arXiv ngày 16 tháng 4 với tiêu đề 《Prefill-as-a-Service》, đề xuất cho phép giai đoạn tiền điền (prefill) của mô hình lớn chạy chéo trung tâm dữ liệu.
Phân tích suy luận của mô hình lớn gồm hai bước: prefill đọc toàn bộ đầu vào một lần và tạo ra một bộ đệm KV; decode sau đó dựa trên bộ đệm này để từng từ xuất ra kết quả.
Hai bước này yêu cầu đặc tính phần cứng hoàn toàn khác nhau, prefill tiêu tốn sức mạnh tính toán, decode tiêu thụ bộ nhớ GPU và băng thông RAM.
Phương pháp chủ đạo trong ngành là tách hai bước ra các máy khác nhau (PD phân tách), nhưng điều này yêu cầu hai bên trong cùng một trung tâm dữ liệu kết nối qua RDMA, vì bộ đệm KV của mô hình attention tập trung xuất ra hàng chục Gbps mỗi giây, nếu truyền chậm GPU sẽ rỗng chạy.
Sự chuyển biến đến từ mô hình attention lai thế hệ mới.
Bài báo thực nghiệm cho thấy các mô hình như Kimi Linear, MiMo-V2-Flash, Ring-2.5-1T, qua việc kết hợp ít lớp attention đầy đủ với nhiều lớp tuyến tính, đã giảm lượng tiêu thụ bộ đệm KV khoảng một cấp độ, tỷ lệ nén tổng thể của Ring-2.5-1T đạt 36 lần.
Lúc này, bộ đệm KV có thể chuyển từ mạng riêng RDMA sang mạng Ethernet thông thường để truyền.
Cách thực hiện của PrfaaS: thành lập "cụm tiền điền" độc lập, chỉ định tuyến các yêu cầu có ngữ cảnh dài, tiền tố chưa trúng, còn các yêu cầu ngắn giữ lại trong cụm PD cục bộ; sau khi tiền điền hoàn tất, gửi bộ đệm KV qua Ethernet về cụm cục bộ để decode.
Kèm theo đó là giới hạn độ dài tuyến đường, bộ điều phối cảm nhận băng thông và bể đệm tiền tố lai.
Bài báo đã thực nghiệm với mô hình hybrid nội bộ 1T tham số (dựa trên kiến trúc Kimi Linear), cho thấy tổng thể qua lại dịch vụ cao hơn 54% so với triển khai PD đồng nhất, cao hơn 32% so với phương án lai đơn giản, mỗi máy chỉ tiêu thụ băng thông chéo trung tâm dữ liệu vừa phải.
(Nguồn: BlockBeats)
Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
  • Phần thưởng
  • 9
  • 2
  • Retweed
Bình luận
Thêm một bình luận
Thêm một bình luận
YieldNotYell
· 2giờ trước
Thiết kế định tuyến ngưỡng độ dài này rất chi tiết, xử lý yêu cầu dài và ngắn riêng mới là tối ưu đúng đắn
Xem bản gốcTrả lời0
CircuitDaydreamer
· 5giờ trước
Mô hình chú ý pha trộn giảm thông lượng bộ đệm KV, chi tiết kỹ thuật và các bài báo nghiên cứu kỹ lưỡng
Xem bản gốcTrả lời0
AirdropCartographer
· 6giờ trước
Tăng 54% thực sự hấp dẫn, nhưng khi chuyển qua trung tâm dữ liệu khác bằng Ethernet, làm thế nào để xử lý jitter?
Xem bản gốcTrả lời0
DeepSeaColdStart
· 6giờ trước
Chỉ có các yêu cầu không trúng tuyến đường, tỷ lệ trúng bộ nhớ đệm trở thành điểm nghẽn chính
Xem bản gốcTrả lời0
UnderTheGlassDome
· 6giờ trước
PD đồng cấu so với PD dị cấu so với PrfaaS, sự so sánh theo các chiều cạnh này được đặt ra khá thông minh
Xem bản gốcTrả lời0
BluePeonyCalmingAgent
· 6giờ trước
1T tham số mô hình đo cái này, chi phí phần cứng không dám nghĩ
Xem bản gốcTrả lời0
GateUser-fb035825
· 6giờ trước
Triển khai độc lập cụm tiền điền trước, độ phức tạp vận hành và bảo trì lại tăng lên, lợi ích có xứng đáng không
Xem bản gốcTrả lời0
IdleFishDaoMember
· 6giờ trước
Lập lịch cảm nhận băng thông nghe có vẻ đơn giản, thực tế triển khai ước chừng gặp phải vô số chông gai
Xem bản gốcTrả lời0
GateUser-aa277334
· 6giờ trước
Ý tưởng này thú vị, bỏ phần điền sẵn vào xa phía đám mây, tập trung xử lý giải mã tại chỗ, độ trễ có chịu nổi không
Xem bản gốcTrả lời0
Xem thêm
  • Đã ghim