- Engine suy luận cục bộ chuyên cho DeepSeek V4 Flash được tối ưu cho GPU Apple Metal, là bản triển khai C thuần tập trung vào một mô hình duy nhất thay vì runner GGUF đa dụng
- DeepSeek V4 Flash có số lượng tham số hoạt động ít hơn nên cho tốc độ nhanh, đồng thời trong chế độ thinking tạo ra đoạn suy luận ngắn chỉ bằng khoảng 1/5 so với các mô hình khác
- Hỗ trợ cửa sổ ngữ cảnh 1 triệu token và KV cache nén cực mạnh, cho phép suy luận ngữ cảnh dài ngay cả trên máy cục bộ, đồng thời hỗ trợ lưu bền KV cache trên đĩa
- Tích hợp sẵn máy chủ HTTP API tương thích OpenAI và Anthropic, nên có thể kết nối ngay với nhiều coding agent như Claude Code, opencode, Pi
- Được xây dựng trên nền tảng của llama.cpp và hệ sinh thái GGML, đồng thời là dự án được phát triển với sự hỗ trợ mạnh mẽ về lập trình từ GPT 5.5
Tổng quan dự án và triết lý thiết kế
ds4.c là một engine suy luận native nhỏ gọn chuyên cho DeepSeek V4 Flash, không phải runner GGUF đa dụng hay wrapper của runtime khác- Đường thực thi cốt lõi là trình thực thi đồ thị Metal được chuyên biệt cho DeepSeek V4 Flash, kèm mã tải DS4 riêng, render prompt, trạng thái KV và phần kết nối API máy chủ
- Trong lĩnh vực suy luận cục bộ đã có nhiều dự án xuất sắc, nhưng vấn đề là sự chú ý bị phân tán khi các mô hình mới liên tục xuất hiện
- Dự án này cố ý tập trung vào một mô hình tại một thời điểm, đồng thời thực hiện cả xác minh vector chính thức (logits), kiểm thử ngữ cảnh dài và tích hợp agent
- Tầm nhìn cho suy luận cục bộ là: A) engine suy luận có kèm HTTP API + B) GGUF được tối ưu cho engine cụ thể + C) kiểm thử và xác minh thông qua triển khai coding agent, cả ba phải cùng hoạt động
- Chỉ dành cho Metal; có thể hỗ trợ CUDA trong tương lai nhưng chưa chắc chắn
- Đường CPU chỉ tồn tại để kiểm chứng tính đúng đắn, và hiện tại do lỗi triển khai bộ nhớ ảo của phiên bản macOS hiện nay, chạy mã CPU có thể gây crash kernel
- Dự án được phát triển với sự hỗ trợ mạnh mẽ từ GPT 5.5, còn con người dẫn dắt ý tưởng, kiểm thử và gỡ lỗi
Vì sao DeepSeek V4 Flash được tách thành engine riêng
- Có ít tham số hoạt động hơn nên cho tốc độ suy luận nhanh hơn
- Ở chế độ thinking, tạo ra đoạn suy luận ngắn chỉ bằng khoảng 1/5 so với các mô hình khác, và độ dài đoạn suy luận tỷ lệ với độ phức tạp của bài toán
- Trong những tình huống các mô hình khác gần như không thể dùng thực tế ở chế độ thinking, DeepSeek V4 Flash vẫn dùng được
- Hỗ trợ cửa sổ ngữ cảnh 1 triệu token
- Với quy mô 284B tham số, mô hình này biết nhiều thông tin hơn ở rìa tri thức so với các mô hình 27B và 35B
- Có thể thấy khác biệt qua các câu hỏi về chương trình TV tiếng Ý hoặc chính trị
- Chất lượng viết tiếng Anh và tiếng Ý ở mức mô hình cận-frontier
- KV cache được nén cực mạnh nên có thể suy luận ngữ cảnh dài trên máy tính cục bộ, đồng thời hỗ trợ lưu bền KV cache trên đĩa
- Nếu lượng tử hóa theo cách đặc biệt, mô hình vẫn chạy tốt ở lượng tử hóa 2 bit, nên có thể chạy trên MacBook RAM 128GB
- Dự kiến DeepSeek sẽ phát hành phiên bản cập nhật V4 Flash trong tương lai
Lời cảm ơn tới llama.cpp và GGML
- ds4.c không liên kết với GGML, nhưng tồn tại trên con đường mà dự án llama.cpp đã khai phá
- Kernel, định dạng lượng tử hóa, hệ sinh thái GGUF và tri thức kỹ thuật phần cứng của llama.cpp là tài liệu tham khảo thiết yếu
- Một số mã nguồn cấp độ source được giữ lại hoặc áp dụng theo giấy phép MIT: layout và bảng GGUF quant, logic CPU quant/dot, một số Metal kernel cụ thể, v.v.
- Giữ nguyên thông báo bản quyền của tác giả GGML trong tệp LICENSE
Trọng số mô hình
- Chỉ hoạt động với DeepSeek V4 Flash GGUF được phát hành riêng cho dự án này; các tệp DeepSeek/GGUF tùy ý sẽ không tương thích
- Lượng tử hóa 2 bit áp dụng phương pháp lượng tử hóa bất đối xứng
- Chỉ lượng tử hóa các expert của MoE: up/gate dùng
IQ2_XXS, down dùng Q2_K
- Các thành phần còn lại như shared expert, projection, routing... không lượng tử hóa để đảm bảo chất lượng
- Dùng
./download_model.sh q2 để tải mô hình cho máy RAM 128GB, ./download_model.sh q4 cho máy RAM từ 256GB trở lên
- Tải từ Hugging Face (
antirez/deepseek-v4-gguf) và hỗ trợ tiếp tục tải dở bằng curl -C -
- Có thể tải GGUF hỗ trợ speculative decoding tùy chọn bằng
./download_model.sh mtp
- Đường MTP/speculative decoding hiện vẫn còn thử nghiệm và hiện chỉ đem lại mức cải thiện tốc độ nhẹ
Benchmark tốc độ
- Số liệu từ một lần chạy Metal CLI với thiết lập
--ctx 32768, --nothink, giải mã greedy và -n 256
- MacBook Pro M3 Max, 128GB (q2)
- Prompt ngắn: prefill 58.52 t/s, sinh 26.68 t/s
- Prompt 11709 token: prefill 250.11 t/s, sinh 21.47 t/s
- q4: N/A do thiếu bộ nhớ
- Mac Studio M3 Ultra, 512GB (q2)
- Prompt ngắn: prefill 84.43 t/s, sinh 36.86 t/s
- Prompt 11709 token: prefill 468.03 t/s, sinh 27.39 t/s
- Mac Studio M3 Ultra, 512GB (q4)
- Prompt ngắn: prefill 78.95 t/s, sinh 35.50 t/s
- Prompt 12018 token: prefill 448.82 t/s, sinh 26.62 t/s
Cách dùng CLI
- Dùng tùy chọn
-p để chạy prompt một lần, còn nếu chạy không có -p sẽ vào chế độ chat đa lượt tương tác
- CLI tương tác giữ transcript chat đã render cùng checkpoint KV Metal đang hoạt động, nên mỗi lượt sẽ mở rộng cuộc hội thoại trước đó
- Các lệnh hữu ích:
/help, /think, /think-max, /nothink, /ctx N, /read FILE, /quit
- Nhấn Ctrl+C để dừng quá trình sinh hiện tại và quay lại prompt
- Mặc định là chế độ thinking; có thể chuyển sang chế độ trả lời trực tiếp bằng
/nothink hoặc --nothink
- Có thể bật đường MTP speculative tùy chọn bằng
--mtp MTP.gguf --mtp-draft 2
- Chỉ hữu ích với giải mã greedy, và dùng confidence gate (
--mtp-margin) để tránh chấp nhận các đoạn chậm
Máy chủ
- Có thể chạy máy chủ HTTP cục bộ tương thích OpenAI/Anthropic
- Chỉ dành cho Metal và giữ một checkpoint đồ thị/KV có thể thay đổi trong bộ nhớ
- Nếu client stateless gửi lại phiên bản dài hơn của cùng prompt, có thể tái sử dụng tiền tố chung
- Việc phân tích request và socket chạy trên luồng client, nhưng bản thân quá trình suy luận được tuần tự hóa qua một worker Metal duy nhất
- Hiện máy chủ không batch nhiều request độc lập; các request đồng thời sẽ chờ theo thứ tự
-
Endpoint được hỗ trợ
GET /v1/models, GET /v1/models/deepseek-v4-flashPOST /v1/chat/completions, POST /v1/completions, POST /v1/messages
-
/v1/chat/completions (tương thích OpenAI)
- Hỗ trợ
messages, max_tokens/max_completion_tokens, temperature, top_p, top_k, min_p, seed, stream, stream_options.include_usage, tools, tool_choice
- Schema công cụ được render theo định dạng công cụ DSML của DeepSeek, và lời gọi công cụ DSML được sinh ra sẽ được chuyển ngược thành lời gọi công cụ OpenAI
-
/v1/messages (tương thích Anthropic)
- Endpoint dành cho client kiểu Claude Code
- Hỗ trợ
system, messages, tools, tool_choice, max_tokens, temperature, top_p, top_k, stream, stop_sequences, điều khiển thinking
- Việc dùng công cụ được trả về dưới dạng khối
tool_use của Anthropic
- Cả hai API đều hỗ trợ SSE streaming; trong chế độ thinking, quá trình suy luận được stream theo dạng API native
Tích hợp client agent
- ds4-server có thể tích hợp với các coding agent cục bộ dùng chat completions tương thích OpenAI
- Khi chạy quant 2 bit (81GB) trên RAM 128GB, cửa sổ ngữ cảnh 100k~300k token là hợp lý
- Toàn bộ ngữ cảnh 1M token dùng khoảng 26GB bộ nhớ (riêng compressed indexer khoảng 22GB)
- Có thể tránh trần token bằng cách đặt giới hạn đầu ra
384000 (mô hình có thể sinh tối đa 384k token)
-
Tích hợp opencode
- Cấu hình bằng cách thêm mục provider và agent vào
~/.config/opencode/opencode.json
- Đặt
baseURL thành http://127.0.0.1:8000/v1
-
Tích hợp Pi
- Thêm cấu hình provider vào
~/.pi/agent/models.json
- Bao gồm các tùy chọn tương thích như định dạng thinking của DeepSeek, hỗ trợ reasoning effort, hỗ trợ streaming usage
- Có thể đặt làm mô hình mặc định trong
~/.pi/agent/settings.json
-
Tích hợp Claude Code
- Dùng endpoint tương thích Anthropic và script wrapper
~/bin/claude-ds4 để đặt biến môi trường
- Đặt
ANTHROPIC_BASE_URL về máy chủ cục bộ và đặt mọi biến model thành deepseek-v4-flash
- Claude Code ban đầu gửi một prompt lớn khoảng 25k token, nên bắt buộc phải bật
--kv-disk-dir
- Sau prefill tốn kém đầu tiên, KV cache trên đĩa sẽ tái sử dụng tiền tố đã lưu nên các phiên sau không cần xử lý lại toàn bộ prompt
Chế độ Thinking
- DeepSeek V4 Flash hỗ trợ ba chế độ: non-thinking, thinking và Think Max
- Mặc định của máy chủ là chế độ thinking
- Có thể yêu cầu Think Max bằng
reasoning_effort=max, nhưng chỉ áp dụng khi kích thước ngữ cảnh đủ lớn theo khuyến nghị của model card
- Với ngữ cảnh nhỏ hơn, hệ thống sẽ fallback về thinking thông thường
reasoning_effort=xhigh của OpenAI được ánh xạ sang thinking thông thường, không phải Think Max- Nếu cần trả lời trực tiếp, hãy dùng
thinking: {"type":"disabled"}, think:false, hoặc alias mô hình non-thinking như deepseek-chat
KV cache trên đĩa
- API chat/completion là stateless, nên client agent sẽ gửi lại toàn bộ cuộc hội thoại ở mỗi request
- ds4-server xử lý bằng cách so sánh luồng token đã render với tiền tố token được cache
- Checkpoint đang hoạt động trong bộ nhớ phục vụ phiên hiện tại
- KV cache trên đĩa là cơ chế giữ lại các tiền tố hữu ích sau khi chuyển phiên và sau khi khởi động lại máy chủ
- Hiện trong bộ nhớ chỉ có một KV cache live duy nhất; nếu một phiên không liên quan mới thay thế nó, checkpoint trước đó chỉ có thể tiếp tục mà không cần xử lý lại nếu đã được ghi vào KV cache trên đĩa
- Bật bằng
--kv-disk-dir và --kv-disk-space-mb
-
Khóa cache và cấu trúc tệp
- Khóa cache là băm SHA1 của đúng các token ID, không phải văn bản thô
- Mỗi token ID được băm dưới dạng số nguyên 32 bit little-endian, và tên tệp là
<sha1>.kv
- Ghi bằng I/O
read/write thông thường, không dùng mmap (để tránh thêm VM mapping vào tiến trình vốn đã map mô hình)
-
Bố cục tệp cache trên đĩa
- Header cố định KVC 48 byte: magic("KVC"), phiên bản, số bit quant của routed expert, lý do lưu, số token được cache, số lượt hit, kích thước ngữ cảnh, thời gian Unix tạo/lần dùng cuối, số byte payload phiên DS4
- Văn bản đã render: văn bản giải mã tokenizer từ tiền tố token đã cache (dùng để quan sát, không dùng làm khóa)
- Payload phiên DS4: bắt đầu bằng 13 trường u32 little-endian, gồm magic("DSV4"), phiên bản payload, kích thước ngữ cảnh, kích thước chunk prefill, dung lượng vòng KV, v.v.
- Lưu token ID tại checkpoint, logits float32 cho token kế tiếp, số hàng attention nén theo từng layer, hàng KV sliding window raw đang hoạt động, hàng KV của các layer nén và tensor compressor frontier, v.v.
-
Thời điểm lưu checkpoint
cold: sau khi prompt khởi đầu dài đạt đến tiền tố ổn định, trước khi sinhcontinued: khi prefill hoặc quá trình sinh tiến thêm một khoảng đã cấu hìnhevict: trước khi một request không liên quan thay thế phiên live trong bộ nhớshutdown: khi máy chủ tắt bình thường
- Khi lưu cold, hệ thống cắt bớt một hậu tố token nhỏ và căn theo ranh giới chunk prefill để tránh lỗi retokenize lệch ranh giới BPE trong các request tương lai
- Mặc định: tiền tố tối thiểu 512 token, cold save tối đa 30000 token, cắt 32 token ở đuôi, căn chunk 2048 token
- Mặc định, checkpoint có thể được tái sử dụng giữa biến thể routed-expert 2 bit và 4 bit nếu tiền tố token khớp nhau
- Có thể buộc chỉ tái sử dụng cùng lượng tử hóa bằng
--kv-cache-reject-different-quant
Backend
- Backend mặc định là Metal (
--metal)
- Cũng có đường CPU tham chiếu/gỡ lỗi (
--cpu) nhưng không phải mục tiêu production
- Máy chủ chỉ dành cho Metal, và phần triển khai tối ưu nằm trên đường đồ thị Metal
- Giấy phép MIT, triển khai bằng C/Objective-C/Metal
1 bình luận
Ý kiến trên Hacker News
Tôi đã thử dùng nó cùng Claude Code trên một codebase sẵn có, và có vẻ nó vẫn làm được việc dù là mô hình lượng tử hóa 2 bit
Xử lý prompt mất vài phút, nhưng lúc chỉnh sửa thực tế thì khá nhanh, hơn 20 token/giây
Với các tác vụ nhỏ, nó đã tìm hiểu code, áp dụng sửa đổi và viết test thành công, nhưng lại không sửa được một lỗi nhỏ mà tôi chỉ ra
Tệ hơn là trong lúc giải một vấn đề khác, nó đã ảo giác kéo vào cuộc trò chuyện về “The Duck” mà tôi đang nói song song. Có lẽ đó là một trong các ví dụ prompt khởi tạo của Claude Code
Trước đây tôi đã làm một thứ rất giống vậy cho mô hình Qwen3. Nó chỉ chạy Qwen3, chỉ hỗ trợ một số kiểu lượng tử hóa, nạp từ GGUF, và dùng phần suy luận được Claude tối ưu lặp đi lặp lại
Toàn bộ dự án chỉ cỡ vài file, nhỏ và dễ hiểu, nên tôi làm nó để sinh viên có thể thử thêm chiến lược giải mã hay những thứ như abliteration để học hỏi. Các framework nổi tiếng thì lớn và phức tạp, khó hack, còn các dự án giáo dục thường lại dừng ở những thứ cũ như GPT-2
Ban đầu chỉ là dự án giáo dục, nhưng rồi tôi cứ không ngừng nghĩ đến một ý tưởng. Nếu làm một engine suy luận siêu tối ưu hóa cho tổ hợp GPU+mô hình cụ thể thì sao? GPU đắt và ngày càng khó kiếm, nên nếu bỏ bớt đủ nhiều tầng trừu tượng và nhắm trực tiếp vào đúng phần cứng/mô hình thì có thể tối ưu được khá nhiều
Dù vậy, nếu mô hình lỗi thời thì sẽ phải làm lại từ đầu toàn bộ
Trên các nền tảng kém phổ biến hơn vẫn còn những cải thiện hiệu năng dễ đạt được, nhưng không còn nhiều dư địa để tạo ra một runtime siêu tối ưu cho riêng một dòng GPU rồi đạt kết quả vượt trội hẳn. Phần tính toán cốt lõi đã được xử lý bằng các kernel tối ưu hóa rất sâu cho từng GPU rồi
Cũng có các bản fork của llama.cpp tối ưu để chạy tốt hơn trên một số kiến trúc CPU, nhưng trừ khi những người bảo trì bất đồng quan điểm, còn không thì đưa các cải tiến đó upstream sẽ là cách dùng thời gian tốt hơn là làm một runtime riêng cho từng mô hình+GPU
https://codegolf.stackexchange.com/questions/215216/high-thr...
Liệu có thể dùng op-amp để xử lý phép nhân ma trận nặng tính toán không? Và liệu cách tiếp cận tương tự như vậy có thể hiệu quả hơn rất nhiều so với giới hạn của biểu diễn bit không?
Giờ khi AI hiện đại đã có thể làm cả tối ưu hóa kernel, tôi nghĩ nhiều người hơn nên tự xây suy luận tốt hơn cho phần cứng của mình
Tôi có một con W7900 cũ (RDNA3), ngoài 48GB VRAM thì các chỉ số như 123 FP16 TFLOPS/INT8 TOPS và băng thông bộ nhớ 864GB/s đều khá ổn. Nhưng hỗ trợ ROCm của AMD lẫn hỗ trợ llama.cpp đều nổi tiếng là rất tệ
Gần đây tôi bắt đầu tinh chỉnh một mô hình W8A8-INT8 để dùng chiếc card này làm endpoint agent/coding chuyên dụng. Tôi đã chạy khoảng 800 vòng lặp tự động trong vài ngày và thử nhiều mô hình frontier/SOTA khác nhau, trong đó Kimi K2.6 làm tốt bất ngờ. Kết quả là với Qwen3.6 MoE, prefill nhanh hơn 20% và decode nhanh hơn 50% so với con số tốt nhất của llama.cpp
Giờ tôi vẫn đang tiếp tục đào sâu tối ưu MTP và DFlash, kết quả khá khả quan, và tiếp theo có lẽ sẽ thử Gemma 4
Dù vậy, llama.cpp có thể không phải nhanh nhất nhưng chạy được hầu hết mô hình một cách ổn định. Có vẻ nó thiếu MTP và có vấn đề invalidation cache với các mô hình hybrid, nhưng ít nhất tôi biết cái gì chạy được
Các bộ suy luận dựa trên Python thì uv/venv, venv của tôi, môi trường hệ thống, Python và thư viện trộn lẫn vào nhau đến mức muốn biết rốt cuộc thứ gì đang chạy có khi còn cần agent hỗ trợ. Tôi biết đó là do kỹ năng hoặc lỗi người dùng, nhưng tôi không còn thời gian cho chuyện đó
Dù chưa hoàn hảo, cứ đưa nó lên GitHub hoặc Hugging Face thì các agent khác có thể bắt đầu từ đó thay vì từ con số 0. Tôi cũng đã làm vậy với Ling-2.6-flash (107B-A7B4 MoE), và đó là LLM lớn nhất tôi có thể chạy thực tế trên M2 Max, phần cứng khác tôi có cho LLM cục bộ
Dù MTP chưa hoạt động tốt, như vậy vẫn tốt hơn việc llama.cpp hiện tại hoàn toàn không chạy được Ling-2.6-flash. Thảo luận liên quan ở https://huggingface.co/inclusionAI/Ling-2.6-flash/discussion..., bản lượng tử hóa 4 bit ở https://huggingface.co/ljupco/Ling-2.6-flash-GGUF, và branch ở https://github.com/ljubomirj/llama.cpp/tree/LJ-Ling-2.6-flas...
Tôi nghĩ llama.cpp lẽ ra có thể hỗ trợ PC tốt hơn nhiều. Một phần chắc là vì hỗ trợ từ vendor kém, nhưng với ngần ấy người dùng mà vẫn ít thấy suy luận tối ưu hơn trên PC tiêu chuẩn thì khá bất ngờ
Thật sự rất ngầu. Tôi tò mò nếu ai đó tập trung tối ưu một mô hình mã nguồn mở duy nhất trong nhiều tháng thì kết quả sẽ ra sao
Không chỉ phục vụ suy luận mà còn cả tối ưu harness và workflow tùy biến, để xem có thể thu hẹp đến mức nào khoảng cách ở những điểm mà mô hình frontier có thể suy luận và rút ra được, còn mô hình mã nguồn mở thì vốn thiếu hụt do giới hạn về kích thước hay huấn luyện
Để vận hành Kimi 2.6 ở tốc độ token/giây tử tế tốn 20.000 USD mỗi tháng, trong khi nếu muốn bán số token đó có lãi thì chi phí phần cứng phải dưới 1.000 USD/tháng
Nếu bạn đang đặt cược năng lực của mình vào tương lai nơi các tỷ phú hào phóng bán token với giá bằng 1/10 đến 1/20 giá vốn, hoặc vào ảo tưởng rằng các mô hình mã nguồn mở đủ giỏi sẽ chạy trên phần cứng tiêu dùng, thì coi như đã xong rồi
Có một dữ liệu khá vui, thú vị và nói lên nhiều điều. MacBook M3 Max của tôi lên tới 50W điện năng khi DS4 tạo token ở tốc độ tối đa
Nếu DS4 Flash đạt đỉnh ở 50W và có 280B tham số, thì DS4 Pro 1,6T tham số có vào khoảng 300W không? GPT 5 và Opus mới nhất có lẽ cũng cỡ 500W
Khi tôi dùng Claude Code và mô hình cứ tự chạy lan man một mình, có thể coi là ở đâu đó trong một trung tâm dữ liệu đang đốt 500W chăng?
Tôi không thể đặt Mac Studio với tùy chọn lớn hơn 96GB RAM. M3 Ultra hay M4 Max cũng vậy. Không rõ có phải chỉ ở Úc không
Trong khi đó MacBook Pro lại có thể chọn 128GB trên Mac M5
https://www.apple.com/au/shop/buy-mac/mac-studio
Có thể Apple chọn cách khỏi định giá luôn thay vì đối mặt tranh cãi bị chê chặt chém hay phản ứng vì thiếu hàng
Họ đã bỏ tất cả cấu hình Mac Studio trên 96GB và cả Mac mini bản cơ bản. Cũng có tin đồn họ đang cân nhắc rút luôn cấu hình Neo cơ bản khỏi thị trường
Có vẻ đây là cách họ xử lý giới hạn công suất fab và nguồn cung RAM
Tôi không chắc có phải tôi đã bỏ lỡ một benchmark hay mục tiêu tạo động lực đơn giản nào đó không
Tôi đoán là nó nhanh hơn dùng toolchain thông thường, hoặc cho phép chạy mô hình lớn hơn và thông minh hơn, nhưng có vẻ chưa ghi rõ mức cải thiện hiện tại hay kỳ vọng cải thiện so với đường cơ sở đó là bao nhiêu
Tất nhiên nếu biết các giá trị so sánh liên quan thì vẫn có thể tự tính từ những con số được đưa ra
Rất ấn tượng. Tuy nhiên việc phải mất khoảng 4 phút mới bắt đầu phản hồi với đầu vào lớn trông khá lạ
Tôi không dùng LLM trên phần cứng Mac, nhưng điều này khá gây bất ngờ và có vẻ là trở ngại lớn cho sử dụng thực tế
Dù vậy, trong sử dụng thông thường thì lời giải thích về cache nghe hợp lý hơn nhiều. Claude Code thường có thể gửi một prompt khởi tạo lớn khoảng 25k token trước khi bắt đầu làm việc hữu ích, và nếu bật
--kv-disk-dirthì sau lần prefill đắt đỏ đầu tiên, disk KV cache sẽ tái sử dụng prefix đã lưu để không phải xử lý lại toàn bộ promptNhưng trên M3 Ultra thì tốc độ prefill gần 500 token/giây nên vẫn đủ thực dụng. M3 Max cần kiên nhẫn hơn một chút nhưng vẫn chạy tốt, và nếu dùng pi agent thì nó sẽ in ra quá trình suy nghĩ nên thay vì chờ bạn có thể đọc chain of thought không bị kiểm duyệt
Hôm qua tôi đã đăng lên X một video dùng nó trên M3 Max, và nó nhả token với tốc độ khá ổn
Trên MacBook, LLM lớn có tốc độ tạo token chấp nhận được, nhưng vấn đề là đọc ngữ cảnh
Không phải kiểu đọc tăng dần có dùng KV cache như trong một phiên chat, mà là khi phải đọc đầu vào lớn như dán một file lớn vào. Trường hợp đó có thể mất vài phút
Có lẽ vẫn còn cách khá xa so với trí tuệ gốc mà nhà cung cấp đám mây đưa ra
Nhưng dù sao nó cũng cho thấy rõ hơn tiềm năng của LLM cục bộ trong workflow kiểu agent
Có kiến trúc nào không phụ thuộc vào việc nhét lại toàn bộ lịch sử hội thoại mỗi lần không? Kiểu LLM hồi quy chẳng hạn?