App của bạn không nên biết tên model
Một nền tảng LLM chạy tại chỗ, thiết kế sao cho đổi model là sửa config chứ không phải viết lại. Topology chúng tôi dùng trên phần cứng DGX, phép tính GPU đằng sau nó, và ranh giới duy nhất mà lớp trừu tượng không vượt qua được.
Câu hỏi đầu tiên gần như luôn là "nên chạy model nào?"
Câu hỏi hợp lý, nhưng là chỗ bắt đầu tệ. Model bạn chọn hôm nay có tuổi thọ tính bằng tháng. Phần cứng bên dưới nó thì khấu hao ba tới năm năm. Nếu câu trả lời cho "model nào" đã nướng cứng vào bốn mươi ứng dụng, bạn vừa ký cam kết viết lại cả bốn mươi cái đó mỗi lần câu trả lời thay đổi.
Nên chúng tôi thiết kế nền tảng sao cho chọn sai model là chuyện rẻ.
Một địa chỉ, mọi model
Toàn bộ kiến trúc treo trên đúng một quy tắc: mọi lớp đều nói OpenAI-compatible API, và ứng dụng chỉ gọi một endpoint duy nhất. Chúng không bao giờ biết tên model, số lượng GPU, hay địa chỉ IP.
Gateway là LiteLLM proxy đứng sau NGINX, và nó xứng đáng có mặt vì làm năm việc không hào nhoáng cùng lúc: routing, quota, rate limit, audit log, và load balancing giữa các node DGX. Nó cũng giữ đường failover, nên khi một model chết thì request rơi sang model dự phòng chứ không rơi vào trang lỗi.
Phía trên, access layer tách thành ba nhóm cần đối xử khác nhau. Nhân viên dùng Open WebUI để chat nội bộ, hỏi đáp tài liệu, và dùng chung thư viện prompt. Ứng dụng nghiệp vụ nhận một REST endpoint OpenAI-compatible cho mỗi team, thay thẳng vào chỗ của một API thương mại. Identity nằm cạnh cả hai, dùng Keycloak hoặc IdP sẵn có, cấp phiên SSO và phân quyền model theo group, thu hồi API key theo từng phòng ban.
Phía dưới, các node DGX chạy bốn workload chẳng liên quan gì tới nhau: một vLLM chính cho model lớn nhất mà VRAM cho phép, một vLLM thứ hai tinh chỉnh cho chat lưu lượng cao kèm multi-LoRA, TEI cho embedding và rerank, và LLaMA-Factory để fine-tune vào giờ thấp điểm.
Data plane nằm lại trong nhà, và với phần lớn tổ chức muốn dựng hệ này thì đó chính là lý do làm cả dự án. Qdrant giữ embedding tài liệu, PostgreSQL giữ lịch sử chat và key, MinIO giữ tài liệu gốc cùng model weight. Không có gì rời khỏi toà nhà.
Cái được thì hẹp nhưng có thật. Thêm một node DGX, nâng lên một model open-weight mới hơn, hay đổi quantisation từ FP8 sang FP4 đều là thay đổi cấu hình ở gateway. Không phải viết lại ứng dụng. Cùng một thiết kế đó phục vụ được một máy để bàn đơn lẻ hoặc cả một rack node tám GPU.
Model-agnostic không có nghĩa là hardware-agnostic
Đây là chỗ lớp trừu tượng hết miễn phí. Gateway giấu được model nào trả lời request. Nó không đẻ ra được VRAM. Vẫn phải có người quyết định chia GPU thế nào, và quyết định đó là số học chứ không phải gu thẩm mỹ.
Bốn GPU chạy tensor-parallel 4 gánh model tổng quát chính: 437 GB weight ở FP8, chừa lại khoảng 127 GB cho KV cache. Hai GPU nữa ở TP2 lo phần coding và agent. Một card đơn lẻ xử lý chat lưu lượng cao ở MXFP4, nhẹ tới mức còn dư khoảng 77 GB cho KV cache và mỗi team một LoRA adapter. Card cuối chia MIG thành bảy slice, và toàn bộ pipeline retrieval, cả embedding lẫn reranker, nằm gọn trên đó mà vẫn còn chỗ trống.
Cái cuối này hay làm người ta bất ngờ. Cụm RAG nghe có vẻ nặng ký về mặt kiến trúc thực ra chiếm đúng một phần tám cỗ máy.
Giờ tới phần quyết định chuyện này có chạy được hay không: cách đọc một con số throughput.
Một benchmark đã công bố của DGX Spark phục vụ 256 người dùng đồng thời báo cáo 695 token mỗi giây. Cũng lần chạy đó trả về 2,85 token mỗi giây cho mỗi người, chậm hơn tốc độ đọc. Cả hai con số đều đúng và chúng cách nhau 244 lần.
Số liệu vendor đưa lên tiêu đề gần như luôn là aggregate, và gần như luôn giả định 2:4 structured sparsity mà dense inference không chạm tới được. Cũng không hẳn là nói dối. Chúng chỉ đang trả lời một câu hỏi mà không ai bên mua sắm đang thực sự hỏi.
Nên chúng tôi sizing theo độ trễ trên mỗi người dùng ở mức đồng thời mục tiêu, và báo số compute theo dense. Cách này cho ra con số nhỏ hơn, kém hoành tráng hơn, và một hệ thống chạy đúng như bảng tính đã nói.
Ranh giới mà lớp trừu tượng không vượt qua được
Có đúng một chỗ câu chuyện "mọi thứ chỉ là cấu hình" bị gãy, và nên biết trước khi lên kế hoạch dựng nhiều node.
Một node DGX có hai mạng chứ không phải một. Bên trong chassis, NVLink và NVSwitch cho mỗi GPU một đường 1.800 GB/s tới mọi GPU khác, tổng 14,4 TB/s cho tám con. Fabric đó hàn chết trên HGX baseboard. Nó không phải một dòng trong báo giá để bạn chọn, và nó không ra khỏi được cái hộp. Giữa các chassis, InfiniBand hoặc Ethernet gánh tất cả, ở mức 800 GB/s cho cả node.
Vẽ đúng tỉ lệ thì đó là cú rơi 18 lần, và đấy là spec sheet đang nói hộ phía rộng rãi. Code đo thật cũng cho ra hình dạng tương tự: kernel MoE DeepEP của DeepSeek chuyển 726 GB/s giữa các expert trong cùng node và 90 GB/s giữa các node, tức vách 8 lần trong production chứ không phải trên datasheet.
Một quy tắc thực dụng rơi ra từ đây. Pipeline parallelism và expert parallelism có thể vượt ranh giới node. Tensor parallelism thì không. Một model bị chẻ theo tensor qua hai chassis sẽ dành cả đời chờ mắt xích chậm nhất hệ thống, và không cấu hình gateway nào cứu được.
Đáng lưu ý khi so báo giá: NVIDIA quảng cáo H200 là "10x ConnectX-7, 1 TB/s". Con số đó tính cả hai NIC dành cho storage và management, vốn không bao giờ chở lưu lượng GPU collective.
Tám tuần, bốn cổng nghiệm thu
Thứ tự thi công quan trọng ngang với thiết kế, chủ yếu vì hai thứ có thể phá nát tiến độ đều lộ ra ngay tuần đầu.
Tuần 1 là khảo sát và sizing: kiểm kê thiết bị và VRAM, xác minh điện, làm mát và mật độ rack, chốt use case ưu tiên cùng SLA, rồi chạy lại phép tính sizing trên số liệu thật. Cổng nghiệm thu là thiết kế phải được duyệt trước khi lắp bất cứ thứ gì.
Tuần 2 và 3 dựng nền tảng platform, cổng nghiệm thu là telemetry: metric GPU và alerting phải được kiểm chứng trước khi phục vụ một model nào. Tuần 4 và 5 đưa vLLM, gateway, Open WebUI kèm SSO và pipeline nạp tài liệu vào Qdrant lên chạy, cổng nghiệm thu là bài load test đạt SLA đã thống nhất. Tuần 6 tới 8 lo lần chạy LoRA đầu tiên, đánh giá A/B với model gốc, runbook và đào tạo vận hành. Cổng này mới là cổng thành thật: model đã tinh chỉnh phải thắng baseline, không thắng thì không lên.
Hai thứ nằm ngoài tầm kiểm soát của chúng tôi và quyết định ngày khởi động thật.
Điện và làm mát. Nếu thiết bị cần mật độ rack hoặc vòng làm mát bằng chất lỏng mà cơ sở hiện tại không cấp nổi, thì chuyện chỗ đặt máy là đường găng. Bắt đầu từ tuần 1, đừng để tới tuần 5.
Dữ liệu đã gán nhãn. Giai đoạn 4 không thể bắt đầu nếu thiếu. Nếu chưa có gì, tuần 1 phình thêm phần thiết kế label schema và quy trình annotation, và phần tinh chỉnh lùi lại.
Cả hai đều lộ ra trong buổi khảo sát, và không cái nào chặn giai đoạn 2 và 3, vốn vẫn giao được một nền tảng chạy được. Chính mệnh đề cuối đó làm tiến độ sống sót.
Hình dạng này thực ra mua được gì
Không phải hiệu năng. Gateway thêm một chặng, và chặng đó tốn vài mili giây so với một luồng token kéo dài hàng giây.
Cái nó mua được là quyền sai với giá rẻ. Sai model thì sửa một dòng config. Sai quantisation thì nạp lại với cờ khác. Sai công suất thì thêm node phía sau cùng một địa chỉ. Sai phân quyền phòng ban nào dùng model nào thì sửa một group trong IdP thay vì deploy lại ứng dụng.
Phương án còn lại không nhanh hơn. Nó chỉ là một hệ thống mà mỗi lỗi kể trên đều tốn một chu kỳ release, nhân với mọi team đã tích hợp.
Chọn model sau. Dựng đường nối trước.
Chúng tôi thiết kế và xây hạ tầng platform và AI kiểu như thế này theo hướng trọn gói, từ sizing tới bàn giao. Nếu bạn đang lên phạm vi cho một hệ tương tự và muốn thêm một cặp mắt soi vào topology, liên hệ với chúng tôi.
Có hệ thống cần xây?
Chúng tôi thiết kế và xây phần mềm cho doanh nghiệp đang lớn — trọn gói.
Gửi yêu cầu tư vấn