SaaS render farm vs cluster riêng: so sánh trung thực cho người mua

Giới thiệu

Cuộc thảo luận về render farm năm 2026 vẫn bắt đầu bằng một câu hỏi duy nhất: nhà cung cấp nào sẽ hoàn thành job sớm hơn và tính phí ít hơn. Câu hỏi đó quan trọng, nhưng trả lời ở lớp sai. Quyết định định hình toàn bộ engagement — toán học giá, ranh giới bảo mật, hành vi mở rộng, chi phí tích hợp, dữ liệu nằm ở đâu — là mô hình deployment mà nhà cung cấp bán, không phải thương hiệu nhà cung cấp ở trên. Hai farm vận hành tốt với mô hình khác nhau sẽ cảm thấy như hai sản phẩm khác nhau, ngay cả khi cả hai đều có thể render cùng một scene.

Hai mô hình deployment thống trị trong thị trường này là render farm SaaS được quản lý (hạ tầng dùng chung, credential do nhà cung cấp quản lý, workflow do nhà cung cấp vận hành) và cluster render dành riêng (phần cứng do nhà cung cấp cung cấp, credential thuộc khách hàng, workflow do khách hàng kiểm soát). Phần lớn cloud render farm chỉ vận hành mô hình SaaS; một nhóm nhỏ hơn cung cấp mô hình dành riêng như một lựa chọn song song cho người mua enterprise và nhạy cảm với IP. Chúng tôi vận hành cả hai — SaaS được quản lý là dịch vụ mặc định và là nơi phần lớn cơ sở khách hàng của chúng tôi sinh sống, và cluster dành riêng là một lựa chọn mà chúng tôi triển khai cho các studio có workload, tư thế IP hoặc độ phức tạp workflow khiến các đánh đổi của mô hình dành riêng đáng để trả phí. Chúng tôi nói thẳng về việc mô hình nào thắng khi nào. Có những workload mà mô hình dành riêng là quá mức và SaaS rõ ràng là câu trả lời đúng; có những workload mà SaaS là lựa chọn sai bất kể chất lượng nhà cung cấp SaaS ra sao.

Bài viết này đi qua từng mô hình thực sự là gì, kinh tế của chúng hoạt động ra sao, chúng xử lý kiểm soát dữ liệu và cách ly IP thế nào, mở rộng ra sao, một ma trận fit mười dòng, một framework quyết định mua mười câu hỏi có thể trả lời trong một buổi chiều, và các ví dụ nhà cung cấp trung thực trong mỗi danh mục. Đối tượng là CTO studio, TD pipeline, lead production của agency và supervisor VFX freelance đang đánh giá cloud rendering cho một dự án thực. Nếu đang đánh giá render farm lần đầu, hướng dẫn what is a fully managed render farm là điểm khởi đầu tốt hơn; bài này giả định bạn đã biết render farm là gì và đang chọn cách tiêu thụ nó.

Render farm SaaS được quản lý là gì?

Render farm SaaS được quản lý là một dịch vụ rendering multi-tenant. Nhà cung cấp sở hữu và vận hành một pool phần cứng — node CPU, node GPU, hoặc cả hai — và đưa pool đó ra cho nhiều khách hàng đồng thời thông qua dashboard, plugin DCC hoặc form upload web. Bạn upload scene, chọn cấu hình render, submit job, và queue của nhà cung cấp dispatch nó lên phần cứng đang rảnh. Phần lớn studio đang đọc bài này từng dùng một render farm SaaS vào lúc nào đó. Đây là mô hình đưa cloud rendering lên bản đồ.

Đặc điểm xác định của mô hình SaaS là nhà cung cấp xử lý workflow, không chỉ phần cứng. Nhà cung cấp duy trì cài đặt DCC và phiên bản plugin, giữ license phần mềm rendering, vận hành render manager (thường là Deadline hoặc tương đương), quản lý pipeline upload asset, vận hành scheduler queue, và trả frame hoàn thiện về cho khách hàng. Từ góc nhìn khách hàng, bề mặt là "upload, render, download". Giá dựa trên sử dụng — thường là per-OctaneBench-hour cho render GPU, per-GHz-hour cho render CPU, hoặc per-frame tùy engine.

Kinh tế phù hợp với một dạng workload cụ thể. Một studio submit scene test Karma trên 500 frame, nhận hóa đơn tính bằng dollar thay vì hàng nghìn, và xong vào sáng hôm sau là ca dùng SaaS điển hình. Một freelance render một job archviz duy nhất cho deadline khách trả tiền cho job đó rồi đi. Một studio có nhu cầu render bursty — tuần yên ắng, tuần cao điểm — chỉ trả khi render và không phải gồng capacity trong tuần yên ắng. Pool dùng chung của nhà cung cấp hấp thụ burst vì các tuần yên ắng của khách hàng khác trợ giá cho nó.

Các nhà cung cấp trong danh mục này gồm iRender, RebusFarm, GarageFarm.net, FoxRenderFarm, và Super Renders Farm trong cấu hình SaaS-managed của chúng tôi. Sự khác biệt giữa các nhà cung cấp này là có thật nhưng nằm dưới mô hình — DCC và plugin được hỗ trợ, spec phần cứng, độ trễ địa lý, giá per-OctaneBench-hour, license partner-authorized khi cần, và chất lượng support khách hàng trong tuần deadline. Bản thân mô hình, xuyên qua các nhà cung cấp này, là nhận biết được giống nhau: hạ tầng dùng chung, workflow do nhà cung cấp quản lý, pay-per-use.

Cluster render dành riêng là gì?

Cluster render dành riêng là đối nghịch kiến trúc với mô hình SaaS trên những chiều quan trọng. Nhà cung cấp vẫn cung cấp và vận hành phần cứng — cùng chassis, cùng GPU, cùng network — nhưng ranh giới vận hành dừng ở phần cứng. Khách hàng sở hữu credential, vận hành render manager riêng (thường là repository Deadline riêng được dời vào cluster), duy trì stack phần mềm riêng, và đối xử với cluster như thể là phần cứng on-premise tình cờ nằm trong datacenter của nhà cung cấp. Nhà cung cấp chịu trách nhiệm cho lớp vật lý, baseline OS, network và storage dùng chung; khách hàng chịu trách nhiệm cho mọi thứ ở trên.

Đặc điểm xác định của mô hình dành riêng là cluster là single-tenant. Không có job của khách hàng khác đáp lên những node đó. Không có user account của khách hàng khác tồn tại bên trong ranh giới xác thực của cluster. Render manager, khi ghi log path asset hoặc check-out license, chỉ trỏ vào pipeline của khách hàng. Cuối engagement, cluster được wipe và khách hàng có thể được cấp một attestation rằng dữ liệu của họ đã được xóa. Đây là mô hình hợp lý cho các studio có NDA cấm render multi-tenant, cho workflow asset có license mà thư viện không thể rời khỏi một ranh giới tin cậy đã xác định, và cho pipeline được tùy biến nặng trong nội bộ không thể biểu diễn trong UI submit của nhà cung cấp SaaS.

Kinh tế của mô hình phù hợp với một dạng workload khác. Giá thường là retainer hàng tháng cộng với phí setup, kèm cam kết tối thiểu nhiều tháng. Vốn phần cứng được nhà cung cấp hấp thụ và phân bổ qua retainer; khách hàng trả một con số hàng tháng dự đoán được thay vì hóa đơn biến đổi per-frame. Phép toán cho ra kết quả khi utilization của khách hàng đủ cao để retainer hàng tháng rẻ hơn hóa đơn per-OctaneBench-hour tương đương ở mức giá SaaS, và khi tính liên tục vận hành của "cùng cluster, cùng cấu hình, mọi dự án" biện minh cho cam kết.

Thị trường cluster dành riêng nhỏ hơn nhiều so với thị trường SaaS. Phần lớn cloud render farm không cung cấp lựa chọn này — toàn bộ mô hình kinh doanh được xây quanh utilization hạ tầng dùng chung, và một deployment single-tenant đi ngược với giả định vận hành. Trong cơ sở khách hàng của chúng tôi, deployment cluster dành riêng chiếm thiểu số engagement nhưng chiếm phần đáng kể trong doanh thu enterprise. Chúng tôi vận hành chúng khi workload, tư thế IP hoặc workflow của khách hàng khiến các đánh đổi của mô hình dành riêng trở thành fit tốt hơn; chúng tôi điều hướng khách hàng tới dịch vụ SaaS-managed khi workload không đòi hỏi điều mà mô hình dành riêng cung cấp. Self-hosted on-premise là lựa chọn thứ ba — khách hàng có thể mua phần cứng riêng và vận hành cluster trong datacenter riêng, đổi vốn, mặt bằng, điện, làm mát và gánh nặng vận hành lấy sự tự do của toàn quyền kiểm soát. Mỗi mô hình có những trường hợp là câu trả lời đúng.

So sánh mô hình giá

Giá là nơi hai mô hình trông khác nhau nhất trên giấy và là nơi so sánh thường bị đóng khung sai nhất. Phiên bản trung thực đòi hỏi so sánh cùng một workload qua cả hai mô hình ở mức utilization thực tế, không phải giá niêm yết so với giá niêm yết.

Giá SaaS dựa trên sử dụng. Cho render GPU, đơn vị tính phí chính tắc là OctaneBench-hour: nhà cung cấp đo lượng compute scene của bạn theo đơn vị tương đương OctaneBench-hour và nhân với mức per-OB-hour. Cho render CPU, đơn vị tính phí là GHz-hour. Ví dụ tiêu biểu: một scene Karma 500 frame mất một RTX 5090 đơn lẻ khoảng 20 phút mỗi frame ở thiết lập điển hình tiêu thụ khoảng 1900 OctaneBench-hour trên render phân tán, ở mức $0,004/GHz-hr điển hình ngành (tương đương khoảng $0,10 per OctaneBench-hour) tính ra khoảng $190 cho job. Khách hàng trả hóa đơn đó một lần, engagement hoàn thành, hóa đơn job kế phụ thuộc vào scope của job kế. Hóa đơn mở rộng tuyến tính với công việc.

Giá cluster dành riêng dựa trên retainer. Hình dạng tiêu biểu là retainer hàng tháng trong khoảng thấp tới trung năm chữ số cho cluster GPU 10–20 node, phí setup trong khoảng bốn-năm chữ số để provision build, và cam kết tối thiểu nhiều tháng — thường 3 tới 12 tháng. Bảng giá công khai không phổ biến vì cấu hình quá quan trọng; số node, lựa chọn GPU, kích thước storage, dung lượng network và mô hình license của khách hàng đều dịch chuyển con số. Mẫu hình thì nhất quán: chi phí hàng tháng dự đoán được, không biến động per-frame, và một sàn cứng bên dưới mà khách hàng trả dù có lấp đầy cluster hay không.

SaaS thắng về giá khi utilization thấp hoặc bursty. Một studio có nhu cầu render project-based, với những giai đoạn yên ắng giữa các engagement, trả ít hơn trên SaaS vì không trợ giá cho capacity nhàn rỗi. Một studio có tổng hóa đơn SaaS hàng tháng ở khoảng thấp bốn chữ số hoặc dưới không có lập luận toán cho mô hình dành riêng.

Mô hình dành riêng thắng về giá khi utilization cao và bền vững. Một studio có hóa đơn SaaS thường xuyên rơi vào khoảng giữa năm chữ số mỗi tháng đạt tới một crossover ở đó retainer hàng tháng rẻ hơn hóa đơn per-OB-hour tương đương. Crossover thay đổi theo engine, phần cứng và mức giá đã thương lượng, nhưng mẫu hình có thể tái lập: có một ngưỡng utilization mà trên đó mô hình dành riêng trở thành mô hình vận hành rẻ hơn. Retainer cũng bao gồm một lớp tính liên tục vận hành — cùng cluster, cùng cấu hình, cùng cache nóng, cùng render manager thuộc khách hàng — mà so sánh per-bill SaaS không bắt được và đáng giá tiền thật với người vận hành lượng lớn.

Không mô hình nào thắng về giá trong trường hợp chung. Chúng thắng ở những chế độ vận hành khác nhau. So sánh đúng là workload thực của khách hàng qua cả hai mô hình ở utilization thực, không phải giá niêm yết.

So sánh kiểm soát dữ liệu và bảo mật IP

So sánh dữ liệu và bảo mật là nơi quyết định mô hình thường được đưa ra cho các khách hàng có hợp đồng cấm tư thế SaaS. Hai mô hình có ranh giới mặc định khác nhau, và mô hình dành riêng có một biến thể cấu hình bổ sung — Bring Your Own Credentials (BYOC) — thắt chặt thêm ranh giới cho khách hàng cần.

Trên mô hình SaaS, nhà cung cấp xử lý dữ liệu khách hàng bên trong ranh giới vận hành của nhà cung cấp. File scene của khách hàng đáp xuống storage của nhà cung cấp, render manager của nhà cung cấp dispatch nó lên worker multi-tenant, credential của nhà cung cấp ủy quyền check-out license phần mềm, và output đã render nằm trên storage của nhà cung cấp cho tới khi khách hàng tải xuống. Nhà cung cấp nhìn thấy asset, quản lý credential và vận hành bên trong tenancy. Cho workload không nhạy cảm IP — phần lớn archviz hướng tiêu dùng, phần lớn công việc freelance, phần lớn dự án không có nghĩa vụ xử lý dữ liệu theo hợp đồng — tư thế này là bình thường và được chấp nhận, và kinh tế multi-tenant là điều khiến mô hình SaaS có giá phải chăng.

Trên mô hình cluster dành riêng, credential của khách hàng vận hành bên trong cluster. Cluster là single-tenant, nên không có job khách hàng khác chạy kế bên. Khách hàng có thể chọn mức độ thu hẹp truy cập của nhà cung cấp: BYOC đầy đủ, nơi khách hàng giữ tất cả credential và nhà cung cấp không có truy cập logic vượt quá baseline OS, ở một đầu; vận hành vendor-assisted, nơi nhà cung cấp giúp quản lý credential nhưng credential vẫn nằm trong tenancy khách hàng, ở giữa. Cuối engagement, cluster được wipe và khách hàng có thể được cấp attestation rằng dữ liệu đã được xóa.

Khách hàng cần tư thế dành riêng biết là họ cần, vì yêu cầu đến từ bên ngoài quyết định render — một NDA từ client, một nghĩa vụ hợp đồng từ film studio làm việc với IP có license, một yêu cầu compliance từ ngành được quản lý, hoặc một tư thế bảo mật từ CISO của khách hàng không chấp nhận render multi-tenant. Cluster dành riêng thỏa mãn những yêu cầu đó mà không buộc khách hàng phải mua và vận hành phần cứng. Để hiểu thêm BYOC nghĩa là gì trong thực tế, hướng dẫn customer-owned credentials của chúng tôi bao quát mô hình chi tiết.

Tư thế dành riêng không tự động cải thiện bảo mật — một cluster dành riêng vận hành kém yếu hơn một deployment SaaS vận hành tốt, và phần lớn nhà cung cấp SaaS quy mô đáng kể đã đầu tư cho security engineering nhiều hơn phần lớn studio sẽ đầu tư trong một thập kỷ. Điều mà mô hình dành riêng cung cấp là một ranh giới khác — một ranh giới thỏa mãn các yêu cầu hợp đồng và compliance mà ranh giới SaaS, do bản chất multi-tenant, không thể. Lựa chọn là về ranh giới mà hợp đồng và nghĩa vụ của khách hàng đòi hỏi, không phải về mô hình nào "an toàn hơn" một cách trừu tượng.

So sánh khả năng mở rộng

Khả năng mở rộng là chiều so sánh nơi hai mô hình thực sự hành xử theo cách khác nhau, và nơi câu trả lời đúng phụ thuộc vào loại scaling mà khách hàng cần.

SaaS mở rộng tức thì tới giới hạn của pool dùng chung của nhà cung cấp. Khi khách hàng submit job cần 80 node trong hai giờ, scheduler của nhà cung cấp dispatch trên 80 node đang rảnh. Khách hàng không provision, không pre-warm, không trả cho capacity không dùng — tính đàn hồi được pool dùng chung hấp thụ. Cho burst không thể dự đoán — một thay đổi deadline client nén một tuần render xuống 36 giờ, một render redo trên shot đã finalize, một job đến bất ngờ — SaaS xử lý đỉnh mà không cần khách hàng lập kế hoạch capacity. Trần là kích thước pool tổng của nhà cung cấp và tranh chấp với khách hàng khác chạy job lớn cùng lúc, mà trong thực tế hiếm khi là ràng buộc thực ngoài vài giai đoạn cao điểm mỗi năm.

Mô hình dành riêng mở rộng theo capacity được lên kế hoạch. Một cluster dành riêng 20 node cho khách hàng 20 node — mỗi giờ mỗi ngày, dù có job chạy hay không. Burst vượt 20 node yêu cầu hoặc làm cluster lớn lên (một bước mua sắm và provisioning mất ngày tới tuần) hoặc vận hành một hybrid trong đó capacity dành riêng xử lý baseline và capacity SaaS hấp thụ đỉnh. Cluster được dimension cho steady state, không cho đỉnh.

Mô hình scaling đúng phụ thuộc vào tính dự đoán của tải. Một studio có volume render hàng tháng dao động trong 30 % quanh một baseline và biết trước nhiều tháng khi nào dự án lớn đáp xuống thì hợp với mô hình dành riêng. Một studio có tải hàng tháng dao động 5× giữa tháng yên ắng và tháng bận thì không hợp — khách hàng đó sẽ bị over-provision trong tháng yên ắng hoặc under-provision trong tháng bận, và SaaS hấp thụ biến động tự nhiên hơn.

Một mẫu hình hybrid dùng cả hai mô hình có chủ đích: dành riêng cho phần dự đoán được, SaaS từ cùng nhà cung cấp cho đỉnh. Hybrid đòi hỏi một nhà cung cấp hỗ trợ cả hai mô hình, và là end-state phổ biến cho các studio đã qua pha pure-SaaS.

Ma trận fit theo ca dùng

Hai mô hình phù hợp với các kịch bản studio khác nhau. Ma trận dưới đây map các tình huống phổ biến tới một khuyến nghị mặc định. Không cái nào là tuyệt đối — một studio có ràng buộc ngoài mẫu hình điển hình có thể đáp vào ô khác — nhưng các mặc định là điểm khởi đầu chúng tôi sẽ đưa ra trong một cuộc trò chuyện với khách hàng tiềm năng.

Một vài hàng xứng đáng được xử lý "phụ thuộc workload" minh thị. Phân tán team cross-country có thể hoạt động trên SaaS với các studio có workflow upload-asset-rồi-render-rồi-download, vì nhà cung cấp SaaS xử lý địa lý nội bộ; nhưng các studio cần truy cập artist trễ thấp liên tục vào môi trường render xuyên lục địa cuối cùng vào mô hình dành riêng với một kiến trúc cross-country dùng WireGuard và cache SMB dùng chung. Stack plugin custom chạy trên SaaS nếu hỗ trợ plugin của nhà cung cấp SaaS đã cover stack của khách hàng; nếu khách hàng vận hành plugin nội bộ hoặc tooling bên thứ ba ngách mà nhà cung cấp SaaS không thể cài lên worker dùng chung, mô hình dành riêng trở thành mặc định. Công việc client agency cỡ trung là mặc định-SaaS với phần lớn agency nhưng ngả sang dành riêng với các agency mà client lớn nhất có NDA yêu cầu render single-tenant — tư thế IP override kinh tế utilization.

Ma trận nên được đọc là "bắt đầu cuộc trò chuyện ở đâu", không phải "làm gì". Một studio có tình huống nằm trong hai ô nên nghĩ ô nào mang ràng buộc mạnh hơn. Tư thế IP và utilization là hai ô override các ô khác thường xuyên nhất.

Framework quyết định mua 10 câu hỏi

Ma trận đưa ra một khuyến nghị mô hình theo kịch bản. Framework người mua dưới đây là phiên bản chi tiết — mười câu hỏi mà nếu trả lời trung thực sẽ đưa bạn tới mô hình đúng cho tình huống cụ thể. Phần lớn studio có thể trả lời cả mười trong một buổi chiều.

1. Độ dài dự án trung bình của bạn là bao nhiêu? Dự án ngắn (giao một lần, engagement đơn tháng) ưu ái SaaS. Engagement nhiều tháng với tải render bền vững ưu ái mô hình dành riêng.
2. Hợp đồng client hoặc NDA của bạn có yêu cầu render single-tenant hoặc hạn chế nơi dữ liệu có thể xử lý không? Câu trả lời có ở đây phần lớn quyết định ngả về mô hình dành riêng bất kể các yếu tố khác.
3. Mô hình license của bạn là gì — BYOL (Bring Your Own License) hay vendor-provided? Cả hai mô hình hỗ trợ cả hai cách tiếp cận, nhưng chi phí vận hành dịch chuyển. Mô hình dành riêng thường ghép sạch sẽ hơn với BYOL; SaaS thường gói license vendor-provided vào mức per-OB-hour.
4. Bạn có cần chạy nhiều dự án song song trên các pipeline khác nhau không? Nếu có, lập luận cách ly dự án nghiêng về mô hình dành riêng, nơi mỗi dự án có thể có user account và cấu hình riêng. SaaS xử lý dự án song song nhưng qua queue của nhà cung cấp, không qua cách ly do khách hàng quản lý.
5. Năng lực IT nội bộ và pipeline-engineering của bạn ra sao? Mô hình dành riêng đòi hỏi một team nội bộ đủ năng lực vận hành render manager và pipeline. Nếu studio không có năng lực đó, SaaS loại bỏ yêu cầu vì nhà cung cấp vận hành pipeline.
6. Bạn thích linh hoạt CapEx hay OpEx? SaaS là OpEx thuần — hóa đơn mở rộng theo dùng, không cam kết. Mô hình dành riêng là OpEx dạng retainer nhưng với cam kết nhiều tháng cư xử giống chi phí cố định hơn. Hybrid chia đôi.
7. Stack plugin và DCC của bạn phức tạp đến mức nào? Một pipeline 3ds Max + V-Ray tiêu chuẩn chạy trên mọi nhà cung cấp SaaS trên thị trường. Một pipeline Houdini nội bộ với HDA custom, plugin bên thứ ba ngách và phụ thuộc OS cụ thể có thể không fit lên worker dùng chung của nhà cung cấp SaaS và đẩy quyết định về mô hình dành riêng.
8. Thành viên team ở đâu về mặt địa lý? Team đơn quốc gia có ràng buộc địa lý nhẹ nhất. Team đa lục địa có thể cần kiến trúc network cross-country của mô hình dành riêng để giữ độ trễ workflow hợp lý.
9. Yêu cầu compliance của bạn là gì? SOC 2, ISO 27001, MPA-readiness và các tư thế tương tự thường đòi hỏi render single-tenant hoặc các cam kết xử lý dữ liệu cụ thể mà mô hình SaaS multi-tenant không thể cung cấp out-of-the-box.
10. Volume render hàng năm của bạn là bao nhiêu tính theo OctaneBench-hour hoặc GHz-hour? Hãy tính: ở mức giá SaaS điển hình ngành, volume hàng năm của bạn sẽ tốn bao nhiêu trên SaaS, và retainer dành riêng tương đương sẽ tốn bao nhiêu trong cùng kỳ? Nếu mô hình dành riêng rẻ hơn ở volume của bạn, kinh tế utilization ưu ái mô hình dành riêng. Nếu SaaS rẻ hơn, kinh tế utilization ưu ái SaaS.

Phần lớn studio trả lời trung thực mười câu hỏi này đáp xuống một mặc định rõ ràng. Các studio có quyết định thực sự chia đôi thường là những studio có tư thế IP nói mô hình dành riêng nhưng utilization nói SaaS — trường hợp đó thường giải quyết về mô hình dành riêng vì yêu cầu IP là không thương lượng theo cách mà kinh tế utilization không phải.

Ví dụ nhà cung cấp (trung thực)

Quyết định mô hình thu hẹp danh sách nhà cung cấp. Chúng tôi nêu tên nơi điều đó giúp người mua đánh giá toàn cảnh trung thực. SRF xuất hiện cuối phần này có chủ đích — chúng tôi không phải lựa chọn duy nhất trong bất kỳ danh mục nào, và quyết định nên dựa trên fit của nhà cung cấp với workload của bạn, không phải bài viết của nhà cung cấp nào bạn tình cờ đọc.

Các nhà cung cấp render farm SaaS được quản lý với lịch sử vận hành đã thiết lập:

• iRender — trụ sở tại Việt Nam, định hướng GPU-first, giá hybrid subscription và pay-per-use. Mạnh ở các thị trường nơi artist tự quản lý nhiều phần của pipeline.
• RebusFarm — trụ sở tại Đức, 20 năm lịch sử vận hành, hỗ trợ DCC và engine rộng, nhiều datacenter địa lý. Dịch vụ render thương mại lâu năm với độ phủ ngôn ngữ rộng.
• GarageFarm.net — đăng ký tại UK với datacenter Ba Lan (Copernicus Computing tại Toruń, chứng nhận ISO 27001), hub customer service tại Hàn Quốc, 16 năm lịch sử vận hành. Farm tổng quát với hỗ trợ DCC rộng; AE đã bị deprecated và Houdini không được hỗ trợ native từ 2026.
• FoxRenderFarm — trụ sở tại Trung Quốc, hỗ trợ DCC rộng, độ phủ đa ngôn ngữ. Mạnh ở các thị trường Châu Á - Thái Bình Dương.
• Super Renders Farm (SaaS-managed) — dịch vụ mặc định của chúng tôi. Tính phí per-OctaneBench-hour cho render GPU, per-GHz-hour cho render CPU. Hỗ trợ 3ds Max, Maya, Cinema 4D, Blender, Houdini, After Effects và NukeX. Render engine: V-Ray, Corona, Arnold, Redshift, Octane, Cycles. License partner-authorized qua Chaos Group (V-Ray, Corona) và Maxon (Cinema 4D, Redshift). Fleet: 20.000+ CPU core và một fleet GPU dành riêng trên NVIDIA RTX 5090 với 32 GB VRAM mỗi card.

Cluster render dành riêng là thị trường nhỏ hơn. Phần lớn nhà cung cấp SaaS phía trên không cung cấp mô hình dành riêng như lựa chọn song song — mô hình kinh doanh xây quanh utilization dùng chung, và cấu hình single-tenant nằm ngoài cung cấp mặc định. Khách hàng cần mô hình dành riêng hoặc xây trên rail infrastructure-as-a-service (AWS, GCP, nhà cung cấp bare-metal) và chạy render manager riêng phía trên, hoặc làm việc với nhà cung cấp vận hành cả hai mô hình.

Super Renders Farm (cluster dành riêng) — cung cấp cluster dành riêng của chúng tôi. Chúng tôi triển khai cluster riêng cho khách hàng trên cùng phần cứng mà dịch vụ SaaS của chúng tôi chạy, nhưng cấu hình single-tenant với credential thuộc khách hàng, render manager do khách hàng kiểm soát, năng lực BYOC, attestation dữ liệu cuối-engagement và capacity hybrid (baseline dành riêng kèm hấp thụ burst SaaS từ pool dùng chung khi cần). Cung cấp dành riêng được xây quanh các mẫu hình vận hành chúng tôi đã học từ việc vận hành cluster production tại site khách hàng qua các engagement nhiều tháng, bao gồm các deployment cross-country kết hợp artist tại US với hạ tầng tại Việt Nam qua tunnel mã hóa.

Một ghi chú về self-hosted như lựa chọn thứ ba: một studio có năng lực kỹ thuật hạ tầng mạnh có thể xây cùng kiến trúc trên phần cứng sở hữu, trong một colocation thuê, với cùng các thành phần open-source (Linux, Samba SMB3, Deadline, v.v.). Quyết định giữa dành-riêng-với-vendor và self-hosted là một câu hỏi build-vs-buy xoay quanh vốn khả dụng, mặt bằng, điện và làm mát và độ chín vận hành của studio. Hướng dẫn render farm build vs cloud total cost của chúng tôi bao quát toán self-hosted-vs-vendor riêng.

FAQ

Q: Khi nào ROI của cluster dành riêng vượt SaaS được quản lý? A: Crossover xảy ra khi utilization hàng tháng bền vững ở giá SaaS vượt retainer dành riêng tương đương. Ngưỡng chính xác phụ thuộc vào mức per-OB-hour của khách hàng, mix phần cứng và độ dài hợp đồng, nhưng mẫu hình có thể tái lập: các studio có hóa đơn SaaS hàng tháng nhất quán rơi vào khoảng giữa năm chữ số trở lên thường thấy phép toán dành riêng cho ra kết quả, kèm giá trị bổ sung của tính liên tục vận hành (cùng cluster, cùng cache nóng, cùng render manager thuộc khách hàng) phía trên.

Q: Tôi có thể bắt đầu trên SaaS được quản lý rồi nâng cấp lên dành riêng sau không? A: Có, đây là con đường phổ biến. Studio thường bắt đầu trên SaaS để xác thực workflow và đo utilization thực, sau đó chuyển sang dành riêng ngay khi hóa đơn hàng tháng hoặc tư thế IP biện minh cho điều đó. Với nhà cung cấp vận hành cả hai mô hình, việc chuyển chủ yếu là bước mua sắm cộng bước migration pipeline; với nhà cung cấp chỉ-SaaS, việc chuyển yêu cầu đổi vendor hoặc đi self-hosted, là nỗ lực lớn hơn.

Q: Cluster dành riêng có chỉ dành cho enterprise không? A: Nghiêng về enterprise vì phép toán retainer yêu cầu utilization bền vững mà các studio nhỏ thường không có, nhưng không chỉ dành cho enterprise. Các studio cỡ trung với workload nhạy cảm IP (agency có client bị ràng buộc NDA, VFX house indie làm dự án thuộc property có license) thường triển khai mô hình dành riêng ngay cả ở utilization thấp hơn vì tư thế là bắt buộc, không phải vì kinh tế utilization đòi hỏi. Yêu cầu IP override yêu cầu volume trong các trường hợp đó.

Q: Render manager (Deadline) được xử lý khác nhau giữa hai mô hình ra sao? A: Trên SaaS, nhà cung cấp vận hành render manager và khách hàng submit job qua UI submit hoặc plugin của nhà cung cấp. Khách hàng không log vào Deadline trực tiếp. Trên mô hình dành riêng, khách hàng hoặc vận hành repository Deadline riêng trong cluster hoặc dùng một repository nhà cung cấp vận hành thay mặt khách hàng — nhưng khách hàng có truy cập trực tiếp tới render manager, có thể cấu hình pool và group, có thể tích hợp công cụ pipeline riêng với API Deadline và có thể thay đổi hành vi scheduling mà không qua yêu cầu support vendor.

Q: Còn hybrid SaaS + dành riêng — một số job trên mỗi cái thì sao? A: Đây là end-state phổ biến cho studio đã qua pha pure-SaaS. Tải baseline chạy trên dành riêng vì kinh tế chi phí đơn vị và tính liên tục vận hành, còn đỉnh burst đẩy sang SaaS từ cùng nhà cung cấp (hoặc khác) trong khoảng thời gian đỉnh. Hybrid yêu cầu nhà cung cấp vận hành cả hai mô hình hoặc kỷ luật vận hành để chia workflow giữa hai nhà cung cấp. Phần lớn studio đáp xuống hybrid đã bắt đầu trên SaaS, chuyển baseline sang dành riêng và giữ SaaS để hấp thụ đỉnh.

Q: Uptime và SLA khác nhau giữa hai mô hình ra sao? A: SLA của SaaS thường là cam kết khả dụng queue — nhà cung cấp đảm bảo queue chấp nhận job và dispatch trong một cửa sổ thời gian, nhưng độ trễ job cụ thể của khách hàng thay đổi theo tranh chấp pool dùng chung. SLA của mô hình dành riêng thường là cam kết khả dụng per-node — nhà cung cấp đảm bảo node dành riêng up và tới được, và khách hàng kiểm soát hành vi queue. Các studio có workflow nhạy cảm deadline thường thích SLA dành riêng vì đặt kiểm soát queue trong tay họ, loại biến động pool dùng chung khỏi critical path.

Q: Độ dài hợp đồng điển hình cho một engagement cluster dành riêng là bao nhiêu? A: Cam kết tối thiểu thường chạy từ ba tháng cho engagement ngắn hơn tới mười hai tháng cho deployment enterprise đầy đủ, tùy kích thước cluster và cấu trúc phí setup. Tồn tại cam kết ngắn hơn cho trial hoặc công việc đơn dự án nhưng mang mức hàng tháng cao hơn để phân bổ setup. Hợp đồng nhiều năm đi kèm nhượng bộ về mức giá để đổi lấy độ dài cam kết. Độ dài hợp đồng đúng khớp với chân trời lập kế hoạch của khách hàng cho workload biện minh cho cluster.

Q: Cluster dành riêng có thể mở rộng giữa engagement nếu workload tăng không? A: Có, nhưng scaling là theo kế hoạch chứ không tức thì. Làm cluster dành riêng lớn lên bằng cách thêm node yêu cầu mua sắm, provisioning và một cửa sổ commissioning ngắn — thường là ngày tới tuần thay vì tính đàn hồi tức thì của SaaS. Cho workload mà scale-up có thể dự đoán được, không thành vấn đề; cho tăng trưởng không dự đoán được, khách hàng thường cấu hình sắp xếp hybrid nơi SaaS hấp thụ đỉnh trong khi cluster dành riêng mở rộng tới steady state mới.