Tốc độ model nằm ở hậu trường

Tốc độ model nằm ở hậu trường

Gemma 4 nhanh hơn trong Ollama không chỉ là chuyện token/giây. Với builder, câu hỏi đúng là: bottleneck của agent đang nằm ở đâu?

“Chạy lại agent đi em, lần này chắc nhanh hơn.”

Minh, tech lead của một team SaaS ở Đà Nẵng, nói câu đó lúc 5 giờ chiều thứ Sáu. Cả team đang thử một coding agent nội bộ: đọc issue, sửa vài file TypeScript, chạy test, rồi mở PR nháp. Demo trên máy M-series nhìn khá mượt, nhưng khi giao task dài hơn một chút, agent bắt đầu có kiểu diễn chậm: nghĩ lâu, gõ lâu, gọi tool lâu, rồi lại nghĩ lâu.

Sáng thứ Hai, Minh thấy release mới: Gemma 4 trong Ollama 0.31 chạy nhanh hơn đáng kể trên Apple Silicon nhờ multi-token prediction. Cả Slack sáng đèn. Một bạn dev hỏi ngay: “Vậy mình đổi hết sang cái này chưa?”

Mình hiểu cảm giác đó. Mỗi lần có model mới, engine mới, benchmark mới, sân khấu lại bật đèn rất sáng. Nhưng phần quyết định có nên dùng hay không thường nằm sau cánh gà: workload của bạn đang nghẽn ở đâu, agent gọi model theo nhịp nào, và tốc độ thêm vào có biến thành trải nghiệm tốt hơn thật không.

Sơ đồ minh họa cho bài Tốc độ model nằm ở hậu trường

Sơ đồ tóm tắt ý chính của bài viết.

Thứ đang diễn ra: model không chỉ “mạnh hơn”, mà đang “đỡ chờ hơn”

Điểm đáng chú ý của bản cập nhật Ollama không phải là “Gemma 4 thông minh hơn”. Theo công bố, trên Apple Silicon, Gemma 4 trong Ollama 0.31 tạo token nhanh hơn gần 90% trung bình trên một benchmark coding-agent. Tính năng này bật mặc định và không đổi output của model.

Cơ chế nằm ở multi-token prediction, viết tắt là MTP — dự đoán nhiều token trước rồi để model chính xác nhận. Nếu ví model chính là diễn viên chính, thì draft model giống người nhắc thoại ở hậu trường: đề xuất vài câu tiếp theo thật nhanh, diễn viên chính chỉ cần kiểm tra và giữ phần đúng.

Điểm hay là code thường rất dễ đoán ở một số đoạn: dấu ngoặc đóng, tên biến lặp lại, boilerplate, import quen thuộc. Vì vậy, draft model có cơ hội đoán trúng nhiều hơn so với văn xuôi tự do. Với coding agent, chuyện này càng đáng tiền, vì agent không gọi model một lần rồi thôi. Nó đọc file, sửa file, chạy tool, xem lỗi, sửa tiếp. Mỗi vòng chờ ít hơn một chút, cả phiên làm việc sẽ bớt ì.

Nhưng đây là chỗ nhiều team dễ hiểu sai: token nhanh hơn không tự động đồng nghĩa task xong nhanh hơn.

Va chạm của team Minh: nhanh ở màn nào?

Team Minh có ba loại task:

  1. Sửa bug nhỏ: agent đọc 2-3 file, patch nhanh, chạy test.
  2. Refactor vừa: agent phải đi qua nhiều module, giữ logic cross-file.
  3. Tạo migration nội bộ: agent đọc spec, gọi tool, cập nhật schema, viết test, chạy lại nhiều lần.

Sau khi bật bản mới, task sửa bug nhỏ cảm giác “bốc” hơn rõ. Agent stream code nhanh, dev đỡ sốt ruột khi ngồi review. Nhưng với refactor vừa, thời gian tổng không giảm tương ứng, vì phần chậm lại nằm ở đọc repo, chạy test, và lặp tool. Với migration, có lúc model trả nhanh hơn nhưng agent vẫn kẹt ở I/O và test suite.

Hình dung thế này: một vở diễn có diễn viên nói thoại nhanh hơn, nhưng nếu đổi cảnh mất lâu, đạo cụ đưa nhầm, ánh đèn bật trễ, khán giả vẫn thấy vở diễn ì. Coding agent cũng vậy. Model generation chỉ là một cảnh trong cả vở.

Vì vậy, câu hỏi đúng không phải là “model nào mới nhất?”, mà là:

Trong vòng lặp agent của bạn, phần nào đang chiếm thời gian và phần nào làm dev mất niềm tin?

Đây là câu người đọc nên nghĩ khác sau bài này: release tốc độ không phải vé nâng cấp mặc định; nó là một tín hiệu để bạn soi lại bottleneck.

Bóc lớp kỹ thuật: MTP có ích khi xác suất đoán đúng cao

MTP nghe đơn giản, nhưng tradeoff không hề miễn phí. Draft length — số token được đoán trước mỗi lượt — nếu quá ít thì không ăn thua, quá nhiều thì phí công kiểm tra và có thể chậm hơn. Ollama nói phần này được tự điều chỉnh trong lúc chạy, tức builder không cần tự vặn cấu hình.

Với team làm production, chi tiết đó quan trọng hơn headline. Vì nếu phải ngồi tune tay từng máy, từng model, từng prompt, MTP sẽ thành một đạo cụ đẹp nhưng khó đưa lên sân khấu thật.

Có ba biến bạn nên nhìn:

| Biến | Vì sao ảnh hưởng |
|---|---|
| Workload predictability — độ dễ đoán của output | Code boilerplate, test fixture, JSON schema thường hưởng lợi hơn lập luận mở |
| Hardware path — đường chạy phần cứng | Ở đây điểm nhấn là Apple Silicon với MLX; đừng suy diễn y hệt sang mọi GPU/cloud |
| Agent loop shape — hình dạng vòng lặp agent | Nếu agent dành nhiều thời gian gọi tool hoặc đọc file, token nhanh hơn chỉ giải quyết một phần |

Ví dụ cụ thể: giả sử team bạn dùng local coding agent trên MacBook để xử lý các ticket “sửa UI theo pattern có sẵn”. Output thường là code lặp cấu trúc, component quen thuộc, test snapshot. MTP có đất diễn. Nhưng nếu agent chủ yếu phân tích một incident dài, đọc log, truy vấn database, rồi viết postmortem, phần generation có thể không phải nút thắt chính.

Framework gọn: chọn theo “cảnh nghẽn”, không chọn theo tiếng vỗ tay

Mình đề xuất một khung 4 cảnh cho builder khi nhìn các release model/tool gần đây.

1. Nghẽn ở generation latency

Dấu hiệu: dev ngồi nhìn token chảy chậm, agent đã có đủ context và tool result nhưng vẫn mất thời gian viết patch.

Lúc này, MTP kiểu Gemma 4 trên Ollama đáng thử, nhất là với coding task chạy local trên Apple Silicon. Bạn đo bằng thời gian hoàn thành từng vòng plan -> edit -> explain, không chỉ đo tokens/second.

2. Nghẽn ở context selection

Context window là vùng ngữ cảnh model giữ được trong một lượt xử lý. Model có cửa sổ lớn, như GLM-5.2 được quảng bá với 1M token, có thể hấp dẫn nếu bạn muốn nhét nhiều repo vào một phiên. Nhưng cửa sổ lớn không thay thế được việc chọn đúng thông tin.

Ở phía GitHub Copilot, hướng đáng học là context handling và model routing: đưa đúng phần việc cho đúng model, đúng lượng context. Với builder, đây là bài toán “ai được đứng dưới ánh đèn lúc nào”, không phải gom cả đoàn lên sân khấu.

3. Nghẽn ở edge/on-device

Nếu bạn cần agent chạy trên điện thoại, robot, thiết bị automation, một model nhỏ như LFM2.5-230M của Liquid AI có hướng đi riêng: footprint nhỏ, hỗ trợ nhiều runtime như llama.cpp, MLX, vLLM, SGLang, ONNX. Nó không nhằm thắng mọi bài reasoning, mà nhắm vào tool use và extraction trên thiết bị.

Quyết định ở đây là: bạn cần độ tự chủ tại thiết bị hay khả năng suy luận sâu? Hai thứ này thường kéo chi phí và kiến trúc theo hướng khác nhau.

4. Nghẽn ở storage/I/O

Có những agent không chậm vì model. Chúng chậm vì đọc dữ liệu, đồng bộ file, mount storage, hoặc pipeline Linux/cloud có I/O lắt nhắt. Nguồn Azure Files nhắc lại một điểm rất đời: workload hiện đại, nhất là AI và data-intensive workload, không chỉ cần compute. Shared storage, latency, throughput, cách mount vào Linux cũng có thể là nút cổ chai.

Nếu agent của bạn cứ phải chờ file, cache, artifact, log, thì đổi model nhanh hơn giống thay diễn viên chính trong khi cửa hậu trường vẫn kẹt.

Điều đáng giữ: benchmark phải giống việc bạn làm

Ollama chọn Aider polyglot benchmark vì nó chạy coding agent qua task lập trình thực tế hơn kiểu benchmark tổng hợp. Chi tiết này đáng giữ lại: đo trên vòng lặp agent, không đo mỗi prompt đơn lẻ.

Một bài test nhỏ cho team Minh có thể như sau:

# Ví dụ minh họa: chạy cùng một bộ task nội bộ
# Mỗi task lưu lại thời gian, số vòng tool, số lần test fail, và PR diff

agent run tasks/bugfix-01.md --model gemma4-old
agent run tasks/bugfix-01.md --model gemma4-ollama-031

agent run tasks/refactor-02.md --model gemma4-old
agent run tasks/refactor-02.md --model gemma4-ollama-031

Đừng chỉ ghi “nhanh hơn”. Hãy log tối thiểu:

Nếu output không đổi như công bố, bạn vẫn cần xác nhận ở workflow của mình: diff có ổn không, agent có lặp ít hơn không, dev có review dễ hơn không.

Điều nên bỏ qua: cuộc đua thông số không có ngữ cảnh

Có vài thứ dễ làm team lệch hướng:

Plot twist: nhiều khi cải thiện đáng giá nhất không nằm ở model mới, mà ở việc chia task đúng hơn. Với coding agent, một prompt “sửa toàn bộ repo” thường kém hơn ba bước rõ: tìm phạm vi, sửa tối thiểu, chạy test liên quan. Model nhanh giúp từng bước đỡ chờ, nhưng orchestration — cách điều phối nhiều bước và tool — mới quyết định agent có đi đúng đường hay không.

Nếu là mình, mình sẽ thử như thế nào?

Nếu team đang dùng Ollama trên Apple Silicon cho coding agent, mình sẽ không tranh luận trên Slack quá lâu. Mình sẽ dành một buổi chiều làm 5 việc:

  1. Chọn 6-10 task thật đã từng làm: bugfix, refactor nhỏ, thêm test, cập nhật config.
  2. Chạy baseline với bản hiện tại, lưu log và diff.
  3. Nâng Ollama 0.31, chạy lại cùng task với Gemma 4.
  4. Tách thời gian thành: model generation, tool call, test run, file I/O.
  5. Quyết định theo loại task nào hưởng lợi, không quyết định theo trung bình chung.

Nếu chỉ bugfix nhỏ nhanh hơn, dùng nó cho bugfix nhỏ. Nếu refactor không khác nhiều, đừng ép. Nếu test suite mới là thứ kéo chân, quay sang tối ưu pipeline. Builder giỏi không phải người chạy theo ánh đèn sáng nhất, mà là người biết cảnh nào đang thiếu đạo cụ.

Takeaway của mình: đừng hỏi model mới có nhanh không; hãy hỏi tốc độ đó rơi đúng chỗ đau của agent chưa. Nhanh mà sai chỗ thì cũng chỉ là chạy thật lực trong hậu trường rồi quên kéo màn.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo