63 điểm bởi GN⁺ 11 ngày trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Chiến lược bootstrap để vận hành nhiều công ty SaaS có MRR vượt 10.000 USD với chi phí hạ tầng dưới 20 USD/tháng, tận dụng một VPS duy nhất, ngôn ngữ Go, SQLite và GPU cục bộ
  • Thay vì AWS hay hệ thống điều phối cloud phức tạp, toàn bộ dịch vụ được chạy trên một VPS giá 5~10 USD; tập trung vào xử lý request thay vì quản trị hạ tầng
  • Chọn Go làm ngôn ngữ backend để có quy trình triển khai cực kỳ đơn giản: biên dịch thành một binary duy nhất không cần quản lý dependency rồi deploy lên server
  • Chạy VLLM trên GPU cục bộ (RTX 3090) để đưa chi phí xử lý AI theo lô về 0, chỉ dùng các model frontier qua OpenRouter cho những tính năng trực tiếp phục vụ người dùng
  • Ngay cả khi không có vốn đầu tư mạo hiểm, nếu giữ chi phí gần như bằng 0 thì có thể đạt được runway gần như vô hạn, đủ thời gian để tìm product-market fit

Chiến lược vận hành server tinh gọn

  • Cách phổ biến để ra mắt web app vào năm 2026 là provision cụm EKS, instance RDS và NAT Gateway trên AWS; như vậy sẽ tốn hơn 300 USD/tháng ngay cả khi chưa có người dùng nào
  • Giải pháp thay thế là thuê một VPS 5~10 USD/tháng từ Linode hoặc DigitalOcean và vận hành trên một server duy nhất
  • Ngay cả 1GB RAM cũng đủ nếu dùng hợp lý; khi cần thêm dư địa có thể dùng swapfile
  • Khi chỉ có một server, bạn biết chính xác log nằm ở đâu, nguyên nhân crash là gì và cách restart ra sao
  • Lý do chọn VPS thay vì AWS là để giữ chi phí có thể dự đoánkiến trúc đơn giản

Vì sao chọn ngôn ngữ Go

  • Python hay Ruby có thể ngốn một nửa RAM chỉ để khởi động interpreter và quản lý worker gunicorn
  • Go cho hiệu năng vượt trội hơn nhiều trong các tác vụ web, có hệ thống kiểu chặt chẽ, và đến năm 2026 là ngôn ngữ mà LLM suy luận rất dễ
  • Ưu điểm cốt lõi của Go là sự đơn giản trong quy trình triển khai: biên dịch toàn bộ ứng dụng thành một binary liên kết tĩnh duy nhất, build trên laptop rồi gửi lên server bằng scp để chạy
  • Không cần địa ngục dependency kiểu pip install hay virtual environment, và vẫn có thể xây dựng web server cấp độ production mà không cần framework cồng kềnh
  • Chỉ với thư viện chuẩn của Go, có thể viết server xử lý hàng chục nghìn request mỗi giây

Tận dụng AI cục bộ: đưa chi phí tác vụ theo lô về 0

  • Nếu ở nhà bạn có card đồ họa, thì về cơ bản bạn đã sở hữu AI credit không giới hạn
  • Khi xây dựng eh-trade.ca, cần thực hiện nghiên cứu cổ phiếu định tính quy mô lớn bằng cách phân tích báo cáo quý của hàng nghìn công ty; nếu dùng OpenAI API thì có thể tốn hàng trăm USD
  • Thay vào đó, tác giả chạy VLLM trên RTX 3090 (24GB VRAM) mua với giá 900 USD từ Facebook Marketplace, loại bỏ nhu cầu phải trả phí cho nhà cung cấp AI
  • Lộ trình nâng cấp AI cục bộ:
    • Bắt đầu với Ollama: thiết lập bằng một lệnh duy nhất (ollama run qwen3:32b), thử nghiệm nhiều model ngay lập tức, rất phù hợp cho việc lặp lại prompt
    • Chuyển sang production với VLLM: Ollama trở thành nút thắt khi có request đồng thời, còn VLLM dùng PagedAttention nên nhanh hơn vượt bậc. Khi gửi đồng thời 8~16 request bất đồng bộ, hệ thống sẽ batch trong bộ nhớ GPU với thời gian gần tương đương xử lý một request duy nhất
    • Transformer Lab: khi cần pretraining hoặc fine-tuning model, có thể thực hiện dễ dàng trên phần cứng cục bộ
  • Để quản lý việc này, tác giả phát triển laconic: công cụ nghiên cứu dạng agent tối ưu cho cửa sổ ngữ cảnh 8K, hoạt động giống trình quản lý bộ nhớ ảo của hệ điều hành, “page out” những phần hội thoại không cần thiết để chỉ giữ các dữ kiện cốt lõi trong context đang hoạt động của LLM
  • llmhub: công cụ trừu tượng hóa mọi LLM thành tổ hợp provider/endpoint/apikey, giúp xử lý I/O văn bản và hình ảnh trơn tru dù chạy cục bộ hay trên cloud

Truy cập các model frontier qua OpenRouter

  • Không phải mọi tác vụ đều có thể xử lý cục bộ; với các tương tác chat độ trễ thấp hướng tới người dùng, vẫn cần các model suy luận hàng đầu như Claude 3.5 Sonnet hay GPT-4o
  • Thay vì phải quản lý riêng tài khoản billing, API key và giới hạn tốc độ của Anthropic, Google và OpenAI, có thể hợp nhất qua OpenRouter
  • Chỉ cần viết một lớp tích hợp tương thích OpenAI là có thể truy cập ngay tất cả các model frontier lớn
  • Hỗ trợ fallback routing mượt mà: khi API của Anthropic gặp sự cố, hệ thống tự động chuyển sang model OpenAI tương đương, giúp người dùng hoàn toàn không thấy màn hình lỗi và không cần logic retry phức tạp

Viết code AI tiết kiệm chi phí với GitHub Copilot

  • Trong khi các model đắt tiền mới ra mắt mỗi tuần, nhiều lập trình viên đang chi hàng trăm USD/tháng cho gói Cursor và API key Anthropic
  • Trong khi đó, ngay cả khi dùng Claude Opus 4.6 cả ngày thì chi phí hằng tháng cũng hiếm khi vượt quá 60 USD
  • Bí quyết là tận dụng mô hình định giá của Microsoft: mua thuê bao GitHub Copilot từ năm 2023 và kết nối với VS Code tiêu chuẩn
  • Mẹo quan trọng của Copilot: Microsoft không tính phí theo token mà theo request; và một “request” chính là một lần nhập vào khung chat. Ngay cả khi agent phân tích toàn bộ codebase trong 30 phút và chỉnh sửa hàng trăm file, chi phí cũng chỉ khoảng 0,04 USD
  • Chiến lược tối ưu: viết prompt chi tiết với tiêu chí thành công nghiêm ngặt, rồi yêu cầu “tiếp tục cho đến khi sửa xong mọi lỗi” và để nó chạy

Dùng SQLite làm cơ sở dữ liệu cho mọi thứ

  • Khi bắt đầu một dự án mới, tác giả luôn dùng sqlite3 làm cơ sở dữ liệu chính
  • Theo góc nhìn enterprise, nhiều người cho rằng cần một database server chạy ở tiến trình riêng; nhưng trên thực tế, file SQLite cục bộ giao tiếp qua giao diện C hoặc bộ nhớ lại nhanh hơn nhiều bậc so với một server Postgres từ xa phải đi qua bước nhảy TCP qua mạng
  • Hiểu lầm về vấn đề đồng thời: nhận thức rằng SQLite khóa toàn bộ database với mọi thao tác ghi là không chính xác; việc này được giải quyết bằng cách bật Write-Ahead Logging(WAL)
    • Khi đặt PRAGMA journal_mode=WAL;PRAGMA synchronous=NORMAL;, thao tác đọc và ghi sẽ không chặn lẫn nhau
    • Một file .db duy nhất trên ổ NVMe có thể phục vụ hàng nghìn người dùng đồng thời
  • Để tiện triển khai xác thực người dùng, tác giả đã phát triển thư viện riêng smhanov/auth: tích hợp trực tiếp với database đang dùng, hỗ trợ đăng ký, session, đặt lại mật khẩu và đăng nhập bằng Google/Facebook/X/SAML

Kết luận: xây startup mà không cần hạ tầng phức tạp

  • Ngành công nghệ thường khẳng định rằng để xây một doanh nghiệp thực sự thì cần hệ thống điều phối phức tạp, hóa đơn AWS hàng tháng khổng lồ và hàng triệu USD vốn đầu tư mạo hiểm, nhưng thực tế không phải vậy
  • Bằng cách kết hợp một VPS duy nhất, binary biên dịch tĩnh, tác vụ AI theo lô trên phần cứng GPU cục bộ và tốc độ thô của SQLite, bạn có thể bootstrap một startup có khả năng mở rộng với chi phí chỉ bằng vài ly cà phê mỗi tháng
  • Điều này mang lại cho dự án runway vô hạn, để bạn có thời gian tập trung giải quyết vấn đề của người dùng thay vì lo lắng về burn rate

1 bình luận

 
Ý kiến trên Hacker News
  • Trong môi trường doanh nghiệp, nhiều người tin rằng phải dùng máy chủ DB bên ngoài, nhưng thực tế tệp SQLite cục bộ nhanh hơn rất nhiều so với Postgres từ xa khi giao tiếp qua giao diện C hoặc bộ nhớ
    Tất nhiên SQLite rất tuyệt, nhưng nếu kết nối tới Postgres trên localhost bằng Unix domain socket thì gần như loại bỏ được overhead mạng
    Nó không khó dùng hơn SQLite là bao, vẫn tận dụng được toàn bộ tính năng của Postgres, đồng thời cũng dễ hơn nhiều trong việc chạy báo cáo, thiết lập read replica hay cấu hình HA
    Chạy Postgres trên cùng máy chủ với ứng dụng là một lựa chọn hoàn toàn khác mức độ so với việc quá tay dựng cả cụm Kubernetes

    • Ngay cả trên cùng một máy, SQLite vẫn nhanh hơn Postgres dùng domain socket rất nhiều (ví dụ 100.000 TPS)
      Khi chạy monolithic app trên một máy duy nhất, Postgres không mang lại nhiều tính năng hơn SQLite
      SQLite có thể được mở rộng trực tiếp bằng ngôn ngữ của ứng dụng qua Application functions, và nhờ Litestream mà việc sao lưu và sao chép cũng tốt hơn nhiều
      Tuy vậy, cấu hình mặc định không tốt lắm, nên cần tách kết nối đọc/ghi và để ứng dụng tự quản lý write queue
    • Thực tế, khi chạy 100.000 truy vấn SELECT 1, Postgres mất 2,77 giây còn SQLite (in-memory) mất 0,07 giây, chênh lệch rất lớn (link benchmark)
    • Tôi từng dùng SQLite cùng các phần mở rộng trong kịch bản hiệu năng cao xử lý hàng triệu tài liệu mỗi giây
      Làm bằng máy chủ từ xa cũng có thể được, nhưng sẽ phức tạp hơn nhiều
      Thay vào đó, tôi đưa DB lên S3 để mỗi instance nhận một bản sao và xử lý song song. SQLite là một phương án thay thế đã được kiểm chứng khi cần hiệu năng hơn là nhiều tính năng
    • Câu “có thể dùng mọi tính năng của Postgres” chẳng phải chính là kiểu tiếp cận YAGNI (You Ain’t Gonna Need It) mà bài viết đang phê phán sao?
    • Càng nhiều tính năng không cần đến thì càng là tổn thất ròng. DB lý tưởng là DB chỉ cung cấp đúng những gì cần thiết
  • Nhiều người tin rằng ngay từ đầu phải dựng cấu hình phức tạp như serverless, Kubernetes, multi-zone HA
    Nếu nói rằng “cứ chạy trên VPS giá rẻ là được”, phản ứng thường là “còn scaling?”, “backup?”, “bảo trì?” — thực chất chỉ là lặp lại khẩu hiệu marketing của cloud
    Thái độ này gần như là một dạng bất lực được học sẵn

    • Khi làm tư vấn, tôi từng thiết kế 25 thành phần cloud cho một ứng dụng có chưa tới 200 người dùng. Tất cả đều là kết quả của việc bị huấn luyện rằng ‘cloud = phải phức tạp’
    • Người phụ trách mua sắm IT rất sẵn sàng tiêu tiền công ty để khỏi phải hiểu hệ thống hoạt động ra sao
    • Gần đây tôi cũng thấy hiện tượng tương tự trong quy trình làm việc dựa trên agent. Dữ liệu huấn luyện đầy các codebase dành cho đội ngũ lớn, nên cả dự án nhỏ cũng bị kéo theo cấu trúc khổng lồ
      Ví dụ một SPA chỉ có vài form nhập đơn giản mà vẫn nhét đủ Shadcn, Tailwind, React, Zod và Vite. Gánh nặng bảo trì là rất lớn
      Cách làm này có thể là “đáp án đúng”, nhưng không phải đáp án phù hợp với tình huống
    • “Thế hệ cloud-native” nhờ các gói miễn phí mà không có cơ hội học xem một ứng dụng cơ bản thực sự cần gì
    • Dù vậy, tôi vẫn nghĩ backup là quan trọng
  • Tôi dùng Linode hoặc DigitalOcean nên chỉ trả 5~10 USD mỗi tháng. 1GB RAM là đủ
    Gom nhiều dự án lên một máy chủ riêng còn giúp giảm chi phí hơn nữa
    Ví dụ tôi dùng máy 40 euro/tháng trên đấu giá máy chủ Hetzner, cài Proxmox lên đó để chạy nhiều VM (link Proxmox)
    Dù tạo 15 VM thì mỗi VM cũng chỉ khoảng 2,66 euro, nên hiệu quả chi phí theo quy mô rất cao
    Nếu là phần cứng tân trang thì backup là bắt buộc, nhưng dù sao đó cũng là việc phải làm
    Hetzner, Contabo hay Scaleway vẫn là những lựa chọn rẻ

    • Giá Hetzner có tăng, nhưng OVH đang cung cấp phần cứng mới hơn với mức giá tương tự
    • Tôi tò mò vì sao lại dùng VM mà không dùng container
    • Cũng tò mò việc xử lý IPv4 thế nào. Không rõ về mặt thương mại có được phép thuê một VM lớn làm hypervisor hay không
    • Có vẻ chạy bằng container Docker sẽ hiệu quả hơn chăng
  • Tôi nghĩ WAL mode của SQLite là yếu tố tiết kiệm chi phí lớn nhất
    Python hay Node cũng dùng tốt như Go. VPS Hetzner 4GB RAM, 10TB network chỉ khoảng 5 USD/tháng
    Tuy nhiên, nếu dùng máy chủ riêng thì phải backup DB thường xuyên và tự chịu trách nhiệm về bảo mật
    Tôi cấu hình bằng Terraform để chỉ cho IP của mình SSH vào, sau đó thiết lập Tailscale rồi đóng cổng SSH công khai

    • Với backup, an toàn hơn là dùng storage của một công ty khác với nhà cung cấp VM. Như vậy nếu tài khoản bị khóa vẫn còn khả năng khôi phục
      Tôi dùng Backblaze B2, nhưng với Restic thì cũng dễ backup sang dịch vụ khác
    • Để bảo mật SSH thì không nhất thiết cần cấu hình quá phức tạp. Chỉ cần mật khẩu mạnh cũng đủ
    • Trước đây tôi từng để Postgres mở với mật khẩu mặc định và chỉ sau một ngày đã bị hack thành máy chủ bot
      Gần đây log thử SSH cũng chất đống chỉ trong một giờ. Giờ tôi tắt đăng nhập bằng mật khẩu và chỉ truy cập qua Tailscale
      Máy chủ lộ ra Internet thực sự rất nguy hiểm
    • Khó tin là SSH có thể bị nhiễm chỉ sau một giờ. Nếu không phải mật khẩu yếu hoặc mở VNC thì có lẽ không thể
    • Tôi cũng đã bỏ Postgres và chuyển sang SQLite WAL khi chuyển site Django sang Docker Compose. Việc quản lý và backup đơn giản hơn nhiều
  • Tôi nghĩ giới hạn 1GB RAM là không cần thiết. Với 20 USD/tháng có thể có 8GB RAM để dùng cho cache hoặc DB
    Chênh lệch 15 USD không ảnh hưởng lớn đến vận hành doanh nghiệp. Cách nghĩ cố ép về VPS 5 USD không giúp tăng trưởng kinh doanh

    • Nhưng 15 USD cũng không phải số tiền có thể xem nhẹ. Nếu 1GB là đủ thì chẳng có lý do gì phải chi thêm
      Trước đây 128MB cũng chạy LAMP stack tốt, và website ngày nay cũng không hẳn phức tạp hơn nhiều
    • Độ trễ đọc NVMe chỉ khoảng 100µs, nên với SQLite vẫn có thể xử lý hàng trăm request mỗi giây
      Không cần cache vẫn chịu được 17 triệu request/ngày, nên việc tăng hạ tầng lên gấp 4 trước đó là lãng phí
    • Lý do thực sự của giới hạn 1GB là để rèn luyện tránh over-engineering và tập trung vào giá trị cho khách hàng
    • Hệ thống hiện đại có hiệu quả RAM cao hơn nhiều nhờ nén trang và NVMe swap.
      Macbook Neo bản 8GB là ví dụ điển hình
    • Tôi cũng thấy chênh lệch 15 USD không lớn, nhưng cốt lõi vẫn là tối thiểu hóa chi phí hosting
  • WebSequenceDiagram có vẻ là một sản phẩm rất hay
    Nhưng thứ khó hơn triển khai kỹ thuật là tìm ra vấn đề thực sự có giá trị và tiếp cận được người dùng. Giá trị thật nằm ở đó

    • Tôi cũng có cùng trăn trở. Sau khi làm việc và dành thời gian cho gia đình thì một ngày là không đủ. Nhưng một khi biết được vấn đề của một lĩnh vực cụ thể, lời giải lại có vẻ quá rõ ràng
    • Đã có nhiều sản phẩm cạnh tranh rồi. Ví dụ như Excalidraw
  • Tôi đã đăng ký GitHub Copilot từ năm 2023, kết nối với VS Code và dùng liên tục từ đó tới nay
    Điểm mấu chốt là Microsoft tính phí theo từng request. Chỉ với một request, dù nó sửa toàn bộ code trong vài chục phút, tôi cũng chỉ tốn khoảng 0,04 USD
    Vì vậy tôi viết prompt thật cụ thể, bảo nó “tiếp tục cho đến khi sửa xong mọi lỗi”, rồi đi pha cà phê. Về cơ bản là Satya Nadella đang trợ cấp chi phí tính toán cho tôi

    • Tuy vậy, đã có trường hợp tài khoản bị khóa vì kiểu lạm dụng theo request này (trường hợp trên Reddit)
    • Tác giả gọi GPT‑4o và Sonnet 3.5 là SOTA, nên mẹo AI thì nên đọc với chút hoài nghi
    • (Bình luận đã xóa) nói rằng không hiểu vì sao bị downvote
  • Tôi không học được gì mới từ bài viết này. Phần lớn có cảm giác như lời khuyên nhập môn được AI gói lại
    Chỉ nhìn tiêu đề tôi đã tưởng đây sẽ nói về tìm ý tưởng và ra mắt thành công

    • Với tiêu đề kiểu “dưới 5 USD/tháng” thì đương nhiên sẽ là các lời khuyên cơ bản. Nhưng ngạc nhiên là vẫn có nhiều người chưa biết những điều này
    • Nếu vậy thì tôi khuyên bạn hãy bắt đầu blog. Kiến thức bạn thấy là cơ bản có thể lại mới mẻ với người khác
    • Tôi cũng sẵn sàng chi 5.000 USD/tháng để kiếm 10.000 USD nếu làm được. Vấn đề là tìm ra cách tạo doanh thu
    • Câu “cần khả năng suy luận tối tân của Claude 3.5 Sonnet hay GPT‑4o” là dấu vết của bài viết do AI tạo ra
    • Nhưng lạm phát tài nguyên mà tác giả nói đến là có thật. Tôi thường thấy những việc chỉ cần script Python đơn giản lại bị giải bằng AWS và Spark quá mức cần thiết
  • Phòng khi có ai tò mò như tôi, MRR là viết tắt của “Monthly Recurring Revenue” (doanh thu định kỳ hàng tháng)

    • Thật ngạc nhiên là đã đăng ký 16 năm rồi mà vẫn không biết MRR là gì
    • Còn có ARR (Annual Recurring Revenue) nữa, nhưng thường chỉ là MRR nhân 12 để thổi phồng con số.
      Tôi từng thấy có người mới vận hành được hai tháng đã công bố ARR
  • Tư duy lấy cloud làm trung tâm trong nhiều trường hợp chỉ làm tăng độ phức tạp và chi phí một cách không cần thiết
    Phần lớn dự án chỉ cần một VPS tầm trung là đủ
    Công ty chúng tôi từng chạy trang có 600.000 người dùng bằng một VPS 30 euro, rồi chuyển sang AWS và trả 800 euro/tháng. Chẳng được lợi gì cả
    Nếu không có lý do rõ ràng thì nên giữ cách làm máy chủ đơn giản đã hoạt động tốt suốt hàng chục năm
    Nhân tiện, tôi nghe nói StackOverflow cũng chạy trên chỉ vài máy chủ root mạnh