Hướng dẫn API DeepSeek V4.1 Flash: Xây dựng tác nhân sửa lỗi giao diện

DeepSeek V4.1 Flash là gì?

DeepSeek cung cấp V4.1 Flash qua API dưới ID mô hình deepseek-flash. Mô hình nhận đầu vào hình ảnh, hỗ trợ cả chế độ suy nghĩ và không suy nghĩ, có cửa sổ ngữ cảnh 1 triệu token và có thể trả về tối đa 384K token thông qua Chat Completions và Responses API.

Bài tổng quan về DeepSeek V4.1 Flash của chúng tôi đề cập đến thời điểm ra mắt, kiến trúc và các benchmark. 

DeepSeek V4.1 Flash hoạt động như thế nào?

DeepSeek mô tả V4.1 Flash là một xương sống MoE 552 tỷ tham số, trong khi Hugging Face báo 763 tỷ tham số cho checkpoint đã công bố. Chênh lệch chủ yếu do bộ nhớ điều kiện Engram 196 tỷ tham số, cộng với bộ mã hóa và bộ chiếu thị giác, đều được cung cấp trong checkpoint nhưng nằm ngoài xương sống MoE.

Thiết kế Causal Encoder-Decoder tái sử dụng trạng thái bộ mã hóa đã lưu đệm, với 8B tham số hoạt động mỗi token khi xử lý đầu vào và 16B khi tạo đầu ra.

Có gì mới trong DeepSeek V4.1 Flash?

V4.1 Flash là mô hình đầu tiên trong họ kiến trúc V4.1 mới, với khả năng hiểu hình ảnh được tích hợp gốc. Vector nhúng hình ảnh và văn bản được huấn luyện chung ngay từ đầu giai đoạn tiền huấn luyện, thay vì bổ sung sau như ở bản thử nghiệm V4-Flash-Vision-Exp.

Responses API có trước V4.1 Flash; DeepSeek đã bổ sung hỗ trợ gốc trong đợt phát hành V4 trước đó. Các tên mô hình đã ngừng deepseek-v4-flash và deepseek-v4-flash-vision-exp giờ được chuyển hướng tới V4.1 Flash.

DeepSeek V4.1 Flash có giá bao nhiêu?

Giá của DeepSeek dựa trên giờ cao điểm, với mức ngoài giờ bằng 50% giờ cao điểm. Khi tôi chạy tác nhân, chi phí đầu vào được lưu đệm là $0,003 mỗi triệu token ngoài giờ và $0,006 giờ cao điểm, đầu vào không lưu đệm là $0,15 ngoài giờ và $0,30 giờ cao điểm, còn đầu ra là $0,60 ngoài giờ và $1,20 giờ cao điểm, theo trang giá của DeepSeek. 

Giờ cao điểm là 01:00–04:00 và 06:00–10:00 UTC, từ thứ Hai đến thứ Sáu, không tính các ngày nghỉ lễ công của Trung Quốc. Các khung giờ còn lại là ngoài giờ, và toàn bộ ngày nghỉ lễ công của Trung Quốc đều tính ngoài giờ.

Chúng ta sẽ xây dựng gì: Tác nhân sửa lỗi giao diện Launch Metrics

Nimbus Analytics Launch Metrics là một bảng điều khiển Flask cho tổng lượt truy cập, lượt đăng ký, tỷ lệ chuyển đổi, doanh thu và đăng ký hằng ngày. Tôi đã cài ba lỗi ở ba tệp và không nói cho tác nhân biết đó là gì. Mã nguồn và bảng điều khiển lỗi nằm trong kho GitHub này.

Bảng điều khiển lỗi cạnh thiết kế tham chiếu. Ảnh: Tác giả.

Ba lỗi cần loại bằng chứng khác nhau. Một lỗi xuất hiện trên ảnh chụp màn hình, một lỗi ảnh hưởng hành vi trình duyệt, và một lỗi làm pytest thất bại. Tác nhân không nhận danh sách lỗi.

Trước khi giao việc cho tác nhân, tôi định nghĩa thế nào là “đã sửa”: bộ pytest phải vượt qua, và một ảnh chụp mới phải khớp trực quan với ảnh tham chiếu. Ý kiến của mô hình là chưa đủ, nên trình chạy sẽ kiểm tra cả hai loại bằng chứng.

Cách vòng lặp sửa chữa hoạt động

Vòng lặp luân phiên giữa yêu cầu gửi tới mô hình và thực thi công cụ cục bộ. V4.1 Flash trả về phần suy luận, một thông điệp, hoặc lời gọi công cụ; Python chạy các công cụ được yêu cầu và thêm kết quả vào lịch sử. Vòng lặp dừng khi mô hình trả lời mà không gọi công cụ khác hoặc chạm giới hạn mười bốn lượt.

Vòng lặp sửa chữa nối mô hình, công cụ và trình duyệt. Ảnh: Tác giả.

Cách thiết lập API DeepSeek V4.1 Flash

Bạn sẽ cần Python 3.10 trở lên và khóa API DeepSeek có tín dụng. API của DeepSeek theo định dạng yêu cầu của OpenAI, nên dự án này dùng gói openai trong Python với base_url trỏ tới DeepSeek.

Tạo môi trường ảo và cài đặt các thành phần cần thiết cho dự án.

python3 -m venv .venv
source .venv/bin/activate
pip install openai flask playwright pytest python-dotenv requests streamlit
playwright install chromium

Tôi đã thử với openai 3.14.1, flask 3.1.3, và playwright 1.63.0. Lưu khóa trong tệp .env ở thư mục gốc dự án với DEEPSEEK_API_KEY=sk-... và nạp bằng python-dotenv. Nếu khóa của bạn đã hoạt động với Responses API, hãy bỏ qua khối mã sau; nếu không, yêu cầu này sẽ kiểm tra khóa và base URL.

from openai import OpenAI
import os
from dotenv import load_dotenv

load_dotenv()
client = OpenAI(api_key=os.environ["DEEPSEEK_API_KEY"], base_url="https://api.deepseek.com")

response = client.responses.create(model="deepseek-flash", input="Say hi in five words.")
print(response.output_text)

Nếu dòng in ra là một lời chào ngắn, khóa và base URL đang hoạt động.

Bước 1: Cho mô hình thấy trạng thái "đã sửa" trông như thế nào

Đầu vào đầu tiên của tác nhân gồm một ảnh chụp tham chiếu, một nhiệm vụ ngắn và URL trực tiếp. Đây là ảnh duy nhất được gửi trong thông điệp của người dùng. Mọi ảnh chụp sau đó đến từ công cụ.

Trình chạy gửi ảnh tham chiếu dưới dạng URL dữ liệu base64 trong mọi yêu cầu. DeepSeek khuyến nghị dùng Files API khi tái sử dụng ảnh. Một file_id giúp tránh gửi lại cùng dữ liệu ảnh mỗi lần.

Lấy phản ứng ban đầu trước khi cho phép thay đổi

Trong ảnh đính kèm, tôi hỏi mô hình sẽ kiểm tra gì trước tiên, nhưng chưa có công cụ nào. Điều này cho phép tôi xem kế hoạch của nó trước khi nó có thể chỉnh sửa. Phản hồi đề xuất liệt kê tệp dự án, lần theo biến CSS và chụp ảnh màn hình; tôi dùng reasoning: {"effort": "high"}, mức suy nghĩ mặc định của DeepSeek.

Bước 2: Cấp cho tác nhân các công cụ cần dùng

Tác nhân nhận bốn công cụ hàm và một công cụ tùy chỉnh. 

• list_files và read_file để kiểm tra dự án, cả hai đều bị giới hạn trong dashboard/ và tests/. 

• run_tests chạy pytest.

• capture_dashboard_screenshot khởi chạy Chromium ở chế độ headless thông qua Playwright.

Công cụ tùy chỉnh là apply_patch, được khai báo là {"type": "custom", "name": "apply_patch"} và được chấp nhận “vì tương thích với Codex.” Bất kỳ tên công cụ tùy chỉnh nào khác sẽ trả về lỗi 400, trong khi các loại dựng sẵn như tìm kiếm web và sử dụng máy tính sẽ bị bỏ qua im lặng.

Đối số của hàm đến dưới dạng văn bản JSON và được kiểm tra trước khi Python chạy. apply_patch đến với tư cách đầu vào của công cụ tùy chỉnh, nên mã xử lý riêng và kiểm tra bản vá trước khi ghi tệp. Lỗi công cụ được trả về cho mô hình thay vì dừng vòng lặp.

Gửi lại ảnh chụp Playwright dưới dạng đầu ra công cụ

Khi capture_dashboard_screenshot chạy, kết quả của nó không được lưu ra đĩa. Python trả về nó như một phần input_image bên trong function_call_output. DeepSeek sau đó đọc ảnh chụp như một hình ảnh thay vì mô tả văn bản.

history.append({
    "type": "function_call_output",
    "call_id": item.call_id,
    "output": [{"type": "input_image", "image_url": f"data:image/png;base64,{png_b64}"}],
})

Tác nhân có thể vá CSS, chụp ảnh mới và kiểm tra xem các con số đã đọc được chưa.

Bước 3: Xây dựng vòng lặp tác nhân và tự quản lý lịch sử

Lịch sử được lưu trong một danh sách Python vì API không hỗ trợ previous_response_id hoặc hội thoại phía máy chủ. Chế độ suy nghĩ cũng yêu cầu mọi mục suy luận từ các lượt công cụ trước đó.

Quan trọng: Nếu đầu ra công cụ được chèn giữa hai lời gọi trong cùng một lượt, yêu cầu tiếp theo sẽ trả về lỗi 400. Hãy thêm mọi mục từ response.output theo đúng thứ tự, rồi chạy các công cụ và thêm kết quả của chúng.

Trình chạy giới hạn tác nhân trong mười bốn lượt và hai thư mục dashboard/ và tests/ . Nó không cung cấp quyền truy cập shell, kiểm tra đối số công cụ và dùng pytest để xác minh.

DeepSeek V4.1 Flash có hỗ trợ đầu ra có cấu trúc không?

Có. Qua Responses API, DeepSeek V4.1 Flash chấp nhận JSON Schema thông qua text.format. Chat Completions response_format hỗ trợ chế độ JSON nhưng không hỗ trợ schema. Sau khi vòng lặp dừng, yêu cầu cuối sẽ ghi lại lỗi, bản vá, kết quả kiểm thử, kết quả ảnh chụp và phương thức xác minh.

Dự án cũng bao gồm một ứng dụng Streamlit trong app_streamlit.py. Cùng một tác nhân chạy dưới dạng generator với stream=True, nên trang sẽ hiển thị văn bản suy luận và các lời gọi công cụ ngay khi đến. Thanh bên thay đổi mức nỗ lực suy luận và chi tiết hình ảnh.

Giao diện Streamlit truyền trực tiếp quá trình chạy của tác nhân. Video: Tác giả.

Bước 4: Chạy tác nhân sửa lỗi giao diện

Lần chạy trông như đã hoàn tất sau một bản vá, nhưng trang trực tiếp lại không đồng ý.

Tìm và sửa lỗi

Tác nhân dùng hai lượt đầu để quan sát trước khi chạm vào bất cứ thứ gì: lượt một liệt kê tệp và chụp ảnh cơ sở, lượt hai đọc app.py, index.html, style.css và tệp kiểm thử. 

Lượt ba chạy pytest, rồi lượt bốn áp dụng một bản vá sửa công thức chuyển đổi, thay đổi màu số liệu và khớp truy vấn JavaScript với ID canvas.

-    conversion_rate = data["conversions"] / data["signups"] * 100
+    conversion_rate = data["conversions"] / data["total_visitors"] * 100

Chạy kiểm thử ở lượt năm cho thấy cả năm đều vượt qua. Đây là lúc lần chạy không còn gọn gàng nữa. Mỗi ảnh chụp mới vẫn hiển thị tỷ lệ chuyển đổi 15% và biểu đồ trống.

Phát hiện sự cũ trạng thái hệ thống và khắc phục

Tác nhân xác nhận rằng các tệp trên đĩa đã chứa bản vá, thử lại ảnh chụp và thăm dò xem máy chủ có nạp các tệp Python và template đã đổi hay không. Hai kiểm tra độ mới tạm thời cũng không xuất hiện trên trang trực tiếp.

Đến lượt mười bốn, vòng lặp đã chạm ngân sách và xác định nguyên nhân: run_tests kiểm tra mã trên đĩa, trong khi ảnh chụp kiểm tra một tiến trình đang chạy với trạng thái cũ. Flask khởi động với debug=False, nên không có reloader tải lại mô-đun Python đã đổi, và tính năng tự động tải lại template cũng không bật.

Thay đổi CSS xuất hiện, trong khi giá trị sinh từ Python và biểu đồ dựa trên template vẫn cũ. Pytest nhập app.py từ đĩa, vì vậy kiểm thử xanh không đảm bảo trang mới.

Sau khi tôi khởi động lại Flask, bảng điều khiển khớp với ảnh tham chiếu. Mảnh ghép thiếu là một công cụ restart_server, không phải thêm bản vá mã.

Khởi động lại giúp các thay đổi đã vá hiển thị. Ảnh: Tác giả.

Tác nhân có sửa được bảng điều khiển không?

Có, tác nhân đã sửa bảng điều khiển trên đĩa. Nó chỉ thay đổi ba tệp lỗi, và pytest đi từ bốn lỗi sang năm kiểm thử đều vượt qua. Trang trực tiếp hiển thị mọi bản sửa sau khi Flask khởi động lại.

Bước 5: Đo lường mức sử dụng, lưu đệm và chi phí

Vì tác nhân gửi lại lịch sử của mình, các yêu cầu sau lặp lại nhiều phần đầu vào từ các lượt trước. DeepSeek kiểm tra tiền tố lặp lại này với bộ nhớ đệm tự động. Bộ nhớ đệm hoạt động theo nguyên tắc nỗ lực tối đa, nên các con số này chỉ áp dụng cho lần chạy này.

Qua mười bốn lượt sửa và yêu cầu báo cáo JSON cuối, API báo 156.724 token đầu vào, gồm 137.088 token được lưu đệm, tỷ lệ trúng 87%. Đầu ra là 11.497 token, gồm 9.362 token suy luận. Lần chạy rơi vào ngoài giờ, nên cả mười lăm yêu cầu chỉ tốn khoảng $0,0103.

Đầu ra suy luận là hạng mục chi phí lớn nhất. Ảnh: Tác giả.

Một codebase lớn hơn, nhiều ảnh chụp hơn hoặc ít lần trúng bộ nhớ đệm hơn sẽ làm thay đổi số token và chi phí.

Các giới hạn API DeepSeek V4.1 Flash cần biết

Ba giới hạn API quan trọng trước khi trình chạy này vượt ra ngoài bản demo.

• Không hỗ trợ phản hồi nền, nên các lượt dài sẽ chặn đến khi hoàn thành.

• parallel_tool_calls và max_tool_calls bị bỏ qua; gọi công cụ song song vẫn bật.

• Không hỗ trợ cắt tự động, nên các yêu cầu vượt quá giới hạn ngữ cảnh sẽ trả về lỗi 400.

Danh sách kiểm triển khai tác nhân DeepSeek V4.1 Flash

Trước khi dùng mẫu này trong dịch vụ thực tế, hãy đặt các điều khiển trong mã ứng dụng thay vì trong hướng dẫn cho mô hình.

• Áp đặt giới hạn lượt và chi phí, và cảnh báo khi đạt tới một trong hai
• Giới hạn quyền truy cập tệp và kiểm tra mọi đối số công cụ
• Các công cụ để khởi động lại và kiểm tra dịch vụ, để xác minh dựa trên mã hiện tại
• Ghi log mức sử dụng token, lời gọi công cụ, kết quả kiểm thử và trạng thái cuối

Khi nào nên dùng apply_patch so với công cụ hàm thông thường?

Dùng apply_patch khi một thay đổi cần cập nhật nhiều tệp cùng lúc, như trong trường hợp này. Chạy kiểm thử sau bản vá, vì một lệnh gọi lỗi có thể làm hỏng nhiều tệp.

Dùng read_file và write_file khi mỗi chỉnh sửa cần kiểm tra hoặc phê duyệt riêng. Chúng tốn nhiều lượt hơn, nhưng một chỉnh sửa lỗi chỉ ảnh hưởng một tệp tại một thời điểm.

Tổng kết

Vòng lặp sửa lỗi giao diện đã sửa cả ba lỗi trong một bản vá, nhưng lần chạy không hoàn toàn sạch sẽ. Pytest vượt qua trong khi Flask vẫn phục vụ mã Python và template cũ, nên tác nhân không thể xác nhận trang cuối cùng cho đến khi tôi khởi động lại máy chủ.

Tôi sẽ bổ sung công cụ restart_server và so sánh theo pixel trước khi thử nghiệm ứng dụng lớn hơn. Tôi sẽ giữ ranh giới tệp và giới hạn lượt, rồi coi pytest và so sánh ảnh chụp là hai kiểm tra riêng. Vượt qua một kiểm tra không bao giờ thay thế cho kiểm tra còn lại.