Hai chiếc máy 128GB, chung một nút thắt băng thông

Hai cỗ máy ra mắt trong cùng một khoảng thời gian với cùng một con số nổi bật: 128GB bộ nhớ hợp nhất, bộ tăng tốc truy cập trực tiếp, nằm gọn trên bàn làm việc, với giá vài nghìn đô la. DGX Spark của NVIDIA và Ryzen AI Max+ 395 (“Strix Halo”) của AMD.

Khách hàng liên tục hỏi tôi nên mua cái nào. Câu trả lời trung thực bắt đầu bằng một điều mà không bên nào đưa lên đầu tài liệu tiếp thị: xét về tốc độ sinh token, hai cỗ máy này gần nhau hơn nhiều so với khoảng cách giữa chúng và một GPU rời thực thụ — và thứ khiến chúng đáng chú ý là dung lượng, không phải tốc độ.

(Các thông số phần cứng bên dưới lấy từ tài liệu chính thức của NVIDIA và AMD, có dẫn nguồn ở những chỗ quan trọng. Phần giá được nêu một cách dè dặt có chủ ý: tình trạng khan hiếm bộ nhớ năm 2026 đang khiến giá biến động đủ nhanh để mọi con số tôi ghi ở đây đều sai vào lúc bạn đọc. Sẽ nói kỹ hơn ngay dưới bảng.)

Thông số đặt cạnh nhau

Hãy nhìn dòng băng thông. 273 so với 256 GB/s. Đó là sai số làm tròn, và nó chính là con số quyết định mỗi máy sinh token nhanh đến đâu.

Rồi hãy nhìn ba dòng ngay bên dưới — nhân 4-bit gốc, kết nối liên máy, ghép cụm. Đó mới là chỗ hai cỗ máy thật sự khác nhau, và không điều nào trong số đó hiện ra trong một bài benchmark đo token mỗi giây.

Khoảng cách về giá đã bị xóa nhòa

Lúc mới ra mắt, một cỗ máy Strix Halo 128GB có giá chỉ khoảng một nửa DGX Spark, và đó từng là một luận điểm trụ cột cho nó. Điều đó không còn đúng nữa.

Vào thời điểm tôi viết bài này, các mini-PC Strix Halo bản 128GB đang bán ở cùng tầm giá với Spark — Minisforum MS-S1 Max 128GB khoảng 3.639 đô la so với giá niêm yết 4.549 đô la, và GMKtec EVO-X2 khoảng 3.650 đô la so với giá niêm yết 3.999 đô la, là những ví dụ tiêu biểu. Ở mức giá niêm yết, một số máy trong đó hiện còn đắt hơn một chiếc DGX Spark.

Nguyên nhân là tình trạng khan hiếm DRAM năm 2026, thứ đã đẩy giá bộ nhớ tăng mạnh trên toàn ngành — Apple đã nâng giá Mac và iPad, còn giá bộ nhớ theo hợp đồng ở một số nơi đã tăng gần gấp đôi. Một cỗ máy mà chi phí linh kiện bị chi phối bởi 128GB LPDDR5X sẽ hứng trọn mức tăng đó gần như trực tiếp, trong khi một thiết bị bán theo giá cố định thì thấm chậm hơn. Khoảng cách bị xóa nhòa không phải vì Spark rẻ đi.

Hai hệ quả. Thứ nhất, mọi con số giá cụ thể trong bài này nhiều khả năng đã lỗi thời vào lúc bạn đọc — hãy kiểm tra lại trước khi lập kế hoạch dựa trên nó. Thứ hai, và quan trọng hơn: luận điểm “AMD đơn giản là rẻ hơn” giờ yếu hơn hẳn so với trước, và điều đó làm thay đổi phần khuyến nghị ở cuối bài.

Phần so sánh kỹ thuật thì không bị ảnh hưởng. Băng thông, FP4, mức đồng thời và ghép cụm vẫn hành xử như nhau bất kể hai cỗ máy có giá bao nhiêu.

Vì sao băng thông mới là con số quan trọng

Sinh ra một token bị giới hạn bởi bộ nhớ, không phải bởi năng lực tính toán. Với mỗi token, máy phải đọc toàn bộ trọng số của mô hình từ bộ nhớ. Vậy nên có một trần cứng:

token/giây  ≈  băng thông bộ nhớ ÷ số byte đọc mỗi token

Áp dụng cho một mô hình dense 70B ở mức 4-bit — khoảng 40GB trọng số:

273 GB/s ÷ 40 GB ≈ 6,8 token/giây, trước khi tính đến mọi hao hụt thực tế. Trên thực tế hãy chờ đợi con số thấp hơn đáng kể. Như vậy là chậm hơn tốc độ bạn đọc.

Giờ hãy so với một GPU rời chơi game hiện nay ở khoảng 1,8 TB/s. Với một mô hình vừa với VRAM của nó, chiếc card đó nhanh hơn khoảng 7 lần so với cả hai cỗ máy 128GB. Không phải 7% — mà là 7 lần.

Đó là toàn bộ câu chuyện. Những cỗ máy này không nhanh. Chúng lớn. Bạn mua một chiếc vì mô hình không vừa ở đâu khác trong tầm giá này, và bạn chấp nhận tốc độ đi kèm.

Và đó là lý do mixture-of-experts thay đổi kết luận

Tôi từng viết ở bài trước rằng mô hình MoE nhanh trên phần cứng khiêm tốn, chứ không phải nhỏ trên đó. Trên một cỗ máy 128GB bộ nhớ hợp nhất, tính chất ấy không còn là chú thích bên lề mà trở thành toàn bộ lý do để sở hữu nó.

Một mô hình dense 70B đọc khoảng 40GB mỗi token. Một mô hình MoE lớn với số tham số kích hoạt nhỏ — chẳng hạn tổng trên 100B nhưng chỉ vài tỷ được kích hoạt — chỉ đọc phần chuyên gia đang hoạt động, có thể là 3–5GB mỗi token. Cùng băng thông, cùng cỗ máy, nhiều token mỗi giây hơn cả một bậc độ lớn, và mô hình lại mạnh hơn nhiều.

128GB bộ nhớ tương đối chậm gần như là hình dạng hoàn hảo cho lớp mô hình đó: đủ dung lượng để chứa mọi chuyên gia, và số byte đọc mỗi token đủ thấp để trần băng thông không còn siết. Nếu bạn mua một trong hai máy, hãy mua để chạy MoE. Các mô hình dense cỡ 70B về mặt kỹ thuật vẫn nạp được, và sẽ khiến bạn thất vọng trên cả hai.

Nơi chúng thật sự khác nhau: prefill

Giai đoạn sinh token bị giới hạn bởi bộ nhớ và hai máy gần như ngang nhau. Giai đoạn xử lý prompt thì bị giới hạn bởi năng lực tính toán, và ở đây chúng hoàn toàn không ngang nhau.

Prefill là lượt quét toàn bộ đầu vào trước khi token đầu tiên xuất hiện. Với một tin nhắn chat thì không đáng kể. Với RAG, nơi mỗi truy vấn kéo theo 8k–32k token ngữ cảnh được truy xuất — đúng loại tác vụ mà phần lớn khách hàng của tôi đang xây dựng — nó có thể chiếm phần lớn thời gian phản hồi mà người dùng cảm nhận được.

Ngân sách tính toán của DGX Spark ở một đẳng cấp khác. Nếu tác vụ của bạn liên tục đẩy ngữ cảnh dài qua máy, khoảng cách đó là khác biệt thực tế quan trọng nhất giữa hai cỗ máy này, và nó không hiện ra trong một bài benchmark token mỗi giây chạy trên prompt ngắn.

Phần tiếp theo giải thích vì sao khoảng cách lại lớn đến vậy — và vì sao đó không phải thứ AMD có thể khắc phục bằng một bản cập nhật driver.

FP4: khác biệt mang tính kiến trúc, không phải cải tiến nhỏ

Dòng “~1 PFLOP FP4” trông như một chi tiết trang trí trên bảng thông số. Không phải vậy. Đó là khoảng cách năng lực duy nhất giữa hai cỗ máy này mà bạn không thể lấp bằng phần mềm tốt hơn.

Nhân tensor thế hệ thứ năm của Blackwell hiện thực NVFP4 ngay trong phần cứng. Định dạng này là số thực 4-bit (1 bit dấu, 2 bit mũ, 1 bit phần định trị) mang theo hai tầng hệ số tỉ lệ: một hệ số FP8 cho mỗi micro-block 16 giá trị, cộng thêm một hệ số FP32 cho mỗi tensor. Phần cứng tự lo việc gom nhóm, chia tỉ lệ động và bản thân phép nhân ma trận 4-bit. Số liệu NVIDIA công bố đặt chi phí ở mức khoảng 4,5 bit cho mỗi trọng số — tức nhỏ hơn FP16 khoảng 3,5 lần và nhỏ hơn FP8 khoảng 1,8 lần — với mức suy giảm độ chính xác dưới 1% so với FP8 trên bảy bộ đánh giá với DeepSeek-R1.

Điều đó mang lại hai thứ tách biệt, và rất đáng để phân biệt rạch ròi:

Phần lợi về bộ nhớ thì ai cũng được hưởng. Ít byte hơn cho mỗi trọng số nghĩa là ít byte phải đọc hơn cho mỗi token, và điều đó nâng trần băng thông trong công thức phía trên. Bất kỳ cỗ máy nào có thể lưu trọng số 4-bit đều được lợi, AMD cũng vậy.

Phần lợi về tính toán chỉ tồn tại ở nơi nhân tensor thật sự hiểu FP4. Và trên dòng RDNA của AMD thì không. Danh mục lệnh WMMA có FP16, BF16, INT8 và INT4 — không có dạng FP4 nào. Vì thế một mô hình 4-bit sẽ bị giải lượng tử ngược về FP16 trong một shader tiền xử lý trước khi phép nhân ma trận chạy, rơi đúng vào trần thông lượng của FP16. Trọng số thì nhỏ; phép tính thì không nhanh. Strix Halo là RDNA 3.5, còn cũ hơn một thế hệ nữa — nó ra đời trước cả khi FP8 xuất hiện trong tập lệnh đó.

Cũng cần công bằng với AMD: đây là khoảng trống của nhánh RDNA, không phải của cả công ty. Các sản phẩm CDNA cho trung tâm dữ liệu của họ có hỗ trợ nhân ma trận FP4 vi tỉ lệ ở mức phần cứng. Chỉ là nó không nằm trong con chip bạn đặt trên bàn làm việc.

Vậy tóm tắt trung thực là: FP4 thu hẹp khoảng cách tốc độ sinh token cho cả hai máy và nới rộng khoảng cách prefill một cách đáng kể. Nó rơi đúng vào nửa bị giới hạn bởi tính toán của tác vụ — chính là nửa mà tôi vừa nói là khác biệt thực tế lớn nhất giữa hai máy.

Điểm vướng là nó không miễn phí. Bạn cần mô hình tồn tại ở dạng NVFP4 (điều này ngày càng phổ biến — các checkpoint đã lượng tử sẵn được công bố, và llama.cpp đã có đường chạy FP4 gốc cho Blackwell) và một nền tảng phục vụ biết điều phối tới nó. Mảng này đang trưởng thành nhanh, nhưng “phần cứng hỗ trợ” và “hệ thống của bạn có dùng” vẫn là hai khẳng định khác nhau. Hãy kiểm tra khẳng định thứ hai trước khi trả tiền cho khẳng định thứ nhất.

Phục vụ nhiều hơn một người: vLLM giải quyết được gì và không giải quyết được gì

Mọi thứ ở trên đều giả định mỗi lần một yêu cầu. Phần lớn những người mua một trong hai cỗ máy này đều định hướng cả một nhóm nhỏ vào đó, và có một trực giác khá phổ biến rằng việc này gần như miễn phí: giai đoạn sinh token bị giới hạn bởi bộ nhớ, việc gộp lô chỉ đọc trọng số một lần cho mỗi bước rồi tính cho cả lô, nên mười người dùng đáng lẽ tốn xấp xỉ một người dùng. Trực giác đó đúng trên GPU trung tâm dữ liệu. Đó chính là chỗ cơ chế gộp lô liên tục và KV cache phân trang của vLLM tạo được danh tiếng.

Trên những cỗ máy này, điểm giao cắt đến sớm hơn nhiều so với kỳ vọng.

Chính hướng dẫn cho DGX Spark của vLLM nói về điều đó một cách thẳng thắn khác thường. Công thức khuyến nghị đặt --max-num-seqs 4, và lý do được nêu rõ: vượt quá khoảng bốn luồng sinh token đồng thời thì “chi phí băng thông trên mỗi token có thể lớn hơn lợi ích của việc gộp lô liên tục, và thời gian tới token đầu tiên tăng vọt”. Họ tóm lại rằng Spark “phù hợp với suy luận theo lô nhỏ hơn là phục vụ với mức đồng thời cao”.

Có ba yếu tố tạo nên cái trần đó:

Gộp lô là đánh đổi băng thông lấy năng lực tính toán. Đó là một món hời khi bạn dư tính toán. Một con chip trung tâm dữ liệu dư dả ở cả hai chiều, nên bạn có thể đẩy kích thước lô lên hàng chục trước khi phép tính trở thành giới hạn. Với 273 GB/s và ngân sách điện của máy để bàn, kích thước lô mà tại đó bạn bị giới hạn bởi tính toán là rất nhỏ.

MoE âm thầm chống lại bạn. MoE là lớp mô hình mà hai cỗ máy này làm tốt nhất — nhưng lợi thế của nó nằm ở chỗ một token chỉ kích hoạt vài chuyên gia. Thêm người dùng đồng thời thì token của họ định tuyến tới những chuyên gia khác nhau, nên tập hợp chuyên gia bị chạm tới trong mỗi bước phình ra, và số byte phải đọc mỗi bước cũng phình theo. Lợi thế băng thông bị bào mòn đúng vào lúc bạn thêm người. Đây không phải hiệu ứng hiếm gặp: công trình song song hóa chuyên gia quy mô lớn của NVIDIA tồn tại chính là để giải quyết nó, bằng cách trải chuyên gia ra nhiều GPU để gộp băng thông tổng. Trên một cỗ máy đơn lẻ thì chẳng có gì để gộp.

Tranh chấp ở prefill mới là thứ người dùng thật sự cảm nhận. Mỗi yêu cầu đồng thời đều cần xử lý prompt, prefill bị giới hạn bởi tính toán, và thời gian tới token đầu tiên là con số người ta cảm thấy là “chậm”. Với RAG, nơi mỗi truy vấn kéo theo 8k–32k token ngữ cảnh, đây là thứ xuống cấp đầu tiên khi tải tăng.

Đáng chú ý, số đo của vLLM cho thấy mức sử dụng KV cache dưới 5% trong các bài thử một người dùng và dưới 30% với lưu lượng demo theo lô nhỏ trên một mô hình MoE 120B NVFP4. Điều này rất đáng ngẫm: trên một cỗ máy 128GB bạn sẽ không cạn KV cache. Bạn sẽ cạn băng thông bộ nhớ trước. Dung lượng là thứ bạn bỏ tiền mua, và nó không phải thứ giới hạn bạn.

Phía AMD, đây là câu chuyện phần mềm chứ không phải phần cứng. vLLM là đường chạy hạng nhất, có tài liệu, có image chính thức trên Spark. Trên Strix Halo, gfx1151 chưa được ROCm hỗ trợ đầy đủ — chính container vLLM của AMD đã lỗi trên Ryzen AI Max+ với thông báo invalid device function, và cách chạy được là dùng các toolbox do cộng đồng vá cùng bản ROCm nightly. Vẫn có người chạy được. Họ cũng viết những câu như “hơn 8 ngày gỡ lỗi” và “bất ổn, dễ vỡ”. Trong khi đó llama.cpp — thứ chạy tốt trên đó — lại gộp lô yếu hơn vLLM.

Vậy nên nếu mục tiêu thật sự là phục vụ nhiều người dùng, khoảng cách đó quan trọng hơn nhiều so với 17 GB/s băng thông chênh lệch giữa hai máy.

Một đòn bẩy thật sự đáng dùng: cache tiền tố (prefix caching). Nếu người dùng của bạn dùng chung một system prompt hoặc truy vấn cùng một tập tài liệu, vLLM sẽ tái sử dụng phần tiền tố đã cache thay vì prefill lại cho từng yêu cầu. Với một nhóm cùng hướng vào một kho tài liệu RAG, điều này có thể quan trọng hơn mọi thiết lập khác trong danh sách trên.

Ghép nhiều máy: khi một chiếc là không đủ

Cả hai nền tảng đều cho phép ghép nhiều máy để chạy những mô hình không vừa trong 128GB. Cách làm của chúng rất khác nhau.

DGX Spark ghép đôi. Mỗi máy có sẵn card mạng thông minh ConnectX-7 và cổng QSFP. Nối hai máy bằng một sợi cáp 200GbE gắn trực tiếp là bạn có một kết nối RoCE (RDMA trên nền Ethernet) điểm-tới-điểm — NCCL chạy các phép collective thẳng qua đó, còn vLLM hoặc TensorRT-LLM chia mô hình bằng song song tensor. Tổng cộng 256GB, và tuyên bố nổi bật của NVIDIA cho cặp máy này là chạy Llama 3.1 405B ở FP4. Hai máy là cấu hình được hỗ trợ; vượt hơn thế vẫn đang là đề nghị lặp đi lặp lại trên chính diễn đàn của NVIDIA chứ chưa phải một tính năng đã xuất xưởng.

Strix Halo ghép cụm qua Ethernet thường. Không cần card mạng đặc biệt, không RDMA — chế độ RPC của llama.cpp chia mô hình ra các node ngay lúc nạp, và mỗi node mở bộ nhớ cùng năng lực tính toán của nó cho một máy điều phối. Chính bài hướng dẫn của AMD chạy một mô hình một nghìn tỷ tham số trên bốn máy Ryzen AI Max+, với 96GB VRAM dành riêng cho mỗi node — tổng cộng 384GB.

Giờ khi giá mỗi máy đã xích lại gần nhau, khác biệt đáng chú ý ở đây không còn là chi phí trên mỗi gigabyte nữa — bốn node tốn khoảng gấp đôi hai node, trên cả hai nền tảng. Nó là cái trần. Cụm được hỗ trợ của Spark dừng ở hai máy và 256GB; Strix Halo thì cứ thế đi tiếp chừng nào bạn còn mua thêm máy và còn chấp nhận kết nối Ethernet. Đổi lại, NVIDIA cho bạn kết nối liên máy tốt hơn nhiều và một nền tảng phân tán ở mức sẵn sàng cho sản xuất.

Nhưng đây mới là phần quan trọng hơn cả hai điều trên. Ghép máy không gộp băng thông bộ nhớ. Mỗi node vẫn đọc trọng số ở tốc độ riêng của nó, khoảng 256–273 GB/s. Thêm máy sẽ nâng trần về kích thước mô hình, mức đồng thời và dư địa KV cache — nó không làm một luồng phản hồi đơn lẻ chảy nhanh hơn. Một mô hình 405B trên hai chiếc Spark thì chạy được; và nó chạy chậm.

Vấn đề prefill còn cộng dồn thêm. Cũng trong bài hướng dẫn đó của AMD, thời gian tới token đầu tiên trên cụm bốn node là 90,5 giây với prompt 8k và 239 giây với prompt 16k — khi đã bật Flash Attention; không bật thì hết bộ nhớ. Đó là một cấu hình cực đoan và không phải điều bạn sẽ thấy với một mô hình bình thường trên một máy, nhưng nó cho thấy hình dạng của vấn đề: trên phần cứng không có phép nhân ma trận độ chính xác thấp ở mức gốc, thời gian nằm ở khâu xử lý prompt, và ghép cụm không sửa được điều đó.

Nếu bạn ghép máy để phục vụ một mô hình lớn hơn cho vài người, cả hai cách đều được. Nếu bạn ghép máy với hy vọng làm nó nhanh hơn, cả hai đều không.

Nơi chúng thật sự khác nhau: phần mềm

DGX Spark chạy CUDA. Mọi thứ đều hoạt động: vLLM, TensorRT-LLM, các container NIM, công cụ đo hiệu năng, mọi công cụ lượng tử hóa, mọi hướng dẫn viết ra trong một thập kỷ qua.

Strix Halo chạy ROCm và Vulkan. Hỗ trợ cho llama.cpp tốt và đang cải thiện; hệ sinh thái rộng hơn thì gập ghềnh hơn. Bạn sẽ gặp những chỗ cần giải pháp thay thế, và nên dự trù thời gian cho việc đó thay vì để nó làm mình bất ngờ.

Nếu bạn là doanh nghiệp đang cân nhắc, cách diễn đạt sắc nhất là: DGX Spark không thật sự là một máy chủ, nó là một máy phát triển có sự tương đồng với môi trường sản xuất. Lời chào hàng là những gì bạn xây trên đó sẽ chạy y nguyên trên phần cứng NVIDIA trong trung tâm dữ liệu hay trên đám mây, cùng container, cùng CUDA. Nếu lộ trình chuyển đổi đó nằm trong kế hoạch của bạn, khoản chênh giá mua về một thứ có thật.

Nếu nó không nằm trong kế hoạch, bạn đang trả tiền cho một con hào mà bạn sẽ không bao giờ băng qua.

Nơi Strix Halo lặng lẽ thắng

Nó là một chiếc máy tính bình thường. Nó chạy Windows, chạy IDE của bạn, chơi game được, và có mặt trong laptop, mini-PC lẫn máy để bàn nhỏ. Điện năng khoảng một nửa, và khi không phục vụ mô hình thì nó vẫn là một máy trạm 16 nhân thật sự nhanh.

DGX Spark là một thiết bị chuyên dụng. Nó làm tốt một việc và nó không phải cỗ máy bạn dùng hằng ngày.

Trước đây tính đa dụng ấy đi kèm một mức giảm giá lớn. Giờ khi khoảng cách giá gần như đã khép lại, luận điểm cho Strix Halo nằm ở những thứ tiền không mua lại được: nó là một cỗ máy đa dụng bạn còn dùng cho việc khác, nó chạy Windows, và nó là cái duy nhất trong hai cái mà bạn có thể mở rộng quá hai node. Đó là những lý do thật. Chỉ là chúng không còn là những lý do rẻ hơn nữa.

Điều tôi thật sự nói với khách hàng

Đừng mua cái nào nếu mô hình của bạn vừa trong 24–32GB. Một GPU rời sẽ nhanh hơn nhiều lần với chi phí thấp hơn. Dung lượng bạn không cần là cách phổ biến nhất để lãng phí ngân sách phần cứng — và đây là sai lầm tôi gặp thường xuyên nhất.

Hãy lên kế hoạch cho bốn luồng đồng thời, không phải bốn mươi. Cơ chế gộp lô liên tục của vLLM là thật và nó tạo ra khác biệt giữa phục vụ một người và phục vụ một nhóm nhỏ — nhưng chính công thức cho Spark của vLLM giới hạn --max-num-seqs ở mức 4, và đó là con số hợp lý để lập kế hoạch cho cả hai máy. Vài đồng nghiệp dùng chung một cỗ máy thì ổn. Cả một phòng ban thì không. Nếu bạn cần phục vụ hàng chục người dùng đồng thời với ngữ cảnh dài, lớp phần cứng này là công cụ sai và một GPU thuê mới là công cụ đúng.

Hãy mua DGX Spark nếu bạn đang phát triển hướng tới môi trường sản xuất chạy NVIDIA, hoặc tác vụ của bạn nặng về prefill, hoặc bạn định phục vụ vài người qua vLLM. Đường chạy FP4 gốc là luận điểm kỹ thuật mạnh nhất cho nó, và đó là thứ duy nhất ở đây mà phần mềm không thể san bằng. Khi khoảng cách giá gần như đã biến mất, đây là khuyến nghị mặc định cho phần lớn tác vụ phục vụ mô hình, theo cách mà một năm trước thì chưa phải vậy.

Hãy mua Strix Halo nếu bạn muốn một cỗ máy đồng thời là máy trạm thật sự hữu dụng, bạn thoải mái chạy mô hình MoE qua llama.cpp, hoặc bạn dự tính mở rộng quá hai node — điều mà cụm được hỗ trợ của Spark không làm được. Lưu ý rằng “nó rẻ hơn nhiều” phần lớn đã không còn nằm trong danh sách lý do.

Đừng mua cụm máy để mua tốc độ. Dù chọn bên nào, thêm node chỉ mua về dung lượng và mức đồng thời, không bao giờ là tốc độ sinh phản hồi đơn lẻ — trần băng thông nằm ở từng node trên cả hai nền tảng. Nếu có người trong ban lãnh đạo đang kỳ vọng một dàn máy ghép sẽ cho cảm giác nhanh hơn, hãy điều chỉnh kỳ vọng đó trước khi ký đơn mua hàng, đừng để sau.

Và hãy cân nhắc tạm thời chưa mua gì cả. Hãy thuê cấu hình tương đương trong một tháng, tìm hiểu xem quy trình của bạn thật sự đòi hỏi gì, rồi mới mua phần cứng dựa trên một con số đã đo được thay vì dựa trên bảng thông số. Đó cũng chính là lời khuyên tôi đã đưa ra về chi phí đám mây so với nội bộ, và 128GB bộ nhớ hợp nhất trên bàn làm việc không làm nó thay đổi.

Phần thú vị của cả hai cỗ máy không nằm ở điểm benchmark. Nó nằm ở chỗ một lớp mô hình mà hai năm trước cần đến cả trung tâm dữ liệu thì nay đã nằm gọn dưới gầm bàn với giá của một chiếc laptop. Chỉ là đừng nhầm lẫn giữa vừa và nhanh.