Router AI mới là bảng điểm thật

Router AI mới là bảng điểm thật

Perplexity đang đẩy local-cloud routing lên mặt bàn. Với builder, câu hỏi không phải model nào xịn hơn, mà bài nào nên chấm ở đâu.

Thứ Sáu tuần trước, một team fintech giả định của mình — gọi là team An — ngồi review demo agent nội bộ. Agent đọc file giao dịch, tóm tắt rủi ro, rồi gọi model cloud để viết báo cáo cho trưởng phòng.

Demo chạy mượt. Cả phòng gật gù. Đến đoạn log hiện ra một file CSV có thông tin khách hàng được gửi ra ngoài để “reasoning tốt hơn”, không khí chuyển từ lớp học vui vẻ sang giờ kiểm tra miệng đột xuất.

Không ai hỏi “model này thông minh cỡ nào” nữa. Câu hỏi mới là: ai quyết định dữ liệu nào được đi đâu?

Đó mới là điểm đáng bàn trong chuyện Perplexity giới thiệu hybrid local-server inference orchestrator cho Personal Computer. Không phải vì đây là một nhãn sản phẩm mới. Mà vì nó đẩy một lớp kiến trúc nhiều team đang né: routing inference theo ngữ cảnh, tức quyết định tác vụ nào chạy local, tác vụ nào lên cloud, và khi nào cần xin phép người dùng.

Sơ đồ minh họa cho bài Router AI mới là bảng điểm thật

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

Cái đang đổi: từ chọn model sang phân luồng bài làm

Trước đây, nhiều team build AI app theo kiểu khá thẳng: prompt vào, gọi model mạnh nhất có ngân sách chịu được, nhận output. Nếu cần riêng tư thì chuyển sang local model. Nếu cần chất lượng thì quay lại cloud model. Mỗi lần đổi là một lần tranh luận.

Perplexity đang đề xuất một cách khác: có một model nhỏ chạy trên máy người dùng, đóng vai trò phân loại tác vụ. Nó nhìn request, tách phần việc, rồi quyết định phần nào xử lý on-device, phần nào gửi lên frontier model trên cloud. Nếu dữ liệu nhạy cảm — ví dụ hồ sơ tài chính, thông tin sức khỏe, file cá nhân — hệ thống được thiết kế để giữ local hoặc hỏi quyền trước khi gửi đi.

Điểm hay không nằm ở chữ “hybrid”. Cloud-local hybrid đã được nói lâu rồi. Điểm hay là routing trở thành policy runtime, tức chính sách vận hành sống ngay trong luồng xử lý, thay vì nằm trong một file guideline bị bỏ quên sau buổi onboarding.

Ví dụ cụ thể: team An có một yêu cầu “phân tích 200 giao dịch bất thường và viết memo cho compliance”. Một hệ thống non-routing có thể đẩy toàn bộ bảng dữ liệu lên cloud. Một hệ thống có routing tốt sẽ tách ra:

Nói thẳng ra thì, đây không còn là bài toán “model nào giỏi nhất”. Đây là bài toán ra đề đúng cho từng học sinh trong lớp: bài dễ giao cho học sinh khá, bài olympic mới gọi học sinh chuyên, còn đề chứa thông tin riêng tư thì không được chuyền lung tung.

Bóc lớp kỹ thuật: router không được chỉ là if-else đẹp mã

Một inference orchestrator — lớp điều phối suy luận — nghe có vẻ chỉ cần vài rule: nếu file nhạy cảm thì local, nếu câu hỏi khó thì cloud. Nhưng đi vào production, “khó” và “nhạy cảm” không phải boolean sạch sẽ.

Builder nên nhìn router qua 5 tín hiệu:

| Tín hiệu | Câu hỏi cần trả lời | Quyết định gợi ý |
|---|---|---|
| Sensitivity | Có dữ liệu cá nhân, tài chính, y tế, code riêng không? | Local, redaction, hoặc xin phép |
| Capability need | Tác vụ cần reasoning sâu, multimodal, long context không? | Cloud frontier hoặc model chuyên |
| Latency budget | Người dùng đang chờ realtime hay batch? | Local nhanh, cloud nếu chấp nhận chờ |
| Cost ceiling | Mỗi request có trần chi phí không? | Model nhỏ trước, escalate khi cần |
| Auditability | Sau này có cần giải thích vì sao gửi đi không? | Log quyết định routing |

Phần cuối thường bị xem nhẹ. Nhưng với team nghiêm túc, router mà không có audit log thì giống bảng điểm không ghi tên học sinh: lúc phụ huynh hỏi, cả lớp nhìn nhau.

Perplexity cũng đang nối câu chuyện này với Computer và Deep Research: hệ thống có thể chia nhỏ câu hỏi nghiên cứu, route subtasks qua nhiều model, rồi trả về report, deck, dashboard. Với builder, bài học không phải “hãy dùng 20+ model”. Bài học là: workflow càng nhiều bước, routing càng phải có hợp đồng rõ ràng.

Hợp đồng đó nên trả lời được:

route_decision:
  task_type: "summarize_transactions"
  data_class: "sensitive_financial"
  allowed_targets: ["local_model"]
  escalation_requires: "user_permission"
  reason: "contains customer identifiers"
  fallback: "redact_then_cloud"

Không cần bắt đầu bằng YAML thật trong ngày đầu. Nhưng nếu team bạn không thể mô tả quyết định routing bằng vài dòng như vậy, khả năng cao hệ thống đang dựa vào cảm giác.

Va chạm thật: local chưa chắc rẻ, cloud chưa chắc nhanh

Hiểu lầm phổ biến là local đồng nghĩa với an toàn, rẻ, nhanh; cloud đồng nghĩa với mạnh, đắt, rủi ro. Đời không chia lớp gọn vậy.

Local model có thể tốt cho phân loại, tóm tắt ngắn, redaction, kiểm tra dữ liệu nhạy cảm. Nhưng nếu bạn bắt nó làm phân tích pháp lý dài, đọc bảng lớn, hoặc reasoning nhiều bước, nó có thể trả lời tự tin nhưng thiếu chiều sâu. Khi đó “tiết kiệm cloud cost” biến thành “tốn chi phí kiểm lỗi”.

Cloud model mạnh hơn, nhưng có ba vết xước:

  1. Data governance — quản trị dữ liệu: dữ liệu đi đâu, ai được phép, log ở đâu.
  2. Tail latency — độ trễ ở phần request chậm nhất: vài request lâu bất thường có thể phá trải nghiệm.
  3. Cost variance — chi phí dao động theo lượng token, tool call, retry.

Nhìn rộng hơn, NVIDIA Dynamo Snapshot nhắc một chuyện khác: trong Kubernetes, cold start — thời gian từ lúc worker inference khởi động đến khi phục vụ request — có thể kéo dài vì phải pull image, load weights, warm up CUDA kernels, chuẩn bị runtime. Nghĩa là ngay cả cloud/self-host cũng không tự động “sẵn sàng”. Nếu router đẩy việc sang một replica đang lạnh, người dùng vẫn ngồi chờ.

Ở phía model, MiniMax-M3 với context 1M token và các tối ưu serving, hay Zamba2-VL với kiến trúc hybrid Mamba2–Transformer giảm mạnh time-to-first-token theo công bố, đều cho thấy một xu hướng: model và serving engine đang được tối ưu theo workload cụ thể. Nhưng router mới là nơi quyết định workload đó có được đặt đúng chỗ hay không.

Framework cho builder: ma trận 4 cửa

Nếu là team đang build AI app, mình sẽ không bắt đầu bằng câu hỏi “có nên làm giống Perplexity không?”. Mình sẽ bắt đầu bằng ma trận 4 cửa này:

1. Local-only

Dùng khi dữ liệu cực nhạy, tác vụ đủ nhỏ, và chất lượng local chấp nhận được.

Ví dụ: phát hiện PII trong file, phân loại loại tài liệu, tóm tắt nháp một đoạn ngắn.

Rủi ro: model yếu quá làm sai bước đầu, kéo hỏng cả workflow.

2. Local-first, cloud-escalate

Local xử lý trước; nếu thiếu confidence hoặc cần reasoning sâu thì chuyển cloud sau khi redaction hoặc xin phép.

Đây là cửa đáng thử nhất cho nhiều team Việt Nam vì cân bằng được chi phí, riêng tư và chất lượng.

Rủi ro: phải định nghĩa được confidence signal — tín hiệu tự tin. Nếu chỉ hỏi model “mày có chắc không?”, câu trả lời thường không đáng tin.

3. Cloud-first with guardrails

Dùng cloud ngay, nhưng có lớp kiểm tra dữ liệu, policy, logging, và masking trước khi gửi.

Hợp với tác vụ cần model mạnh: deep research, tạo dashboard phức tạp, phân tích nhiều nguồn, multimodal.

Rủi ro: nếu guardrails chỉ nằm ở prompt, bạn đang giao nội quy lớp học cho học sinh tự đọc rồi tự giám sát.

4. Split execution

Tách workflow thành nhiều subtasks: phần nhạy cảm local, phần tổng quát cloud, phần retrieval qua search/tool riêng.

Đây là hướng gần với hybrid agentic inference. Mạnh, nhưng cũng dễ phình.

Rủi ro: orchestration — điều phối nhiều bước/tool/model — trở thành nguồn bug chính. Càng nhiều nhánh, càng cần trace rõ.

Một buổi chiều để kiểm tra hệ của bạn

Không cần đợi sản phẩm thương mại nào ra mắt mới học được bài này. Trong một buổi chiều, team bạn có thể làm một bản “bài tập về nhà” cho router hiện tại.

Bước 1: Lấy 30 request thật hoặc gần thật

Chọn từ log, ticket support, prompt nội bộ. Gắn nhãn thủ công:

Bước 2: Viết policy routing bản đầu

Ví dụ:

def route(task):
    if task.contains_pii and not task.user_approved_cloud:
        return "local_only"
    if task.requires_deep_reasoning and task.redacted:
        return "cloud_frontier"
    if task.is_classification_or_redaction:
        return "local_small_model"
    return "local_first_then_escalate"

Đây chỉ là khung minh họa, không phải production code. Mục tiêu là ép team nói rõ logic.

Bước 3: Log lý do, không chỉ log kết quả

Mỗi route nên có reason. Khi user hoặc compliance hỏi “vì sao request này lên cloud?”, bạn có câu trả lời.

Bước 4: Đo failure mode

Đừng chỉ đo accuracy cuối. Hãy đo:

Đây là chỗ nhiều demo đẹp bị trượt khi vào production.

Thứ nên giữ, thứ nên bỏ qua

Nên giữ lại từ câu chuyện Perplexity: routing là một sản phẩm kỹ thuật riêng, không phải đoạn glue code phụ. Nó cần policy, evaluation, logging, permission flow, và fallback.

Nên bỏ qua: cuộc đua ai tuyên bố “đầu tiên”, ai route qua nhiều model hơn, ai có tên gọi kêu hơn. Với team build thật, router tốt không phải router biết gọi nhiều nơi nhất. Router tốt là router biết không gọi khi không nên gọi.

Sau bài này, thứ mình muốn bạn nghĩ khác là: đừng chọn hạ tầng AI theo bảng xếp hạng model trước. Hãy vẽ bảng phân luồng tác vụ trước, rồi mới chọn model, cloud, local runtime, hay snapshot mechanism cho đúng.

Còn nếu router của bạn đang âm thầm gửi mọi bài kiểm tra lên “thầy giáo cloud” chấm hộ, ít nhất hãy đảm bảo học sinh đã ký giấy xin phép.

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

Nguồn tham khảo