Máy chủ render là gì? (Và khi nào bạn cần render farm thay vào đó)

Giới thiệu

Nếu bạn từng tìm "render server" (máy chủ render), có lẽ bạn đã nhận ra kết quả tìm kiếm chỉ về ba hướng khác nhau cùng lúc. Một số trang nói về một máy tính vật lý đặt dưới bàn làm việc, chuyên dùng để render. Một số nói về một hộp máy gắn rack trong trung tâm dữ liệu mà bạn thuê theo tháng. Và một số nói về cả một nền tảng cloud rendering với hàng trăm máy đứng sau. Cả ba đều được gọi là "render server" bởi ai đó, và phần giao nhau chính là nơi sự nhầm lẫn xảy ra.

Sự phân biệt này quan trọng vì nó thay đổi thứ bạn thực sự mua và khả năng mở rộng. Một máy chủ đơn lẻ render một ảnh tĩnh trước deadline là một khoản mua sắm rất khác so với một cụm máy xử lý một animation 3.000 khung hình qua đêm — dù cả hai đều được mô tả bằng cùng hai từ. Bài viết này sẽ vạch rõ ranh giới: render server thực sự là gì ở mức nghĩa đen, nó khác render farm như thế nào, khi nào một máy là thực sự đủ, và những ngưỡng cụ thể, trung thực khi một máy chủ đơn lẻ không còn theo kịp và bạn cần nâng cấp. Chúng tôi đã vận hành hạ tầng render phân tán nhiều năm, và điểm mà "một máy mạnh" âm thầm trở thành "không đủ" dễ đoán hơn nhiều người nghĩ — vì vậy chúng tôi sẽ nói cụ thể ranh giới đó nằm ở đâu.

Câu trả lời ngắn gọn: Server vs. Farm vs. Service

Ba thuật ngữ này thường bị lẫn vào nhau, nên cần tách rõ trước khi đi sâu hơn:

• Render server (máy chủ render) là một máy tính duy nhất chuyên dùng để render. Một máy tính — CPU, GPU, hoặc cả hai — có nhiệm vụ xử lý các tác vụ render thay vì làm workstation hàng ngày của ai đó. Nó có thể là một tháp máy headless trong góc studio, một node rack trong một cơ sở colocation, hoặc một hộp máy chuyên dụng bạn thuê từ nhà cung cấp.
• Render farm là nhiều render server cộng với một bộ lập lịch công việc (job scheduler). Bộ lập lịch (render manager) chia công việc ra giữa các máy — phân phối khung hình, tile, hoặc tác vụ — rồi ghép lại kết quả đầu ra. Đặc điểm định nghĩa của một farm không phải là số lượng máy; mà là lớp điều phối khiến chúng hoạt động như một pool duy nhất.
• Render service là lớp kinh doanh — một công ty bán cho bạn quyền truy cập vào một server hoặc một farm, kèm theo một tổ hợp phần mềm, cấp phép, và hỗ trợ. Chúng tôi trình bày sâu hơn về sự khác biệt này trong bài viết đồng hành về sự khác biệt giữa render service và render farm; ở đây trọng tâm vẫn là câu hỏi về phần cứng — một server so với nhiều server.

Vậy tiến trình rất đơn giản: một máy là một render server; một nhóm máy được điều phối là một render farm; và ai bán quyền truy cập vào một trong hai thứ đó đang vận hành một render service. Phần lớn sự nhầm lẫn trong thực tế đến từ việc các nhà cung cấp dùng "render server" để chỉ bất kỳ cái nào trong ba thứ trên, nên xuyên suốt bài viết này, chúng tôi sẽ giữ "server" nghiêm ngặt theo nghĩa một-máy-duy-nhất.

Sơ đồ so sánh một render server đơn lẻ, một render farm gồm nhiều server được điều phối, và lớp kinh doanh render service

Render server thực sự là gì

Bóc render server (hệ thống máy tính kết xuất) xuống bản chất, đó là một máy tính có ba đặc điểm: nó chuyên render thay vì làm việc tương tác, nó thường chạy "headless" (không màn hình, điều khiển từ xa), và nó được thiết kế để chịu tải đầy đủ trong nhiều giờ hoặc nhiều ngày mà không cần dùng cho việc khác.

Trong thực tế, một render server tồn tại dưới một vài dạng:

• Một máy trạm headless. Một studio lấy một tháp máy dư — thường là một workstation chính cũ — gỡ xuống chỉ còn OS và render engine, rồi dành riêng cho việc render qua đêm hoặc chạy nền. Không có phiên GUI đang dùng; công việc được gửi từ xa và máy cứ thế chạy.
• Một node gắn rack. Một khung máy chủ chuyên dụng (1U/2U/4U) với CPU hoặc GPU cấp máy chủ, đặt trong rack tại phòng máy của studio hoặc một cơ sở colocation. Được thiết kế cho mật độ, làm mát, và hoạt động 24/7 thay vì đặt trên bàn.
• Một dedicated server đi thuê. Nhà cung cấp cho bạn quyền sử dụng độc quyền một máy vật lý — bạn không chia sẻ CPU hay GPU của nó với ai khác — tính phí theo tháng hoặc theo giờ. Bạn thường tự quản trị nó: cài render engine, quản lý license, gửi job.

Điểm chung xuyên suốt cả ba là tính đơn nhất. Một render server là một đơn vị throughput. Nó xử lý một khung hình (hoặc một bucket) tại một thời điểm cho mỗi thread hoặc GPU khả dụng, và giới hạn của nó cố định theo chính con chip của nó. Bản chất đơn-đơn-vị đó chính xác là thứ định nghĩa cả điểm mạnh — đơn giản, dễ dự đoán, kiểm soát hoàn toàn — lẫn giới hạn cứng, mà chúng ta sẽ nói đến.

Một lưu ý nhanh về việc render server không phải là gì: nó không tự động "trên cloud", và nó không tự động là một farm. Một hộp GPU dedicated bạn thuê theo tháng là một render server (một máy), không phải một farm — sự khác biệt nằm ở bộ lập lịch và số lượng máy. Nếu bạn muốn hiểu toàn bộ bức tranh khi nhiều server được điều phối cùng nhau, hướng dẫn đầy đủ về render farm của chúng tôi trình bày chi tiết về kiến trúc đó.

Thực tế của render server tự vận hành (in-house)

Tự vận hành render server của riêng bạn — dù là một workstation tái sử dụng hay một node rack đã mua — nghe rất hấp dẫn trên giấy: mua phần cứng một lần, render miễn phí mãi mãi. Thực tế có nhiều chi tiết hơn, và cần thành thật về những phần không xuất hiện trong giá mua.

Máy bạn không thể dùng khi nó đang render. Đây là chi phí bị đánh giá thấp nhất của một setup một-server. Nếu render server của bạn cũng là workstation của bạn, thì mỗi giờ nó render là một giờ bạn không thể modeling, texturing, hay comping. Các artist giải quyết việc này bằng cách dành riêng một máy thứ hai cho việc render — đây chính là lúc "một máy tính" âm thầm trở thành "hai máy tính", và giấc mơ render miễn phí bắt đầu có thêm một khoản ngân sách phần cứng.

Điện năng và nhiệt. Một render server chạy hết công suất tiêu thụ điện năng đáng kể — một hộp CPU nhiều nhân hoặc một máy nhiều GPU có thể kéo vài trăm watt liên tục, trong nhiều giờ. Đó là một khoản tiền điện thực sự, và đó là nhiệt phải được thoát đi đâu đó. Một hộp máy trong văn phòng tại nhà sẽ làm ấm phòng rõ rệt; vài máy cần hệ thống thông gió thực sự. Tải nhiệt kéo dài cũng ảnh hưởng đến tuổi thọ phần cứng — linh kiện tiêu dùng chạy 100% trong nhiều ngày hoạt động khác với khi dùng tương tác ngắt quãng.

Cấp phép (licensing). Điều khoản license của render engine quyết định liệu bạn có được phép hợp pháp chạy nó headless trên một hộp dedicated hay không, và bạn được phép chạy bao nhiêu instance đồng thời. Các engine thương mại như V-Ray, Corona, Redshift, Arnold, và Octane đều có quy tắc cấp phép render-node riêng; một số đi kèm một số lượng render node với license workstation, số khác yêu cầu license node riêng. Điều này dễ bị bỏ qua khi bạn chỉ "thêm một máy nữa", và đó là một ràng buộc thực sự đối với việc một setup server DIY có thể mở rộng đến đâu. (Cycles, render engine tích hợp sẵn của Blender, là mã nguồn mở và không có cấp phép theo node — một lý do nó xuất hiện thường xuyên trong các setup render server DIY.)

Bảo trì giờ là việc của bạn. Cập nhật driver, vá OS, một ổ đĩa hỏng, một render bị treo lúc 2 giờ sáng — trên server của riêng bạn, tất cả đều là trách nhiệm của team bạn. Điều này vẫn quản lý được với một hộp máy. Nhưng mở rộng quy mô thì rất tệ.

Minh họa render server tự vận hành cho thấy các chi phí ẩn — điện năng tiêu thụ, nhiệt tỏa ra, ràng buộc license, và gánh nặng bảo trì

Không điều nào trong số này khiến render server tự vận hành trở thành ý tưởng tồi. Với đúng loại workload, đó là một lựa chọn hoàn toàn hợp lý — vấn đề chỉ là "mua một máy và render miễn phí" đã đánh giá thấp chi phí thực tế, liên tục. Điểm mà bài toán này thay đổi được trình bày kỹ trong bảng phân tích tổng chi phí tự xây dựng vs. cloud của chúng tôi, đưa ra con số cụ thể cho điểm giao nhau đó.

Thuê dedicated render server vs. cloud farm tính theo job

Nếu bạn không muốn sở hữu phần cứng, có hai cách rất khác nhau để thuê — và nhầm lẫn giữa chúng là một trong những sai lầm tốn kém hơn trong lĩnh vực này.

Thuê một dedicated render server nghĩa là bạn có quyền sử dụng độc quyền một máy vật lý, thường theo tháng. Nó là của bạn trong suốt thời gian thuê: bạn cài gì tùy ý, nó luôn sẵn sàng, và bạn không chia sẻ compute của nó. Điều này phù hợp với workload ổn định, có thể dự đoán — một artist hoặc studio nhỏ render hầu hết các ngày và muốn một chi phí hàng tháng cố định, đã biết trước. Điểm bất lợi là bạn trả tiền cho nó dù nó đang render hay đang rảnh. Một hộp dedicated bạn dùng bốn giờ một ngày vẫn bị tính phí cho hai mươi giờ còn lại. Nó cũng vẫn là một máy — thuê không loại bỏ giới hạn throughput của một-server, nó chỉ chuyển phần cứng ra khỏi bàn của bạn. Với các team muốn cụ thể một hộp GPU dedicated, hướng dẫn dedicated RTX 5090 render server của chúng tôi trình bày phần cứng đó thực sự mang lại gì.

Một cloud render farm tính theo job đảo ngược mô hình. Thay vì một máy luôn bật, bạn gửi một job và nó được phân tán song song trên nhiều máy, bạn chỉ trả cho compute mà job thực sự tiêu thụ, và khi job xong, đồng hồ tính phí dừng lại. Một cloud render farm về bản chất là một farm — nhiều server cộng với một bộ lập lịch — được bán theo mức tiêu thụ. Lợi thế là tính co giãn: một chuỗi 500 khung hình mà một server phải mất cả đêm có thể hoàn thành trong một phần nhỏ thời gian đó khi 50 máy mỗi máy nhận 10 khung hình, và bạn chỉ bị tính phí cho tổng compute, không phải cho công suất nhàn rỗi.

Sự đánh đổi trung thực giữa hai lựa chọn nằm ở mô hình sử dụng của bạn, chứ không phải mức giá theo giờ:

Quy tắc chung: nếu việc render của bạn liên tục và có thể dự đoán, một dedicated server có thể tiết kiệm chi phí vì bạn giữ nó luôn bận. Nếu nó bùng nổ — vài tuần yên ắng rồi đến deadline gấp rút — một farm tính theo job hầu như luôn thắng, vì bạn không phải trả tiền cho máy nằm không giữa các đợt gấp rút. Để hiểu sâu hơn sự đánh đổi giữa managed và tự làm (DIY) bên dưới cả hai lựa chọn này, xem so sánh fully managed vs. DIY render farm của chúng tôi.

Dùng render server vs. farm cho Blender

Blender đáng được nói riêng, vì câu hỏi "render server" xuất hiện liên tục trong workflow Blender và câu trả lời phụ thuộc nhiều vào việc bạn dùng engine nào trong hai engine của Blender.

Cycles là path tracer dựa trên vật lý của Blender. Nó tốn nhiều compute và mở rộng rất tốt trên nhiều máy — mỗi khung hình độc lập, nên một farm có thể render khung 1 trên một máy và khung 240 trên máy khác mà không cần điều phối gì thêm. Cycles chạy trên cả CPU và GPU. Trên một render server đơn lẻ, một animation Cycles nặng đúng là loại job chiếm máy trong nhiều giờ; đó cũng đúng là loại job mà một farm biến từ một đêm render thành một khoảng thời gian uống cà phê, vì các khung hình song song hóa rất gọn gàng. Cycles là mã nguồn mở (không có license theo node) cũng khiến nó là engine dễ mở rộng nhất — dù là ra máy thứ hai của riêng bạn hay ra một cloud farm.

EEVEE là engine rasterization thời gian thực của Blender, và nó được tăng tốc bằng GPU. Vì EEVEE nhanh trên mỗi khung hình, render một máy thường hoàn toàn đủ cho ảnh tĩnh và các chuỗi ngắn — một render server có thể là tất cả những gì bạn cần. EEVEE hưởng lợi từ một farm khi số khung hình lớn (animation dài) hoặc các pass nặng trên mỗi khung hình mà ngay cả khi "nhanh" vẫn cộng dồn qua hàng ngàn khung hình. EEVEE được hỗ trợ trên farm của chúng tôi — nó chạy trên các máy GPU dedicated của chúng tôi (NVIDIA RTX 5090, 32 GB VRAM), nên một animation EEVEE có thể được phân tán trên các node GPU thay vì chiếm dụng một card local duy nhất của bạn. Điều này đáng nói rõ vì có một quan niệm sai phổ biến rằng render farm "chỉ dành cho Cycles" — điều đó không đúng ở đây.

Vậy quyết định cho Blender không thực sự là "server hay farm" một cách trừu tượng — mà là một hàm của engine và số khung hình. Một ảnh tĩnh, hay một loop EEVEE ngắn? Một render server (của bạn hoặc đi thuê) thường là đủ. Một animation Cycles dài chạy deadline, hay một chuỗi EEVEE nặng với hàng ngàn khung hình? Đó là lúc tính song song của một farm phát huy giá trị, và là lúc một máy — dù mạnh đến đâu — trở thành nút thắt cổ chai.

Khi nào một render server là đủ

Một render server đơn lẻ thực sự là công cụ đúng cho một tập hợp công việc thực tế. Bạn không cần một farm chỉ vì farm tồn tại. Một server hoạt động tốt khi:

• Bạn là một artist đơn lẻ hoặc một team rất nhỏ. Một người chỉ có thể tạo ra ngần ấy công việc để render cùng lúc. Nếu bạn không tạo job render nhanh hơn tốc độ một máy mạnh có thể xử lý xong, công suất của một farm sẽ nằm không.
• Bạn đang render ảnh tĩnh hoặc chuỗi ngắn. Một vài ảnh tĩnh chất lượng cao, hoặc một clip 5–10 giây, nằm hoàn toàn trong tầm với của một máy qua đêm. Tính song song của một farm không giúp ích nhiều khi chỉ có vài khung hình để phân tán.
• Deadline của bạn có độ trễ. Nếu "trước tuần sau" là mốc và job xong qua đêm trên một hộp máy, một server là đủ. Farm mua tốc độ; nếu bạn không cần tốc độ, bạn không cần farm.
• License hoặc pipeline của bạn bị giới hạn vào một máy. Một số plugin hoặc setup license thực sự đơn giản hơn khi giữ trên một môi trường đơn, được kiểm soát. Một môi trường nhiều máy được quản lý không phải lúc nào cũng phù hợp với một stack khác thường.
• Workload của bạn ổn định và có thể dự đoán. Như đã nói ở trên, render gần như hàng ngày giữ một dedicated server đủ bận để xứng đáng với chi phí cố định của nó.

Phiên bản trung thực của phần này: hầu hết các artist solo và nhiều studio nhỏ chưa bao giờ thực sự vượt quá một render server được cấu hình tốt. Bước chuyển sang farm được thúc đẩy bởi các áp lực cụ thể, có thể đo lường — không phải bởi cảm giác mơ hồ rằng "studio thật thì dùng farm".

Ngưỡng thực tế: Khi nào bạn đã vượt quá một server

Đây là điểm mà một render server đơn lẻ không còn đủ. Đây là những áp lực cụ thể — không phải các mốc marketing, mà là giới hạn thực sự:

Số khung hình và bài toán deadline. Đây là điểm rõ ràng nhất, và nó là phép tính số học. Lấy thời gian render mỗi khung hình, nhân với số khung hình, rồi so với thời gian bạn có. Một animation 1.000 khung hình ở 6 phút mỗi khung là 100 giờ render trên một máy — hơn bốn ngày compute liên tục. Nếu deadline của bạn còn ba ngày, một server về mặt toán học không thể hoàn thành, dù nó mạnh đến đâu. Một farm chia 100 giờ đó ra nhiều máy; 50 máy biến bốn ngày thành khoảng hai giờ đồng hồ thực tế. Khi số khung hình nhân thời gian mỗi khung vượt quá khung thời gian bạn có, bạn đã chạm giới hạn.

Giới hạn VRAM (hoặc RAM). Một render server chỉ có thể tải một scene vừa với bộ nhớ của nó. Nếu scene của bạn cần nhiều VRAM hơn một GPU đơn có — hình học nặng, texture 4K/8K, volumetric dày đặc — render sẽ thất bại, rơi về bộ nhớ out-of-core chậm hơn, hoặc buộc bạn phải cắt giảm scene. Đây là một bức tường cứng, không phải vấn đề tốc độ: một scene lớn hơn không render chậm hơn trên một máy thiếu công suất, nó không render được chút nào. Truy cập vào các máy có nhiều dư địa hơn (hoặc khả năng phân tán) đôi khi là cách khắc phục duy nhất. Bài viết của chúng tôi về giới hạn VRAM RTX 5090 trong các scene phức tạp đi sâu chính xác vào nơi bức tường đó nằm ở đâu.

Nhu cầu throughput liên tục. Khi team của bạn tạo job render nhanh hơn tốc độ một máy có thể xử lý xong — nhiều artist gửi job qua đêm, các chu kỳ look-dev lặp lại, các bản sửa chồng chất — một server đơn lẻ trở thành một hàng đợi mà mọi người phải chờ. Nút thắt không còn là một job cụ thể nào mà trở thành sự tranh chấp cho một tài nguyên duy nhất.

Sự lệch pha giữa nhàn rỗi và bùng nổ. Nếu bạn sở hữu hoặc thuê một server có kích thước theo workload đỉnh điểm, nó sẽ nằm không phần lớn thời gian giữa các đỉnh — bạn đã trả tiền cho công suất mà bạn hiếm khi dùng. Nếu bạn định cỡ theo mức trung bình, nó không thể xử lý các đợt gấp rút. Một máy cố định không thể vừa là cả hai. Đó chính xác là sự lệch pha mà một farm tính theo job giải quyết được: công suất bùng nổ theo nhu cầu, không tốn chi phí nhàn rỗi.

Hãy để ý điểm chung của các ngưỡng này: chúng đều có thể đo lường. Bạn có thể tính toán bài toán số khung hình, kiểm tra dung lượng bộ nhớ của scene so với VRAM của card, và đếm số job đang xếp hàng chờ nhau. Quyết định chuyển từ một server sang một farm nên đến từ những con số đó, không phải từ cảm giác rằng bạn "nên" mở rộng quy mô.

Một khung quyết định đơn giản (kèm phép tính theo khung hình)

Gộp tất cả lại thành một checklist ngắn. Bắt đầu với một render server, và chuyển lên farm khi các con số nói vậy.

1. Tính toán số khung hình trước tiên. thời gian mỗi khung hình × số khung hình = tổng giờ render. So sánh con số đó với khung thời gian deadline của bạn. Nếu tổng số giờ nằm gọn trong một máy trong deadline, một server là đủ. Nếu không, bạn cần tính song song.
2. Kiểm tra giới hạn bộ nhớ. Scene nặng nhất của bạn có vừa với VRAM của một GPU (hoặc RAM của một máy) không? Nếu không, đó là một bức tường cứng, không liên quan đến tốc độ.
3. Đánh giá mô hình sử dụng. Render hàng ngày ổn định → một dedicated server (sở hữu hoặc thuê) có thể tiết kiệm chi phí. Tải bùng nổ, chạy deadline → một farm tính theo job tránh trả tiền cho thời gian nhàn rỗi.
4. Đếm hàng đợi. Có thường xuyên hơn một job đang chờ không? Sự tranh chấp là tín hiệu throughput cho thấy một máy không theo kịp.

Để cụ thể hóa phép tính theo khung hình, đây là một ví dụ thực tế dùng mức giá đã công bố của chúng tôi. GPU rendering của chúng tôi được tính phí ở mức 0,003 USD mỗi OctaneBench-giờ (OBh), và một RTX 5090 dedicated (32 GB VRAM) tương đương khoảng 5,2 USD mỗi card-giờ render. Giả sử một animation Cycles hoặc Octane chạy 240 khung hình ở 90 giây mỗi khung hình trên loại card đó:

• Tổng thời gian GPU: 240 khung hình × 90 giây = 21.600 giây = 6 card-giờ.
• Ở mức ~5,2 USD/card-giờ, đó là khoảng 31 USD compute GPU cho toàn bộ chuỗi.
• Trên một server, 6 giờ đó chạy nối tiếp nhau: animation của bạn xong trong khoảng 6 giờ đồng hồ thực tế.
• Trên một farm phân tán 240 khung hình đó qua, chẳng hạn, 12 máy GPU, cùng khoảng 31 USD compute đó hoàn thành trong khoảng 30 phút đồng hồ thực tế — bạn trả cho cùng một tổng công việc, nhưng nhận kết quả nhanh hơn 12 lần.

Đó chính là bản chất của sự đánh đổi server-vs-farm trong một ví dụ: một farm hiếm khi thay đổi nhiều tổng chi phí compute — bạn bị tính phí cho công việc dù theo cách nào — thứ nó mua là tốc độ đồng hồ thực tế bằng cách chạy công việc đó song song. Vậy câu hỏi thực sự là "tôi có cần nó nhanh hơn một máy có thể làm không?" Với CPU rendering, cùng logic đó áp dụng với mức giá CPU của chúng tôi là 0,004 USD mỗi GHz-giờ; phép tính khác nhưng nguyên tắc giống hệt. Hướng dẫn chi phí mỗi khung hình của chúng tôi phân tích sâu hơn các ví dụ thực tế này, và nếu bạn đang cân nhắc giữa sở hữu một card riêng và thuê, so sánh chi phí workstation 5090 đơn lẻ vs. cloud rendering trình bày phép tính sở hữu song song nhau.

Sơ đồ quyết định: bắt đầu với một render server, rồi rẽ nhánh sang render farm dựa trên phép tính số khung hình, giới hạn VRAM, mô hình sử dụng, và sự tranh chấp hàng đợi

Bước chuyển lên trông như thế nào

Chuyển từ một render server sang một farm không nhất thiết phải tự xây cluster của riêng bạn. Nhìn chung, có ba cách để tăng throughput sau khi bạn đã vượt quá một máy:

• Tự thêm máy. Mua hoặc thuê một server thứ hai (và thứ ba) và tự chạy render manager của riêng bạn để điều phối chúng. Đây là một farm thật, tự vận hành — kiểm soát hoàn toàn, và giờ chịu trách nhiệm hoàn toàn cho bộ lập lịch, license trên các node, điện năng, và bảo trì mọi hộp máy.
• Thuê một setup dedicated lớn hơn. Một số nhà cung cấp cho thuê nhiều dedicated server; bạn vẫn tự quản trị chúng nhưng bỏ qua việc sở hữu phần cứng. Điều này mở rộng giới hạn throughput nhưng không giải quyết vấn đề chi phí nhàn rỗi hoặc gánh nặng vận hành.
• Dùng một cloud farm tính theo job. Gửi job vào một farm phân tán công việc của bạn qua nhiều máy và tính phí theo mức job tiêu thụ. Trên một dịch vụ quản lý toàn diện, việc cấp phép, tình trạng node, và requeue job khi lỗi được xử lý ở phía nhà cung cấp — workflow chỉ là upload, render, download, không có bước remote-desktop và không cần bạn tự quản trị server. Trên farm của chúng tôi, mô hình managed đó chạy trên hơn 20.000 nhân CPU cùng với các máy GPU dedicated (NVIDIA RTX 5090, 32 GB VRAM), với license cho các engine thương mại đã bao gồm trong mức giá theo giờ thay vì tính riêng.

Lựa chọn nào trong số này phù hợp phụ thuộc vào cùng các biến số từ khung quyết định ở trên — mô hình sử dụng, yêu cầu kiểm soát, và bạn muốn tự chịu bao nhiêu gánh nặng vận hành. Không có một câu trả lời đúng duy nhất; chỉ có câu trả lời phù hợp với các con số của bạn. Nếu bạn đang thuê công suất GPU theo giao dịch thay vì tìm hiểu câu hỏi định nghĩa, một cụm dedicated là một khoản mua sắm hoàn toàn khác — nhưng với hầu hết mọi người, điểm khởi đầu trung thực là một render server đơn lẻ, và chỉ chuyển lên farm khi phép tính số khung hình, giới hạn VRAM, hoặc hàng đợi nói rằng đã đến lúc.

FAQ

Q: Render server là gì? A: Render server là một máy tính duy nhất chuyên xử lý các job render thay vì dùng cho công việc tương tác. Nó có thể là một máy trạm headless, một node gắn rack trong trung tâm dữ liệu, hoặc một hộp máy dedicated bạn thuê từ nhà cung cấp. Đặc điểm định nghĩa là nó chỉ một máy tập trung vào render — điều này phân biệt nó với một render farm, tức nhiều render server được điều phối bởi một bộ lập lịch công việc.

Q: Sự khác biệt giữa render server và render farm là gì? A: Render server là một máy; render farm là nhiều render server cộng với một bộ lập lịch công việc phân phối công việc qua chúng. Bộ lập lịch là khác biệt then chốt — nó chia khung hình hoặc tile qua các máy rồi ghép lại kết quả, nên một farm hoạt động như một pool throughput lớn hơn, duy nhất. Lợi thế của farm là tính song song: công việc chạy nối tiếp trên một server thì chạy đồng thời trên nhiều máy, hoàn thành nhanh hơn nhiều về thời gian thực tế.

Q: Khi nào một render server đơn lẻ là đủ? A: Một render server thường là đủ cho một artist đơn lẻ hoặc team nhỏ render ảnh tĩnh và chuỗi ngắn với deadline có độ trễ. Nếu tổng thời gian render của bạn (thời gian mỗi khung hình nhân số khung hình) nằm gọn trong deadline trên một máy, và scene của bạn vừa với bộ nhớ của máy đó, một server là đủ. Bước chuyển sang farm được thúc đẩy bởi phép tính số khung hình, giới hạn VRAM, hoặc sự tranh chấp job — không phải chỉ vì quy mô studio.

Q: Tôi có thể dùng render server cho Blender không? A: Có. Với ảnh tĩnh Blender hoặc chuỗi EEVEE ngắn, một render server đơn lẻ thường là tất cả những gì bạn cần, vì EEVEE nhanh trên mỗi khung hình. Với các animation Cycles dài — tốn nhiều compute nhưng song song hóa gọn gàng qua các khung hình — một farm biến một đêm render thành một job ngắn hơn nhiều. EEVEE được tăng tốc bằng GPU và được hỗ trợ trên các máy GPU của farm chúng tôi, nên các animation EEVEE nặng cũng có thể được phân tán thay vì chiếm dụng một card local duy nhất.

Q: Thuê một dedicated render server có rẻ hơn một cloud render farm không? A: Điều đó hoàn toàn phụ thuộc vào mô hình sử dụng của bạn. Một dedicated server đi thuê có chi phí hàng tháng cố định dù nó đang render hay đang rảnh, tiết kiệm chi phí cho việc render ổn định, gần như hàng ngày, giữ nó luôn bận. Một cloud farm tính theo job chỉ tính phí cho compute mà một job tiêu thụ, rẻ hơn cho các workload bùng nổ hoặc chạy deadline khi một máy dedicated sẽ nằm không giữa các đợt gấp rút. Hãy so sánh mức sử dụng thực tế của bạn, không chỉ mức giá theo giờ.

Q: Làm sao tôi tính được liệu một render server có đáp ứng được deadline của tôi không? A: Nhân thời gian render trung bình mỗi khung hình với tổng số khung hình để có tổng số giờ render, rồi so sánh với khung thời gian deadline bạn có. Ví dụ, 1.000 khung hình ở 6 phút mỗi khung là 100 giờ — hơn bốn ngày render liên tục trên một máy. Nếu con số đó vượt quá deadline của bạn, một server không thể xong kịp dù nó mạnh đến đâu, và bạn cần tính song song của một farm.

Q: Render farm có tốn chi phí hơn một render server đơn lẻ cho cùng một job không? A: Thường thì không, xét riêng phần compute — bạn bị tính phí cho tổng công việc render dù theo cách nào, nên cùng một job có chi phí compute gần tương đương dù một máy chạy chậm hay nhiều máy chạy nhanh. Thứ một farm mua là tốc độ đồng hồ thực tế: cùng một tổng chi phí nhưng được giao nhanh hơn nhiều nhờ chạy các khung hình song song. Khác biệt chi phí thực sự đến từ thời gian nhàn rỗi — một dedicated server bạn vẫn trả tiền trong khi nó không dùng, so với một farm tính theo job dừng tính phí giữa các job.

Q: Chi phí ẩn của việc tự vận hành render server là gì? A: Ngoài chi phí mua phần cứng, một render server tự vận hành mang theo các chi phí liên tục: tiền điện cho một máy chạy hết công suất trong nhiều giờ, nhiệt cần thông gió, các điều khoản license render engine quy định việc dùng headless và nhiều node, và gánh nặng bảo trì từ cập nhật driver, vá lỗi, và hỏng hóc phần cứng. Còn có chi phí cơ hội từ một máy bạn không thể dùng cho công việc sáng tạo trong khi nó đang render — điều này thường đẩy các studio hướng tới một máy thứ hai dedicated, âm thầm nhân đôi số lượng phần cứng.