OpenArchLabOpen Architecture — From Models to Systems

X · Cross-cutting

Theo dõi và tìm nguyên nhân request chậm

Hệ thống thu thập vết thực thi (traces), chỉ số (metrics) và dữ liệu profiler để định vị chính xác điểm nghẽn của request.

LESSON ID observe GROUP Kiến trúc Inference
Mục lục bài học

1Định nghĩa

Observability (quan sát và chẩn đoán) là hệ thống ghi nhận dữ liệu vận hành xuyên suốt đường đời của một request — từ lúc chạm gateway, xếp hàng ở scheduler, chạy prefill và decode cho tới khi trả xong token cuối. Mục tiêu là chỉ ra chính xác request bị chậm hay lỗi ở khâu nào thay vì chỉ nhìn thấy tổng thời gian phản hồi tăng cao.

Hệ thống kết hợp ba tầng dữ liệu: distributed traces gắn mã định danh (trace_id) để đo thời gian từng chặng của một request; metrics tổng hợp toàn cụm như thời gian chờ token đầu (TTFT), thời gian giữa các token (TPOT), độ dài hàng đợi và tỷ lệ lấp đầy KV cache; cùng GPU profiler thu chi tiết timeline của từng kernel và giao tiếp mạng khi cần mổ xẻ hiệu năng sâu.

Ví dụ đời thường: Observability giống như hệ thống mã vận đơn theo dõi bưu kiện kết hợp camera giám sát trong kho giao hàng. Khi khách báo hàng giao trễ, thay vì đoán mò, bạn tra mã vận đơn để biết ngay gói hàng bị ngâm 2 tiếng ở khâu chờ phân loại hay bị kẹt 30 phút trên xe tải, từ đó điều chỉnh đúng khâu đang gây tắc.

2Luồng

Sơ đồ luồng (4 bước)
  1. Request được gắn định danh

    Theo nó qua các service.

  2. Ghi các khoảng xử lý

    Chuẩn bị, queue, prefill, decode và stream.

  3. Đối chiếu timeline thiết bị

    Tìm phần compute, memory hoặc communication chậm.

  4. Thử một giả thuyết

    Đổi yếu tố nghi ngờ rồi đo lại.

Mã Mermaid
flowchart TD
  step1["Request được gắn định danh"]
  step2["Ghi các khoảng xử lý"]
  step3["Đối chiếu timeline thiết bị"]
  step4["Thử một giả thuyết"]
  step1 --> step2
  step2 --> step3
  step3 --> step4

3Giải pháp

Nối application traces với engine counters và lấy một số GPU timelines đại diện. PyTorch Profiler có thể ghi phép toán, shapes và memory; dùng labels cho từng pha.

Không profile mọi request nếu overhead quá lớn. Tránh label theo từng người dùng hoặc nguyên prompt gây nhiều chuỗi metrics và vấn đề dữ liệu.

Để phân rã TTFT thành thời gian chuẩn bị đầu vào, chờ chỗ chạy và prefill từ số đo theo từng bước, hãy chạy khối 11 (Telemetry & capacity feedback) trong Bài Lab tổng hợp.

4Profiling

  • Latency breakdown

    Đối chiếu các spans với tổng thời gian và kiểm tra phần bị thiếu.

  • Tail theo workload

    Tách context ngắn/dài và mức tải; trung bình chung có thể che nhóm bị chậm.

Mẹo đo lường: ghim số liệu trên workload thật, ghi cả p50/p95/p99 thay vì chỉ trung bình, và luôn ghi lại điều kiện chạy (batch, cache, đồng thời, phần cứng) trước và sau khi tối ưu. Số đo thiếu điều kiện chạy thì không so sánh được.

5Ví dụ

Token đầu chậm

Nếu queue tăng còn prefill không đổi, tối ưu kernel chưa xử lý được nguyên nhân.

Token đến không đều

Timeline có thể cho thấy host phát lệnh trễ hoặc collective dài giữa các bước decode.

6Thuật ngữ

Trace / span
Dấu vết của request gồm các khoảng công việc có thời điểm bắt đầu và kết thúc.
Percentile
Mức thời gian mà một tỷ lệ request nằm dưới; percentile 95 nghĩa là 95% request không chậm hơn mức đó.
Glossary (7)
Graphics Processing Unit
Bộ xử lý đồ họa, thường dùng cho phép tính tensor song song.
Kernel
Hàm tính toán chạy trên thiết bị; thường xử lý nhiều phần tử song song.
Runtime
Phần mềm quản lý việc thực thi, buffers và phụ thuộc giữa phép toán.
Latency
Thời gian chờ để nhận một kết quả hoặc một bước kết quả.
Overhead
Chi phí phụ như điều phối, chuyển đổi hoặc phát lệnh ngoài phép tính chính.
Host
Phần chương trình điều khiển thiết bị, thường chạy trên bộ xử lý trung tâm.
Context
Chuỗi token trước vị trí hiện tại mà model được phép sử dụng.

7Bài liên quan

8Nguồn