Giá token đang ngày càng đắt hơn
(ethanding.substack.com)- Trái với kỳ vọng rằng chi phí token của LLM sẽ giảm 10 lần mỗi năm, các dịch vụ đăng ký AI lại đang chứng kiến tình trạng lợi nhuận ngày càng xấu đi
- Nhu cầu đối với các mô hình LLM mới nhất luôn tập trung vào những mô hình hàng đầu (SOTA, State-of-the-art), nên việc giá của các mô hình “đời cũ” giảm xuống không dẫn tới tiết kiệm chi phí thực tế
- Hiệu năng mô hình càng tăng thì lượng token được sử dụng càng tăng theo cấp số nhân, bù trừ cho mức giảm đơn giá và thậm chí còn khiến tổng chi phí tăng vọt
- Các thử nghiệm gói thuê bao không giới hạn (ví dụ: Claude Code $200/tháng) cũng không bền vững do token usage bùng nổ từ nhóm người dùng nặng
- Ngoài tính phí theo mức sử dụng, không có mô hình nào bền vững về dài hạn, nhưng việc triển khai trong thực tế lại khó khăn do cạnh tranh giữa các startup và sự phản đối từ người tiêu dùng
- Nếu không chuyển sang mô hình doanh thu bền vững, phần lớn startup cuối cùng sẽ đối mặt với nguy cơ phá sản
Kinh doanh thuê bao AI: vì sao đơn giá token giảm mà thua lỗ chỉ tăng thêm?
Ảo tưởng về việc giá LLM giảm
- Các nhà sáng lập tin vào playbook của VC rằng “đơn giá token giảm 10 lần, chỉ cần cầm cự thêm chút nữa là có thể chuyển sang cấu trúc biên lợi nhuận cao”, nên ở giai đoạn đầu họ vận hành sản phẩm thuê bao ở mức hòa vốn hoặc lỗ
- Thực tế, đơn giá token của các mô hình cũ như GPT-3.5 đã giảm hơn 10 lần, nhưng nhu cầu của người dùng và thị trường luôn dồn vào những mô hình mới nhất và mạnh nhất (SOTA)
- Trên thực tế, sau 18 tháng, biên lợi nhuận không những không cải thiện mà còn tệ hơn
- Việc giảm giá của mô hình cũ chỉ thực sự được cảm nhận ở những thứ đã nằm ngoài mối quan tâm của thị trường, giống như “báo ngày hôm qua”
Cấu trúc giá và nhu cầu của các mô hình mới nhất
- GPT-4, Claude 3 Opus và các mô hình mới nhất luôn được phát hành với mức giá cao tương tự nhau, và dù mô hình cũ có rẻ đến đâu thì mức sử dụng thực tế của chúng cũng rất nhỏ
- Người dùng chỉ muốn “hiệu năng tốt nhất”, còn “mô hình cũ giá rẻ” chẳng khác nào những chiếc xe cũ lâu năm trên thị trường ô tô
- Vì điều người dùng thực sự muốn khi dùng AI là kết quả tốt nhất, nên rất hiếm trường hợp họ tự nguyện dùng mô hình cũ chỉ để tiết kiệm chi phí
- Rốt cuộc, để có sức cạnh tranh trên thị trường thì lúc nào cũng phải cung cấp mô hình mới nhất đắt đỏ nhất, và vì thế chi phí đầu vào tiếp tục được giữ nguyên
- Cũng giống như việc giá xe cũ từ thập niên 90 có giảm thì người tiêu dùng vẫn mua xe mới
Mức tăng bùng nổ của lượng token sử dụng
- Khi hiệu năng mô hình tăng lên, xuất hiện hiện tượng lượng token tiêu thụ cho một tác vụ tăng theo cấp số nhân
- Trước đây một công việc chỉ cần 1.000 token, giờ đây có thể tiêu tốn 100.000 token
- Trước kia chỉ là một câu hỏi một câu trả lời, còn hiện nay là các quy trình nghiên cứu phức tạp, loop và orchestration chạy liên tục 10–20 phút, tạo ra lượng token khổng lồ
- Khi AI được dùng cho nghiên cứu/phân tích sâu hơn, các kiểu “một lần chạy 20 phút, chạy liên tục 24 giờ mỗi ngày” khiến mức sử dụng trung bình mỗi ngày trên mỗi người dùng tăng vọt
- Ví dụ, chỉ cần dùng một lần mỗi ngày tính năng 'deep research' trị giá $1 thì gói thuê bao $20 đã không còn hiệu quả kinh tế
- Phần giảm của đơn giá bị bù hết bởi tổng lượng token tiêu thụ tăng lên, dẫn tới tình trạng gói $20/tháng thậm chí không gánh nổi một tác vụ $1 mỗi ngày
Sự thất bại của gói cước không giới hạn
- Claude Code của Anthropic và các dịch vụ tương tự đã thử áp dụng gói không giới hạn $200/tháng, tự động tối ưu token và tận dụng PC của người dùng như các biện pháp cắt giảm chi phí
- Nhưng một số power user đã dùng gần 10 tỷ token mỗi tháng (tương đương 12.500 bản “War and Peace”), vì họ tận dụng tự động hóa, tác vụ lặp và loop để đẩy mức sử dụng token bùng nổ
- Mức sử dụng AI tách rời khỏi thời gian của con người, API chạy 24/7 và token bùng nổ
- Dù đã có nhiều đổi mới về kỹ thuật, cuối cùng họ vẫn phải rollback gói cước
- Kết luận: mô hình thuê bao không giới hạn giờ đã bất khả thi, bản thân phép tính đã không còn hợp lý
Thế lưỡng nan mà toàn ngành đang đối mặt
- Nếu tiếp tục cố chấp với mô hình thuê bao thì lợi nhuận sẽ xấu đi và rủi ro sụp đổ ngày càng lớn
- Các công ty AI đều biết rằng chỉ usage-based pricing mới là lời giải, nhưng nếu xuất hiện đối thủ cạnh tranh theo mô hình thuê bao thì nguy cơ mất người dùng là rất lớn
- Cấu trúc kiểu “thế lưỡng nan của tù nhân” đẩy tất cả vào cuộc cạnh tranh trợ giá cho power user
- Cursor, Replit và các công ty khác cũng tiếp cận theo hướng “ưu tiên tăng trưởng, lợi nhuận là vấn đề của tương lai”, nhưng rốt cuộc sớm muộn vẫn không tránh khỏi tái cấu trúc vì bài toán lợi nhuận
3 giải pháp thực tế
- 1. Tính phí theo mức sử dụng
- Nếu áp dụng mô hình kinh tế minh bạch ngay từ đầu thì có thể thiết kế cấu trúc doanh thu không vượt quá chi phí đầu vào. Về dài hạn, đây là mô hình bền vững duy nhất
- Tuy nhiên, người tiêu dùng cực kỳ không thích hình thức tính tiền theo đồng hồ đo, nên rất khó đạt thành công đại chúng
- 2. Tấn công thị trường doanh nghiệp dựa trên chi phí chuyển đổi cao
- Thông qua bán hàng B2B cho khách hàng enterprise có chi phí chuyển đổi cao (ví dụ: tập đoàn lớn, tổ chức tài chính), một khi đã vào được thị trường thì gần như không thể bị hủy và biên lợi nhuận cũng cao
- Các lĩnh vực system of record (SOR, như CRM/ERP/EHR) là ví dụ thành công tiêu biểu (ví dụ: triển khai cho 40.000 kỹ sư của Goldman Sachs)
- 3. Tạo giá trị gia tăng thông qua tích hợp dọc (Vertical Integration)
- Giống như Replit, có thể cung cấp chính suy luận LLM như một sản phẩm mồi đang bị lỗ, rồi tạo doanh thu từ các dịch vụ đặt phía trên như hosting, cơ sở dữ liệu, triển khai, giám sát
- Xây dựng cấu trúc trong đó mức sử dụng AI tăng lên sẽ dẫn sang thị trường hạ tầng
- Trong tương lai, đơn giá token vẫn sẽ tiếp tục giảm, nhưng kỳ vọng của người dùng và lượng sử dụng cũng sẽ tăng theo cấp số nhân
- Những công ty vẫn chỉ bám vào chiến lược tăng trưởng bằng thuê bao rốt cuộc rất dễ phải tổ chức một “đám tang chi phí cao”
Tóm tắt
- Chỉ dựa vào sự lạc quan rằng “sang năm token sẽ rẻ hơn 10 lần” thì không thể duy trì kinh doanh
- Người dùng luôn đòi hỏi kỳ vọng cao hơn và mức sử dụng lớn hơn
- Công thức mô hình tiến bộ = mức sử dụng bùng nổ = chi phí tăng đang thành hình, và cuối cùng một doanh nghiệp AI bền vững buộc phải chuyển sang cấu trúc mới thông qua tính phí theo mức sử dụng, hợp đồng doanh nghiệp lớn hoặc tích hợp dọc
- Nếu muốn duy trì hoạt động kinh doanh thì cần một cách tiếp cận cấu trúc mới như chiến lược 'Neocloud'
4 bình luận
Do việc caching khó khăn cộng với tự động hóa tận dụng MCP, mức sử dụng không giới hạn có thể thực sự tiến tới đúng nghĩa là dùng không giới hạn. ..Giống như các nhà mạng không có gói cước dữ liệu không giới hạn, có thể sẽ chuyển sang kiểu tính phí như khoảng ~300 lần/ngày, ~2000 lần/ngày, v.v.. cũng có cảm giác như sẽ hướng tới mô hình giá giống tin nhắn SMS ngày xưa.
Có lẽ sẽ tốt nếu đi theo cách giống Internet: về cơ bản lượng sử dụng là không giới hạn (dù đôi khi cũng có tính phí theo mức dùng), nhưng áp giới hạn về tốc độ. Về triển khai thì ngay cả bây giờ cũng đã có kiểu xử lý theo lô, nên có thể tách biệt tài nguyên tính toán với tài nguyên đến tay người dùng. Xét cho cùng, nếu phía nhà cung cấp cũng đảm bảo được tính dự đoán, còn người dùng được bảo đảm mức giá và tốc độ hợp lý, thì chẳng phải là đôi bên cùng có lợi sao? Với một số người dùng dùng quá mức, có lẽ nên đi theo hướng phân bổ tài nguyên riêng thông qua hợp đồng riêng.
Ý kiến Hacker News
Nhìn vào nội dung được trích trong bài, có thể thấy người tiêu dùng ghét kiểu tính phí theo mức sử dụng (metered billing) và nói rằng họ thà trả dư cho gói không giới hạn còn hơn nhận một hóa đơn cao bất ngờ, nhưng thực tế phức tạp hơn vậy. Trên Amazon, rất nhiều lúc vừa nghĩ rằng mình đã dự đoán được chi phí thì hóa đơn lại đột nhiên tăng mạnh. Lý do là không có cách nào để đặt kiểu "hãy tự động tắt nếu vượt quá X đô la mỗi tháng". Kiểu cấu trúc "surprise net 30" như vậy lúc nào cũng tạo cảm giác chi phí có thể dự đoán được, nhưng cuối cùng vẫn quay lại thành khoản phát sinh ngoài dự kiến. Tuy nhiên, nếu tính phí theo mức sử dụng giúp người dùng thấy rõ mức tiêu thụ của mình và có thể đặt trần để ngăn vượt ngân sách, thì ngược lại đây có thể là một cách tốt. Về phía các công ty AI, họ chỉ cần giúp người dùng quản lý ngân sách bằng các biểu đồ cột "token đã dùng / tổng token", số token trên mỗi phản hồi, số lượt phản hồi ước tính còn lại trước khi vượt hạn mức, v.v. Điều quan trọng là tuyệt đối không được tạo ra các hóa đơn bất ngờ. Nhưng các công ty lại thích che giấu các thông tin token và đô la này, tương tự như cách các trang cờ bạc không liên kết trực tiếp "corporate bucks" với USD.
Tôi nghĩ tính phí theo mức sử dụng phù hợp với các dịch vụ B2B dạng hạ tầng (như AWS). Khi doanh nghiệp tăng trưởng thì mức dùng hạ tầng và chi phí cũng tăng tương ứng, nên có thể dự đoán được; hạ tầng một khi đã thiết lập thì hầu như không phải bận tâm nữa. Nhưng trong bối cảnh AI được dùng như công cụ/phục vụ công việc, tính phí theo mức sử dụng là một rào cản lớn. Trong tình huống này, kiểu tính phí đó trực tiếp kìm hãm việc sử dụng sản phẩm và tạo ra sự mệt mỏi rất lớn vì mỗi lần dùng lại phải phân tích hiệu quả so với chi phí. Nếu dùng trong công việc, có khi còn phải liên tục xin phê duyệt của quản lý. Một công cụ nhắm đến tăng năng suất không nên tạo ra những rào cản như vậy. Gần như chẳng ai muốn suy nghĩ 250 lần kiểu “hành động này có đáng 3 đô không?”. Nếu là trả theo mức dùng thì họ đơn giản sẽ không dùng.
Tôi khó chịu vì các công ty cố che giấu thông tin quy đổi token sang đô la. Tôi đang dùng thử Copilot agent của GitHub, và giá cả thực sự rất mù mờ. Họ cứ nói về "premium request", nhưng trên dashboard của tôi không thể xem mức sử dụng và hạn mức theo thời gian thực. Trong UI, nếu bấm vào phần nói về premium request thì nó dẫn tới tài liệu, nhưng lại không chỉ rõ hạn mức thực tế hay dashboard tính phí.
Ở Amazon (AWS) vấn đề còn nghiêm trọng hơn. Trái với sức hút "rẻ hơn" của AWS, việc chuyển sang đó chỉ có ý nghĩa nếu nó thực sự rẻ hơn phương án thay thế. Thế nhưng nhiều công ty không bỏ thời gian của lập trình viên ra để thay đổi hạ tầng. Chi phí cơ hội rất lớn, và vì có rủi ro (doanh thu, thời gian phát triển, cạnh tranh, v.v.), nên nếu hiệu quả đầu tư không thật sự đủ lớn thì người ta sẽ coi đó chỉ là lãng phí thời gian phát triển. Nếu cấu trúc hạ tầng cuối cùng lại còn đắt hơn cả phương án thay thế, thì vì đã tốn thời gian của lập trình viên nên đành phải chấp nhận khoản lỗ đó. Với mô hình tính phí theo token hiện tại, gánh nặng chuyển đổi/chi phí cơ hội kiểu này vẫn chưa được cảm nhận rõ vì vẫn có thể dễ dàng quay lại cách cũ. Nhưng tôi đoán sau này cấu trúc này sẽ thay đổi.
Cấu trúc giá của Amazon tạo cảm giác rất mơ hồ và phức tạp. Ví dụ, có những lúc không có cách nào biết được vì sao chi phí cơ sở dữ liệu cứ lên xuống liên tục.
Với các quy trình được xác định rõ, trả theo mức sử dụng thực sự rất hữu ích. Điểm tôi thích ở AWS là có thể làm cho chi phí khớp với hoạt động kinh doanh thực tế. Trước đây chuyện đó rất khó và còn kéo theo nhiều vấn đề chính trị nội bộ. Từng có trường hợp nhân viên sales trực tiếp thuyết phục lãnh đạo rằng cần mua thiết bị, rồi cuối cùng lại phải ôm cả đống thiết bị mạng mà chẳng hề mong muốn. Nhưng từ góc nhìn người dùng, kiểu quản lý chi phí chi li như vậy lại không tốt, vì người dùng sẽ liên tục bị đánh giá bằng đủ loại chỉ số không liên quan trực tiếp tới năng suất. Hồi còn là thực tập sinh những năm 90, để được duyệt một cuộc gọi đường dài thôi tôi cũng phải chịu đủ thứ quan liêu. Người phê duyệt còn đánh giá từng chút xem cuộc gọi 20 phút có hợp lý không, và nếu vượt hạn mức thì tôi phải tự trả tiền. Trải nghiệm chẳng vui vẻ gì. Với AI dành cho người dùng, gói giá cố định mới là đáp án. Nếu năng suất của tôi tăng 20% và tôi dùng ChatGPT Pro giá $200/tháng thì nó đáng giá $16k mỗi năm. Đó là một khoản đầu tư cực kỳ rẻ.
Những lập luận trong bài không khiến tôi thấy hợp lý về mặt logic. Tôi khó đồng ý với ý “khi có mô hình mới nhất thì 99% nhu cầu lập tức chuyển sang đó”. Ngược lại, Sonnet 4 đang được dùng nhiều hơn Opus 4; thực tế có rất nhiều người dùng chọn mô hình rẻ hơn, bình thường hơn thay vì mô hình mạnh nhất. Vì nhiều lý do như tính dễ dùng, tốc độ, độ quen thuộc, v.v., nhiều mô hình không phải SOTA vẫn được sử dụng song song. Tham khảo bảng xếp hạng mô hình: https://openrouter.ai/rankings. Và việc mô tả chuyển từ Opus sang Sonnet, hoặc khi tải nặng thì sang Haiku như thể autoscaling, theo tôi thì hành vi đó không hẳn được nhúng vào trọng số mô hình. Nhìn chung, vấn đề giá cả trong bài có vẻ chỉ đang lặp lại những gì từng xảy ra thời cloud hosting: nhiều người dùng chọn gói tháng cố định để tiện dù hiệu năng thấp hơn, còn một số người dùng API (heavy user/doanh nghiệp) thì dùng pay-as-you-go; cấu trúc này vốn đã đảm bảo lợi nhuận đầy đủ. Phần lớn startup AI là B2B chứ không phải B2C.
Câu chuyện “Claude Code ban đầu cung cấp $200/tháng không giới hạn rồi sau đó rollback” là không đúng sự thật. Ngay từ tên gói đã là gói 20x, và từ đầu đã có giới hạn rõ ràng như giới hạn phiên 5 giờ và giới hạn 50 phiên mỗi tháng (dù không bị ép cứng). Bản thân tôi dùng cũng hiếm khi thấy thiếu, thậm chí còn cảm thấy hạn mức vẫn cao. Vì vậy, nói đúng sự thật cũng hoàn toàn không làm hại luận điểm chút nào.
Vấn đề thực tế lớn là hiện tại chúng ta đang ở trong tình huống dùng mô hình không phân biệt, kiểu lấy đại bác bắn muỗi bằng cách ném mô hình tổng quát cao cấp nhất vào mọi bài toán. Không phải mọi vấn đề đều cần mô hình SOTA. Trong tương lai, khi các dịch vụ chuyển sang kiểu “bundle” nhiều mô hình lại với nhau, biểu đồ sử dụng sẽ hiệu quả hơn rất nhiều.
Cho đến giờ vẫn chưa có mô hình nào đủ đáng tin để tôi hoàn toàn giao phó các nhiệm vụ chính. Ngay cả các mô hình mạnh nhất đôi khi cũng hành xử rất kỳ quặc, trong khi bộ não của tôi thì lúc nào cũng tự xử lý công việc nên chẳng cần phải tốn đầu óc vào việc ủy quyền. Vì thế chỉ khi giao cho AI mang lại “lợi ích chắc chắn” tôi mới thực sự giao. Tôi vẫn ưu tiên thứ mình giỏi. Các công ty AI quảng bá hiệu năng tốt nhất, nhưng với người dùng thì chỉ số quan trọng lại là “khoảnh khắc tệ nhất” của AI. Đó là lý do chỉ SOTA mới luôn có nhu cầu. AI bị đánh giá bằng “khoảnh khắc tệ nhất” — làm tốt đến đâu mà chỉ một lần sai cũng có thể chí mạng, giống như con người bị sa thải vì sai lầm tệ nhất của họ. Hiệu năng trong trường hợp hoàn hảo (môi trường phòng lab) không phải điều quan trọng; lúc nó hỏng trong thực tế mới quan trọng hơn. Bài viết thể hiện phần này khá rõ.
Cho tới giờ, những tác vụ khó nhất vẫn chưa được giải quyết, và cũng không có nhiều công việc mà người ta sẵn sàng chấp nhận câu trả lời có độ chính xác thấp. Một số tác vụ pipeline văn bản có thể ổn, nhưng gần như mọi ứng dụng hướng tới người dùng đều đòi hỏi chất lượng cao.
Nhiều người bỏ qua điểm này. Các mô hình GPU 7b, 32b cũng hoạt động đủ tốt cho nhiều tác vụ. Và chúng còn chạy được trên phần cứng cũ. Hiện tại vẫn còn đang trong giai đoạn hype khi hiệu năng LLM nói chung cùng tăng lên, nhưng theo thời gian thì mức tăng của các mô hình lớn sẽ chững lại và mọi người sẽ bắt đầu đưa ra các lựa chọn thực tế hơn.
Việc thử nhiều mô hình khác nhau là rất đáng giá. Hệ thống chatbot đơn giản mà tôi làm gần đây dùng 5 loại mô hình khác nhau tùy tình huống. Việc thay đổi và trộn mô hình đa dạng tạo ra khác biệt rất lớn về chi phí, trải nghiệm người dùng và chất lượng.
Nếu có tùy chọn để Claude Opus hướng dẫn Sonnet thì tôi sẽ dùng nó cho gần như mọi cuộc trò chuyện. Làm kiểu này thủ công thì vừa phiền vừa làm đứt mạch, nên cuối cùng tôi cứ dùng Opus mãi. Nhờ xử lý song song, chi phí input thấp nên tôi nghĩ ngay cả khi prompt lớn lên thì cũng không phải gánh nặng quá lớn.
Tôi ước có công ty AI nào xây được hệ thống có thể giao các tác vụ đơn giản cho mô hình “ngu” hơn. Những tác vụ phức tạp thì cần mô hình cỡ Opus, nhưng bên trong đó thực ra có rất nhiều phần việc mà 3.5 Sonnet là đủ. Opus có thể phân biệt phần đơn giản và phần khó, rồi phân tán việc dễ cho nhiều 3.5 Sonnet xử lý. Ý tưởng này nghe quá hiển nhiên nên tôi nghĩ chắc ai cũng đang làm rồi.
Claude code thực sự tự động sử dụng cả Sonnet và Haiku. Khi kết thúc phiên, nó còn cho biết đủ loại thống kê như token, chi phí, v.v. Tôi đoán trong lúc phiên đang chạy cũng sẽ có cách để xem các thông tin đó.
Ví dụ, có thể để prompt xuất ra “mức mô hình được khuyến nghị” theo thang 1~10 cho từng subtask thì sao.
Trong 1~2 năm qua, tôi tự thanh toán API rồi dùng frontend mã nguồn mở (như LibreChat) để truy cập và sử dụng nhiều mô hình khác nhau. Với kiểu dùng thỉnh thoảng thì cách này rất hợp; chỉ cần nạp khoảng $10 vài tháng một lần là đủ. Vì lượng token tôi dùng ít hơn rất nhiều so với hầu hết các gói package, nên tôi thấy cách này rẻ hơn hẳn. Nhưng khi bắt đầu thử các công cụ như Claude Code thì token bị tiêu hao nhanh thấy rõ. Hôm qua chỉ trong 15 phút tôi đã dùng hết $5 tiền token. Tôi biết công cụ code hoạt động rất khác với việc chỉ hỏi LLM đơn giản, nhưng tôi không ngờ mức chênh lại lớn đến vậy. Càng ngạc nhiên hơn vì phần lớn lượng token dùng thực ra không dễ nhìn thấy bằng mắt thường (nó bị che bởi context ngày càng lớn hoặc orchestration công cụ).
Hiện tượng này xảy ra vì Claude Code dùng context rộng hơn nhiều và xử lý lặp đi lặp lại nhiều hơn so với bình thường.
Tôi dùng Deepseek API với $20 mà đủ gần một năm rồi (tôi không quan tâm chuyện đó là công ty Trung Quốc). Nó chậm nhưng trong các mô hình Deepseek tự host độc lập thì tôi lại thấy chất lượng còn tốt hơn (ít nhất theo trải nghiệm của tôi). Tôi không dùng mấy thứ như agent.
Tôi phản đối khẳng định “99% nhu cầu lúc nào cũng dồn vào mô hình tiên tiến nhất”. Biên giới thực sự nằm không chỉ ở ‘năng lực’ mà còn ở ‘năng lực so với giá’. Mô hình cao cấp nhất không chiếm 99% thị phần, mà ngược lại. Nhìn vào thống kê OpenRouter thì Claude Opus 4 chỉ chiếm khoảng 1%, còn phổ biến nhất là Sonnet 4 với 18% người đăng ký sử dụng. Ngoài ra, Gemini Flash 2.0 và 2.5 rẻ hơn cũng được dùng rất nhiều. Chúng còn rẻ hơn cả Sonnet 4.
Tôi thắc mắc vì sao ở San Francisco người ta không dùng chữ hoa và dấu câu. Và tôi cũng không hiểu vì sao dân Silicon Valley lại ám ảnh với tăng trưởng lũy thừa giả tạo như vậy. Thực ra, thay vì AI đang tiến bộ theo cấp số nhân, có vẻ rõ ràng hơn là lượng tài nguyên đổ vào hiện nay lớn hơn khủng khiếp so với vài năm trước.
Tôi tự hỏi liệu văn phong kỳ quặc này có phải để cho thấy bài viết không phải do LLM viết ra không.
Không chịu nổi việc ngôn ngữ thay đổi tự nhiên à?/đùa thôi. Có lẽ phải sống theo cách cũ vậy.
Nếu đến Tenderloin hay Mission Street ở San Francisco thì thật sự không dùng chữ hoa với dấu câu là có thể bị bắn à? (đùa thôi)
Bài viết bỏ lỡ trò “ghế âm nhạc” trong quá trình “chiếm đất”. Cũng như trường hợp Uber, nếu dùng vốn đầu tư mạo hiểm để chiếm thị phần và chấp nhận lỗ trong nhiều năm, chỉ cần giành được vị trí trong nhận thức khách hàng trước thì về sau dù có đối thủ mới rẻ hơn cũng không dễ bị lung lay. Doanh nghiệp sẽ ổn định chỗ đứng, và kể cả sau IPO vẫn có thể duy trì giá cổ phiếu lành mạnh (dù không hẳn xuất sắc).
Bài viết mô tả như thể không ai trả giá theo mức sử dụng, nhưng thực tế thì khách hàng API (tức gần như toàn bộ khách hàng doanh nghiệp) đã và đang trả theo mức sử dụng hết rồi.
"Mình thắc mắc vì sao ở San Francisco lại không dùng chữ in hoa và dấu câu"
Vào đọc nội dung thì đúng là thật. Điều thú vị là có câu thì dùng dấu chấm, có câu thì không, cứ lẫn lộn như vậy, là vì lý do gì nhỉ? Có ai biết không? Mình tò mò quá 🤔