DeepInfer là gì? Engine suy luận của DeepSeek và những phần nó chưa phát hành

DeepInfer là framework suy luận mà DeepSeek công bố vào ngày 16 tháng 10 năm 2026 theo giấy phép Apache-2.0, và nó chỉ phục vụ đúng một mô hình: DeepSeek-V4.1-Flash, với DeepSeek-V4.1-Flash-1017 là checkpoint mặc định. Phạm vi chỉ một mô hình đó là điều đầu tiên cần hiểu, vì nó giải thích gần như mọi thứ còn lại về kho mã nguồn. Đây không phải là một framework phục vụ tổng quát tình cờ bao gồm cấu hình DeepSeek. Đây là luồng mã mà DeepSeek vận hành trong môi trường sản xuất, được cắt gọt còn những phần có thể khái quát hóa, và nó nói thẳng về phần đã bị cắt bỏ: danh sách của chính README về những gì một dịch vụ suy luận hoàn chỉnh cần, và những gì bản phát hành này không bao gồm, có nêu tên một hệ thống KV cache, phân rã VE/Prefill/Decode, và cân bằng tải giữa các bản sao song song dữ liệu. Những gì bạn nhận được là đường tính toán — kernel, song song hóa, giải mã suy đoán, lập lịch, đầu ra có cấu trúc. Những gì bạn không nhận được là lớp lưu trữ và định tuyến khiến đường tính toán trở nên rẻ khi vận hành ở quy mô lớn. DeepSeek nói rõ lý do: những thành phần đó gắn chặt với hạ tầng nội bộ, nên thiết kế được mô tả trong một bài viết đã công bố trong khi mã vẫn nằm trong nội bộ.

Thực sự có gì trong kho lưu trữ?

Danh sách tính năng được công bố giống như một chuyến tham quan các điểm nghẽn khi phục vụ một mô hình mixture-of-experts lớn. Có các thư viện kernel mà DeepSeek đã phát hành trước đây — FlashMLA cho attention, DeepGEMM cho phép nhân ma trận, DeepEP cho giao tiếp song song chuyên gia, cùng với TileKernels và DeepSelect. Có sơ đồ song song hóa: phần attention chạy dưới dạng song song dữ liệu với song song ngữ cảnh cân bằng, nửa MoE chạy dưới dạng song song chuyên gia với bộ cân bằng tải song song chuyên gia. Có DSpark, ngăn xếp giải mã suy đoán, với độ dài xác minh được lập lịch thay vì cố định. Có SWA bounded replay, cơ chế giúp bộ nhớ đệm attention cửa sổ trượt không buộc phải tính toán lại toàn bộ mỗi khi bỏ lỡ bộ nhớ đệm. Có lập lịch lô không đồng bộ, suy luận bất biến theo lô với lấy mẫu tất định, và đầu ra có cấu trúc bị ràng buộc bởi regex, JSON schema hoặc EBNF.

Điểm vào được cố ý giữ nhỏ. Sau khi đặt DEEPINFER_ACCELERATOR thành nvidia hoặc tương đương Ascend và chạy build.sh, kho lưu trữ cung cấp examples/offline_inference.py, tệp này chạy checkpoint mặc định từ đầu đến cuối. DEEPINFER_HF_MODEL_DIR trỏ nó đến một thư mục trọng số khác. Các benchmark đã công bố được đo trên bốn GPU SM100 cho prefill và 64 GPU SM100 cho decode, đây là quy mô triển khai mà engine được viết để phục vụ và không phải bản demo kiểu laptop.

README cũng nêu rõ mã nguồn đến từ đâu, điều đáng biết trước khi đọc nó. Ban đầu engine được xây dựng chủ yếu trên vLLM, với cảm hứng thiết kế lấy từ SGLang và TensorRT-LLM. Dòng dõi đó thể hiện trong cấu trúc — scheduler, giao diện paged attention và luồng lấy mẫu sẽ quen thuộc với bất kỳ ai đã đọc những dự án đó — và nó giải thích vì sao bản phát hành này là một fork của một serving stack chứ không phải một kiến trúc được viết từ đầu. Phần DeepSeek bổ sung là phần đặc trưng cho mô hình của chính họ: triển khai phân tách, song song chuyên gia diện rộng với bộ cân bằng của nó, phát lại cửa sổ trượt và DSpark.

Những gì nó không chứa, và vì sao điều đó lại quan trọng hơn

Ba mảnh còn thiếu không phải là những thiếu sót nhỏ. Mỗi mảnh là một hệ thống phải tồn tại trước khi engine phục vụ lưu lượng trong môi trường production, và mỗi mảnh đều tốn kém theo một cách khác nhau.

• Hệ thống bộ nhớ đệm KV. Tái sử dụng tiền tố là nơi phần lớn chi phí được tiết kiệm trong khối lượng công việc trò chuyện, vì một lần trúng bộ nhớ đệm sẽ thay thế một lần prefill. Không có kho lưu bộ nhớ đệm, mỗi yêu cầu đều tính toán lại lời nhắc của nó. Bài viết của chính DeepSeek mô tả kho mà nó sử dụng: một cụm 3FS chuyên dụng thay vì bộ nhớ máy chủ cục bộ, chính xác để bất kỳ máy prefill nào cũng có thể truy cập bất kỳ tiền tố nào và dung lượng bộ nhớ đệm có thể được mở rộng độc lập với năng lực tính toán.

• Tách rời VE/Prefill/Decode. README lưu ý rằng phần lớn chức năng phía engine đã có trong bản phát hành; thứ còn thiếu là triển khai. Tách rời vision encoder, prefill và decode cho phép bạn định cỡ từng giai đoạn theo điểm nghẽn riêng của nó và kiểm soát thời gian đến token đầu tiên tách biệt với thời gian giữa các token. Đó là một quyết định hạ tầng, không phải một cờ.

• Cân bằng tải trên các bản sao song song dữ liệu. DeepSeek vận hành bốn bộ cân bằng tải — prefill, decode, vision encoder và expert-parallel — và mô tả cả bốn trong bài viết. Không có logic định tuyến nào được phát hành. Nếu thiếu nó, một cụm bản sao chỉ tốt ngang với bất kỳ router nào bạn đặt phía trước, và một router round-robin đơn giản sẽ phá hủy tỷ lệ trúng bộ nhớ đệm mà kho lưu trữ được xây dựng để bảo vệ.

Đọc cùng nhau, phần thiếu sót cho bạn biết đây là loại sản phẩm gì. DeepInfer là một bản triển khai tham chiếu của đường tính toán, được công bố để công việc kernel và lập lịch có thể được kiểm tra và tái sử dụng, không phải một bản phân phối mà bạn cài đặt và trỏ lưu lượng truy cập vào.

Cổng phần cứng chính là bộ lọc thực sự.

DeepInfer nhắm tới NVIDIA SM100 và Huawei Ascend 950. Không có đường xử lý Ampere và cũng không có đường xử lý Hopper, điều này loại trừ phần lớn GPU trong hầu hết các cụm hiện nay. Phần còn lại của bộ công cụ cũng đặc thù tương tự: chỉ hỗ trợ Linux, GCC 13 trở lên, Python 3.12, CUDA 13 cho NVIDIA hoặc CANN 9.2 cho Ascend. Và hoàn toàn không có bản phát hành nào — kho lưu trữ có 0 bản phát hành được công bố tại thời điểm được đọc vào ngày 21 tháng 10 năm 2026, nên không có gì để tải xuống và không có gì để ghim phiên bản. Bạn clone nó và build nó dựa trên bộ công cụ của riêng bạn.

Sự kết hợp đó là bất thường đối với một bản phát hành mã nguồn mở được chú ý đến vậy, và tốt nhất nên hiểu đó là một tuyên bố chính xác về phạm vi chứ không phải một sơ suất. Các kernel trong kho lưu trữ được viết cho một tập lệnh cụ thể và một kết nối liên kết cụ thể; những con số trong README đến từ phần cứng đó. Việc chuyển đường tính toán xuống một thế hệ đúng là kiểu công việc mà cộng đồng làm nhanh còn một tổ chức kỹ thuật thì không thể hứa hẹn. Trong vòng vài ngày sau khi phát hành, một bản chuyển mã của bên thứ ba nhắm đến các linh kiện NVIDIA cũ hơn đã xuất hiện trên GitHub, một tín hiệu hữu ích về nhu cầu và hoàn toàn không phải tín hiệu về việc liệu các số liệu thông lượng đã công bố có giữ nguyên sau khi chuyển mã hay không.

Hình thức triển khai mà DeepSeek thực sự vận hành

Bài mô tả kiến trúc là nơi các giả định của repository trở nên rõ ràng. Hệ thống được tách rời thành bộ mã hóa thị giác, prefill và decode, cùng các nút lưu trữ chuyên dụng. Prefill sử dụng song song theo chuyên gia từ 2 đến 8 với song song dữ liệu tương ứng, chọn cấu hình nhỏ nhất mà HBM cho phép. Decode đi theo hướng ngược lại: song song theo chuyên gia và song song dữ liệu từ 64 đến 128, mà DeepSeek gọi là Wide-EP, sử dụng cấu hình lớn nhất mà các GPU sẵn có cho phép. Song song tensor và song song ngữ cảnh hoàn toàn không được sử dụng. Bộ mã hóa thị giác chạy một GPU mỗi instance, với khuyến nghị dùng các GPU rẻ hơn, vì bộ mã hóa không phải là nơi tiền đổ vào.

Triển khai nhỏ nhất hợp lý suy ra từ những con số đó. Một GPU prefill và một GPU decode sẽ chạy, và trên thực tế tỷ lệ giữa hai nhóm là khoảng một-một. Nhưng vì decode cần 64 GPU trở lên để có được lợi ích song song chuyên gia, đơn vị hiệu quả nhỏ nhất là 64 GPU prefill cộng 64 GPU decode. Đó là con số cần ghi nhớ khi đọc bất kỳ tuyên bố nào về hiệu quả của DeepInfer: các số liệu mô tả một triển khai 128 GPU, và một nửa trong đó là một giai đoạn.

Việc tách prefill và decode trên nhiều trung tâm dữ liệu là khả thi về mặt kỹ thuật vì {{1}}DeepSeek-V4.1-Flash{{/1}} nén KV cache của nó đáng kể, và triển khai của chính DeepSeek thực sự đặt các nút suy luận ở các trung tâm dữ liệu khác nhau nhưng liền kề. Ngân sách là khoảng 400 Gbps băng thông kết nối cho mỗi tám GPU, và bài viết thẳng thắn về chi phí độ tin cậy — cáp quang giữa các tòa nhà rất dễ bị cắt.

Tại sao decode lại được trải rộng đến vậy

Song song chuyên gia quy mô rộng là lựa chọn có hệ quả quan trọng nhất trong thiết kế, và rất dễ bị hiểu nhầm là một thủ thuật mở rộng quy mô. Trong một lớp mixture-of-experts, mỗi token chỉ chạm tới một số ít chuyên gia, nên chi phí của một bước giải mã bị chi phối bởi việc di chuyển trọng số chuyên gia và activation chứ không phải bởi cường độ số học. Việc trải các chuyên gia trên 64 hoặc 128 GPU làm giảm lưu lượng bộ nhớ mỗi bước mà mỗi GPU đóng góp, từ đó tăng số token mỗi giây nếu — và đây chính là điều kiện — tải giữa các chuyên gia vẫn đồng đều. Đó là mục đích của bộ cân bằng tải song song chuyên gia.

Các thiết lập của DeepSeek đủ cụ thể để sao chép. Đối với prefill, mỗi GPU giữ thêm bốn expert dư thừa ngoài những expert nó sở hữu, số liệu thống kê được thu thập trong cửa sổ 100 bước, và các expert được gán lại mỗi 1.000 bước, với trọng số được xáo trộn trong nhóm qua bộ nhớ chia sẻ NVLink. Mức mất cân bằng đo được — rank chậm nhất chia cho giá trị trung bình — là 1,074 cho cấu hình EP4/DP4 và 1,045 cho EP2/DP2. Đối với decode, các thiết lập được kéo dài ra: một expert dư thừa mỗi GPU, cửa sổ thống kê 1.000 bước, gán lại mỗi 10.000 bước và mức mất cân bằng đo được là 1,090. Điểm mấu chốt chính là sự khác biệt giữa hai trường hợp. Prefill gặp công việc dạng bùng nổ, không đồng nhất và cần cân bằng lại nhanh; decode gặp dòng công việc ổn định và có thể chấp nhận cửa sổ dài, nên nó hiếm khi cân bằng lại và gần như không tốn gì cho đặc quyền đó.

Phía định tuyến cũng mang đặc điểm tương tự. Các yêu cầu prefill được phân nhóm theo tổng độ dài ngữ cảnh thành bốn bậc — dưới 16K, 16 đến 64K, 64 đến 256K, và từ 256K trở lên — và các engine được gán vào các bậc theo tỷ phần nhu cầu tính toán của mỗi bậc trong vòng trước đó. Trong một GPU, kích thước chunk cho mỗi bước prefill không cố định: một mô hình chi phí bậc hai được khớp dự đoán một bước sẽ mất bao lâu với số token chuỗi và tiền tố đã được tính, và bộ lập lịch giải bài toán tìm chunk lớn nhất vừa với ngân sách 32,768 token trong thời gian còn lại. Bộ cân bằng decode cân bằng hai chiều cùng lúc, số lượng yêu cầu và tổng độ dài KV cache, gửi các yêu cầu ngắn đến các GPU có độ đồng thời thấp và cache dài, còn các yêu cầu dài đến các GPU có cache nhỏ. Tóm tắt của chính DeepSeek về việc tất cả những điều này mang lại bao nhiêu: khoảng 80 phần trăm so với một benchmark offline được cân bằng hoàn hảo.

Bộ nhớ đệm, và câu hỏi ba ngày

Bộ nhớ đệm KV nằm trên một cụm 3FS chuyên dụng, không nằm trong bộ nhớ của máy chủ cục bộ, và quyết định đó chi phối phần còn lại của thiết kế lưu trữ. Dữ liệu được lưu với mã hóa xóa 10+2, nên mỗi nhóm mã hóa chịu được hai lỗi nút đồng thời; một thao tác đọc sẽ gửi yêu cầu đến tất cả 11 nút trong nhóm và chỉ cần 10 phản hồi là đủ để giải mã. Một tiến trình thu gom rác chạy trên mọi nút lưu trữ và loại bỏ theo LRU khi vượt ngưỡng watermark. Máy chủ được khuyến nghị có 20 ổ thể rắn, mỗi ổ 30,73 TB, và duy trì tối thiểu 40 GB/s tốc độ đọc và 5 GB/s tốc độ ghi, được định cỡ để giữ khoảng 24 giờ dữ liệu cho mỗi máy chủ. Trên thực tế, cụm vận hành ở khoảng 14,4 TB bộ nhớ đệm logic trên mỗi GPU đang trực tuyến, với dung lượng vật lý lớn hơn mức đó.

Thời gian lưu trú là nơi sự đánh đổi trở nên rõ ràng. Không có logic hết hạn ở phía cache; TTL được đặt ở phía lưu trữ là ba ngày cho lưu lượng agent và bảy ngày cho lưu lượng chatbot, trên một cụm lưu trữ khoảng 100 petabyte bộ nhớ thể rắn. Sự phân tách này tồn tại vì lưu lượng chatbot có đuôi dài các lượt trúng cache nặng hơn nhiều — một lượng nhỏ cache được đọc nhiều lần, nên việc mất nó gây tổn thất tỷ lệ trúng cache tổng thể nhiều hơn mức mà khối lượng gợi ý. Chi phí đo được của DeepSeek khi rút thời gian lưu trú chatbot xuống ba ngày là 0,5 đến 1 phần trăm tỷ lệ trúng cache. Đó là một con số nhỏ nhưng lại đại diện cho một lượng lớn prefill được tính toán lại.

Attention cửa sổ trượt có một bộ nhớ đệm riêng với các quy tắc khác. Bộ nhớ đệm SWA không đi vào các khối phân trang; mỗi chuỗi chiếm một vị trí kích thước cố định trong bộ nhớ máy chủ, và đối với DeepSeek-V4.1-Flash, các lớp được lưu trữ là 20 lớp đầu tiên. Chỉ vùng đó tồn tại — 20 lớp x 134 token x 528 byte, tức 1.415.040 byte mỗi chuỗi ở định dạng MXFP8. Không có gì được đưa đến cụm lưu trữ; nó nằm trong bộ nhớ của máy đã tạo ra nó, với một thư mục trong bộ nhớ ghi lại máy nào giữ gì, và một lần truy cập trúng xuyên máy sẽ kéo nó trở lại qua một VLAN 400 Gbps.

Hai cơ chế tạo ra những con số nổi bật

Bounded replay là cơ chế thú vị hơn trong hai cơ chế vì nó biến một chi phí không giới hạn thành chi phí hằng số. Thông thường, một lần cache miss của cửa sổ trượt đồng nghĩa với việc tính lại cửa sổ từ đầu, và chi phí tăng theo độ dài ngữ cảnh và số lớp. Thay vào đó, DeepSeek chỉ tính lại 128 token gần nhất và cắt cửa sổ attention xuống đúng đoạn đó, tạo ra một SWA cache xấp xỉ với mức giá cố định. Ở phía encoder, điều này tách hoàn toàn độ dài hit của prefix-cache khỏi SWA cache: nếu thiếu SWA cache, 128 token cuối của tiền tố hit sẽ được replay trong khi block cache được tái sử dụng nguyên vẹn.

Phía decoder là nơi tiết kiệm lớn. Trong kiến trúc này, block cache của các lớp decoder được chiếu từ trạng thái ẩn của lớp encoder cuối, nên chỉ có SWA cache của decoder phải được tính cho từng lớp — và để tái tạo chính xác nó, sẽ phải đẩy 2.560 token cuối qua 20 lớp decoder trong mỗi lần prefill. Thay vào đó, phát lại 128 token và chỉ dùng kết quả cho decode thay vì để nó đi vào prefix cache gần như giảm một nửa tổng tính toán prefill. Chỉ thay đổi đó thôi đã đáng giá hơn phần lớn các tối ưu kernel, và đó là kiểu việc chỉ một nhóm sở hữu kiến trúc mô hình mới làm được.

Đóng góp của DSpark nhỏ hơn và thông thường hơn. Các token nháp có xác suất được chấp nhận khác nhau tùy theo yêu cầu và vị trí, vì vậy việc xác minh cố định năm bản nháp mỗi bước sẽ lãng phí tính toán cho những token sẽ bị từ chối. Một head độ tin cậy dự đoán tỷ lệ chấp nhận của từng token nháp, và bộ lập lịch sắp xếp các bản nháp theo lợi nhuận kỳ vọng rồi chỉ xác minh tiền tố tối đa hóa thông lượng. Trong môi trường production, mô hình nháp vẫn tạo ra năm token mỗi bước; số lượng được xác minh giảm từ 5,00 xuống khoảng từ 3,2 đến 4,4, tức giảm khoảng 30%, trong khi độ dài được chấp nhận gần như không đổi — 3,29 so với 3,20. Dựa trên dữ liệu benchmark EP64/DP64, điều đó tương đương với thông lượng tăng thêm 4 đến 7 phần trăm ở khoảng 60 chuỗi đồng thời mỗi rank. Ở đúng 60, thông lượng mỗi rank tăng từ 13.730 lên 14.466 token mỗi giây. Dưới khoảng 16 chuỗi đồng thời, kỹ thuật này gây lỗ ròng nhỏ, điều đáng biết trước khi áp dụng cho triển khai lưu lượng thấp.

Con số 155 nghìn tỷ có nghĩa là gì

Con số được trích dẫn nhiều nhất gắn với bản phát hành này là một cụm duy nhất phục vụ 155 nghìn tỷ token mỗi ngày, với tổng doanh thu 38 đô-la Mỹ mỗi GPU-giờ theo giá thấp điểm. Cả hai nửa đều do nhà cung cấp báo cáo và không cái nào là benchmark bạn có thể tái tạo, điều đó không làm chúng bớt thú vị — một con số doanh thu trên mỗi GPU-giờ là một kiểu tuyên bố thực sự khác với một con số thông lượng, vì nó gộp mức sử dụng, giá cả và tỷ lệ trúng bộ nhớ đệm vào một dòng. Đây cũng là con số dễ bị trích dẫn nhất mà thiếu các điều kiện kèm theo, nên những điều kiện đó đáng được ghi rõ: một cụm duy nhất, giá thấp điểm, doanh thu chứ không phải chi phí, và tổng hợp trên prefill, decode và vision encoder.

Hai tiết lộ nhỏ hơn thì hữu ích trực tiếp hơn. Kernel giải mã FlashMLA trong kho công khai thiếu một tối ưu hóa assembly được tinh chỉnh thủ công mà phiên bản nội bộ có, khiến nó chậm hơn 5 đến 10 phần trăm khi chạy riêng lẻ; DeepSeek nói rằng hiệu năng đầu-cuối chênh lệch nhiều nhất 5 phần trăm. Và mô hình nháp nội bộ cho giải mã suy đoán mới hơn bản đã công bố, với khác biệt hiệu năng được mô tả là nhỏ. Cả hai tuyên bố đặt ra kỳ vọng về việc bên thứ ba có thể đạt được bao nhiêu phần hiệu năng đã công bố bằng cách sao chép mã, và câu trả lời là: phần lớn, miễn là phần cứng khớp.

Kho lưu trữ, như hiện trạng

Ảnh chụp ở trên được thực hiện vào ngày 21 tháng 10 năm 2026 và cho thấy trang hiển thị 16,3k sao. API GitHub, được truy vấn cùng ngày, trả về 16.590 sao, 1.649 lượt fork và 176 issue đang mở, với issue bị tắt và thảo luận được chuyển hướng sang GitHub Discussions. Số sao kể từ đó vẫn tiếp tục tăng, nên hãy đọc mọi con số ở đây như một dấu mốc thời gian thay vì như một thuộc tính của mã nguồn. Lượng truy cập lớn như vậy trong chưa đầy một tuần nói lên nhiều hơn về sự quan tâm đến stack phục vụ của DeepSeek so với mức độ sẵn sàng của mã nguồn, và con số 0 bản phát hành nói lên phần còn lại.

Nếu bạn đang nghĩ đến việc tự mình chạy nó

Tóm tắt một cách trung thực là DeepInfer đáng để đọc kỹ và khó vận hành. Bốn câu hỏi sẽ cho bạn biết liệu nó có phù hợp hay không.

• Bạn có SM100 hay Ascend 950 không? Mọi thứ khác trong chuỗi công cụ đều phụ thuộc vào điều này. Nếu không có bộ tăng tốc phù hợp, các con số đã công bố sẽ không áp dụng được, và các bản port cộng đồng chưa được xác thực ở quy mô sản xuất.

• Bạn có thể chạy 64 GPU giải mã trong một miền truyền thông không? Song song hóa chuyên gia quy mô rộng không phải là một tối ưu hóa bạn có thể bỏ qua; đó là cấu hình mà đường giải mã được thiết kế xoay quanh. Dưới quy mô đó, bạn đang chạy một hệ thống khác với cùng tên.

• Bạn đã có sẵn prefix cache chưa? Nếu chưa, bạn đang so sánh đường tính toán của DeepInfer với một stack đối thủ vốn được trang bị sẵn tính năng này, và phép so sánh sẽ trông tệ hơn mức mà thiết kế xứng đáng.

• Bạn có đủ nguồn lực để tự viết lớp định tuyến không? Prefill bucketing, cân bằng decode và phân bổ lại expert được mô tả đủ kỹ để có thể tái triển khai, và việc tái triển khai chúng là công việc kéo dài hàng tuần mà kho mã nguồn không làm sẵn cho bạn.

Nếu bạn không muốn sở hữu bất kỳ mục nào ở trên

Với hầu hết các nhóm, câu hỏi thực tế không phải là làm thế nào để triển khai DeepSeek-V4.1-Flash mà là gọi nó ở đâu. Mô hình này có sẵn thông qua một API tương thích mà không cần xây dựng cụm 128 GPU hay triển khai lại bộ cân bằng tải, và đó chính là mô hình mà kiến trúc của nó đã được bài viết này mô tả — cùng cách xử lý ngữ cảnh, cùng hành vi đầu ra có cấu trúc, mà không cần đến công việc disaggregation.

Phép so sánh cần thực hiện không phải là engine nào nhanh hơn trên lý thuyết, vì những con số đã công bố là các phép đo do nhà cung cấp báo cáo trên phần cứng mà hầu hết độc giả không có. Mà là liệu khối lượng công việc có phải loại mà TTL bộ nhớ đệm 3 ngày và nhóm giải mã 64 GPU làm thay đổi giá, hay là loại mà một yêu cầu vài giây một lần qua API đơn giản là rẻ hơn bất kỳ thao tác nào được mô tả ở trên. Với trường hợp thứ hai — chiếm hầu hết các trường hợp — lượng DeepInfer nên dùng là không có, và lượng nên đọc là toàn bộ. Bắt đầu từ trang mô hình DeepSeek V4.1 Flash nếu bạn muốn điểm cuối; hãy bắt đầu từ README của kho lưu trữ nếu bạn muốn biết điểm cuối đang làm gì.