Liệu cơn sốt Token trên OpenRouter có phải là thước đo giá trị thực sự của một mô hình AI hay chỉ là một chỉ số dễ bị làm giả để đánh lừa thị trường?

I. Con số gây sốc và phản biện lối mòn tư duy phổ biến

Tháng 5 năm 2026, OpenRouter công bố rằng tổng lượng token throughput hàng tháng trên nền tảng đã vượt mốc 480 tỷ token/ngày, tăng hơn 340% so với cùng kỳ năm 2025. Con số này tương đương với việc mỗi giây, hệ thống xử lý hơn 5,5 triệu token. Những con số khổng lồ này ngay lập tức tạo ra một làn sóng phân tích, suy luận, và quan trọng nhất là những kết luận vội vàng từ cộng đồng developer lẫn nhà đầu tư.

Cơn sốt token trên OpenRouter không phải là một hiện tượng ngẫu nhiên. Nó phản ánh một nhu cầu thị trường thực sự: cần một con số duy nhất, dễ hiểu, để đánh giá và so sánh các mô hình AI lớn (Large Language Models - LLMs) với nhau. Tuy nhiên, chính sự đơn giản hóa quá mức này đã tạo ra hai lối mòn tư duy nguy hiểm mà phần lớn người dùng đang mắc phải.

1. Lối mòn thứ nhất: Lượng token cao đồng nghĩa với chất lượng mô hình cao

Đây là lối mòn phổ biến nhất và cũng tai hại nhất. Nhiều người nhìn vào bảng xếp hạng token volume trên OpenRouter, thấy mô hình A có lượng token gấp 3 lần mô hình B, và ngay lập tức kết luận rằng A tốt hơn B. Cách suy luận này sai ngay từ tiền đề.

Lượng token được xử lý qua OpenRouter phản ánh khối lượng sử dụng, không phải chất lượng đầu ra. Một mô hình rẻ tiền, tốc độ nhanh, nhưng chất lượng tầm thường hoàn toàn có thể đạt token volume cao hơn một mô hình đắt tiền nhưng tạo ra kết quả xuất sắc. Lý do rất đơn giản: các developer automation pipeline chạy hàng triệu request mỗi ngày để phục vụ các tác vụ lặp lại như phân loại dữ liệu, tạo nội dung hàng loạt, hay scraping có cấu trúc. Họ chọn mô hình rẻ nhất, nhanh nhất, không phải mô hình tốt nhất.

Nhìn bề ngoài, token volume giống như doanh thu của một quán phở bình dân. Quán phở bán 1.000 bát mỗi ngày với giá 30.000 đồng không có nghĩa là nó ngon hơn nhà hàng fine-dining bán 50 bát mỗi ngày với giá 2 triệu đồng. Sự khác biệt nằm ở đơn vị giá trị trên mỗi lần giao dịch, không phải ở tổng số giao dịch.

2. Lối mòn thứ hai: Token ranking phản ánh nhu cầu thị trường thực sự

Lối mòn này tinh vi hơn. Nó giả định rằng sự phân bố token trên OpenRouter là một phản xạ tự nhiên của thị trường tự do, nơi người dùng tự do lựa chọn và do đó kết quả phản ánh giá trị thực. Thực tế hoàn toàn khác.

OpenRouter là một trung gian phân phối (intermediary), không phải là một thị trường tự do thuần túy. Nền tảng này có các pricing incentive, default routing logic, và promotional placement ảnh hưởng trực tiếp đến cách người dùng lựa chọn mô hình. Khi một mô hình mới được đưa vào OpenRouter với mức giá giảm 50% trong tháng đầu tiên, lượng token của nó sẽ tăng vọt. Khi chương trình khuyến mãi kết thúc, token volume giảm mạnh. Chỉ số này phản ánh hành vi được điều kiện hóa bởi giá cả và chính sách, không phải phản ánh giá trị nội tại của mô hình.

Key Takeaway: Token volume trên OpenRouter là một phép đo về tần suất sử dụng trong một hệ sinh thái trung gian có điều kiện hóa, không phải là thước đo giá trị thực sự của mô hình AI. Nhầm lẫn hai khái niệm này là một lỗi logic nghiêm trọng, tương đương với việc nhầm lẫn giữa lượng truy cập website và doanh thu thực tế.

---

II. Phá rã vấn đề: Phân tích First Principles

Để hiểu bản chất của câu hỏi này, chúng ta cần loại bỏ hoàn toàn các lớp ý nghĩa đã được xây dựng chồng lên nhau bởi marketing, truyền thông, và các cuộc thảo luận trên mạng xã hội. Hãy trở về trạng thái nguyên thủy nhất.

1. Thực thể nguyên thủy thứ nhất: Token là gì ở cấp độ vật lý?

Một token là một đơn vị mã hóa văn bản (text encoding unit). Trong kiến trúc của các mô hình transformer, token là đơn vị nhỏ nhất mà mô hình xử lý. Một câu tiếng Anh 10 từ thường được mã hóa thành khoảng 13-15 token. Về mặt vật lý, mỗi token là một vector số có chiều (dimension) từ 768 đến 12.288 tùy thuộc vào kiến trúc mô hình.

Token không mang thông tin về chất lượng. Một token trong câu trả lời xuất sắc và một token trong câu trả lời sai hoàn toàn đều là những vector số. Giá trị của token không nằm ở bản thân nó, mà nằm ở vị trí và mối quan hệ của nó với các token khác trong một chuỗi hoàn chỉnh.

2. Thực thể nguyên thủy thứ hai: OpenRouter là gì ở cấp độ hạ tầng?

OpenRouter là một API gateway (cổng giao diện lập trình ứng dụng). Ở cấp độ hạ tầng, nó thực hiện ba chức năng cốt lõi: định tuyến request (request routing), tích hợp billing (thanh toán tập trung), và chuẩn hóa giao diện (API normalization). Nó biến việc gọi hàng chục API khác nhau từ các nhà cung cấp LLM thành một endpoint duy nhất.

Giá trị cốt lõi của OpenRouter nằm ở sự tiện lợi, không phải ở khả năng đánh giá chất lượng. Nền tảng này được thiết kế để tối ưu hóa trải nghiệm developer, không phải để tạo ra một thước đo giá trị khách quan cho mô hình AI. Khi chúng ta sử dụng token volume trên OpenRouter như một chỉ báo chất lượng, chúng ta đang ép một công cụ hạ tầng phải thực hiện một chức năng mà nó không được thiết kế để làm.

3. Thực thể nguyên thủy thứ ba: Nhu cầu đánh giá mô hình đến từ đâu?

Nhu cầu đánh giá và so sánh mô hình AI đến từ ba nhóm actor chính. Nhóm thứ nhất là developer cần chọn mô hình phù hợp cho ứng dụng cụ thể. Nhóm thứ hai là nhà đầu tư cần đánh giá tiềm năng của công ty AI. Nhóm thứ ba là researcher cần theo dõi sự tiến bộ của ngành.

Mỗi nhóm có tiêu chí đánh giá hoàn toàn khác nhau. Developer quan tâm đến latency (độ trễ), cost per token (chi phí mỗi token), và task-specific accuracy (độ chính xác cho tác vụ cụ thể). Nhà đầu tư quan tâm đến adoption rate (tỷ lệ áp dụng) và moat (hào bảo vệ cạnh tranh). Researcher quan tâm đến benchmark performance (hiệu suất trên các bài kiểm tra chuẩn). Không nhóm nào trong ba nhóm trên có thể được phục vụ đầy đủ chỉ bằng một con số token volume duy nhất.

4. Thực thể nguyên thủy thứ tư: Thị trường token có thể bị thao túng như thế nào?

Token volume là một chỉ số dễ bị inflate (phồng lên) nhất trong tất cả các loại chỉ số đánh giá công nghệ. Cơ chế thao túng đơn giản đến mức bất kỳ ai có kiến thức lập trình cơ bản đều có thể thực hiện.

Một script đơn giản chạy trên cloud, gửi hàng triệu request lặp lại qua OpenRouter API đến một mô hình cụ thể, có thể tạo ra hàng tỷ token mỗi tháng với chi phí chỉ vài trăm đô la nếu chọn đúng mô hình rẻ nhất. Các bot farm hoạt động 24/7, mỗi bot chạy hàng chục luồng song song, hoàn toàn có thể biến một mô hình không tên tuổi trở thành top 5 trên bảng xếp hạng token volume chỉ trong vài ngày.

Key Takeaway: Bốn thực thể nguyên thủy token, hạ tầng trung gian, nhu cầu đa chiều, và cơ chế thao túng cho thấy rằng token volume trên OpenRouter là một chỉ số đa nghĩa, dễ bị manipulate, và không đủ khả năng đứng một mình như một thước đo giá trị mô hình AI.

---

III. Xây dựng lại mô hình: Kiến trúc đánh giá từ nguyên tử

Nếu token volume không phải là thước đo giá trị thực sự, thì đâu là cách tiếp cận đúng? Câu trả lời nằm ở việc xây dựng một multi-signal evaluation framework (khung đánh giá đa tín hiệu) kết hợp nhiều nguồn dữ liệu nguyên thủy.

1. Kiến trúc nội dung: Nguyên tắc ba lớp

Một khung đánh giá mô hình AI đáng tin cậy cần ba lớp tín hiệu. Lớp thứ nhất là technical benchmarks (điểm chuẩn kỹ thuật), bao gồm các bài kiểm tra tiêu chuẩn hóa như MMLU, HumanEval, MATH, và Arena Elo. Lớp này cung cấp dữ liệu khách quan, có thể tái lập, nhưng chỉ phản ánh khả năng của mô hình trên các tác vụ tiêu chuẩn, không phải trên các tác vụ thực tế.

Lớp thứ hai là application-specific evaluation (đánh giá theo tác vụ cụ thể). Mỗi developer tự xây dựng test suite riêng cho use case của mình. Ví dụ, một công ty luật sẽ đánh giá mô hình dựa trên khả năng phân tích hợp đồng, không phải dựa trên điểm MMLU.

Lớp thứ ba là economic signals (tín hiệu kinh tế), bao gồm pricing trends, adoption velocity, và ecosystem integration. Tín hiệu này cho thấy thị trường thực sự đang phản ứng như thế nào, nhưng cần được lọc kỹ để loại bỏ noise.

2. Pipeline nguyên tử: Quy trình đánh giá mô hình AI từ đầu đến cuối

Giai đoạn 1: Xác định yêu cầu tác vụ. Thời gian: 2-4 giờ. Liệt kê các task cụ thể mà mô hình cần thực hiện, định nghĩa rõ ràng input và expected output cho mỗi task.

Giai đoạn 2: Thu thập dữ liệu đánh giá. Thời gian: 4-8 giờ. Tổng hợp technical benchmarks từ nhiều nguồn (LMSYS Chatbot Arena, Papers with Code, các báo cáo đánh giá độc lập). Thu thập token volume từ OpenRouter kèm theo context về pricing và promotional activities.

Giai đoạn 3: Xây dựng test suite riêng. Thời gian: 8-16 giờ. Tạo bộ câu hỏi kiểm tra chuyên biệt cho use case, bao gồm cả edge cases. Chạy test trên tối thiểu 3-5 mô hình để có cơ sở so sánh.

Giai đoạn 4: Chạy đánh giá và thu thập kết quả. Thời gian: 4-12 giờ (tùy số lượng mô hình và test cases). Mỗi mô hình chạy tối thiểu 3 lần trên mỗi test case để đảm bảo tính ổn định. Ghi lại latency, cost, và quality score cho mỗi lần chạy.

Giai đoạn 5: Phân tích đa chiều. Thời gian: 4-6 giờ. Xây dựng bảng so sánh tổng hợp, áp dụng weighting (trọng số) phù hợp với ưu tiên cụ thể. Ví dụ, nếu chi phí là yếu tố quan trọng nhất, weight cost score lên 40%.

Tổng thời gian pipeline: 22-48 giờ cho một vòng đánh giá hoàn chỉnh.

3. Chiến lược thực thi: Xây dựng hệ thống đánh giá liên tục

Việc đánh giá mô hình AI không phải là hoạt động một lần mà là một quy trình liên tục. Các mô hình được cập nhật thường xuyên, giá cả thay đổi theo tuần, và các benchmark mới liên tục xuất hiện.

Key Takeaway: Một pipeline đánh giá nguyên tử, được thực hiện có kỷ luật và lặp lại định kỳ, là cách duy nhất để có được cái nhìn chính xác về giá trị thực sự của một mô hình AI. Không có shortcut nào thay thế được quá trình này.

---

IV. Chiến lược thực thi chi tiết

Phần này trình bày chi tiết từng bước trong chiến lược đánh giá mô hình AI, hướng đến việc xây dựng một hệ thống mà bất kỳ developer hay team product nào cũng có thể áp dụng ngay trong thực tế công việc hàng ngày.

1. Thiết lập baseline evaluation protocol

Bước đầu tiên và quan trọng nhất là thiết lập một baseline protocol (giao thức cơ sở). Đây là tập hợp các quy tắc và tiêu chuẩn mà bạn sẽ sử dụng để đánh giá tất cả các mô hình, đảm bảo tính nhất quán và khả năng so sánh.

Baseline protocol cần bao gồm ba thành phần. Thành phần thứ nhất là danh sách các tác vụ đại diện. Chọn tối thiểu 5 tác vụ khác nhau mà team sử dụng thường xuyên nhất. Ví dụ: tóm tắt văn bản dài, sinh code Python, phân tích sentiment tiếng Việt, dịch thuật chuyên ngành, và trả lời câu hỏi dựa trên context.

Thành phần thứ hai là dataset kiểm tra. Chuẩn bị tối thiểu 20-50 mẫu test cho mỗi tác vụ. Các mẫu test phải đa dạng, bao gồm cả trường hợp dễ, trung bình, và khó. Đặc biệt quan trọng là phải có các adversarial examples (mẫu đối kháng), tức là các input được thiết kế để đánh lừa hoặc gây khó khăn cho mô hình.

Thành phần thứ ba là thước đo đánh giá. Đối với mỗi tác vụ, định nghĩa rõ ràng metric đánh giá. Các metric phổ biến bao gồm accuracy (độ chính xác), BLEU score (cho dịch thuật), pass@k (cho code generation), và human preference score (điểm đánh giá từ con người). Quan trọng nhất: quyết định trước tỷ lệ đánh giá tự động so với đánh giá thủ công.

2. Triển khai data collection layer trên OpenRouter

Để sử dụng dữ liệu token volume một cách có ý nghĩa, bạn cần thu thập dữ liệu từ OpenRouter ở mức chi tiết, không phải chỉ nhìn vào con số tổng.

Sử dụng OpenRouter API để theo dõi các chỉ số sau: model pricing (giá mỗi input và output token), latency distribution (phân bố độ trễ qua các thời điểm trong ngày), rate limits (giới hạn tốc độ), và model availability (tình trạng sẵn sàng). Lưu trữ dữ liệu này trong một database đơn giản, ngay cả một file CSV cũng đủ cho giai đoạn đầu.

Thiết lập một daily scraping script chạy tự động vào 3 thời điểm khác nhau trong ngày (sáng, trưa, tối) để ghi lại sự thay đổi về pricing và availability. Dữ liệu này sẽ giúp bạn phân biệt giữa token volume tăng do nhu cầu thực và token volume tăng do promotional pricing.

3. Xây dựng automated evaluation pipeline

Pipeline đánh giá tự động là xương sống của toàn bộ hệ thống. Mục tiêu là giảm thiểu thời gian thủ công và tăng tần suất đánh giá.

Bước 1: Viết wrapper function chuẩn hóa API calls. Function này nhận vào model name, prompt, và các parameters, trả về response, latency, và cost. Wrapper này phải xử lý được rate limiting, retry logic, và error logging.

Bước 2: Tạo test runner script. Script này đọc danh sách test cases từ file JSON, chạy tuần tự hoặc song song qua wrapper function, và ghi kết quả vào file kết quả. Mỗi test case bao gồm prompt, expected output (nếu có), và evaluation criteria.

Bước 3: Viết evaluation function cho mỗi metric. Đối với metrics có thể đánh giá tự động (accuracy, BLEU), viết function tính toán trực tiếp. Đối với metrics cần đánh giá thủ công (coherence, creativity), thiết lập một UI đơn giản để reviewer chấm điểm trên thang 1-5.

Bước 4: Tạo report generator. Script này đọc kết quả đánh giá, tính toán weighted score, và tạo bảng so sánh tổng hợp. Output dưới dạng markdown hoặc HTML.

4. Anti-manipulation detection system

Đây là phần thường bị bỏ qua nhưng vô cùng quan trọng. Bạn cần một hệ thống để phát hiện khi dữ liệu token volume bị thao túng.

Dấu hiệu thứ nhất là sudden spike không tương ứng với bất kỳ sự kiện nào. Nếu một mô hình tăng 300% token volume trong 24 giờ mà không có sự kiện ra mắt mới, pricing change, hay viral moment nào, đây rất có thể là artificial inflation.

Dấu hiệu thứ hai là pricing-volume correlation bất thường. Trong thị trường tự do, khi giá giảm, volume tăng. Nếu giá tăng mà volume vẫn tăng mạnh, hoặc giá giảm mà volume không thay đổi, đó là tín hiệu bất thường.

Dấu hiệu thứ ba là geographic distribution bất thường. Nếu 90% token volume của một mô hình đến từ một quốc gia hoặc region cụ thể, khả năng cao đó là bot activity.

Dấu hiệu thứ tư là usage pattern uniformity. Người dùng thực có hành vi đa dạng: họ gửi request vào nhiều thời điểm khác nhau, với nhiều loại prompt khác nhau, với độ dài khác nhau. Bot có pattern đồng đều: request đều đặn theo thời gian, prompt có độ dài tương tự, và không có sự đa dạng về loại tác vụ.

5. Lưu ý từ chuyên gia: Kết hợp quantitative và qualitative signals

Đừng bao giờ dựa hoàn toàn vào dữ liệu định lượng. Dữ liệu định lượng cho bạn biết cái gì đang xảy ra, nhưng không cho bạn biết tại sao.

Mỗi tháng, dành 2-3 giờ để đọc developer forum discussions, GitHub issues, và community feedback về các mô hình bạn đang đánh giá. Những tín hiệu định tính này thường chứa đựng những insight mà dữ liệu số không thể hiện được. Ví dụ, một mô hình có token volume tăng nhưng developer forum tràn ngập complaints về hallucination rate tăng trong phiên bản mới, thì sự tăng trưởng token đó là một tín hiệu tiêu cực, không phải tích cực.

Key Takeaway: Chiến lược thực thi hiệu quả nhất là xây dựng một hệ thống đánh giá tự động kết hợp nhiều nguồn tín hiệu, có cơ chế phát hiện thao túng, và được thực hiện định kỳ. Không có chỉ số đơn lẻ nào, kể cả token volume, có thể thay thế được hệ thống đánh giá đa chiều.

---

V. Bảng so sánh và Đánh giá hiệu quả

1. Bảng so sánh các phương pháp đánh giá mô hình AI

Tiêu chí	Token Volume (OpenRouter)	Technical Benchmarks (MMLU, HumanEval…)	Community-based (Arena Elo)	Self-built Test Suite	Multi-signal Framework
Độ chính xác đánh giá	Thấp	Trung bình	Khá	Cao	Rất cao
Chi phí triển khai	Rất thấp	Thấp	Không tốn phí	Trung bình	Cao
Tính chống thao túng	Rất yếu	Trung bình	Khá	Mạnh	Rất mạnh
Tốc độ cập nhật	Thời gian thực	Chậm (theo paper)	Trung bình	Tùy chỉnh	Tùy chỉnh
Khả năng tùy chỉnh	Không có	Thấp	Không có	Rất cao	Rất cao
Độ phức tạp triển khai	Rất thấp	Thấp	Thấp	Trung bình	Cao
Phù hợp cho developer	Thấp	Trung bình	Khá	Cao	Rất cao
Phù hợp cho nhà đầu tư	Khá	Khá	Khá	Thấp	Cao

2. Bảng Scorecard đánh giá: Token Volume trên OpenRouter như thước đo giá trị mô hình AI

Tiêu chí	Điểm	Ghi chú
Tính đại diện cho chất lượng mô hình	3	Token volume phản ánh usage frequency, không phải output quality
Khả năng chống thao túng	2	Dễ dàng inflate bằng bot scripts với chi phí thấp
Độ tin cậy thống kê	4	Sample size lớn nhưng distribution bị bias bởi pricing và routing logic
Tính nhất quán qua thời gian	5	Biến động mạnh theo promotional cycles và pricing changes
Khả năng so sánh cross-model	4	Bị ảnh hưởng bởi sự khác biệt về pricing strategy giữa các nhà cung cấp
Chi phí thu thập dữ liệu	9	API endpoint sẵn có, gần như không tốn chi phí để theo dõi
Tốc độ cập nhật	9	Dữ liệu cập nhật theo thời gian thực
Giá trị khi kết hợp với chỉ số khác	7	Hữu ích khi đặt trong context với các tín hiệu khác
Khả năng áp dụng cho developer	3	Không cung cấp đủ thông tin để ra quyết định lựa chọn mô hình
Giá trị cho nhà đầu tư	4	Cần nhiều context bổ sung để diễn giải chính xác

Giải thích tổng điểm Scorecard:

Tổng điểm trung bình: 5.0/10, thuộc phân loại Khá theo thang đánh giá (1-4: Thấp, 5-8: Khá, 9-10: Xuất sắc).

Kết quả này cho thấy token volume trên OpenRouter là một chỉ số có giá trị hữu hạn khi được sử dụng đúng cách. Điểm mạnh nằm ở tính sẵn có, tốc độ cập nhật, và chi phí thu thập thấp. Điểm yếu chí mạng nằm ở khả năng chống thao túng (2/10) và tính đại diện cho chất lượng mô hình (3/10).

Điểm giá trị khi kết hợp với chỉ số khác đạt 7/10, đây là cách sử dụng hợp lý nhất. Token volume đóng vai trò là một tín hiệu trong chuỗi tín hiệu, không phải là tín hiệu duy nhất. Nó hoạt động tốt nhất khi được cross-reference với technical benchmarks, pricing data, và community feedback.

---

VI. Dự báo xu hướng tương lai và Kết luận

1. Xu hướng 2026-2027: Token volume sẽ mất dần ý nghĩa

Ba xu hướng chính sẽ làm giảm giá trị của token volume như một chỉ số đánh giá. Xu hướng thứ nhất là sự trỗi dậy của task-specific benchmarking platforms. Các nền tảng như LMSYS Chatbot Arena đang mở rộng phạm vi đánh giá từ chat sang coding, reasoning, và multimodal tasks. Khi các benchmark chuyên biệt trở nên phổ biến, nhu cầu dùng token volume như proxy sẽ giảm.

Xu hướng thứ hai là sự phát triển của AI model observability tools (công cụ quan sát mô hình AI). Các công cụ như LangSmith, Arize Phoenix, và Weights & Biases cung cấp khả năng theo dõi hiệu suất mô hình trong production với mức chi tiết mà token volume không thể sánh được. Khi developer có công cụ tốt hơn, họ sẽ ngừng dựa vào các chỉ số thô.

Xu hướng thứ ba là khả năng dynamic routing trở thành tiêu chuẩn. Khi các hệ thống tự động chọn mô hình phù hợp nhất cho từng request cụ thể dựa trên quality-cost tradeoff, việc so sánh mô hình theo tổng volume trở nên vô nghĩa. Mỗi request sẽ được routed đến mô hình tối ưu cho task đó, và tổng volume chỉ phản ánh distribution of task types, không phải relative model quality.

2. Kết luận

Cơn sốt token trên OpenRouter phản ánh một nhu cầu con người tự nhiên và chính đáng: muốn có một con số đơn giản để hiểu một thế giới phức tạp. Nhưng sự đơn giản hóa này có cái giá của nó. Token volume là một chỉ số bị over-indexed (được gán quá nhiều ý nghĩa) trong một hệ sinh thái mà sự phức tạp đòi hỏi cách tiếp cận đa chiều.

Cách tiếp cận đúng đắn nhất không phải là phủ nhận hoàn toàn token volume, mà là đặt nó vào đúng vị trí: một tín hiệu phụ trong một hệ thống đánh giá đa tín hiệu có kỷ luật. Kết hợp nó với technical benchmarks, application-specific test suites, community feedback, và anti-manipulation detection, bạn sẽ có được bức tranh chính xác hơn nhiều so với việc nhìn vào bất kỳ chỉ số đơn lẻ nào.

Câu hỏi đúng không phải là “Mô hình nào có nhiều token nhất?” mà là “Mô hình nào đáp ứng tốt nhất yêu cầu cụ thể của tôi, với chi phí và tốc độ mà tôi chấp nhận được, dựa trên bằng chứng đáng tin cậy?” Trả lời được câu hỏi này, bạn sẽ không bao giờ bị đánh lừa bởi bất kỳ cơn sốt chỉ số nào.

---