Một kho lưu trữ dự án 900 trang thì dễ tải lên. Câu hỏi khó hơn là liệu mô hình có thể chỉ ra điều khoản, commit, hoặc điểm dữ liệu chính xác mà bạn cần hay không. Các trường hợp sử dụng cửa sổ ngữ cảnh 1M của DeepSeek V4.1 Flash có ý nghĩa khi nhiều nguồn liên quan phải được xem xét cùng nhau, chẳng hạn như một cơ sở mã, một kho tài liệu nghiên cứu, hoặc hồ sơ dự án nhiều năm. Cửa sổ lớn hơn giúp giảm nhu cầu chia nhỏ những tài liệu đó ngay từ đầu, trong khi việc kiểm tra bằng chứng vẫn quyết định liệu câu trả lời có đáng tin cậy hay không.
Các trường hợp phù hợp nhất là đánh giá mã nguồn xuyên tệp, tổng hợp nghiên cứu, so sánh chính sách, phân tích phản hồi, dòng thời gian dự án, và hồ sơ đa phương thức dài. DeepSeek liệt kê ngữ cảnh 1 triệu token, nhưng dung lượng đó không đảm bảo rằng mọi chi tiết sẽ được ghi nhớ chính xác. Hãy kiểm tra giới hạn của mô hình và API cho tuyến của bạn, sau đó kiểm tra tài liệu của riêng bạn trước khi dựa vào kết quả.
Những điểm chính
- Sử dụng cửa sổ một triệu token khi câu hỏi phụ thuộc vào mối quan hệ giữa nhiều nguồn liên quan.
- Yêu cầu tham chiếu tệp, phần, hoặc trang và tách bằng chứng trực tiếp khỏi suy luận.
- Bắt đầu với một bài kiểm tra đã biết đáp án và chỉ mở rộng ngữ cảnh khi nó cải thiện kết quả.
- Ước tính chi phí từ đầu vào, đầu ra, và cách xử lý bộ nhớ đệm, không chỉ từ giới hạn ngữ cảnh.
Cửa sổ ngữ cảnh 1 triệu token nghĩa là gì?
Cửa sổ ngữ cảnh là lượng thông tin mà một mô hình có thể xem xét trong một yêu cầu hoặc trạng thái hội thoại, bao gồm tài liệu được cung cấp và các hướng dẫn xung quanh. Trang định giá API hiện tại của DeepSeek liệt kê DeepSeek-V4.1-Flash với độ dài ngữ cảnh 1M và đầu ra tối đa 384K token. Đó là giới hạn do nhà cung cấp công bố; ứng dụng, điểm cuối, hoặc cấu hình yêu cầu của bạn có thể áp đặt giới hạn nhỏ hơn. ( Tài liệu API DeepSeek )
Token là các mảnh văn bản, không phải từ hay trang. Một kho lưu trữ nguồn chứa mã, bảng, đánh dấu, văn bản lặp lại, và bản quét có thể được token hóa rất khác so với văn xuôi sạch có cùng số trang. Đối với khối lượng công việc thực tế, hãy ước tính token bằng tokenizer hoặc báo cáo sử dụng cho API mà bạn sẽ gọi. Bao gồm hướng dẫn hệ thống, tên tệp, siêu dữ liệu, văn bản câu hỏi, và ngân sách trả lời trong ước tính của bạn.
Lợi ích thực tế là tính liên tục. Bạn có thể hỏi về các phụ thuộc giữa một số mô-đun hoặc mâu thuẫn giữa chính sách hiện hành và phụ lục của nó mà không cần tự tay ghép các bản tóm tắt trước. Đánh đổi là một lời nhắc rất lớn có thể chứa tài liệu không liên quan hoặc trùng lặp, mất nhiều thời gian xử lý hơn, và vẫn khiến việc truy xuất chính xác trở nên khó khăn hơn. Hãy coi “vừa với cửa sổ” là kiểm tra dung lượng, sau đó kiểm tra xem mô hình có thể tìm thấy các sự kiện mà nhiệm vụ của bạn cần hay không.
Các trường hợp sử dụng ngữ cảnh 1M tốt nhất của DeepSeek V4.1 Flash
Câu hỏi đúng không phải là “Tôi có thể tải lên mọi thứ không?” Mà là “Những nguồn nào phải được so sánh để trả lời điều này?” Sử dụng ngữ cảnh dài khi câu trả lời phụ thuộc vào mối liên kết giữa các tài liệu, và xác định cách bạn sẽ xác minh câu trả lời đó trước khi gửi toàn bộ kho lưu trữ.
| Trường hợp sử dụng | Tại sao ngữ cảnh dài hữu ích | Nội dung cần bao gồm | Điều cần xác minh |
|---|---|---|---|
| Đánh giá cơ sở mã lớn | Giao diện và quy ước trải rộng nhiều mô-đun | Mã nguồn liên quan, kiểm thử, ghi chú kiến trúc | Đường dẫn tệp, ký hiệu, bằng chứng kiểm thử |
| Tổng hợp nghiên cứu | Phương pháp và phát hiện cần so sánh song song | Bài báo, báo cáo, hạn chế | Nguồn và lưu ý của từng tuyên bố |
| So sánh hợp đồng hoặc chính sách | Định nghĩa và ngoại lệ lặp lại qua các phần | Phiên bản hiện tại và trước đó, phụ lục | Số điều khoản và từ ngữ chính xác |
| Phân tích phản hồi | Chủ đề xuất hiện qua nhiều bình luận | Phản hồi đã ẩn danh và quy tắc mã hóa | Trích dẫn đại diện và phương pháp đếm |
| Dòng thời gian lịch sử dự án | Quyết định thay đổi qua các biên bản cuộc họp | Biên bản, nhật ký quyết định, ghi chú phát hành | Ngày, người phụ trách, hồ sơ mâu thuẫn |
| Đánh giá sự cố dài | Nhật ký, phiếu, và phân tích sau sự cố giải thích các giai đoạn khác nhau | Khoảng thời gian liên quan và tài liệu sự cố | Dấu thời gian, nguồn sự kiện, sự không chắc chắn |
| Đánh giá tài liệu đa phương thức | Bằng chứng văn bản và hình ảnh có thể cần đọc cùng nhau | Hình ảnh được hỗ trợ và chú thích hoặc ngữ cảnh của chúng | Liệu điểm cuối có hỗ trợ loại phương tiện hay không |
Sử dụng ngữ cảnh tập trung cho câu hỏi cục bộ; mở rộng khi các nguồn cần kết nối, sau đó kiểm tra bằng chứng.
Đánh giá cơ sở mã lớn xuyên tệp
Ngữ cảnh một triệu token có thể giúp kỹ sư theo dõi một cấu trúc dữ liệu từ ranh giới API qua logic dịch vụ, lưu trữ, và kiểm thử. Nó hữu ích cho tóm tắt kiến trúc, tìm các mô-đun có khả năng bị ảnh hưởng, và phác thảo kế hoạch tái cấu trúc tôn trọng các quy ước được ghi lại ở nhiều nơi.
Cung cấp cho mô hình một ảnh chụp kho lưu trữ có giới hạn thay vì một bản kết xuất đĩa chưa lọc. Bao gồm các tệp nguồn liên quan đến thay đổi, các kiểm thử gần nhất, tệp kê khai phụ thuộc, và ghi chú kiến trúc. Loại trừ đầu ra build, phụ thuộc đi kèm, gói được tạo, và bản sao trùng lặp trừ khi câu hỏi liên quan đến chúng. Yêu cầu đường dẫn tệp và tên ký hiệu cho mọi phụ thuộc được đề xuất, cùng sự phân biệt giữa hành vi quan sát được và giả định.
Sử dụng đầu ra như một kế hoạch đánh giá. Xác nhận từng ký hiệu được trích dẫn tồn tại, kiểm tra các dòng được trích dẫn, và tự chạy các kiểm tra của dự án. Mô hình không nên tuyên bố kiểm thử đã vượt qua trừ khi một công cụ thực sự chạy chúng và trả về kết quả. Đối với lỗi cục bộ trong một hàm, ngữ cảnh nhỏ hơn thường nhanh hơn và dễ kiểm tra hơn.
Tổng hợp nghiên cứu xuyên các bài báo và báo cáo
Ngữ cảnh dài hữu ích khi các nghiên cứu sử dụng phương pháp, quần thể, thước đo, hoặc định nghĩa khác nhau. Yêu cầu một bảng so sánh với một hàng cho mỗi nguồn và các cột cho câu hỏi nghiên cứu, dữ liệu, phương pháp, kết quả, hạn chế, và mức độ liên quan đến câu hỏi của bạn. Giữ các tuyên bố ở cấp nguồn gắn với nguồn của chúng thay vì để một bản tóm tắt pha trộn xóa bỏ sự bất đồng.
Ví dụ, khi so sánh các đánh giá về một công cụ, hãy phân biệt kết quả điểm chuẩn với nghiên cứu thực địa và với diễn giải của tác giả. Yêu cầu mô hình đánh dấu các thước đo không tương thích thay vì xếp hạng các kết quả không thể so sánh. Sau đó mở các đoạn nguồn đằng sau những tuyên bố liên quan nhất đến quyết định. Tổng hợp là một bản đồ bằng chứng, không phải là thay thế cho việc kiểm tra các bài báo.
So sánh hợp đồng, chính sách, hoặc đặc tả dài
Hợp đồng và chính sách thường định nghĩa một thuật ngữ một lần và bổ sung điều kiện ở nơi khác. Cung cấp phiên bản có hiệu lực, sửa đổi, phụ lục, và bản thảo cũ liên quan cùng nhau có thể giúp làm nổi bật các định nghĩa đã thay đổi, tham chiếu chéo, điều kiện thiếu, và xung đột rõ ràng.
Yêu cầu phần hoặc điều khoản chính xác cho mỗi quan sát và một đoạn trích ngắn mà người đánh giá có thể định vị. Tách biệt khác biệt văn bản khỏi hậu quả có thể của chúng. Mô hình có thể giúp tổ chức đánh giá, nhưng giải thích pháp lý, quyết định tuân thủ, và thẩm quyền ký kết vẫn thuộc về những người có chuyên môn có thể tính đến thẩm quyền tài phán và bối cảnh.
Phân tích phản hồi khách hàng ở quy mô lớn
Một lượng lớn phản hồi có thể tiết lộ các yêu cầu và phản đối lặp lại qua các kênh hoặc khoảng thời gian. Cung cấp một mẫu xác định, loại bỏ thông tin cá nhân không cần thiết, và chỉ định một sơ đồ mã hóa như “ma sát khi bắt đầu,” “thiếu tích hợp,” hoặc “nhầm lẫn về giá.” Yêu cầu ví dụ đại diện và phản ví dụ, không chỉ là danh sách chủ đề.
Không trình bày tỷ lệ phần trăm chủ đề do mô hình tạo ra như thống kê khảo sát. Nếu bạn cần số lượng, hãy xác định đơn vị (tin nhắn, khách hàng, hoặc vấn đề), loại bỏ trùng lặp hồ sơ, áp dụng quy tắc gán nhãn nhất quán, và xác minh số lượng bằng một script có thể lặp lại hoặc mẫu được con người xem xét. Mô hình hữu ích cho việc đề xuất danh mục và tìm ví dụ; một phương pháp được ghi lại hỗ trợ các tuyên bố định lượng.
Xây dựng dòng thời gian từ tài liệu dự án
Đối với việc bàn giao hoặc phân tích sau dự án, bằng chứng liên quan có thể nằm rải rác trong biên bản cuộc họp, ghi chú phát hành, nhật ký quyết định, và phiếu. Yêu cầu một bảng theo thời gian với ngày, sự kiện, người phụ trách được nêu tên nếu có, vị trí nguồn, và độ tin cậy hoặc sự mơ hồ. Hướng dẫn mô hình giữ nguyên các ngày mâu thuẫn thay vì chọn một cách im lặng.
Một dòng thời gian hữu ích giúp đồng đội mới thấy điều gì đã được quyết định, khi nào một yêu cầu thay đổi, và tài liệu nào hỗ trợ mỗi sự kiện. Xác minh các chuyển đổi quan trọng dựa trên hồ sơ nguồn, đặc biệt khi một ghi chú được viết sau đó hoặc tóm tắt một cuộc họp thay vì ghi lại trực tiếp.
Đánh giá hồ sơ sự cố dài và tài liệu đa phương thức
Đánh giá sự cố có thể hưởng lợi từ việc giữ cảnh báo, ghi chú vận hành, phiếu, và phân tích sau sự cố trong một tập bằng chứng. Yêu cầu một chuỗi các sự kiện quan sát được và phân biệt rõ ràng dấu thời gian trong nhật ký với ước tính sau này trong ghi chú tường thuật. Điều này có thể làm cho lần xem xét đầu tiên mạch lạc hơn, trong khi kỹ sư trực vẫn kiểm tra hệ thống nguồn trước khi hành động.
Thông báo chính thức của DeepSeek cho biết V4.1-Flash đã hoạt động trên API của họ với hỗ trợ đa phương thức gốc. Các định dạng hình ảnh chính xác, phương thức yêu cầu, và giới hạn phụ thuộc vào điểm cuối và tích hợp, vì vậy hãy xác nhận những chi tiết đó trước khi giả định rằng ngân sách văn bản một triệu token cũng mô tả việc xử lý hình ảnh. ( Thông báo DeepSeek V4.1-Flash )
Khi nào một triệu token hữu ích, và khi nào nó thêm nhiễu?
Ngữ cảnh nhiều hơn hữu ích khi các nguồn cần được tham chiếu chéo. Một thay đổi mã liên quan đến giao diện dùng chung có thể yêu cầu một số mô-đun và kiểm thử. So sánh phiên bản cần cả hai phiên bản đầy đủ và phụ lục của chúng. Dòng thời gian dự án có thể cần hồ sơ trải rộng qua nhiều tháng.
Một lỗi cục bộ với dấu vết ngăn xếp rõ ràng có thể chỉ cần hàm, các trình gọi nó, và kiểm thử liên quan. Một câu hỏi yêu cầu một định nghĩa có thể chỉ cần phần có thẩm quyền. Đối với những nhiệm vụ đó, việc bao gồm toàn bộ kho lưu trữ làm tăng không gian tìm kiếm và có thể chôn vùi đoạn hữu ích.
Trước khi mở rộng lời nhắc, hãy loại bỏ các bản xuất lặp lại, bản thảo lỗi thời, thư mục không liên quan, văn bản mẫu, và hồ sơ ngoài khoảng thời gian của câu hỏi. Giữ một bản kê khai những gì bạn đã bao gồm và lý do. Nếu câu trả lời thay đổi khi bạn thêm một loạt lớn các tệp không liên quan, đó là dấu hiệu để thu hẹp tập nguồn và chạy lại bài kiểm tra.
Quy trình thực tế cho câu trả lời ngữ cảnh dài đáng tin cậy
Sử dụng một giao thức bằng chứng nhất quán để câu trả lời trôi chảy không bị nhầm với câu trả lời đã được xác minh. Đầu tiên dán nhãn các nguồn với tên tệp ổn định và, nếu có thể, số trang, tiêu đề, số dòng, ngày, hoặc mã định danh phiên bản. Giữ đủ ngữ cảnh xung quanh để diễn giải các đoạn trích một cách chính xác.
Tiếp theo, nêu một quyết định hoặc câu hỏi nghiên cứu. Chỉ định hình dạng đầu ra và các vị trí mà mô hình phải trích dẫn. Một lời nhắc có thể tái sử dụng là:
plaintext1Analyze only the supplied materials. For every factual claim, cite the source filename and the closest available section, page, line, or heading. Separate direct evidence from inference. If sources conflict or evidence is missing, say so. Do not fill gaps with assumptions. Return a concise answer, an evidence table, and a list of unresolved questions.
Đối với cơ sở mã, thêm: “Trích dẫn đường dẫn kho lưu trữ và tên hàm hoặc lớp. Trước khi đề xuất thay đổi, liệt kê các tệp bị ảnh hưởng và bằng chứng kiểm thử hỗ trợ đề xuất. Không nói rằng một kiểm thử đã chạy trừ khi kết quả của nó được bao gồm trong bằng chứng được cung cấp.”
Chuẩn bị nguồn, đặt câu hỏi có giới hạn, kiểm tra trích dẫn, và chỉ mở rộng để giải quyết khoảng trống.
Sau đó kiểm tra câu trả lời theo ba lượt. Kiểm tra xem mỗi trích dẫn có chỉ đến một vị trí thực hay không. Kiểm tra xem đoạn được trích dẫn có hỗ trợ tuyên bố hay không, thay vì chỉ đề cập đến chủ đề. Cuối cùng, xem xét các thiếu sót và xung đột bằng cách đặt câu hỏi tiếp theo có mục tiêu dựa trên cùng tập nguồn. Đối với các quyết định quan trọng, hãy để người đánh giá có chuyên môn đọc trực tiếp tài liệu nguồn.
Bản đồ bằng chứng quy trình ngữ cảnh dài
| Giai đoạn | Hành động | Giữ lại | Dấu hiệu dừng |
|---|---|---|---|
| 1. Chuẩn bị | Dán nhãn, loại trùng, và giới hạn phạm vi nguồn | Bản kê khai nguồn và phiên bản | Nguồn gốc không rõ hoặc bản sao cũ |
| 2. Hỏi | Đặt một câu hỏi và định dạng bằng chứng | Tên tệp và định vị trong câu trả lời | Yêu cầu rộng không có mục tiêu quyết định |
| 3. Kiểm tra | Mở các đoạn được trích dẫn và so sánh tuyên bố | Tuyên bố được hỗ trợ và khoảng trống rõ ràng | Trích dẫn không hỗ trợ tuyên bố |
| 4. Mở rộng | Chỉ thêm nguồn cần cho các liên kết chưa giải quyết | Cải thiện trên kiểm tra đã biết đáp án | Thêm đầu vào mà không có bằng chứng tốt hơn |
Cách kiểm tra liệu ngữ cảnh 1M có hữu ích cho nhiệm vụ của bạn hay không
Tạo một tập đánh giá nhỏ trước khi tải toàn bộ kho lưu trữ. Viết các câu hỏi mà bạn đã biết câu trả lời từ tài liệu nguồn. Đặt một số sự kiện gần đầu, một số ở giữa, và một số gần cuối. Thêm ít nhất một câu hỏi yêu cầu kết nối hai tài liệu và một câu hỏi không thể trả lời từ các nguồn được cung cấp.
Chạy các câu hỏi tương tự trên một tập con nhỏ hơn, có liên quan trước, sau đó tăng ngữ cảnh theo các bước đo lường. Ghi lại tính đúng đắn thực tế, độ chính xác của định vị, bằng chứng bị bỏ sót, tuyên bố không được hỗ trợ, từ chối trả lời câu hỏi không thể trả lời, độ trễ, và mức sử dụng token. Giữ lời nhắc và cài đặt giải mã ổn định để các thay đổi có thể diễn giải được. Lặp lại một câu hỏi nếu đầu ra thay đổi đáng kể giữa các lần chạy.
| Kiểm tra | Câu trả lời đạt yêu cầu cho thấy điều gì | Việc cần làm sau thất bại |
|---|---|---|
| Sự kiện đã biết ở vị trí đầu, giữa, cuối | Truy xuất xuyên suốt khoảng nguồn | Kiểm tra lập chỉ mục, nhãn tệp, và độ dài lời nhắc |
| Liên kết xuyên tài liệu | Bằng chứng có thể được nối giữa các nguồn | Yêu cầu cả hai trích dẫn, sau đó thu hẹp câu hỏi liên kết |
| Câu hỏi không thể trả lời | Mô hình có thể báo cáo bằng chứng thiếu | Thắt chặt “chỉ sử dụng nguồn được cung cấp” và kiểm tra lại |
| Kiểm tra trích dẫn | Định vị và đoạn trích hỗ trợ tuyên bố | Coi tuyên bố là chưa được xác minh cho đến khi được sửa |
| So sánh ngữ cảnh lớn hơn | Tài liệu thêm cải thiện nhiệm vụ mục tiêu | Loại bỏ nhiễu nếu độ chính xác hoặc độ trễ kém đi |
Chấm điểm truy xuất, hỗ trợ trích dẫn, thiếu sót, tuyên bố không được hỗ trợ, độ trễ, và sử dụng token.
Các báo cáo cộng đồng thì hỗn hợp và phụ thuộc vào nhiệm vụ. Một người dùng Reddit đã chia sẻ về sự gia tăng đặc thù của harness trong các đối số công cụ bị lỗi ở kích thước ngữ cảnh lớn hơn, trong khi những người bình luận mô tả công việc thành công ở số lượng token cao hơn trong các thiết lập khác. Đó là lý do hữu ích để đánh giá benchmark harness của riêng bạn, không phải bằng chứng cho một ngưỡng thất bại phổ quát. ( Thảo luận về ngữ cảnh DeepSeek trên Reddit )
Một cách mở rộng hợp lý là: xác thực lời nhắc trên một mẫu nhỏ, thêm các nhóm nguồn cần thiết cho câu hỏi xuyên tài liệu, sau đó kiểm tra một yêu cầu lớn đại diện. Giữ ngữ cảnh nhỏ nhất trả lời câu hỏi thực với bằng chứng đáng tin cậy. Điều này cũng làm cho việc so sánh độ trễ và chi phí dễ diễn giải hơn.
Giá và truy cập API DeepSeek V4.1 Flash
Tại Atlas Cloud, danh sách mô hình hiện hiển thị DeepSeek V4.1 Flash với ngữ cảnh 1M và mức giá $0.30 cho mỗi triệu token đầu vào, $1.20 cho mỗi triệu token đầu ra, và $0.03 cho mỗi triệu token đọc bộ nhớ đệm. Danh sách không hiển thị giảm giá cho mô hình này. Đây là mức giá của Atlas Cloud, khác với giá cao điểm và thấp điểm phụ thuộc thời gian của chính DeepSeek. Kiểm tra lại danh mục mô hình Atlas Cloud và trang giá mô hình trước khi xuất bản hoặc lập ngân sách vì giá có thể thay đổi.
Với mức giá được liệt kê, một yêu cầu có 100.000 token đầu vào không được lưu trong bộ nhớ đệm và 2.000 token đầu ra tốn khoảng $0.03 cho đầu vào cộng $0.0024 cho đầu ra, hoặc tổng $0.0324 trước bất kỳ khoản phí áp dụng nào khác. Nếu đầu vào được tính phí dưới dạng đọc bộ nhớ đệm, 100.000 token được lưu trong bộ nhớ đệm sẽ là $0.003 thay vào đó. Ví dụ giả định số lượng token và mức giá đó; đây không phải là báo giá cho một khối lượng công việc cụ thể. Toàn bộ dung lượng 1M không bị tính phí chỉ vì nó tồn tại. Việc tính phí tuân theo mức sử dụng và cách xử lý bộ nhớ đệm.
Đối với các nhóm muốn một điểm truy cập API duy nhất, trang mô hình DeepSeek V4.1 Flash cung cấp thông tin về mô hình và cách gọi. So sánh mức sử dụng token đo được và nhu cầu tích hợp của bạn với điểm cuối chính thức; tên mô hình, giới hạn, và giá có thể khác nhau tùy nhà cung cấp.
Câu hỏi thường gặp
Cửa sổ ngữ cảnh 1 triệu token có giống 1 triệu từ không?
Không. Token có thể là các phần của từ, dấu câu, đoạn mã, hoặc các đơn vị khác. Số lượng từ hoặc trang vừa với ngữ cảnh phụ thuộc vào tài liệu và cách token hóa của nó. Sử dụng số lượng token đo được thay vì chuyển đổi trang cố định.
DeepSeek V4.1 Flash có luôn sử dụng toàn bộ cửa sổ ngữ cảnh không?
Không. Một triệu token là thông số ngữ cảnh tối đa, không phải mục tiêu cho mọi yêu cầu. Một lời nhắc ngắn sử dụng ít hơn, và một giao diện hoặc tuyến API cụ thể có thể áp đặt giới hạn thấp hơn. Kiểm tra tài liệu điểm cuối và các trường sử dụng thực tế.
Ngữ cảnh 1M có đủ cho toàn bộ cơ sở mã không?
Nó có thể vừa với một số cơ sở mã theo số lượng token, nhưng điều đó không làm cho mọi tệp trở nên liên quan hoặc mọi câu trả lời đáng tin cậy. Bao gồm các tệp cần thiết cho câu hỏi, xác minh đường dẫn và ký hiệu được trích dẫn, và kiểm tra thay đổi bằng các kiểm tra thực tế của dự án.
Tôi có nên đặt mọi tài liệu có sẵn vào một lời nhắc không?
Chỉ khi các tài liệu liên quan đến cùng một câu hỏi. Bắt đầu từ bản kê khai nguồn, loại bỏ trùng lặp và tài liệu không liên quan, sau đó thêm nhiều hơn khi một bài kiểm tra xuyên tài liệu cần. Các trường hợp sử dụng cửa sổ ngữ cảnh 1M tốt nhất của DeepSeek V4.1 Flash được xác định bởi bằng chứng phải được so sánh, không phải bởi kích thước của kho lưu trữ.
