512 維的人臉嵌入如果用 32 位元浮點數儲存，會佔用 2048 位元組，超過 PostgreSQL 的 TOAST 臨界值（2040 位元組）。這表示資料庫會自動把它們丟到另一個 TOAST 資料表，而不是保留在主表裡，結果就是 I/O 效能翻倍變差——因為要多查一次指標、再讀一次資料。雖然 HNSW 可以完全繞過這個問題，但真正的疑問是：ArcFace 嵌入真的需要 32 位元精度嗎？還是可以安全地降到 16 位元 HALFVEC，直接省一半的儲存空間？
我將微軟的 TRELLIS.2 移植到 Apple Silicon 上，透過 PyTorch MPS 運行。原始版本依賴五個僅限 CUDA 的編譯擴展（flex_gemm、flash_attn、o_voxel、cumesh、nvdiffrast），在 Mac 上沒有對應版本。我從零開始編寫了替代後端：純 PyTorch 稀疏 3D 卷積（替代 flex_gemm）、使用空間雜湊的 Python 網格提取（替代 o_voxel 中的 CUDA 雜湊映射操作）、用於稀疏 Transformer 的 SDPA 注意力機制（替代 flash_attn），以及 GPU 加速的三線性插值（替代 cumesh 和 nvdiffrast）。
我將微軟的 TRELLIS.2（40 億參數的圖像轉 3D 模型）移植到 Apple Silicon 上，透過 PyTorch MPS 執行。原始版本需要 CUDA 搭配 flash_attn、nvdiffrast 和自訂稀疏卷積核心——這些在 Mac 上都無法運作。我用純 PyTorch 替代方案取代了 CUDA 特定操作：包括 gather-scatter 稀疏 3D 卷積、用於稀疏 Transformer 的 SDPA 注意力機制，以及以 Python 實現的網格提取（取代 CUDA 雜湊表操作）。總共在 9 個檔案中修改了數百行程式碼。
有位使用者在 M5 Pro 機器上配置了 24GB 記憶體，想用 Ollama 執行 Qwen 3.6 大型語言模型（LLM），但不確定該選擇 Q4 量化版本（4 位元量化）。他們找不到合適的 Q3 量化解決方案，希望能獲得建議，找到在他們的硬體配置上既能順利運行，又不會過度犧牲模型品質的版本。