Lemonade của AMD: máy chủ LLM cục bộ nhanh, mã nguồn mở, sử dụng GPU ...

Lemonade của AMD: Máy chủ LLM cục bộ nhanh và mã nguồn mở sử dụng GPU và NPU

Một máy chủ LLM cục bộ dùng trong thực tế không còn thực sự “cục bộ” ngay khi nó cần 18 giây để trả lời một prompt dài 20 token. Tôi đã nhiều lần thấy tình trạng này trên laptop của lập trình viên: về mặt kỹ thuật, mô hình vẫn chạy, mức sử dụng CPU giữ ở 700%, quạt tăng tốc và token đầu tiên chỉ xuất hiện sau khi người dùng đã mất mạch suy nghĩ.

Đó là bài toán kỹ thuật mà Lemonade đang cố giải quyết: khiến suy luận cục bộ mang lại trải nghiệm như một dịch vụ thực thụ, thay vì một script trình diễn.

Lemonade của AMD là máy chủ LLM cục bộ mã nguồn mở được thiết kế để chạy các mô hình ngôn ngữ trên phần cứng máy khách, đặc biệt là các hệ thống AMD có khả năng tăng tốc GPU và NPU Ryzen AI. Điểm thú vị không chỉ là “chạy mô hình trên máy”. Chúng ta đã có nhiều cách để làm điều đó. Điểm thú vị nằm ở cách tổ chức máy chủ: cung cấp các mô hình cục bộ qua API, định tuyến suy luận qua các bộ tăng tốc hiện có và cho phép sử dụng từ mã ứng dụng thông thường.

Với các kỹ sư xây dựng trợ lý lập trình cục bộ, trợ lý tài liệu riêng tư, môi trường thử nghiệm cô lập cho tác tử hoặc quy trình suy luận ngoại tuyến, đây là lớp trừu tượng phù hợp. Bạn không muốn mọi ứng dụng đều phải biết cách tải mô hình, lượng tử hóa trọng số, chọn bộ thực thi, ghim bộ nhớ, truyền token liên tục và quản lý phiên. Bạn muốn có một dịch vụ suy luận cục bộ.

Lemonade thực sự dùng để làm gì

Ở cấp độ tổng quan, Lemonade là một máy chủ mô hình cục bộ. Nó nằm giữa ứng dụng và phần cứng của bạn.

Thay vì nhúng logic suy luận trực tiếp vào ứng dụng, bạn chạy một tiến trình nền cục bộ:

lemonade-server serve

Sau đó, ứng dụng giao tiếp với tiến trình này qua HTTP, thường thông qua API chat completions theo kiểu OpenAI:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/api/v1",
    api_key="not-needed-for-local"
)

response = client.chat.completions.create(
    model="llama-3.1-8b-instruct",
    messages=[
        {"role": "system", "content": "You are a concise coding assistant."},
        {"role": "user", "content": "Write a Python function to chunk text by tokens."}
    ],
    temperature=0.2,
    stream=True,
)

for chunk in response:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

Cấu trúc API rất quan trọng. Nếu backend của bạn đã hỗ trợ GPT-5.5, Claude Sonnet 4.6, Gemini 3 hoặc một endpoint mô hình mở, bạn thường có thể trỏ cùng lớp trừu tượng phía máy khách đó đến Lemonade để thực thi cục bộ. Nhờ vậy, bạn có thể thử nghiệm định tuyến mô hình, các tính năng nhạy cảm về quyền riêng tư và quy trình ngoại tuyến mà không phải viết lại ứng dụng theo một SDK mới.

Trong thực tế, tôi xem máy chủ LLM cục bộ là một thành phần hạ tầng:

App / IDE / Agent Runtime
        |
        | HTTP streaming chat API
        v
Lemonade local server
        |
        | model loader + scheduler
        v
Execution backend
        |
        | GPU / NPU / CPU fallback
        v
AMD client hardware

Sự phân tách rõ ràng này giúp giải pháp có thể sử dụng được trong các hệ thống thực tế.

Vì sao cả GPU lẫn NPU đều quan trọng

Phần lớn kỹ sư đã hiểu vì sao tăng tốc GPU quan trọng với suy luận LLM: phép nhân ma trận chiếm phần lớn thời gian chạy, và GPU được xây dựng để tính toán song song. NPU còn mới hơn và dễ bị hiểu sai hơn.

NPU không phải là “GPU nhỏ hơn”. Đây là bộ tăng tốc chuyên dụng được tối ưu hóa cho các phép toán mạng nơ-ron trong giới hạn chặt chẽ về điện năng và nhiệt độ. Trên laptop, điều đó rất quan trọng. Bộ công nghệ suy luận cục bộ tốt nhất không phải lúc nào cũng là bộ đạt số token mỗi giây cao nhất trong một bài đo hiệu năng kéo dài 30 giây. Thường thì đó là bộ vẫn phản hồi nhanh khi người dùng đang chạy Slack, trình duyệt, VS Code và Docker.

Cách hình dung hữu ích:

• GPU: phù hợp hơn với mô hình lớn, thông lượng cao và khối lượng tính toán song song nặng.
• NPU: phù hợp với các mô hình tiêu thụ ít điện năng, hoạt động liên tục, có kích thước nhỏ hoặc đã được tối ưu hóa.
• CPU: phương án dự phòng đáng tin cậy, nhưng thường có độ trễ cao khi dùng LLM tương tác.
• Hệ thống kết hợp: hữu ích khi định tuyến công việc dựa trên kích thước mô hình, mức lượng tử hóa và tài nguyên sẵn có.

Ví dụ, một trợ lý cục bộ có thể sử dụng:

{
  "routes": {
    "autocomplete": {
      "model": "small-code-model",
      "device": "npu",
      "max_tokens": 64
    },
    "chat": {
      "model": "llama-3.1-8b-instruct-q4",
      "device": "gpu",
      "max_tokens": 1024
    },
    "summarization": {
      "model": "compact-instruct",
      "device": "auto",
      "max_tokens": 512
    }
  }
}

Đó là cách tiếp cận tôi thích: đừng cố chấp chọn duy nhất một bộ tăng tốc. Hãy chọn đích thực thi phù hợp cho từng khối lượng công việc.

Vị trí của Lemonade trong các máy chủ LLM cục bộ

Hiện đã có nhiều lựa chọn suy luận cục bộ hoàn thiện. Điểm khác biệt của Lemonade là khả năng tăng tốc cục bộ ưu tiên AMD, đặc biệt trên những hệ thống mà cả GPU và NPU đều là thành phần của nền tảng máy khách.

Lemonade không thể thay thế trực tiếp mọi hệ thống suy luận. Nếu bạn đang phục vụ hàng trăm người dùng đồng thời bằng GPU tại trung tâm dữ liệu, kiến trúc gom lô liên tục kiểu vLLM thường phù hợp hơn. Nếu bạn cần khả năng chạy linh hoạt nhất có thể trên đủ loại máy, llama.cpp vẫn khó có đối thủ.

Lemonade trở nên đáng chú ý khi máy đích là máy tính xách tay, máy trạm hoặc thiết bị biên dùng AMD và bạn coi trọng một máy chủ cục bộ được hỗ trợ đầy đủ hơn là một tập lệnh Python chỉ dùng một lần.

Kiến trúc cục bộ thực tiễn

Đây là một mô hình kiến trúc hoạt động hiệu quả cho các ứng dụng AI cục bộ:

┌──────────────────────────────┐
│ Desktop App / Backend Service │
└───────────────┬──────────────┘
                │ OpenAI-compatible client
                v
┌──────────────────────────────┐
│ Local Model Gateway           │
│ - retries                     │
│ - model routing               │
│ - prompt templates            │
│ - telemetry                   │
└───────────────┬──────────────┘
                │ localhost HTTP
                v
┌──────────────────────────────┐
│ Lemonade Server               │
│ - model loading               │
│ - streaming responses         │
│ - device selection            │
│ - accelerator backend         │
└───────────────┬──────────────┘
                │
       ┌────────┴────────┐
       v                 v
   AMD GPU            Ryzen AI NPU

Tôi thường thêm một lớp cổng trung gian gọn nhẹ ngay cả khi máy chủ cục bộ đã cung cấp một API rõ ràng. Cổng này mang lại một giao ước nội bộ ổn định và cho phép bạn chuyển đổi giữa mô hình cục bộ và mô hình từ xa.

Ví dụ:

import os
from openai import OpenAI

def build_llm_client():
    if os.getenv("LLM_MODE") == "local":
        return OpenAI(
            base_url="http://localhost:8000/api/v1",
            api_key="local"
        )

    return OpenAI(
        base_url=os.environ["REMOTE_LLM_BASE_URL"],
        api_key=os.environ["REMOTE_LLM_API_KEY"]
    )

client = build_llm_client()

Khi đó, logic ứng dụng của bạn không cần quan tâm yêu cầu được gửi đến Lemonade, GPT-5.5, Claude Opus 4.8, Gemini 3 hay một mô hình mở được lưu trữ trên máy chủ. Sự linh hoạt này rất có giá trị khi bạn đánh giá chất lượng, độ trễ, quyền riêng tư và chi phí. Nếu nhóm của bạn dùng nhà cung cấp API đa mô hình như AI Prime Tech làm phương án dự phòng trên đám mây, hãy đặt cả luồng cục bộ và luồng từ xa sau cùng một giao diện.

Lựa chọn mô hình: Nhỏ hơn hiệu quả hơn trí thông minh trên lý thuyết

Sai lầm phổ biến nhất khi dùng máy chủ LLM cục bộ là chọn mô hình vì nó có thứ hạng tốt trên bảng xếp hạng thay vì vì nó phù hợp với máy.

Đối với suy luận cục bộ, mức độ phù hợp của mô hình quyết định tất cả:

• Mô hình đã lượng tử hóa có vừa với bộ nhớ khả dụng của bộ tăng tốc không?
• Độ dài ngữ cảnh có thực tế với khối lượng công việc không?
• Thời gian đến token đầu tiên là bao lâu?
• Mô hình có truyền dữ liệu liên tục mượt mà trong điều kiện nhiệt độ thông thường của máy tính xách tay không?
• Ứng dụng có chấp nhận được việc thỉnh thoảng chuyển sang CPU không?
• Chất lượng có đủ tốt cho tác vụ không?

Một mô hình instruct 7B hoặc 8B được lượng tử hóa xuống 4 bit thường hữu ích hơn khi chạy cục bộ so với một mô hình lớn hơn nhiều nhưng liên tục tràn bộ nhớ, bị khựng hoặc buộc phải cắt giảm mạnh ngữ cảnh. Với các tác vụ lập trình, những mô hình mở từ Qwen, DeepSeek, Llama, MiniMax và các mô hình phát triển từ Kimi đều có thể là ứng viên hợp lý, tùy theo giấy phép, khả năng hỗ trợ định dạng và mức độ tương thích với backend.

Quy trình phù hợp cần dựa trên thực nghiệm:

# Example benchmark flow; adapt names to installed Lemonade commands/models.
lemonade-server pull llama-3.1-8b-instruct-q4
lemonade-server serve --host 127.0.0.1 --port 8000

Sau đó chạy một câu lệnh có thể dùng để kiểm thử lặp lại:

import time
from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/api/v1", api_key="local")

prompt = "Explain how an LRU cache works, then implement one in Python."

start = time.perf_counter()
first_token_at = None
tokens = 0

stream = client.chat.completions.create(
    model="llama-3.1-8b-instruct-q4",
    messages=[{"role": "user", "content": prompt}],
    stream=True,
    temperature=0.1,
    max_tokens=400,
)

for chunk in stream:
    text = chunk.choices[0].delta.content or ""
    if text and first_token_at is None:
        first_token_at = time.perf_counter()
    tokens += len(text.split())

end = time.perf_counter()

print({
    "time_to_first_token_s": round(first_token_at - start, 3),
    "total_time_s": round(end - start, 3),
    "rough_word_rate_per_s": round(tokens / (end - start), 2)
})

Đây không phải là phép đo hiệu năng hoàn hảo về mặt khoa học. Đây là một phép kiểm tra nhanh thực tiễn. Nó cho bạn biết người dùng sẽ cảm nhận thế nào.

Lựa chọn thiết bị và phương án dự phòng

Một máy chủ cục bộ tốt cần thể hiện việc lựa chọn thiết bị đủ rõ ràng để kỹ sư có thể phân tích nguyên nhân lỗi. Chế độ “Tự động” rất tiện cho đến khi mô hình âm thầm chuyển từ GPU sang CPU và độ trễ của bạn tăng thêm 8x.

Trong các triển khai cục bộ gần với môi trường vận hành thực tế, tôi ưu tiên cấu hình đơn giản và dễ kiểm tra:

{
  "server": {
    "host": "127.0.0.1",
    "port": 8000
  },
  "models": [
    {
      "name": "local-chat",
      "path": "./models/llama-3.1-8b-instruct-q4",
      "device": "gpu",
      "context_length": 8192
    },
    {
      "name": "fast-draft",
      "path": "./models/small-instruct-npu",
      "device": "npu",
      "context_length": 4096
    }
  ],
  "fallback": {
    "allow_cpu": false,
    "on_failure": "return_error"
  }
}

Các tùy chọn cấu hình cụ thể của Lemonade có thể khác nhau theo phiên bản, nhưng nguyên tắc vẫn giữ nguyên: tránh suy giảm hiệu năng mà không thể nhận biết. Nếu luồng xử lý bằng GPU thất bại, tôi muốn ứng dụng biết điều đó. Với các ứng dụng tương tác, trả về một lỗi rõ ràng thường tốt hơn là để người dùng chờ 90 giây cho phản hồi từ CPU.

Một vấn đề thường gặp: trình điều khiển và thư viện thời gian chạy quan trọng không kém mô hình. Khi tăng tốc bằng GPU hoặc NPU không được kích hoạt, máy chủ có thể vẫn “hoạt động”, chỉ là chậm. Luôn xác minh bộ cung cấp thực thi đang hoạt động trong nhật ký khi khởi động.

Các bước kiểm tra hữu ích khi khởi động:

lemonade-server serve --log-level debug

Hãy tìm:

loaded model: local-chat
selected device: gpu
execution provider: <accelerated backend>
context length: 8192
quantization: q4

Nếu nhật ký không thể hiện rõ luồng xử lý qua bộ tăng tốc, hãy coi như bạn chưa xác minh được khả năng tăng tốc.

Truyền dữ liệu liên tục là bắt buộc

Đối với trải nghiệm người dùng LLM cục bộ, truyền dữ liệu liên tục là một yêu cầu bắt buộc. Ngay cả khi tổng thời gian hoàn thành không đổi, cách này vẫn khiến ứng dụng có cảm giác nhanh hơn rõ rệt vì người dùng thấy được tiến trình.

Máy chủ của bạn cần hỗ trợ truyền token liên tục, và máy khách phải tiếp nhận luồng đó đúng cách:

def stream_answer(client, model, messages):
    stream = client.chat.completions.create(
        model=model,
        messages=messages,
        stream=True,
        temperature=0.2,
        max_tokens=700,
    )

    for event in stream:
        piece = event.choices[0].delta.content
        if piece:
            yield piece

Trên thực tế, truyền dữ liệu liên tục còn giúp bạn gỡ lỗi. Nếu độ trễ đến token đầu tiên cao nhưng sau đó quá trình sinh token diễn ra nhanh, nút thắt có thể nằm ở việc tải mô hình, xử lý câu lệnh hoặc độ dài ngữ cảnh. Nếu token đầu tiên đến nhanh nhưng quá trình sinh token rất chậm, nguyên nhân có thể là giới hạn băng thông bộ nhớ, giảm xung do nhiệt hoặc chuyển sang CPU.

Hãy đo riêng các chỉ số sau:

• Thời gian khởi động nguội: từ lúc máy chủ khởi động đến khi mô hình sẵn sàng.
• Thời gian xử lý câu lệnh: từ lúc nhận yêu cầu đến token đầu tiên.
• Tốc độ giải mã: từ token đầu tiên đến token cuối cùng.
• Độ trễ đầu cuối: từ lúc ứng dụng gửi yêu cầu đến khi nhận đầy đủ phản hồi.
• Độ ổn định nhiệt: cùng một phép thử sau năm phút sử dụng.

Chỉ số cuối cùng dễ bị bỏ qua nhưng gây nhiều phiền toái trong sản phẩm thực tế.

Độ dài ngữ cảnh: Yếu tố âm thầm nhân độ trễ

Cửa sổ ngữ cảnh dài rất hữu ích, nhưng không miễn phí. Một mô hình hỗ trợ ngữ cảnh 8192 token hoặc 32768 token vẫn có thể gây khó chịu nếu bạn nhồi nhật ký, tài liệu và lịch sử trò chuyện vào mọi yêu cầu.

Với các hệ thống cục bộ, tôi thường áp dụng giới hạn ngữ cảnh tại cổng trung gian:

MAX_PROMPT_CHARS = 18_000

def trim_context(system_prompt, history, new_user_message):
    packed = [
        {"role": "system", "content": system_prompt},
        *history[-8:],
        {"role": "user", "content": new_user_message},
    ]

    total = sum(len(m["content"]) for m in packed)
    while total > MAX_PROMPT_CHARS and len(packed) > 2:
        removed = packed.pop(1)
        total -= len(removed["content"])

    return packed

Cách này còn thô sơ nhưng hiệu quả. Phiên bản hoàn thiện hơn sử dụng đếm token, nén ngữ nghĩa và truy xuất. Điều quan trọng là việc quản lý ngữ cảnh thuộc về lớp ứng dụng của bạn, thay vì chỉ hy vọng mơ hồ rằng máy chủ sẽ luôn chạy nhanh.

Nếu bạn đang dùng mô hình có ngữ cảnh lớn như Fable 5 với ngữ cảnh 1M trên đám mây, phạm vi thiết kế sẽ thay đổi. Trên hệ thống GPU/NPU cục bộ, bạn nên mặc định rằng ngữ cảnh tốn nhiều tài nguyên, trừ khi kết quả đo cho thấy điều ngược lại.

Các phương pháp tốt nhất để phục vụ mô hình cục bộ kiểu Lemonade

Giữ máy chủ luôn sẵn sàng

Tải mô hình từ trạng thái nguội là một trong những yếu tố gây tổn hại lớn nhất đến trải nghiệm người dùng. Hãy khởi động máy chủ cùng ứng dụng, chủ động tải mô hình mặc định ngay từ đầu và cung cấp trạng thái sẵn sàng riêng biệt với tình trạng hoạt động của tiến trình.

curl http://127.0.0.1:8000/health
curl http://127.0.0.1:8000/models

Ứng dụng của bạn cần phân biệt:

• tiến trình máy chủ đang chạy
• mô hình đã được tải
• bộ tăng tốc đang hoạt động
• luồng xử lý yêu cầu hoạt động bình thường

Cố định phiên bản mô hình

Đừng để các mô hình “mới nhất” âm thầm thay đổi bên dưới một ứng dụng máy tính. Hãy cố định tên mô hình, mức lượng tử hóa và độ dài ngữ cảnh dự kiến.

{
  "model": "llama-3.1-8b-instruct-q4",
  "revision": "2025-02-local-tested",
  "expected_device": "gpu"
}

Ngay cả những thay đổi nhỏ trong bộ tách token, mẫu trò chuyện hoặc lượng tử hóa cũng có thể làm thay đổi hành vi.

Tách kiểm thử chất lượng khỏi kiểm thử tốc độ

Trong nhiều quy trình công việc, một mô hình cục bộ nhanh nhưng đưa ra câu trả lời sai một cách khó nhận ra còn tệ hơn một mô hình chậm hơn. Tôi thường duy trì hai bộ kiểm thử:

evals/
  latency_prompts.jsonl
  task_quality_prompts.jsonl

Ví dụ về một mục kiểm thử chất lượng:

{
  "id": "python_exception_summary_01",
  "messages": [
    {
      "role": "user",
      "content": "Summarize this stack trace and identify the likely bug: ..."
    }
  ],
  "must_include": ["None", "attribute", "guard"],
  "must_not_include": ["database outage"]
}

Cách này không thay thế đánh giá chính thức, nhưng giúp phát hiện sự suy giảm khi bạn thay đổi mô hình, mức lượng tử hóa hoặc luồng xử lý trên thiết bị.

Thiết kế phương án dự phòng từ xa

Suy luận cục bộ có thể thất bại vì những lý do rất bình thường: chế độ tiết kiệm pin của máy tính xách tay, cập nhật trình điều khiển, thiếu tệp mô hình, lượng tử hóa không được hỗ trợ, giảm xung do nhiệt. Nếu tác vụ quan trọng, hãy thiết kế phương án dự phòng.

try:
    answer = call_local_model(messages, timeout_s=20)
except Exception:
    answer = call_remote_model(messages, timeout_s=30)

Hãy quy định rõ về quyền riêng tư. Một số câu lệnh tuyệt đối không được rời khỏi máy. Với những trường hợp đó, hãy dừng xử lý khi không thể bảo đảm điều này.

Hạn chế và đánh đổi

Lemonade phát huy tiềm năng tốt nhất trên các hệ thống AMD tương thích với bộ phần mềm thời gian chạy phù hợp. Điều đó cũng có nghĩa là phạm vi vận hành bao gồm năng lực phần cứng, trạng thái trình điều khiển, khả năng hỗ trợ định dạng mô hình và mức độ trưởng thành của backend tăng tốc.

Các đánh đổi chính:

• Tính di động: tăng tốc tập trung vào AMD rất có giá trị, nhưng các hệ thống gồm nhiều loại máy khác nhau có thể cần nhiều backend.
• Mức độ sẵn có của mô hình: không phải mọi mô hình mở đều được đóng gói hoặc tối ưu hóa cho mọi luồng thực thi.
• Hạn chế của NPU: NPU rất phù hợp để suy luận hiệu quả, nhưng không phải mọi cấu trúc mô hình hay độ dài ngữ cảnh đều phù hợp.
• Khả năng quan sát: máy chủ cục bộ cũng cần nhật ký và số liệu đo lường như các dịch vụ đám mây.
• Khả năng xử lý đồng thời: một chiếc máy tính xách tay của lập trình viên không phải là cụm suy luận phục vụ nhiều bên thuê.

Cách nhìn nhận thực tế là: Lemonade không tạo ra năng lực xử lý một cách thần kỳ. Đây là lớp phục vụ mô hình cục bộ tốt hơn trên phần cứng máy khách có giới hạn. Hiệu năng được cải thiện nhờ sử dụng đúng mô hình, đúng phương pháp lượng tử hóa, đúng bộ tăng tốc và một API máy chủ giúp ứng dụng của bạn không phải xử lý những chi tiết đó.

Những điểm thực tiễn cần ghi nhớ

• Sử dụng Lemonade khi bạn muốn có một máy chủ LLM cục bộ được AMD tăng tốc thay vì nhúng trực tiếp quá trình suy luận vào ứng dụng.
• Xem GPU, NPU và CPU là các đích thực thi khác nhau, với đặc điểm khác nhau về độ trễ, mức tiêu thụ điện và mức độ phù hợp với mô hình.
• Ưu tiên các mô hình nhỏ đã lượng tử hóa mang lại độ trễ ổn định cho tương tác hơn là các mô hình lớn chỉ vừa đủ để chạy.
• Xác minh việc tăng tốc qua nhật ký; một máy chủ “hoạt động” vẫn có thể đang chạy trên CPU.
• Truyền phản hồi theo luồng, đo thời gian đến token đầu tiên và kiểm thử trong điều kiện tải nhiệt kéo dài.
• Đặt cơ chế định tuyến, dự phòng, cắt gọn prompt và chính sách quyền riêng tư tại cổng ứng dụng của bạn.
• Cố định phiên bản mô hình và duy trì các bộ đánh giá nhỏ về độ trễ và chất lượng trước khi phát hành tính năng AI cục bộ.