Private AI · Investigation Architecture · 22 AUG 2026

เครื่องมีพอแล้ว
ระบบงาน สำคัญกว่า

เป้าหมายไม่ใช่ LLM ที่เร็วที่สุด แต่คือระบบวิเคราะห์คดีที่รับข้อมูลจำนวนมาก คำนวณแม่น อ้างกลับถึงหลักฐาน และใช้ Cloud เฉพาะงานที่คุ้มค่าจริง

4 hardware roles5-step evidence flowdeterministic numbershybrid AI router30-day measurement gate

อ่าน 30 วินาที: คำตัดสิน 4 ข้อ

เริ่มจากของที่มี วัดคิวจริง และแยก “ความจุ” ออกจาก “ความเร็ว”

฿0งบซื้อเพิ่มที่แนะนำทันที

5ขั้นจากเอกสารถึงรายงานตรวจย้อนกลับได้

30 วันช่วงวัดคอขวดก่อนอนุมัติฮาร์ดแวร์

1 TruthDatabase/SQL เป็นเจ้าของข้อเท็จจริง ไม่ใช่ LLM

4 สถาปัตยกรรม แก้คนละปัญหา

อย่าจัดอันดับรวมเป็นแถวเดียว ให้ถามก่อนว่า “คอขวดคือความเร็ว ความจุ CUDA หรือความจุโมเดลใหญ่”

CUDA workhorse

RTX 3090 ×2

วัดแล้ว · ใช้งานจริง

24GB + 24GB VRAM · วัดได้ 143 tok/s

เหมาะกับ OCR batch, embedding, reranking, vision และโมเดลที่ runtime แบ่งข้าม 2 GPU ได้ แต่ VRAM ไม่ได้รวมเป็นก้อนเดียวอัตโนมัติ; งานเกิน VRAM แล้ว offload ไป RAM จะติด PCIe. [15]

วัดจริง 24 ส.ค. 69: โมเดล 35B MoE ที่ Q8 context 262K · KV f16 ไม่บีบ ได้ 143 tok/s โดยกิน VRAM 44.3 จาก 48GB — อยู่ครบในการ์ด ไม่ต้อง offload
ทดสอบ needle-in-haystack ภาษาไทยที่ 250,000 token → หาเจอถูกต้อง (prefill 88 วิ · ตอบ 74.5 tok/s)
ไม่ยืด RoPE/YaRN เกิน 262K ที่โมเดลฝึกมา — เลือกคุณภาพ recall แทนตัวเลข context ที่สวยกว่า
ข้อกังวลเดิมเรื่อง offload ไป RAM แล้วติด PCIe จึงยังไม่เกิดกับ workload ระดับนี้

Large-model lane

M1 Ultra 128GB

ใช้ของเดิมก่อน

128GB · 800GB/s

เหมาะกับโมเดลใหญ่บน MLX/llama.cpp และ reasoning จากข้อมูลที่ clean แล้ว แต่ระบบปฏิบัติการ, KV cache และ runtime ต้องใช้ memory ด้วย จึงห้ามตีความว่าโมเดลใช้ได้เต็ม 128GB. [16]

จุดเด่น: unified memory และความจุสูง
จุดระวัง: ไม่มี CUDA และ bandwidth ไม่รับประกัน token/s

Fast 32GB CUDA lane

RTX 5090

ซื้อเมื่อคิวช้า

32GB GDDR7

เหมาะเมื่อโมเดลและ KV cache ใส่ 32GB ได้ และคอขวดคือ OCR/vision/video หรือ token throughput. NVIDIA ระบุ 32GB GDDR7 และ Blackwell; ไม่ใช่คำตอบของโมเดลที่ต้องใช้ memory เกิน 32GB. [14]

ซื้อเมื่อ: งาน ≤32GB รอคิวนานต่อเนื่อง
ไม่ซื้อเมื่อ: จุดเจ็บคือโมเดลใหญ่กว่า VRAM

Large CUDA capacity

DGX Spark 128GB

ซื้อเมื่อมี hard gate

128GB · 273GB/s

เพิ่ม capability ที่เครื่องอื่นไม่มี: CUDA + unified memory 128GB. NVIDIA ระบุรองรับโมเดลสูงสุด 200B class แต่ตัวเลขนั้นคือ capacity claim ไม่ใช่คำรับรองความเร็ว และ host เป็น Arm64 จึงต้องทดสอบ container/dependency จริง. [13][17]

ซื้อเมื่อ: งาน CUDA ต้องใช้เกิน 48GB จริง
ไม่ซื้อเพียงเพราะ: “128GB มากกว่า 32GB”

Bandwidth ratio ≠ speed ratioM1 Ultra 800/273 ≈ 2.93× และ RTX 5090 1,792/273 ≈ 6.56× เป็นเพียงเพดาน memory subsystem; kernel, quantization, compute, interconnect และ runtime ทำให้ token/s ต่างจากอัตรานี้ได้มาก.

Model size ≠ usable capacityต้องเผื่อ runtime, KV cache, context และ OS เสมอ โมเดลที่ไฟล์ใกล้เพดาน memory อาจโหลดได้แต่ใช้งานจริงไม่เสถียร.

FIELD MEASUREMENT · 2026-08-23

คอขวดที่วัดเจอ ไม่ใช่ GPU

รายงานฉบับก่อนสรุปว่า “อย่าเพิ่งซื้อ ให้วัดหาคอขวดก่อน” — นี่คือผลวัดจริงครั้งแรกจากเครื่องที่ประกอบเสร็จ

COMPUTE

122 tok/s

โมเดล 35B MoE · Q8 · context 256K · กระจายข้าม 2 การ์ด · กิน VRAM 42.8 จาก 48GB

ยังมี headroom — ไม่ใช่คอขวด

STORAGE PATH

909 MB/s

NVMe 4 ตัวบนการ์ด PCIe switch (Gen3 x8) เสียบสล็อต x4 ที่เจรจาลงมาเหลือ Gen1 — เร็วกว่าไดรฟ์เดี่ยว (846 MB/s) เพียง 8%

นี่คือคอขวดจริง

THERMAL

50 °C

อัดงานต่อเนื่อง 3 นาที อุณหภูมิสูงสุด 50°C ห่างเพดาน throttle ที่ 85°C อยู่ 35 องศา

ตัดสมมติฐานความร้อนออกได้

สิ่งที่ตัวเลขนี้เปลี่ยน ถ้าเชื่อสเปกบนกล่องแล้วสั่งซื้อ GPU เพิ่ม จะแก้ผิดจุด — เพราะการรวมไดรฟ์เป็น RAID0 ไม่ได้ช่วยเลย (ทุกตัวแชร์ท่อเดียวกัน) และเงินก้อนถัดไปที่คุ้มที่สุดคือสายต่อขยาย PCIe ไม่กี่พันบาท ไม่ใช่การ์ดจอ

ความเร็วลิงก์ตอนว่าง ≠ ตอนทำงานGPU ทั้งสองใบรายงาน PCIe 2.5 GT/s ตอนเครื่องว่าง ซึ่งดูเหมือนเสียทั้งคู่ แต่พอยิงงาน generate จริงกลับขึ้น 16 GT/s ทันที เพราะไดรเวอร์ลดลิงก์เองเพื่อประหยัดไฟ — อ่านค่าตอนว่างอย่างเดียวจะสรุปผิดว่าฮาร์ดแวร์พัง.

การ์ด switch ≠ การ์ด bifurcationการ์ด M.2 หลายช่องที่ใช้ชิป packet switch ทำงานได้ในสล็อตความกว้างใดก็ได้ ไม่ต้องพึ่ง bifurcation ของเมนบอร์ด หลักฐานคือไดรฟ์ขึ้นครบ 4 ตัวทั้งที่เสียบสล็อต x4 — แต่แลกด้วยเพดานรวมที่ขาขึ้นซึ่งทุกไดรฟ์ต้องแชร์กัน.

อ่านค่าที่พอร์ตขอ ก่อนโทษการตั้งค่าถ้า target link speed ที่ต้นทางขอความเร็วสูงสุดอยู่แล้วแต่ได้ต่ำ แปลว่าเป็นเรื่องสัญญาณหรือหน้าสัมผัส ไล่ตั้งค่าใน BIOS ต่อก็เสียเวลาเปล่า.

ระบบคดีที่แม่น: ให้ AI ตีความ ไม่ให้ AI เป็นบัญชี

ทุกตัวเลขและข้อเชื่อมโยงต้องย้อนกลับถึงแถวข้อมูลหรือเอกสารต้นทางได้

01 · INGESTOCR / Parse

PDF, รูป, Excel, statement พร้อม confidence และ source pointer

02 · VALIDATEExtract / Check

ชื่อ เบอร์ บัญชี วันเวลา เงิน พร้อม checksum, pattern และ normalization

03 · TRUTHSQL / Graph

Database เก็บข้อเท็จจริง คำนวณ SUM/COUNT และเชื่อม entity

04 · REASONLocal + Cloud

Local สรุป/ค้น; Cloud เฉพาะโจทย์ยากที่ผ่าน policy gate

05 · RELEASEReview / Cite

ตรวจต่างโมเดล + human approval + กดกลับถึงหลักฐาน

Database = ข้อเท็จจริงยอดเงิน จำนวนครั้ง วันเวลา และความสัมพันธ์หลักต้องมาจาก query ที่ทำซ้ำได้

AI = ผู้ช่วยตีความสรุป pattern, contradiction, hypothesis และภาษารายงานจากผลที่คำนวณแล้ว

Human = ผู้อนุมัติAI/OCR เป็น lead ไม่ใช่หลักฐานชี้ตัว บุคคลต้องตรวจ source ก่อนใช้งานจริง

ซื้อเมื่อไร: ให้คอขวดเป็นคนเลือกเครื่อง

การซื้อผ่านเกตเมื่อมี log งานจริง คุณภาพผ่าน และคำนวณการทดแทน Cloud ได้ ไม่ใช่ตัดสินจาก benchmark ของคนอื่น

สิ่งที่วัดได้จริง	คำตอบที่ควรเลือก	เหตุผล
งาน CUDA ≤32GB รอคิว / latency สูงต่อเนื่อง	RTX 5090	เพิ่ม throughput โดยตรงสำหรับโมเดลและงานสื่อที่ใส่ VRAM ได้
โมเดล CUDA ต้องใช้มากกว่า 48GB และ Arm64 stack ผ่าน PoC	DGX Spark	เพิ่ม capacity ใหม่: CUDA + unified memory 128GB
ต้อง reasoning โมเดลใหญ่ แต่ไม่บังคับ CUDA	M1 Ultra เดิม	มี unified memory 128GB อยู่แล้ว ไม่ต้องซื้อ capacity ซ้ำ
มี 3090 ×2 และงาน OCR / embedding / reranking / vision batch ยังมี headroom	ใช้ 3090 ×2 ต่อ	วัดแล้ว 24 ส.ค. 69: 143 tok/s บนโมเดล 35B Q8 context 262K ยังมี headroom
วัดแล้วพบว่าคอขวดอยู่ที่เส้นทางข้อมูล ไม่ใช่ compute	แก้เส้นทางข้อมูลก่อน	สายต่อขยาย PCIe หลักพัน แก้ได้ตรงจุดกว่าการ์ดจอหลายหมื่น
ยังไม่มี queue, quality, cost-displacement telemetry	ไม่ซื้อ	ยังพิสูจน์ไม่ได้ว่าเงินแก้คอขวดใด

หลักฐานเดิม: MLX เร็วขึ้น แต่คุณภาพยังต้องสอบ

A/B ใช้โมเดลขนาดเดียวกัน 3 runs ต่อ variant ผลมีความแปรปรวน จึงรายงาน median และไม่ขยายผลเกินข้อมูล

Qwen3.8 27B · Apple Silicon

MEDIAN GENERATION THROUGHPUT · 3 RUNS / VARIANT

Standard runtime

16.07 tok/s

MLX optimized

22.87 tok/s

+42.3%median speed gain
quality parity = ยังต้องพิสูจน์

Router ที่ควรคงไว้

ไม่ใช่ local-only และไม่ใช่ cloud-only แต่เป็น policy-first routing ที่แยกความสามารถออกจากขอบเขตข้อมูล

Capability lane

Frontier Cloud

งาน agent ซับซ้อน การเขียนโค้ดหลายขั้น และการตรวจข้ามโมเดล เมื่อข้อมูลผ่านเกตแล้ว

Decision layer

Policy Router

เลือก lane ตามความไวของข้อมูล ความเสี่ยง ความเร็ว และหลักฐานจาก benchmark

Private lane

Local Models + Tools

ข้อมูลอ่อนไหว งาน offline, RAG synthesis, embeddings และ deterministic code/SQL

กระแสไหนควรหยิบ กระแสไหนควรวาง

Repository popularity เป็นสัญญาณความสนใจ ไม่ใช่ production gate

Trend	สถานะ	เหตุผล
MLX-optimized models	Pilot now	ผ่านเกตความเร็วแล้ว แต่ต้องมี golden set ยืนยัน refusal, JSON/tool schema, citation และ error recovery
llama.cpp agent / MCP	Lab only	ฟีเจอร์มีจริง แต่ runtime ระบุ experimental; อย่าเปิด production จากโพสต์ตัวอย่างเพียงอย่างเดียว
Ollama Launch integrations	Pilot	เหมาะสำหรับทดสอบ harness เดิมกับโมเดล local โดยไม่ย้ายทั้งสถาปัตยกรรม
LiteLLM / model gateway	Wait	เพิ่มเมื่อมีช่องว่าง routing ที่วัดได้ ไม่ใช่เพิ่มเพราะ diagram นิยม
vLLM / SGLang	Conditional	เหมาะเมื่อมี NVIDIA worker และต้อง serving หลายผู้ใช้; ยังไม่ใช่เหตุผลซื้อฮาร์ดแวร์โดยลำพัง
Unsloth fine-tuning	Wait for data	fine-tune เมื่อมี labeled failure set มากพอ ไม่ใช่ fine-tune เพราะโมเดลใหม่ออก

คะแนนระบบเดิมแบบไม่เข้าข้าง

จุดแข็งอยู่ที่ governance และ evaluation จุดอ่อนอยู่ที่ local agent reliability, simplicity และ throughput แบบหลายผู้ใช้

Privacy & governance9.5

Evaluation discipline9.0

Production hardening8.5

Hardware / workload fit8.5

Simplicity & maintainability6.0

Local agent reliability5.5

Multi-user throughput5.5

แผน 30 วัน: ทำเลย / รอ / ไม่ควร

เปลี่ยนคำว่า “น่าจะประหยัด” ให้เป็นข้อมูลจริงก่อนอนุมัติซื้อ

ทำเลย

เก็บ queue wait, tok/s, VRAM/RAM peak และงานล้มเหลวแยกตาม lane
ทำ golden set 20–30 งาน: OCR, extraction, linking, report
วัด Cloud บาท/งานที่ Local แทนได้จริง

รอหลักฐาน

RTX 5090 รอจนงาน ≤32GB ติด throughput
DGX Spark รอ CUDA workload >48GB และ Arm64 PoC ผ่าน
fine-tune รอ labeled failure set ที่มากพอ

ไม่ควร

ตั้งเป้า Local 80–90% โดยไม่มี telemetry
ให้ LLM บวกยอดเงินหรือเป็น source of truth
ซื้อจาก bandwidth, parameter class หรือดาว GitHub อย่างเดียว

ความเห็นต่างตระกูลโมเดล

ส่วนนี้เป็นผลทบทวนรอบก่อน หน้าแก้ไขล่าสุดต้องผ่าน review ต่างตระกูลใหม่ก่อนขึ้น production

6.5QWEN REVIEW / 10

เห็นตรงกันเรื่อง gap — เห็นต่างเรื่อง deployment

เห็นตรงกันว่า runtime ซ้ำ, local multi-step agent evaluation และ MLX quality parity ยังเป็นจุดอ่อน แต่ข้อเสนอให้เพิ่ม gateway และ NVIDIA-oriented serving ทันทีถูกปฏิเสธ เพราะ ไม่ตรงฮาร์ดแวร์และยังไม่มี operational gap ที่พิสูจน์แล้ว

Primary source ledger

ลิงก์ทั้งหมดถูกเปิดโดยตรงและลงทะเบียนตามลำดับ ไม่สร้าง URL จากความจำ

[1]Ollama · Qwen3.8, MLX และ agent integrations [2]llama.cpp · Qwen3.8 agent และ MTP example [3]Unsloth · Dynamic GGUF และ fine-tuning [4]Ollama · Local performance recommendation [5]GitHub · ollama/ollama [6]GitHub · ggml-org/llama.cpp [7]GitHub · open-webui/open-webui [8]GitHub · ml-explore/mlx-lm [9]GitHub · BerriAI/litellm [10]GitHub · mostlygeek/llama-swap [11]LiteLLM · PyPI compromise timeline [12]llama.cpp · Qwen tool-call issue [13]NVIDIA · DGX Spark 128GB, 273GB/s, Arm CPU และ 200B model class [14]NVIDIA · GeForce RTX 5090 32GB GDDR7 และ Blackwell [15]NVIDIA · GeForce RTX 3090 24GB GDDR6X ต่อใบ [16]Apple · M1 Ultra 128GB unified memory และ 800GB/s [17]NVIDIA · DGX Spark Arm64 porting และ CUDA build guidance

Method & boundary: หน้าเว็บนี้เป็น public-sanitized edition ข้อมูลระบุตัวเครื่อง, เครือข่าย, path, endpoint, credential และ topology ภายในไม่ถูกนำขึ้นเผยแพร่ ตัวเลข benchmark เป็น sample ขนาดเล็กและไม่ใช้แทน quality evaluation