HN công khai: Kết nối GPU ảo qua TCP

 (thundercompute.com)
2 điểm bởi GN⁺ 2024-08-10 | 1 bình luận | Chia sẻ qua WhatsApp
  • Không giống CPU, lưu trữ, mạng và bộ nhớ, GPU vẫn chưa được ảo hóa thành nguồn tài nguyên dồi dào; Thunder Compute muốn giải quyết điều này ở tầng hệ thống
  • Trọng tâm của việc mở rộng nguồn cung không chỉ là sản xuất thêm chip, mà còn là khai thác bằng phần mềm để sử dụng tốt hơn các GPU đã được triển khai
  • Trong khi các tối ưu hóa hiện có chủ yếu dừng ở tầng workload như batching suy luận hay xếp hàng tác vụ huấn luyện, thì ảo hóa GPU lại nhắm đến một lĩnh vực hệ thống tương đối ít được chú ý hơn
  • Có thể dùng NVIDIA H100 với giá từ $1.38/giờ trong VS Code, CLI và trình duyệt; nhấn mạnh tiết kiệm 80% so với AWS, không hợp đồng, không phí egress và có lưu trữ mở rộng
  • Sau 4 năm hoạt động stealth để xây dựng nguyên mẫu nghiên cứu, công ty muốn triển khai cải thiện dung lượng GPU cho trung tâm dữ liệu thông qua cloud riêng và các đối tác doanh nghiệp

Cải thiện mức sử dụng thấp bằng ảo hóa GPU

  • Thunder Compute cho rằng nhiều tài nguyên khan hiếm trong điện toán cuối cùng đã trở nên dồi dào, nhưng GPU vẫn chưa trải qua sự chuyển đổi tương tự
  • Cách làm cho GPU trở nên dồi dào không chỉ là sản xuất thêm chip, mà còn phụ thuộc vào phần mềm giúp tận dụng tốt hơn các chip đã được triển khai
  • Hiện nay GPU thường chưa được sử dụng đủ hiệu quả, và các giải pháp hiện có chủ yếu tập trung vào tầng workload
    • Batch xử lý các yêu cầu suy luận
    • Xếp hàng các tác vụ huấn luyện trên nhiều cụm máy chủ
  • CPU, lưu trữ, mạng và bộ nhớ đã được ảo hóa rộng rãi, nhưng GPU vẫn chưa đạt đến mức độ ảo hóa tương tự
  • Trọng tâm trong cách tiếp cận của Thunder Compute là xử lý khoảng trống này ở tầng hệ thống

Cách tiếp cận sản phẩm và kế hoạch triển khai

  • Thunder Compute là một system lab với trọng tâm thương mại, muốn đưa các nghiên cứu ảo hóa GPU mới nhất vào môi trường production
  • Nhóm cho biết họ gồm các chuyên gia hạ tầng và nhà nghiên cứu hệ thống từng làm tại Citadel Securities, Aquatic và AWS
  • Trong 4 năm hoạt động stealth, họ đã xây dựng nguyên mẫu nghiên cứu, và hiện đang triển khai thành quả qua cloud riêng cùng các đối tác doanh nghiệp
  • Theo mô tả sản phẩm, NVIDIA H100 có thể được sử dụng với giá từ $1.38/giờ
    • Có thể truy cập từ VS Code, CLI và trình duyệt
    • Nêu mức tiết kiệm 80% so với AWS
    • Không hợp đồng, không phí egress và cung cấp lưu trữ mở rộng
  • Mục tiêu là từng bước cải thiện dung lượng GPU của trung tâm dữ liệu

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-08-10
Ý kiến trên Hacker News

  • Khá thú vị. Trước đây tôi từng cần GPU-over-IP chỉ để chuyển mã video
    Máy chủ homelab của tôi có một GPU AMD yếu, cứ mỗi lần thử mã hóa video là lại làm kernel crash, còn PC chơi game thì có NVIDIA RTX 3080. Vì vậy tôi đã tạo https://github.com/steelbrain/ffmpeg-over-ip, chạy server trên máy Windows và client trên media server (Plex, Emby, Jellyfin, v.v.), và nó hoạt động hoàn hảo

    • Nếu bạn chưa từng đăng lên Show HN thì nên cân nhắc thử
      https://gist.github.com/tzmartin/88abb7ef63e41e27c2ec9a5ce5d...
      https://news.ycombinator.com/showhn.html
      https://news.ycombinator.com/item?id=22336638
    • Khi nhìn tiêu đề, tôi đã kỳ vọng đại khái một thứ như thế này. Hơi tiếc là bài được gửi thực tế lại là một dịch vụ đám mây trả phí chứ không phải một công cụ đa dụng hữu ích; đúng là nội dung thật sự lại nằm trong phần bình luận
      Tôi cũng tò mò ngoài mã hóa video thì còn chỗ nào đáng dùng GPU-over-network không. Nếu độ trễ tăng lên thì học máy hay các tác vụ nặng về đồ họa có lẽ sẽ khó
    • Thú vị đấy. Tôi tò mò liệu nó có hỗ trợ chuyển đổi nhiều tệp tạo ra nhiều file timeslice như HLS không

  • Tôi hơi bối rối: nếu thứ này hoạt động ở ranh giới CPU/GPU, chẳng phải với các dataset không nằm vừa trong VRAM sẽ phát sinh nút thắt cổ chai I/O cực lớn sao
    Có thể tôi hiểu sai cách nó hoạt động, nhưng nếu nó chặn I/O của GPU thì mỗi epoch sẽ phải stream toàn bộ dataset sang máy từ xa, nghe có vẻ lãng phí

    • Bạn hiểu hệ thống như vậy là đúng. Để làm cho nó thực tế hơn, chúng tôi đã triển khai nhiều tối ưu nhằm giảm chi phí I/O
      Hiệu năng suy luận BERT có thể xem ở đây: https://youtu.be/qsOBFQZtsFM?t=69
      Huấn luyện có overhead lớn hơn suy luận, và chúng tôi đang triển khai thêm các tối ưu để tiệm cận hiệu năng native

  • Với những ai tò mò thực tế nó hoạt động ra sao, có vẻ cấu trúc là inject một thư viện vào process, hook các hàm này[1], rồi chuyển tiếp sang service
    [1] https://pastebin.com/raw/kCYmXr5A

    • Tôi tò mò làm sao bạn biết được các hàm này đã bị hook. Tôi đoán có một cờ ld/ldd nào đó cho biết symbol nào được bind lại
      Ngoài ra tôi từng nghĩ symbol muốn được bind lại thì phải là weak symbol, mà NVIDIA hẳn sẽ không expose weak symbol, nên rốt cuộc có phải điều này về cơ bản là kiểu LD_PRELOAD không
    • Tôi đã hy vọng có một cách ma thuật nào đó để truyền nguyên cả thiết bị PCIe qua

  • Thú vị, nhưng thứ tôi quan tâm hơn là self-hosting. Tôi đã có khá nhiều GPU, một số đang chạy, một số đang nhàn rỗi
    Tôi tò mò có tùy chọn self-hosting để dùng các GPU sẵn có của mình không

    • Hiện chưa hỗ trợ self-hosting, nhưng có vẻ cùng công nghệ này rất phù hợp
      Các lợi ích như lập lịch tác vụ hiệu quả, chia sẻ GPU và dễ sử dụng cũng áp dụng nguyên vẹn cho môi trường self-hosting. Chúng tôi hoàn toàn để ngỏ khả năng này trong tương lai
    • Nếu bạn muốn dùng GPU của chính mình, dù là máy cố định hay cloud, với trải nghiệm sử dụng giống PyTorch, hãy xem https://github.com/run-house/runhouse
    • Nếu bạn dùng GPU riêng hoặc tài khoản cloud mà vẫn muốn trải nghiệm phát triển tốt thì hãy xem SkyPilot
    • Bạn có thể cho thuê GPU của mình trên cloud qua các dịch vụ như Akash Network, và cũng có thể thuê GPU trên thundercompute.com. Nó gần giống một luồng dành cho quản trị viên vận hành kiểu self-hosting

  • Tôi không hiểu lắm. Bạn có thể tự chạy instance GPU mong muốn trên ECS, vậy tại sao lại phải chạy instance trên ECS rồi dùng GPU của các bạn từ ECS
    Riêng chuyện khác, tôi cũng không hiểu vì sao ai đó muốn dùng Nitro nửa vời thay vì Nitro thật

    • Điểm hay đấy. Có vài lợi ích
      Nếu bạn đang phát triển thứ gì đó cần GPU, thường bạn phải trả tiền cho toàn bộ thời gian instance bật. Với Thunder, bạn chỉ trả tiền cho thời gian thật sự dùng GPU. Khi chỉ chạy code CPU thì không phát sinh chi phí thời gian GPU. Phương án thay thế là bật/tắt instance thủ công, việc này có thể phiền
      Ngoài ra bạn có thể dễ dàng mở rộng loại và số lượng GPU đang dùng. Ví dụ, nếu đang phát triển trên một instance T4 rẻ tiền rồi muốn chạy toàn bộ job huấn luyện deep learning trên 8 A100, bạn không cần đổi instance và thiết lập lại môi trường; chỉ cần chạy một lệnh rồi chạy ngay trên GPU mạnh hơn
    • Nhìn từ phía hệ thống thì nó có vẻ minh bạch hơn. Ví dụ, nếu dùng ứng dụng GUI cần tăng tốc GPU (Matlab, SolidWorks, Blender) trên thin client, bạn có thể làm vậy mà không cần cấu hình ECS
      Bạn có thể phát triển không cần GPU, rồi khi chạy mô phỏng thì đột ngột gắn GPU vào, và có vẻ sẽ rẻ hơn AWS nhiều. Về bản chất, nó trông như giải quyết bài toán mà Ray(https://www.ray.io/) đang giải, nhưng theo cách tổng quát hơn. Nó cũng có thể cho phép chia sẻ GPU hạt mịn hơn như nửa GPU, nên rất đáng kỳ vọng

  • Vì có nhiều người quan tâm nên chúng tôi quyết định mở miễn phí instance T4. Hãy tự dùng thử và cho chúng tôi biết suy nghĩ của bạn

    • Tôi tò mò giá A100 và H100 sẽ thế nào

  • Hay đấy. Tôi tò mò liệu có thể làm cho nó hoạt động với MIG hoặc vGPU không

    • Chúng tôi chưa thử với MIG hay vGPU, nhưng vì về bản chất đó là cách phân vùng GPU về mặt vật lý nên có vẻ sẽ hoạt động
      Một trong những mục tiêu chính trong tương lai gần là cho phép chia sẻ GPU. Vì chúng tôi sẽ cho phép người dùng dùng toàn bộ bộ nhớ GPU thay vì giới hạn họ trong một phần bộ nhớ, nên nó có thể tốt hơn MIG hoặc vGPU

  • Tôi tò mò khi dùng thực tế với throughput đáng kể thì cảm giác sẽ ra sao. Có dùng cho bẻ khóa hash được không?
    Mỗi khi nghĩ tới GPU ảo qua mạng, tôi lại liên tưởng đến botnet. Đặc biệt là đoạn trong https://www.hpcwire.com/2012/12/06/gpu_monster_shreds_passwo... nói rằng “Gosney trước hết phải thuyết phục giáo sư Amnon Barak, đồng sáng lập Mosix, rằng ông ấy ‘không cố biến cả thế giới thành một botnet khổng lồ’”

    • Đây là một thí nghiệm tư duy thú vị, nhưng thực tế hệ thống của chúng tôi không có GPU phân tán, nên nó gần với AWS hơn là botnet
      Công nghệ này có những ứng dụng thú vị trong việc tạo các cụm rất linh hoạt bên trong trung tâm dữ liệu, và chúng tôi đang khám phá phần đó

  • Các kỹ sư SGI ban đầu phát triển glx đã thiết kế rất cẩn thận để dùng cơ chế X11 cho việc truyền GPU, nên việc gửi GL stream qua mạng và render trên card đồ họa của tôi khá đơn giản
    Kiểu như “chạy trên siêu máy tính cuối hành lang, render trên workstation”. Việc phát triển driver gần đây có vẻ không còn quan tâm đến điều đó, nên thường không còn làm được nữa. Tôi không rõ thực tế nó hữu ích đến mức nào. Thường nếu có card đồ họa tốt thì CPU cũng tốt. Dù vậy, đem ra nghịch thì khá vui, và có điều gì đó hấp dẫn kỳ lạ khi một chương trình chạy trong phòng máy lại có được đồ họa tăng tốc. Có lần tôi đã chạy được glquake theo cách này

  • Việc điều này có thể làm được đã đủ ấn tượng, nhưng tôi tò mò chuyện gì sẽ xảy ra khi kết nối mạng bị ngắt hoặc không ổn định 100%
    Theo kinh nghiệm, driver thường phản ứng không tốt ngay cả khi GPU cục bộ chỉ hoạt động hơi bất thường