Tính phi xác định của GPT-4 là do Sparse MoE

 (152334H.github.io)
1 điểm bởi GN⁺ 2023-08-06 | 1 bình luận | Chia sẻ qua WhatsApp
  • Ngay cả khi temperature=0, GPT-4 và GPT-3.5-turbo vẫn cho ra đầu ra khác nhau mỗi lần với cùng một đầu vào, một hành vi bất thường không xuất hiện ở các mô hình decoder dense truyền thống
  • Từ trước đến nay, nguyên nhân của tính phi xác định thường được giải thích là do sự bất ổn của phép toán dấu phẩy động CUDA, nhưng chỉ như vậy thì vẫn chưa đủ để giải thích
  • Trong cấu trúc batched inference của kiến trúc Sparse MoE, các token từ những chuỗi khác nhau trong cùng một batch cạnh tranh vị trí trong bộ đệm expert, từ đó phát sinh tính phi xác định
  • Trong thí nghiệm gọi lặp lại 30 lần, GPT-4 tạo ra số lượng đầu ra duy nhất nhiều vượt trội so với các mô hình khác, qua đó củng cố giả thuyết bằng thực nghiệm
  • Việc mô hình chỉ mang tính quyết định ở cấp batch chứ không phải cấp chuỗi là nguyên nhân cốt lõi của vấn đề độ tin cậy trong API GPT-4

Nêu vấn đề — temperature=0 mà vì sao đầu ra vẫn khác nhau mỗi lần

  • Việc GPT-4/GPT-3.5-turbo phi xác định ngay cả ở temperature=0.0 đã là điều được biết đến rộng rãi
    • với mô hình dense decoder-only, temp=0 có nghĩa là greedy sampling, và điều này lẽ ra phải dẫn đến tính xác định hoàn toàn
    • vì logits của token tiếp theo là một hàm thuần túy chỉ phụ thuộc vào chuỗi đầu vào và trọng số mô hình
  • Câu trả lời của đội ngũ kỹ thuật tại bàn tròn dành cho nhà phát triển trong OpenAI World Tour
    • "Thành thật mà nói, chính chúng tôi cũng thấy khó hiểu. Có thể là bug hệ thống hoặc là tính phi xác định trong phép tính dấu phẩy động đã được tối ưu hóa"
  • Hành vi này đã được nhắc tới từ 2 năm trước nhưng vẫn chưa được giải quyết, nên càng gây thắc mắc
    • vì OpenAI nhấn mạnh reliability, nên khó có lý do gì để họ cố tình giữ lại tính phi xác định; do đó ban đầu, lời giải thích hợp lý nhất được xem là giới hạn phần cứng không thể khắc phục

Giả thuyết mới — manh mối tìm thấy trong bài báo Soft MoE

  • Phát hiện một mối liên hệ mang tính quyết định ở mục 2.2 của bài báo Soft MoE
    • dưới các ràng buộc về dung lượng (capacity constraints), mọi phương pháp Sparse MoE đều định tuyến token theo các nhóm kích thước cố định và ép buộc hoặc khuyến khích sự cân bằng trong nhóm
    • khi một nhóm chứa token từ các chuỗi/đầu vào khác nhau, các token này sẽ cạnh tranh với nhau để giành chỗ trống trong bộ đệm expert
    • kết quả là mô hình phi xác định ở cấp chuỗi và chỉ xác định ở cấp batch, và một số chuỗi đầu vào có thể ảnh hưởng tới dự đoán cuối cùng của đầu vào khác
  • Việc GPT-4 là mô hình Mixture of Experts vốn đã là thông tin được công khai
    • GPT-4 được huấn luyện trước quý 2 năm 2022, và Sparse MoE đã tồn tại từ trước đó
  • Giả thuyết cốt lõi được đưa ra
    • API GPT-4 được lưu trữ trên một backend thực hiện batched inference
    • có thể còn một số yếu tố khác tác động, nhưng phần lớn tính phi xác định của API bắt nguồn từ việc kiến trúc Sparse MoE không thể cưỡng chế tính xác định theo từng chuỗi

Kiểm chứng — xác nhận đây không phải vấn đề phần cứng

  • Để kiểm tra giả thuyết, tác giả yêu cầu chính GPT-4 viết script thử nghiệm
    • với các chat model (gpt-4, gpt-3.5-turbo) và completion model (text-davinci-003/001, davinci-instruct-beta, davinci), lặp lại cùng một prompt với temperature=0 và đếm số đầu ra duy nhất
  • Các vấn đề phát sinh trong lúc viết script
    • phản hồi từ OpenAI API rất chậm, ngay cả gọi 3.5 turbo cũng gần như bị trễ 10 giây; tác giả thêm log timestamp để xác nhận đó không phải lỗi phía mình
    • một số completion model cắt phản hồi quá sớm, nên đã hiệu chỉnh bằng cách áp logit bias lên token EOS
    • với token <|im_end|> (100265) của chat model thì không thể áp dụng bias tương đương, vì API trả lỗi khóa vượt quá giá trị tối đa 100257
      • do phần lớn completion đã chạm max token length và chat model vốn đã phi xác định hơn nhiều, nên hạn chế này được xem là vấn đề không cốt lõi

Kết quả thực nghiệm

  • 3 lần thử, điều kiện N=30, max_tokens=128, số đầu ra duy nhất (trung bình/30)
    • gpt-4: 12, 11, 12 — trung bình 11.67
    • gpt-3.5-turbo: 4, 4, 3 — trung bình 3.67
    • text-davinci-003: 3, 2, 4 — trung bình 3.00
    • text-davinci-001: 2, 2, 2 — trung bình 2.00
    • davinci-instruct-beta: 1, 1, 1 — có tính xác định, đầu ra sụp vào vòng lặp lặp lại
    • davinci: 1, 1, 1 — có tính xác định, đầu ra sụp vào vòng lặp lặp lại
  • Kết quả ở điều kiện max_tokens=256 trước khi phát hiện vấn đề logit_bias
    • gpt-4: 30, gpt-3.5-turbo: 9, text-davinci-003: 5, text-davinci-001: 2

Diễn giải kết quả

  • Số lượng đầu ra duy nhất của GPT-4 cao bất thường, đến mức với đầu ra dài thì gần như luôn phi xác định
  • Những mô hình khác không sụp vào vòng lặp lặp lại cũng vẫn có một mức độ phi xác định nhất định; điều này phù hợp với tuyên bố công khai rằng sự bất ổn trong tính toán GPU là nguồn gốc của một phần tính ngẫu nhiên
  • Các câu hỏi còn lại
    • vẫn chưa có lời giải thích rõ ràng vì sao tính ngẫu nhiên lại tăng dần từ text-davinci-001 tới gpt-3.5-turbo
    • cũng chưa thể loại trừ khả năng tính phi xác định mạnh của GPT-4 chỉ đơn giản là do số lượng tham số chứ không phải MoE; tuy nhiên việc Turbo nhanh hơn mà lại phi xác định hơn davinci thì mâu thuẫn với cách giải thích này

Hàm ý

Chúng ta đang tụt lại quá xa

  • Nếu tính phi xác định là đặc tính nội tại của batched inference trong Sparse MoE, thì đây lẽ ra phải là điều hiển nhiên với những người làm trong lĩnh vực này
  • Thực tế là phần lớn người dùng GPT-4 không biết nguyên nhân khiến API bất ổn cho thấy либо giả thuyết này sai, либо số người hiểu mô hình MoE quá ít nên cách giải thích này chưa thể trở thành nhận thức chung
  • Google Deepmind đã biết điều này và chỉ nhắc đến bằng một câu thoáng qua trong bài báo, xem nó như chuyện nhỏ; điều đó tạo cơ sở để lạc quan về Deepmind hơn so với các tổ chức chỉ làm mô hình dense

GPT-3.5-Turbo cũng có thể là MoE

  • Có tin đồn rằng 3.5-turbo dùng cùng kiến trúc với GPT-4 nhưng chỉ có số tham số ít hơn rất nhiều
  • Trong bối cảnh hiện tại cần tới 70B tham số mới đạt hiệu năng tương đương Turbo, thì xét tới quy mô lưu lượng và tốc độ mà OpenAI phải xử lý, rất khó giải thích Turbo bằng một mô hình dense đơn lẻ
  • Turbo là mô hình duy nhất khác trong API bị hạn chế không công khai logprobs
    • cách giải thích cũ là để ngăn tăng độ chính xác của distillation, nhưng sau các trường hợp như Orca thì lập luận này kém thuyết phục hơn
    • việc OpenAI công khai tuyên bố đang tích hợp logprobs vào ChatCompletions khiến cách diễn giải rằng "vấn đề không phải chống distillation mà là do bản chất quá ngẫu nhiên nên khó engineering ổn định" trở nên đáng tin hơn

Kết luận

  • Việc các mô hình GPT của OpenAI phi xác định ở temperature=0 là điều ai cũng biết
  • Nguyên nhân thông thường được chỉ ra là độ không chính xác của phép tính dấu phẩy động CUDA đã tối ưu hóa
  • Giả thuyết khác được đưa ra: batched inference của mô hình Sparse MoE là nguyên nhân gốc rễ của tính phi xác định trong API GPT-4, và đây là giả thuyết gọn gàng hơn cách giải thích cũ
  • Bằng thực nghiệm, tác giả cho thấy các lệnh gọi API GPT-4 (và một số mô hình 3.5) phi xác định hơn nhiều so với các mô hình OpenAI khác
  • Dựa trên tốc độ, tính phi xác định và việc loại bỏ logprobs, tác giả suy đoán rằng GPT-3.5-turbo cũng có thể là MoE

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-08-06
Các ý kiến trên Hacker News

  • Sai số dấu phẩy động thường mang tính quyết định, nên nếu chạy cùng một phép tính hai lần thì kết quả phải giống nhau đến từng bit
    Kết quả chỉ phân kỳ khi có trạng thái khác hoặc nguồn entropy nào đó, chẳng hạn không khởi tạo đúng bộ đệm về 0, có điều kiện tranh chấp, hoặc không thiết lập nhất quán cờ chế độ làm tròn
    Nhìn vào chất lượng mã được chắp vá vội trong hệ sinh thái AI/ML, có lẽ cả ba điều này, thậm chí còn hơn thế, đều đang xảy ra

    • Trên GPU thì không phải vậy: https://www.twosigma.com/articles/a-workaround-for-non-deter...
      Trong trường hợp này, do tính song song của GPU, thứ tự cộng các con số là không quyết định, và kết quả có thể hơi khác nhau
      Tốt nhất nên tránh chê bai mã của người khác khi đó là mã viết trên những hệ thống mình chưa hiểu rõ
      CPU cũng có thể gặp chuyện tương tự vì xử lý song song, nhưng trong khi phần lớn từng lệnh riêng lẻ của CPU là quyết định, CUDA lại cung cấp các phép toán cơ bản không quyết định
      Đây là thiết kế có chủ ý vì chúng nhanh hơn các đối ứng quyết định, và vấn đề là bài viết diễn đạt như thể đó là lỗi do mã tệ gây ra
    • Khi có tính song song, nhận định đó có thể không còn đúng
      Ví dụ, một số phép toán dấu phẩy động như cộng hoặc nhân không có tính kết hợp, nên kết quả sẽ khác nhau tùy theo thứ tự thực thi hoàn tất phép thu gọn (reduction)
      Trong môi trường song song, có những triển khai vì hiệu năng mà làm cho thứ tự thu gọn trở nên không quyết định, do đó kết quả cuối cùng cũng không quyết định
    • Về mặt toán học, phép tính là quyết định, nhưng thiết bị vật lý thực sự thực hiện phép tính có nhiều cách khiến kết quả phần mềm trở thành hàm của thời gian
      Chỉ một lệnh gọi GetTimeOfDay() cũng đủ, và độ trôi tần số xung nhịp giữa nhiều bộ xử lý cũng có thể như vậy
    • Tôi tự hỏi nếu mô phỏng bài toán bi-a tròn của Alhazen trong n bước thì liệu kết quả có giống nhau sau nhiều lần chạy không
      https://forumgeom.fau.edu/FG2012volume12/FG201216.pdf
    • Ở quy mô lớn, chỉ riêng việc không có bộ nhớ ECC tốt cũng đã đủ tạo ra entropy

  • Không chắc tôi đã hiểu đúng phần trích từ bài báo tham khảo chưa
    Có phải ý là một phần suy luận hiệu quả hơn phụ thuộc vào việc trộn token từ các đầu vào hoàn toàn riêng biệt, chẳng hạn đầu vào của người dùng khác? Và tùy vào các đầu vào khác vô tình nằm cùng một nhóm, tỷ lệ phân bổ cho “chuyên gia” sẽ thay đổi, khiến kết quả hoàn thiện cuối cùng cũng khác đi?
    Nếu vậy thì không chỉ là đưa tính không quyết định vào hệ thống; chất lượng phản hồi còn có thể phụ thuộc vào số lượng yêu cầu đồng thời đang cạnh tranh để được phân bổ vào cùng các chuyên gia
    Ví dụ, phần hệ thống giỏi dịch/diễn giải tiếng Hindi có thể cho kết quả tệ hơn vào giờ cao điểm ở Ấn Độ, khi có nhiều đầu vào đồng thời cạnh tranh cho cùng năng lực đó
    Đây cũng có thể là một cách giải thích khác cho cảm giác chất lượng giảm dần theo thời gian. Trước đây một bài kiểm tra cụ thể có thể vượt qua ổn định vì ít tắc nghẽn ở chuyên gia liên quan, còn giờ lượng dùng đồng thời tăng lên khiến cùng bài kiểm tra đó không nhận được đủ nỗ lực từ chuyên gia ấy
    Cũng có thể xuất hiện vũng lầy: nếu một chuyên gia con ban đầu làm rất ấn tượng trong một lĩnh vực nhất định, lượng sử dụng trong lĩnh vực đó sẽ đổ về nhiều hơn; sự tắc nghẽn mới khiến các lượt dùng bắt chước không còn nhận được cùng phân bổ chuyên gia nữa, làm hiệu năng ấn tượng ban đầu suy giảm
    Nếu hiệu ứng này mạnh và OpenAI biết nhưng không công khai, có thể xem đó như một dạng sản phẩm mồi: ban đầu thu hút người dùng bằng sự xuất sắc không đại diện của một hệ thống Mixture-of-Experts chưa bị tắc nghẽn, rồi cung cấp kết quả chất lượng thấp hơn từ một hệ thống đông đúc hơn

    • Kết quả dường như về bản chất là 12 phản hồi duy nhất trong 30 lần thử, không phải điều người ta kỳ vọng nếu token bị trộn
      Có lẽ họ đang gom batch theo cách khác nhau. Khi chia 10 batch thành 2 nhóm mỗi nhóm 5, câu trả lời sẽ khác tùy prompt của tôi nằm trong nhóm đầu hay nhóm thứ hai; nếu ở cùng vị trí trong batch thì sẽ nhận cùng câu trả lời
      Với cùng một batch, tức cùng chuỗi và thứ tự, toàn bộ batch là quyết định; nhưng nếu trộn batch thì tính quyết định đó mất đi
    • Đây là một kết quả hợp lý, và nếu đúng thì các mô hình của OpenAI có thể bị ảnh hưởng nặng so với mô hình cạnh tranh hoặc mô hình nguồn mở
      Ngay cả hiện nay, độ tin cậy vẫn là một trong những rào cản cốt lõi ngăn LLM được áp dụng rộng rãi trong nhiều luồng công việc trọng yếu
      Nếu tin đồn rằng GPT-4 về bản chất là không quyết định và không ổn định là đúng, phần lớn doanh nghiệp nên tinh chỉnh một LLM nguồn mở có hiệu năng tương tự cho miền cụ thể của mình
      Mô hình chuyên biệt theo miền luôn đạt hiệu năng tốt hơn mô hình đa dụng, nên hướng đó cũng đem lại lợi ích hiệu năng lớn hơn

  • Nếu GPT-3.5 là mô hình MoE, chẳng phải đó là tín hiệu khá hy vọng cho phe nguồn mở sao?
    Nếu có một mô hình MoE nguồn mở tốt, có thể dưới dạng biến thể của các mô hình decoder hiện có, thì điều đó có nghĩa là với ít tài nguyên hơn nhiều vẫn làm được nhiều việc hơn nhiều
    Tôi không biết liệu có cần huấn luyện mô hình MoE từ đầu hay không

    • Đồng ý, và thật sự hy vọng Meta đang làm gì đó theo hướng đó
      Cách giảm tỷ lệ FLOPs:bộ nhớ, chẳng hạn Soft MoE, cũng có thể khiến suy luận trên CPU, hoặc ít nhất trên Apple Silicon, trở nên có ý nghĩa hơn
    • Có thể bất lợi cho môi trường suy luận chạy trên một GPU tiêu dùng duy nhất

  • Nếu các chuỗi trong batch có thể ảnh hưởng đến việc định tuyến của nhau, tôi có cảm giác sẽ xuất hiện khả năng tấn công kênh bên kỳ lạ và khó triển khai

    • Có vẻ đúng. Tuy nhiên thực tế có lẽ rất khó khai thác

  • Đây là một công trình thật sự xuất sắc. Tôi đã phản đối mạnh mẽ MoE vì nhiều lý do, nhưng đây là lần đầu tiên thấy bằng chứng thuyết phục chứ không phải bài Substack hay lặp lại tin đồn
    Tôi hoàn toàn không biết GPT-4 là phi quyết định, dù dùng khoảng 2 giờ mỗi ngày
    Giờ thì hiểu vì sao nhìn qua loa lại khó nhận ra. Trong trí nhớ thì “cảm giác” giống nhau và dùng nhiều từ vựng tương tự, nhưng định dạng thì hoàn toàn khác, một số từ khóa cốt lõi giống nhau còn phần diễn đạt thì đổi kiểu như các cụm từ đồng nghĩa

    • Tôi không phải chuyên gia nghiên cứu MoE, nhưng khi đọc những gì viết trong bài báo Soft MoE thì thấy cần kiểm chứng
      Nhìn các ví dụ trong gist được liên kết, đầu ra phi quyết định thật sự rất giống nhau: https://gist.github.com/152334H/047827ad3740627f4d37826c867a...
      Vì tính ngẫu nhiên hẳn phải bị giới hạn, nên riêng điểm này ít nhất cũng không đáng ngạc nhiên
      Tôi nghĩ một ngày nào đó OpenAI sẽ tìm ra cách giảm tính ngẫu nhiên này. Việc họ đã công khai hứa sẽ thêm lại logprobs vào ChatCompletions càng khiến điều đó có vẻ hợp lý hơn
    • Nếu dùng GPT-4 web chat hai giờ mỗi ngày thì có thể như vậy
      Còn nếu phát triển chương trình theo kiểu gọi API lặp đi lặp lại với cùng một đầu vào thì khó mà bỏ lỡ tính phi quyết định
    • Tôi tò mò vì sao bạn lại phản đối mạnh mẽ MoE
    • Tôi cũng tò mò bạn dùng nó vào việc gì. Và có dùng nhiều plugin không
      Tôi quan tâm một người dùng nhiều như vậy sẽ rút ra được insight gì, kể cả với nhóm tính năng mới ra tuần này

  • MoE là Mixture of Experts, tức hỗn hợp các chuyên gia

    • Cảm ơn. Tôi cứ tưởng là Margin of Error
      Mãi đến khoảng giữa bài mới gần như tình cờ giải nghĩa chữ viết tắt này; độc giả mà bài nhắm tới có vẻ là người biết “hỗn hợp các chuyên gia”, còn tôi thì không nằm trong số đó

  • Các mô hình davinci-instruct-beta của GPT-3.0 đã trả về logprobs phi quyết định từ đầu năm 2021 rồi
    Đây chỉ là suy đoán, và bản thân CUDA cũng thường có lỗi phi quyết định
    text-davinci-001 và text-davinci-002 được huấn luyện bằng FeedMe và SFT, còn text-davinci-003 là RLHF
    Bản thân mô hình cũng có độ phân tán lớn hơn ở nhiệt độ cao

    • Vậy các mô hình nền, tức davinci và code-davinci-002, thì sao?

  • Nếu “các token này thường cạnh tranh với nhau để giành các vị trí còn trống trong buffer của chuyên gia”, thì đó có phải cũng là lý do khi tôi yêu cầu code dài, ChatGPT hay chỉ nhét placeholder vào chỗ hàm không?

  • “Các token này thường cạnh tranh với nhau để giành các vị trí còn trống trong buffer của chuyên gia” — vậy nghĩa là khi tải cao thì kết quả sẽ khác đi sao?
    Cảm giác đôi khi chất lượng đầu ra thay đổi cũng có thể được giải thích bằng tải cao à?

  • MoE là viết tắt của Mixture of Experts